ECC-Rezepte

Was macht ECC-Rezepte?

Ein Einstiegspunkt für die Frage: „Welche Gruppe von ECC-Slash-Befehlen führt meinen Workflow aus, in welcher Reihenfolge und wann höre ich auf?“. Durchsucht außerdem alle Rezeptfamilien von Befehlsgruppen.

Schließt die Lücke zwischen zwei vorhandenen Skills:

• ecc-guide — listet Befehle auf und zeigt, wo die Dokumentation zu finden ist, jedoch als flaches Verzeichnis.
• prompt-optimizer — ordnet einer Aufgabe Komponenten zu, gibt aber nur einen einzelnen Prompt aus, keine Befehlsgruppe mit Ausführungsreihenfolge und Stoppbedingung.

Dieser Skill fügt hinzu: Familien-Gruppierung + Ausführungsreihenfolge + Stoppbedingung.

Wann aktivieren

• „Welche Befehlsgruppe führe ich für aus?“
• „Wie lautet die Befehlssequenz, um ein MVP zu erstellen / einen Fehler zu beheben / zu refaktorisieren?“
• „Zeige mir alle ECC-Befehlsgruppen-Rezepte“ (Katalogmodus)
• „Wie viele Workflow-Pipelines hat ECC?“
• Benutzer ruft /ecc-recipes mit oder ohne Beschreibung auf.

Nicht verwenden bei

• Benutzer möchte die Aufgabe sofort erledigt haben – leite an den eigentlichen Befehl weiter, beschreibe ihn nicht.
• Benutzer möchte eine ausführliche Dokumentation für EINEN Befehl – verwende ecc-guide.
• Benutzer möchte einen Entwurf umschreiben lassen – verwende prompt-optimizer.

Kernprinzip

Antworte aus den aktuellen Dateien, nicht aus dem Gedächtnis. Der Befehlsbestand ändert sich; zähle niemals hartcodierte Werte oder Mitgliederlisten. Lies bei jedem Durchlauf das Live-Verzeichnis commands/ und klassifiziere es dann in Familien.

Live-Lesen

Ermittle das Befehlsverzeichnis (das erste, das existiert), liste dann die Namen auf:

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 "Kein ECC-Befehlsverzeichnis gefunden."; return 1; }
find "$CMD_DIR" -maxdepth 1 -name '*.md' -exec basename {} .md \; | sort

Optional manifests/install-*.json lesen, falls vorhanden, für eine umfangreichere Gruppierung. Verwende die minimal benötigte Anzahl an Lesevorgängen.

Familienklassifikation (nach Präfix)

Gruppiere Befehlsnamen nach führendem Präfix; ordne bekannte Einzelbefehle manuell zu. Familien werden live abgeleitet – die folgende Tabelle ist die Klassifikationsregel, keine eingefrorene Liste.

Familienpräfix	Rezeptbedeutung	Typische Ausführungsreihenfolge
orch-*	Gestaffeltes Research, Plan, TDD, Review, Commit pro Aufgabentyp	Wähle ein orch-* je nach Aufgabenart; es führt seine eigenen internen Phasen aus
multi-*	Multi-Modell-Workflow	multi-plan dann multi-execute dann Review (oder multi-workflow Ende-zu-Ende)
prp-*	PRD zu Plan zu Implementierung zu PR-Pipeline	prp-prd dann prp-plan dann prp-implement dann prp-commit dann prp-pr
epic-*	Große Multi-Unit-Epik, parallel	epic-decompose dann epic-claim dann epic-validate dann epic-review dann epic-unblock dann epic-sync dann epic-publish
loop-*	Verwaltete autonome Schleife und Überwachung	loop-start <muster> dann mit loop-status beobachten
gan-*	Generator- und Evaluator-Schleife	gan-build (Code) oder gan-design (UI); selbstschleifend
*-build / *-review / *-test	Sprachspezifische CI-Triade	<sprache>-test (TDD) dann <sprache>-build (beheben) dann <sprache>-review
hookify-*	Verhaltens-Hook-Verwaltung	hookify dann hookify-list dann hookify-configure
learn / instinct-* / evolve / promote / prune	Kontinuierliches Lernen	learn dann instinct-status dann evolve dann promote
Einzelbefehle	santa-loop, plan, plan-prd, pr, code-review, checkpoint usw.	Eigenständig oder als Kleber zwischen Gruppen

Jeder Befehl, der keiner Präfixregel entspricht, wird unter Einzelbefehle mit seiner einzeiligen Beschreibung aufgelistet.

Funktionsweise

1. Lese live die Befehlsnamen aus dem CMD_DIR.
2. Klassifiziere in Familien nach Präfix und einer Map für Einzelbefehle.
3. Wenn eine Workflow-Beschreibung angegeben wurde → ABGLEICHMODUS.
   Wenn nicht → KATALOGMODUS.
4. Nur beratend: Gib den Plan aus. Führe die passenden Befehle niemals aus.

Katalogmodus (keine Beschreibung)

Gib die Familien-Tabelle aus: jede Familie, Mitgliederanzahl, Mitglieder, einzeilige Bedeutung, typische Ausführungsreihenfolge. Beende mit der Gesamtanzahl der Befehle und einer Aufforderung, einen Workflow zu beschreiben, um ein passendes Rezept zu erhalten.

Abgleichmodus (Beschreibung gegeben)

1. Gib den Workflow in einem Satz wieder.
2. Wähle die besten 1-2 Familien aus; erkläre WARUM in je einem Satz.
3. Ausführungsreihenfolge-Block – genaue Befehlssequenz für die passende Familie.
4. Stoppbedingung – immer explizit (maximale Durchläufe, Abschlusssignal, bestandene Überprüfungen oder einmalige Ausführung). Bei autonomen Schleifen vor dem Verbrauch von Abonnements warnen und eine Begrenzung empfehlen.
5. Wo lesen – den Pfad commands/<name>.md plus /ecc-guide <name>.

Ausgabevorlage (Abgleichmodus)

Workflow: <ein-Satz-Wiedergabe>

Beste Übereinstimmung: <Familie> — <Grund>
(Alt: <Familie> — <Grund>)

Ausführungsreihenfolge:
  /<befehl1>   # Aufgabe
  /<befehl2>   # Aufgabe
  /<befehl3>   # Aufgabe
  STOPP bei: <Bedingung>
  WARNUNG (nur bei autonomen Schleifen): Eine unbegrenzte Schleife verbraucht Abonnement-Guthaben –
  füge eine Maximalwiederholungs- oder Maxmalkosten-Begrenzung zusätzlich zum Abschlusssignal hinzu.

Vollständige Dokumentation lesen:
  commands/<befehl1>.md   (oder: /ecc-guide <befehl1>)

Beispiele

Katalog: /ecc-recipes → gibt die Familien-Tabelle und die Gesamtanzahl aus.

Abgleich: /ecc-recipes plane eine gesamte App im Voraus, dann automatischer Build mit adversariellem Review, bis fertig → Beste Übereinstimmung: loop-* (autonom) um gan-* oder santa-loop (adversariell) herum. Ausführungsreihenfolge: plan-prd dann loop-start rfc-dag --mode safe dann loop-status überwachen; STOPP, wenn alle Einheiten N aufeinanderfolgende Reviews bestehen (zusätzlich eine Maximalwiederholungs-Begrenzung einfügen, um den Verbrauch zu begrenzen).

Abgleich: /ecc-recipes behebe einen Fehler in meinem Go-Dienst → Beste Übereinstimmung: orch-fix-defect (reproduzieren, beheben, reviewen, committen). Alt: go-test dann go-build dann go-review. STOPP: Regressionstest grün und Review bestanden.

Nicht-Ziele

• Kein Ausführer – nur beratend.
• Keine tiefgehende Dokumentation pro Befehl – das ist ecc-guide.
• Keine Prompt-Umschreibung – das ist prompt-optimizer.
• Niemals hartcodierte Befehlszählungen oder Mitgliederlisten – immer live lesen.