You came for a product spec template — the sections, the headings, a structure to build from. It's below; take it. A spec is the document closest to the metal: not "what are we building and why" (that's the PRD) but "here is exactly how it works." The trouble is where it lives. Write it in a doc and it detaches from the PRD and the decisions above it — so when a call upstream changes, the spec keeps describing a thing you're no longer building, and the engineer (or the AI agent) builds from fiction. Draftlize gives you the same eight sections, makes each one a card wired to the decisions it depends on, and flags the spec stale the moment one of them moves.
This is the whole spec template. It works in a doc, a wiki, or a markdown file — it's the shape a good feature or technical spec already takes. Use it as-is. The next section is about what changes when each part stops being a heading in a document and becomes a card that knows what it depends on.
What this feature is and the user-facing outcome it produces, in a few lines. Not the business case — that lives in the PRD — but enough that a reader knows what they're about to build before the requirements start.
What the system does, stated as concrete, checkable behaviors. "When a user submits with an empty title, show an inline error and block save." If a requirement can't be turned into a test, it's still a wish, not a spec.
The shape of the implementation: the components, the flow, the key choices and why this approach over the obvious alternative. This is where the spec earns its keep — it's the part a coding agent reads to avoid re-deciding what was already decided.
The tables, fields, types, and endpoints — the surface other code commits to. The most expensive section to get wrong and the first one downstream work hard-codes against, so it's the one that most needs to be addressable, not buried.
Empty, concurrent, offline, malformed, rate-limited, half-failed. The gap between a demo and a product lives entirely here — and it's the section that quietly rots first when the happy-path design changes and nobody revisits the edges.
The decisions, other specs, and services this spec assumes hold — the pricing call, the auth model, the schema two features over. In a doc this is a list you forget to update. It's the section that decides whether the spec stays true when the world above it moves.
How you'll know it works: the cases that must pass, the behaviors that must hold. Written before the code, this is the line between "shipped" and "shipped, probably." Written after, it just describes whatever the code happens to do.
Flag, migration, staged release, rollback. How this reaches users without a bad night — and how it comes back if it has to. The section everyone skips and the one the on-call engineer wishes had existed.
That's the template. Below: why a spec in a doc drifts away from the PRD above it — and what we do about it.
A PRD says what to build and why; a spec says exactly how. That's a real dependency: the spec only makes sense while the PRD it implements still holds. But in two separate docs nothing encodes that link, so the spec floats free — and the closer it sits to implementation, the more expensive it is when it's wrong.
A decision shifts — the pricing model, the auth flow, a field on the core object. The PRD gets updated, maybe. The spec that built on the old call doesn't, because re-syncing it is manual and competes with shipping. Now Data model and Edge cases describe a system that no longer exists, and no banner says so.
Hand a doc to a coding agent and it builds exactly what the doc says — including the parts that quietly went out of date three commits ago. A spec that can't tell you which of its sections are still trustworthy is worse than no spec: it lends false confidence to the wrong implementation.
In Draftlize the spec isn't a single document — each part is a typed card: Overview, Functional requirements, Technical approach, Data model / API, Edge cases, Dependencies, Test criteria, Rollout. Structured, addressable by ID, and citable from a thread or a sibling spec instead of buried under a wiki heading.
Because Dependencies is a real link to the decisions above it — not a list of nouns — changing one of those decisions turns the spec cards that rested on it stale automatically. In a build context we call it drift_detected: the substrate notices the implementation spec no longer matches the call it was written under, the way a build system invalidates everything downstream of a changed file.
Claude Code or Cursor, over MCP, reads the live spec before it writes a line — and sees, on the same surface, which sections are flagged stale and why. The spec stops being a snapshot an agent trusts blindly and becomes context it re-reads every turn, current to the last decision.
A PRD says what to build. A spec says how. The spec is only safe to build from while the decisions above it still hold — so let those decisions flag it when they move.Keep the eight sections. Let the substrate keep them in sync.
A product spec is the document closest to the build: not "what are we making and why" — that is the PRD — but "here is exactly how it works." It describes the behavior, states, edge cases, and constraints in enough detail that an engineer, or an AI agent, can implement it without guessing.
A PRD sets the intent — the problem, the audience, the outcome. A spec turns that intent into precise behavior. The PRD says "users can recover a deleted project"; the spec says exactly how recovery works, for how long, with what permissions, and what happens at each failure. One decides what to build, the other defines how it works.
Typically an overview, goals and non-goals, the detailed behavior or user flow, states and edge cases, technical constraints, dependencies, and open questions. The template above covers all of these — use it as-is in a doc, a wiki, or a markdown file.
The failure is that a spec detaches from the PRD and the decisions above it, so when a call upstream changes, the spec keeps describing something you are no longer building. Draftlize wires each section to the decisions it depends on and flags the spec stale the moment one of them moves, so the engineer or agent never builds from a fossilized version.
Take the template above, or spin up a project and let the agent draft the spec from your PRD and decisions — then keep every section, and the calls it depends on, in sync for you while you build.
Start free with $5One click creates a project with these exact sections as typed, linked cards. Answer them with the agent — and when a decision changes later, every dependent section flags stale instead of silently drifting. $5 free credit on signup, no card required.