Feature spec template

Your agent drafts the spec for one feature in under a minute — then you share one link that collects comments on the exact line, before anyone estimates.

What it is

A feature spec scopes a single feature: the goal, the non-goals, the user flows, the acceptance criteria, and the edge cases. It's narrower than a PRD — one feature, one document, one owner.

A feature spec answers one question: what does "done" look like for this specific feature? Without one, that answer lives in three Slack threads, a Figma comment, and an engineer's head — and it's different in all three places. Draft it with your agent, share the link, and the feedback lands on the line it's about.

Generate it with your agent

Paste this into Claude, Cursor, or any agent:

claude

❯

Write a feature spec for {feature}. Structure it as: 1) Goal — one sentence, the user outcome when this ships, 2) Non-goals — what this feature explicitly won't do (prevents scope creep), 3) User flow — the happy path, step by step, plus the two most likely failure states, 4) Acceptance criteria — testable conditions that define 'done,' written so QA can use them without asking clarifying questions, 5) Edge cases — nulls, permission boundaries, concurrent actions. Then publish it to Drafty so I can share a link and collect inline comments — no account needed to reply.▌

See it on a real one

Live canvas — comment on any elementOpen ↗

What goes in a feature spec

Five sections. Each one earns its place:

Goal — one sentence, user-outcome framed. "Users can reset their password without contacting support" is a goal. "Add password reset functionality" is a task description.
Non-goals — the section most specs skip. List what this feature deliberately won't do: no SSO integration, no bulk reset, no admin override in v1. The out-of-scope list stops the most expensive conversations.
User flow — the happy path first, step by step. Then the two failure states most likely to hit production: network drop, invalid input, permission error. If you don't define these, engineering will — and their default may not match yours.
Acceptance criteria — binary, testable conditions. Not "the form works." Try: "submitting a valid email address sends a reset link within 30 seconds; submitting an unrecognised address shows the same success state (no email enumeration)." QA can run these without a conversation.
Edge cases — nulls, duplicates, concurrency. What happens if the user clicks twice? What if the token expires mid-flow? These take ten minutes to write and save a half-day of back-and-forth per feature.

The non-goals section is the one that pays

Most makers and PMs write goal-first, edge-cases-last, and skip non-goals entirely. That's backwards in practice. The non-goals section is what prevents "while we're in there" from eating your sprint. If it's not in the spec, it's in scope by default — and scope by default is how a two-day feature becomes a two-week one.

Write non-goals before you write the user flow. It forces a decision: is this a v1 constraint or a permanent cut? Name the reason ("not in v1 — adds auth complexity before we've validated the core flow") so you're not re-litigating it in standup.

Feature spec vs. PRD

They're not interchangeable — they're sequential:

PRD — the problem, the users, the success metric, the full scope. Written before you know which features you're building. Read by stakeholders and cross-functional leads.
Feature spec — one feature from that PRD, translated into what engineering and QA can act on. Written once a feature is approved. Read by the people building it.

A PRD with five features in it is often five feature specs waiting to be written. Use the PRD template to align on the whole; write a feature spec for each piece once the scope is locked.

FAQ

What's the difference between a feature spec and a technical spec? A feature spec defines what the feature should do and the conditions for "done." A technical spec (or engineering spec) goes a level deeper — data models, API contracts, system architecture. Feature specs are usually PM or maker-authored; technical specs are engineering-authored. For a small feature, they're sometimes one document. For anything with cross-service dependencies, keep them separate.

How long should a feature spec be? One to two pages for most features. If it's running to four pages, you're probably specifying a subsystem, not a feature — consider splitting it. The useful test: can a new engineer read it and estimate in under twenty minutes? If not, it's either too long or missing the right information.

Who writes the feature spec? The PM or maker who owns the feature typically writes it, with engineering reviewing for feasibility and QA reviewing the acceptance criteria before work starts. The best specs have early engineering input — not to prescribe the how, but to catch "that's three services, not one" before the sprint starts.

What's the most common mistake in a feature spec? Writing acceptance criteria that aren't testable. "The feature feels fast" and "error messages are helpful" aren't acceptance criteria — they're aspirations. Acceptance criteria need to be binary: it either passes or fails. If your QA engineer has to make a judgment call, the criterion isn't written yet.

Should a feature spec include designs? Reference them — don't duplicate them. Link to the Figma file or the specific frame; don't paste screenshots that go stale. The spec describes the behavior; the design shows the interface. Keep them as separate artifacts with a clear link between them.

Can I use one spec for multiple related features? Only if they ship together and are genuinely inseparable. A shared spec for related features often means neither gets scoped tightly enough. When in doubt, write one spec per feature and note the dependency explicitly ("this depends on the password reset spec shipping first").