Draft a Product Requirements Document from a feature idea or brief — evidence-backed problem statement with zero solution language, testable MoSCoW-prioritized requirements, mandatory non-goals, and a success line per goal. Use when the user needs a PRD, wants to capture business requirements for a feature, or asks to turn an idea, pitch, or brief into a requirements doc.
Pack product-managerTier standardJob Decide what to buildv0.1.0
In Claude Code, with the product-manager plugin installed, invoke it as:
/product-manager:prd-draft
Try it
A realistic prompt from the skill's acceptance evals:
Draft a PRD for a saved-search feature in our analytics product — users keep re-running the same filters every morning.
What a good result looks like
The problem statement passes the alternative-solution test. If only one solution could follow from it, it's a spec, not a problem.
Every requirement is verifiable — a tester can demo it pass/fail. Implementation choices and adjective requirements both fail.
Won't-have list is non-empty and specific. "Out of scope: everything else" is an empty gesture; name the tempting things.
Every goal has a success line with a number and a timeframe. "Improve agent efficiency" is a hope; "median handle time −25% within 60 days of GA" is a goal.
Evidence is tagged to its source — [reported by X], [data: Y], [assumption]. A PRD's authority is exactly as good as its weakest untagged claim.
It reads in 30 minutes. Length is a tax on every reviewer; appendices exist for the rest.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 58% of its checks, against 62% without it, and a blind judge preferred the agent without it. How skills are checked
19 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
The problem statement contains zero solution language and passes the alternative-solution test — more than one solution could follow from it
Every requirement is verifiable — a tester can demo it pass or fail; adjective requirements and implementation choices are rejected
Requirements are MoSCoW-prioritized
The won't-have list is non-empty and names specific excluded things
Each goal carries a success line stating how it will be measured
Claims that need evidence are marked rather than asserted as fact
Does not promise real-time or within-minutes alerts; the requirements reflect that meter readings reach the utility only once a day
Uses or reconciles the call-centre figure (2,140 of 18,600 calls, about 11.5%) rather than repeating the brief's 30% as fact
Does not adopt the 20% network water-loss reduction as a target or fact without flagging that nothing in the inputs supports it
Respects the opt-in rule for SMS: does not switch SMS alerts on for all 140,000 customers, and accounts for app reach being only 9%
Deals explicitly with the 18% of homes on manually read meters (for example excluding them from v1), rather than assuming they get alerts
Does not invent figures, systems, or stakeholders not in the three input files
Stays under about three pages (roughly 1,500 words)
Produces the requirements write-up rather than only asking questions
About half a page — no more than roughly 300 words
Plain language that both a PTA parent and a hobbyist web developer can follow, without unexplained product-management jargon
Requirements are concrete enough to check (for example parents can see open slots, sign up, and the organiser can see who is coming), not vague aims
Keeps the scope small enough for one volunteer to build — does not make payments, accounts, or a mobile app must-haves
Does not invent specifics presented as facts (school name, number of events, existing systems, budget); any assumptions are marked
When it should and shouldn't activate
Should activate:
Draft a PRD for this feature
Write the product requirements document from this idea
I need testable requirements with MoSCoW priorities and non-goals
Turn this feature idea into a PRD engineering can build from
Should leave to another skill:
Write the press release before the product exists
Draft the engineering design doc for this
Split this epic into INVEST user stories
Write interview questions for our stakeholders
Hands off to
nfr-spec — when the functional requirements are agreed. Set the quality targets the design will be judged against.
user-story-splitter — when the requirements are ready to become units of work. Split into vertically-sliced stories with acceptance criteria.
design-doc — when the what is agreed and the how is open. Design the system that satisfies these requirements.