Von der Spezifikation zum Pull-Request-Entwurf

Spec-Driven Development mit Anvil Coder: von der Spezifikation über Tickets und Commits zum Pull-Request-Entwurf, mit Prüfungen und menschlichem Review.

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. Die Gegenprüfung ist gesondert zuschaltbar und benötigt die passenden Werkzeuge in der Prüfumgebung; das Profil allein beweist keine bestandenen Tests.

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. Auch diese Vorbereitung kann Modellverbrauch verursachen. 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: Kleine Änderungen nachvollziehbar umsetzen

Läuft eine Story, arbeitet Anvil Coder in Phasen und Slices. Der Plan beschreibt kleine Arbeitsschritte und deren Abhängigkeiten. Die TaskSlices begrenzen den Arbeitskontext; sie garantieren weder unabhängige Änderungen noch fehlerfreien Code.

Die Commit-Historie macht die Umsetzung nachvollziehbar. Ob sie die Spezifikation erfüllt, beurteilst du anhand des Diffs, der Akzeptanzkriterien und der tatsächlich ausgeführten Prüfungen gemeinsam.

Prüfergebnisse lesen und den Entwurf reviewen

Ob Build und Tests ausgeführt wurden, steht im Laufbericht. Eine fehlende Toolchain kann die Prüfung verhindern, auch wenn bereits Testdateien erzeugt wurden. Der Laravel-Referenzlauf zeigt genau diese Grenze.

Am Ende steht ein Entwurf, kein Fait accompli. Im betriebenen Dienst entscheidet ein Mensch über den Merge — 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.