---
name: "product-requirements-draft"
description: "Draft requirements with scope, user stories, acceptance criteria, open questions, and success measure."
triggers: ["PRD", "product spec", "requirements doc", "write a spec", "acceptance criteria"]
version: "1"
---
# Product requirements draft
Use this once the team has agreed which problem to solve.
## Problem and goal
State the user, the problem, and the evidence behind it, with counts and
sources. Give one goal that can be measured, the current baseline, and how
it will be tracked. If there is no baseline yet, say so.
## Scope and criteria
- **In scope**: user stories in the form "As a ..., I want ..., so that ...";
- **Out of scope**: what this work will not do, stated plainly;
- **Acceptance criteria**: for each story, testable conditions an engineer
and a tester can check;
- **Edge cases**: empty states, limits, permissions, errors;
- **Dependencies**: other teams, data, or approvals needed.
Describe what the user must be able to do, not how to build it. Leave design
and technical choices to the people who own them.
## Open questions
List each open question, who can answer it, and whether it blocks the build.
Add known risks and what would make the team stop or change course.
Do not commit engineering to scope or a date, and do not edit the tracker
yourself; draft for approval. Never invent a metric, quote, or estimate.