• — erforderlich; relativer oder absoluter Pfad (@docs/... wird akzeptiert).
• --lang — Sprachvariante des Prüfers; Standardwert ist „auto“ (wird aus dem Projekt ermittelt).
• --scope — begrenzt die ausgegebenen Schritte; Standardwert ist „all“.
• --dry-run — gibt nur die Zerlegung und die Begründung der Kette aus; gibt keine abschließenden Eingabeaufforderungen aus.

Maßgebliche /orchestrate -Form (nicht abweichen)

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

Wobei {ORCH_CMD} in Phase 0 festgelegt wird (siehe unten). Die Befehlszeichenfolge in der ausgegebenen Ausgabe verwendet immer eine konkrete Form – niemals beide, niemals einen Platzhalter.

• „custom“ ist eine sequenzielle Kette; das HANDOFF jedes Agenten speist den nächsten.
• Durch Kommas getrennte Agentenliste. Leerzeichen werden nicht bevorzugt; ein Leerzeichen wird toleriert.
• Es gibt keine Flags wie --mode / --gate / --agents=... – erfinden Sie diese niemals.
• Agentennamen stammen aus dem Katalog dieses Skills. Eingebettete doppelte Anführungszeichen in der Aufgabenbeschreibung werden als \" maskiert.

ECC-Installationsform und Namensraum

Zwei Installationsformate bestimmen das Präfix sowohl für den Slash-Befehl als auch für jeden Agenten-Namen. Die beiden MÜSSEN synchron bleiben – ein Format pro Ausgabe, niemals gemischt:

Lassen Sie das Claude-Code-Home-Verzeichnis bezeichnen: ~/.claude unter macOS/Linux, %USERPROFILE%\.claude unter Windows. Lösen Sie es so auf, wie die Host-Plattform das Benutzer-Home-Verzeichnis auflöst ( ~ nicht fest codieren).

Warum das wichtig ist: Bei der Plugin-Installation registrieren sich Agenten als „everything-claude-code:tdd-guide“. Bare-Namen erzwingen einen unscharfen Abgleich, der bei parallelen Aufrufen zeitweise fehlschlägt. Bei der Legacy-Installation werden die Formen mit Präfix nicht registriert und schlagen sofort fehl.

Verfügbarer Agentenkatalog (Auswahl muss aus diesen erfolgen)

Allgemein:

• Planner – Neuformulierung von Anforderungen, Risikozerlegung, Schrittplanung
• architect — Architektur, Systemdesign, Refactoring-Vorschläge
• tdd-guide – Tests schreiben → implementieren → 80 %+ Testabdeckung
• Code-Reviewer – allgemeine Code-Überprüfung
• Sicherheitsprüfer — Sicherheitsaudit, OWASP, Aufdeckung von Geheimnissen
• Refactor-Cleaner – toter Code, Duplikate, Bereinigung der Knip-Klasse
• Dok-Aktualisierer — Dokumentation, Codemap, README
• docs-lookup – API-Abfragen für Bibliotheken von Drittanbietern (Context7)
• e2e-runner – Koordination von End-to-End-Tests
• database-reviewer – PostgreSQL-Schema, Migration, Leistung
• harness-optimizer – Konfiguration des lokalen Agent-Harnesses
• loop-operator – Lang laufende autonome Schleifen
• chief-of-staff — Multi-Channel-Triage (selten für Plan-Schritte geeignet)

Lösungen für Build-Fehler:

• build-error-resolver (generisch) / cpp-build-resolver / go-build-resolver / java-build-resolver / kotlin-build-resolver / rust-build-resolver / pytorch-build-resolver

Code-Reviewer:

• Python-Reviewer / TypeScript-Reviewer / Go-Reviewer / Rust-Reviewer / C++-Reviewer / Java-Reviewer / Kotlin-Reviewer / Flutter-Reviewer

Ein falsch geschriebener Agentenname führt zu einem Fehler bei /orchestrate. Bitte vor der Ausgabe anhand dieser Liste überprüfen.

So funktioniert es

Phase 0 – ECC-Modus und Sprache erkennen

1. Lesen . Falls fehlend oder leer, melden und abbrechen.

2. Ermittle die ECC-Installationsform einmalig und lege sie als ECC_MODE fest. Algorithmus (der Reihe nach ausführen, bei erster Übereinstimmung anhalten):

   1. Wenn /plugins/marketplaces/everything-claude-code/ existiert → ECC_MODE=plugin.
   2. Andernfalls: Wenn /agents/ existiert und mindestens eine ECC-Agent-Datei enthält (z. B. tdd-guide.md, code-reviewer.md) → ECC_MODE=legacy.
   3. Andernfalls → Standardwert ECC_MODE=legacy und Ausgabe einer einzeiligen Warnung am Anfang der Ausgabe: > Warnung: ECC-Installation konnte nicht erkannt werden; Standardmäßig wird die Legacy-Form verwendet. Wenn Sie die Plugin-Installation verwenden, bearbeiten Sie die Präfixe manuell.
   4. Wenn beide Marker vorhanden sind (gemischte Installation), hat das Plugin Vorrang – der Plugin-Namespace ist der einzige, der Agentennamen ohne unscharfe Übereinstimmung auflöst.

   Ab diesem Zeitpunkt verwendet jede ausgegebene Zeile das passende Präfix sowohl für den Slash-Befehl als auch für jeden Agentennamen. Es dürfen niemals beide Formen in derselben Ausgabe erscheinen.

3. Auflösung von `--lang`. Bei der Einstellung „auto“ wird eine polyglotte Erkennung durchgeführt:

   • Marker prüfen: pyproject.toml / uv.lock / requirements.txt → Python; package.json → TypeScript; go.mod → Go; Cargo.toml → Rust; CMakeLists.txt oder *.cpp auf oberster Ebene → cpp; pom.xml / build.gradle (Java) → java; build.gradle.kts oder Kotlin auf oberster Ebene → kotlin; pubspec.yaml → flutter.
   • Entscheidung bei mehreren Sprachen: Wenn mehr als ein Marker übereinstimmt, wähle die Sprache, deren Quelldateien die anderen zahlenmäßig übertreffen (Zählung über `git ls-files`, unter Ausschluss von `vendor/`, `node_modules/`, `dist/`, `build/`, `.venv/`, generierten Dateien und offensichtlichen Test-Fixtures). Bei Gleichstand oder wenn keine Sprache mehr als 60 % der Quelldateien ausmacht, setze lang=unknown.
   • Es wurde kein Marker gefunden → setze lang=unknown.
   • lang=unknown ist ein Sentinel – es handelt sich nicht um einen Agenten-Namen. Die Regeln 4 und 5 der Phase 2 wandeln ihn zum Zeitpunkt der Kettenzusammenstellung in einen Code-Reviewer bzw. Build-Fehler-Beheber um.

4. Erkenne ein PyTorch-Unterprofil: Wenn lang=python gilt und in einer der Dateien pyproject.toml, requirements.txt oder uv.lock eine Abhängigkeit von torch deklariert ist, setze pytorch=true. Dies wirkt sich nur auf die Auswahl der Build-Kette aus (Regel der Phase 2 unten); der Prüfer bleibt python-reviewer.

5. Normalisieren Sie alle im Plan deklarierten Agenten-Namen: Wenn der Plan-Text Agenten in ihrer mit einem Plugin-Präfix versehenen Form referenziert (z. B. everything-claude-code:tdd-guide), entfernen Sie das Präfix, um den reinen Katalognamen zu erhalten, bevor Sie Ketten validieren oder zusammenstellen. Das erneute Voranstellen des Präfixes erfolgt erst zum Zeitpunkt der Ausgabe gemäß ECC_MODE (Phase 4). Ein Name mit vorangestelltem Präfix darf niemals in die Kettenzusammenstellung gelangen – dies würde im Plugin-Modus zu einem doppelten Präfix führen.

Phase 1 – Schritte zerlegen

Identifizieren Sie „Schritteinheiten“ in der Reihenfolge ihrer Priorität:

1. Explizite Nummerierung: ## Schritt N / ### Phase N / ## N. ... / geordnete Liste auf oberster Ebene.
2. Eine Spalte „Schritt“ in einer Tabelle.
3. ----getrennte Blöcke mit verbengeführten Überschriften.
4. Andernfalls wird jede H2-Überschrift als ein Schritt behandelt.

Pro Schritt ID (1-basiert), Titel (≤ 80 Zeichen), Absicht (1–3 Sätze) und Tags extrahieren.

Phase 2 – Taggen und Kette bilden

Nach Absicht taggen (Mehrfach-Tags zulässig; Kette aus Primär-Tag und gestapelten Sekundär-Tags):

Die folgenden Auslösewörter werden groß-/kleinschreibungsunabhängig abgeglichen. Mehrsprachige Pläne werden unterstützt, indem die Wortstämme in jeder Sprache abgeglichen werden, solange die Bedeutung mit den aufgeführten englischen Auslösewörtern übereinstimmt.

Regeln für die Zusammensetzung von Ketten:

1. Auswahl des primären Tags: Wenn ein Schritt mehreren Tags entspricht, ist das erste in der Reihenfolge der Tabelle (oben in der Tabelle = höchste Priorität) das primäre; die übrigen sind sekundär. Die folgenden Zusammensetzungsregeln 2 und 3 behandeln bestimmte Kombinationen mehrerer Tags explizit; andernfalls werden sekundäre Ketten in der Reihenfolge der Tag-Tabelle angehängt.
2. impl + security → tdd-guide,-reviewer,security-reviewer.
3. impl + db → tdd-guide,database-reviewer,-reviewer.
4. Entdoppeln Sie die resultierende Kette (behalten Sie das erste Vorkommen bei). Beispielsweise würde „review + lang=unknown“ nach Regel 5 zu „code-reviewer,code-reviewer“ führen; durch die Entdopplung wird dies zu „code-reviewer“ zusammengefasst.
5. -reviewer wird zu code-reviewer aufgelöst, wenn lang=unknown ist.
6. -build-resolver wird zu build-error-resolver aufgelöst, wenn lang=unknown ist. Sonderfall: Wenn in Phase 0 pytorch=true gesetzt wurde, verwende pytorch-build-resolver für Build- Ketten, unabhängig von . Es gibt keinen „python-build-resolver“; „--lang=python“ ohne „pytorch=true“ wird zu „build-error-resolver“ aufgelöst.
7. Schritte ohne Tag: Wenn kein Triggerwort übereinstimmt, setze die Kette auf „code-reviewer“ und schreibe „kein Tag gefunden“; Standardkette „review-only“ gemäß „Begründung der Kette“.
8. Kettenlänge ≤ 4 nach Deduplizierung. Bei Überschreitung das schwächste Tag verwerfen (zuerstLookup und Docs ).
9. Planer und Architekt nicht in einer „impl“-Kette kombinieren (Tokenverschwendung). Kombiniere sie nur bei Design -Schritten.
10. Schritte mit den Tags „impl“, „refactor“ oder „migration“ enden mit einem Agenten der Reviewer-Klasse – entweder „-reviewer“, „code-reviewer“, „security-reviewer“ oder „database-reviewer“. Der domänenspezifischste Prüfer erhält die letzte Position (z. B. endet „impl+security“ aus Regel 2 mit „security-reviewer“; „impl+db“ aus Regel 3 endet mit „-reviewer“, da „database-reviewer“ die Migration bereits früher in der Kette abschließt). Test- und Build-Schritte werden durch ihre eigenen Validatoren (e2e-runner bzw. den Build-Resolver) gesteuert und erfordern keinen zusätzlichen Prüfer.

Phase 3 – Aufgabenbeschreibung komprimieren

Jedes ausgegebene muss:

• In sich geschlossen sein (der erste Agent muss das Plandokument nicht geöffnet haben).
• mit [Plan: #step-] beginnen.
• 1–3 überprüfbare Akzeptanzkriterien enthalten.
• Enthalten Sie eine Geltungsbereichsangabe (Außerhalb des Geltungsbereichs: ...) nur, wenn der Plan eine solche für diesen Schritt festlegt. Übernehmen Sie diese wörtlich. Wenn der Plan keine Angabe zum Geltungsbereich enthält, lassen Sie die Klausel vollständig weg – erfinden Sie keine.
• Umfang: 200–600 Zeichen; eine Zeile; eingebettete „“ als \“ maskiert; keine literalen Zeilenumbrüche.

Phase 4 – Ausgabe

Geben Sie Markdown in der durch ECC_MODE festgelegten Form aus. Die Ausgabe verwendet durchgehend ein Format – jedes {ORCH_CMD} und jeder Agentenname wird mit dem entsprechenden Präfix aus Phase 0 dargestellt. Geben Sie nicht beide Formate aus; fügen Sie keine Anweisungen wie „dies ist das Plugin-Format“ oder „Präfix entfernen“ in die gerenderte Ausgabe ein.

Konkrete Darstellungsregeln:

• {ORCH_CMD} = /everything-claude-code:orchestrate unter „Plugin“, /orchestrate unter „Legacy“.
• {AGENT(name)} = „everything-claude-code: “ unter „plugin“, unter „Legacy“.
• Die Spalte „Chain“ der Übersichtstabelle verwendet dieselbe {AGENT(name)} -Darstellung.
• Die Bash-Blöcke pro Schritt enthalten nur den ausführbaren Befehl. Keine Kommentare im Format # plugin oder # legacy – das Format ist implizit und einheitlich über die gesamte Ausgabe hinweg.

Ausgabestruktur:

# Plan-Orchestrate Ergebnis

**Plan**: ``
**Sprache**: ``
**ECC-Modus**: ``
**Schritte**: 
**Umfang**: 

## Übersicht über die Schritte

| # | Titel | Tags | Chain |
|---|---|---|---|
| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |
| ... | | | |

---

## Schritt 1 – „