🎁 Ce que tu reçois : l'installation et le mode d'emploi des skills que Matt Pocock utilise tous les jours. Zéro ligne de code à copier, que des procédures pour ton agent : il te cuisine sur le besoin, écrit la spec, la découpe en tickets, puis code.
C'est quoi ce repo ?
Matt Pocock a publié le contenu de son dossier .agents, les skills qu'il utilise pour développer de vraies applications.
Au lieu de « Claude, fais-moi cette feature », tu fais :
/grill-with-docs
/to-spec
/to-tickets
/implementChaque commande est une procédure spécialisée qui guide l'agent.
Rappel : c'est quoi une Skill ?
Une Skill = un dossier avec un fichier SKILL.md en Markdown. Il explique à l'IA quand utiliser cette compétence, quelles étapes suivre, quelles erreurs éviter et quel résultat produire. En pratique : un GPT spécialisé, mais directement dans Claude Code.
Les 3 problèmes que ça règle
- L'agent n'a pas compris : la plupart des projets qui partent en vrille partent d'un malentendu, pas d'un bug. La parade : une session de grillage avant d'écrire la moindre ligne.
- L'agent est trop verbeux : s'il ne connaît pas ton jargon, il utilise 20 mots là où 1 suffit. D'où le
CONTEXT.md, qui fixe le vocabulaire du projet une bonne fois. - Le code se dégrade : plus l'agent code vite, plus le bordel s'accumule vite. Ça se rattrape avec du TDD et une review du diff à chaque itération.
Les skills les plus utiles
/grill-me, au lieu de coder, Claude te bombarde de questions : qui est la cible, comment on facture, multi-tenant ou pas, l'auth, les cas limites… Tu ressors avec un besoin clair.
/grill-with-docs, même chose, sauf qu'elle écrit la doc pendant qu'elle t'interroge : le CONTEXT.md avec ton vocabulaire métier, et les ADR (les décisions d'archi avec la raison derrière). À la session d'après, Claude sait déjà de quoi tu parles.
/to-spec, transforme toute une discussion en vraie spécification. Tu discutes 30 minutes, tu tapes /to-spec, tu obtiens une spec propre.
/to-tickets, découpe la spec en petites tâches indépendantes. Au lieu de « faire le dashboard » : tables → auth → API → UI → tests. Chaque ticket tient dans une fenêtre de contexte.
/implement, prend un ticket et le développe pour de vrai : compréhension → implémentation en TDD → vérifications → code review avant commit.
/wayfinder, pour les gros projets qui ne tiennent pas dans une seule session : il pose une carte du chantier en tickets d'investigation, et tu résous chaque zone une par une.
/triage, si tu bosses avec GitHub Issues ou Linear : il classe les issues, ajoute les labels, définit les priorités.
Installation : les 2 méthodes
Méthode 1 : Copier les skills dans ton projet
Les fichiers sont copiés chez toi : tu peux les modifier, les adapter, supprimer des étapes.
npx skills@latest add mattpocock/skillsPuis :
- Sélectionne les skills que tu veux et les agents cibles (Claude Code, Codex…)
- Coche bien
/setup-matt-pocock-skills - Dans ton agent, lance
/setup-matt-pocock-skills
Il te demande ton issue tracker (GitHub, Linear ou fichiers locaux), tes labels de triage, et où ranger la doc générée.
Méthode 2 : Installer le plugin Claude Code
Bundle géré, mis à jour tout seul quand Matt publie une version. Tu ne peux pas l'éditer : tu t'abonnes au lieu de forker.
claude plugin marketplace add mattpocock/skills
claude plugin install mattpocock-skills@mattpocockPuis /setup-matt-pocock-skills une fois par repo, comme au-dessus.
Ce que je garde, moi : et pourquoi
| Skill | Pourquoi je la garde |
|---|---|
/grill-with-docs | C'est là que je gagne le plus de temps. Mes clients arrivent avec une idée floue, et cette skill fait sortir les vraies contraintes avant qu'on parte construire le mauvais truc. |
/to-spec | Transforme un appel de découverte de 30 min en cahier des charges. Je l'envoie au client pour validation avant de toucher au code. |
/to-tickets | Découpe la spec en lots livrables. C'est ce qui me permet de facturer par brique au lieu d'un forfait flou. |
/implement | Exécute un ticket avec un vrai workflow (tests → code → review). Fini le « ça marche chez moi ». |
/wayfinder | Pour les gros chantiers qui ne tiennent pas dans une session : il cartographie avant de foncer. |
/tdd | Boucle red-green-refactor : l'agent écrit le test qui échoue avant d'écrire le code. C'est ce qui change le plus la qualité de ce qui sort. |
/code-review | Review du diff sur deux axes, les standards du repo et la fidélité à la spec, en sous-agents parallèles. Mon garde-fou avant de commit. |
Mon workflow type
- Appel client → je lance
/grill-with-docspendant ou juste après /to-spec→ j'envoie la spec au client pour validation/to-tickets→ je chiffre chaque ticket/implementticket par ticket, avec/tddet/code-reviewen dessous- Gros projet → je passe par
/wayfinderavant l'étape 2
Ressources
- 📦 Dépôt officiel : github.com/mattpocock/skills
- 🌐 Page skills.sh : skills.sh/mattpocock/skills