ECC Recettes
Point d'entrée unique pour « quel groupe de commandes slash ECC exécute mon workflow, dans quel ordre et quand dois-je m'arrêter ». Permet également de parcourir toutes les familles de recettes de groupes de commandes.
Comble le fossé entre deux compétences existantes :
ecc-guide— liste les commandes et où lire la documentation, mais sous forme de catalogue plat.prompt-optimizer— associe une tâche à des composants, mais produit un seul prompt, pas un groupe de commandes avec ordre d'exécution et condition d'arrêt.
Cette compétence ajoute : regroupement familial + ordre d'exécution + condition d'arrêt.
Quand l'activer
- « Quel groupe de commandes dois-je exécuter pour ? »
- « Quelle est la séquence de commandes pour construire un MVP / corriger un défaut / refactoriser ? »
- « Affiche-moi toutes les recettes de groupes de commandes ECC » (mode catalogue)
- « Combien de pipelines de workflow ECC existe-t-il ? »
- L'utilisateur invoque
/ecc-recettesavec ou sans description.
Ne pas utiliser quand
- L'utilisateur souhaite que la tâche soit effectuée maintenant — diriger vers la commande réelle, ne pas la décrire.
- L'utilisateur souhaite une documentation approfondie pour UNE commande — utiliser
ecc-guide. - L'utilisateur souhaite réécrire un brouillon de prompt — utiliser
prompt-optimizer.
Principe fondamental
Répondre à partir des fichiers actuels, pas de la mémoire. L'ensemble des commandes change ; ne jamais coder en dur les décomptes ou les listes de membres. Lire le répertoire commands/ en direct à chaque exécution, puis classer en familles.
Lectures en direct
Résoudre le répertoire des commandes (le premier qui existe), puis lister les noms :
for D in \
"$HOME"/.claude/plugins/marketplaces/ecc/commands \
"$HOME"/.claude/plugins/cache/ecc/ecc/*/commands \
./commands \
./.claude/commands \
"$HOME"/.claude/commands; do
[ -d "$D" ] && CMD_DIR="$D" && break
done
[ -z "${CMD_DIR:-}" ] && { echo "Aucun répertoire de commandes ECC trouvé."; return 1; }
find "$CMD_DIR" -maxdepth 1 -name '*.md' -exec basename {} .md \; | sort
Optionnellement lire manifests/install-*.json si présent pour un regroupement plus riche. Utiliser le plus petit ensemble de lectures nécessaire.
Classification en familles (par préfixe)
Grouper les noms de commandes par préfixe principal ; mapper les singletons connus manuellement. Les familles sont dérivées en direct — le tableau ci-dessous est la règle de classification, pas une liste figée.
| Préfixe de famille | Signification de la recette | Ordre d'exécution typique |
|---|---|---|
orch-* | Recherche, Plan, TDD, Revue, Commit par type de tâche avec portes | choisir un orch-* selon le type de tâche ; il exécute ses propres phases internes |
multi-* | Workflow multi-modèle | multi-plan puis multi-execute puis revue (ou multi-workflow de bout en bout) |
prp-* | Pipeline PRD vers plan vers implémentation vers PR | prp-prd puis prp-plan puis prp-implement puis prp-commit puis prp-pr |
epic-* | Grande épopée multi-unités, parallèle | epic-decompose puis epic-claim puis epic-validate puis epic-review puis epic-unblock puis epic-sync puis epic-publish |
loop-* | Boucle autonome gérée et surveillance | loop-start <modèle> puis surveiller avec loop-status |
gan-* | Boucle générateur et évaluateur | gan-build (code) ou gan-design (UI) ; auto-bouclage |
*-build / *-review / *-test | Triade CI par langage | <lang>-test (TDD) puis <lang>-build (correction) puis <lang>-review |
hookify-* | Gestion des hooks de comportement | hookify puis hookify-list puis hookify-configure |
learn / instinct-* / evolve / promote / prune | Apprentissage continu | learn puis instinct-status puis evolve puis promote |
| singletons | santa-loop, plan, plan-prd, pr, code-review, checkpoint, etc. | autonome ou colle entre groupes |
Toute commande ne correspondant pas à une règle de préfixe → la lister sous singletons avec sa description en une ligne.
Comment ça fonctionne
1. Lire en direct les noms de commandes depuis CMD_DIR.
2. Classer en familles par préfixe et une carte des singletons.
3. Si une description de workflow a été fournie -> MODE CORRESPONDANCE.
Sinon -> MODE CATALOGUE.
4. Uniquement consultatif : afficher le plan. Ne jamais exécuter les commandes correspondantes.
Mode catalogue (aucune description)
Afficher le tableau des familles : chaque famille, nombre de membres, membres, signification en une ligne, ordre d'exécution typique. Terminer avec le nombre total de commandes et une invite à décrire un workflow pour une recette correspondante.
Mode correspondance (description fournie)
- Reformuler le workflow en une phrase.
- Choisir les 1 à 2 meilleures familles ; expliquer POURQUOI en une ligne chacune.
- Bloc d'ordre d'exécution — séquence de commandes exacte pour la famille correspondante.
- Condition d'arrêt — toujours explicite (max-exécutions, signal d'achèvement, validations de revue, ou unique). Pour les boucles autonomes, avertir de la consommation d'abonnement et recommander une limite de protection.
- Où lire — le chemin
commands/<nom>.mdplus/ecc-guide <nom>.
Modèle de sortie (mode correspondance)
Workflow : <reformulation en une phrase>
Meilleure correspondance : <famille> — <pourquoi>
(Alt : <famille> — <pourquoi>)
Ordre d'exécution :
/<cmd1> # tâche
/<cmd2> # tâche
/<cmd3> # tâche
STOP quand : <condition>
ATTENTION (boucles autonomes uniquement) : une boucle non bornée consomme l'abonnement/les crédits —
ajouter une limite de max-itérations ou de coût max comme filet de sécurité en plus du signal d'achèvement.
Lire la documentation complète :
commands/<cmd1>.md (ou : /ecc-guide <cmd1>)
Exemples
Catalogue: /ecc-recettes → affiche le tableau des familles et le nombre total.
Correspondance: /ecc-recettes planifier une application entière au préalable puis auto-construire avec revue antagoniste jusqu'à terminaison → Meilleure correspondance : loop-* (autonome) encapsulant gan-* ou santa-loop (antagoniste). Ordre d'exécution : plan-prd puis loop-start rfc-dag --mode safe puis surveiller loop-status ; STOP quand toutes les unités passent la revue N fois consécutives (ajouter une limite de max-itérations pour borner la consommation).
Correspondance: /ecc-recettes corriger un bug dans mon service Go → Meilleure correspondance : orch-fix-defect (reproduire, corriger, revoir, commiter). Alt : go-test puis go-build puis go-review. STOP : test de régression vert et revue validée.
Non-objectifs
- Pas un exécuteur — uniquement consultatif.
- Pas une documentation approfondie par commande — c'est le rôle de
ecc-guide. - Pas une réécriture de prompt — c'est le rôle de
prompt-optimizer. - Ne jamais coder en dur les décomptes ou listes de commandes — toujours lire en direct.