PRD Writing skill for Claude Code
Requirements engineers can estimate and test. Claude writes the problem before the solution, backed by tickets, data and quotes, then sets goals, explicit non-goals and success metrics that each carry a baseline, target, timeframe and guardrail. Requirements are prioritized P0 to P2 with Given-When-Then acceptance criteria, and vague asks like 'make it fast' are turned into numbers someone can test against.
- name
prd-writing - size163 lines · ≈1,750 tokens
- files1
- licenseMIT
- updated
What Claude sees before loading it
This description is the only part of the skill that sits in context all the time. Claude reads it to decide when to load the full playbook below.
description: Writes product requirement documents that engineering and design can build from — a problem statement backed by evidence, target users and jobs, goals and explicit non-goals, measurable success metrics with baselines and guardrails, prioritized requirements with testable acceptance criteria, risks, open questions, and rollout. Use when writing a PRD, product spec, feature brief, or one-pager, turning a vague feature request into requirements, or reviewing a PRD for gaps before kickoff.Try asking
- Turn this feature request thread into a PRD for bulk invoice exports
- Review our PRD and point out what's missing before engineering kickoff
- Write a one-pager for adding SSO, with success metrics and non-goals
Use it when
- Writing a PRD, product spec, or one-pager
- A feature request is vague and needs requirements
- Reviewing a spec for gaps before kickoff
- Defining success metrics for a launch
Skip it when
- You are proposing a technical architecture, use design-docs-rfc instead
- You need to break approved work into estimated tasks, use work-estimation instead
How to check the result
The review checklist passes: evidence-backed problem, non-goals, metrics with baselines and guardrails, testable acceptance criteria and owned open questions.
The common mistake it prevents
Stating a solution as the problem, such as 'users need a Kanban view', which skips the question of whether that view solves anything.
--- name: prd-writing description: Writes product requirement documents that engineering and design can build from — a problem statement backed by evidence, target users and… license: MIT ---
A PRD is done when an engineer could estimate it, a designer could start flows from it, and anyone could tell after launch whether it worked. It describes the problem and the required outcomes in testable terms; it does not prescribe implementation.
Ground rules
- Problem before solution. If the problem section is weaker than the solution section, the PRD is a feature request with formatting.
- Evidence over assertion: support tickets, usage data, interview quotes, revenue at risk. Mark assumptions explicitly as assumptions.
- Non-goals are as important as goals. They stop scope creep and settle arguments before they start.
- Every requirement is testable: someone can write an acceptance test for it.
- Metrics have a baseline, a target, a timeframe, and at least one guardrail.
- Short wins. A 2-page PRD that is read beats a 15-page one that is skimmed. Use a one-pager for small features; full PRD for multi-team or multi-month work.
Workflow
- [ ] 1. Gather evidence and constraints (data, tickets, interviews, deadlines)
- [ ] 2. Write the problem statement and who has it
- [ ] 3. Define goals, non-goals, and success metrics
- [ ] 4. Write requirements with priority and acceptance criteria
- [ ] 5. Capture flows, edge cases, and dependencies
- [ ] 6. List risks, open questions, and rollout plan
- [ ] 7. Review against the checklist; circulate for comments2. Problem statement
Pattern: who + struggles to do what + because + evidence + cost of not solving.
| Before | After |
|---|---|
| “Users want better exports.” | “Finance admins at accounts with 50+ seats export invoices to reconcile in their ERP every month. Exports time out above ~5,000 rows (38 tickets in Q3; 11% of enterprise churn interviews mention it), forcing manual splitting that takes 2–3 hours per close.” |
| “We need a dashboard.” | “Team leads cannot see which projects are behind until the weekly meeting; 4 of 6 interviewed leads keep a separate spreadsheet to track this.” |
3. Goals, non-goals, metrics
## Goals
1. Finance admins can export any month of invoices in one action.
2. Reduce export-related tickets.
## Non-goals
- Real-time ERP sync (separate initiative, Q2).
- Changing the invoice data model.
- Exports for non-admin roles.
## Success metrics
| Metric | Baseline | Target | Timeframe | Source |
|---|---|---|---|---|
| Export success rate for > 5k rows | 41% | ≥ 99% | 30 days after GA | export_job events |
| Export-related tickets / month | 13 | ≤ 3 | 60 days after GA | Zendesk tag "export" |
| Guardrail: p95 API latency during exports | 280 ms | no regression > 10% | continuous | APM |- Leading metric (behavior soon after launch) plus lagging metric (business outcome).
- Guardrails protect what must not get worse (latency, error rate, support load, conversion elsewhere).
- If a metric cannot be measured today, add the instrumentation as a requirement.
4. Requirements
Prioritize with P0 (launch blocker), P1 (should ship, can follow fast), P2 (nice to have). Write requirements as user-observable behavior plus acceptance criteria.
| ID | Priority | Requirement | Acceptance criteria |
|---|---|---|---|
| R1 | P0 | Admins can export all invoices for a chosen month as CSV | Given 50,000 invoices in October, when an admin requests the October export, then a complete CSV is available within 5 minutes and row count matches the invoice list |
| R2 | P0 | Large exports run in the background with notification | Export over 5,000 rows shows “We’ll email you when it’s ready”; email arrives with a link valid for 7 days |
| R3 | P1 | Column selection persists per user | Selected columns are pre-filled on the next export |
| R4 | P2 | XLSX format | — |
Before/after for vague requirements:
| Before | After |
|---|---|
| “Exports should be fast.” | “Exports of up to 50,000 rows complete within 5 minutes at p95.” |
| “Make it intuitive.” | “A first-time admin can start an export from the invoice list in ≤ 2 clicks.” (validate in usability test) |
| “Support all formats.” | “CSV (P0, RFC 4180, UTF-8 with BOM for Excel), XLSX (P2).” |
| “Handle errors gracefully.” | “If an export fails, the admin sees the failure in the exports list with a Retry action and the reason.” |
5. Flows, edge cases, dependencies
- Main flow as numbered steps or a link to design files.
- Edge cases checklist: empty data, maximum volume, permissions (who can and cannot), concurrent actions, partial failure, localization (dates, currency, RTL), accessibility, mobile, offline, data retention and privacy (PII in exports?), audit logging.
- Dependencies: teams, services, vendors, legal/security review, with owners and dates.
6. Risks, open questions, rollout
## Risks
| Risk | Likelihood | Impact | Mitigation |
| Large exports overload the read replica | Medium | High | Queue with concurrency 2 per region; load test at 3× peak |
## Open questions
| Question | Owner | Due | Answer |
| Do exports need to include voided invoices? | PM + Finance SME | Oct 25 | |
## Rollout
- Internal → 10% of enterprise accounts behind flag `bulk_exports` → GA
- Success gate to expand: export success ≥ 99%, no latency guardrail breach for 7 days
- Support/docs: help article, changelog entry, CSM briefingGotchas
- Writing the solution as the problem (“Users need a Kanban view”) hides whether a Kanban view is the right answer.
- Metrics without baselines make success unprovable; get the baseline before kickoff.
- Requirements that specify UI layout or tech stack constrain design and engineering without reason; specify behavior and constraints.
- Every requirement marked P0 means nothing is prioritized; aim for P0 ≤ ~40% of items.
- Open questions without owners and dates stay open until launch week.
- Silently changing a PRD after sign-off; keep a change log at the top.
Review checklist
- Problem has evidence and a cost of inaction
- Target users are specific (role, segment, size)
- Non-goals listed
- Each metric has baseline, target, timeframe, source; at least one guardrail
- Each P0/P1 requirement has testable acceptance criteria
- Edge cases (permissions, volume, failure, privacy, accessibility) addressed
- Dependencies and reviewers named
- Open questions have owners and due dates
- Rollout and success gate defined
Output contract
# PRD: <feature name>
Status: Draft | In review | Approved Owner: <PM> Last updated: <YYYY-MM-DD>
Reviewers: <eng lead, design, data, support, legal if needed>
Change log: <date — what changed>
## Problem
## Users and jobs to be done
## Goals
## Non-goals
## Success metrics
## Requirements (table: ID, priority, requirement, acceptance criteria)
## User flows and design links
## Edge cases
## Dependencies
## Risks
## Open questions
## Rollout and launch plan
## Appendix: evidence (data, quotes, tickets)About this skill
Written and maintained by the Claude Skills editors to the same editorial standard as every skill in the directory: a selective trigger, a real workflow, known pitfalls and a verification step. First published , last updated . MIT licensed.