Plan Orchester

Que fait Plan Orchester ?

Faire le pont entre un document de plan et /orchestrate custom en émettant une invocation prête à être copiée-collée par étape. La compétence est purement générative — elle n'exécute jamais /orchestrate. L'utilisateur colle chaque ligne lorsqu'il est prêt.

Quand l'activer

• L'utilisateur a un document de plan en plusieurs étapes (PRD, RFC, plan d'implémentation) et souhaite le piloter via /orchestrate.
• L'utilisateur dit « orchestre ce plan », « donne-moi des invites orchester pour chaque étape », « compose les chaînes pour ce plan ».
• Un plan étape par étape existe mais l'utilisateur ne veut pas sélectionner manuellement les agents par étape.

Passer lorsque :

• Le travail est une étape ponctuelle → appeler /orchestrate custom directement.
• Le plan est illisible ou vide. L'absence de numérotation explicite seule n'est pas une condition pour passer — voir le cas particulier « Pas d'étapes claires » ci-dessous.

Entrées

<chemin-du-plan> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]

• <chemin-du-plan> — obligatoire ; chemin relatif ou absolu (@docs/... accepté).
• --lang — variante linguistique du relecteur ; par défaut auto (détecté depuis le projet).
• --scope — limite les étapes émises ; par défaut all.
• --dry-run — affiche uniquement la décomposition et la justification des chaînes ; n'émet pas les invites finales.

Forme autorisée de /orchestrate (ne pas dévier)

{CMD_ORCH} custom "<agent1>,<agent2>,...,<agentN>" "<description de la tâche>"

Où {CMD_ORCH} est déterminé en Phase 0 (voir ci-dessous). La chaîne de commande dans la sortie émise utilise toujours une forme concrète — jamais les deux, jamais un espace réservé.

• custom est une chaîne séquentielle ; le HANDOFF de chaque agent alimente le suivant.
• Liste d'agents séparés par des virgules. Pas d'espace de préférence ; un espace toléré.
• Il n'existe pas de drapeaux --mode / --gate / --agents=... — ne jamais les inventer.
• Les noms d'agents proviennent du catalogue de cette compétence. Les guillemets doubles incorporés dans la description de la tâche sont échappés en \".

Forme d'installation ECC et espaces de noms

Deux formes d'installation déterminent le préfixe à la fois sur la commande slash et sur chaque nom d'agent. Les DEUX doivent rester synchronisés — une forme par sortie, jamais mélangées :

Soit <répertoire-claude> le répertoire personnel de Claude Code : ~/.claude sur macOS/Linux, %USERPROFILE%\.claude sur Windows. Résolvez-le comme la plateforme hôte résout le répertoire personnel de l'utilisateur (ne codez pas en dur ~).

Forme	Détection	{CMD_ORCH}	Format du nom d'agent
Installation plugin (2.0.0+)	<répertoire-claude>/plugins/marketplaces/ecc/ existe	/ecc:orchestrate	ecc:<nom>
Installation héritée nue	Absence de ce qui précède ; fichiers d'agents sous <répertoire-claude>/agents/	/orchestrate	<nom>

Pourquoi c'est important : sous l'installation plugin, les agents s'enregistrent en tant que ecc:tdd-guide. Les noms nus forcent la correspondance floue, qui échoue par intermittence sous des appels parallèles. Sous l'installation héritée, les formes préfixées ne sont pas enregistrées et échouent complètement.

Catalogue d'agents disponibles (doivent être choisis parmi ceux-ci)

Généraux :

• planner — reformulation des exigences, décomposition des risques, planification des étapes
• architect — architecture, conception système, propositions de refonte
• tdd-guide — écrire les tests → implémenter → couverture ≥ 80%
• code-reviewer — révision de code générique
• security-reviewer — audit de sécurité, OWASP, fuite de secrets
• refactor-cleaner — code mort, doublons, nettoyage de type knip
• doc-updater — documentation, codemap, README
• docs-lookup — consultations d'API de bibliothèques tierces (Context7)
• e2e-runner — orchestration de tests de bout en bout
• database-reviewer — schéma PostgreSQL, migration, performance
• harness-optimizer — configuration du harnais d'agent local
• loop-operator — boucles autonomes de longue durée
• chief-of-staff — triage multicanal (rarement adapté aux étapes de plan)

Résolveurs d'erreurs de build :

• build-error-resolver (générique) / cpp-build-resolver / go-build-resolver / java-build-resolver / kotlin-build-resolver / rust-build-resolver / pytorch-build-resolver

Relecteurs de code :

• python-reviewer / typescript-reviewer / go-reviewer / rust-reviewer / cpp-reviewer / java-reviewer / kotlin-reviewer / flutter-reviewer

Un nom d'agent mal orthographié fait échouer /orchestrate. Vérifiez cette liste avant d'émettre.

Comment ça fonctionne

Phase 0 — Détecter le mode ECC + langage

1. Lire <chemin-du-plan>. S'il est manquant ou vide, le signaler et s'arrêter.

2. Détecter la forme d'installation ECC une fois et la geler dans MODE_ECC. Algorithme (exécuter dans l'ordre, s'arrêter à la première correspondance) :

   1. Si <répertoire-claude>/plugins/marketplaces/ecc/ existe → MODE_ECC=plugin.
   2. Sinon si <répertoire-claude>/agents/ existe et contient au moins un fichier d'agent ECC (par exemple tdd-guide.md, code-reviewer.md) → MODE_ECC=legacy.
   3. Sinon → par défaut MODE_ECC=legacy et émettre un avertissement d'une ligne en haut de la sortie : > Avertissement : impossible de détecter l'installation ECC ; utilisation par défaut de la forme héritée. Si vous utilisez l'installation plugin, modifiez les préfixes manuellement.
   4. Si les deux marqueurs existent (installation mixte), plugin l'emporte — l'espace de noms du plugin est le seul qui résout les noms d'agents sans correspondance floue.

   À partir de ce point, chaque ligne émise utilise le préfixe correspondant à la fois sur la commande slash et sur chaque nom d'agent. Ne jamais émettre les deux formes dans la même sortie.

3. Résoudre --lang. Lorsque auto, exécuter une détection polyglotte :

   • Sonder les marqueurs : pyproject.toml / uv.lock / requirements.txt → python ; package.json → typescript ; go.mod → go ; Cargo.toml → rust ; CMakeLists.txt ou *.cpp de niveau supérieur → cpp ; pom.xml / build.gradle (Java) → java ; build.gradle.kts ou Kotlin de niveau supérieur → kotlin ; pubspec.yaml → flutter.
   • Départage polyglotte : si plus d'un marqueur correspond, choisir le langage dont les fichiers sources surpassent les autres en nombre (compter via git ls-files, en excluant vendor/, node_modules/, dist/, build/, .venv/, les fichiers générés et les fixtures de test évidentes). En cas d'égalité ou lorsque aucun langage ne dépasse 60% des fichiers sources, définir lang=inconnu.
   • Aucun marqueur correspondant → définir lang=inconnu.
   • lang=inconnu est un sentinelle — ce n'est pas un nom d'agent. Les règles 4 et 5 de la Phase 2 le transforment en code-reviewer / build-error-resolver au moment de la composition de la chaîne.

4. Détecter un sous-profil PyTorch : lorsque lang=python et que l'un des fichiers pyproject.toml / requirements.txt / uv.lock déclare une dépendance à torch, définir pytorch=true. Cela n'affecte que la sélection de la chaîne build (règle de Phase 2 ci-dessous) ; le relecteur reste python-reviewer.

5. Normaliser tous les noms d'agents déclarés dans le plan : si le texte du plan fait référence à des agents par leur forme préfixée par plugin (par exemple ecc:tdd-guide), supprimer le préfixe pour obtenir le nom nu du catalogue avant de valider ou composer les chaînes. Le re-préfixage n'a lieu qu'au moment de la sortie selon MODE_ECC (Phase 4). Ne jamais laisser un nom pré-préfixé entrer dans la composition de la chaîne — cela double-préfixerait en mode plugin.

Phase 1 — Décomposer les étapes

Identifier les « unités d'étape » par ordre de priorité :

1. Numérotation explicite : ## Étape N / ### Phase N / ## N. ... / liste ordonnée de niveau supérieur.
2. Une colonne « Étape » dans un tableau.
3. Blocs séparés par --- avec des en-têtes menés par un verbe.
4. Sinon, traiter chaque H2 comme une étape.

Par étape, extraire id (basé sur 1), titre (≤ 80 caractères), intention (1–3 phrases), tags.

Phase 2 — Tagger et choisir la chaîne

Tagger par intention (multi-tags autorisés ; chaîne construite à partir du primaire + secondaires empilés) :

Les mots déclencheurs ci-dessous sont mis en correspondance sans tenir compte de la casse. Les plans multilingues sont pris en charge en faisant correspondre les racines des mots dans n'importe quelle langue tant que le sens s'aligne avec les mots déclencheurs anglais listés.

Tag	Mots déclencheurs	Chaîne par défaut
design	architecture, conception, choisir, évaluer, RFC	planner,architect
plan	plan, décomposition, jalon	planner
impl	implémenter, construire, ajouter, créer, porter	tdd-guide,<lang>-reviewer
test	test, couverture, e2e, intégration	tdd-guide,e2e-runner
refactor	refactoriser, nettoyer, dédoublonner, diviser	architect,refactor-cleaner,<lang>-reviewer
migration	migrer, mettre à niveau, réécrire, porter	architect,tdd-guide,<lang>-reviewer
db	schéma, migration, index, SQL, Postgres, alembic, sqlmodel	database-reviewer,<lang>-reviewer
security	chiffrer, auth, secret, OWASP, PII	security-reviewer,<lang>-reviewer
build	build, compiler, échec de lint, CI	<lang>-build-resolver (se rabat sur build-error-resolver)
docs	docs, readme, codemap, changelog	doc-updater
lookup	consulter, référence, utilisation API	docs-lookup
review	revoir, auditer, vérifier	<lang>-reviewer,code-reviewer
loop	boucle, autonome, gardien	loop-operator

Règles de composition de chaîne :

1. Sélection du tag primaire : lorsqu'une étape correspond à plusieurs tags, le premier dans l'ordre du tableau (haut du tableau = priorité la plus élevée) est le primaire ; les autres sont secondaires. Les règles de composition 2 et 3 ci-dessous traitent explicitement les combinaisons multi-tags spécifiques ; sinon, ajouter les chaînes secondaires dans l'ordre du tableau des tags.
2. impl + security → tdd-guide,<lang>-reviewer,security-reviewer.
3. impl + db → tdd-guide,database-reviewer,<lang>-reviewer.
4. Dédoublonner la chaîne résultante (conserver la première occurrence). Par exemple, review + lang=inconnu donnerait code-reviewer,code-reviewer après la règle 5 ; le dédoublonnage le réduit à code-reviewer.
5. <lang>-reviewer se résout en code-reviewer lorsque lang=inconnu.
6. <lang>-build-resolver se résout en build-error-resolver lorsque lang=inconnu. Cas particulier : si la Phase 0 a défini pytorch=true, utiliser pytorch-build-resolver pour les chaînes build indépendamment de <lang>. Il n'y a pas de python-build-resolver ; --lang=python sans pytorch=true se résout en build-error-resolver.
7. Étapes sans tag : si aucun mot déclencheur ne correspond, définir la chaîne sur code-reviewer et écrire aucun tag correspondant ; chaîne de révision par défaut uniquement sous « Justification de la chaîne ».
8. Longueur de chaîne ≤ 4 après dédoublonnage. Si dépassé, supprimer le tag le plus faible (lookup et docs en premier).
9. Ne pas associer planner et architect dans une chaîne impl (gaspillage de jetons). Les associer uniquement sur les étapes design.
10. Les étapes taguées impl, refactor ou migration se terminent par un agent de classe relecteur — n'importe lequel de <lang>-reviewer, code-reviewer, security-reviewer ou database-reviewer. Le relecteur le plus spécifique au domaine remporte la position finale (par exemple, la règle 2 impl+security se termine par security-reviewer ; la règle 3 impl+db se termine par <lang>-reviewer car database-reviewer valide déjà la migration plus tôt dans la chaîne). Les étapes test et build sont validées par leurs propres validateurs (e2e-runner et le résolveur de build respectivement) et ne nécessitent pas de relecteur supplémentaire.

Phase 3 — Compresser la description de la tâche

Chaque <description de la tâche> émise doit :

• Être autonome (le premier agent n'a pas besoin d'avoir le document de plan ouvert).
• Commencer par [Plan: <chemin>#étape-<id>].
• Inclure 1 à 3 critères d'acceptation vérifiables.
• Inclure une garde de périmètre (Hors périmètre : ...) uniquement si le plan en déclare une pour cette étape. Hériter textuellement. Si le plan n'a pas de déclaration hors périmètre, omettre complètement la clause — n'en inventez pas.
• Faire 200 à 600 caractères ; une seule ligne ; " incorporé échappé en \" ; pas de sauts de ligne littéraux.

Phase 4 — Sortie

Émettre du Markdown en utilisant la forme déterminée par MODE_ECC. La sortie utilise une seule forme partout — chaque {CMD_ORCH} et chaque nom d'agent est rendu avec le préfixe correspondant de la Phase 0. N'émettez pas les deux formes ; n'incluez pas d'instructions « ceci est la forme plugin » / « supprimer le préfixe » dans la sortie rendue.

Règles de rendu concrètes :

• {CMD_ORCH} = /ecc:orchestrate sous plugin, /orchestrate sous legacy.
• {AGENT(nom)} = ecc:<nom> sous plugin, <nom> sous legacy.
• La colonne « Chaîne » du tableau de synthèse utilise le même rendu {AGENT(nom)}.
• Les blocs bash par étape contiennent uniquement la commande exécutable. Pas de commentaires # forme plugin ou # forme legacy — la forme est implicite et uniforme sur toute la sortie.

Structure de sortie :

# Résultat Plan-Orchester

**Plan** : `<chemin>`
**Lang** : `<détecté-ou-donné>`
**Mode ECC** : `<plugin | legacy>`
**Étapes** : <N>
**Périmètre** : <all | étape:n | plage:a-b>

## Synthèse des étapes

| # | Titre | Tags | Chaîne |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |

---

## Étape 1 — <titre>

**Intention** : <1–3 phrases>
**Tags** : <a, b>
**Justification de la chaîne** : <pourquoi cette chaîne ; quel agent ferme la boucle>

```bash
{CMD_ORCH} custom "{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}" "[Plan: docs/foo.md#étape-1] <description de tâche compressée> ; Acceptance : <1–3 éléments> ; Hors périmètre : <…>"
```

La notation {CMD_ORCH} et {AGENT(...)} ci-dessus décrit la substitution que cette compétence effectue à l'exécution. Le Markdown réel émis contient les chaînes résolues, jamais les espaces réservés.

Ajouter un bloc final « Exécution par lots » agrégeant les commandes de chaque étape dans l'ordre, afin que l'utilisateur puisse toutes les coller à la fois. Ignorer le bloc de lots en mode aperçu uniquement (voir le cas particulier « Grand plan ») : lorsque seul le tableau de synthèse est émis, il n'y a pas de commandes par étape à agréger.

Phase 5 — Auto-vérification (avant d'émettre)

• Tous les agents de chaque chaîne proviennent du catalogue (après avoir supprimé tout préfixe ecc: apparu dans le plan ; voir Phase 0 étape 5).
• Le {CMD_ORCH} résolu et chaque {AGENT(...)} résolu utilisent la même forme (plugin ou legacy) — jamais mélangés dans une même sortie.
• Aucune annotation # forme plugin / # forme legacy et aucune instruction « supprimer le préfixe » ne subsistent dans la sortie rendue.
• Aucun champ --mode / --gate / --agents=... inventé.
• Chaque description de tâche est sur une seule ligne, entre guillemets doubles, avec les " incorporés échappés.
• Chaque description de tâche commence par [Plan: <chemin>#étape-<id>] et inclut des Acceptances (1 à 3 éléments). La clause Hors périmètre : n'est présente que lorsqu'elle est héritée du plan.
• Aucun doublon d'agent dans une chaîne après dédoublonnage de la Phase 2.
• Longueur de chaîne ≤ 4.
• Les étapes taguées impl/refactor/migration se terminent par un agent de classe relecteur (…

[… tronqué pour la traduction]