Modul 6
Workflow-Frameworks im Vergleich
Tag 2 · ca. 90 Minuten
Lernziel Modul 6
Der Teilnehmer kann QRSPI, BMAD und
OpenSpec nach Philosophie einordnen und
begründet ein Framework für einen gegebenen Projekttyp wählen.
Einordnen heißt: die Leitidee benennen können. Nicht: die Kommandos auswendig können.
Inhalt
Gemeinsame DNA
Alignment, Artefakte, isolierter Context
Phasen — QRSPI / RPI
Die Pipeline als Leitidee
Rollen — BMAD
Das Team als Leitidee
Artefakte — OpenSpec
Die Spezifikation als Leitidee
GitHub Spec Kit
Was wir belegen können — und was nicht
Vergleichsmatrix
Sechs Achsen statt Glaubensfragen
Der eigene Workflow
16–20 Schritte aus der Praxis
Zeremonie-Falle
Prozess-Overhead & Adoptionsrisiko
Alle lösen dasselbe Problem
Die Frameworks sehen unterschiedlich aus, aber sie sind Antworten auf
zwei Eigenschaften aus Modul 1:
stateless
Das Modell behält nichts. Alles, was es beim nächsten Schritt wissen
muss, muss irgendwo stehen — und wieder mitgeschickt werden.
nicht-deterministisch
Der Weg variiert. Verlassen kann man sich nur auf ein
vorher vereinbartes Ziel, nie auf Wiederholbarkeit.
Ein Agent ohne Gedächtnis und ohne festes Ziel braucht
externe Struktur. Jedes dieser Frameworks ist ein Vorschlag,
wie diese Struktur aussieht.
Drei Bausteine, überall dieselben
1Alignment vor Arbeit. Bevor Code entsteht, wird Einigkeit über Problem und Lösung hergestellt — und zwar schriftlich. Der teure Denkfehler soll passieren, solange er noch nichts kostet.
2Artefakte statt Gedächtnis. Das Einvernehmen liegt in einer Datei im Repo, nicht in einer Chat-Historie. Eine frische Session muss daraus weiterarbeiten können.
3Isolierter Context statt Riesensession. Jeder Schritt bekommt genau den Kontext, den er braucht — nicht die gesamte Projektgeschichte.
Wer diese drei sieht, muss sich zwischen den Frameworks nicht
entscheiden wie zwischen Religionen — sondern nur
fragen, welche Ausprägung zum eigenen Projekt passt.
Die Einordnungsachse dieses Moduls
Phasen
QRSPI / RPI — die Leitidee ist die Reihenfolge. Struktur entsteht durch Stufen und Gates dazwischen.
Rollen
BMAD — die Leitidee ist die Arbeitsteilung. Struktur entsteht durch spezialisierte Agenten und ihre Übergaben.
Artefakte
OpenSpec — die Leitidee ist das Dokument. Struktur entsteht durch eine gepflegte Wahrheit und Deltas dagegen.
Keine der drei Leitideen schließt die anderen aus. Jedes Framework
betont eine davon — und erbt die anderen implizit.
Phasen — die Pipeline als Leitidee
QRSPI steht für Questions → Research →
Structure → Plan → Implement. Der Ablauf ist die Struktur:
jede Stufe hat einen eigenen Output, und zwischen den Stufen sitzen Gates.
Questions
Research
Structure
Plan
Implement
Kern der Idee: Pflicht-Gates nach dem Design und nach der
Aufgabenzerlegung. Der Mensch gibt frei, bevor die nächste Stufe beginnt.
Drei Prinzipien, die es wert sind
Context-Isolation gegen „completion bleed". In Research und Structure wird das Ticket-Framing bewusst weggelassen. Sonst baut der Agent die naheliegende Lösung, bevor er das System verstanden hat.
„Brain Surgery Moment". Design fertig, null Zeilen Code — genau hier ist eine Korrektur fast gratis. Danach wird sie teuer.
„control flow, not prompts". Verlass dich nicht darauf, dass das Modell sich an eine Regel erinnert — baue den Ablauf so, dass der falsche Schritt gar nicht möglich ist.
Diese drei Prinzipien sind aus dem CGS-internen Benchmark in
RFC-223 (cgsit-finance, 2026-07-01) belegt zitiert. Versionen,
Kommandos und der genaue Stufenschnitt von QRSPI stehen bewusst nicht auf
dieser Folie — der Trainer gleicht den Detailstand vor dem Kurs gegen
die Projektdokumentation des Frameworks ab. — geprüft am 2026-07-21
Rollen — das Team als Leitidee
BMAD-METHOD („Agentic Agile Driven Development") verteilt
die Arbeit auf spezialisierte Agent-Rollen. Struktur entsteht
nicht durch Stufen, sondern durch Übergaben zwischen Rollen.
Agentic Planning
Analyst → PM → Architect erzeugen gemeinsam ein
Produktdokument und eine Architektur. Ergebnis: eine belastbare
Planungsgrundlage, bevor gebaut wird.
Context-Engineered Development
Ein Scrum-Master zerlegt die Planungsdokumente in
self-contained Story-Files — jede Story trägt den
nötigen Architektur-Kontext eingebettet mit.
Der Mensch ist in dieser Aufstellung der „Vibe CEO":
er entscheidet und gibt Richtung vor, statt jeden Schritt selbst zu tun.
Was BMAD stark macht — und was es kostet
Stark
Self-contained Story-Files — der umsetzende Agent
braucht nichts sonst. Kein Nachlesen der Architektur, keine Abhängigkeit
vom Chat-Gedächtnis. Das eliminiert Context-Loss zwischen Handoffs.
Quality-Gates mit abgestuftem Ergebnis
(PASS / CONCERNS / FAIL /
WAIVED) statt binärem „passt schon".
Teuer
Eine Rollen-Armada (in der Größenordnung von 12 bis 21
Personas) plus Scaffolding will gepflegt werden.
„Agenten prüfen Agenten" — wenn früh ein Fehler
entsteht, kann er durch die ganze Rollenkette propagieren, ohne dass ein
Mensch ihn je sieht.
Zahlen und Rollenbezeichnungen stammen aus dem CGS-Benchmark vom 2026-07-07
(docs/rfcs/223-external-framework-benchmark.md). Der aktuelle
Funktionsumfang wird vor dem Kurs gegen die BMAD-Projektdokumentation
abgeglichen. — geprüft am 2026-07-21
Artefakte — die Spezifikation als Leitidee
OpenSpec trennt sauber zwischen der aktuellen
Wahrheit und der vorgeschlagenen Änderung:
Truth
specs/
Delta
changes/<id>/
Review
Merge zurück
in die Truth
Der Merge-back ist der eigentliche Trick: Nach dem Abschluss
beschreibt die Spezifikation wieder den Ist-Zustand.
Das ist die eingebaute Antwort auf Doku-Drift.
Spec als Vertrag, nicht als Plan
Behavior-Contracts statt Implementierungspläne: Anforderungen in MUST/SHOULD-Form plus GIVEN … WHEN … THEN-Szenarien.
Delta statt Vollbild: eine Änderung wird als ADDED / MODIFIED / REMOVED gegen die Truth beschrieben — nicht als neue Gesamtspezifikation.
Bewusst gate-frei: Reviews sind menschengetrieben, es gibt keine erzwingende Zustandsmaschine. Die erklärte Haltung ist „fluid over rigid".
Belegt aus dem CGS-Benchmark (RFC-223, aufgefrischt 2026-07-07). CLI-Kommandos,
Ordnernamen im Detail und der aktuelle Tooling-Umfang stehen bewusst nicht auf
dieser Folie — Abgleich gegen die OpenSpec-Projektdokumentation vor dem
Kurs. — geprüft am 2026-07-21
GitHub Spec Kit
Ein weiterer Vertreter der artefakt-orientierten Familie:
Spec-Driven Development, bei dem die Spezifikation der führende Gegenstand ist
und der Code daraus abgeleitet wird.
Ehrlichkeitshalber: Spec Kit ist in unserem eigenen Framework-Benchmark
ausdrücklich als noch offen geführt. Wir haben es
nicht geprüft — also behaupten wir hier nichts darüber.
Belegt ist nur: docs/rfcs/223-external-framework-benchmark.md
(2026-07-07) listet Spec-Kit, Kiro, Agent-OS, Tessl als „offen —
nächste Runde". Alles Weitere — Kommandos, Phasenschnitt, Reifegrad,
Werkzeug-Integration — gleicht der Trainer vor dem Kurs gegen die
offizielle Projektdokumentation ab und ergänzt es mündlich.
— geprüft am 2026-07-21
Vergleichsmatrix — sechs Achsen statt Glaubensfragen
| Achse | QRSPI / RPI | BMAD | OpenSpec |
|---|
| Leitidee | Phasen | Rollen | Artefakte |
| Wo entsteht Alignment? | Am Gate zwischen zwei Phasen — „Design fertig, 0 Code" | Im Handoff zwischen den Rollen — Planning vor Development | In der Spec-Review vor dem Merge des Deltas |
| Zentrales Artefakt | Der Output der jeweiligen Stufe (Research, Struktur, Plan) | Das self-contained Story-File | Die Truth-Spec plus das Delta dagegen |
| Wie wird Context isoliert? | Ticket-Framing in frühen Phasen bewusst weglassen | Story-File trägt allen nötigen Kontext eingebettet mit | Delta statt Vollbild — nur die Änderung ist im Blick |
| Härte der Freigabe | Erzwungene Gates | Abgestufte Quality-Gates (PASS / CONCERNS / FAIL / WAIVED) | Bewusst gate-frei, menschengetrieben („fluid over rigid") |
| Overhead sitzt bei… | …der Zahl der Stufen | …der Zahl der Rollen und Dokumente | …der Pflege der Truth-Specs |
Wie diese Matrix zu lesen ist
Belegt
Zeilen 1–5 fassen zusammen, was im CGS-Benchmark zu OpenSpec,
QRSPI und BMAD dokumentiert ist (RFC-223, 2026-07-01 und 2026-07-07).
Einschätzung
Zeile 6 („Overhead sitzt bei…") ist eine Ableitung aus der
Leitidee, keine Aussage der Frameworks über sich selbst.
Als solche kennzeichnen.
Bewusst nicht in der Matrix: Versionen, Kommandos, Community-Größe,
„welches ist das beste". Solche Zeilen veralten schneller, als man sie pflegen kann.
Die Matrix vergleicht Leitideen, nicht Funktionsumfänge. Vor
einer echten Einführungsentscheidung ist der aktuelle Stand des jeweiligen
Projekts direkt in dessen Dokumentation zu prüfen. — geprüft am 2026-07-21
Der eigene 16–20-Schritte-Workflow
Ein echter Workflow, kein Lehrbeispiel
Was jetzt kommt, ist der tatsächlich gelebte Entwicklungs-Lebenszyklus aus
einem produktiven CGS-Projekt — wörtlich aus dessen
CLAUDE.md. Rund zwanzig Einträge:
15 Hauptschritte plus acht eingeschobene Sub-Schritte, die alle
nachträglich entstanden sind.
Legende
Gate = Freigabe-Punkt im Ablauf, an dem nicht weitergearbeitet wird, solange er offen ist.
Legende
Mensch = ein Punkt, an dem ausdrücklich ein Mensch bestätigen muss. Kein Agent entscheidet das.
Herkunft
Die Sub-Schritte tragen Nummern wie 1b, 2a, 3a, 6a — die Nummerierung verrät, dass sie zwischen bestehende Schritte eingeschoben wurden.
Planen und designen (1–3a)
1Plan / Clarify — bei unklarem Scope wird nachgefragt, nicht geraten.
1bUnderstanding-Loop bei Eingaben ohne RFC: „Verstanden…" + „Plan…" schreiben und auf OK warten. Ersetzt die fehlende formale Abnahme.
2RFC oder Ticket — neue Funktion oder Architekturänderung bekommt einen RFC, ein kleiner Fix nur ein Ticket.
2aAnalyse-Review + Accept (Draft→Accepted) — richtiges Problem? Done-Definition verifizierbar? Test-Strategie und Testdaten je Layer vorgesehen?
3Spec / Concept — erst die Architektur- und Domänen-Dokumente lesen, dann das Topic-Doc schreiben oder erweitern.
3aDesign-Gate + Design-Review (Accepted→In Progress) — Design-Freigabe setzen, 0 Code davor. Ohne Haken warnt das Werkzeug.
Bauen und prüfen (4–7b)
4Implement code + tests — vorher das Test-Layer-Modell und die Regeln lesen. Neue zustands-, security-, geld- oder compliance-relevante Aktion? Dann Event mitdenken.
5Local verify — Tests vom Repo-Root, Frontend-Tests, Compile, Build.
6RFC-Checkliste nachziehen — erledigte Punkte im Planungsartefakt abhaken.
6aSame-Commit-Doku-Pflicht prüfen — die geänderten Dateien gegen eine Trigger-Tabelle scannen. Jeder Treffer heißt: Doku-Update in diesem Commit.
6bMigration-Safety, falls Datenbank-Migrationen dabei sind — Sperrverhalten, Backfill, Rollback, Versionsnummer.
7Klassifizieren + Version — Feature, Bugfix oder Doc-only? Kleine Fixes werden zu einem Versionssprung gebündelt.
7bSelf-Review (Pflicht) — feste Checkliste; bei sensiblen Bereichen zusätzlich ein Review-Subagent vor dem Commit. Übersprungen wird nur mit Begründung in der Commit-Message.
Ausliefern und schließen (8–15a)
8–9Commit und Push — autonom. Der Pre-Push-Hook prüft Compile und Tests, die CI ist das Sicherheitsnetz.
10–11Lokaler Smoke-Test (optional) und CI abwarten — die fünf Minuten Bauzeit werden zum Durchklicken genutzt.
12DB-Backup, falls Migrationen im Push sind.
13Vor dem Deploy fragen — Mensch immer. Dieser Schritt ist nicht delegierbar, egal wie grün alles aussieht.
14Deploy + Verify — ausrollen, danach die laufende Version prüfen.
14aOperational Readiness — Vier-Punkte-Check nach dem Deploy: Scheduler/Alarm, Metrik, Fehler-Log-Muster, Betriebsdoku.
15/15aDoku nachziehen + Closeout-Review — bevor ein RFC auf „Done" geht: „Done-Definition erfüllt? Bug-Typ strukturell unmöglich?" Bei Nein bleibt er offen — offene Punkte werden im RFC benannt, nicht in ein Folgeticket vertagt.
Wo darin welche Philosophie steckt
| Schritt im eigenen Workflow | Entspricht der Idee… | Leitidee |
|---|
| 3a Design-Gate — „0 Code davor" | „Brain Surgery Moment" | Phasen |
| Research im Subagenten ohne Ticket-Framing | Context-Isolation gegen „completion bleed" | Phasen |
| Hooks und deny-Regeln statt Prosa-Regeln | „control flow, not prompts" | Phasen |
| Review-Subagenten mit je einem Output-Artefakt | Rollen-Handoff mit isoliertem Deliverable | Rollen |
| Kontext-komplette Bau-Phasen (geplant, offen) | Self-contained Story-Files | Rollen |
| Domänen-Dokumente als Wahrheit, RFC als Delta | Truth ↔ Delta | Artefakte |
| 6a Same-Commit-Doku-Pflicht | Merge-back nach Abschluss | Artefakte |
Alle drei Leitideen sind da — keine davon rein. Genau das ist der
Normalfall in einem gewachsenen Projekt.
Gewachsene Synthese, kein Produkt
Dieser Workflow ist nicht „Framework X mit Anpassungen". Er ist entstanden,
indem gegen die Frameworks geprüft wurde — und dann
einzelne Prinzipien übernommen wurden, das Tooling aber nicht.
Der volle Aufbau ist „unsere eigene Synthese — von
keinem der beiden Frameworks als Standard belegt (bewusste
Design-Wette, kein Industrie-Standard)“.
— RFC-223, cgsit-finance, 2026-07-01
Übernommen
Prinzipien: Design-Gate, Context-Isolation, Truth↔Delta,
kontext-komplette Arbeitspakete.
Bewusst nicht übernommen
Fremde Ordnerstrukturen und CLIs, die volle Stufen-Pipeline, die
Persona-Armada. Begründung jeweils dokumentiert.
Prozess-Overhead & Adoptionsrisiko
Die Zeremonie-Falle
Zeremonie-Falle: Ein Prozess sammelt so viele Schritte,
Gates und Pflichtdokumente an, dass die Einhaltung teurer wirkt als die
Arbeit — und deshalb nur noch behauptet wird.
Wie sie aussieht
Die Haken werden gesetzt, nachdem der Code schon steht. Der RFC wird
rückwirkend zur Implementierung passend geschrieben. Reviews sagen
reflexhaft „passt".
Warum sie schlimmer ist als kein Prozess
Ein nicht gelebter Prozess erzeugt falsche Sicherheit:
alle glauben, es habe jemand hingesehen — niemand hat.
Ein Gate, das nie „nein" sagt, ist kein Gate. Es ist ein Klick.
Was jeder Gate wirklich kostet
Wartezeit
Jede Freigabe, die ein Mensch geben muss, ist ein potenzieller Halbtag Liegezeit.
Schreibarbeit
Jedes Pflichtartefakt muss geschrieben und aktuell gehalten werden.
Kognitive Last
Wer den Ablauf nicht im Kopf hat, macht ihn falsch oder gar nicht.
Adoptionsrisiko
Je größer die Hürde, desto größer die Versuchung, „nur diesmal" daran vorbeizuarbeiten.
Die Gegenmaßnahme ist nicht „weniger Prozess", sondern
Zeremonie an Auslösern skalieren: der volle Ablauf greift bei
riskanten Änderungen — Geld, Datenschutz, Migration, mandantenübergreifende
Daten. Ein Tippfehler-Fix läuft ohne.
Belegt Der CGS-Workflow formuliert genau diese
Schwelle selbst: Pflicht-Reviews nur bei sensiblen Auslösern —
„für 1 Architekt + Claude darf nicht jeder Kleinkram-RFC ein
3-Gate-Marathon werden“.
Ein Prozess braucht eine Aus-Schaltung, sonst schaltet ihn
das Team aus.
Regeln aus Schmerz, nicht aus Prinzip
Das stärkste Gegenargument zur Zeremonie-Falle: Im CGS-Workflow hat
jede Regel einen datierten Auslöser — sie steht nicht da,
weil sie gut klingt.
RFC-184 → Bug #177
Eine halb implementierte Architektur führte zu einem Datenschutz-Fehler.
Daraus entstand das Design-Gate (Schritt 3a): Design
freigegeben, 0 Code davor.
2026-05-14
Ein veraltetes Domänen-Dokument war die Ursache eines Produktionsfehlers —
das Doku-Update war als Folgeaufgabe geplant und nie passiert:
„the follow-up never happens and the doc rots within weeks“.
Daraus entstand die Same-Commit-Doku-Pflicht (Schritt 6a).
2026-05-18
Ein neues Dokument wurde von Grund auf geschrieben, obwohl ein bestehendes
600-Zeilen-Dokument das Thema bereits abdeckte — niemand hatte es geöffnet.
Daraus entstand die Doc-Discipline: erst greppen, dann
erweitern statt duplizieren.
Deshalb heißen die Schritte 1b, 2a, 3a, 6a, 6b, 7b, 14a, 15a: Es sind
eingeschobene Schritte. Die Nummerierung ist die
Unfallgeschichte des Projekts.
Wie man daraus etwas einführt
1Nicht das Framework kopieren, die Leitidee wählen. Braucht euer Problem Reihenfolge, Arbeitsteilung oder eine gepflegte Wahrheit?
2Mit einem Gate anfangen. In der Praxis fast immer das gleiche: Alignment vor Code. Alles andere kann folgen.
3Auslöser definieren, nicht Pflicht für alles. Wann greift der volle Ablauf, wann reicht ein Ticket?
4Mechanisieren, was mechanisierbar ist. Eine Regel, die ein Hook prüft, driftet nicht — „control flow, not prompts".
5Jede neue Regel bekommt ihren Auslöser ins Dokument. Datum und Vorfall dazu, sonst fehlt in einem Jahr die Begründung.
Modul 6 in vier Sätzen
1Alle Workflow-Frameworks beantworten dieselben zwei Eigenschaften aus Modul 1: Alignment, Artefakte, isolierter Context.
2Sie unterscheiden sich in der Leitidee: Phasen (QRSPI/RPI), Rollen (BMAD), Artefakte (OpenSpec).
3Ein realer Workflow ist meist eine Synthese aus allen dreien — und darf das auch ehrlich so nennen.
4Jeder Gate kostet. Wer die Zeremonie-Falle vermeiden will, skaliert Zeremonie an Auslösern und begründet jede Regel mit einem echten Vorfall.
Die Frage ist nie „welches Framework ist das beste", sondern
„welche Struktur hält mein Team durch, und wo darf sie fehlen".
Übung 6 — Begründet entscheiden
Aufgabe
Wählt für jeden der drei Projekttypen ein Vorgehen —
eine der drei Leitideen oder eine benannte Mischung:
AGreenfield-Produkt — neues Team, nichts existiert, Fachlichkeit noch unscharf.
BLegacy-Wartung mit Altlasten — gewachsener Code, kaum Doku, produktive Kunden.
CKleines internes Tool — ein bis zwei Entwickler, geringes Risiko, schnelle Änderungen.
Verifizierbares Ergebnis: Drei Entscheidungen mit je
zwei Sätzen Begründung, die sich ausdrücklich auf die
Achsen der Vergleichsmatrix beziehen — mindestens
„wo entsteht Alignment", „zentrales Artefakt" und
„wo sitzt der Overhead". Eine Begründung ohne Achsenbezug zählt nicht.
Dauer ca. 20 Minuten · Zweiergruppen, danach Auflösung im Plenum
© 2026 CGS IT Solutions GmbH
Alle Rechte vorbehalten
Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung,
Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit
ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.
cgsit-claude-training · Modul 6 · v0.1.0
