2026-09-02

Von der Spezifikation zum geprüften Pull-Request: Spec-Driven Development in der Praxis

Warum Spec-Driven Development die richtige Reihenfolge ist, hat ein früherer Artikel begründet: erst die geprüfte Spezifikation, daraus die Architektur, daraus der Code. Was dort Prinzip war, ist hier Weg — einmal konkret vom leeren Blatt bis zum Pull-Request.

Schritt 1: Die Spezifikation entsteht als Dokument, nicht als Verlauf

Der Ausgangspunkt ist das Spec-Studio: ein geführter Wizard, der eine Projektspezifikation entwickelt, bevor überhaupt ein Projekt existiert. Sechs inhaltliche Abschnitte — Vision & Kontext, Ziele & Nicht-Ziele, fachliche Anforderungen, Stack & Constraints, NFRs & Guardrails, Epics-Schnitt — jeweils mit einem KI-Chat auf der einen und dem eigentlichen Text auf der anderen Seite. Der Unterschied zum Chatverlauf ist genau der, um den es der Methode geht: was hier entsteht, ist ein Dokument mit Abschnitten, jederzeit unterbrechbar und wiederaufnehmbar — nicht eine Gesprächsgeschichte, aus der man die Anforderungen später rekonstruieren müsste.

Schritt 2: Der Stack wird Vertrag, nicht Vermutung

Im Stack-Schritt wählt man ein Profil der eigenen Organisation oder startet mit einer Plattform-Vorlage — Spring Boot, Laravel, Angular, React/Vite, Node/Express, Go, Quarkus oder Flutter — und passt sie an. Das Profil ist ein Vertrag, kein Feature: Sprache, Framework, Versionen und Prüfkommandos stehen ausdrücklich da, statt dass ein Modell sie aus dem Repository errät. Alles, was später gebaut wird, wird gegen genau diese Angaben geprüft.

Schritt 3: Aus der Spezifikation werden Tickets — und ein Mensch bleibt am Hebel

Am Ende kuratiert man den Epics-Schnitt und lässt das Studio erzeugen: ein Projekt mit Repository, Grundlagendokument und den Epics als echten Tickets im Tracker. Wichtig ist, was dabei nicht passiert: es startet kein Code-Lauf. Das Studio schreibt Tickets — welche Story tatsächlich läuft, entscheidet weiterhin ein Mensch, Ticket für Ticket. Die Spezifikation setzt den Rahmen; den Auftakt gibt sie nicht selbst.

Schritt 4: Die Ausführung folgt der Spezifikation — in kleinen, belegbaren Schritten

Läuft eine Story, arbeitet die Fabrik in Phasen und Slices: aus den Anforderungen wird ein Plan, aus dem Plan werden kleine Arbeitsschritte, und jeder Slice ist bewusst klein — klein genug, dass er samt seinem Kontext vollständig in einen Prompt passt. Jeder Schritt hinterlässt einen eigenen Commit. Das Ergebnis ist ein Pull-Request-Entwurf, dessen Commit-Historie der Nachweis ist: wer wissen will, ob die Umsetzung der Spezifikation gefolgt ist, liest nicht ein Diff von tausend Zeilen, sondern eine Kette benannter Schritte.

Der ehrliche Schluss: geprüft heisst prüfbar

Am Ende steht ein Entwurf, kein Fait accompli. Die Voreinstellung ist, dass ein Mensch merged — und dass das Team das Ergebnis fachlich beurteilt, bleibt seine Arbeit. Was Spec-Driven Development an dieser Stelle liefert, ist nicht die Abnahme, sondern ihre Grundlage: eine Spezifikation, gegen die man prüfen kann, und eine Spur, an der man es tut. Wer den Weg selbst gehen will: das Kapitel Spec-Studio in der Dokumentation führt durch alle sieben Schritte.