Protocole de développement discipliné pour une tâche non triviale : brainstorm → spec → plan → implémentation incrémentale (pilotée par sous-agents) → TDD → revue → ship. À utiliser quand l'utilisateur veut "faire les choses dans l'ordre", "spec d'abord", "un plan avant de coder", "approche disciplinée/rigoureuse", "TDD", "revue avant merge", ou quand une tâche est assez grosse/risquée pour mériter un cadrage. Orchestrateur : il SÉQUENCE et DÉLÈGUE aux skills existants, il ne les refait pas. Inspiré d'obra/superpowers (design, pas d'import de code). NE PAS utiliser pour un correctif trivial en une étape (overkill).
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Protocole de développement discipliné pour une tâche non triviale : brainstorm → spec → plan → implémentation incrémentale (pilotée par sous-agents) → TDD → revue → ship. À utiliser quand l'utilisateur veut "faire les choses dans l'ordre", "spec d'abord", "un plan avant de coder", "approche disciplinée/rigoureuse", "TDD", "revue avant merge", ou quand une tâche est assez grosse/risquée pour mériter un cadrage. Orchestrateur : il SÉQUENCE et DÉLÈGUE aux skills existants, il ne les refait pas. Inspiré d'obra/superpowers (design, pas d'import de code). NE PAS utiliser pour un correctif trivial en une étape (overkill).
Transforme « code-moi ça » en une séquence traçable et vérifiable, avec une porte à chaque étape.
C'est un orchestrateur : chaque phase délègue au bon skill existant (spec-driven, planning,
incremental, TDD, code-review, shipping, head-agent, canal_agents). On ne duplique pas ces skills,
on les met en ordre — et on s'arrête aux portes pour validation humaine quand l'enjeu le justifie.
Quand l'appliquer
Tâche > 1 fichier ou à risque (prod, sécurité, irréversible, code inconnu). Sinon : faire direct.
Les phases (avec porte de sortie)
Brainstorm / clarifier — cerner l'intention réelle, les contraintes, le « pourquoi maintenant ».
Si flou : 1 question à la fois (cf. interview-me). Porte : intention validée.
Spec — rédiger une spécification courte (objectif, périmètre, non-objectifs, critères d'acceptation).
Déléguer à spec-driven-development. Porte : spec approuvée (humain si enjeu).
Plan / découpage — tâches ordonnées, dépendances, ce qui est parallélisable. planning-and-task-breakdown.
Porte : plan revu.
Implémentation incrémentale — petits incréments livrables ; déléguer les sous-tâches indépendantes à
des sous-agents (head-agent / Task) et, pour le multi-agents, au bus canal_agents.
incremental-implementation. Porte : chaque incrément compile/passe.
TDD — un test par comportement (rouge → vert), preuve exécutable. test-driven-development.
Porte : tests verts.
Revue — revue multi-axes (qualité, sécurité, simplicité) avant merge. code-review-and-quality,
security-and-hardening, et les gates R37/R38 du repo. Porte : revue OK + gates vertes.
Ship — checklist de lancement, rollback, observabilité. shipping-and-launch. Porte : déployable.
Garde-fous
Adaptatif : sauter les phases inutiles pour une petite tâche ; ne pas sur-cadrer (l'overkill est un défaut).
Portes humaines sur ce qui est structural/risqué/irréversible (cohérent avec code-corrector / agent-config-audit).
Anti-duplication : ce skill n'implémente pas spec/plan/TDD/review — il les séquence et délègue.
Traçabilité : journaliser décisions et étapes là où la boucle de réflexion existe (reflection/learning-engine).
R37 : générique, aucun terme/chemin privé dans le repo public.
