---
titel: "From spec to reviewed pull request: spec-driven development in practice"
adresse: https://anvil-coder.tech/en/blog/from-spec-to-pull-request
beschreibung: "That the spec should be the source of truth rather than the chat history is quickly said. This article walks the path concretely: from a blank page in the Spec Studio through stack profile and curated epics to a pull request whose commit history documents every step."
sprache: en
---

2026-09-02

# From spec to reviewed pull request: spec-driven development in practice

[Why spec-driven development is the right order of things](https://anvil-coder.tech/en/blog/spec-driven-development) was the subject of an earlier article: first the reviewed specification, from it the architecture, from that the code. What was principle there is path here — once, concretely, from blank page to pull request.

## Step 1: The spec grows as a document, not as a history

The starting point is the **Spec Studio**: a guided wizard that develops a project specification before a project even exists. Six content sections — vision & context, goals & non-goals, functional requirements, stack & constraints, NFRs & guardrails, epic slicing — each with an AI chat on one side and the actual text on the other. The difference from a chat history is exactly what spec-driven development is about: what grows here is a document with sections, interruptible and resumable at any time — not a conversation from which requirements would later have to be reconstructed.

## Step 2: The stack becomes a contract, not a guess

In the stack step you pick one of your organisation’s profiles or start from a platform template — Spring Boot, Laravel, Angular, React/Vite, Node/Express, Go, Quarkus or Flutter — and adapt it. The profile is [a contract, not a feature](https://anvil-coder.tech/en/frameworks): language, framework, versions and check commands are stated explicitly instead of a model guessing them from the repository. Everything built later is checked against exactly these statements.

## Step 3: The spec becomes tickets — and a person stays in charge

At the end you curate the epic slicing and let the studio generate: a project with repository, foundation document and the epics as real tickets in the tracker. What matters is what does **not** happen: no code run starts. The studio writes tickets — which story actually runs is still decided by a person, ticket by ticket. The specification sets the frame; it does not fire the starting gun itself.

## Step 4: Execution follows the spec — in small, provable steps

Once a story runs, the factory works [in phases and slices](https://anvil-coder.tech/en/how-it-works#achsen): requirements become a plan, the plan becomes small work steps, and [every task slice is deliberately small](https://anvil-coder.tech/en/blog/warum-taskslices-klein-sind) — small enough to fit into one prompt together with its context. Every step leaves its own commit. The result is a draft pull request whose [commit history is the evidence](https://anvil-coder.tech/en/blog/commit-historie-als-nachweis): to know whether the implementation followed the spec, you do not read a thousand-line diff but a chain of named steps.

## The honest ending: reviewed means reviewable

What stands at the end is a draft, not a fait accompli. The default is that a person merges — and judging the result on its merits remains the team’s work. What spec-driven development delivers at this point is not the sign-off but its foundation: a specification you can check against, and a trail along which to do it. To walk the path yourself, the [Spec Studio chapter in the documentation](https://docs.anvil-coder.tech/docs/spec-studio) (in German) covers all seven steps.

## Try it yourself?

The free tier needs no conversation, registration currently goes through a waitlist — create a project, pull an epic, review the result in your own repository.

[Start for free](https://app.anvil-coder.tech/register)[Book a demo](https://anvil-coder.tech/en/demo)