Édition Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Utiliser Superpowers dans Claude Code pour planifier, tester et examiner une modification du code

> Un guide fondé sur la documentation pour mener une modification autorisée depuis une conception et un plan Superpowers approuvés jusqu’aux tests rouge-vert observés, aux revues des tâches et de la branche, puis à la décision du responsable.

By BIG CHANGE Editorial

Published: 2026-10-20T10:39:38.153Z
Updated: 2026-10-20T10:39:38.153Z
Canonical: https://bigchange.ai/blog/superpowers-claude-code-plan-test-review-change-guide

![Conceptual charcoal illustration of a long, unlettered code-diff proof sheet emerging from a printer across an inspection table, with a short orange passage.](https://bigchange.ai/api/media/file/superpowers-whole-branch-proof-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE.

Superpowers peut guider un utilisateur de Claude Code dans une modification importante d’un dépôt Git qu’il gère : convenir de la conception, approuver un plan de tâches, réaliser avec des tests, examiner chaque tâche et inspecter la branche finale. Ce guide suit les manuels officiels de Superpowers 7.0.0 consultés le 20 octobre 2026. BIG CHANGE a examiné la documentation ; nous n’avons ni installé le plugin ni exécuté ce processus sur un projet.

## Le grand changement

- **Ce qui change :** Une conception et un plan de réalisation approuvés donnent aux agents de programmation une tâche précise et des contraintes avant toute modification du dépôt.
- **Pourquoi cela compte :** Le processus documenté associe des tests dont l’échec puis la réussite sont observés aux verdicts distincts d’un même évaluateur sur la conformité et la qualité, puis à une revue plus large de toute la branche.
- **Points à surveiller :** Le responsable vérifie toujours le diff complet et les résultats récents des contrôles d’acceptation, puis décide du sort de la branche. Un processus agent terminé peut conserver des problèmes signalés.

## Avant de commencer

Choisissez une modification autorisée en plusieurs étapes dans un dépôt que vous gérez ou pouvez modifier. Elle doit se diviser en tâches vérifiables et avoir un comportement testable. Notez le comportement demandé, la zone concernée, les exclusions, la commande d’acceptation initiale et le commit de départ. Exécutez cette commande et les contrôles existants pertinents avant de commencer. Si l’état initial échoue déjà, identifiez cette défaillance maintenant : un résultat rouge ou vert ultérieur exige un point de départ connu.

Il vous faut Git, une installation authentifiée de Claude Code, l’autorisation d’installer des plugins et de créer une branche ou un worktree, ainsi qu’une capacité suffisante dans votre forfait ou API pour Claude Code et ses sous-agents. Vérifiez les règles de votre organisation concernant l’accès au code source et les plugins. Examinez le contenu du plugin, ses autorisations effectives, les conditions de traitement des données du fournisseur et les contrôles de dépenses avant de l’activer. Anthropic avertit que les hooks et processus serveur des plugins peuvent s’exécuter avec vos privilèges utilisateur en dehors du bac à sable des appels d’outils ; les demandes ordinaires d’autorisation des outils ne couvrent pas tout ce code. Limitez les secrets, dépendances, écritures externes, envois et mises en production aux pouvoirs dont vous disposez réellement. [La documentation de sécurité des plugins Claude Code](https://code.claude.com/docs/en/plugins/security) explique cette limite.

Le parcours ci-dessous utilise la compétence Superpowers `subagent-driven-development` pour une modification comprenant plusieurs tâches. Les manuels décrivent aussi un parcours intégré `executing-plans` et autorisent un accord de conception simplifié pour les petits travaux. Choisissez le parcours avec le responsable avant la réalisation, plutôt que de supposer que tout projet doit suivre la séquence entière.

## 1. Installer le plugin et vérifier la version active

Dans une session interactive de Claude Code, saisissez la [commande du catalogue officiel](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/README.md) :

```text
/plugin install superpowers@claude-plugins-official
```

Claude Code ouvre un panneau de détails du plugin avant l’installation. Inspectez son contenu et choisissez une portée autorisée. La portée locale l’active pour vous dans ce dépôt ; la portée projet affecte les paramètres du dépôt des collaborateurs. Lisez le résumé d’installation et l’onglet Errors. Suivez les consignes d’activation de la session ou redémarrez, puis consultez l’onglet Installed et exécutez `claude plugin list` dans un terminal. Notez les valeurs affichées de Version, Scope et Status, et confirmez que les compétences Superpowers sont disponibles dans la session active. La commande du catalogue ne fixe pas le commit de référence de ce guide. Si la version ou le texte des compétences installées diffère de 7.0.0, adaptez la procédure à cette version avant de poursuivre. Une installation en échec ou désactivée impose un arrêt ; elle ne prouve pas que le processus est chargé. [Le guide d’installation de Claude Code](https://code.claude.com/docs/en/discover-plugins) décrit ces vérifications.

## 2. Approuver la conception, puis le plan

Donnez à Claude Code la modification réelle, les critères d’acceptation, le résultat initial et les modifications interdites. Utilisez le processus Superpowers `brainstorming` pour préciser l’intention, les choix de conception et les contraintes. Pour cette modification en plusieurs étapes, examinez la conception écrite et les conclusions du contrôle de réalisation, résolvez les questions qui relèvent du responsable et approuvez la description complète. L’approbation doit décrire le comportement à construire ; elle ne doit pas être déduite du simple fait que l’agent continue à parler. Le [manuel de conception](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/brainstorming/SKILL.md) autorise un accord plus léger ou une dérogation explicite pour les petits travaux : ici, le parcours complet est un choix délibéré pour une tâche importante.

Demandez ensuite au processus `writing-plans` de transformer cette conception en tâches. Examinez les limites de fichiers, interfaces, contraintes globales, commandes de test et Review Focus du plan. Chaque tâche doit être assez petite pour être inspectée, et son test doit mesurer le comportement convenu. Approuvez le plan et l’exécution par sous-agents avant toute modification du code. [Le manuel de planification](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/writing-plans/SKILL.md) définit la transmission. Un plan plausible n’autorise pas à ajouter des dépendances ni à modifier des fichiers sans rapport.

Au moment de l’exécution, `using-git-worktrees` vérifie la présence d’un espace de travail existant approprié ou en prépare un isolé avec le consentement nécessaire. Notez sa branche réelle, son commit de base et son état initial propre. Utilisez le support natif des worktrees de Claude Code lorsqu’il est disponible. Si l’espace contient des modifications étrangères, clarifiez leur propriété avant de continuer. [Le manuel des worktrees](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/using-git-worktrees/SKILL.md) décrit les vérifications et la création.

## 3. Observer chaque test et chaque revue de tâche

Une fois le plan approuvé, utilisez `subagent-driven-development` pour des tâches vérifiables séparément. Le manuel actuel confie une tâche à un exécutant, puis transmet sa réalisation et son diff à **un seul évaluateur de tâche**. Celui-ci rend deux jugements : la conformité de la tâche à la spécification et l’acceptabilité de la qualité de réalisation. Il s’agit de deux verdicts issus d’une seule revue, pas de deux agents évaluateurs successifs. De petites tâches de même forme peuvent être regroupées selon les règles du manuel. [Le processus des tâches](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/subagent-driven-development/SKILL.md) et le [prompt de l’évaluateur](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/subagent-driven-development/task-reviewer-prompt.md) établissent cette séquence.

Pour chaque comportement adapté aux tests d’abord, exigez un cycle rouge-vert observable : ajoutez le test comportemental, exécutez-le et constatez l’échec attendu ; réalisez la plus petite implémentation, relancez-le et constatez sa réussite ; puis remaniez le code en maintenant les contrôles au vert. Une erreur d’importation ou un dispositif de test défectueux n’est pas le résultat rouge attendu. Conservez la commande, la sortie et le commit ou diff pertinent de chaque tâche. Le [manuel du développement piloté par les tests](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/test-driven-development/SKILL.md) décrit les exceptions nécessitant un accord humain ; ce guide suppose une tâche adaptée au parcours habituel avec test préalable.

Lisez les deux verdicts et le diff réel. Résolvez chaque point « impossible à vérifier à partir du diff » en consultant le plan et le dépôt avant d’accepter la tâche. Inspectez les corrections et leur nouvelle revue ciblée ; une nouvelle affirmation de réussite n’est pas un résultat de test récent. Le processus 7.0.0 limite sa boucle de correction et peut mettre des problèmes en attente avec des décisions écrites. Conservez-les pour la revue ultérieure. Une tâche déclarée terminée n’a pas nécessairement une revue sans réserve.

Après les tâches, examinez la **revue distincte de toute la branche**. Elle peut déceler des interactions entre tâches et réexaminer les points différés qu’un évaluateur de tâche ne pouvait trancher à partir d’un seul diff. Demandez les preuves et la décision justifiant chaque problème ouvert. Conservez conception, plan, sorties de tests, rapports de revue et diff complet avant le nettoyage de l’espace temporaire du plugin. Si une compétence attendue ne s’est pas déclenchée, vérifiez le statut et la version du plugin actif ainsi que le diagnostic documenté ; l’installation du plugin ne prouve pas que le processus a été appliqué.

## 4. Vérifier la branche et décider de son sort

Exécutez à nouveau la commande d’acceptation initiale sur le code final, ainsi que toute la suite de tests du projet. Examinez les nouvelles sorties, le diff complet de la branche et tous les problèmes en suspens. [Le manuel de vérification de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/verification-before-completion/SKILL.md) exige des preuves de l’état actuel avant de déclarer le travail terminé. Si la suite échoue, identifiez l’erreur précise et corrigez-la ou laissez la branche en revue ; le menu documenté de finalisation n’est pas atteint lorsque la suite échoue.

Sur une branche nommée, `finishing-a-development-branch` propose une fusion locale, un envoi avec création d’une pull request, ou le maintien de la branche en l’état. Un HEAD détaché offre les choix pull request et conservation. L’abandon n’intervient qu’après une demande explicite du responsable et une confirmation saisie ; ce n’est pas une quatrième option ordinaire. [Le manuel de finalisation de branche](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/finishing-a-development-branch/SKILL.md) expose ces choix. Présentez au responsable les contrôles, le diff et les réserves restantes avant sa décision. Une fusion, un envoi, une suppression ou une mise en production exige l’autorité correspondant à l’action.

Le résultat utile est une branche vérifiable liée au besoin initial : conception et plan approuvés, résultats de tests observés, deux verdicts de revue de tâche, revue de toute la branche, diff complet et résultat d’acceptation récent. Si l’installation, l’accès, le budget ou un contrôle arrête l’exécution, gardez les éléments vérifiés et indiquez la dernière étape achevée. La documentation décrit un processus ; elle ne prouve pas que la modification non exécutée de ce guide ait été plus rapide, moins chère ou moins défectueuse.

## Sources et lectures complémentaires

- [Superpowers 7.0.0 : README et installation](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/README.md) : parcours officiel du projet et description du processus. Ne vérifie ni la version installée du lecteur ni ses résultats.
- [Manuel d’exécution des tâches Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/subagent-driven-development/SKILL.md) : évaluateur de tâche, deux verdicts, décisions de correction et revue finale de branche. À lire avec la version réellement installée.
- [Installation des plugins Claude Code](https://code.claude.com/docs/en/discover-plugins) et [sécurité](https://code.claude.com/docs/en/plugins/security) : portée, activation, vérification de version et privilèges d’exécution. Les contrôles de l’organisation peuvent modifier les possibilités.

Pour corriger un seul contrôle d’acceptation, consultez le [guide BIG CHANGE de vérification d’un contrôle de dépôt en échec](https://bigchange.ai/blog/ai-goal-failing-repository-check-guide). Le processus présenté ici commence plus tôt, avec la conception et le plan d’une modification comprenant plusieurs tâches.

## Sources

- [README de Superpowers en version 7.0.0](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/README.md) — Commande du catalogue officiel et processus général du projet. C’est une référence fixe, pas la preuve que le catalogue a installé ce commit exact ni que le processus a été exécuté.
- [Compétence brainstorming de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/brainstorming/SKILL.md) — Décrit les questions de conception, le contrôle de réalisation et l’approbation humaine ; les petites tâches peuvent suivre un parcours plus léger.
- [Compétence writing-plans de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/writing-plans/SKILL.md) — Décrit la structure du plan et sa transmission pour revue. Cela ne signifie pas qu’un plan a été approuvé pour un projet non exécuté.
- [Compétence using-git-worktrees de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/using-git-worktrees/SKILL.md) — Décrit la sélection d’un espace existant ou isolé, le consentement et les contrôles initiaux ; aucun worktree n’a été créé pour cet article.
- [Compétence subagent-driven-development et évaluateur de tâche Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/subagent-driven-development/SKILL.md) — Établit un évaluateur de tâche rendant des verdicts de conformité et de qualité, des boucles de correction limitées, des réserves différées et une revue distincte de toute la branche. La fin du travail peut inclure des points non résolus ayant fait l’objet d’une décision.
- [Compétence test-driven-development de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/test-driven-development/SKILL.md) — Décrit le cycle attendu rouge-vert-remaniement et les exceptions convenues avec un humain. Aucun test n’a été exécuté pour cet article.
- [Compétence verification-before-completion de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/verification-before-completion/SKILL.md) — Exige des preuves récentes issues de commandes réelles avant d’affirmer la fin du travail ; ne peut établir les résultats de ce guide.
- [Compétence finishing-a-development-branch de Superpowers](https://github.com/obra/superpowers/blob/bb92a77741419a4ab5f06e711a283343f1ada0c3/skills/finishing-a-development-branch/SKILL.md) — Décrit les options des branches nommées et détachées, ainsi que l’abandon demandé séparément et confirmé par saisie. L’autorité du responsable reste nécessaire.
- [Installer et gérer les plugins — Claude Code Docs](https://code.claude.com/docs/en/discover-plugins) — Panneau d’installation actuel, portées, activation, onglet Installed et lecture Version/Scope/Status en ligne de commande ; la politique locale peut modifier la disponibilité réelle.
- [Sécurité des plugins — Claude Code Docs](https://code.claude.com/docs/en/plugins/security) — Explique que les hooks et processus serveur des plugins peuvent s’exécuter avec les privilèges utilisateur hors des demandes du bac à sable des appels d’outils ; les utilisateurs doivent examiner l’accès local.