Claude Code Skills : à quoi sert le plugin Superpowers ?

Qu’est-ce que Claude Superpowers ?

Superpowers est une bibliothèque de skills d’ingénierie créée par Jesse Vincent, accompagnée d’instructions qui incitent un agent de programmation à les utiliser. Dans Claude Code, l’assistant de programmation d’Anthropic qui travaille dans votre dépôt, elle fournit des workflows pour comprendre une demande, planifier les modifications, tester, déboguer, déléguer et terminer le travail sur une branche. Voyez-y le manuel de fonctionnement d’un atelier : les outils sont déjà là ; le manuel fixe l’ordre des opérations et les contrôles avant livraison. README de Superpowers

Vérification du 18 octobre 2026 : le manifeste du code source indique la version 7.0.0, et le dépôt contient 15 dossiers de skills à la racine du répertoire correspondant, chacun doté d’un fichier SKILL.md. Ce constat porte sur le code examiné pour cet article ; vérifiez la révision qu’installe la marketplace choisie. Manifeste du plugin, répertoire des skills

L’intérêt concret tient à la visibilité des décisions. Avant de modifier une fonctionnalité, Claude peut en préciser le comportement attendu. Avant d’annoncer qu’elle est terminée, il peut exiger un nouveau résultat de test. Ces instructions vous donnent des éléments tangibles à examiner, sans pour autant garantir que les exigences ou les tests sont justes.

Comment installer Superpowers dans Claude ?

Dans Claude Code, suivez l’une des méthodes d’installation du README du projet. Les commandes ci-dessous sont reprises à l’identique de sa section Claude Code. Ce sont des commandes interactives commençant par une barre oblique, à saisir dans Claude Code et non dans un shell classique. Instructions d’installation du README

Installer le plugin Claude Superpowers depuis la marketplace officielle

/plugin install superpowers@claude-plugins-official

Le créateur documente aussi sa propre marketplace. Si vous préférez cette méthode, ajoutez-la, puis installez le plugin :

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Choisissez une source dont vous pourrez suivre les évolutions. Il n’y a aucun intérêt à enchaîner les deux méthodes pour installer le même plugin.

Après l’installation, ouvrez une nouvelle session Claude Code pour déclencher le hook de démarrage. Confiez-lui une demande bien délimitée, par exemple l’ajout d’un filtre à une liste de tâches existante. Le point à observer est simple : annonce-t-il un skill adapté et en suit-il les instructions ? Constater que la commande d’installation s’est terminée ne revient pas à constater que le workflow fonctionne comme prévu.

Qu’est-ce qui change dans une session après l’installation ?

Le premier changement concerne le contexte : un hook de démarrage insère les instructions d’utilisation de Superpowers dans la conversation. Le sélecteur configuré pour SessionStart couvre startup, clear et compact. Son script lit using-superpowers, en injecte le texte et demande à Claude de charger les autres skills avec l’outil Skill. Il ne colle pas le contenu intégral de tous les skills dans le message de démarrage. Configuration du hook, script de démarrage

Comment Claude choisit-il un skill Superpowers ?

Claude rapproche la tâche des descriptions des skills, puis lit les instructions pertinentes. Le guide de rédaction du plugin précise que chaque description doit indiquer dans quelles situations le skill s’applique. Les instructions d’amorçage demandent à l’agent de faire cette vérification avant de répondre ou d’agir, d’annoncer le skill retenu et de faire passer les skills de méthode avant ceux d’implémentation. Guide de découverte des skills

Ainsi, une demande de création oriente vers brainstorming ; un test qui échoue, vers systematic-debugging. Un skill spécialisé peut ensuite guider l’implémentation. Vous pouvez aussi demander explicitement un skill par son nom, par exemple : « Utilise superpowers:systematic-debugging pour rechercher la cause de cet échec avant de proposer un correctif. » Instructions d’utilisation

La sélection automatique repose sur une consigne donnée au modèle, pas sur un déclencheur déterministe à mots-clés. Le hook fournit les instructions d’amorçage ; l’agent doit encore reconnaître la situation et suivre les consignes du skill choisi. S’il se trompe de workflow, précisez le périmètre de la tâche ou demandez directement le skill approprié.

Claude Code Skills : quels skills Superpowers déclenche-t-il ?

La bibliothèque couvre tout le cycle de développement, mais une session doit charger les skills adaptés au travail à accomplir. Voici les noms exacts relevés dans les fichiers examinés. La colonne des situations d’usage reformule leurs descriptions et leurs instructions ; elle ne garantit pas qu’une phrase donnée déclenchera toujours un skill précis. Répertoire actuel des skills

Inutile de mémoriser tout cet inventaire. Pour développer une fonctionnalité courante, surveillez les transitions : demande comprise, plan concret si nécessaire, implémentation testée, modification revue, décision d’intégration. Pour un bug, commencez par l’investigation plutôt que par une discussion de conception comme s’il s’agissait d’une nouvelle fonctionnalité.

Comment s’articule-t-il avec le mode Plan natif et vos propres skills ?

Superpowers encadre la planification par un workflow ; son skill writing-plans est distinct du mode Plan natif de Claude Code. Les instructions d’amorçage actuelles demandent explicitement d’invoquer brainstorming avant d’entrer en mode Plan si cette étape n’a pas déjà eu lieu. Elles fixent donc un ordre des opérations, sans considérer le mode natif et leur propre skill de rédaction de plans comme interchangeables. Instruction actuelle sur la planification

writing-plans produit un document dans le dépôt, généralement sous docs/superpowers/plans/, qui consigne les choix d’implémentation et les vérifications. Lors du passage à l’exécution, il demande à l’utilisateur de relire le plan et de choisir une méthode d’exécution, sauf si ce choix a déjà été précisé. Sélectionner un mode ne suffit pas à fournir ce document ni ces instructions par tâche. Pour les commandes et le fonctionnement de l’outil hôte, consultez le guide du mode Plan de Claude Code.

Vos propres skills gardent leur place. Le fichier writing-skills du plugin désigne ~/.claude/skills/ comme le répertoire des skills personnels de Claude Code. Ses instructions d’amorçage placent explicitement les consignes de l’utilisateur, y compris CLAUDE.md et les demandes directes, au-dessus de celles des skills. Un skill propre au projet peut donc porter vos conventions pendant que Superpowers fournit la méthode de développement. Définissez clairement cette répartition si les deux dictent le déroulement des tests ou de la revue. Fichier de rédaction des skills, priorité des instructions

Pour comprendre le principe de ces fichiers d’instructions, consultez l’article sur les skills d’agents. Superpowers en propose une collection fondée sur des choix de méthode affirmés.

Superpowers dans Claude Code : une fonctionnalité de l’idée à la fusion

Un bouton « Masquer les tâches terminées » suffit à illustrer le workflow complet. L’exemple qui suit s’appuie sur les fichiers des skills ; ce n’est pas le compte rendu d’une session de test enregistrée. Les noms de fichiers, les cas d’acceptation et le résultat sont hypothétiques.

Partons d’une application de liste de tâches qui dispose déjà de tests. L’utilisateur demande un bouton pour masquer les éléments terminés sans les supprimer. Pour cet exemple, il exige explicitement un plan écrit et des revues de tâches par des sous-agents. Sans cette demande, une modification aussi modeste pourrait suivre le parcours court, dont la description tient dans la conversation.

Définir le comportement avec brainstorming

La question décisive est de savoir si « masquer » ne touche qu’à l’affichage ou modifie les tâches enregistrées. Ici, le comportement convenu est un filtre limité à la vue : le bouton est désactivé au départ, les éléments terminés réapparaissent lorsqu’on le désactive, et l’état vide de la vue filtrée indique qu’il n’y a aucune tâche active.

Claude reformule ce périmètre et obtient l’accord de l’utilisateur. Puisque celui-ci a choisi le parcours écrit, la conception est consignée dans un document sous docs/superpowers/specs/, avec une vérification côté implémentation avant transmission. Le parcours habituel de ce skill pour une petite modification permet de garder la description et l’accord dans la conversation. Règles de brainstorming

L’élément à examiner est l’accord sur le comportement attendu. S’il ajoute discrètement des préférences enregistrées ou change le stockage des tâches, le périmètre s’est déjà élargi avant même le début de l’implémentation.

Rendre le travail vérifiable avec writing-plans

Le plan découpe la fonctionnalité en livrables vérifiables séparément. Le premier implémente une fonction de filtrage dans un fichier d’exemple src/tasks/filterTasks.ts, avec des tests sur des listes mixtes, vides et entièrement terminées. Le suivant raccorde un bouton accessible dans src/tasks/TaskList.tsx, en respectant l’interface convenue pour la fonction et en testant le résultat visible.

Le plan précise les fichiers, les interfaces, les assertions de test, les commandes de test du projet et les résultats attendus. Il indique aussi que le filtrage doit préserver la collection de tâches sous-jacente. L’utilisateur relit le plan et confirme le recours aux sous-agents. C’est à ce stade qu’une consigne vague devient assez précise pour qu’un développeur et un relecteur puissent discuter d’un point concret. Instructions de rédaction des plans

Préparer l’espace de travail avec using-git-worktrees

Au démarrage de l’exécution, Claude vérifie si le travail est déjà isolé. Un worktree Git est un autre répertoire de travail du dépôt, généralement associé à sa propre branche. Le skill privilégie le mécanisme natif de worktree de l’outil hôte et respecte les préférences déjà exprimées par l’utilisateur ; à défaut, il demande son accord avant d’en créer un.

Dans cet exemple, l’utilisateur accepte un worktree consacré à la fonctionnalité. Claude y lance les tests existants du projet avant de modifier l’application. Si cet état initial échoue aux tests, il faut s’en occuper avant d’attribuer d’éventuels échecs ultérieurs au nouveau bouton. Instructions sur l’espace de travail

Implémenter avec subagent-driven-development et test-driven-development

L’agent coordinateur confie le filtrage à un nouvel agent d’implémentation, puis organise la revue de cette tâche. Une fois cette étape passée, il enchaîne avec l’interface. Le skill de développement par sous-agents actuel vérifie la conformité à la spécification et la qualité du code lors de la revue de chaque tâche, puis exige une revue plus large de la branche terminée. Il consigne également l’avancement et les décisions dans un journal propre au plan. Workflow par sous-agents

Pendant l’implémentation, test-driven-development impose le cycle rouge-vert-refactorisation. Ici, un test montre d’abord que la demande d’une vue filtrée renvoie encore une tâche terminée. Ce n’est qu’après avoir constaté cet échec que l’agent ajoute le filtrage, relance le test, puis nettoie le code en maintenant les tests au vert. Instructions TDD

Pour l’interface, l’assertion utile porte sur ce que voit l’utilisateur après avoir actionné le bouton. Un test qui vérifie uniquement l’appel d’une fonction ne démontre pas le comportement visible de la fonctionnalité.

L’autre voie est executing-plans : Claude implémente lui-même le plan dans la session en cours, avec un nouveau relecteur chargé de l’ensemble de la branche à la fin lorsque les sous-agents sont disponibles. Choisissez cette voie si les transmissions et revues tâche par tâche ne correspondent pas à votre besoin. Instructions d’exécution dans la session

Traiter les retours avec les skills de revue et systematic-debugging

Lors de la revue finale de la branche, requesting-code-review prépare la transmission au relecteur. Supposons que celui-ci constate que désactiver le bouton ne fait pas réapparaître les tâches terminées. receiving-code-review demande de confronter ce constat au code et au comportement attendu avant toute modification. Demander une revue, traiter les retours

Si l’échec est reproductible, systematic-debugging guide l’enquête. Ses phases enchaînent recherche de la cause racine, analyse des schémas récurrents, mise à l’épreuve des hypothèses et implémentation. Dans cet exemple, l’hypothèse pourrait être que le code a remplacé la collection d’origine par la collection filtrée. Examinez ce flux de données, reproduisez la perte et corrigez la cause avec un test de non-régression. Ne vous contentez pas de forcer l’apparence du bouton pour qu’elle semble correcte. Instructions de débogage

Prouver que le travail est terminé et choisir la fusion

verification-before-completion exige de nouveaux résultats de commandes avant toute annonce de réussite. Pour cette fonctionnalité, il faut donc des preuves concernant le filtrage, l’interaction avec le bouton et les contrôles pertinents du projet, en signalant clairement les échecs non résolus. Instructions de vérification

Ensuite, finishing-a-development-branch vérifie la suite de tests complète et présente les choix d’intégration. Sur une branche nommée classique, le fichier actuel propose une fusion locale, un push accompagné de la création d’une pull request, ou la conservation de la branche. Il attend la décision de l’utilisateur : une revue concluante ne vaut pas autorisation implicite de fusionner.

Pour terminer cet exemple, l’utilisateur choisit une fusion locale dans la branche de base confirmée. Claude effectue la fusion, teste le résultat, puis ne supprime le worktree et la branche de fonctionnalité qu’après la réussite de ces tests. La création d’une pull request laisserait, elle, le travail en attente du processus de fusion du dépôt. Instructions de finalisation

Quand une petite tâche mérite-t-elle un parcours allégé ?

La méthode devient une charge lorsqu’elle redemande des décisions que la demande a déjà tranchées. Renommer un libellé visible à partir d’un texte de remplacement exact ne devrait pas exiger la même préparation qu’une modification du stockage de l’état des tâches. Ce constat porte sur le travail ajouté par le workflow, pas sur un gain de temps mesuré.

Le fichier brainstorming actuel distingue trois niveaux :

• Tâche rapide et claire : la demande contient déjà la description nécessaire ; exécutez-la.
• Petite modification : convenez de la description dans la conversation, puis passez à la réalisation avec le workflow habituel.
• Projet : faites approuver une conception écrite, puis produisez un plan complet d’implémentation logicielle.

Ce même fichier permet à l’utilisateur de refuser explicitement les questions, ce qui met fin à cette étape de validation du brainstorming. Ce choix n’annule pas automatiquement les autres instructions de test ou de vérification. Règles d’adaptation à la tâche et de refus des questions

Une consigne utile serait : « C’est une petite modification. Garde la description dans la conversation, utilise le dispositif de test existant et n’élargis pas la fonctionnalité. » Pour une correction de texte déjà décidée, donnez le texte exact et le périmètre. Ce sont des contraintes de tâche reconnues par la hiérarchie d’instructions du plugin, pas des commandes secrètes de contournement.

La limite identifiée est la lourdeur du processus : les échanges supplémentaires, les documents de planification, les délégations et les revues peuvent être disproportionnés par rapport aux incertitudes restantes. Le code source documente ces étapes ; il ne dit pas combien de minutes prendra votre modification. Si la session ignore régulièrement son périmètre, le dépôt propose diagnosing-superpowers pour examiner ce qui s’est passé à partir des transcriptions. Skill de diagnostic des sessions

Quelles promesses de Superpowers faut-il relativiser ?

Un workflow prescrit ne prouve ni la fiabilité du logiciel ni un gain de vitesse. Un test qui échoue peut traduire une exigence erronée, un plan peut oublier une contrainte d’intégration et un agent relecteur peut laisser passer un défaut. Évaluez les assertions et le diff, plutôt que l’assurance du message de fin.

Le recours aux sous-agents ne signifie pas non plus que toutes les tâches d’implémentation s’exécutent en parallèle. Le skill actuel interdit explicitement d’exécuter simultanément plusieurs sous-agents d’implémentation dans ce workflow, afin d’éviter les conflits. dispatching-parallel-agents est un skill distinct, destiné aux problèmes indépendants. Règles de délégation de l’implémentation

L’installation ne vous décharge pas davantage de la définition du périmètre ou de l’intégration. La procédure de finalisation du plugin laisse la décision de fusion à l’utilisateur. Sa promesse la plus solide est méthodologique : il indique à Claude les points à vérifier et les preuves à présenter. Son utilité dépend du travail à accomplir et du respect de ces consignes par l’agent.

À qui s’adresse Superpowers et par quoi commencer ?

Installez-le si votre problème récurrent est un agent qui saute des décisions d’ingénierie. Si vous développez en solo et que votre agent passe trop vite sur les exigences, commencez par une fonctionnalité délimitée comportant un cas d’échec significatif. Vérifiez que la session établit le comportement attendu avant l’implémentation et fournit des preuves ensuite.

Dans une équipe de développement déjà structurée, commencez par accorder vos conventions de planification, de test et de revue avec les instructions du plugin. Si vos skills existants décrivent déjà le processus souhaité, un workflow général supplémentaire risque de faire doublon. Si vos tâches sont surtout des retouches minimes et entièrement spécifiées, il y a moins de raisons d’adopter toute la méthode pour les réaliser.

Lundi, choisissez une modification bien circonscrite et notez ses critères d’acceptation. Utilisez Superpowers, examinez les skills choisis, relisez le diff final et demandez-vous si chaque document ou résultat supplémentaire vous a aidé à décider. Gardez le workflow pour l’utilité de ses contrôles, pas pour la longueur du plan produit.

Pour découvrir des outils complémentaires qui répondent à d’autres besoins, consultez les meilleurs plugins Claude Code.

Questions fréquentes sur Claude Superpowers

Pour des conseils pratiques sur le développement avec l’IA, abonnez-vous à la newsletter.