Plan Orchestrate

Was macht Plan Orchestrate?

Überbrücke ein Plan-Dokument mit /orchestrate custom, indem pro Schritt ein einfügefertiger Aufruf ausgegeben wird. Die Fähigkeit ist nur generativ – sie führt nie selbst /orchestrate aus. Der Benutzer fügt jede Zeile ein, wenn er bereit ist.

Wann aktivieren

• Der Benutzer hat ein mehrschrittiges Plan-Dokument (PRD, RFC, Implementierungsplan) und möchte es über /orchestrate steuern.
• Der Benutzer sagt "orchestriere diesen Plan", "gib mir Orchestrate-Prompts für jeden Schritt", "erstelle Ketten für diesen Plan".
• Ein schrittweiser Plan existiert, aber der Benutzer möchte nicht manuell Agenten pro Schritt auswählen.

Überspringen, wenn:

• Die Arbeit ein einzelner Ad-hoc-Schritt ist → rufe direkt /orchestrate custom auf.
• Der Plan unlesbar oder leer ist. Fehlende explizite Nummerierung allein ist kein Grund zum Überspringen – siehe den Sonderfall "Keine klaren Schritte" unten.

Eingaben

<plan-doc-path> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:<n>|range:<a>-<b>] [--dry-run]

• <plan-doc-path> – erforderlich; relativer oder absoluter Pfad (@docs/... akzeptiert).
• --lang – Sprachvariante des Reviewers; Standard ist auto (aus dem Projekt erkannt).
• --scope – schränkt die ausgegebenen Schritte ein; Standard ist all.
• --dry-run – nur Zerlegung und Kettenbegründung ausgeben, keine endgültigen Prompts.

Autoritative Form von /orchestrate (nicht abweichen)

{ORCH_CMD} custom "<agent1>,<agent2>,...,<agentN>" "<Aufgabenbeschreibung>"

Wobei {ORCH_CMD} in Phase 0 bestimmt wird (siehe unten). Der Befehl in der ausgegebenen Ausgabe verwendet immer eine konkrete Form – nie beide, nie einen Platzhalter.

• custom ist eine sequenzielle Kette; jedes Agenten-HANDOFF speist den nächsten.
• Kommagetrennte Agentenliste. Keine Leerzeichen bevorzugt; ein Leerzeichen toleriert.
• Es gibt keine Flags --mode / --gate / --agents=... – erfinde sie nie.
• Agentennamen stammen aus dem Katalog dieser Fähigkeit. Eingebettete doppelte Anführungszeichen in der Aufgabenbeschreibung werden als \" maskiert.

ECC-Installationsform und Namensgebung

Zwei Installationsformen bestimmen das Präfix für sowohl den Slash-Befehl als auch jeden Agentennamen. Die beiden MÜSSEN synchron bleiben – eine Form pro Ausgabe, niemals gemischt:

Sei <claude-home> das Claude Code Home-Verzeichnis: ~/.claude auf macOS/Linux, %USERPROFILE%\.claude auf Windows. Löse es so auf, wie die Host-Plattform das Home-Verzeichnis des Benutzers auflöst (hart codiere nicht ~).

Form	Erkennung	{ORCH_CMD}	Agentenname-Format
Plugin-Installation (2.0.0+)	<claude-home>/plugins/marketplaces/ecc/ existiert	/ecc:orchestrate	ecc:<name>
Legacy-Bare-Installation	Obiges fehlt; Agentendateien unter <claude-home>/agents/	/orchestrate	<name>

Warum das wichtig ist: Unter der Plugin-Installation registrieren sich Agenten als ecc:tdd-guide. Bare-Namen erzwingen vage Übereinstimmungen, die bei parallelen Aufrufen gelegentlich fehlschlagen. In der Legacy-Form sind die präfixierten Formen nicht registriert und schlagen sofort fehl.

Verfügbarer Agentenkatalog (muss daraus ausgewählt werden)

Allgemein:

• planner – Anforderungsneuformulierung, Risikozerlegung, Schrittablauf
• architect – Architektur, Systemdesign, Refactoring-Vorschläge
• tdd-guide – Tests schreiben → implementieren → 80 %+ Abdeckung
• code-reviewer – generische Code-Review
• security-reviewer – Sicherheitsaudit, OWASP, Geheimnisleckage
• refactor-cleaner – toter Code, Duplikate, knip-artige Bereinigung
• doc-updater – Dokumentation, Codemap, README
• docs-lookup – API-Nachschlagewerke für Drittanbieter-Bibliotheken (Context7)
• e2e-runner – End-to-End-Test-Orchestrierung
• database-reviewer – PostgreSQL-Schema, Migration, Leistung
• harness-optimizer – lokale Agenten-Harness-Konfiguration
• loop-operator – langlaufende autonome Schleifen
• chief-of-staff – mehrkanalige Triage (passt selten zu Planschritten)

Build-Fehlerbeheber:

• 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 / cpp-reviewer / java-reviewer / kotlin-reviewer / flutter-reviewer

Ein falsch geschriebener Agentenname führt zu einem Fehler in /orchestrate. Überprüfe vor der Ausgabe diese Liste.

So funktioniert es

Phase 0 – ECC-Modus + Sprache erkennen

1. Lese <plan-doc-path>. Falls fehlend oder leer, melden und stoppen.

2. Erkenne die ECC-Installationsform einmal und friere sie als ECC_MODE ein. Algorithmus (in Reihenfolge ausführen, bei erstem Treffer stoppen):

   1. Wenn <claude-home>/plugins/marketplaces/ecc/ existiert → ECC_MODE=plugin.
   2. Sonst, wenn <claude-home>/agents/ existiert und mindestens eine ECC-Agentendatei enthält (z. B. tdd-guide.md, code-reviewer.md) → ECC_MODE=legacy.
   3. Sonst → standardmäßig ECC_MODE=legacy setzen und eine einzeilige Warnung am Anfang der Ausgabe ausgeben: > Warnung: ECC-Installation nicht erkannt; Standard-Legacy-Form wird verwendet. Wenn Sie die Plugin-Installation verwenden, bearbeiten Sie die Präfixe manuell.
   4. Wenn beide Marker vorhanden sind (gemischte Installation), gewinnt plugin – der Plugin-Namensraum ist der einzige, der Agentennamen ohne vage Übereinstimmungen auflöst.

   Ab diesem Punkt verwendet jede ausgegebene Zeile das entsprechende Präfix für sowohl den Slash-Befehl als auch jeden Agentennamen. Gib nie beide Formen in derselben Ausgabe aus.

3. Löse --lang auf. Bei auto wird eine polyglotte Erkennung ausgefü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.
   • Polyglot-Tie-Break: Wenn mehr als ein Marker übereinstimmt, wähle die Sprache, deren Quelldateien die anderen zahlenmäßig überwiegen (zählen über git ls-files, ausschließlich vendor/, node_modules/, dist/, build/, .venv/, generierte Dateien und offensichtliche Test-Fixtures). Bei Gleichstand oder wenn keine Sprache 60 % der Quelldateien überschreitet, setze lang=unknown.
   • Kein Marker gefunden → setze lang=unknown.
   • lang=unknown ist ein Sentinel – es ist kein Agentenname. Phase 2, Regeln 4 und 5, wandeln es zur Kettenkompositionszeit in code-reviewer / build-error-resolver um.

4. Erkenne ein PyTorch-Unterprofil: wenn lang=python und eine der Dateien pyproject.toml / requirements.txt / uv.lock eine Abhängigkeit von torch deklariert, setze pytorch=true. Dies wirkt sich nur auf die Auswahl der build-Kette aus (Phase 2-Regel unten); der Reviewer bleibt python-reviewer.

5. Normalisiere alle im Plan deklarierten Agentennamen: wenn der Plantext Agenten in ihrer Plugin-präfixierten Form referenziert (z. B. ecc:tdd-guide), entferne das Präfix, um den Bare-Katalognamen zu erhalten, bevor Ketten validiert oder komponiert werden. Die erneute Präfixierung erfolgt erst zur Ausgabezeit gemäß ECC_MODE (Phase 4). Lass niemals einen bereits präfixierten Namen in die Kettenkomposition einfließen – dies würde im Plugin-Modus eine Doppelpräfixierung verursachen.

Phase 1 – Schritte zerlegen

Identifiziere "Schritteinheiten" in Prioritätsreihenfolge:

1. Explizite Nummerierung: ## Schritt N / ### Phase N / ## N. ... / geordnete Liste auf oberster Ebene.
2. Eine "Schritt"-Spalte in einer Tabelle.
3. Mit --- getrennte Blöcke mit verbgeführten Überschriften.
4. Andernfalls behandle jede H2 als einen Schritt.

Pro Schritt extrahiere id (1-basiert), title (≤ 80 Zeichen), intent (1–3 Sätze), tags.

Phase 2 – Taggen und Kette auswählen

Tagge nach Absicht (Mehrfach-Taggen erlaubt; Kette aus primärem + gestapelten sekundären Tags aufgebaut):

Die folgenden Triggerwörter werden unabhängig von der Groß-/Kleinschreibung abgeglichen. Mehrsprachige Pläne werden unterstützt, indem die Wortstämme in jeder Sprache abgeglichen werden, solange die Bedeutung mit den aufgelisteten englischen Triggerwörtern übereinstimmt.

Tag	Triggerwörter	Standardkette
design	Architektur, Design, wählen, bewerten, RFC	planner,architect
plan	Plan, Aufschlüsselung, Meilenstein	planner
impl	implementieren, bauen, hinzufügen, erstellen, portieren	tdd-guide,<lang>-reviewer
test	testen, Abdeckung, e2e, Integration	tdd-guide,e2e-runner
refactor	umstrukturieren, bereinigen, deduplizieren, aufteilen	architect,refactor-cleaner,<lang>-reviewer
migration	migrieren, aktualisieren, umschreiben, portieren	architect,tdd-guide,<lang>-reviewer
db	Schema, Migration, Index, SQL, Postgres, Alembic, SQLModel	database-reviewer,<lang>-reviewer
security	verschlüsseln, Authentifizierung, Geheimnis, OWASP, PII	security-reviewer,<lang>-reviewer
build	bauen, kompilieren, Lint-Fehler, CI	<lang>-build-resolver (fällt zurück auf build-error-resolver)
docs	Dokus, README, Codemap, Changelog	doc-updater
lookup	nachschlagen, Referenz, API-Nutzung	docs-lookup
review	überprüfen, auditieren, verifizieren	<lang>-reviewer,code-reviewer
loop	Schleife, autonom, Watchdog	loop-operator

Kettenkompositionsregeln:

1. Primäre Tag-Auswahl: wenn ein Schritt mehrere Tags trifft, ist das erste in der Tabellenreihenfolge (Tabellenanfang = höchste Priorität) das primäre; der Rest sind sekundäre. Die Kompositionsregeln 2 und 3 unten behandeln bestimmte Mehrfach-Tag-Kombinationen explizit; andernfalls füge sekundäre Ketten in der Tag-Tabellenreihenfolge an.
2. impl + security → tdd-guide,<lang>-reviewer,security-reviewer.
3. impl + db → tdd-guide,database-reviewer,<lang>-reviewer.
4. Dedupliziere die resultierende Kette (behalte das erste Vorkommen). Z. B. würde review + lang=unknown nach Regel 5 code-reviewer,code-reviewer ergeben; Deduplizierung reduziert es auf code-reviewer.
5. <lang>-reviewer wird zu code-reviewer, wenn lang=unknown.
6. <lang>-build-resolver wird zu build-error-resolver, wenn lang=unknown. Spezialfall: wenn Phase 0 pytorch=true gesetzt hat, verwende pytorch-build-resolver für build-Ketten unabhängig von <lang>. 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 unter "Begründung der Kette" kein Tag gefunden; standardmäßig Nur-Review-Kette.
8. Kettenlänge ≤ 4 nach Deduplizierung. Bei Überschreitung entferne das schwächste Tag (lookup und docs zuerst).
9. Kombiniere planner und architect nicht in einer impl-Kette (Token-Verschwendung). Kombiniere sie nur bei design-Schritten.
10. Schritte, die mit impl, refactor oder migration getaggt sind, enden mit einem Reviewer-Klassen-Agenten – einem von <lang>-reviewer, code-reviewer, security-reviewer oder database-reviewer. Der domänenspezifischste Reviewer gewinnt die Endposition (z. B. endet Regel 2's impl+security mit security-reviewer; Regel 3's impl+db endet mit <lang>-reviewer, weil database-reviewer die Migration bereits früher in der Kette überwacht). test- und build-Schritte werden durch ihre eigenen Validierer (e2e-runner bzw. den Build-Resolver) überwacht und benötigen keinen zusätzlichen Reviewer.

Phase 3 – Aufgabenbeschreibung komprimieren

Jede ausgegebene <Aufgabenbeschreibung> muss:

• In sich geschlossen sein (der erste Agent benötigt das Plan-Dokument nicht geöffnet).
• Mit [Plan: <path>#step-<id>] beginnen.
• 1–3 überprüfbare Abnahmekriterien enthalten.
• Eine Bereichsbegrenzung (Außerhalb des Rahmens: ...) enthalten nur, wenn der Plan eine für diesen Schritt deklariert. Wörtlich übernehmen. Wenn der Plan keine Aussage zu außerhalb des Rahmens hat, lasse die Klausel vollständig weg – erfinde keine.
• 200–600 Zeichen lang sein; eine Zeile; eingebettete " maskiert als \"; keine wörtlichen Zeilenumbrüche.

Phase 4 – Ausgabe

Gib Markdown unter Verwendung der durch ECC_MODE bestimmten Form aus. Die Ausgabe verwendet durchgängig eine Form – jeder {ORCH_CMD} und jeder Agentenname werden mit dem passenden Präfix aus Phase 0 gerendert. Gib nicht beide Formen aus; füge keine Anweisungen wie "dies ist die Plugin-Form" / "entferne das Präfix" in die gerenderte Ausgabe ein.

Konkrete Rendering-Regeln:

• {ORCH_CMD} = /ecc:orchestrate unter plugin, /orchestrate unter legacy.
• {AGENT(name)} = ecc:<name> unter plugin, <name> unter legacy.
• Die Spalte "Kette" in der Übersichtstabelle verwendet dieselbe {AGENT(name)}-Darstellung.
• Bash-Blöcke pro Schritt enthalten nur den ausführbaren Befehl. Keine Kommentare wie # Plugin-Form oder # Legacy-Form – die Form ist implizit und im gesamten Output einheitlich.

Ausgabestruktur:

# Plan-Orchestrate-Ergebnis

**Plan**: `<path>`
**Sprache**: `<erkannt-oder-angegeben>`
**ECC-Modus**: `<plugin | legacy>`
**Schritte**: <N>
**Bereich**: <all | step:n | range:a-b>

## Schritte-Übersicht

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

---

## Schritt 1 — <Titel>

**Absicht**: <1–3 Sätze>
**Tags**: <a, b>
**Begründung der Kette**: <warum diese Kette; welcher Agent schließt den Kreislauf>

```bash
{ORCH_CMD} custom "{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}" "[Plan: docs/foo.md#step-1] <komprimierte Aufgabenbeschreibung>; Abnahme: <1–3 Punkte>; Außerhalb des Rahmens: <…>"
```

Die Notation {ORCH_CMD} und {AGENT(...)} oben beschreibt die Substitution, die diese Fähigkeit zur Laufzeit durchführt. Das tatsächlich ausgegebene Markdown enthält die aufgelösten Zeichenfolgen, niemals die Platzhalter.

Füge einen abschließenden "Batch-Ausführung"-Block an, der die Befehle jedes Schrittes der Reihe nach zusammenfasst, damit der Benutzer sie alle auf einmal einfügen kann. Überspringe den Batch-Block im Nur-Übersichtsmodus (siehe Sonderfall "Großer Plan"): wenn nur die Übersichtstabelle ausgegeben wird, gibt es keine schrittspezifischen Befehle zum Aggregieren.

Phase 5 – Selbstprüfung (vor der Ausgabe durchführen)

• Jeder Agent in jeder Kette stammt aus dem Katalog (nachdem ein eventuelles ecc:-Präfix entfernt wurde, das im Plan erschien; siehe Phase 0 Schritt 5).
• Aufgelöster {ORCH_CMD} und jeder aufgelöste {AGENT(...)} verwenden die gleiche Form (plugin oder legacy) – nie gemischt in einer Ausgabe.
• Keine Annotationen # Plugin-Form / # Legacy-Form und keine Anweisungen wie "entferne das Präfix" sind in der gerenderten Ausgabe verblieben.
• Keine erfundenen Felder --mode / --gate / --agents=....
• Jede Aufgabenbeschreibung ist einzeilig, in doppelten Anführungszeichen, mit maskierten eingebetteten ".
• Jede Aufgabenbeschreibung beginnt mit [Plan: <path>#step-<id>] und enthält Abnahme (1–3 Punkte). Die Klausel Außerhalb des Rahmens: ist nur vorhanden, wenn sie aus dem Plan übernommen wurde.
• Kein doppelter Agent in einer Kette nach Phase 2-Deduplizierung.
• Kettenlänge ≤ 4.
• Schritte, die mit impl/refactor/migration getaggt sind, enden mit einem Agenten der Reviewer-Klasse (siehe Phase 2 Regel 10).