orc-pipeline

Orchestrator-Pipeline (gemeinsame Engine)

Die orch-* Skills sind dünne Hüllen. Sie implementieren keine Arbeit neu – sie klassifizieren die Anfrage, wählen aus, welche Phasen dieser Pipeline ausgeführt werden, und delegieren jede Phase an einen vorhandenen ECC-Agenten oder Befehl. Diese Datei ist jene Pipeline.

Rufen Sie einen Operationsskill auf (orch-add-feature, orch-fix-defect, …) anstatt diese Engine direkt zu verwenden. Diese Datei ist die Referenz, auf die sie verweisen.

Wann verwenden

• Indirekt geladen, sobald ein orch-* Operationsskill ausgeführt wird.
• Direkt nur lesen, wenn eine neue Operation zur Familie hinzugefügt wird oder die gemeinsamen Phasen, Gates oder die Agentenzuordnung angepasst werden.

Die Operationsfamilie

Skill	Operation	Auslöser	Erster Schritt
orch-add-feature	feature	Funktionalität existiert noch nicht	Recherche + Planung einer neuen Teilaufgabe
orch-change-feature	tweak	Funktioniert, aber gewünschtes Verhalten weicht ab	Vorhandenes Verhalten und seine Tests anpassen
orch-fix-defect	fix	Defekt; Verhalten ist falsch	Als fehlschlagenden Test reproduzieren, dann beheben
orch-refine-code	refactor	Verhalten bleibt, Struktur verbessert sich	Umstrukturieren, während Tests grün bleiben
orch-build-mvp	mvp	Bootstrap aus einem Design-/Spezifikationsdokument	Dokument einlesen → vertikale Teilaufgaben

Diese Hüllen komponieren vorhandene ECC-Befehle, anstatt sie zu ersetzen: /feature-dev, /plan, /code-review, /build-fix, /refactor-clean und /gan-build, plus den tdd-workflow Skill. Die orch-* Familie fügt den gemeinsamen Größenklassifizierer und die beiden Gates hinzu, sodass ein Dach alle fünf Operationen konsistent abdeckt.

Schritt 0 – Größe klassifizieren (right-sizing)

Der Umfang der Zeremonie skaliert mit dem Schadensradius. Bewerten Sie die Anfrage anhand von drei Signalen, nehmen Sie die höchste Stufe, die ein Signal erreicht, und geben Sie das Ergebnis in einer Zeile aus, damit der Benutzer es überschreiben kann:

Stufe	Berührte Dateien	Neue Abhängigkeit / Vertrag	Design-Mehrdeutigkeit	Ausgeführte Phasen
trivial	1, wenige Zeilen	keine	keine – die Änderung ist offensichtlich	4 → 5 → 6
small	1 Datei / 1 Funktion	keine	klar, sobald man den Code liest	(1 leicht) → 4 → 5 → 6
standard	2–5 Dateien	vielleicht ein neues internes Modul	eine echte Entscheidung zu treffen	1 → 2 → 4 → 5 → 6
large	viele / übergreifend	neue externe Abhängigkeit, öffentliche API oder ein Spezifikationsdokument	mehrere offene Fragen	1 → 2 → (3) → 4 → 5 → 6

Phase 0 (Intake) läuft immer und ist in der obigen Spalte weggelassen. Der Tie-Breaker: Alles, was einen Sicherheitstrigger (unten) oder eine öffentliche API / einen Vertrag berührt, ist mindestens standard, unabhängig von der Dateianzahl.

Die Phasen

Jede Phase delegiert – sie führt die Arbeit nicht inline aus.

• 0. Intake – die Anfrage neu formulieren. Für orch-build-mvp das Spezifikations-/Design- Dokument lesen und Umfang, festgelegte Entscheidungen und eine Feature-Liste extrahieren.
• 1. Research & Reuse – gemäß rules/common/development-workflow.md: gh search repos / gh search code, dann Context7 / Anbieterdokumente, dann Paketregister, dann Exa. Bevorzugen Sie die Übernahme einer bewährten Implementierung gegenüber neuem Code.
• 2. Plan – an den planner-Agenten delegieren (oder architect / code-architect für strukturelle Entscheidungen). Eine task_list ausgeben, geordnet als dünne vertikale Teilaufgaben. → GATE 1.
• 3. Scaffold – nur orch-build-mvp: die erste Ende-zu-Ende-Teilaufgabe aufsetzen.
• 4. Implementieren (TDD) – jede Aufgabe durch den tdd-guide-Agenten (oder den tdd-workflow Skill) treiben: rot → grün → refactorn. Die erste-Bewegung-Regel der Operation beachten.
• 5. Review – code-reviewer-Agent / /code-review. security-reviewer hinzufügen, wenn der Diff einen Sicherheitstrigger (unten) berührt.
• 6. Commit – konventionelle Commits (feat: / fix: / refactor: / …), einer pro logischem Block. → GATE 2.

Die beiden Gates

Diese Familie ist gated, nicht autonom:

1. GATE 1 – nach Plan. Die task_list präsentieren; keinen Implementierungscode schreiben, bis der Benutzer zustimmt.
2. GATE 2 – vor Commit. Die Diff-Zusammenfassung und vorgeschlagenen Nachrichten präsentieren; nichts committen, bis der Benutzer bestätigt.

Alles zwischen den Gates fließt ohne Unterbrechung.

Agenten-/Befehlszuordnung

Phase	Primär	Fallback / Eskalation
Intake / Verstehen	code-explorer	Vorhandene Pfade vor einem Tweak, Fix oder Refactor nachverfolgen
Plan	planner	architect, code-architect für strukturelle Aufrufe
Implementieren	tdd-guide (oder tdd-workflow Skill)	build-error-resolver / /build-fix bei Build-Fehlern
Review	code-reviewer / /code-review	Sprachreviewer (python-reviewer, typescript-reviewer, …)
Sicherheit	security-reviewer	—
MVP-innerer Loop	/gan-build "<kurzbeschreibung>" --skip-planner	Treibt gan-generator → gan-evaluator; --max-iterations / --pass-threshold anpassen

Den Sprachreviewer an das Repository anpassen (siehe die eigene CLAUDE.md des Repos).

Sicherheits-Review-Trigger

security-reviewer einbinden, wenn der Diff eines der folgenden Elemente berührt: Authentifizierung oder Autorisierung, Benutzereingabenverarbeitung, Datenbankabfragen, Dateisystempfade, externe API-Aufrufe, Kryptographie oder Geheimnisse / Anmeldeinformationen. (Gemäß rules/common/security.md.)

Übergabe-Artefakte

Die Pipeline trägt keinen versteckten Zustand – die Planungsdokumente sind die Übergabe:

• task_list (aus Plan) treibt den Implementierungs-Loop.
• Größere Arbeiten können auch PRD / Architektur / Systemdesign unter dem docs/ des Repos gemäß rules/common/development-workflow.md ausgeben.
• Review-Erkenntnisse (KRITISCH / HOCH) müssen vor Gate 2 aufgelöst werden.

Verifikation

• Größenstufe wurde benannt und entsprach der Arbeit
• Gate 1 (Plan) und Gate 2 (Commit) wurden beide eingehalten
• security-reviewer lief genau dann, wenn ein Sicherheitstrigger berührt wurde
• Commits sind konventionell und auf eine logische Änderung begrenzt
• Neues / geändertes Verhalten hat Tests; Abdeckung ≥ 80 % gemäß rules/common/testing.md