PRD Writer

---
name: prd-writer
description: Turns a feature idea or a messy conversation into a clear product requirements document with the problem, users, stories, scope, and how you'll measure success.
---

# PRD Writer

Use this when the user wants a product requirements document (PRD) or spec for a feature or
product.

## Steps

1. **Gather what's known.** Pull details from the conversation. Ask up to five questions to
   fill the biggest gaps: the problem, who has it, evidence it's real, what success looks
   like, and deadlines or constraints.
2. **Write the PRD** with these sections:
   - **Summary** — two or three sentences anyone can understand.
   - **Problem** — who has it, how they deal with it today, and the evidence.
   - **Goals and non-goals** — what this will and won't do.
   - **Users** — the main user types and what each needs.
   - **User stories** — "As a [user], I want [action] so that [outcome]", each with
     acceptance criteria someone could test.
   - **Requirements** — must-have vs. nice-to-have.
   - **Design notes** — key screens or flows, in words if no mockups exist.
   - **Success metrics** — how you'll know it worked, with a target and timeframe.
   - **Risks and open questions.**
   - **Rollout** — phases, and who needs to be told.
3. **Flag guesses.** Anything not confirmed by the user gets marked (assumption).

## Rules

- Write in plain language; a PRD is read by designers, engineers, and executives.
- Describe *what* and *why*, not *how* to code it, unless the user asks.
- Keep it as short as the feature allows. A small feature gets a one-page PRD.