TL;DR : Le repo Skills de Matt Pocock compte plus de 160 000 étoiles sur GitHub, et son workflow principal tient en quatre commandes : d'abord, vous laissez l'agent vous cuisiner (grill-me), puis vous compressez la réponse dans une spécification (Spec), la découpez en Tickets qui tiennent chacun dans une fenêtre de contexte (Context Window), et lancez l'implémentation — mais la révision (review) est effectuée par un sous-agent (subagent) avec un contexte frais. Le secret n'est pas l'intelligence, mais le processus : l'agent n'écrit pas de code tant que vous ne vous êtes pas compris, et il n'évalue pas son propre travail.
Le problème : l'agent tape plus vite que vous ne pensez
La plupart des projets de codage par IA n'échouent pas à cause de la qualité du modèle, mais parce que les questions de conception n'ont jamais été posées. L'humain et l'agent commencent avec une idée vague dans la fenêtre de chat, l'agent se lance, et vingt minutes plus tard émerge une PR que personne n'a vraiment demandée — un code "plat de spaghettis" à moitié fini, parce que personne n'a réfléchi à l'architecture avant de commencer à taper.
Matt Pocock, connu pour ses cours TypeScript, a créé un ensemble de "Skills" (compétences) exactement pour contrer cela : son répertoire personnel .agents, rendu public sous github.com/mattpocock/skills. Il compte aujourd'hui plus de 160 000 étoiles, des millions de téléchargements — et depuis peu, un tutoriel officiel complet de bout en bout.
Le principe de base : L'alignement avant le code. L'agent est déjà intelligent. Ce qui manque, c'est un processus qui force le travail de réflexion que personne ne faisait auparavant.
Phase 1 : grill-me — le canard en plastique automatisé et bavard
Le skill le plus populaire du repo tient en trois phrases. Il ne fait rien de spectaculaire : il pose la bonne question au bon moment. Au lieu de passer en mode planification, vous laissez l'agent vous cuisiner (grill) — une question après l'autre, jusqu'à ce que vous ayez tous les deux la même compréhension de l'objectif, des contraintes et des risques.
Avant l'ère de l'IA, on appelait ça le Rubber Ducking (le canard en plastique). La différence : le processus "Grill" transforme le canard en plastique en un interlocuteur qui débat, contredit, cherche les lacunes et met en évidence les hypothèses que vous aviez tacitement tenues pour acquises.
La variante avancée /grill-with-docs maintient en plus un fichier CONTEXT.md contenant le vocabulaire du projet et utilise des Architectural Decision Records (ADRs) pour que les décisions non évidentes soient documentées au lieu d'être simplement enterrées dans l'historique du chat.
Phase 2 : to-spec — de la discussion à l'artefact
Après le "grill", le flux se sépare : si le travail tient en une seule session, vous passez directement à l'implémentation. S'il nécessite plusieurs sessions, vous compressez la discussion avec /to-spec dans une spécification détaillée (Detailed Spec) — l'objectif, les User Stories, les décisions d'implémentation et de test, rédigées dans l'outil de suivi des tickets (Issue Tracker), et non dans un message de chat.
La Spec est le point d'ancrage auquel tout peut être rattaché par la suite : chaque ticket, chaque commentaire de review, chaque commit. Sans cet artefact, la notion de "terminé" n'est qu'un sentiment.
Phase 3 : to-tickets — un ticket par Context Window
/to-tickets découpe la Spec en tranches qui tiennent chacune dans une fenêtre de contexte (Context Window). L'exemple de Pocock tiré du tutoriel : une Spec a été transformée en onze sous-tickets (Sub-Issues).
Pourquoi une telle rigueur ? Les LLMs ont une "Smart Zone" (zone d'intelligence) fiable. Plus le contexte est rempli, plus l'agent oublie les conventions, les cas particuliers et les instructions précédentes. Un ticket qui reste en dessous de cette limite (en gros moins de ~140K tokens de contexte utilisé) sera implémenté de manière beaucoup plus fiable qu'un méga-ticket qui vit pendant trois sessions dans les méandres de la mémoire d'une seule conversation.
Important lors du découpage : les tickets doivent être des tranches verticales (vertical slices) — une section fonctionnelle complète de bout en bout plutôt que "d'abord la BDD, puis l'UI, puis les tests". Ainsi, chaque ticket peut être testé de manière autonome.
Phase 4 : implement — et surtout : Review avec un contexte frais
Le skill /implement traite un ticket : Type Checks, Build, TDD sur les interfaces convenues à l'avance — et pour finir /code-review, exécuté par des sous-agents.
C'est à ce stade que la plupart des configurations choisissent la facilité : l'agent principal passe en revue (review) son propre code — dans le même contexte usé où il l'a écrit. Le résultat est au mieux indulgent, au pire aveugle. Un contexte propre fait une revue plus honnête car il ne traîne aucune logique de justification.
La Code-Review de Pocock fonctionne donc sur deux axes sous forme de sous-agents parallèles qui ne se contaminent pas mutuellement :
| Axe | Question | Référence |
|---|---|---|
| Standards | Le diff respecte-t-il les standards de codage et évite-t-il les "code smells" classiques ? | codingstandards.md dans le repo + Smell-Baseline |
| Spec | Le code implémente-t-il réellement le ticket/la Spec d'origine ? | Issue/Spec d'origine |
Dans la configuration personnelle de Pocock, les sous-agents d'implémentation tournent dans Sandcastle, son orchestrateur pour agents de codage sandboxés. Mais au quotidien, le workflow fonctionne tout aussi bien avec des sous-agents normaux — le principe fondamental est de repartir d'un contexte vierge, l'outil importe peu.
La configuration en deux commandes
npx skills@latest add mattpocock/skills
/setup-matt-pocock-skills
Le skill de configuration paramètre l'issue tracker, les labels de triage et la structure des documents une fois par repo. Ensuite, le workflow s'exécute dans un ordre précis : grill → (spec → tickets) → implement. Pour ceux qui ne veulent que l'essentiel : grill-me fonctionne aussi très bien tout seul — la version en trois phrases ne coûte rien en infrastructure et offre le meilleur retour sur investissement (ROI) de tous les skills individuels.
Le workflow en un coup d'œil
| Phase | Commande | Artefact | Durée |
|---|---|---|---|
| Alignement | /grill-me ou /grill-with-docs | Compréhension partagée, CONTEXT.md | 10–30 Min |
| Compression | /to-spec | Spec dans le tracker | une seule fois |
| Découpage | /to-tickets | Des tickets d'une taille max d'une Context Window | une seule fois |
| Implémentation | /implement + /code-review | PR avec review par un contexte frais | par ticket |
❌ À ne pas faire — ✅ À faire
- ❌ Entrer un prompt, sortir du code, ouvrir une PR — ✅ Se faire "cuisiner" (grill), répondre aux questions, puis faire une Spec
- ❌ "Fais toute la fonctionnalité" dans un seul chat — ✅ Un ticket par fenêtre de contexte (Context Window)
- ❌ L'agent principal review son propre code dans un contexte plein — ✅ Sous-agent frais, deux axes séparés
- ❌ Des décisions prises uniquement dans l'historique du chat — ✅ Spec et ADRs dans le tracker, version par version
Quand ce workflow est-il excessif (overkill) ?
Pour être juste : pour une correction de deux lignes ou un prototype jetable, le cycle complet des quatre phases est trop lourd. Le workflow devient rentable à partir du moment où une fonctionnalité doit survivre à plusieurs sessions, que d'autres personnes (ou agents) devront travailler dessus plus tard, ou que vous-même ne saurez plus demain pourquoi vous avez opté pour la variante B. C'est exactement pour cela que ce repo a été conçu — "Skills for Real Engineers" (Des compétences pour de vrais ingénieurs), et non pour des jeux de prompts. D'ailleurs, pour un travail trop vaste pour tenir dans une seule session d'agent, le repo propose également /wayfinder — un système de cartographie basé sur des tickets de décision dans le tracker.
FAQ
Par quoi commencer si tout le workflow me semble trop lourd ?
Avec /grill-me uniquement. Ce skill tient en trois phrases, ne nécessite aucune configuration et change immédiatement votre façon de planifier : l'agent vous pose des questions une par une jusqu'à ce que vous ayez la même vision de l'objectif. Le reste du flux (spec, tickets, review) s'appuie là-dessus, mais peut être ajouté ultérieurement. Si vous ne devez retenir qu'une seule chose de cet article, c'est de laisser l'agent vous cuisiner avant de commencer la prochaine fonctionnalité, au lieu de prompter tête baissée.
Ai-je besoin de Sandcastle ou de la toolchain exacte de Pocock ?
Non. Sandcastle est l'outil de Pocock pour orchestrer des agents de codage en sandbox, mais le flux fonctionne avec n'importe quelle configuration d'agents gérant des sous-agents ou au moins des sessions fraîches — Claude Code, Codex, OpenClaw, peu importe. Le cœur transférable est la règle : "L'implémentation et la révision s'exécutent dans des contextes séparés et frais", et non l'outil en lui-même. Même la partie Review peut être mise en œuvre de manière primitive : ouvrez un nouveau chat, collez le diff, interrogez les deux axes.
Quelle est la taille maximale d'un ticket ?
En règle générale : il doit tenir, avec le contexte de la base de code et la discussion, dans une seule fenêtre de contexte (Context Window) tout en restant dans la zone fiable du modèle — grosso modo en dessous d'environ 140K tokens de contexte utilisé, parfois beaucoup moins selon le modèle. Un bon indicateur est de pouvoir terminer le ticket en une session avec des tests au vert. Si un ticket ressemble à "Phase 1 sur 3", c'est qu'il est mal découpé — il vaut alors mieux le diviser à nouveau.
Quelle est la différence entre grill-me et grill-with-docs ?
/grill-me est la version rapide : l'agent pose des questions, vous discutez jusqu'à ce que la compréhension soit partagée — terminé. /grill-with-docs mène le même interrogatoire, mais maintient des artefacts persistants : un CONTEXT.md comme glossaire de votre domaine et des Architectural Decision Records (ADR) pour les décisions non évidentes. Pour un travail ponctuel, grill-me suffit ; dans un repo d'équipe avec un historique, la variante avec documentation est rentabilisée dès la deuxième semaine.
Pourquoi un étranger devrait-il vérifier mon code au lieu de l'agent qui l'a écrit ?
Parce que l'agent rédacteur est partial et aveugle : son contexte est rempli des compromis et des erreurs qui ont conduit au code, et les modèles ont tendance à juger leur propre performance avec indulgence. Un sous-agent frais ne voit que le diff, les standards et la Spec — et signale les "code smells" (défauts) de manière plus honnête, précisément parce qu'il n'a pas à défendre son propre travail. L'approche à deux axes (Standards en parallèle au respect de la Spec) empêche en outre les commentaires de review d'un canal de contaminer l'autre.
Est-ce que ça fonctionne uniquement avec Claude Code ou aussi avec d'autres agents ?
Le format (les skills sous forme de fichiers SKILL.md dans le répertoire de l'agent) est délibérément conçu pour être cross-tool et fonctionne dans Claude Code, Codex et d'autres environnements qui chargent des skills basés sur des dossiers. L'installeur (npx skills add mattpocock/skills) dépose les fichiers en conséquence, /setup-matt-pocock-skills adapte le tracker et la structure à votre repo. La qualité du modèle sous-jacent importe peu pour le workflow — ce dernier sert précisément à structurer le processus autour du modèle.
Sources
- Matt Pocock: Repo Skills — https://github.com/mattpocock/skills
- Matt Pocock: Tutoriel de bout en bout du workflow (X) — https://x.com/mattpocockuk/status/2075218406266036236
- Matt Pocock: Tutoriel du Workflow (YouTube) — https://www.youtube.com/watch?v=M6mYodf0dJM
- Matt Pocock: Changelog des Skills v1.1 (/wayfinder, /to-spec, /to-tickets, axes de Code-Review) — https://www.aihero.dev/skills/skills-changelog-v1-1-wayfinder-to-spec-to-tickets-grilling-improvements
- Matt Pocock: Atelier d'IA-Coding avec Sandcastle (YouTube) — https://www.youtube.com/watch?v=-QFHIoCo-Ko
- Alex Rusin: "Matt Pocock Skills: The Main Flow Explained" — https://blog.alexrusin.com/matt-pocock-skills-main-flow
- Aditya Kumar Puri: "Matt Pocock's Claude Code Skills made me rewrite how I work with AI agents" — https://adityakumarpuri.medium.com/matt-pococks-5-claude-code-skills-made-me-rewrite-how-i-work-with-ai-agents-d71853c3056c
- Danny Shmueli: Subagents + Pocock-Skills dans Hermes — https://dannyshmueli.com/2026/04/29/Matt-Pocock-Skills-Hermes-Subagents-Feature-Work/