Specify first · Then implement
The longer the chat with the coding agent, the further the result drifts from the goal, because the goal was never written down. Spec-driven development reverses the order: you describe what should exist, Spec Studio turns it into epics and stories, and every review has a yardstick to check against.
Audience, goals, non-goals, behaviour. Spec Studio asks the questions that otherwise surface mid-sprint, and takes notes.
Stack, interfaces, quality rules, check commands. They become the stack profile and the guardrails that later stand in every prompt.
The studio proposes epics and stories; you cut, add and decide which story runs first.
Every draft PR can be measured against the specification. What you learn flows back into the spec, not into a chat transcript.
Example
Monday, 09:00, product sync. “We need invitations,” someone says, and everyone nods. Ten minutes in Spec Studio later, the decisions the first developer would otherwise have made alone are on the table:
The spec becomes two stories. The first one runs the same afternoon; the draft PR that evening reads sentence by sentence against the four criteria.
Spec Studio guides you through vision, goals and non-goals, functional requirements, stack and constraints, quality rules and epic slicing. Every section has its own follow-up chat that names gaps instead of papering over them.
At the end the studio creates real tickets in your tracker, with a freshly created repository if you want one. It writes no code; the first run starts when you drag a story.
A specification does not make bad requirements good; it makes them visible before code exists. Contradictions and missing decisions surface in the studio, not in review.
Keep the spec current as you learn. Agents and reviewers then work against the same reference.