Installation de Cursor Agent Skills en 2026 : mattpocock

Dernière mise à jour : 13 août 2026. Les commandes, le nom du programme d’initialisation et l’avertissement concernant la double installation ont été vérifiés dans le README de mattpocock/skills, sur la page du projet dans skills.sh et dans la documentation officielle de Cursor sur les Rules.

Symptôme : les Skills apparaissent dans un dépôt, mais pas dans un autre, ou l’Agent applique des consignes contradictoires.
Solution la plus rapide : installez mattpocock/skills depuis la racine du dépôt avec npx skills@latest add mattpocock/skills, sélectionnez setup-matt-pocock-skills, puis conservez les règles durables dans .cursor/rules.

Cette méthode convient si vous voulez versionner la configuration avec le code, reproduire le même environnement pour plusieurs développeurs et déclencher des workflows comme le TDD, le diagnostic ou la revue de code. Cursor prend officiellement en charge les Agent Skills dans l’éditeur et la ligne de commande depuis la version 2.4, annoncée le 22 janvier 2026. Les Skills sont destinés aux procédures à appliquer selon le contexte, tandis que les Rules servent de consignes persistantes. (cursor.com)

Pour qui ce guide est-il utile ?

Ce guide s’adresse aux développeurs qui utilisent Cursor pour accélérer la conception, les tests, le débogage ou la revue de code. Il est également destiné aux responsables techniques qui veulent éviter une configuration différente pour chaque membre de l’équipe.

Il devient particulièrement utile lorsque votre équipe travaille sur un Mac local et un Mac distant, ou lorsque les dépôts doivent produire les mêmes fichiers de configuration après un clonage propre.

Avant l’installation : choisir la portée plutôt que copier une commande

Le premier choix ne concerne pas la commande. Il concerne l’endroit où les fichiers seront écrits.

Pour un dépôt d’équipe, privilégiez l’installation au niveau du projet. Les Skills deviennent alors des fichiers ordinaires du dépôt, visibles dans git diff, révisables en pull request et récupérables par les autres membres. Une installation utilisateur peut convenir à vos préférences personnelles, mais elle crée une dépendance invisible pour les collaborateurs et les environnements de livraison.

Cursor reconnaît les Skills dans les emplacements prévus par sa configuration d’Agent. Dans le flux présenté par mattpocock/skills, l’installation par skills.sh écrit notamment des fichiers de Skills que vous pouvez modifier et versionner. Vérifiez toujours le chemin réellement créé par l’installeur au lieu de supposer que le terminal a travaillé dans le bon dépôt.

Avant de lancer npx, contrôlez les prérequis suivants :

• Node.js et npx fonctionnent dans le terminal utilisé par Cursor ;
• Git identifie le dépôt courant avec git rev-parse --show-toplevel ;
• votre compte possède le droit d’écrire dans le dépôt ;
• vous êtes sur une branche indépendante ou sur une branche de travail explicitement dédiée ;
• le dépôt ne contient pas déjà une copie de mattpocock/skills installée par une autre méthode ;
• les scripts et fichiers de référence pourront être examinés avant leur exécution.

Dans quel répertoire faut-il lancer npx skills add mattpocock/skills ?
Lancez la commande depuis la racine du dépôt dans lequel vous voulez versionner les Skills. Ne la lancez pas depuis votre dossier personnel, un sous-répertoire d’application ou un autre projet ouvert dans Cursor. Contrôlez le résultat avec pwd, git rev-parse --show-toplevel et git status.

Installation projet : sélectionner peu de Skills, mais le bon programme d’initialisation

Depuis la racine du dépôt, exécutez :

npx skills@latest add mattpocock/skills

L’installeur vous demande généralement quels Skills récupérer et pour quel Agent les installer. La sélection initiale doit rester volontaire. Ajoutez setup-matt-pocock-skills dès cette étape : le projet le présente comme le programme à exécuter une fois par dépôt pour enregistrer les choix propres à l’équipe. Les autres Skills, par exemple ceux liés au TDD, au triage, au diagnostic ou à la revue de code, peuvent être sélectionnés selon votre flux réel. (skills.sh)

Le projet distingue clairement deux philosophies : le plugin Claude Code installe un ensemble géré et en lecture seule, tandis que skills.sh copie des fichiers éditables dans le projet. Le README recommande de choisir une seule voie, car l’installation des deux peut produire chaque Skill en double. (github.com)

Le plugin Claude Code et skills.sh peuvent-ils être installés ensemble ?
Pour le même ensemble mattpocock/skills, évitez cette combinaison. Choisissez le plugin si vous voulez recevoir un bundle géré sans le modifier. Choisissez skills.sh si vous voulez adapter les fichiers, les versionner et contrôler le moment des mises à jour. Un membre qui utilise Claude Code doit donc documenter son choix au lieu d’ajouter silencieusement une seconde copie.

Après l’installation, ne passez pas directement au premier ticket. Inspectez d’abord ce qui a été écrit :

git status --short
find . -type f \( -name "SKILL.md" -o -name "*.sh" \) | sort
git diff --stat

Vous devez pouvoir répondre à quatre questions :

1. Les fichiers sont-ils dans le dépôt attendu ?
2. setup-matt-pocock-skills est-il présent ?
3. Les Skills sélectionnés correspondent-ils à votre processus réel ?
4. Des scripts ou références externes ont-ils été ajoutés sans revue ?

Si le diff est vide alors que l’installeur a annoncé une installation, arrêtez-vous. Vous êtes peut-être dans un mauvais répertoire, dans un dossier ignoré par Git ou dans un emplacement utilisateur.

Configuration du dépôt : lancer setup avant de demander du code

Ouvrez ensuite le dépôt dans Cursor, passez en mode Agent et appelez explicitement :

/setup-matt-pocock-skills

Le programme demande notamment quel système de suivi utiliser, quels libellés servent au triage et où enregistrer les documents produits. Ces réponses ne sont pas de simples préférences de conversation. Elles déterminent la manière dont les Skills de triage, de recherche ou de documentation vont interagir avec votre dépôt.

Consignez les décisions dans un fichier d’équipe, par exemple :

docs/agent-workflow.md

Notez-y :

• le système de suivi retenu ;
• les libellés autorisés pour le triage ;
• le répertoire où placer les documents générés ;
• les Skills approuvés pour les tâches de développement ;
• les commandes qui nécessitent une validation humaine ;
• la personne responsable de la revue des mises à jour.

La commande slash et la découverte automatique ne sont pas équivalentes. L’appel /setup-matt-pocock-skills force l’exécution d’un Skill précis. En revanche, lors d’une demande normale, Cursor peut présenter les Skills disponibles à l’Agent, puis celui-ci décide si la description du Skill correspond au contexte. Cursor explique que les Skills servent à fournir des connaissances ou procédures spécialisées lorsque la tâche le justifie, alors que les Rules injectent des consignes persistantes dans le contexte de l’Agent. (cursor.com)

Les champs de métadonnées doivent donc être traités comme une interface de déclenchement. Une description trop vague provoque des appels imprévisibles. Une restriction comme disable-model-invocation modifie le mode de déclenchement : le Skill peut alors exiger un appel manuel au lieu d’être proposé automatiquement. Avant de modifier ces champs, relisez la syntaxe actuellement documentée et le SKILL.md concerné.

Dans Cursor, vérifiez la présence du Skill dans la liste des Skills ou dans l’interface où l’Agent peut décider d’utiliser une capacité. Fermez puis rouvrez le projet si la liste reste ancienne. Le guide d’aide de MacHTML peut compléter cette étape si vous devez documenter une procédure d’exploitation reproductible pour votre équipe.

Skills contre Cursor Rules : séparer le déclenchement de la contrainte

La confusion entre Skills et Cursor Rules est la cause la plus fréquente d’une configuration qui semble fonctionner en démonstration, puis devient incohérente au quotidien.

Comment répartir Skills et Rules dans Cursor ?
Placez dans un Skill les étapes dynamiques : poser des questions, rechercher des fichiers, exécuter une séquence de tests, diagnostiquer une panne ou préparer une revue. Placez dans une Cursor Rule les décisions qui doivent rester vraies dans chaque tâche : conventions de nommage, architecture, règles de sécurité, format des commits ou interdiction d’écrire dans certains répertoires.

Une règle « toujours utiliser l’architecture hexagonale » appartient à .cursor/rules. Une procédure « analyser une régression, reproduire le défaut, écrire un test puis proposer un correctif » appartient à un Skill de diagnostic. Si vous mettez toute la procédure dans une Rule toujours active, elle consomme du contexte même lorsque vous travaillez sur une maquette audio, une interface vidéo ou un composant de design sans rapport.

La documentation de Cursor recommande des Rules ciblées, actionnables et organisées par portée. Les Project Rules se trouvent dans .cursor/rules, sont versionnables et peuvent être attachées selon les chemins ou la pertinence. (docs.cursor.com)

L’arborescence cible peut ressembler à ceci :

mon-projet/
├── .cursor/
│   ├── rules/
│   │   ├── architecture.mdc
│   │   └── securite.mdc
│   └── skills/
│       ├── tdd/
│       │   └── SKILL.md
│       ├── diagnosing-bugs/
│       │   └── SKILL.md
│       └── setup-mattpocock-skills/
│           └── SKILL.md
├── docs/
│   └── agent-workflow.md
└── package.json

Faut-il choisir .cursor/skills ou un répertoire global ?
Choisissez .cursor/skills pour les Skills qui modifient le travail d’équipe ou produisent des fichiers attendus dans le dépôt. Réservez le répertoire utilisateur à vos préférences personnelles, à vos expériences et aux Skills que vous ne souhaitez pas imposer aux collaborateurs. Dans un monorepo, vérifiez aussi le comportement des répertoires imbriqués avant de décider d’une convention globale.

Premier ticket : vérifier le contexte au lieu d’activer toute la bibliothèque

Ne testez pas 49 Skills en une seule session, même si la page de mattpocock/skills en affiche actuellement ce volume et des compteurs d’installations évolutifs. Ces compteurs changent et ne constituent pas une preuve de compatibilité avec votre dépôt. (skills.sh)

Choisissez un ticket limité, avec un résultat mesurable. Pour un produit audio ou vidéo, prenez par exemple une correction de synchronisation, un export de métadonnées ou un composant d’interface de montage. Pour un projet applicatif, choisissez une fonction avec un test reproductible.

Procédez ainsi :

1. Demandez une clarification de la tâche. Vérifiez que l’Agent comprend le résultat attendu et les contraintes du dépôt.
2. Appelez le Skill de TDD ou de spécification. Il doit produire un plan ou un test avant de modifier plusieurs fichiers.
3. Lancez le test ou le scénario de reproduction. Le résultat initial doit être enregistré dans la conversation ou dans le ticket.
4. Utilisez le Skill de diagnostic uniquement si le défaut est confirmé. Ne déclenchez pas une procédure de triage sur un simple changement d’interface.
5. Demandez une revue ciblée. Contrôlez les fichiers modifiés, les commandes exécutées et les références citées.
6. Comparez le résultat avec les Rules. Une procédure correctement exécutée ne doit pas contourner une contrainte d’architecture ou de sécurité.
7. Conservez le diff et le verdict. Le prochain membre de l’équipe doit pouvoir comprendre ce qui a été validé.

Utilisez les noms présents dans votre copie actuelle. Si un Skill a été renommé ou supprimé en amont, ne recopiez pas son ancien nom depuis un article, une capture d’écran ou une ancienne branche.

Les trois limites à surveiller sont concrètes :

• Découverte : le Skill n’est pas proposé si son dossier, son SKILL.md ou ses métadonnées sont incorrects.
• Portée : une copie utilisateur peut masquer l’absence de la copie projet.
• Permissions : Cursor peut demander une approbation avant d’exécuter une commande ou d’écrire un fichier. Les règles de permission du CLI peuvent être globales ou propres au projet. (docs.cursor.com)

Première semaine : traiter les Skills comme du code tiers

Après le premier ticket, mettez en place une gouvernance minimale. Un Skill peut contenir des instructions, des scripts et des fichiers de référence. Son nombre d’installations ne remplace pas une revue de sécurité.

Répartissez les responsabilités :

• le développeur qui propose un nouveau Skill explique son usage et sa portée ;
• un responsable technique examine les scripts, commandes shell et chemins d’écriture ;
• la revue Git vérifie que les fichiers ajoutés correspondent au dépôt ;
• la personne chargée de la maintenance suit les changements amont ;
• l’équipe décide si une mise à jour est adoptée, adaptée ou refusée.

Avant toute mise à jour, créez une branche de test et sauvegardez les personnalisations locales :

git switch -c chore/update-agent-skills
git diff -- .cursor/skills
npx skills update
git diff -- .cursor/skills

N’exécutez pas cette séquence sur la branche principale sans examiner le diff. Comparez les changements de procédure, les nouvelles commandes, les références externes et les modifications de métadonnées. Lancez ensuite le petit ticket de validation utilisé lors de l’installation initiale.

Si votre équipe a adapté un Skill, choisissez entre trois options :

• conserver le fichier local et documenter l’écart ;
• reprendre manuellement les changements amont ;
• revenir à la version amont si la personnalisation n’est plus nécessaire.

La mise à jour ne doit jamais écraser silencieusement une procédure approuvée. Les fichiers installés par skills.sh restent sous votre contrôle et peuvent être mis à jour quand vous le décidez.

Validation locale et environnement Mac distant

Cette section doit être remplie avec vos propres résultats. Ne déduisez pas le comportement d’un Mac distant à partir d’une documentation générale : une image système, une politique de permissions, une version de Node.js ou une installation Cursor différente peut modifier le résultat.

Utilisez cette grille sur le Mac local, puis dans l’environnement distant qui doit reproduire le dépôt :

• [ ] Le dépôt est cloné dans un répertoire propre.
• [ ] git rev-parse --show-toplevel renvoie le chemin attendu.
• [ ] npx skills@latest add mattpocock/skills écrit les fichiers dans le même périmètre.
• [ ] setup-matt-pocock-skills est visible et peut être appelé.
• [ ] Le programme d’initialisation conserve les mêmes choix de suivi, de libellés et de documentation.
• [ ] Cursor découvre les mêmes Skills après ouverture du projet.
• [ ] Un redémarrage ou un rechargement nécessaire est noté dans la procédure.
• [ ] Le ticket de TDD, de diagnostic ou de revue produit le même type de résultat.
• [ ] Les permissions demandées sont acceptables pour l’équipe.
• [ ] Les erreurs et journaux sont conservés dans le rapport d’acceptation.

Pour préparer cette comparaison, vous pouvez consulter la console MacHTML afin d’identifier le mode d’accès et les étapes d’initialisation réellement disponibles dans votre environnement. Ne remplacez pas vos journaux de validation par une hypothèse sur le comportement d’un poste distant.

Pourquoi une installation manuelle reste préférable à une configuration dispersée

Une configuration dispersée entre le profil utilisateur, plusieurs dépôts et des installations automatiques crée trois coûts cachés.

Premièrement, le diagnostic devient lent : deux développeurs peuvent appeler le même Skill avec des versions différentes. Deuxièmement, la revue de sécurité perd sa portée : un fichier exécuté localement peut ne jamais apparaître dans le dépôt. Troisièmement, la reproduction à distance devient incertaine : le code est identique, mais l’environnement Agent ne l’est pas.

L’installation projet réduit ces écarts, sans les supprimer. Vous devez encore contrôler les permissions, les chemins, les scripts et les versions. Elle n’est donc pas une promesse de compatibilité universelle ; c’est un point de contrôle Git qui rend les différences visibles.

Pour une équipe qui travaille en audio, en vidéo ou en design, cette discipline est particulièrement utile. Les tâches combinent souvent des fichiers volumineux, des outils spécialisés et des étapes de validation non triviales. Un Skill de revue ne doit pas déclencher automatiquement une conversion média ou une commande destructive. Une Rule peut imposer la conservation des fichiers sources, tandis qu’un Skill peut guider une procédure d’export uniquement lorsqu’elle est demandée.

Le choix d’environnement après la validation

Une fois la configuration validée sur votre poste, comparez votre environnement actuel avec un espace Mac reproductible. Votre poste local peut dépendre de paquets installés manuellement, de permissions historiques et d’un profil Cursor impossible à reconstruire rapidement. Une machine distante mal documentée ajoute les mêmes problèmes : initialisation variable, accès aux fichiers et état du dépôt difficiles à auditer.

Si vous devez seulement tester mattpocock/skills sur un dépôt, votre Mac actuel reste souvent le choix le plus simple. En revanche, pour une équipe distribuée qui doit fournir un espace Cursor identique, revenir à une installation manuelle sur chaque poste entraîne des divergences, des oublis de permissions et des retours arrière plus difficiles. Dans ce cas, louer un environnement Mac auprès de MacHTML peut être plus cohérent qu’entretenir plusieurs configurations personnelles, à condition de valider d’abord les étapes et les limites décrites dans ce guide.

Commencez par la documentation d’aide MacHTML, puis utilisez la console seulement après avoir défini votre arborescence, vos contrôles Git et votre procédure de retour arrière. L’objectif n’est pas de déplacer un problème local vers une machine distante : c’est de disposer d’un espace de développement Cursor que votre équipe peut initialiser, vérifier et révoquer selon les mêmes critères.