Superpowers rend Claude Code fiable, mais ça a un prix

Superpowers est un plugin pour Claude Code écrit par Jesse Vincent, qui livre des outils open source pour développeurs depuis les années 1990. Il l'a publié en octobre et, moins d'un an plus tard, le dépôt affiche 280 000 étoiles et 25 000 forks, le dernier push datant de deux jours avant notre enregistrement. Le projet en est déjà à sa sixième version majeure avec 681 commits sur la branche main : ce n'est donc pas un recueil de prompts abandonné après le pic du lancement.

Signal	Valeur
Étoiles GitHub	280 000
Forks	25 000
Version majeure	6
Commits sur main	681
Issues ouvertes	125

Le pari de Vincent tient en une phrase : ce qui manque aux agents de code, ce n'est pas la capacité, c'est la discipline. Cette discipline est livrée sous forme de simples fichiers markdown que chacun peut lire, forker et adapter. Nous avons installé le plugin, lu les quatorze skills ligne par ligne, et regardé ce que cela change sur quatre fronts : productivité, fiabilité du code, dépense en tokens et documentation.

Superpowers est un plugin gratuit et open source pour Claude Code. Il est publié sur la marketplace officielle de plugins d'Anthropic et s'installe en une seule commande. La même méthodologie existe pour plus d'une dizaine d'autres outils, dont Cursor, Codex et Gemini, chacun avec son propre chemin d'installation.

Le cœur, ce sont quatorze skills : des fichiers d'instructions en markdown que l'agent charge dès qu'une situation leur correspond. Brainstorming, rédaction de plans, développement par subagents, développement piloté par les tests et debugging systématique encodent chacun une façon complète de travailler, avec leurs propres checklists et garde-fous. Le skill de debugging interdit de proposer un correctif avant d'avoir isolé la cause racine. Un skill de vérification oblige l'agent à prouver qu'un travail est terminé au lieu de l'affirmer. Chaque skill s'annonce quand il se charge, donc vous savez toujours dans quel mode l'agent travaille.

Un hook au démarrage de session force Claude à vérifier, avant chaque tâche, si l'un de ces skills s'applique. La règle est écrite dans le skill d'entrée : s'il y a même un pour cent de chance qu'un skill soit pertinent, l'agent doit le charger. Le résultat se comporte moins comme une boîte à outils que comme une méthodologie de développement injectée dans l'agent.

Vincent raconte l'origine du projet sur son blog. Il a construit les skills en fouillant 2 249 fichiers markdown de leçons apprises par ses propres agents, puis en mettant les brouillons à l'épreuve de ces mêmes archives. La méthodologie a été extraite de vrais échecs d'agents plutôt qu'écrite à partir de la théorie.

Le brainstorming est le skill par lequel tout passe. Dès que vous demandez une fonctionnalité, Claude le charge et se comporte en expert du recueil des besoins pendant toute la conversation de cadrage. La méthode complète tient dans un seul fichier lisible.

Le fichier s'ouvre sur un verrou strict : pas de code, pas de scaffolding, aucun skill d'implémentation d'aucune sorte avant que vous ayez validé une intention explicite. Rien ne se construit sur une intuition, et le verrou s'applique à chaque tâche, aussi petite qu'elle paraisse. Le skill trie ensuite chaque demande dans l'une de trois voies.

Voie	Définition	Résultat
Spike	Une question de faisabilité	Une réponse, pas du code que vous gardez
Bornée	Un petit changement sur un flux qui existe déjà dans le dépôt	Un changement délimité
Architecturale	Tout ce qui restructure la façon dont le projet s'assemble	Une spec que vous validez, puis un plan d'implémentation

L'agent annonce sa classification à voix haute pour que vous puissiez la corriger, et le cliquet ne tourne que dans un sens : une complexité cachée découverte en cours de tâche fait monter la voie, jamais l'inverse. Le fichier fournit un tableau de signaux d'alerte, des pensées comme « c'est trop simple pour avoir besoin d'un design », avec la réfutation juste à côté : les tâches simples sont exactement là où les hypothèses non examinées coûtent le plus. Même un spike garde son garde-fou. Ce que l'agent construit pour répondre à la question reste étiqueté jetable, et garder ce code devient une nouvelle demande à classer.

Pendant le dialogue, l'agent pose les questions qu'un lead dev poserait et présente son design par sections digestes. Sur notre propre pipeline, cette phase a déjà tué des fonctionnalités que nous aurions construites pour rien.

Le skill de rédaction de plans s'ouvre sur une instruction qui donne le ton : écrivez le plan pour un bon développeur qui n'a aucun contexte sur votre code et, selon les mots du fichier, un goût discutable.

Concrètement, le travail est découpé en tâches où chaque étape prend de deux à cinq minutes : écrire le test qui échoue, le lancer pour vérifier qu'il échoue, écrire le code minimal qui le fait passer, relancer les tests, commit. Une action, une vérification, et le travail avance par commits fréquents. C'est le cycle du développement piloté par les tests, imposé par un autre skill du plugin, donc chaque tâche porte son propre cycle de test.

Chaque tâche liste les fichiers exacts à créer ou à toucher, jusqu'au numéro de ligne. Le plan s'ouvre sur un en-tête obligatoire : l'objectif en une phrase, l'architecture en deux ou trois, la stack technique, un lien vers la spec et les contraintes globales du projet copiées mot pour mot. Si la spec couvre plusieurs sous-systèmes indépendants, le skill exige des plans séparés, un par sous-système, chacun produisant du logiciel testable tout seul.

Le découpage des tâches est le cœur de l'argument sur la fiabilité. Une tâche courte, c'est un agent qui finit son travail avec une fenêtre de contexte encore presque vide. Il n'atteint jamais le moment où la session déborde, où l'agent perd le fil et se met à inventer des fonctions qui n'existent pas. Aucune démo de cinq minutes ne montre ce problème, mais il décide de tout sur un vrai projet : la qualité d'un agent en fin de session n'a rien à voir avec sa qualité sur le premier prompt. Un contexte moins saturé, c'est mécaniquement moins d'hallucinations, et du code qui fait ce que le plan a dit.

À l'exécution, un skill dédié isole le travail dans un worktree git, une copie de travail séparée du dépôt, pour que le plan tourne sans marcher sur ce que vous faites à côté.

Le skill d'exécution pilote le développement par subagents. Son principe tient en une ligne du fichier : un subagent neuf par tâche, une review après chaque tâche, et une review large de toute la branche à la fin. Votre session principale devient un orchestrateur. Elle ne code plus, elle dispatche. Chaque subagent reçoit exactement le contexte dont sa tâche a besoin et jamais l'historique de votre session, ce qui évite la pollution du contexte et garde votre propre fenêtre libre pour la coordination.

Le subagent peut poser des questions avant de commencer, puis il implémente, teste, commit et relit son propre travail. Quand il a fini, l'orchestrateur lance une review en deux parties, conformité à la spec d'abord et qualité du code ensuite, avec un siège de reviewer dédié pour chaque tâche. Rien n'est improvisé : le skill fournit un prompt type pour chaque rôle (implémenteur, reviewer de tâche, et le reviewer qui revérifie les correctifs) que l'orchestrateur remplit avec le contexte de la tâche.

Résultat de la review	Ce qui se passe
Réussite	L'orchestrateur note la tâche finie dans un registre et avance dans le plan
Échec, tours 1 à 3	L'implémenteur d'origine reprend, puisqu'il connaît déjà le code et ses propres choix
Échec, tour 4	Un implémenteur neuf est dispatché sur un modèle plus capable
Échec, tour 5	Un disjoncteur saute et l'orchestrateur tranche lui-même chaque point encore ouvert

Le skill évite aussi l'excès inverse : une rafale de petites tâches mécaniques part comme un seul dispatch groupé, relu d'un bloc. Rien n'est mergé sans passer devant un reviewer. Le résultat est ce qu'une équipe humaine appelle un processus de code review, sauf qu'il tourne tout seul, tâche après tâche.

Le système de dispatch ouvre la porte à un troisième gain : l'économie de tokens. Le skill a une section sur le choix du modèle qui part d'une règle unique : utiliser le modèle le moins puissant capable de tenir chaque rôle. L'orchestrateur évalue la difficulté de chaque tâche du plan et assigne le modèle qui correspond.

Tâche	Palier de modèle
Tâche mécanique bien spécifiée sur un ou deux fichiers, ou plan qui contient déjà le code à écrire	Le palier le moins cher (implémenter devient transcrire et tester)
Coordination entre plusieurs fichiers, debugging	Un modèle standard
Architecture, review finale de la branche	Le modèle le plus capable disponible

Le fichier ajoute deux subtilités. D'abord, toujours nommer le modèle explicitement quand vous dispatchez : un subagent sans modèle hérite de celui de votre session, souvent le plus cher, ce qui ruine en silence toute la section. Ensuite, le nombre de tours prime sur le prix du token. Les modèles les moins chers prennent plus de tours sur un travail à nombreuses étapes et finissent par coûter plus cher au total, c'est pourquoi les reviewers et les implémenteurs qui travaillent à partir de prose ont un plancher un palier au-dessus plutôt que le premier prix.

Cette configuration rend viable quelque chose de contre-intuitif : faire tourner Opus ou Fable, les modèles les plus chers du catalogue, sur le plan Pro à 20 dollars. Le modèle cher ne travaille que sur les rares décisions qui le méritent, et le reste du plan tourne sur des modèles qui consomment une fraction de votre quota.

Le dernier gain est celui auquel personne ne pense en installant le plugin. Les specs et les plans ne sont pas des messages de chat qui disparaissent en fin de session. Ce sont des fichiers markdown enregistrés dans le dépôt et commités avec le travail. Le skill fixe l'emplacement : un dossier de plans daté, un fichier par fonctionnalité, avec l'objectif, l'architecture et le lien vers la spec dans l'en-tête.

La spec voyage avec le plan, et les conflits entre les deux se tranchent en faveur de la spec : le document fait autorité, pas la mémoire de l'agent. L'historique git ne dit plus seulement ce qui a changé. Il dit pourquoi, et ce que l'agent avait décidé à ce moment-là. Six mois plus tard, citer le fichier du plan dans un prompt permet à l'agent de reprendre aussitôt le contexte de la fonctionnalité d'origine, et une nouvelle fonctionnalité sur le même sous-système s'appuie sur la spec existante au lieu de redécouvrir le terrain.

Il n'existe plus de tâche sans trace : tout ce qu'un agent a fait sur le code a laissé un document derrière lui, du premier brainstorm au dernier commit. Le projet résume sa philosophie en deux principes, le systématique plutôt que l'improvisé et les preuves plutôt que les affirmations. La documentation découle du processus toute seule.

La limite est réelle et le dépôt ne l'affiche pas : toute cette discipline a un coût fixe, et ce coût ne s'éteint jamais. Le skill d'entrée est sans détour. Au moindre doute, l'agent doit charger le skill, et le fichier de brainstorming précise que la cérémonie s'adapte à la tâche mais que la validation humaine, elle, ne s'adapte jamais.

Sur un correctif de deux lignes, cela veut dire répondre aux questions de cadrage, valider un design de deux phrases, puis attendre le cycle complet avant de voir le correctif. Pour une faute de frappe dans un fichier de config, le processus complet est simplement plus lent que corriger soi-même. L'orchestration elle-même consomme des tokens : les briefs de dispatch, deux reviews par tâche et le registre sont payés à chaque fois, et c'est sur les plus petites tâches qu'on le sent le plus.

Il y a aussi le symptôme inverse, et il répond directement à la question posée sur Reddit. Si vos statistiques d'usage montrent le plugin à quelques pour cent, vos demandes ne déclenchent presque jamais les skills, donc vous payez le contrôle d'entrée à chaque session sans jamais toucher aux gains. Une boucle de correction qui va jusqu'au bout de ses cinq tours, c'est cinq diffs, cinq reviews de plus et un arbitrage, pour une tâche qui devait prendre quelques minutes. Le projet ne tient jamais en place non plus : il est passé d'une première version à une sixième en moins d'un an et compte encore 125 issues ouvertes, donc les skills que vous lisez aujourd'hui auront changé à la prochaine mise à jour.

Le plugin prévoit sa propre sortie. Ses instructions placent vos directives au-dessus des skills, donc vous pouvez dire à l'agent, explicitement, de sauter le processus. Notre règle : Superpowers activé par défaut pour tout travail sur une fonctionnalité, et un skip délibéré pour les tout petits correctifs.

Votre usage de Claude Code	Verdict
Des fonctionnalités de plusieurs heures	Installez-le : le cadrage vous évite d'implémenter la mauvaise chose, les tâches courtes tiennent l'agent loin de la saturation du contexte, le choix du modèle étire votre quota, et vous héritez d'une documentation que vous n'auriez jamais écrite
Des scripts jetables et des petits correctifs	Passez votre chemin : vous paieriez le coût fixe du processus sur des tâches qui n'en ont pas besoin
Entre les deux	Installez-le et apprenez à dire skip : une phrase dans votre prompt vous rend le contrôle

Si vous voulez le tester sans tout adopter, laissez tourner uniquement le skill de brainstorming pendant quelques jours. Il porte le gros du gain, et les autres skills se greffent naturellement après lui. Le plugin tient ses quatre promesses tant que vous lui donnez des fonctionnalités dignes de sa cérémonie. Il tourne désormais sur nos propres projets, et la phase de brainstorming est celle que nous ne désactiverions plus. Le dépôt est gratuit et open source, avec 280 000 personnes dans la file devant vous.