PRD Writer
Idea to structured PRD in one command. Scope, requirements, measurable success criteria, and the open questions that will block engineering if you don't answer them first.
How It Works
- Idea or research brief: A sentence, conversation, or /research-team output
- Gather context: Target repo, CLAUDE.md, architecture, stakeholders, constraints
- Diagrams first: Phase 0 — render-verified architecture + flow pack via /prd-diagrams
- Write the markdown PRD: Problem · metrics · testable AC · tech spec · agent-team plan
- Build HTML companion: Mission Control theme + interactive operator checklist + diagrams
- Sanitization gate: Leak guard on outward-facing files — PII / infra / codenames
- PRD + handoff: Markdown + HTML to docs/prd/ · /ship command printed
Invocation Triggers
/prd-writerwrite PRDproduct requirementsspec this featuredocument this ideaUse Cases
- Turn a Slack idea into a structured PRD before the first line of code
- Write explicit non-goals to kill scope creep before it starts
- Surface open questions that will block engineering if left unresolved
The Problem
Product ideas die in Slack, or they survive as half-formed intentions that engineers have to interpret. The PRDs that do get written are either novels nobody reads or one-liners that leave too much to imagination. Engineers start without clarity and finish building the wrong thing.
What It Does
- 1Extract the core idea
Who is the user, what is the problem, what is the proposed solution, why now — not "someday", but why this sprint. If the answer to "why now" is unclear, that is the first open question.
- 2Define scope
Explicit in/out of scope and non-goals. Non-goals are the most important section: they prevent scope creep and resolve half the arguments before they start.
- 3Write functional requirements
User-facing behaviors, not technical specs. "User can reset their password via email" not "implement SMTP with JWT token validation." The requirement describes what the system does for the user — the implementation is the engineer's domain.
- 4Write success criteria
Measurable, specific, testable. Not "users should find it easy" — "time to complete the reset flow is under 60 seconds for 90% of users." If you cannot tell whether the criteria are met, they are too vague.
- 5Surface open questions
Unresolved decisions that will block implementation. Who decides, and by when. If the PRD has no open questions, it is either perfect or incomplete. Almost always incomplete.
What You Get / What It Doesn't Do
- Structured PRD with title, date, and author
- Scope section with explicit non-goals
- Functional requirements written as user-facing behaviors
- Measurable success criteria that are specific and testable
- Open questions block with owner and deadline for each
- Make product decisions for you
- Write technical specs or implementation plans
- Validate with real users
- Replace a discovery sprint for genuinely novel problems
Tips
It is where the real work is. A PRD with five solid open questions and ten requirements beats a PRD with zero open questions and thirty requirements — the latter is hiding unresolved decisions in prose.
"Users want X" is not a requirement. Name someone specific — a persona, a segment, a job title. That specificity forces real prioritization.
After writing, read each one out loud. If you cannot tell whether it is met after the feature ships, it is too vague. Rewrite until it is unambiguous.
Get the Skill
Unlock the full PRD Writer SKILL.md — drop it into ~/.claude/skills/ and trigger it by name.
- Structured PRD with title, date, and author
- Scope section with explicit non-goals
- Functional requirements written as user-facing behaviors
- Measurable success criteria that are specific and testable
Commonly Used With
29 more production skills ready to install.