• — obligatoire ; chemin relatif ou absolu (@docs/... accepté).
• --lang — variante de langue du réviseur ; valeur par défaut : auto (détectée à partir du projet).
• --scope — limite les étapes générées ; valeur par défaut : all.
• --dry-run — affiche uniquement la décomposition et la justification de la chaîne ; n'affiche pas les invites finales.

Forme standard /orchestrate (ne pas s'en écarter)

{ORCH_CMD} custom ",,...," ""

Où {ORCH_CMD} est déterminé lors de 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 HANDOFF de chaque agent alimente le suivant.
• Liste d’agents séparés par des virgules. De préférence sans espaces ; un seul espace est toléré.
• Il n’existe aucun indicateur --mode / --gate / --agents=... — ne les inventez jamais.
• 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 sous la forme \".

Formulaire d’installation ECC et espacement des noms

Deux formes d’installation déterminent le préfixe à la fois de la commande « / » et de chaque nom d’agent. Les deux DOIVENT rester synchronisées — une forme par sortie, jamais mélangées :

Soit désigne le répertoire personnel de Claude Code : ~/.claude sous macOS/Linux, %USERPROFILE%\.claude sous Windows. Résolvez-le de la manière dont la plateforme hôte résout le répertoire personnel de l’utilisateur (ne codez pas en dur ~).

Pourquoi est-ce important ? : avec l’installation via le plugin, les agents s’enregistrent sous le nom « everything-claude-code:tdd-guide ». Les noms « nus » forcent une correspondance approximative, ce qui échoue de manière intermittente lors d’appels parallèles. Avec l’installation héritée, les formes préfixées ne sont pas enregistrées et échouent purement et simplement.

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

Général :

• planner — reformulation des exigences, décomposition des risques, planification des étapes
• architect — architecture, conception du système, propositions de refactorisation
• tdd-guide — rédaction de tests → implémentation → couverture ≥ 80 %
• code-reviewer — revue de code générique
• réviseur de sécurité — audit de sécurité, OWASP, fuites de données confidentielles
• nettoyeur de refactorisation — code mort, doublons, nettoyage des classes Knip
• mise-à-jour de la documentation — documentation, carte de code, README
• docs-lookup — recherche d’API de bibliothèques tierces (Context7)
• e2e-runner — orchestration des tests de bout en bout
• database-reviewer — schéma PostgreSQL, migration, performances
• harness-optimizer — configuration du harnais d’agents locaux
• loop-operator — boucles autonomes de longue durée
• chief-of-staff — triage multicanal (rarement adapté aux étapes d’un plan)

Résolution des 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é entraîne l’échec de /orchestrate. Vérifiez cette liste avant de l’envoyer.

Fonctionnement

Phase 0 — Détection du mode ECC et du langage

1. Lire . Si elle est manquante ou vide, signalez-le et arrêtez-vous.

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

   1. Si /plugins/marketplaces/everything-claude-code/ existe → ECC_MODE = plugin.
   2. Sinon, si /agents/ existe et contient au moins un fichier d’agent ECC (par ex. tdd-guide.md, code-reviewer.md) → ECC_MODE=legacy.
   3. Sinon → valeur par défaut ECC_MODE=legacy et affichage d’un avertissement d’une ligne en haut de la sortie : > Avertissement : impossible de détecter l’installation ECC ; passage par défaut au mode legacy. Si vous utilisez l’installation par plugin, modifiez les préfixes manuellement.
   4. Si les deux marqueurs existent (installation mixte), le plugin prévaut : l’espace de noms du plugin est le seul à résoudre les noms d’agents sans correspondance approximative.

   À partir de ce moment, chaque ligne générée utilise le préfixe correspondant à la fois pour la commande « / » et pour chaque nom d’agent. Ne générez jamais les deux formes dans la même sortie.

3. Résolution de --lang. En mode « auto », effectuez une détection tenant compte du polyglottisme :

   • Marqueurs de détection : 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.
   • Critère de départage en cas de polyglottisme: si plusieurs marqueurs correspondent, choisissez le langage dont les fichiers source sont les plus nombreux (comptez-les via `git ls-files`, en excluant les répertoires `vendor/`, `node_modules/`, `dist/`, `build/`, `.venv/`, les fichiers générés et les fixtures de test évidentes). En cas d’égalité ou si aucun langage ne représente plus de 60 % des fichiers source, définissez lang=unknown.
   • Aucun marqueur ne correspond → définissez lang=unknown.
   • lang=unknown est une 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éfinissez pytorch=true. Cela n’affecte que la sélection de la chaîne de construction (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 fait référence à des agents sous leur forme préfixée par le plugin (par exemple everything-claude-code:tdd-guide), supprimer le préfixe pour obtenir le nom de catalogue nu avant de valider ou de composer les chaînes. La ré-ajout du préfixe n’a lieu qu’au moment de la sortie, selon ECC_MODE (phase 4). Ne laissez jamais un nom pré-préfixé entrer dans la composition de la chaîne — cela entraînerait un double préfixe en mode plugin.

Phase 1 — Décomposer les étapes

Identifiez 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 des en-têtes commençant par un verbe.
4. Sinon, considérer chaque H2 comme une étape.

Pour chaque étape, extraire l’identifiant (à partir de 1), le titre (≤ 80 caractères), l’intention (1 à 3 phrases) et les balises.

Phase 2 — Chaîne de balisage et de sélection

Baliser par intention (balises multiples autorisées ; chaîne constituée d’une balise principale + de balises secondaires empilées) :

Les mots-clés ci-dessous sont mis en correspondance sans distinction de majuscules/minuscules. Les plans multilingues sont pris en charge en faisant correspondre les racines des mots dans n’importe quelle langue, à condition que le sens corresponde aux mots-clés anglais répertoriés.

Règles de composition des chaînes :

1. Sélection de la balise principale: lorsqu’une étape correspond à plusieurs balises, la première dans l’ordre du tableau (en haut du tableau = priorité la plus élevée) est la balise principale ; les autres sont secondaires. Les règles de composition 2 et 3 ci-dessous traitent explicitement certaines combinaisons spécifiques de balises ; sinon, ajoutez les chaînes secondaires dans l’ordre du tableau des balises.
2. impl + security → tdd-guide,-reviewer,security-reviewer.
3. impl + db → tdd-guide,database-reviewer,-reviewer.
4. Dédupliquez la chaîne résultante (en conservant la première occurrence). Par exemple, « review + lang=unknown » donnerait « code-reviewer,code-reviewer » après application de la règle 5 ; la déduplication ramène le résultat à « code-reviewer ».
5. -reviewer se résout en code-reviewer lorsque lang=unknown.
6. -build-resolver se résout en build-error-resolver lorsque lang=unknown. Cas particulier: si la phase 0 a défini pytorch=true, utilisez pytorch-build-resolver pour les chaînes de compilation, quel que soit . Il n’existe pas de python-build-resolver; --lang=python sans pytorch=true est résolu en build-error-resolver.
7. Étapes sans balise: si aucun mot déclencheur ne correspond, définir la chaîne sur « code-reviewer » et indiquer « aucune balise correspond » ; chaîne par défaut « review-only » sous « Justification de la chaîne ».
8. Longueur de la chaîne ≤ 4 après déduplication. En cas de dépassement, supprimer le tag le plus faible (recherche et documentation en premier).
9. Ne pas associer « planner » et « architect » dans une chaîne « impl » (gaspillage de jetons). Ne les associer que lors des étapes de conception.
10. Les étapes marquées « impl », « refactor » ou « migration » se terminent par un agent de classe « reviewer » — l’un des suivants : « -reviewer », « code-reviewer », « security-reviewer » ou « database-reviewer ». Le réviseur le plus spécialisé dans le domaine occupe la dernière position (par exemple, la combinaison « impl+security » de la règle 2 se termine par « security-reviewer »; la combinaison « impl+db » de la règle 3 se termine par « -reviewer » car « database-reviewer » contrôle déjà la migration plus tôt dans la chaîne). Les étapes de test et de compilation sont contrôlées par leurs propres validateurs (respectivement «e2e-runner » et le « build resolver ») et ne nécessitent pas de réviseur supplémentaire.

Phase 3 — Compression de la description de la tâche

Chaque doit :

• Être autonome (le premier agent n’a pas besoin que le document de plan soit ouvert).
• Commencer par [Plan : #step-].
• inclure 1 à 3 critères d’acceptation vérifiables.
• Inclure une clause de délimitation du champ d’application (Hors champ d’application : ...) uniquement si le plan en déclare une pour cette étape. La reprendre mot pour mot. Si le plan ne comporte aucune déclaration de hors champ d’application, omettre entièrement la clause — n’en inventer aucune.
• Longueur : 200 à 600 caractères ; une seule ligne ; les caractères « » doivent être échappés par « \ »; pas de sauts de ligne littéraux.

Phase 4 — Sortie

Générer du Markdown en utilisant le format déterminé par ECC_MODE. La sortie utilise un seul format tout au long du texte : chaque {ORCH_CMD} et chaque nom d’agent est rendu avec le préfixe correspondant de la phase 0. Ne générez pas les deux formats ; n’incluez pas d’instructions du type « ceci est le format du plugin » / « supprimer le préfixe » dans la sortie rendue.

Règles de rendu concrètes :

• {ORCH_CMD} = /everything-claude-code:orchestrate sous « plugin », /orchestrate sous « legacy ».
• {AGENT(nom)} = everything-claude-code: sous « plugin », sous « legacy ».
• La colonne « Chain » du tableau récapitulatif utilise le même rendu {AGENT(name)}.
• Les blocs bash par étape ne contiennent que la commande exécutable. Pas de commentaires de type # plugin form ou # legacy form — la forme est implicite et uniforme sur l'ensemble de la sortie.

Structure de la sortie :

# Résultat de Plan-Orchestrate 
**Plan** : ``
**Lang** : ``
**Mode ECC** : ``
**Étapes** : 
**Portée** : 

## Aperçu des étapes

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

---

## Étape 1 —