Le Skill ultime utilisé par les développeurs des géants de la tech : tutoriel mattpocock/skills, avec 300 000 étoiles — 5 étapes pour démarrer : clarifiez d’abord vos besoins avec /grill-me, puis codez avec /tdd

Note de l’auteur : cet article vous guide pas à pas, même si vous partez de zéro, dans la prise en main de deux compétences clés de mattpocock/skills. Commencez par utiliser /grill-me pour clarifier les besoins, puis /tdd pour écrire le code. Chaque étape est accompagnée de critères de validation.

En bref : commencez par /grill-me pour que l’Agent clarifie les besoins, puis utilisez /tdd pour écrire le code en procédant test par test.

Au 22 octobre 2026, heure de Pékin, mattpocock/skills compte environ 300 000 étoiles sur GitHub. Le projet est sous licence MIT et sa dernière version est la v1.3.1. Le nombre d’étoiles indique seulement que le projet suscite beaucoup d’intérêt, pas qu’il sera forcément adapté à votre projet. Cet article se concentre donc sur l’installation, l’utilisation et les moyens de vérifier que tout fonctionne correctement, sans exagérer les résultats.

Un guide pratique que vous pouvez suivre étape par étape, en cliquant et en saisissant les commandes indiquées. Nous partirons d’un petit besoin — ajouter la validation d’un coupon au parcours de commande — et irons de l’installation jusqu’au premier test réussi.

Objectif : installer les compétences, effectuer un premier cycle de clarification des besoins avec /grill-me, puis écrire le premier test « rouge → vert » avec /tdd
Durée : l’installation ne prend que quelques minutes (l’auteur affirme qu’elle se fait en « 30 secondes »). Le temps nécessaire pour répondre aux questions et écrire le test dépend surtout de votre rapidité ; selon notre estimation éditoriale, comptez environ 30 minutes à 1 heure au total
Prérequis : utiliser déjà un Agent de programmation (Claude Code, Codex, GitHub Copilot, Gemini CLI ou Cursor, par exemple) et disposer d’un dépôt de code où vous pouvez faire des essais librement
Niveau : débutant. Le guide repose principalement sur une interface graphique et des boîtes de dialogue ; les commandes de terminal sont proposées en option

Points clés de mattpocock/skills : à quoi servent grill-me et tdd ?

mattpocock/skills est un ensemble de compétences pour agents, publié par Matt Pocock. Le dépôt se décrit comme « Skills for Real Engineers ». Dans le README, l’auteur précise que ces compétences sont légères, combinables, compatibles avec n’importe quel modèle et « fondées sur des décennies d’expérience en ingénierie ».

Point clé	Description	Intérêt
/grill-me	Pose des questions tour après tour, avec une réponse recommandée pour chacune. N’écrit aucun fichier et ne se déclenche que lorsque vous le lancez manuellement.	Aligner vos attentes avec celles de l’agent avant de commencer et faire ressortir les décisions que vous n’aviez pas envisagées.
/tdd	Commence par définir les limites des tests (seams) et attend votre validation, puis suit le cycle « rouge → vert », un test à la fois.	Obtenir un retour à chaque étape et des tests qui résistent au refactoring.
/setup-matt-pocock-skills	À exécuter une fois par dépôt pour configurer l’outil de suivi des tickets, les étiquettes de triage et l’emplacement de la documentation.	Indiquer aux compétences d’ingénierie où enregistrer les informations.
Installation	Choisissez entre le plugin (mises à jour automatiques) et skills.sh (fichiers modifiables).	Installer les deux ferait apparaître chaque compétence en double.

Pourquoi utiliser grill-me et tdd ensemble ?

Le README recense plusieurs modes d’échec courants, dont deux correspondent précisément à ces compétences. Le premier : « L’agent n’a pas fait ce que je voulais. » Le problème vient d’un décalage de communication entre vous et l’agent. La solution consiste à lancer une session de questions approfondies (grilling), pendant laquelle l’agent vous demande en détail ce que vous voulez faire. En réalité, /grill-me se résume à une seule instruction : appeler la compétence de grilling. Les règles détaillées pour poser les questions se trouvent dans cette dernière.

L’autre problème : « Le code ne fonctionne pas. » Même si les besoins sont bien définis, un agent qui ne peut pas observer le résultat réel de l’exécution du code avance à l’aveugle. Avec /tdd, l’agent écrit d’abord un test qui échoue, puis juste assez de code pour le faire réussir. Il dispose ainsi d’un retour fiable à chaque étape. Utilisées ensemble, ces deux compétences répondent à deux questions différentes : la première clarifie « quoi faire », la seconde vérifie « si c’est bien fait ».

Installer mattpocock/skills et utiliser grill-me et tdd : démarrer en 5 étapes

Étape 1 : installer mattpocock/skills (de préférence via l’interface graphique)

La documentation officielle explique comment installer le paquet dans Claude Code, Codex, GitHub Copilot et Gemini CLI. Pour les autres agents, utilisez skills.sh. Le README précise que ces compétences fonctionnent avec n’importe quel modèle. La documentation mentionne aussi Auggie, Droid et Goose, qui n’ont pas encore été testés en pratique. Pour l’instant, il est conseillé de passer par skills.sh.

Agent utilisé	Méthode d’installation recommandée	Mises à jour automatiques
GitHub Copilot (VS Code)	Ouvrez la palette de commandes, lancez Chat: Install Plugin From Source, puis saisissez `https://github.com/mattpocock/skills`	Oui, chaque jour
Claude Code	Installez `mattpocock-skills` depuis la marketplace officielle de plugins `claude-plugins-official`	Oui, activées par défaut
Codex	Ajoutez d’abord la marketplace de plugins `mattpocock/skills`, puis installez le plugin	Oui, au démarrage
Copilot CLI	Installez-le depuis la marketplace de plugins `mattpocock`	Oui, après avoir activé une fois `autoUpdate: true`
Gemini CLI	Installez séparément les répertoires engineering et productivity	Non, il faut relancer les commandes
Cursor, OpenCode, Windsurf, Devin, Amp, Pi, etc.	skills.sh	Non, mise à jour manuelle

Pour les utilisateurs de VS Code, c’est la méthode la plus simple. Appuyez sur Ctrl+Shift+P (Cmd+Shift+P sur macOS) pour ouvrir la palette de commandes, saisissez Chat: Install Plugin From Source, puis appuyez sur Entrée et collez l’adresse du dépôt. Si vous préférez le terminal, voici les commandes d’installation indiquées par la documentation officielle :

Claude Code : exécutez claude plugin install mattpocock-skills@claude-plugins-official. Les mises à jour automatiques sont activées par défaut.
Codex : exécutez d’abord codex plugin marketplace add mattpocock/skills, puis codex plugin add mattpocock-skills@mattpocock. Les mises à jour se font automatiquement à chaque démarrage.
GitHub Copilot CLI : exécutez d’abord copilot plugin marketplace add mattpocock/skills, puis copilot plugin install mattpocock-skills@mattpocock.
Gemini CLI : exécutez séparément gemini skills install https://github.com/mattpocock/skills.git --path skills/engineering et gemini skills install https://github.com/mattpocock/skills.git --path skills/productivity. Les mises à jour ne sont pas automatiques : pour mettre les compétences à jour, relancez ces deux commandes.
Autres agents (skills.sh) : exécutez npx skills@latest add mattpocock/skills -a cursor, en remplaçant cursor par l’agent que vous utilisez, par exemple opencode, devin, windsurf, amp ou pi. Sans -a, vous pourrez choisir vous-même. Pour mettre à jour, exécutez npx skills@latest update. Si de nouvelles compétences sont disponibles, relancez également add.
Installer une seule compétence : exécutez npx skills@latest add mattpocock/skills --skill=<name>, en remplaçant <name> par le nom de la compétence.

Pour Copilot CLI, vous devez aussi modifier une seule fois ~/.copilot/settings.json et y ajouter cette configuration : {"extraKnownMarketplaces": {"mattpocock": {"source": {"source": "github", "repo": "mattpocock/skills"}, "autoUpdate": true}}}. Elle enregistre la marketplace de plugins mattpocock comme provenant du dépôt GitHub mattpocock/skills et active les mises à jour automatiques. La documentation officielle précise que cette configuration respecte le format indiqué, mais personne ne l’a encore testée en pratique.

Vous devez choisir entre le plugin et skills.sh. Le plugin est un paquet en lecture seule qui se met à jour automatiquement, tandis que skills.sh copie des fichiers modifiables dans votre projet. Installer les deux entraînerait donc la présence de deux copies de chaque compétence. Avec skills.sh, lorsque l’installateur vous demande quelles compétences installer, pensez à sélectionner setup-matt-pocock-skills.

Si vous voulez installer un seul skill, vous devez en installer deux dépendances en même temps. grill-me ne fait qu’appeler grilling, qui doit donc être installé lui aussi. tdd dépend de codebase-design et utilise son vocabulaire de conception d’interfaces pour parler des points de découplage.

La configuration est réussie si : en saisissant / dans la boîte de dialogue de l’Agent, vous voyez grill-me, tdd et setup-matt-pocock-skills dans la liste des suggestions, chacun une seule fois.

Étape 2 : lancez /setup-matt-pocock-skills dans la boîte de dialogue

La première fois que vous utilisez ces skills dans un dépôt, saisissez /setup-matt-pocock-skills dans la boîte de dialogue de l’Agent. Il vous posera trois questions, l’une après l’autre : quel outil de suivi des tickets utiliser (GitHub, GitLab, des fichiers locaux ou une autre solution que vous préciserez), quels labels appliquer au triage des tickets et où enregistrer les documents générés.

Répondez simplement en fonction de votre situation. Si vous hésitez, choisissez les fichiers locaux : vous pourrez toujours modifier ce choix plus tard. À la lettre, /grill-me ne dépend pas du dépôt, vous pouvez donc ignorer cette étape. En revanche, pour les skills d’ingénierie comme /tdd, il est recommandé de terminer la configuration. Vous n’avez à le faire qu’une fois par dépôt.

La configuration est réussie si : l’Agent vous a posé les trois questions, vous confirme que la configuration est terminée et vous savez où les prochains documents seront enregistrés.

Étape 3 : choisir les bons modèles pour grill-me et tdd

La documentation officielle souligne que la phase de questions dépend davantage du modèle que la plupart des compétences. Le grilling s’appuie sur les connaissances du modèle concernant les façons dont un système peut échouer. Il vaut donc mieux utiliser le modèle le plus performant à votre disposition. Pour écrire l’implémentation, il suffit surtout de suivre le contexte : un modèle moins coûteux peut très bien faire l’affaire.

Phase	Ce qu’on attend du modèle	Recommandation
Questions avec /grill-me	S’appuie sur les connaissances du modèle en ingénierie ; plus il est performant, plus ses questions sont pertinentes	Utilisez le modèle le plus puissant à votre disposition, par exemple Claude Opus 5.5
Implémentation avec /tdd	Suit principalement le contexte déjà établi	Vous pouvez passer à un modèle moins coûteux
Configuration	Changez de modèle selon la phase dans Claude Code ou Codex	Utilisez une seule clé API d’APIYI, sur apiyi.com, pour accéder à plusieurs modèles

Pour configurer une interface commune dans Claude Code ou Codex, procédez comme suit :

Claude Code : définissez d’abord deux variables d’environnement : ANTHROPIC_BASE_URL sur https://api.apiyi.com (l’interface unifiée d’APIYI) et ANTHROPIC_AUTH_TOKEN sur votre clé API. Lancez ensuite claude et utilisez /model dans la fenêtre de dialogue pour changer de modèle.
Codex : ouvrez ~/.codex/config.toml et ajoutez les deux lignes model = "<模型ID>" et model_provider = "apiyi". Ajoutez ensuite une section [model_providers.apiyi], puis les trois lignes name = "APIYI", base_url = "https://api.apiyi.com/v1" et env_key = "APIYI_API_KEY". L’identifiant du modèle doit correspondre à celui affiché dans la console.

Le nom des champs peut varier selon la version de l’outil. Consultez la documentation officielle de l’outil et docs.apiyi.com pour connaître les valeurs à utiliser.

🎯 Conseil pour choisir un modèle : pour la phase de questions, mieux vaut choisir le modèle le plus performant. Vous pourrez utiliser un modèle moins coûteux pour l’implémentation. Avec une seule clé API d’APIYI, sur apiyi.com, vous pouvez passer facilement d’un modèle à l’autre dans Claude Code ou Codex. À noter : APIYI s’occupe uniquement de l’invocation du modèle et ne remplace pas les compétences grill-me, tdd, etc.

Vous avez réussi si : vous pouvez vérifier le modèle actif dans la fenêtre de dialogue (dans Claude Code, utilisez /model) et confirmer que la phase de questions utilise bien le modèle performant que vous avez choisi.

Étape 4 : clarifier les besoins de validation des coupons avec /grill-me

Ouvrez une nouvelle conversation. Ne reprenez pas celle dans laquelle l’Agent a déjà rédigé un plan, et désactivez le mode planification. Ce mode incite l’Agent à produire rapidement un plan, alors qu’ici, vous avez besoin qu’il pose des questions sans s’arrêter. Dans la zone de dialogue, saisissez /grill-me Je veux ajouter une validation des coupons au processus de commande, puis appuyez sur Entrée.

L’Agent ne lance pas grill-me automatiquement : il ne se déclenche que lorsque vous le saisissez. Il décompose les besoins sous la forme d’un « arbre de conception » et, à chaque tour, pose en une seule fois toutes les questions dont les prérequis sont déjà définis. Chaque question est numérotée et accompagnée d’une réponse recommandée, formulée de manière à ce qu’un simple « oui » signifie que vous acceptez la recommandation. Un échange ressemble à peu près à ceci (exemple) :

❓ Q1 – À quel moment vérifier l’expiration ? Au moment de la commande ou après le paiement ?
➡️ Recommandation : au moment de la commande, pour éviter qu’un coupon expire pendant le paiement.

❓ Q2 – Le seuil de réduction doit-il inclure les frais de livraison ?
➡️ Recommandation : non, seuls les sous-totaux des articles sont pris en compte.

❓ Q3 – Combien de coupons peut-on utiliser au maximum par commande ?
➡️ Recommandation : un seul.

L’erreur la plus courante consiste à répondre « d’accord » à tout. Vous ne faites alors que valider le plan de l’Agent, sans prendre vous-même la moindre décision. Il vaut mieux répondre en faisant des choix, par exemple :

Q1 oui. Q2 non : notre règle promotionnelle inclut les frais de livraison. Q3 je ne sais pas, il faut demander à l’équipe marketing. Pour l’instant, partons sur un coupon.

Les questions du tour suivant s’appuieront sur vos réponses. Par exemple : « Si les frais de livraison sont inclus, les coupons de livraison et les coupons de réduction à partir d’un certain montant peuvent-ils être cumulés ? » Si une question nécessite de vérifier un fait dans le dépôt de code, l’Agent devrait envoyer un sous-agent s’en charger au lieu de vous la poser. La documentation officielle précise qu’il est normal de répondre à plus de quarante questions au total sur quatre tours.

Vous avez réussi si :
– Les questions arrivent par tours, et chacune est numérotée et accompagnée d’une réponse recommandée que vous pouvez accepter en répondant « oui ».
– Les questions des tours suivants s’appuient clairement sur vos réponses précédentes.
– Vous avez au moins une fois contesté une proposition ou répondu sérieusement « je ne sais pas ».
– À la fin, l’Agent vous demande d’abord de confirmer que vous êtes parvenus à un accord. Avant cette confirmation, il ne passe pas à l’action et n’écrit aucun fichier.

Étape 5 : écrire le code avec /tdd, un test à la fois

Continuez dans la même session pour conserver tout le contexte établi. Si nécessaire, passez à un modèle moins coûteux, puis saisissez /tdd Implémente la validation des coupons selon les règles que nous venons de confirmer.

L’agent ne va pas écrire les tests tout de suite. Il va d’abord présenter les limites d’interface (seams) qu’il propose de tester, puis attendre votre confirmation. Par exemple, la proposition A est la fonction pure validateCoupon(coupon, order, now). Elle permet de couvrir la logique des règles, mais pas son intégration au processus de commande. La proposition B est la méthode checkout() du service de commande. Elle permet de tester cette intégration, mais elle est plus lente. Si l’agent se contente de donner des noms, demandez-lui ce que chaque seam permet de détecter et ce qu’il risque de manquer. Ici, nous confirmons la proposition A.

Voici un exemple de premier test avec TypeScript et Vitest. C’est simplement une illustration : cette compétence n’est limitée ni à un langage ni à un framework de test.

Fichier de test : coupon.test.ts, qui importe it et expect depuis vitest, ainsi que validateCoupon depuis ./coupon
Nom du test : l’utilisateur ne peut pas utiliser un coupon expiré
Coupon fourni : { code: "SAVE10", minSubtotal: 100, expiresAt: new Date("2026-10-01") }, c’est-à-dire un coupon utilisable pour un minimum de 100 yuans et qui expire le 1er octobre
Commande fournie : { subtotal: 120 }, avec un sous-total de 120 yuans
Date et heure actuelles fournies : new Date("2026-10-22"). La date et l’heure sont passées en argument plutôt que lues dans la fonction, afin que le résultat soit identique quel que soit le jour où le test est exécuté.
Résultat attendu : expect(result).toEqual({ ok: false, reason: "expired" }), autrement dit, la validation échoue parce que le coupon a expiré

Lancez d’abord le test : il échouera parce que validateCoupon n’existe pas encore. L’agent écrira ensuite le minimum de code nécessaire pour le faire passer, par exemple en renvoyant le statut « expiré » si now >= coupon.expiresAt. Une fois le test au vert, il passera au suivant, par exemple : « rejeter la commande lorsque le sous-total est inférieur au seuil ». Notez que la valeur attendue est un littéral déduit de la règle, et que le nom du test décrit une fonctionnalité accessible à l’utilisateur, pas « l’appel d’une fonction interne ».

La version actuelle de tdd suit uniquement le cycle « rouge → vert », sans étape de refactorisation. Cette étape a été supprimée en juin 2026, car l’agent l’exécutait presque jamais ; la refactorisation est désormais confiée à /code-review. La description de la compétence mentionne toujours red-green-refactor : c’est un problème connu, mais cette formulation permet encore de déclencher la compétence. Utilisez des mocks uniquement aux frontières du système, par exemple pour les API externes, le temps ou les nombres aléatoires. Ne mockez pas vos propres modules.

Le résultat est satisfaisant si :
– Avant d’écrire le moindre fichier de test, l’agent présente les seams et attend votre confirmation.
– Un seul test apparaît à la fois : il échoue, puis passe au vert, et seulement ensuite le test suivant est écrit. Il n’y a pas de série de tests écrite d’un coup, suivie d’une série de modifications du code.
– Renommer une fonction interne ne fait pas échouer les tests.

Quand utiliser les compétences grill-me, tdd, etc. et liste de dépannage

On bloque souvent non pas parce qu’on ne sait pas s’en servir, mais parce qu’on les utilise dans le mauvais contexte. Gardez ce tableau sous la main pour choisir la bonne compétence selon la situation.

Votre situation	Compétence à utiliser	Explication
Votre idée est encore floue et n’a pas forcément de lien avec le code	/grill-me	Aucun dépôt ni fichier nécessaire. Convient aussi aux décisions commerciales et à la rédaction.
Vous modifiez du code dans un dépôt et souhaitez consigner la terminologie et les décisions	/grill-with-docs	Même processus de questions, avec mise à jour de `GLOSSARY.md` et des ADR.
Le travail est trop important pour tenir dans une seule session	/wayfinder	Crée une carte de tickets de décision dans l’outil de suivi des tickets pour les traiter un à un.
Vous devez implémenter un comportement avec des entrées et des sorties clairement définies	/tdd	Convient à la logique métier, aux contrats requête-réponse, aux conversions de données et aux validations.
Vous avez déjà une spécification ou un ticket et souhaitez qu’il soit traité de bout en bout	/implement	Pilote `/tdd` sur les points d’intégration convenus et lance `/code-review` avant la soumission.

Si vous ne savez pas laquelle choisir, saisissez /ask-matt : cette compétence vous recommandera celle qui correspond à votre situation. La plupart des problèmes rencontrés en pratique trouvent leur solution dans le tableau ci-dessous.

Problème constaté	Cause fréquente	Solution
Il y a trop de questions, parfois plus d’une centaine	Le périmètre est trop vaste ou le contexte trop chargé, ce qui dégrade la qualité des questions	Demandez d’abord à l’Agent de découper le travail en tâches plus petites, puis examinez chacune séparément avec grill
La session se termine très vite et vous n’avez fait que répondre « d’accord »	Vos réponses sont trop passives	Contredisez activement, signalez les dérives de périmètre et dites franchement « je ne sais pas »
Vous ne trouvez pas la réponse à une question, même après l’avoir reformulée plusieurs fois	C’est le genre de problème qui ne se résout pas en discutant, par exemple le ressenti d’une interaction	Arrêtez les questions et utilisez `/prototype` pour créer un prototype ponctuel
Vous n’arrivez pas à choisir les limites des tests	Les points d’intégration proposés ne sont que des noms	Demandez d’abord ce que chaque point d’intégration permet de détecter, ce qu’il ne couvre pas et combien de temps il prend
L’implémentation a été écrite avant les tests	C’est le comportement par défaut du modèle	Surveillez l’exécution des tranches essentielles et, si cela se produit, demandez à l’Agent de revenir à l’étape « rouge »
Les tests navigateur tournent en boucle	Les tests de bout en bout ont été écrits avant que la fonctionnalité existe	Indiquez dans `CLAUDE.md` d’attendre que le comportement fonctionne avant d’écrire les tests navigateur
Les tests ne font que recopier l’implémentation	Les configurations et le code de liaison n’ont pas de résultat de référence indépendant	N’utilisez pas tdd pour ce type de modification ; vous pouvez consigner la règle dans `CLAUDE.md`
Chaque compétence apparaît en double	Elle a été installée à la fois via le plug-in et via skills.sh	Désinstallez l’une des deux versions

FAQ : mattpocock/skills

Q1 : Environ 300 000 étoiles, est-ce que ça garantit de bons résultats ?

Non. Le nombre d’étoiles reflète l’intérêt suscité, pas les résultats concrets dans votre projet. L’auteur s’appuie, selon ses propres dires, sur plusieurs décennies d’expérience en ingénierie, mais aucune évaluation indépendante ne fournit de données sur les gains d’efficacité. Le plus fiable est de suivre les critères d’acceptation de chaque étape décrite dans cet article et de les tester dans votre propre dépôt.

Q2 : Ces outils ne fonctionnent-ils qu’avec Claude Code, Codex et les autres ?

Non. La liste officielle présente uniquement les méthodes d’installation vérifiées. Pour les agents qui n’y figurent pas, vous pouvez passer par skills.sh, en utilisant `-a` pour préciser votre choix ou en le sélectionnant dans le menu interactif. Le README précise également que ces compétences sont compatibles avec n’importe quel modèle : ce sont, au fond, des instructions rédigées en Markdown.

Q3 : Après les questions de grill-me, faut-il ouvrir une nouvelle session pour écrire le code ?

Non. Le contexte établi pendant les questions est précisément ce qu’il y a de plus précieux. La recommandation officielle est de poursuivre dans la même session et de demander à /to-spec de générer les spécifications. Dans le petit exemple de cet article, on enchaîne directement avec /tdd, toujours dans la même session.

Q4 : Il y a trop de questions en une seule fois. Peut-on demander à l’outil d’en poser une seule à la fois ?

Oui. Il suffit d’ajouter `When grilling, ask one question at a time.` dans le fichier global `CLAUDE.md`. Cela dit, poser les questions par série vous permet de voir d’un coup toutes les décisions à prendre. Je vous conseille d’essayer ainsi quelques fois avant de modifier ce comportement.

Q5 : Pourquoi la description de tdd mentionne-t-elle red-green-refactor alors que l’outil ne refactorise pas en pratique ?

L’étape de refactorisation a été volontairement supprimée en juin 2026, mais la description n’a pas encore été mise à jour. C’est un problème connu, qui n’a pas encore été résolu. Le processus actuel suit le cycle « rouge → vert » ; la refactorisation est confiée à /code-review. Séparer l’écriture du code et sa revue dans deux sessions donne de meilleurs résultats.

Q6 : Comment utiliser des modèles différents pour les questions et pour l’implémentation ?

Vous pouvez configurer une interface unifiée dans Claude Code ou Codex en suivant la méthode présentée à l’étape 3 de cet article. Avec une seule clé API d’APIYI (apiyi.com), vous pouvez utiliser Claude Opus 5.5 pendant la phase de questions, puis passer à un modèle plus économique pour l’implémentation. Le service gère uniquement l’invocation du modèle ; l’installation des compétences ne change pas.

Q7 : Quels changements ne se prêtent pas à tdd ?

Les changements de configuration, de câblage, de code de liaison, d’annotations de types et les opérations CRUD qui ne font que transférer des données ne se prêtent pas bien à cette approche. Ils n’ont pas de résultat attendu indépendant auquel se comparer, et les tests risquent de simplement recopier l’implémentation. L’auteur reconnaît que la compétence ne vous aide pas encore à déterminer si le TDD est pertinent : c’est à vous d’en décider. En cas de doute, vous pouvez demander à un agent, avec un modèle léger sur APIYI (apiyi.com), de lister les entrées et les sorties observables du changement. S’il n’y arrive pas, n’utilisez pas tdd.

Points clés et résumé de mattpocock/skills

Points clés

Poser des questions avant d’écrire : commencez par clarifier les besoins avec /grill-me, puis implémentez avec /tdd en écrivant un seul test à la fois.
Choisir une seule méthode d’installation : installez soit le plugin, soit skills.sh. Sinon, chaque compétence sera présente en double.
Ne pas oublier les dépendances : en installation manuelle, associez grilling à grill-me et codebase-design à tdd.
Répondre de façon proactive : contestez les hypothèses et dites « je ne sais pas » quand c’est le cas. Acquiescer à tout est l’erreur la plus fréquente.
Définir les frontières des tests : tdd commence par lister les limites des tests et attend votre confirmation. Ensuite, le cycle rouge → vert démarre, sans refactorisation.
Choisir le modèle en fonction de la tâche : utilisez le modèle le plus puissant pour poser les questions, et un modèle moins coûteux pour l’implémentation. Avec APIYI, une seule clé API suffit pour changer de modèle.

Résumé

L’intérêt de mattpocock/skills ne tient pas à ses quelque 300 000 étoiles, mais au fait que cet outil transforme deux principes d’ingénierie simples — clarifier les besoins d’abord, puis valider progressivement — en compétences que l’on peut exécuter de manière répétée. Suivez les cinq étapes de cet article : installer, lancer le setup, choisir un modèle, clarifier les besoins avec /grill-me, puis écrire avec /tdd un premier test qui passe du rouge au vert. Vous pourrez alors juger si cette méthode convient à votre projet.

Si vous souhaitez utiliser des modèles différents pour la phase de questions et celle d’implémentation, vous pouvez passer par APIYI, sur apiyi.com, et changer de modèle dans Claude Code ou Codex avec une seule clé API. Il ne vous reste plus qu’à vous exercer sur des besoins réels et à répondre de façon proactive.

Références

GitHub – mattpocock/skills : page du dépôt, avec le README et tous les fichiers SKILL.md
Lien : github.com/mattpocock/skills
Détails : les méthodes d’installation, la liste des compétences et l’historique des mises à jour sont disponibles ici.
AI Hero – Documentation Skills : présentation officielle de compétences comme grill-me et tdd
Lien : aihero.dev/skills
Détails : comprend une liste de critères d’acceptation intitulée « It’s working if » et une FAQ.
skills.sh – mattpocock/skills : point d’entrée d’installation générique pour d’autres agents
Lien : skills.sh/mattpocock/skills
Détails : adapté à des outils comme Cursor, OpenCode et Windsurf ; les mises à jour doivent être effectuées manuellement.

Auteur : équipe technique d’APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site APIYI, apiyi.com. Pour plus d’informations sur l’intégration, consultez le centre de documentation à l’adresse docs.apiyi.com.