Wie der Skill drei unabhängige Build-Pipelines orchestriert — und warum weniger Dateien der eigentliche Effizienzgewinn sind
Das zentrale Architekturprinzip: Jede Zielgruppe erhält eine eigenständige Build-Pipeline. Diese Pipeline bestimmt, welche Tiefenstufen generiert werden und wann der Prozess stoppt. Die Pipelines sind vollständig voneinander entkoppelt — sie teilen sich weder Zustand noch Wartezeiten.
Pipeline-Tiefe pro Zielgruppe
Kernprinzip: Die Pipelines warten nicht aufeinander. Die 📊 Entscheider-Pipeline ist nach 2 Level-Schritten fertig, während die 🔧 Entwickler-Pipeline noch 2 weitere Stufen vor sich hat. Jede Pipeline kennt nur ihre eigene max_depth und terminiert selbstständig.
Das Parallelisierungsmodell des Skills ist zweistufig: Auf der oberen Ebene laufen Pipeline-Agents (einer pro Zielgruppe), auf der unteren Ebene File-Agents (einer pro zu generierende Datei innerhalb eines Levels). Innerhalb einer Pipeline sind die Levels jedoch strikt sequentiell.
Hierarchisches Parallelisierungsmodell
EBENE 1: Pipeline-Agents (parallel)
EBENE 2: File-Agents pro Level (parallel)
Die Parallelisierungsregeln folgen einer klaren Logik: Alles, was keine Datenabhängigkeit hat, darf parallel laufen. Alles, was auf dem Output einer vorherigen Stufe aufbaut, muss warten.
| Operation | Parallel? | Begründung |
|---|---|---|
| Verschiedene Zielgruppen-Pipelines | ✅ | Kein shared state, keine Datenabhängigkeiten |
| Themen innerhalb eines Levels | ✅ | Themen sind voneinander unabhängig |
| DE + EN desselben Themas | ✅ | Sprachversionen teilen keine Abhängigkeiten |
| Levels innerhalb einer Pipeline | ❌ | L1 referenziert L0-Seiten — L0 muss fertig sein |
| Phase 3 → Phase 4 | ❌ | Phase 4 benötigt die CSS/JS-Foundation aus Phase 3 |
| Phase 5 (Polish) | ❌ | Benötigt den vollständigen Output aller Pipelines |
Ausführungsmodell: Phase 3 (Foundation) läuft einmal global und muss abgeschlossen sein, bevor Phase 4 beginnt. In Phase 4 arbeiten die drei Pipelines unabhängig: Innerhalb jeder Pipeline werden die Levels nacheinander abgearbeitet (L0 muss fertig sein, bevor L1 startet), aber innerhalb eines Levels können alle Themen und Sprachversionen parallel generiert werden. Jede Pipeline stoppt bei ihrer individuellen max_depth. Phase 5 (Polish) darf erst beginnen, wenn alle Pipelines abgeschlossen sind, da sie den gesamten Output für Link-Validierung und Cross-References benötigt.
Die 🔧 Pipeline baut gerade L2-Dateien. Kann die 📊 Pipeline gleichzeitig L1 bauen?
Die Theorie erlaubt volle Parallelisierung. In der Praxis ist das jedoch unzuverlässig: LLM-Kontextfenster sind begrenzt, parallele API-Aufrufe können Timeouts verursachen, und Fehler in einem parallelen Branch sind schwer zu debuggen. Empfohlen wird daher sequentielle Ausführung oder maximal 2 parallele Agents (ein DE+EN-Paar).
Zeitverlauf: Ideal vs. Praxis
Alle 3 Pipelines starten gleichzeitig. Gesamtzeit = längste Pipeline.
Pipelines nacheinander. Länger, aber zuverlässig und debuggbar.
Entscheidend: Die Pipeline-Logik bestimmt weiterhin Reihenfolge und Tiefe, auch bei sequentieller Ausführung. Ob die Pipelines parallel oder nacheinander laufen, ändert nichts am Ergebnis — nur an der Laufzeit. Der Orchestrator entscheidet auf Basis der Systemlast, welcher Modus gewählt wird.
Der eigentliche Effizienzgewinn liegt nicht in der Parallelisierung, sondern darin, weniger Dateien zu generieren. Durch bedarfsgerechte Tiefe (demand-based depth) produziert das System mit 3 Zielgruppen ca. 52 Dateien statt 100+ — eine Reduktion um 48%. Die 📊 Entscheider-Pipeline endet früh (2 Level-Schritte), die 🔧 Entwickler-Pipeline durchläuft alle 4 Stufen.
Dateienanzahl: Uniform vs. Bedarfsgerecht
Aufschlüsselung pro Pipeline
Warum das zählt: Jede nicht generierte Datei spart LLM-Tokens, API-Kosten und Laufzeit. Die Kombination aus Helpfulness-Scoring (filtert irrelevante Themen) und bedarfsgerechter Tiefe (begrenzt die Levels pro Zielgruppe) ergibt die Gesamteinsparung von ~48%.