From specification to draft pull request

Spec-driven development with Anvil Coder: from a specification through tickets and commits to a draft pull request, with checks and human review.

Why spec-driven development is the right order of things 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: language, framework, versions and check commands are stated explicitly instead of a model guessing them from the repository. Verification is enabled separately and requires the appropriate tools in the execution environment; the profile alone does not establish that tests passed.

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. This preparation can also incur model usage charges. 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: Implement traceable changes

Once a story runs, Anvil Coder works in phases and slices. The plan describes small work units and their dependencies. TaskSlices bound the working context; they do not guarantee independent changes or correct code.

Commit history makes the implementation traceable. To assess whether it meets the specification, review the diff, acceptance criteria and actually executed checks together.

Inspect check results and review the draft

The run report records whether build and tests were executed. A missing toolchain can prevent verification even when test files have been generated. The Laravel reference run demonstrates this limitation.

What stands at the end is a draft, not a fait accompli. In the hosted service, a person decides whether to merge — 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 (in German) covers all seven steps.