Skills de Matt Pocock : le mode d'emploi en français pour Claude Code

TL;DR :

• mattpocock/skills regroupe les skills que Matt Pocock utilise pour coder avec un agent : 25 dans le plugin, plus de 263 000 étoiles sur GitHub au 16 septembre 2026.
• L'installation tient en une commande (le plugin Claude Code ou npx skills), puis /setup-matt-pocock-skills une fois par projet. N'installe pas les deux versions.
• La boucle principale : /grill-with-docs pour te faire interroger, /to-spec et /to-tickets si le travail dépasse une session, puis /implement ticket par ticket, qui lance /tdd et /code-review.
• Ce qui dure, c'est un glossaire (CONTEXT.md) et quelques notes de décision (les ADR). La spec, elle, est jetable une fois le travail livré.
• Les limites : dans Claude Code, /code-review entre en conflit avec la commande intégrée. Et selon plusieurs utilisateurs, /implement saute souvent ses tests ; il ne ferme pas non plus les tickets.

---

Salut 👋

Tu as sûrement croisé le dépôt de Matt Pocock : des skills qui font travailler un agent de code avec méthode, en commençant par une série de questions avant la moindre ligne de code. Créé en février 2026, c'est aujourd'hui le 15e dépôt le plus étoilé de GitHub. Presque tout ce qui l'explique est en anglais, et une partie est déjà périmée, car plusieurs skills ont changé de nom cet été.

Claude Code écrit le code de mes applications, et j'ai déjà écrit sur les Skills : mon guide pour créer les tiens et ma sélection des meilleurs Skills Claude, où ce dépôt arrive en sixième position. Par contre, je n'ai pas encore testé ces skills-là sur un vrai projet : ce guide suit le dépôt et sa documentation, lus le 16 septembre 2026 (version 1.2.3 du plugin).

Chapitre 1, 1 min

Les skills de Matt Pocock en bref

Matt Pocock forme des développeurs, d'abord à TypeScript avec Total TypeScript, aujourd'hui à l'ingénierie IA avec AI Hero. Avant ça, il a fait partie de l'équipe de XState et travaillé chez Vercel.

Le 3 février 2026, il a publié mattpocock/skills, les skills qu'il utilise chaque jour pour coder avec des agents comme Claude Code ou Codex. Le dépôt est sous licence MIT, donc gratuit et modifiable. Le titre du README donne le ton : « Skills For Real Engineers », des skills pour de vrais ingénieurs, et le texte précise juste en dessous qu'ils ne sont pas faits pour le vibe coding.

Ce qu'il y a dedans

Un Skill, c'est un dossier avec un fichier SKILL.md qui apprend une méthode de travail à ton agent. Le plugin en contient 25 : 18 pour le code (la catégorie engineering) et 7 pour l'organisation du travail (productivity). Le dépôt en compte 12 de plus, hors plugin : 8 en bêta et 4 outils divers.

Ils se rangent en deux familles :

• ceux que tu lances toi-même en tapant /nom-du-skill. Ils pilotent une étape de travail, et Claude ne les déclenche jamais seul ;
• ceux que l'agent peut aussi lancer seul quand la tâche s'y prête. Ils portent les méthodes réutilisables, comme les tests ou la revue de code.

Un skill de la première famille peut en appeler un de la seconde, jamais un autre de la première. Tous sont écrits en anglais, et ils marchent avec Claude Code, Codex et les autres agents qui lisent le format ouvert des Agent Skills.

Le dépôt en chiffres

Relevés le 16 septembre 2026 :

• plus de 263 000 étoiles et 22 223 forks (copies du dépôt) ;
• le 15e dépôt le plus étoilé de GitHub, devant React et le noyau Linux ;
• environ 113 000 étoiles le 1er juin, 152 000 le 1er juillet, 200 000 le 3 août et 243 000 le 1er septembre, d'après l'archive quotidienne du classement Github-Ranking.

Ce n'est pas pour autant le dépôt de skills le plus étoilé : Superpowers, une autre méthode construite avec des skills, en compte plus de 287 000.

Deux dates aident à lire cette courbe. Le 23 mars 2026, Matt Pocock écrit que grill-me est devenu viral. Le 5 août 2026, le plugin arrive dans la marketplace officielle de Claude Code, d'où il s'installe en une commande.

Chapitre 2, 2 min

Installer les skills dans Claude Code

Il existe deux façons de les installer. Choisis-en une seule : si tu cumules les deux, chaque skill apparaît en double.

Le plugin Claude Code

C'est le plus simple si tu travailles dans Claude Code. Le plugin est dans la marketplace officielle, il n'y a rien à ajouter avant. Dans ton terminal :

claude plugins install mattpocock-skills

Ou depuis une session ouverte :

/plugin install mattpocock-skills

Tu reçois les 25 skills en lecture seule. Les mises à jour arrivent toutes seules, dès que la marketplace officielle passe à la nouvelle version, parfois avec un peu de retard sur le dépôt.

npx skills, pour Codex, Cursor ou pour modifier les fichiers

npx skills@latest add mattpocock/skills

Il te faut Node.js. L'installeur te laisse choisir les skills et les agents où les installer : Claude Code, Codex, Cursor et beaucoup d'autres. Coche bien setup-matt-pocock-skills, sinon les autres skills de code n'auront pas leur réglage. Si tu fais le tri, garde aussi les skills dont les autres dépendent : grill-me a besoin de grilling, et grill-with-docs a besoin de grilling et de domain-modeling. Sans eux, ces deux skills ne marchent pas.

Les fichiers arrivent dans ton projet (dans .claude/skills/ pour Claude Code), par défaut sous forme de liens vers une copie centrale, ou en vraie copie avec l'option --copy si les liens posent problème chez toi. Tu peux les modifier, et rien ne change sans toi : tu récupères les nouveautés avec npx skills update.

Le réglage à faire une fois par projet

Avant la première utilisation, lance dans ton dépôt :

/setup-matt-pocock-skills

L'agent regarde d'abord ce qui existe (le dépôt distant git, CLAUDE.md ou AGENTS.md, un éventuel CONTEXT.md, un dossier docs/adr/...). Puis il traite trois sujets, un à la fois, en proposant chaque fois la réponse qu'il recommande :

1. Le gestionnaire de tickets, là où les autres skills rangeront specs et tickets : GitHub (avec l'outil en ligne de commande gh), GitLab (avec glab), de simples fichiers Markdown dans un dossier .scratch/ de ton projet, ou un autre outil comme Jira ou Linear, que tu décris en un paragraphe.
2. Les labels de tri, seulement si le skill triage est installé, ce qui est le cas avec le plugin. Une seule question : garder les 5 labels par défaut (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix) ?
3. La doc du domaine : par défaut, un seul CONTEXT.md et un dossier docs/adr/ à la racine, sans question. Il ne propose une organisation par sous-projet que s'il détecte un monorepo (un dépôt qui regroupe plusieurs projets).

Il te montre un brouillon avant d'écrire, puis il crée docs/agents/issue-tracker.md, docs/agents/domain.md et, si triage est installé, docs/agents/triage-labels.md. Il ajoute enfin une section ## Agent skills à ton CLAUDE.md, ou à ton AGENTS.md s'il n'y a pas de CLAUDE.md. Si tu n'as ni l'un ni l'autre, il te demande lequel créer.

Deux précisions. Le setup ne crée pas les labels sur GitHub : il note seulement lesquels utiliser. Et domain.md sert à une chose : dire aux autres skills de lire CONTEXT.md et les ADR avant d'explorer le code.

Chapitre 3, 3 min

grill-me et grill-with-docs : se faire interroger avant de coder

Le grilling (de l'anglais « to grill », cuisiner quelqu'un de questions) est le cœur du dépôt. Le README part d'un constat : l'erreur la plus courante en développement, c'est le malentendu. Tu crois que l'agent a compris ce que tu veux, et tu découvres le contraire en voyant le résultat. La parade : lui faire poser des questions détaillées avant d'écrire du code. D'après le README, ce sont ses skills les plus populaires.

grill-with-docs ou grill-me

• /grill-with-docs dès que tu travailles dans un projet : les questions tiennent à jour, au fil de la session, un glossaire et des notes de décision.
• /grill-me hors projet, pour un plan, un design ou un texte : mêmes questions, mais rien n'est enregistré.

Dans un dépôt, ask-matt, le skill qui t'oriente vers le bon skill, juge grill-with-docs strictement meilleur : il pose les mêmes questions et garde une trace.

Pour les curieuxPourquoi grill-me tient en une ligne ?

Ouvre le fichier SKILL.md de grill-me : il contient une seule instruction, appeler le skill grilling. grill-with-docs, lui, appelle grilling puis domain-modeling. Le vrai moteur est donc grilling, un skill que l'agent peut lancer seul et que triage, wayfinder et improve-codebase-architecture réutilisent aussi. Pour changer la façon dont les questions sont posées, c'est grilling qu'il faut modifier.

Comment se passe l'interrogatoire

L'agent range les décisions selon celles dont elles dépendent, et les traite dans cet ordre. Il avance par tours :

• à chaque tour, il pose d'un coup toutes les questions qui ne dépendent d'aucune réponse en attente ;
• chaque question est numérotée, porte un titre et arrive avec la réponse qu'il recommande ;
• il attend tes réponses avant le tour suivant ;
• chercher les faits, c'est son travail : s'il doit savoir comment ton code fonctionne, il envoie un sous-agent (un second agent lancé pour cette seule tâche) le lire au lieu de te le demander ;
• prendre les décisions, c'est le tien.

La session se termine quand plus aucune décision ne reste ouverte, et l'agent n'agit pas tant que tu n'as pas confirmé qu'il a bien compris. Jusqu'à la version 1.2 du 5 août 2026, il posait une question à la fois : les vidéos plus anciennes montrent donc un autre rythme. Si tu le préfères, la doc donne la ligne à ajouter à ton CLAUDE.md global : When grilling, ask one question at a time.

Un exemple : des codes promo

Imagine une petite boutique en ligne à laquelle tu veux ajouter des codes promo. Tu lances /grill-with-docs avec une phrase : « Je veux que les clients puissent saisir un code promo au moment de payer. » Voici à quoi peut ressembler le premier tour, dans le format du skill. C'est un exemple que j'ai écrit en français, pas une vraie session :

❓ Q1. Cumul : un client peut-il utiliser deux codes sur la même commande ?

➡️ Non, un seul code par commande.

---

❓ Q2. Type de réduction : pourcentage, montant fixe, ou les deux ?

➡️ Les deux.

---

❓ Q3. Livraison : la réduction porte-t-elle aussi sur les frais de port ?

➡️ Non, seulement sur les produits.

Tu peux répondre par numéro, par exemple « 1 d'accord, 2 seulement en pourcentage, 3 d'accord ». La question du plafond d'une réduction en pourcentage n'est pas encore posée : elle dépend de ta réponse à Q2, donc elle attend le tour suivant. Et si la boutique affiche déjà des prix barrés, l'agent va voir dans le code comment ils sont calculés au lieu de te poser la question.

D'après la documentation de grill-me, 46 questions en 4 tours, c'est une session ordinaire : compte les tours, pas les questions. Aucune limite n'est fixée : si ça traîne, demande à l'agent de conclure.

CONTEXT.md, le glossaire du projet

Pendant les questions, domain-modeling fixe les mots du projet. Quand tu emploies un terme flou, ou qui contredit le glossaire, l'agent le relève aussitôt. Dans l'exemple, « promo », « coupon », « réduction » et « remise » désignent peut-être la même chose, ou pas. Dès qu'un sens est tranché, il l'écrit dans un fichier CONTEXT.md à la racine. Sur le modèle du format du skill, traduit :

**Code promo** :
Le texte qu'un client saisit au paiement pour obtenir une réduction.
_À éviter_ : coupon, bon de réduction

**Réduction** :
Le montant retiré du prix des produits d'une commande.
_À éviter_ : remise, promo

Ce fichier ne contient que des définitions, une ou deux phrases par terme, sans détail technique ni spec. Il n'est créé qu'au premier terme tranché, et les autres skills le lisent avant d'explorer ton code.

D'après Matt Pocock, ce vocabulaire partagé rend l'agent moins bavard (un mot remplace une longue périphrase), lui fait dépenser moins de tokens à réfléchir et donne des noms de variables et de fichiers cohérents. Sa propre doc cite l'objection inverse : l'agent comprendrait aussi bien la définition écrite en toutes lettres, et le glossaire servirait surtout aux humains qui travaillent ensemble. L'idée rejoint le File Engineering : donner le bon contexte à l'IA dans des fichiers plutôt que de le répéter à chaque conversation.

Les ADR, pour les décisions qui comptent

Un ADR (Architecture Decision Record) est une courte note qui explique une décision technique et sa raison. domain-modeling n'en propose un que si trois conditions sont réunies :

1. la décision est difficile à défaire ;
2. elle surprendrait quelqu'un qui arrive sans contexte ;
3. elle vient d'un vrai compromis entre plusieurs options.

Si une condition manque, pas d'ADR, et la plupart des sessions n'en produisent aucun. Quand il y en a un, il va dans docs/adr/, numéroté (0001-nom-de-la-decision.md), et un paragraphe suffit. Dans l'exemple, « on enregistre le montant de la réduction dans la commande au moment du paiement, au lieu de le recalculer » coche les trois cases : c'est difficile à changer une fois des milliers de commandes passées, ça étonne sans explication, et c'est un choix entre deux options défendables.

Chapitre 4, 3 min

De la spec au commit

Le chemin dépend de la taille du travail. Une fonctionnalité qui tient dans une session enchaîne sur /implement, dans la même fenêtre. Au-delà, la suite est /to-spec, puis /to-tickets, puis /implement ticket par ticket.

to-spec : la spec, sans nouvelles questions

/to-spec ne te réinterroge pas : il résume ce qui a été décidé, avec le vocabulaire de ton CONTEXT.md et en respectant tes ADR. Avant d'écrire, il te fait valider les points de test (les « seams » en anglais) : les points d'entrée publics où les tests observeront le comportement, sans regarder à l'intérieur. Il en veut le moins possible, idéalement un seul. Pour les codes promo, ce pourrait être le calcul du total de la commande.

La spec suit toujours le même plan : le problème, la solution, une longue liste numérotée de user stories (« en tant que client, je veux..., pour... »), les décisions d'implémentation, les décisions de test, ce qui est hors périmètre, et des notes. Pas de chemin de fichier ni de code, qui seraient vite périmés. Elle est publiée dans ton gestionnaire de tickets avec le label ready-for-agent.

La documentation du skill conseille de relire surtout deux parties : les points de test et le hors périmètre, là où une mauvaise décision coûte le moins cher à corriger.

to-tickets : des tranches verticales

/to-tickets découpe ensuite le travail en tickets. Chaque ticket est une tranche verticale : un chemin étroit mais complet à travers toutes les couches (base de données, API, interface, tests), qu'on peut montrer ou vérifier seul, et assez petit pour tenir dans une fenêtre de contexte neuve (tout ce que l'agent garde en tête pendant une session). L'inverse, c'est le découpage en couches : toute la base, puis toute l'API, puis toute l'interface, et rien qui marche avant la fin.

Chaque ticket indique aussi ceux qui le bloquent. Pour les codes promo, ça pourrait donner :

1. Appliquer un code en pourcentage au panier (aucun bloqueur).
2. Ajouter les codes à montant fixe (bloqué par 1).
3. Enregistrer la réduction dans la commande payée (bloqué par 1).

Il te présente cette liste et te demande si le découpage est trop gros ou trop fin et si les blocages sont justes, jusqu'à ce que tu valides. Puis il publie : un fichier par ticket dans .scratch/<nom-de-la-feature>/issues/ en local, ou une issue GitHub par ticket, bloqueurs en premier, en essayant de créer de vrais liens de blocage. Seule exception au découpage vertical : un changement mécanique qui touche tout le code, comme renommer une colonne partout, se fait en trois temps (ajouter la nouvelle forme, migrer par lots, supprimer l'ancienne).

implement : un ticket, un commit

Ensuite seulement, tu vides le contexte avec /clear et tu lances /implement sur un ticket. Une exécution suit cinq temps :

1. lire le ticket et repérer les points de test ;
2. travailler en TDD à ces points, avec le skill /tdd ;
3. lancer souvent la vérification des types et les tests du fichier en cours ;
4. lancer tous les tests une fois, à la fin ;
5. lancer /code-review, puis committer sur la branche courante.

Le TDD (développement piloté par les tests), c'est écrire d'abord un test qui échoue, puis juste assez de code pour qu'il passe, une tranche à la fois. Le skill tdd n'écrit aucun test à un point qui n'a pas été validé avec toi. Sa version actuelle sort la refactorisation de cette boucle et la renvoie à l'étape de revue, même si le README parle encore du cycle rouge, vert, refactor.

/code-review examine les modifications depuis un point fixe (un commit, une branche) sur deux axes, confiés à deux sous-agents lancés en parallèle pour qu'ils ne s'influencent pas :

• les normes : le code respecte-t-il les règles écrites de ton dépôt, plus une liste de 12 défauts classiques tirés d'un livre de référence sur le refactoring ?
• la spec : manque-t-il quelque chose, le code en fait-il plus que demandé, quelque chose semble-t-il faux ?

Les deux rapports sont présentés côte à côte, sans être fusionnés. La revue signale, elle ne corrige rien.

Puis tu recommences : /clear, /implement sur le ticket suivant, commit. /implement ne traite qu'un ticket par appel, sans rien lancer en parallèle ni ouvrir de pull request, et il travaille sur la branche où tu te trouves, sans en créer une. Donne-lui la référence complète du ticket (son adresse ou son chemin) : dans une session neuve, un simple #2 peut désigner autre chose que ton ticket.

Ce que devient la spec

Pendant le travail, la spec est la destination et les tickets le chemin : si tu changes de cap, tu supprimes les tickets pas encore faits et tu gardes la spec. Une fois le travail livré, la documentation conseille de la traiter comme jetable, car rien ne la tient à jour. Ce qui mérite de durer va dans CONTEXT.md et les ADR.

Chapitre 5, 3 min

Les 25 skills du plugin

En cas de doute, /ask-matt sert d'aiguillage : décris ta situation, il t'indique le skill ou l'enchaînement qui convient.

Cinq skills à connaître hors de la boucle

Ces skills répondent à des situations que la boucle principale ne couvre pas.

• /diagnosing-bugs, pour les bugs coriaces. Il refuse la moindre hypothèse tant qu'il n'a pas une commande rapide qui échoue sur ce bug précis (un test, un script, une requête). Ensuite, il réduit le cas au minimum, te montre 3 à 5 hypothèses classées, les vérifie une variable à la fois, écrit un test de non-régression avant la correction quand c'est possible, puis nettoie derrière lui.
• /improve-codebase-architecture, pour l'entretien. Il regarde d'abord les zones que l'historique git montre souvent modifiées, fait explorer le code par un sous-agent, puis ouvre un rapport HTML avec une carte par piste d'amélioration. Choisir une carte lance une série de questions dessus, et la décision qui en sort passe ensuite par /to-spec puis /to-tickets. Le README conseille de le lancer tous les quelques jours, en prévenant qu'il repère les problèmes sans démêler le code à ta place.
• /wayfinder, pour un gros chantier dont tu ne connais pas encore les étapes, comme un nouveau projet. Il crée une carte (une issue avec la destination, les décisions prises, ce qui reste flou et ce qui est hors périmètre) et des tickets de quatre types : recherche, prototype, questions ou tâche. Chaque ticket se traite dans sa propre session. Il en sort des décisions : quand la carte est claire, tu la passes à /to-spec. Sur GitHub, crée ses labels à la main, le setup ne le fait pas.
• /research, quand une décision attend un fait extérieur, comme le comportement exact d'une API. Il lance un agent en arrière-plan qui lit des sources primaires (docs officielles, code source, specs) et laisse dans ton dépôt un fichier Markdown avec une source pour chaque affirmation. Tu continues à travailler pendant ce temps. Sa doc signale un bug ouvert (#530) : cet agent peut en relancer un second, et la facture en tokens grimpe. Surveille tes tâches en arrière-plan.
• /prototype, quand une question ne se tranche pas en discutant. Pour tester une logique, il écrit un fichier HTML à ouvrir d'un double-clic ; pour une interface, plusieurs variantes très différentes. Une fois la question tranchée, le prototype est rangé sur une branche à part, hors de main, pour garder la trace de ce qui a été testé. ask-matt conseille de le faire dans une session séparée, avec /handoff (un document de passation) à l'aller et au retour.

Hors plugin : bêta et divers

Le dépôt contient 12 autres skills, absents du plugin. Les 8 en bêta peuvent changer ou disparaître. Pour la boucle, le plus intéressant est implement-spec : il construit toute une spec sur une branche avec des sous-agents qui travaillent en parallèle, puis livre le tout en une seule pull request. Ils s'installent un par un :

npx skills@latest add mattpocock/skills --skill=implement-spec

Parmi les 4 skills divers, git-guardrails-claude-code bloque dans Claude Code les commandes git dangereuses (git push, git reset --hard...) avant qu'elles ne s'exécutent.

Chapitre 6, 2 min

Face à Spec Kit et BMAD

Ce que Matt Pocock défend

Son README vise explicitement trois méthodes qui prennent en charge tout le processus : GSD, BMAD et Spec Kit. Selon lui, elles t'enlèvent ainsi le contrôle, et un bug dans le processus devient difficile à corriger. Ses skills se veulent l'inverse : petits, faciles à adapter, combinables et utilisables avec n'importe quel modèle. Tu peux en garder quelques-uns, les modifier ou en sortir un de la boucle, à condition de garder ceux qu'ils appellent.

Trois idées reviennent dans le README et la doc :

• la spec est jetable une fois le travail livré : ce qui doit durer va dans le glossaire et les ADR ;
• des mots fixés dans CONTEXT.md, que l'agent et toi employez dans le même sens ;
• des tranches verticales, petites, testées et livrables une par une.

Il y ajoute le soin de l'architecture (des modules qui cachent beaucoup de travail derrière une interface simple) et s'appuie sur quatre livres classiques du métier : The Pragmatic Programmer, Domain-Driven Design, Extreme Programming Explained et A Philosophy of Software Design.

Le comparatif

Spec Kit est publié par GitHub. Sa spec décrit le quoi et le pourquoi, sans technique : le plan technique est un document à part. Tu poses une fois une constitution (les principes du projet), puis chaque fonctionnalité passe par les skills specify, plan, tasks, implement et converge, en répétant implement et converge jusqu'à ce que converge réponde « Converged ». La spec y est l'élément central, et maintenir le logiciel revient à la faire évoluer. Spec Kit découpe lui aussi le travail en user stories classées par priorité, testables et livrables seules, avec des tâches bloquantes et des dépendances. Ce qui sépare les deux : chez Matt Pocock, chaque ticket est publié dans ton outil de tickets et taillé pour une session d'agent neuve, et la spec est abandonnée une fois le travail livré.

BMAD Method fait intervenir des rôles spécialisés (produit, architecture, UX, développement, test), des discussions entre agents, et garde les décisions dans des documents qui servent de contexte durable. Il dit aujourd'hui adapter la quantité de méthode à la taille du travail, les petits changements allant directement au code, et il s'installe lui aussi sous forme de skills. C'est le cadre que j'ai utilisé, dans Cursor, pour structurer la V2 de Sam Tennis. La différence avec Matt Pocock tient surtout à ce qui reste : BMAD garde beaucoup de documents et de rôles, Matt Pocock un glossaire et quelques ADR, sans personnage.

Chapitre 7, 3 min

Limites et problèmes connus

Au 16 septembre 2026, le dépôt compte environ 500 issues ouvertes. J'ai gardé celles qui touchent la boucle principale, plus les faiblesses que la documentation reconnaît elle-même.

Les pièges propres à Claude Code

• Un conflit de nom avec /code-review (#483, 9 juillet 2026, 26 commentaires). Claude Code a sa propre commande /code-review, qui cherche des bugs, alors que celle du dépôt vérifie la spec et les normes. Selon la doc, avec le plugin, les skills sont aussi rangés sous le préfixe mattpocock-skills: et la commande intégrée devient difficile à atteindre sous son nom court. Avec npx skills, c'est le skill du dépôt qui masque celui de Claude Code.
• Des revues en cascade (#573) : les sous-agents de revue peuvent relancer /code-review eux-mêmes, et la doc cite un cas à plus de 50 agents.
• Des skills invisibles pour l'agent (#693, 29 juillet 2026) : les skills à lancer à la main peuvent manquer dans la liste que l'agent voit. Le problème a d'abord été signalé dans les apps desktop et web de Claude Code, puis reproduit fin août dans le terminal, sous Windows. La commande tapée à la main marche encore : tape toujours /grill-with-docs, au lieu de demander en phrase à l'agent de le lancer.

Les séances de questions

• Des interrogatoires sans fin (#44, avril 2026) : une issue raconte une session à 200 questions dans Codex. Matt Pocock y a répondu : « It's a conversation, not an exam. » Autrement dit, c'est toi qui mènes. Le dépôt refuse tout plafond de questions, et la doc de grill-me voit dans ces sessions à rallonge un périmètre trop large : découpe le travail, puis passe chaque morceau sur le gril.
• grill-with-docs n'écrit pas toujours ses fichiers. Selon sa doc, c'est le problème le plus signalé : l'agent charge grilling mais pas domain-modeling. Les questions ont bien lieu, mais CONTEXT.md ne bouge pas. Si des termes ont été tranchés et que le fichier est resté vide, lance /domain-modeling par son nom.
• CONTEXT.md peut gonfler jusqu'à devenir une spec. La doc de domain-modeling en fait son problème numéro un. Pour le remettre au régime, elle propose de lancer /grill-with-docs en demandant de raccourcir CONTEXT.md et d'en retirer les détails techniques.
• La plupart des réponses restent dans la conversation. Seuls les termes et les rares ADR sont écrits, et rien ne relie chaque réponse à la spec, aux tickets et aux tests. Garde la même conversation jusqu'à /to-spec, puis relis la spec en la comparant à tes réponses.

Specs, tickets et tokens

• Des specs longues à relire. La doc de /to-spec admet que relire la spec en entier est une vraie plainte, et qu'il n'existe pas de mode résumé. Une issue (#777, 6 août 2026) cite une spec à 74 user stories à plat. Le modèle convient aussi mal aux refactorisations et aux choix d'architecture.
• Un label qui attire les agents. Le label ready-for-agent posé sur la spec pousse les outils qui lancent un agent dès qu'une issue porte ce label à tout construire d'un coup, au lieu de prendre les tickets un par un. C'est le défaut le plus signalé sur ce skill, selon sa doc : retire le label de la spec une fois /to-tickets passé.
• Les liens entre tickets ne suivent pas toujours (#554, #513) : sur GitHub, les tickets ne sont souvent pas rattachés à la spec, et les blocages restent écrits en texte au lieu de vrais liens. Vérifie-les après la publication.
• Un coût en tokens élevé. La doc de /implement juge normal qu'un ticket non trivial dépasse 100 000 tokens, et des utilisateurs trouvent /implement et /tdd coûteux (#894). Une issue parle aussi de plus de 1,5 million de tokens avec /to-tickets (#826), mais un participant a montré que le skill publié ne lance aucun agent par ticket : ce coût venait d'une surcouche.

implement ne fait pas tout ce qu'il annonce

• Il saute souvent ses tests et sa revue (#479, 9 juillet 2026). Un utilisateur parle d'environ 80 % des cas, un autre a compté 17 appels à /implement sans un seul appel à /tdd. Ce sont des retours d'utilisateurs, sans mesure officielle. La doc reconnaît le point faible : si les points de test n'ont été validés nulle part, l'exécution se résume à écrire le code.
• Personne ne traite les remarques de la revue (#385, 28 juin 2026) : /implement ne les applique pas et ne coche pas les critères d'acceptation.
• Les tickets ne sont jamais fermés (#508, 10 juillet 2026). Sur une chaîne de tickets, ceux qui attendaient ne se débloquent donc jamais : ferme-les toi-même.
• La revue peut passer à côté (#511) : /code-review lit les commits, alors que /implement la lance avant de committer.

Enfin, je n'ai trouvé aucune mesure indépendante qui compare cette méthode au même modèle utilisé sans méthode : les bénéfices annoncés restent des observations. Et les renommages de l'été montrent que tout bouge vite : une copie modifiée que tu ne synchronises pas prend du retard en quelques semaines.

Chapitre 8, 1 min

Pour qui et comment l'essayer

Pour qui c'est utile

• tu codes avec un agent (Claude Code, Codex, Cursor...) dans un dépôt git ;
• ton projet a, ou peut avoir, des tests et une vérification des types : /tdd et /implement en dépendent ;
• tes fonctionnalités dépassent souvent une session, et l'agent part régulièrement dans une autre direction que la tienne ;
• tu veux garder la main à chaque étape plutôt que laisser un agent travailler seul pendant des heures.

Pour qui ça l'est moins

• Tu débutes sans git ni tests : /implement committe directement, et le TDD suppose des tests qui tournent.
• Tes changements sont petits : une série de questions puis /implement suffisent, la spec et les tickets n'apportent rien.
• Tu veux un agent qui enchaîne tout sans toi : regarde plutôt Superpowers, ou le skill bêta implement-spec.
• Tu n'as pas de code : /grill-me seul peut quand même t'aider à clarifier un plan ou un texte.

Ton premier essai en 7 étapes

1. Choisis une petite fonctionnalité que tu sais décrire en deux phrases, dans un projet git qui a déjà au moins un test qui passe.
2. Crée une branche : /implement committe sur la branche où tu te trouves.
3. Installe le plugin (ou passe par npx skills en gardant tous les skills), lance /setup-matt-pocock-skills et choisis les fichiers Markdown locaux pour ne rien publier.
4. Tape /grill-with-docs suivi de ta phrase de départ. Réponds tour par tour, et regarde ce qui arrive dans CONTEXT.md. S'il n'a pas bougé alors que des termes ont été tranchés, lance aussi /domain-modeling.
5. Si le travail tient dans la session, lance /implement dans la même fenêtre. Sinon, enchaîne /to-spec puis /to-tickets, sans vider le contexte.
6. Fais /clear, puis /implement avec le chemin du premier ticket. Vérifie dans le déroulé que /tdd a bien été appelé, pas seulement que des tests sont apparus.
7. Relis les modifications et le rapport de revue, corrige ce qui doit l'être, puis ferme le ticket toi-même avant de passer au suivant.

Chapitre 9, 2 min

Questions fréquentes

Comment installer les skills de Matt Pocock dans Claude Code ?

Lance claude plugins install mattpocock-skills dans ton terminal, ou /plugin install mattpocock-skills dans une session : le plugin est dans la marketplace officielle de Claude Code et reçoit ses mises à jour tout seul. Pour avoir des fichiers modifiables, passe plutôt par npx skills@latest add mattpocock/skills, mais n'installe pas les deux. Lance ensuite /setup-matt-pocock-skills une fois dans chaque projet.

C'est quoi le skill grill-me de Matt Pocock ?

C'est un skill qui demande à l'agent de t'interroger sur une idée avant d'agir : une fonctionnalité, un plan, une décision ou un texte. Il pose ses questions par tours, chacune avec la réponse qu'il recommande, jusqu'à ce qu'aucune décision ne reste ouverte. Il n'écrit aucun fichier et marche même en dehors d'un projet de code.

Quelle différence entre grill-me et grill-with-docs ?

Les deux posent les mêmes questions. grill-me n'enregistre rien et sert hors projet. grill-with-docs, fait pour un dépôt de code, lit ton code et écrit en plus le glossaire CONTEXT.md et les ADR au fil de la session. Il a besoin des skills grilling et domain-modeling pour fonctionner.

Faut-il GitHub pour utiliser les skills de Matt Pocock ?

Non. Au moment du réglage, tu peux choisir GitHub, GitLab, un autre outil comme Jira ou Linear, ou de simples fichiers Markdown dans un dossier .scratch/ de ton projet. Les fichiers locaux conviennent bien à un projet solo.

Pourquoi la commande /setup-matt-pocock-skills est introuvable ?

Si tu as installé les skills avec npx, vérifie que tu as coché setup-matt-pocock-skills dans l'installeur, qui te laisse choisir les skills un par un. Avec le plugin, cherche-le aussi sous le préfixe du plugin, par exemple /mattpocock-skills:setup-matt-pocock-skills. Et si un tuto te parle de to-prd ou de to-issues, ces noms n'existent plus : ce sont aujourd'hui to-spec et to-tickets.

Les skills de Matt Pocock marchent-ils avec Codex ou Cursor ?

Oui. Ils suivent le format ouvert des skills pour agents et s'installent avec npx skills@latest add mattpocock/skills, qui te laisse choisir les agents : Codex, Cursor, Claude Code et beaucoup d'autres. Depuis la version 1.2, chaque skill contient aussi un fichier de réglage pour Codex. Un plugin Codex natif est prévu, mais pas encore sorti.

Les skills de Matt Pocock sont-ils gratuits ?

Oui, le dépôt est sous licence MIT : tu peux les utiliser, les copier et les modifier. Le vrai coût, c'est ton abonnement ou ta consommation de tokens chez ton agent, et la boucle complète en consomme beaucoup : la documentation juge normal qu'un ticket non trivial dépasse 100 000 tokens.

Skills de Matt Pocock ou Superpowers : lequel choisir ?

Superpowers, créé en octobre 2025, est la méthode la plus proche : elle aussi est construite avec des skills. Mais elle se déclenche seule et peut faire travailler des sous-agents longtemps en autonomie, alors que les skills de Matt Pocock te font lancer chaque étape importante et restent petits et modifiables. Superpowers convient mieux si tu veux déléguer au maximum, les skills de Matt Pocock si tu veux garder la main. Je présente les deux dans ma sélection des meilleurs Skills Claude.

Chapitre 10, 1 min

Conclusion : commence par grill-with-docs

Pas besoin de toute la boucle pour savoir si la méthode te va. Prends une petite fonctionnalité d'un projet que tu connais bien, lance /grill-with-docs seul, puis regarde deux choses : si les questions t'ont appris quelque chose, et si le CONTEXT.md qui en sort est juste. Si c'est le cas, passe à /to-spec et /to-tickets sur la fonctionnalité suivante.

Pour choisir tes autres skills, jette un œil à ma sélection des meilleurs Skills Claude. Pour écrire les tiens, lis mon guide des Skills Claude.

À très vite,

Guillaume 👋