Recettes ECC
Point d'entrée unique pour « quel groupe de slash-commandes ECC exécute mon workflow, dans quel ordre, et quand m'arrêter ? ». Permet également de parcourir toutes les familles de recettes de groupes de commandes.
Comble le fossé entre deux skills existants :
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 et condition d'arrêt.
Ce skill ajoute : regroupement par famille + 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 ? »
- « Montre-moi toutes les recettes de groupes de commandes ECC » (mode catalogue)
- « Combien de pipelines de workflow ECC existe-t-il ? »
- L'utilisateur invoque
/ecc-recipesavec ou sans description.
Ne pas utiliser quand
- L'utilisateur veut que la tâche soit exécutée maintenant — redirigez vers la commande réelle, ne la décrivez pas.
- L'utilisateur veut une documentation approfondie pour UNE commande — utilisez
ecc-guide. - L'utilisateur veut qu'un brouillon de prompt soit réécrit — utilisez
prompt-optimizer.
Principe fondamental
Répondez à partir des fichiers actuels, pas de la mémoire. L'ensemble des commandes change ; ne codez jamais en dur les comptes ni les listes de membres. Lisez le répertoire commands/ en direct à chaque exécution, puis classez-les en familles.
Lectures en direct
Résolvez le répertoire des commandes (le premier qui existe), puis listez 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 "Répertoire de commandes ECC introuvable."; return 1; }
find "$CMD_DIR" -maxdepth 1 -name '*.md' -exec basename {} .md \; | sort
Optionnellement, lisez manifests/install-*.json s'il existe pour un regroupement plus riche. Utilisez le plus petit ensemble de lectures nécessaire.
Classification en familles (par préfixe)
Regroupez les noms de commandes par préfixe principal ; mappez 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, Planification, TDD, Revue, Commit par type de tâche | 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 → plan → implémentation → PR | prp-prd puis prp-plan puis prp-implement puis prp-commit puis prp-pr |
epic-* | Grande épique 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 → listez-la sous singletons avec sa description d'une ligne.
Comment ça fonctionne
1. Lecture en direct des noms de commandes depuis CMD_DIR.
2. Classification 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 : affichez le plan. N'exécutez jamais les commandes correspondantes.
Mode catalogue (aucune description)
Affichez le tableau des familles : chaque famille, nombre de membres, membres, signification en une ligne, ordre d'exécution typique. Terminez par le nombre total de commandes et une invite à décrire un workflow pour obtenir une recette correspondante.
Mode correspondance (description fournie)
- Reformulez le workflow en une phrase.
- Choisissez la ou les 2 meilleures familles ; expliquez POURQUOI en une ligne chacune.
- Bloc d'ordre d'exécution — séquence exacte de commandes pour la famille correspondante.
- Condition d'arrêt — toujours explicite (nombre maximal d'exécutions, signal de complétion, passages en revue, ou tir unique). Pour les boucles autonomes, avertissez de la consommation d'abonnement et recommandez une limite de sécurité.
- 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>
(Alternative : <famille> — <pourquoi>)
Ordre d'exécution :
/<cmd1> # tâche
/<cmd2> # tâche
/<cmd3> # tâche
STOP quand : <condition>
ATTENTION (boucles autonomes uniquement) : une boucle sans limite consomme abonnement/crédits —
ajoutez une limite de nombre d'itérations ou de coût maximal en complément du signal de complétion.
Lire la documentation complète :
commands/<cmd1>.md (ou : /ecc-guide <cmd1>)
Exemples
Catalogue : /ecc-recipes → affiche le tableau des familles et le nombre total.
Correspondance : /ecc-recipes planifier toute une application d'abord puis construire automatiquement avec revue contradictoire jusqu'à terminaison → Meilleure correspondance : loop-* (autonome) enveloppant gan-* ou santa-loop (contradictoire). 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 nombre d'itérations pour borner la consommation).
Correspondance : /ecc-recipes corriger un bogue dans mon service Go → Meilleure correspondance : orch-fix-defect (reproduire, corriger, revoir, commit). Alternative : go-test puis go-build puis go-review. STOP : test de régression vert et revue approuvée.
Non-objectifs
- Pas un exécuteur — uniquement consultatif.
- Pas de documentation approfondie par commande — c'est le rôle de
ecc-guide. - Pas de réécriture de prompt — c'est le rôle de
prompt-optimizer. - Ne jamais coder en dur les comptes ou les listes de commandes — toujours lire en direct.