Skills de méthode : Superpowers, Matt Pocock

Un agent de code sans méthode écrit la fonctionnalité avant que tout le monde se soit entendu sur ce qu’elle doit faire, affirme que les tests passent sans les avoir lancés et ajoute tous les fichiers du dossier au prochain commit. Plusieurs projets ouverts lui donnent plutôt une méthode. Si vous voulez une méthode complète, installez Superpowers, de Jesse Vincent, ou les skills de Matt Pocock : les deux vont plus loin que le mien à chaque étape. J’ai écrit workflow pour des mandats où le design pèse lourd. C’est une boucle courte, avec des points de contrôle écrits (clarifier, planifier, écrire les tests d’abord, un développeur et un réviseur par tâche, vérifier, faire rapport). Elle confie chaque étape aux skills de design, ajoute les règles Git et de compte rendu que j’exige de tout agent, et renvoie à ces deux collections quand il faut aller plus en profondeur.

Les outils en lice

Ensemble de skills	Auteur	Licence	Sa force	Ses limites
Superpowers	Jesse Vincent (Prime Radiant)	MIT	Une méthode complète qui se déclenche toute seule : remue-méninges, plan, un sous-agent par tâche avec révision, TDD, vérification	Rien de léger : ses skills sont des démarches obligatoires, et c’est voulu
skills	Matt Pocock	MIT	De petits skills qu’on combine : interrogatoire, spécification puis tickets, TDD, diagnostic de bogues, revue de code, modélisation du domaine	Aucune boucle d’un bout à l’autre : c’est vous qui choisissez l’ordre
Spec Kit	GitHub	MIT	Le développement guidé par la spécification, où les documents sont les livrables, avec beaucoup d’agents différents	Assez lourd : il lui faut une CLI, Python 3.11 et uv
BMAD Method	BMad Code	MIT ; le nom BMad est une marque déposée	Une méthode agile complète, d’une idée floue jusqu’au logiciel qui fonctionne, ajustée à l’ampleur du travail	Pas encore stable : la v7 est une alpha de prévisualisation, et les deux versions demandent uv
workflow	Molveau Studio	MIT	Une boucle courte avec des points de contrôle écrits, des rapports d’état et de résultat, et un renvoi aux skills de design	Peu de profondeur à chaque étape : il vous envoie vers Superpowers et les skills de Matt pour ça

Chacun, sans parti pris

Superpowers, de Jesse Vincent

Superpowers est une méthode plus qu’une collection. Quand l’agent voit que vous voulez construire quelque chose, il prend un pas de recul pour vous demander ce que vous cherchez à faire, vous présente la spécification par morceaux assez courts pour être lus, puis écrit un plan assez clair pour qu’un développeur junior sans contexte puisse le suivre. Dès que vous donnez le feu vert, le développement par sous-agents prend le relais : un nouvel agent pour chaque tâche, dont le travail est inspecté et révisé avant que la suivante commence. Le TDD rouge-vert, les worktrees, le débogage méthodique et la vérification avant de déclarer le travail terminé complètent le tout. L’agent cherche un skill pertinent avant chaque tâche, et le README les présente comme des démarches obligatoires. Installez-le si vous voulez cette discipline partout ; il se trouve sur la place de marché officielle des plugins d’Anthropic. Mon skill garde la même forme pour l’implémentation, avec un développeur et un réviseur par tâche.

Les skills de Matt Pocock

Le dépôt de Matt fait le choix inverse : de petits skills qu’on combine. Selon son README, les cadres qui prennent en charge toute la démarche vous en retirent le contrôle et rendent difficile la correction des défauts de la démarche elle-même. grill-me et grilling vous questionnent jusqu’à ce que le plan tienne la route, to-spec et to-tickets le transforment en spécification puis en tickets, et tdd, diagnosing-bugs, codebase-design et code-review couvrent le développement. domain-modeling tient à jour, dans le dépôt, un vocabulaire commun et un registre des décisions. Installez-le si vous voulez garder la main sur la démarche et choisir un outil pour chaque tâche.

Spec Kit, de GitHub

Avec Spec Kit, c’est la spécification qui fait foi. Une CLI, specify, prépare le projet, puis les commandes se lancent dans la conversation avec l’agent : /speckit-constitution une fois par projet, puis /speckit-specify, /speckit-plan, /speckit-tasks et /speckit-implement pour chaque fonctionnalité, en révisant chaque résultat avant de passer au suivant. La correction de bogues et l’évaluation d’idées s’ajoutent par des extensions, et des préréglages permettent à une organisation d’imposer ses propres normes. Il fonctionne avec beaucoup d’agents de code, ce qui convient à une équipe qui en utilise plus d’un. Il lui faut Python 3.11 ou plus récent, et uv.

BMAD Method, de BMad Code

BMAD couvre tout le projet, de la décision de ce qu’on construit jusqu’aux changements de cap en cours de route, et il ajuste la démarche à l’ampleur du travail : les petits changements passent directement au développement, les travaux complexes ont droit à une planification plus poussée. La version stable, la v6.12, s’installe avec npx bmad-method install. La version 7 est livrée sous forme de skills et de plugins, mais c’est une alpha de prévisualisation, et son README prévient que les mises à jour peuvent briser la compatibilité. Les deux versions demandent uv. Installez-le si votre équipe veut une méthode agile reconnue, avec son propre vocabulaire, et qu’elle est prête à l’adopter d’un bout à l’autre.

Ce que workflow ajoute

• Une boucle avec des points de contrôle. Examiner, clarifier, planifier, développer en écrivant les tests d’abord, réviser, vérifier, faire rapport. Chaque étape attend un point de contrôle écrit : pas de plan tant que le résultat attendu, les règles, la portée, les états et les critères de réussite ne sont pas confirmés ; pas de tâche suivante tant que le réviseur n’a pas validé la précédente, d’abord sur la spécification, puis sur la qualité ; pas de « terminé » sans une vérification fraîche à l’appui.
• Un renvoi aux skills spécialisés. Un tableau confie chaque étape au skill qui connaît le métier : ui pour les écrans et les allers-retours sur la maquette, ux pour les textes et l’accessibilité, motion pour l’animation, anti-slop avant de dire qu’une interface est terminée, design-grill pour un audit en profondeur, french-typography pour les textes en français.
• Des rapports d’état et de résultat. Un bloc STATUS aux étapes clés et un bloc RESULT à la fin, qui distinguent sept états de livraison : implémenté, testé, révisé, commité, poussé, fusionné, déployé. Quand l’agent dit « terminé », il précise toujours lequel est vrai.
• De l’ordre dans Git. Partir d’une branche main à jour, une fonctionnalité par branche, ajouter les fichiers un par un et jamais git add ., et rien n’est poussé, fusionné ou déployé sans le feu vert de la personne qui décide, pour ce changement précis.
• La maquette avant le code. Pour un écran nouveau ou redessiné, la personne qui décide approuve une maquette avant le code. La vérification des types, le linter, les tests et le build passent avant qu’un réviseur IA lise le changement.
• Un format léger. Un SKILL.md et quatre fichiers de référence, autonomes. Il renvoie à Superpowers et aux skills de Matt pour qui veut aller plus loin, avec une règle tirée de l’expérience : un seul système de planification par fonctionnalité, parce que deux systèmes donnent deux versions de la vérité.

Installer

Le skill seul, avec la CLI skills :

npx skills add molveau/skills -s workflow

Le lot Méthodes (saas, vitrine et workflow) :

npx skills add molveau/skills -s saas -s vitrine -s workflow

Dans Claude Code, les onze skills dans un seul plugin :

/plugin marketplace add molveau/skills
/plugin install molveau-skills@molveau

Tous les skills et tous les lots sont sur la page des skills, et le code source est sur github.com/molveau/skills. À lire aussi : les compétences Claude Code que j’utilise, les skills d’audit de design, les skills d’interface.

Liste de vérification

• Un seul système de planification par fonctionnalité, peu importe la collection d’où il vient.
• Le résultat attendu, la portée, les états et les critères de réussite sont écrits et confirmés avant le plan.
• Chaque fonctionnalité et chaque correction de bogue commencent par un test qui échoue.
• Chaque tâche a un développeur et un réviseur, qui vérifie d’abord la spécification, puis la qualité.
• Le mot « terminé » s’appuie sur une commande lancée pendant cette session, et le rapport nomme l’état de livraison.
• Rien n’est poussé, fusionné ou déployé sans un feu vert explicite.