Plan-Orchestrate

Plan Orchestrate

Überbrücke ein Plan-Dokument mit /orchestrate custom, indem ein fertig einfügbarer Befehl pro Schritt ausgegeben wird. Das Skill ist rein generativ – es führt /orchestrate nie aus. Der Benutzer fügt jede Zeile ein, wenn er bereit ist.

Wann aktivieren

• Der Benutzer hat ein mehrstufiges Plan-Dokument (PRD, RFC, Implementierungsplan) und möchte es über /orchestrate ausführen.
• 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 Überspringungsgrund – siehe den „Keine klaren Schritte“-Randfall 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 – Sprache des Reviewers; Standard ist auto (wird aus dem Projekt erkannt).
• --scope – begrenzt die ausgegebenen Schritte; Standard ist all.
• --dry-run – gibt nur die Zerlegung und Kettenbegründung aus; keine finalen Prompts.

Maßgebliche /orchestrate-Form (nicht abweichen)

{ORCH_CMD} custom "<agent1>,<agent2>,...,<agentN>" "<task-beschreibung>"

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

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

ECC-Installationsform und Namensraum

Zwei Installationsformen bestimmen das Präfix für sowohl den Schrägstrichbefehl als auch jeden Agentennamen. Beide MÜSSEN synchron bleiben – eine Form pro Ausgabe, niemals gemischt:

Sei <claude-home> das Claude-Code-Benutzerverzeichnis: ~/.claude unter macOS/Linux, %USERPROFILE%\.claude unter Windows. Löse es so auf, wie das Host-Betriebssystem das Benutzerverzeichnis auflöst (hartcodiere nicht ~).

Form	Erkennung	{ORCH_CMD}	Agentennamenformat
Plugin-Installation (2.0.0+)	<claude-home>/plugins/marketplaces/ecc/ existiert	/ecc:orchestrate	ecc:<name>
Legacy-Basisinstallation	Oben abwesend; Agentendateien unter <claude-home>/agents/	/orchestrate	<name>

Warum das wichtig ist: Bei der Plugin-Installation registrieren sich Agenten als ecc:tdd-guide. Nackte Namen erzwingen Fuzzy-Matching, das bei parallelen Aufrufen zeitweise fehlschlägt. Unter Legacy sind die präfixierten Formen nicht registriert und schlagen komplett fehl.

Verfügbarer Agentenkatalog (muss daraus auswählen)

Allgemein:

• planner – Anforderungsneufassung, Risikozerlegung, Schritteplanung
• architect – Architektur, Systemdesign, Refactoring-Vorschläge
• tdd-guide – Tests schreiben → implementieren → 80 %+ Abdeckung
• code-reviewer – generische Code-Überprüfung
• security-reviewer – Sicherheitsaudit, OWASP, Geheimnislecks
• 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 (selten geeignet für Planschritte)

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 zum Fehlschlag von /orchestrate. Vor dem Ausgeben gegen diese Liste prüfen.

Wie es funktioniert

Phase 0 – ECC-Modus + Sprache erkennen

1. <plan-doc-path> lesen. Wenn fehlend oder leer, melden und anhalten.

2. ECC-Installationsform einmal erkennen und in ECC_MODE einfrieren. Algorithmus (der Reihe nach ausführen, beim ersten Treffer anhalten):

   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 → Standard auf ECC_MODE=legacy und eine einzeilige Warnung am Anfang der Ausgabe ausgeben: > Warnung: ECC-Installation nicht erkennbar; standardmäßig Legacy-Form. Wenn du die Plugin-Installation verwendest, bearbeite die Präfixe manuell.
   4. Wenn beide Marker vorhanden sind (gemischte Installation), gewinnt plugin – der Plugin-Namensraum ist der einzige, der Agentennamen ohne Fuzzy-Matching auflöst.

   Von diesem Punkt an verwendet jede ausgegebene Zeile das passende Präfix für sowohl den Schrägstrichbefehl als auch jeden Agentennamen. Gib niemals beide Formen in derselben Ausgabe aus.

3. --lang auflösen. Bei auto eine polyglott-bewusste Erkennung ausführen:

   • Marker abfragen: 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.
   • Polyglott-Entscheidung: Wenn mehr als ein Marker übereinstimmt, wähle die Sprache, deren Quelldateien die anderen zahlenmäßig übertreffen (zähle via git ls-files, ohne 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. Die Phasen-2-Regeln 4 und 5 wandeln es zur Kettenzusammenstellung in code-reviewer / build-error-resolver um.

4. Ein PyTorch-Subprofil erkennen: Wenn lang=python und eine der Dateien pyproject.toml / requirements.txt / uv.lock eine Abhängigkeit von torch deklariert, setze pytorch=true. Dies betrifft nur die Auswahl der build-Kette (Phase-2-Regel unten); der Reviewer bleibt python-reviewer.

5. Alle im Plan deklarierten Agentennamen normalisieren: Wenn der Plantext Agenten in ihrer Plugin-Präfix-Form referenziert (z. B. ecc:tdd-guide), entferne das Präfix, um den nackten Katalognamen zu erhalten, bevor du Ketten validierst oder zusammenstellst. Die erneute Präfixierung erfolgt nur zur Ausgabezeit gemäß ECC_MODE (Phase 4). Lasse niemals einen vorpräfixierten Namen in die Kettenzusammenstellung einfließen – er würde im Plugin-Modus doppelt präfixiert.

Phase 1 – Schritte zerlegen

„Schritte-Einheiten“ in Prioritätsreihenfolge identifizieren:

1. Explizite Nummerierung: ## Schritt N / ### Phase N / ## N. ... / nummerierte Liste auf oberster Ebene.
2. Eine „Schritt“-Spalte in einer Tabelle.
3. ----getrennte Blöcke mit verbgeführten Überschriften.
4. Ansonsten jede H2 als einen Schritt behandeln.

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

Phase 2 – Kennzeichnen und Kette auswählen

Nach Absicht kennzeichnen (Mehrfachkennzeichnung erlaubt; Kette wird aus primärer + gestapelten sekundären Ketten erstellt):

Auslösewörter unten werden ohne Berücksichtigung der Groß-/Kleinschreibung 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.

Kennzeichnung	Auslösewörter	Standardkette
design	architektur, design, wählen, bewerten, RFC	planner,architect
plan	plan, aufteilung, meilenstein	planner
impl	implementieren, bauen, hinzufügen, erstellen, portieren	tdd-guide,<lang>-reviewer
test	test, abdeckung, e2e, integration	tdd-guide,e2e-runner
refactor	refaktorieren, 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, auth, geheimnis, OWASP, PII	security-reviewer,<lang>-reviewer
build	build, kompilieren, lint-fehler, CI	<lang>-build-resolver (fällt zurück auf build-error-resolver)
docs	docs, readme, codemap, changelog	doc-updater
lookup	nachschlagen, referenz, API-nutzung	docs-lookup
review	review, audit, verifizieren	<lang>-reviewer,code-reviewer
loop	schleife, autonom, watchmodus	loop-operator

Kettenzusammenstellungsregeln:

1. Primäre Kennzeichnungsauswahl: Wenn ein Schritt mit mehreren Kennzeichnungen übereinstimmt, ist die erste in der Tabellenreihenfolge (oben in der Tabelle = höchste Priorität) die primäre; die restlichen sind sekundäre. Die Zusammensetzungsregeln 2 und 3 unten behandeln spezifische Mehrfachkennzeichnungen explizit; andernfalls hänge sekundäre Ketten in der Kennzeichnungstabellenreihenfolge 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. Sonderfall: Wenn Phase 0 pytorch=true gesetzt hat, verwende für build-Ketten unabhängig von <lang> pytorch-build-resolver. Es gibt keinen python-build-resolver; --lang=python ohne pytorch=true wird zu build-error-resolver.
7. Null-Kennzeichnung-Schritte: Wenn kein Auslösewort übereinstimmt, setze die Kette auf code-reviewer und schreibe „keine Kennzeichnung übereinstimmend; standardmäßig reine Review-Kette“ unter „Kettenbegründung“.
8. Kettenlänge ≤ 4 nach Deduplizierung. Wenn überschritten, schwächste Kennzeichnung fallen lassen (lookup und docs zuerst).
9. planner und architect nicht in einer impl-Kette paaren (Verschwendung von Tokens). Nur bei design-Schritten paaren.
10. Mit impl, refactor oder migration gekennzeichnete Schritte 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. Regel 2s impl+security endet mit security-reviewer; Regel 3s impl+db endet mit <lang>-reviewer, weil database-reviewer die Migration bereits früher in der Kette bewacht). test- und build-Schritte werden durch ihre eigenen Prüfer (e2e-runner bzw. den Build-Resolver) bewacht und benötigen keinen zusätzlichen Reviewer.

Phase 3 – Aufgabenbeschreibung komprimieren

Jede ausgegebene <task-beschreibung> muss:

• In sich geschlossen sein (der erste Agent benötigt das Plan-Dokument nicht geöffnet).
• Mit [Plan: <pfad>#schritt-<id>] beginnen.
• 1–3 überprüfbare Akzeptanzkriterien enthalten.
• Eine Umfangsbegrenzung (Außerhalb des Umfangs: ...) nur enthalten, wenn der Plan eine für diesen Schritt deklariert. Wörtlich übernehmen. Wenn der Plan keine Umfangsangabe hat, den Satz vollständig weglassen – keinen erfinden.
• 200–600 Zeichen lang sein; eine Zeile; eingebettete " als \" maskiert; keine wörtlichen Zeilenumbrüche.

Phase 4 – Ausgabe

Markdown ausgeben unter Verwendung der durch ECC_MODE bestimmten Form. Die Ausgabe verwendet durchgängig eine Form – jedes {ORCH_CMD} und jeder Agentenname wird 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 Renderingsregeln:

• {ORCH_CMD} = /ecc:orchestrate unter plugin, /orchestrate unter legacy.
• {AGENT(name)} = ecc:<name> unter plugin, <name> unter legacy.
• Die „Kette“-Spalte der Übersichtstabelle verwendet die gleiche {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 über die gesamte Ausgabe hinweg einheitlich.

Ausgabestruktur:

# Plan-Orchestrate-Ergebnis

**Plan**: `<pfad>`
**Sprache**: `<erkannt-oder-angegeben>`
**ECC-Modus**: `<plugin | legacy>`
**Schritte**: <N>
**Umfang**: <alle | schritt:n | bereich:a-b>

## Schritte-Übersicht

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

---

## Schritt 1 – <titel>

**Absicht**: <1–3 Sätze>
**Kennzeichnungen**: <a, b>
**Kettenbegründung**: <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#schritt-1] <komprimierte aufgabenbeschreibung>; Akzeptanz: <1–3 punkte>; Außerhalb des umfangs: <…>"
```

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

Einen abschließenden „Batch-Ausführung“-Block anhängen, der die Befehle jedes Schritts in der Reihenfolge zusammenfasst, damit der Benutzer sie alle auf einmal einfügen kann. Den Batch-Block im Übersichtsmodus überspringen (siehe Randfall „Großer Plan“): Wenn nur die Übersichtstabelle ausgegeben wird, gibt es keine Befehle pro Schritt, die zusammengefasst werden könnten.

Phase 5 – Selbstprüfung (vor dem Ausgeben ausführen)

• Jeder Agent in jeder Kette stammt aus dem Katalog (nach dem Entfernen aller ecc:-Präfixe, die im Plan aufgetaucht sind; siehe Phase 0, Schritt 5).
• Aufgelöstes {ORCH_CMD} und jedes aufgelöste {AGENT(...)} verwenden die gleiche Form (plugin oder legacy) – niemals gemischt in einer Ausgabe.
• Keine # Plugin-Form / # Legacy-Form-Annotationen und keine Anweisungen zum Entfernen von Präfixen bleiben in der gerenderten Ausgabe.
• Keine erfundenen --mode / --gate / --agents=...-Felder.
• Jede Aufgabenbeschreibung ist einzeilig, doppelt angeführt, mit maskierten eingebetteten ".
• Jede Aufgabenbeschreibung beginnt mit [Plan: <pfad>#schritt-<id>] und enthält Akzeptanzkriterien (1–3 Punkte). Die Klausel Außerhalb des Umfangs: ist nur vorhanden, wenn sie aus dem Plan übernommen wurde.
• Kein doppelter Agent in einer Kette nach Deduplizierung in Phase 2.
• Kettenlänge ≤ 4.
• Mit impl/refactor/migration gekennzeichnete Schritte enden mit einem Reviewer-Klassen-Agenten (…

[truncated for translation]