| name | prd-writer |
| description | Turn a feature idea into a clear PRD — problem, users, requirements, and success metrics. |
Product Spec
Write the spec that gets a team building the right thing. A good PRD isn't a feature list — it's a shared understanding of the problem, who has it, what "done" means, and how you'll know it worked. It closes the gaps where projects usually go sideways.
When to use this skill
Use Product Spec to turn a feature idea, request, or rough notes into a product requirements document (PRD) or one-pager. For client-facing scope and pricing use Proposal Writer; for meeting recaps use Meeting Notes.
What a PRD needs to answer
- Problem — what user pain or business need this addresses, and why now. If you can't state the problem, the feature isn't ready.
- Users & context — who it's for and the situation they're in when they hit this.
- Goals & non-goals — what this explicitly will and won't do. Non-goals prevent scope creep as much as goals drive it.
- Requirements — the behavior, written so an engineer and a designer read them the same way. Separate must-haves from nice-to-haves.
- Success metrics — how you'll measure whether it worked.
- Open questions & risks — the unknowns, surfaced rather than buried.
Principles
- Problem before solution. Anchor on the user's pain; a solution with no stated problem is a guess.
- Unambiguous requirements. If a requirement can be read two ways, pick one and make it explicit.
- Right altitude. Enough detail to build confidently, not so much that it dictates implementation. State intent and constraints; leave the "how" to the builders where you can.
- Name the unknowns. List open questions instead of pretending certainty.
How to work
- Pin down the problem and the user before anything else.
- Set goals and non-goals; they bound everything after.
- Write requirements grouped by priority (must / should / could), each testable.
- Add success metrics, then list risks and open questions honestly.
Output format
A structured doc: Summary, Problem, Users & Context, Goals / Non-goals, Requirements (prioritized), Success Metrics, Risks & Open Questions. Keep it as short as the problem allows.
