subagent-driven-development

Vue d’ensemble

Qu’est-ce que subagent-driven-development ?

subagent-driven-development est une compétence d’orchestration d’agents qui permet d’exécuter un plan d’implémentation sous forme de séquence de tâches indépendantes, chacune prise en charge par un nouveau sous‑agent. Pour chaque tâche, vous :

1. Démarrez un sous‑agent implémenteur dédié.
2. Lancez un sous‑agent de revue de conformité à la spec.
3. Lancez un sous‑agent de revue de qualité de code.

Les trois sont maintenus dans un contexte strictement contrôlé, de sorte qu’ils se concentrent uniquement sur la tâche en cours, tandis que votre session principale reste disponible pour la coordination et la prise de décision.

À qui s’adresse cette compétence ?

subagent-driven-development est conçu pour les développeurs et les équipes qui :

• Utilisent des assistants de codage IA (comme Claude / claude-code) et veulent des résultats plus fiables.
• Travaillent à partir d’un plan d’implémentation écrit, découpé en tâches distinctes.
• Ont besoin d’un processus structuré et reproductible pour faire implémenter et relire du code dans une seule session IA.
• Se soucient à la fois de la conformité à la spec et de la qualité du code, pas seulement d’« un truc qui marche ».

Cette approche s’intègre particulièrement bien aux workflows centrés sur GitHub, où vous pouvez transmettre des SHAs, des fichiers de plan et des diffs aux sous‑agents.

Quels problèmes cela résout-il ?

Cette compétence traite des problèmes fréquents lorsque l’on utilise un seul agent IA pour un développement de bout en bout :

• Gonflement du contexte : Un agent accumule trop d’historique et perd en focalisation.
• Dérive de la spec : Les implémentations s’éloignent progressivement du plan ou des exigences d’origine.
• Revues faibles : Le même contexte qui a écrit le code tente de le relire, ce qui masque des erreurs.

subagent-driven-development impose un schéma : un agent neuf par tâche, un contexte strict, et une revue en deux étapes (spec puis qualité). Cela améliore la justesse, limite la portée des changements et facilite le raisonnement sur chaque étape de votre plan d’implémentation.

Quand subagent-driven-development est-il adapté ?

Utilisez cette compétence lorsque :

• Vous disposez déjà d’un plan d’implémentation découpé en tâches.
• Les tâches sont majoritairement indépendantes – elles ne requièrent pas une coordination constante entre elles.
• Vous prévoyez d’exécuter le plan dans la session en cours, sans l’étaler sur plusieurs jours.

Si vous n’avez pas encore de plan, ou si les tâches sont fortement couplées et évoluent rapidement, il peut être préférable de :

• Concevoir ou affiner le plan d’abord, avec d’autres compétences ou une planification manuelle.
• Utiliser un workflow plus libre, avec un agent unique, pour le travail exploratoire.

Guide d’utilisation

Installation

1. Ajouter la compétence à votre environnement

Installez la compétence subagent-driven-development depuis le dépôt obra/superpowers :

npx skills add https://github.com/obra/superpowers --skill subagent-driven-development

Cette commande récupère la définition de la compétence et les modèles de prompts associés dans votre environnement compatible skills, afin que vous puissiez orchestrer des sous‑agents pour chaque tâche de votre plan.

2. Examiner les fichiers principaux

Après l’installation, ouvrez le répertoire de la compétence dans le dépôt (ou via votre navigateur de skills) et consultez :

• SKILL.md – description générale, cas d’usage et workflow principal.
• implementer-prompt.md – modèle pour votre sous‑agent implémenteur.
• spec-reviewer-prompt.md – modèle pour votre sous‑agent de revue de conformité à la spec.
• code-quality-reviewer-prompt.md – modèle pour votre sous‑agent de revue de qualité de code.

Considérez ces fichiers comme des modèles à copier ou à adapter dans vos propres automatisations ou circuits d’outillage.

Préparer votre plan d’implémentation

1. Rédiger ou affiner votre liste de tâches

Avant d’utiliser subagent-driven-development, préparez un plan d’implémentation avec des tâches :

• Nettement délimitées et testables.
• Largement indépendantes les unes des autres.
• Décrites avec suffisamment de détails pour qu’un sous‑agent implémenteur puisse agir sans deviner.

Chaque tâche doit pouvoir être copiée‑collée dans le prompt de l’implémenteur en tant que « FULL TEXT of task from plan ».

2. Définir votre répertoire de travail et votre stratégie Git

Les modèles de prompt présupposent un workflow basé sur Git et un répertoire de travail concret :

• Choisissez un directory où l’implémenteur travaillera.
• Décidez comment vous suivrez les changements (par exemple, BASE_SHA et HEAD_SHA pour chaque tâche).

Vous transmettrez ces valeurs aux prompts de revue de spec et de qualité de code pour obtenir des revues précises.

Exécuter le workflow tâche par tâche

1. Lancer un sous‑agent implémenteur

Pour chaque tâche N, créez un nouveau sous‑agent implémenteur à partir du modèle dans implementer-prompt.md.

Points clés issus du modèle :

• On indique explicitement à l’implémenteur : “You are implementing Task N: [task name]”.
• Vous collez le texte complet de la tâche dans la section ## Task Description.
• Vous renseignez :
  • Context – la place de cette tâche dans votre système.
  • directory – l’emplacement où effectuer les changements.

L’implémenteur est instruit de :

1. Poser des questions de clarification avant de commencer si quelque chose n’est pas clair.
2. Implémenter exactement ce qui est spécifié dans la tâche.
3. Écrire et exécuter des tests lorsque c’est pertinent.
4. Vérifier l’implémentation.
5. Committer le travail.
6. Produire un rapport clair de ce qui a été réalisé.

Comme vous créez un nouveau sous‑agent pour chaque tâche, il ne voit que le contexte que vous fournissez et n’hérite pas de l’historique sans lien avec votre session principale.

2. Lancer une revue de conformité à la spec

Une fois l’implémenteur terminé et son rapport fourni, lancez un sous‑agent spec compliance reviewer à l’aide de spec-reviewer-prompt.md.

Dans ce modèle, vous :

• Collez les exigences de la tâche dans ## What Was Requested.
• Collez le rapport de l’implémenteur dans ## What Implementer Claims They Built.

Le reviewer de spec reçoit pour consigne explicite de ne pas faire confiance au rapport de l’implémenteur et doit :

• Lire le code réel.
• Le comparer ligne par ligne aux exigences.
• Identifier les exigences manquantes, le travail en trop ou non souhaité, et les mauvaises interprétations.

Si le reviewer de spec trouve des problèmes, vous revenez vers l’implémenteur (le même ou un nouveau sous‑agent) pour corriger les écarts avant de passer à la suite.

3. Lancer une revue de qualité de code

Une fois la conformité à la spec validée, lancez un sous‑agent code quality reviewer à l’aide de code-quality-reviewer-prompt.md.

Le modèle attend une description de tâche de type revue de code, par exemple :

Task tool (superpowers:code-reviewer):
  Use template at requesting-code-review/code-reviewer.md

  WHAT_WAS_IMPLEMENTED: [from implementer's report]
  PLAN_OR_REQUIREMENTS: Task N from [plan-file]
  BASE_SHA: [commit before task]
  HEAD_SHA: [current commit]
  DESCRIPTION: [task summary]

Le reviewer vérifie :

• La propreté et la maintenabilité de l’implémentation.
• La répartition des responsabilités et les interfaces des fichiers (une responsabilité claire par fichier autant que possible).
• Si les fichiers nouveaux ou modifiés ont une taille et une décomposition appropriées.
• La couverture de tests et la capacité à comprendre et tester les unités de manière indépendante.

Il renvoie un feedback structuré : points forts, problèmes (Critical / Important / Minor) et une évaluation globale.

Vous pouvez ensuite décider :

• D’accepter le changement tel quel.
• De demander à l’implémenteur d’effectuer des refactorings complémentaires.

Adapter le workflow à votre environnement

1. Personnaliser les prompts pour votre stack

Les modèles dans implementer-prompt.md, spec-reviewer-prompt.md et code-quality-reviewer-prompt.md sont volontairement génériques. Adaptez‑les à vos :

• Langages et frameworks.
• Conventions de test (par exemple, pytest, Jest, Go test).
• Organisation et nomenclature de dépôt.

Conservez la structure de base — sous‑agent neuf, sections claires, description explicite de la mission — même en personnalisant les détails.

2. Automatiser les étapes répétitives

Une fois à l’aise avec ce schéma, vous pouvez le scripter ou l’outiller :

• Regroupez les trois appels de sous‑agents (implémenteur → reviewer de spec → reviewer de qualité) dans une seule commande par tâche.
• Générez automatiquement des prompts spécifiques à chaque tâche à partir d’un fichier de plan.
• Pré‑remplissez BASE_SHA et HEAD_SHA en lisant les métadonnées Git.

Vous transformez ainsi subagent-driven-development en workflow automatisé, reproductible pour votre équipe.

3. Quand cette compétence n’est-elle pas adaptée ?

Vous pouvez préférer une autre approche lorsque :

• Les tâches sont fortement interdépendantes et ne peuvent pas être isolées proprement.
• Vous n’avez pas encore de plan d’implémentation clair.
• Vous avez besoin de travaux de longue durée, multi‑sessions, où le contexte doit persister sur plusieurs jours.

Dans ces cas, utilisez des compétences ou des processus axés sur la planification, l’architecture ou des agents de long terme, puis revenez à subagent-driven-development lorsque vous êtes prêt à exécuter des tâches bien délimitées.

FAQ

Que signifie « subagent-driven-development » en pratique ?

Concrètement, subagent-driven-development signifie que vous ne demandez pas à un agent « tout‑en‑un » de tout planifier, coder et relire. À la place, vous :

• Conservez la coordination et le contexte global dans votre session principale.
• Pour chaque tâche, construisez un nouveau sous‑agent avec uniquement les informations dont il a besoin.
• Exécutez ce sous‑agent pour implémenter la tâche, puis deux autres sous‑agents pour la relire.

Cela sépare les responsabilités, maintient un contexte gérable et améliore la fiabilité à chaque étape de votre plan d’implémentation.

En quoi est-ce différent d’une session de codage classique avec un seul agent ?

Avec un agent unique, l’historique de conversation et les modifications de code s’accumulent dans un même contexte, ce qui peut entraîner :

• De la confusion entre anciennes et nouvelles exigences.
• La réutilisation des mêmes schémas de raisonnement pour coder et pour relire.

subagent-driven-development, au contraire :

• Utilise des prompts et des rôles distincts pour l’implémentation et la revue.
• Démarre chaque sous‑agent avec un contexte sélectionné, pas tout l’historique de la session.
• Imposent un ordre de revue d’abord la spec, puis la qualité.

Cela tend à produire des implémentations plus précises et des revues plus objectives.

Dois-je suivre les modèles exactement ?

Non. Les modèles du dépôt sont des exemples de structuration des prompts d’implémenteur, de reviewer de spec et de reviewer de qualité de code. Vous êtes censé :

• Conserver le schéma global : implémenteur → revue de spec → revue de qualité.
• Préserver les comportements clés (par exemple, le reviewer de spec doit lire le vrai code et ne pas se fier au seul rapport).

Dans ce cadre, vous pouvez ajuster le wording, ajouter des consignes spécifiques à votre projet et intégrer vos outils et conventions.

Puis-je utiliser subagent-driven-development sans Git ?

Le modèle de reviewer de qualité de code suppose des champs comme BASE_SHA et HEAD_SHA, qui sont naturels dans un workflow Git. Si vous n’utilisez pas Git :

• Vous pouvez malgré tout appliquer les mêmes idées clés — sous‑agents neufs et revue en deux étapes.
• Remplacez les SHAs par votre propre façon de référencer l’état avant/après (par exemple, des identifiants d’archive ou des chemins de snapshots).

La compétence n’impose pas Git en soi ; elle fournit des exemples orientés Git.

Cette compétence dépend‑elle d’un modèle d’IA spécifique ?

Le dépôt ne vous enferme pas dans un modèle particulier, mais il cible clairement des modèles de codage généralistes récents comme Claude / claude-code d’Anthropic. Vous devez :

• Utiliser un modèle capable de lire et raisonner sur du code et des tests.
• Vérifier que votre environnement permet de lancer plusieurs sous‑agents avec des prompts personnalisés.

Si votre stack prend en charge des outils d’agents ou des task runners, vous pouvez y raccorder ces modèles de prompts.

Comment savoir quand utiliser subagent-driven-development plutôt qu’une autre compétence superpowers ?

Le fichier SKILL.md décrit des critères de décision : utilisez subagent-driven-development lorsque vous disposez d’un plan d’implémentation, que vos tâches sont majoritairement indépendantes, et que vous prévoyez de rester dans la session en cours. Si l’un de ces points n’est pas vrai, vous pouvez :

• Utiliser d’abord des compétences de planification ou de brainstorming pour créer le plan.
• Recourir à d’autres patterns d’exécution ou de planification pour un travail fortement couplé et multi‑sessions.

Par où commencer dans le dépôt ?

Si vous évaluez l’intérêt d’installer ou d’adopter cette compétence, commencez par :

1. SKILL.md – pour la logique d’ensemble et le workflow haut niveau.
2. implementer-prompt.md – pour voir comment les sous‑agents implémenteurs sont cadrés.
3. spec-reviewer-prompt.md – pour comprendre les vérifications de conformité à la spec.
4. code-quality-reviewer-prompt.md – pour voir les contrôles supplémentaires de qualité et de structure.

À partir de là, vous pouvez adapter ces modèles à votre propre orchestration d’agents ou à votre système d’automatisation de workflows, et tirer pleinement parti de subagent-driven-development.