SDD-Arbeitsablauf

Spec Driven Development behandelt Specs als lebende Entwicklungsverträge. Jede Implementierungsphase wird durch klar definierte Kriterien gesteuert, die bei jedem Übergang automatisch validiert werden.

Der Lebenszyklus

clarify → create_spec → DoR check → implement (PLAN.md) → validate → drift detection → done

Jeder Pfeil ist ein Gate. Du kannst nicht vorwärtsgehen, ohne die Definition of Done der vorherigen Phase zu erfüllen.

Phase 1 — Klären

Tools: clarify_requirements, reality_check

Bevor eine einzige Zeile Spec geschrieben wird, werden die Unklarheiten aufgedeckt.

Prompt: "Use specforge to clarify requirements for [feature] in project [id]"

clarify_requirements generiert eine gezielte Liste von Fragen — Umfangsgrenzen, Randfälle, nicht-funktionale Anforderungen, externe Abhängigkeiten — damit die Spec mit klarer, eindeutiger Absicht beginnt.

reality_check bewertet, ob die Anforderungen angesichts des aktuellen Projektkontexts machbar sind. Es erkennt "unmöglich bis Freitag"-Situationen, bevor sie zu technischen Schulden werden.

Phase 2 — Spec erstellen

Tools: create_spec, design_schema, define_ui_contract, generate_adr

Prompt: "Create a spec for [feature] in project [id]"

create_spec generiert eine strukturierte HU.md mit:

Abschnitt	Inhalt
User Story	Wer, was, warum
Abnahmekriterien	Testbare, eindeutige Kriterien
DoR-Checkliste	Definition of Ready-Gates
Datenbankschema-Hinweise	Tabellen, Spalten, Beziehungen
UI-Verträge	Komponentenverträge, Zustandsverwaltung
ADR-Hinweise	Architecture Decision Records
PLAN.md	Schrittweiser Ausführungsplan

Wenn eine KI-native Architektur erkannt wird, generiert die Spec auch:

• Latenzbudgets und Fallback-Ketten
• Versionierungskriterien für Prompts
• LLM-Observability-Anforderungen

Phase 3 — DoR-Prüfung

Tools: check_readiness, detect_contradictions

Bevor die Implementierung beginnt, prüfe, ob die Spec wirklich bereit ist.

Prompt: "Check if spec SPEC-003 is ready for implementation in project [id]"

check_readiness bewertet:

• Vollständigkeit der Abnahmekriterien
• Kriterienqualität (testbar, eindeutig)
• Abhängigkeitsstatus (blockierende Specs gelöst?)
• Einhaltung der Verfassung

detect_contradictions scannt alle Specs auf semantische Konflikte — erkennt Situationen, in denen SPEC-A sagt "Benutzer können ihr Konto löschen" und SPEC-B sagt "Konten sind unveränderlich."

Phase 4 — Implementieren

Tools: generate_execution_plan, package_handoff, generate_tests

Prompt: "Generate an execution plan for spec SPEC-003 in project [id]"

generate_execution_plan erzeugt eine PLAN.md mit:

• RED/GREEN/VERIFY-Zyklus-Schritten
• Identifizierten parallelisierbaren Schritten
• Datei-Eigentümerschaft pro Schritt
• Geschätztem Aufwand pro Schritt

package_handoff bündelt die Spec in ein strukturiertes Übergabepaket für einen KI-Agenten — Ziel, Kriterien, Dateiliste, Einschränkungen — bereit für autonome Implementierung.

generate_tests erzeugt einen Testplan und Test-Datei-Stubs aus den Abnahmekriterien der Spec.

Phase 5 — Validieren

Tools: validate, audit, security_check

Nach der Implementierung die Abdeckung prüfen:

Prompt: "Validate spec SPEC-003 against the code at /path/to/src"

validate prüft:

• Welche Abnahmekriterien durch Code abgedeckt sind
• Welche fehlen oder nur teilweise implementiert sind
• Gesamte Spec-Abdeckung in Prozent

audit bewertet die Implementierung 0–100 für:

• SOLID-Prinzipien
• Sauberer Code
• Architektur-Compliance
• Verstöße gegen die Verfassung

security_check führt die Spec durch OWASP Top 10 und scannt Code auf unsichere Muster und generiert einen Sicherheits-Score (A–F).

Phase 6 — Abweichungserkennung

Tools: detect_drift, reconcile_spec

Wenn sich Anforderungen weiterentwickeln, Specs und Code ausgerichtet halten:

Prompt: "Detect drift in spec SPEC-003 for project [id]"

detect_drift berichtet:

• Kriterien, die nicht mehr mit dem Code übereinstimmen
• Verstöße gegen die Verfassung seit der letzten Prüfung
• Nachgelagerte Auswirkungen: welche anderen Specs von der Abweichung betroffen sind

Wenn die Abweichung beabsichtigt ist (die Spec muss aktualisiert werden):

Prompt: "Reconcile spec SPEC-003 with the implementation changes in project [id]"

reconcile_spec präsentiert jede Änderung zur Einzelgenehmigung und prüft die Einhaltung der Verfassung vor dem Speichern.

Die Projekt-Verfassung

Die Verfassung ist eine Reihe unveränderlicher Architekturprinzipien, die aus deiner CLAUDE.md, .cursorrules oder anderen KI-Agenten-Konfigurationsdateien extrahiert wurden.

Prompt: "Initialize the constitution for project [id] from CLAUDE.md"

Einmal festgelegt, wird die Verfassung automatisch in create_spec, audit und detect_drift durchgesetzt. Verstöße werden erkannt, bevor sie in die Code-Überprüfung gelangen.

Status-Übergänge

Status	Beschreibung
draft	Spec erstellt, noch nicht bereit
ready	DoR-Prüfung bestanden
in_progress	Implementierung gestartet
review	Implementierung abgeschlossen, Validierung ausstehend
done	Validiert und akzeptiert
blocked	Durch Abhängigkeit blockiert

Prompt: "Update status of spec SPEC-003 to in_progress in project [id]"

Jeder Übergang führt eine DoR/DoD-Validierung durch. Du kannst eine Spec nicht als done markieren, ohne die DoD-Kriterien zu erfüllen.