subagent-driven-development

Vue d’ensemble de la skill subagent-driven-development

Ce que fait réellement subagent-driven-development

La skill subagent-driven-development est un workflow conçu pour exécuter un plan d’implémentation en découpant le travail en tâches indépendantes, en confiant chaque tâche à un nouveau sous-agent, puis en relisant chaque résultat en deux passes : d’abord la conformité à la spec, ensuite la qualité du code. Sa vraie valeur n’est pas simplement de « faire appel à plus d’agents », mais d’utiliser volontairement un contexte isolé pour que chaque exécutant ne reçoive que la tâche, les exigences et le contexte de code local dont il a besoin.

Quand cette skill est la plus adaptée

Cette subagent-driven-development skill convient surtout aux personnes qui ont déjà un plan et doivent le transformer en implémentation fiable dans la session en cours. Elle est particulièrement adaptée lorsque :

• les tâches sont en grande partie indépendantes
• vous voulez que l’agent coordinateur reste concentré sur l’orchestration
• vous voulez détecter à la fois les écarts par rapport aux exigences et le code bâclé
• vous cherchez une boucle de revue reproductible, pas un simple prompt ponctuel de génération de code

Le besoin auquel elle répond

Les utilisateurs adoptent subagent-driven-development for Agent Orchestration lorsqu’un prompt classique du type « implémente ce plan » commence à échouer de manière prévisible : l’agent mélange les tâches, oublie des contraintes, surconstruit la solution ou produit un code plausible en apparence mais non conforme à la spec. Cette skill apporte un modèle de transmission et de revue discipliné qui réduit ces échecs.

Ce qui la distingue d’un prompt générique

Les différences clés sont très concrètes :

• Un nouveau sous-agent par tâche au lieu d’un seul agent longue durée qui traîne un historique devenu bruyant
• Des paquets de tâches explicites avec le texte complet de la tâche collé dans le prompt, au lieu de demander à l’exécutant de reconstituer les exigences à partir de fichiers dispersés
• Des questions obligatoires avant de coder pour faire remonter les zones floues le plus tôt possible
• Une revue en deux étapes où l’on sépare « est-ce conforme à la spec ? » de « est-ce du bon code ? »

Cette séparation compte. Beaucoup d’équipes évaluent la qualité avant de vérifier le périmètre, ce qui rend les implémentations trop larges ou incomplètes plus difficiles à repérer.

Quand ce n’est pas le bon choix

Ne démarrez pas avec subagent-driven-development si vous n’avez pas encore de plan d’implémentation concret, si les tâches sont fortement couplées, ou si le travail devrait plutôt partir dans un flux d’exécution parallèle distinct de cette session. Dans ces cas-là, il vaut généralement mieux commencer par une phase de planification ou choisir une autre skill d’exécution.

Comment utiliser la skill subagent-driven-development

Installer la skill subagent-driven-development

Si vous installez les skills de ce dépôt via le Skills CLI, utilisez :

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

Ensuite, ouvrez la skill installée ainsi que les templates de prompts associés avant votre premier lancement.

Commencez par lire ces fichiers

Pour une prise en main rapide, lisez les fichiers dans cet ordre :

1. SKILL.md
2. implementer-prompt.md
3. spec-reviewer-prompt.md
4. code-quality-reviewer-prompt.md

Cet ordre vous donne d’abord le workflow, puis la forme exacte des prompts pour l’implémenteur et pour les deux étapes de revue.

Comprendre le schéma d’appel avant de commencer

En pratique, subagent-driven-development usage n’est pas une commande magique unique. Vous l’utilisez en jouant le rôle de coordinateur :

1. prendre une tâche du plan
2. lancer un nouveau sous-agent implémenteur avec un prompt strictement cadré
3. exiger un retour de synthèse
4. exécuter un reviewer de spec sur le code réellement produit
5. seulement si la spec passe, exécuter un reviewer de qualité de code
6. accepter, demander une révision, ou relancer un sous-agent

Si vous sautez les étapes de revue, vous n’utilisez plus vraiment la skill telle qu’elle a été conçue.

Les entrées dont la skill a besoin

Préparez ces éléments avant d’envoyer une tâche à un sous-agent :

• le texte exact de la tâche issu de votre plan
• les critères d’acceptation ou les exigences
• le contexte d’architecture pertinent
• le répertoire de travail ou le périmètre du repo
• toute note sur les dépendances ou l’ordre d’exécution
• le commit de base ou le SHA servant de référence pour relire les diffs
• le numéro et le nom de la tâche pour la traçabilité

Les templates source suggèrent clairement qu’il faut coller la tâche complète dans le prompt, et non dire au sous-agent d’« aller lire le fichier de plan ».

Transformer un objectif flou en prompt d’implémenteur solide

Un prompt faible ressemble à ceci :

• « Implémente la tâche 4 du plan. »

Un prompt subagent-driven-development guide plus solide inclut :

• Le titre et le numéro de la tâche
• Le texte complet de la tâche
• Pourquoi cette tâche existe
• L’emplacement du repo où intervenir
• Les contraintes de structure de fichiers
• Si des tests sont requis
• Que faire si des hypothèses deviennent nécessaires
• L’obligation de poser des questions avant de coder

Cette structure est importante, car la skill repose sur un contexte contrôlé, pas sur une interprétation autonome de l’ensemble du repo.

Exemple de meilleur paquet de tâche

Utilisez une structure de ce type lorsque vous mandatez l’implémenteur :

• Task N: [name]
• FULL TEXT of task from plan
• Context: where this fits, dependencies, architecture
• Work from: [directory]
• Requirements: implement exactly what is specified
• If anything is unclear, ask before starting
• Write tests if required by task
• Commit, self-review, and report back

Cette approche est plus fiable que de demander à un exécutant d’explorer largement, car la skill part du principe que le coordinateur est responsable de bien empaqueter la mission.

Pourquoi la revue de spec passe avant la revue de qualité

C’est l’un des points les plus précieux dans une décision d’installation de subagent-driven-development install : l’ordre est volontaire.

Lancez d’abord le reviewer de spec pour répondre à ces questions :

• le code implémente-t-il bien ce qui a été demandé ?
• certaines exigences ont-elles été oubliées ?
• du travail non demandé a-t-il été ajouté ?
• la tâche a-t-elle été mal comprise ?

Ce n’est qu’ensuite qu’il faut lancer le reviewer de qualité de code, qui vérifie la maintenabilité, le découpage, la responsabilité des fichiers et la forme générale des changements. Si vous inversez l’ordre, du code bien présenté peut masquer des erreurs de périmètre.

Bien utiliser le reviewer de spec

Le template spec-reviewer-prompt.md est inhabituellement direct : il dit explicitement au reviewer de ne pas faire confiance au rapport de l’implémenteur et de vérifier le code réel ligne par ligne. Conservez cette tonalité lorsque vous l’adaptez. Le reviewer a besoin de :

• la totalité des exigences de la tâche
• la sortie revendiquée par l’implémenteur
• l’accès au code modifié

L’objectif est une vérification indépendante, pas une validation polie.

Bien utiliser le reviewer de qualité de code

La revue de qualité de code n’est pas un simple contrôle de style générique. Dans cette skill, elle met l’accent sur :

• une responsabilité claire par fichier
• des interfaces bien définies
• un découpage en unités compréhensibles
• l’alignement avec la structure de fichiers prévue
• le fait que cette tâche ait ou non créé de nouveaux fichiers trop volumineux ou alourdi excessivement des fichiers existants

Ce dernier point est utile, car les sous-agents résolvent souvent la tâche en entassant trop de choses dans un seul changement.

Workflow recommandé dans un vrai repo

En pratique, une boucle subagent-driven-development usage ressemble à ceci :

1. choisir la prochaine tâche indépendante
2. capturer le commit courant comme baseline
3. lancer l’implémenteur avec le texte complet de la tâche
4. récupérer son résumé et la liste des fichiers modifiés
5. exécuter la revue de spec sur les exigences et le code
6. si la spec échoue, renvoyer à l’implémenteur les écarts précis
7. si la spec passe, exécuter la revue de qualité de code
8. si la qualité échoue, demander une révision ciblée
9. fusionner ou passer à la tâche suivante

Cela permet au coordinateur de garder la main sur l’enchaînement et l’acceptation.

Contraintes qui influencent la qualité des résultats

La skill fonctionne mieux si vous respectez ses limites :

• les tâches indépendantes fonctionnent mieux que les tâches imbriquées
• les exigences explicites sont supérieures aux exigences déduites
• un périmètre repo étroit vaut mieux que « regarde autour de toi et décide »
• des boucles de tâches courtes valent mieux que de gros lots multi-fonctionnalités
• des règles d’escalade claires valent mieux que des suppositions silencieuses

Si vous avez besoin qu’un sous-agent réconcilie de nombreux éléments mouvants à l’échelle de toute la codebase, la tâche est probablement trop large pour ce workflow.

Erreur d’adoption fréquente

L’erreur la plus courante consiste à utiliser la subagent-driven-development skill comme simple étiquette tout en continuant à écrire des prompts flous. Le workflow n’apporte un vrai bénéfice que si vous structurez réellement le contexte avec soin et faites respecter la séquence de revue. Sinon, vous cumulez la surcharge d’orchestration sans obtenir les gains de qualité.

FAQ sur la skill subagent-driven-development

subagent-driven-development est-elle adaptée aux débutants ?

Oui, si vous comprenez déjà la tâche à construire. Le workflow est explicite et les templates de prompts fournis réduisent la part d’improvisation. En revanche, cela ne remplace pas la planification. Les débutants qui n’ont pas encore de plan d’implémentation clair risquent de peiner, car la skill suppose que les définitions de tâches existent déjà.

Quand ne faut-il pas utiliser subagent-driven-development ?

Évitez subagent-driven-development si :

• vous êtes encore en train d’explorer le problème
• les tâches sont fortement interdépendantes
• les exigences sont instables
• un humain ou un agent unique doit raisonner en continu à l’échelle de tout le système

C’est un schéma d’exécution, pas un schéma de découverte.

Quelle différence avec le fait de demander à un seul agent de tout coder ?

Un prompt unique et long mélange souvent planification, implémentation, validation et revue dans la même fenêtre de contexte. Cette skill sépare ces rôles. En général, cela améliore la concentration, facilite la détection des écarts aux exigences, et préserve le contexte du coordinateur pour l’orchestration plutôt que pour la génération de code.

La skill nécessite-t-elle des outils spécifiques ?

Aucun script particulier n’est inclus dans ce dossier de skill. Le dépôt fournit des templates de prompts en markdown plutôt que du code d’automatisation. Vous pouvez utiliser ce modèle partout où vous pouvez lancer des sous-agents et exécuter des tâches de revue de code.

subagent-driven-development est-elle réservée aux gros projets ?

Non. Elle peut aussi fonctionner pour de petits changements, mais elle devient surtout précieuse lorsqu’un plan contient plusieurs tâches indépendantes et que le coût d’exigences manquées est suffisamment élevé pour justifier la surcharge de revue.

Quels éléments du dépôt faut-il vérifier avant d’installer ?

Pour cette skill, les éléments les plus importants sont la conception du workflow dans SKILL.md et les trois templates de prompts. Il n’y a ni scripts auxiliaires ni dossiers de ressources qui feraient un travail caché en arrière-plan ; votre décision d’installation doit donc surtout reposer sur l’adéquation entre la structure des prompts, la discipline de revue, et votre manière réelle de livrer du code.

Comment améliorer la skill subagent-driven-development

Donnez de meilleurs paquets de tâches, pas des prompts plus longs

Pour améliorer les résultats de la subagent-driven-development skill, augmentez la précision plutôt que la longueur. Les ajouts les plus utiles sont :

• des critères d’acceptation exacts
• des non-objectifs explicites
• des notes d’architecture pertinentes pour cette tâche uniquement
• des limites claires de fichiers ou de répertoires
• des exemples du comportement attendu
• des attentes de test

Cela aide l’implémenteur à rester concentré et le reviewer de spec à détecter les écarts.

Rendez les frontières des tâches plus nettes

Beaucoup d’échecs viennent d’un découpage médiocre. Si un sous-agent doit à la fois coordonner plusieurs éléments mouvants, décider de l’architecture et déduire les exigences, découpez davantage la tâche. Les bonnes tâches sont assez étroites pour que « implémenté exactement comme demandé » soit facile à vérifier.

Conservez l’étape « poser des questions d’abord »

Le template de l’implémenteur indique explicitement au worker de poser des questions avant de commencer, puis à nouveau si des surprises apparaissent pendant l’implémentation. Conservez ce comportement. Bloquer les demandes de clarification produit un résultat rapide mais peu fiable, ce qui va à l’encontre de l’objectif de la skill.

Renforcez la qualité de revue avec de meilleurs points de comparaison

Pour le reviewer de spec, fournissez :

• le texte complet des exigences
• le rapport de l’implémenteur
• les fichiers modifiés ou le périmètre du diff
• toute exclusion explicite

Pour le reviewer de qualité de code, fournissez :

• BASE_SHA
• HEAD_SHA
• un résumé de la tâche
• la section pertinente du plan

Ces points d’ancrage concrets permettent à la revue d’aller au-delà d’une simple opinion.

Surveillez ces modes d’échec fréquents

Les problèmes les plus courants avec subagent-driven-development for Agent Orchestration sont :

• l’implémenteur déduit des fonctionnalités supplémentaires
• le paquet de tâche oublie une contrainte essentielle
• le reviewer fait trop confiance au résumé de l’implémenteur
• la revue de qualité de code passe avant la revue de spec
• les tâches sont trop larges pour être vérifiées proprement
• la croissance des fichiers n’est pas surveillée

Chacun de ces problèmes peut être évité avec un meilleur empaquetage des tâches et des garde-fous plus stricts.

Itérez après la première sortie

Si la première passe est faible, ne repartez pas immédiatement de zéro. Commencez par identifier la couche en échec :

• échec de spec : exigences floues, incomplètes ou sur-implémentées
• échec de qualité : problèmes de découpage, de maintenabilité ou de structure de fichiers
• échec de coordination : mauvais découpage des tâches ou mauvais empaquetage du contexte

Ensuite, ne révisez que cette couche. Cela rend le workflow plus efficace.

Précisez davantage les règles de structure de fichiers

Un détail utile du template de qualité consiste à vérifier si l’implémentation a bien respecté la structure de fichiers prévue et si les fichiers nouvellement créés sont déjà trop volumineux. Si la maintenabilité vous importe, indiquez dès le départ les frontières de fichiers attendues dans le paquet de tâche au lieu d’espérer que les reviewers le rattrapent plus tard.

Créez une checklist locale réutilisable

Si vous comptez utiliser subagent-driven-development régulièrement, gardez une courte checklist de coordinateur :

• le plan existe
• la tâche est indépendante
• la tâche complète est collée
• les contraintes sont incluses
• le SHA de baseline est capturé
• l’implémenteur a l’instruction de clarifier avant de coder
• la revue de spec est terminée
• la revue de qualité est terminée

Cette petite habitude améliore davantage la régularité que le fait d’écrire des prompts plus longs.

Faites évoluer la skill selon votre propre workflow

La skill de base est volontairement légère. Pour la rendre plus efficace dans votre environnement, adaptez les templates de prompts à votre stack et à vos standards de revue :

• ajoutez vos commandes de test
• ajoutez des règles d’architecture propres au repo
• définissez ce qui compte comme sur-ingénierie
• précisez votre format de rapport préféré
• incluez les modes d’échec fréquents dans votre codebase

Ce type d’adaptation locale améliore généralement davantage subagent-driven-development usage qu’un ajout de théorie supplémentaire.