Plan-Orchestrate

Que fait Plan-Orchestrate ?

Faire le pont entre un document de planification et /orchestrate custom en émettant une invocation prête à coller par étape. La compétence est uniquement générative — elle n'exécute jamais /orchestrate. L'utilisateur colle chaque ligne quand il est prêt.

Quand activer

• L'utilisateur a un document de planification multi-étapes (PRD, RFC, plan de mise en œuvre) et souhaite l'exécuter via /orchestrate.
• L'utilisateur dit « orchestre ce plan », « donne-moi les invites orchestrate 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.

Ignorer quand :

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

Entrées

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

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

Forme autoritaire de /orchestrate (ne pas dévier)

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

Où {ORCH_CMD} est déterminé dans la 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 TRANSFERT 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 intégrés dans la description de la tâche sont échappés comme ".

Forme d'installation ECC et espace de noms

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

Soit <claude-home> 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	{ORCH_CMD}	Format du nom d'agent
Installation par plugin (2.0.0+)	<claude-home>/plugins/marketplaces/ecc/ existe	/ecc:orchestrate	ecc:<nom>
Installation legacy (nue)	Absence de ce qui précède ; fichiers d'agents sous <claude-home>/agents/	/orchestrate	<nom>

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

Catalogue d'agents disponibles (doit choisir parmi ceux-ci)

Généraux :

• planner — reformulation des exigences, décomposition des risques, planification des étapes
• architect — architecture, conception système, propositions de refactorisation
• 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 — recherches 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 de harnais d'agent local
• loop-operator — boucles autonomes longue durée
• chief-of-staff — triage multicanal (rarement adapté aux étapes d'un plan)

Résolveurs d'erreurs de compilation :

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

Réviseurs 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 par recoupement avec cette liste avant d'émettre.

Comment ça fonctionne

Phase 0 — Détection du mode ECC + langage

1. Lire <plan-doc-path>. Si manquant ou vide, signaler et arrêter.

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

   1. Si <claude-home>/plugins/marketplaces/ecc/ existe → ECC_MODE=plugin.
   2. Sinon, si <claude-home>/agents/ existe et contient au moins un fichier d'agent ECC (par exemple tdd-guide.md, code-reviewer.md) → ECC_MODE=legacy.
   3. Sinon → par défaut ECC_MODE=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 legacy. Si vous utilisez l'installation par 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 oblique et sur chaque nom d'agent. Ne jamais émettre les deux formes dans la même sortie.

3. Résoudre --lang. Quand 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 sont plus nombreux que les autres (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 quand aucun langage ne dépasse 60 % des fichiers sources, définir lang=unknown.
   • Aucun marqueur correspondant → définir lang=unknown.
   • lang=unknown 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 : quand lang=python et que l'un des 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 la Phase 2 ci-dessous) ; le réviseur reste python-reviewer.

5. Normaliser tous les noms d'agents déclarés dans le plan : si le texte du plan 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 ECC_MODE (Phase 4). Ne jamais laisser un nom préfixé circuler dans la composition de la chaîne — il serait doublement préfixé 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 premier niveau.
2. Une colonne « Étape » dans un tableau.
3. Blocs séparés par --- avec des titres commençant 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é ; chaîne construite à partir du primaire + secondaires empilés) :

Les mots déclencheurs ci-dessous sont comparés sans tenir compte de la casse. Les plans multilingues sont supportés 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édupliquer, 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, authentifier, secret, OWASP, PII	security-reviewer,<lang>-reviewer
build	construire, compiler, échec de lint, CI	<lang>-build-resolver (se rabat sur build-error-resolver)
docs	docs, readme, codemap, changelog	doc-updater
lookup	recherche, référence, utilisation d'API	docs-lookup
review	révision, audit, vérifier	<lang>-reviewer,code-reviewer
loop	boucle, autonome, watchdog	loop-operator

Règles de composition de la chaîne :

1. Sélection du tag primaire : quand 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édupliquer la chaîne résultante (conserver la première occurrence). Par exemple, review + lang=unknown donnerait code-reviewer,code-reviewer après la règle 5 ; la déduplication le réduit à code-reviewer.
5. <lang>-reviewer se résout en code-reviewer quand lang=unknown.
6. <lang>-build-resolver se résout en build-error-resolver quand lang=unknown. 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 sous « Justification de la chaîne ».
8. Longueur de la chaîne ≤ 4 après déduplication. 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 tokens). Les associer uniquement sur les étapes design.
10. Les étapes taguées impl, refactor ou migration se terminent par un agent de classe réviseur — l'un parmi <lang>-reviewer, code-reviewer, security-reviewer ou database-reviewer. Le réviseur le plus spécifique au domaine remporte la position finale (par exemple la règle 2 pour impl+security se termine par security-reviewer ; la règle 3 pour impl+db se termine par <lang>-reviewer car database-reviewer verrouille déjà la migration plus tôt dans la chaîne). Les étapes test et build sont verrouillées par leurs propres validateurs (e2e-runner et le résolveur de construction respectivement) et ne nécessitent pas de réviseur 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 du document de planification ouvert).
• Commencer par [Plan : <chemin>#step-<id>].
• Inclure 1 à 3 critères d'acceptation vérifiables.
• Inclure une barrière 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 de hors périmètre, omettre entièrement la clause — ne pas en inventer une.
• Faire 200 à 600 caractères ; une seule ligne ; " intégrés échappés comme \" ; pas de retours à la ligne littéraux.

Phase 4 — Sortie

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

Règles de rendu concrètes :

• {ORCH_CMD} = /ecc:orchestrate sous plugin, /orchestrate sous legacy.
• {AGENT(nom)} = ecc:<nom> sous plugin, <nom> sous legacy.
• La colonne « Chaîne » du tableau récapitulatif 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 dans toute la sortie.

Structure de sortie :

# Résultat Plan-Orchestrate

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

## Aperçu 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 boucle la boucle>

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

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

Ajouter un bloc final « Exécution par lots » regroupant chaque commande d'étape dans l'ordre afin que l'utilisateur puisse toutes les coller en une fois. **Ignorer le bloc par lots en mode aperçu uniquement** (voir le cas limite « Grand plan ») : lorsque seul le tableau d'aperçu est émis, il n'y a pas de commandes par étape à regrouper.

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

- [ ] Chaque agent dans chaque chaîne provient du catalogue (après avoir supprimé tout préfixe `ecc:` apparu dans le plan ; voir Phase 0 étape 5).
- [ ] `{ORCH_CMD}` résolu et chaque `{AGENT(...)}` résolu utilisent la **même** forme (`plugin` ou `legacy`) — jamais mélangés dans une seule 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 `"` intégrés échappés.
- [ ] Chaque description de tâche commence par `[Plan: <chemin>#step-<id>]` et inclut l'Acceptation (1 à 3 éléments). La clause `Hors périmètre :` n'est présente que lorsqu'elle est héritée du plan.
- [ ] Aucun agent en double dans une chaîne après déduplication de la Phase 2.
- [ ] Longueur de la chaîne ≤ 4.
- [ ] Les étapes taguées `impl`/`refactor`/`migration` se terminent par un agent de classe réviseur (...)

[partie tronquée pour la traduction]