obra/superpowers : un cadre de compétences qui impose la rigueur d'ingénierie aux agents de code

Contexte et définition du problème

Les agents de code savent écrire du code, mais ils sautent souvent les règles qui font la rigueur d'ingénierie. Ils commencent à implémenter avant que l'objectif soit clair. Ils déclarent une tâche terminée sans lancer les tests. Ils modifient de nombreux fichiers à la fois, et la revue devient difficile. Le problème ne vient presque jamais de la capacité brute du modèle. Il vient de l'absence d'une méthode de travail que l'agent suit réellement.

obra/superpowers vise directement ce manque. Le projet se présente comme « une méthodologie complète de développement logiciel pour vos agents de code ». Elle repose sur un ensemble de compétences composables et sur quelques instructions initiales qui garantissent que l'agent les utilise. Selon le README, les compétences se déclenchent automatiquement, sans commande spéciale de la part de l'utilisateur.

Le projet est développé par Jesse Vincent et l'équipe de Prime Radiant. Il est publié sous licence MIT. Au 3 octobre 2026, le dépôt GitHub affichait 294 554 étoiles. Ce chiffre témoigne d'un fort intérêt de la communauté, mais il ne prouve pas que la méthode fonctionne. Cet article s'appuie sur le README et sur la structure du répertoire skills. Il ne présente aucun benchmark indépendant.

Noyau architectural et principes techniques

Le cœur de Superpowers est un flux de travail en sept étapes. Chaque étape est une compétence, activée par le résultat de l'étape précédente. La première, brainstorming, s'exécute avant toute écriture de code. Elle affine une idée brute par des questions, compare des alternatives, présente la conception par sections pour validation, puis enregistre un document de conception. Après approbation, using-git-worktrees crée un espace de travail isolé sur une nouvelle branche, lance l'initialisation du projet et vérifie que la base de tests est propre. writing-plans découpe ensuite le travail en tâches d'environ deux à cinq minutes. Chaque tâche indique des chemins de fichiers exacts, le code complet et les étapes de vérification.

L'exécution suit deux modes. subagent-driven-development confie chaque tâche à un sous-agent neuf, puis effectue une revue après chacune. Le README la décrit comme l'option la plus rigoureuse. executing-plans traite toutes les tâches dans une seule session et ne revoit l'ensemble de la branche qu'une fois à la fin. Le README la présente comme l'option la moins coûteuse. Dans les deux cas, test-driven-development impose le cycle rouge, vert, puis refactorisation : écrire un test qui échoue, constater l'échec, écrire le code minimal, constater la réussite, puis valider. Selon le README, le code écrit avant son test est supprimé. requesting-code-review s'exécute entre les tâches et signale les problèmes par gravité ; un problème critique bloque la progression. finishing-a-development-branch vérifie les tests, propose de fusionner, d'ouvrir une demande de fusion, de conserver ou d'abandonner la branche, puis nettoie l'espace de travail. L'endroit où sont placées les contraintes compte aussi. Les règles vivent dans des fichiers de compétences, et non dans une seule ligne d'invite. L'agent doit vérifier les compétences pertinentes avant chaque tâche. Le README les décrit comme des flux de travail obligatoires, et non comme de simples suggestions. Un choix de conception mérite attention. La revue en deux étapes de subagent-driven-development vérifie d'abord la conformité à la spécification, puis la qualité du code. Séparer « a-t-on construit la bonne chose » de « est-elle bien construite » empêche les remarques de style de masquer les problèmes fonctionnels.

Évaluation pratique et applications

Le répertoire de compétences compte quinze entrées, réparties en quatre familles. Les tests sont dominés par test-driven-development. Le débogage comprend systematic-debugging, un processus de recherche de la cause racine en quatre phases, avec des techniques de traçage de la cause, de défense en profondeur et d'attente conditionnelle, ainsi que verification-before-completion, qui exige de vérifier que le problème est réellement résolu. La collaboration couvre la conception, la planification, la répartition parallèle, la demande et la réception de revues de code, et la clôture de branche. Les compétences méta incluent writing-skills et using-superpowers. L'installation dépend de la plateforme. Claude Code s'installe depuis la place de marché officielle d'Anthropic ou depuis celle de Superpowers. Antigravity utilise la commande agy plugin install avec l'URL du dépôt. Le README cite plus d'une dizaine de plateformes prises en charge, dont Cursor, Codex CLI, Gemini CLI, OpenCode et Hermes Agent. Chaque plateforme requiert sa propre installation. L'évaluation demande trois précautions. D'abord, le flux vise des échecs bien connus : tests sautés, grands changements non relus, déclarations de réussite sans vérification. Savoir si ces échecs diminuent exige une comparaison contrôlée sur de vrais projets, avec et sans le cadre. Cet article ne contient pas ces données. Ensuite, le README affirme que l'agent peut parfois travailler seul pendant deux heures sans s'écarter du plan. C'est une description du projet, que cet article ne peut pas vérifier. Enfin, un processus plus lourd coûte davantage en jetons. subagent-driven-development crée un sous-agent par tâche, donc il coûte plus cher que executing-plans. Les équipes doivent adapter le mode à la taille de la tâche.

Deux limites comptent aussi. Le projet indique qu'il n'accepte généralement pas de nouvelles compétences, et que toute modification d'une compétence doit fonctionner sur tous les agents de code pris en charge. Superpowers est donc une méthodologie assumée, et non une place de marché ouverte. Par ailleurs, le compagnon visuel optionnel de brainstorming charge par défaut un logo depuis le site de Prime Radiant, et cette requête contient la version de Superpowers utilisée. Le README précise que le projet ne voit ni détails du projet, ni invites, ni clics. La variable SUPERPOWERS_DISABLE_TELEMETRY, réglée sur une valeur vraie, désactive cette fonction. Les organisations doivent le savoir avant tout déploiement.

Impact sur l'industrie et perspectives

L'importance de Superpowers tient moins à un morceau de code qu'à ce qu'il rend distribuable. La rigueur d'ingénierie vivait depuis longtemps dans les habitudes des ingénieurs expérimentés et dans les listes de contrôle de revue. Ici, ces habitudes sont livrées sous forme de compétences, installées avec l'agent, et vérifiées avant le début de chaque tâche. L'effet touche deux publics. Pour un développeur isolé, des règles qu'il devait se rappeler d'appliquer deviennent le comportement par défaut. Pour une équipe, le cadre offre un point de départ commun : les agents des membres suivent la même séquence, et les revues s'alignent plus facilement. Le projet pose aussi une question à suivre dans le temps. Les contraintes méthodologiques resteront-elles utiles à mesure que les modèles progressent ? Un processus indispensable aujourd'hui pourrait devenir une charge inutile avec un modèle plus fort. À l'inverse, des agents plus capables pourraient avoir besoin de limites plus nettes pour rester dans le plan pendant un travail autonome. Y répondre demande des données suivies dans la durée, et non une seule démonstration.

La taille de la communauté montre une demande réelle. Elle ne prouve pas la qualité. Les prochains points à surveiller sont la capacité d'équipes indépendantes à reproduire les gains sur des dépôts de production, la capacité des étapes de revue à repérer de vrais défauts, et la question de savoir si les écarts de comportement entre plateformes érodent la promesse d'une méthode qui fonctionne partout. Dans le cadre de cet article, la conclusion est claire. Superpowers conditionne une méthode d'ingénierie bien structurée et aux contraintes explicites. La justification de sa conception est solide. Son bénéfice pratique doit encore être mesuré de façon indépendante.