---
titel: "Von der Spezifikation zum geprüften Pull-Request: Spec-Driven Development in der Praxis"
adresse: https://anvil-coder.tech/blog/from-spec-to-pull-request
beschreibung: "Dass die Spezifikation die Quelle sein soll und nicht der Chatverlauf, ist schnell gesagt. Dieser Artikel geht den Weg einmal konkret: vom leeren Blatt im Spec-Studio über Stack-Profil und kuratierte Epics bis zum Pull-Request, dessen Commit-Historie jeden Schritt belegt."
sprache: de
---

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](https://anvil-coder.tech/blog/spec-driven-development), 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](https://anvil-coder.tech/frameworks): 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](https://anvil-coder.tech/wie-es-funktioniert#achsen): aus den Anforderungen wird ein Plan, aus dem Plan werden kleine Arbeitsschritte, und [jeder Slice ist bewusst klein](https://anvil-coder.tech/blog/warum-taskslices-klein-sind) — 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](https://anvil-coder.tech/blog/commit-historie-als-nachweis): 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](https://docs.anvil-coder.tech/docs/spec-studio) führt durch alle sieben Schritte.

## Selbst ausprobieren?

Der freie Tarif kommt ohne Gespräch aus, die Registrierung läuft zurzeit über eine Warteliste — ein Projekt anlegen, ein Epic ziehen, das Ergebnis im eigenen Repository reviewen.

[Kostenlos starten](https://app.anvil-coder.tech/register)[Demo vereinbaren](https://anvil-coder.tech/demo)