Use prd-draft

Draft a Product Requirements Document from a feature idea or brief

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.

Reach for it 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.

Install it

npx skilldrop-cli install prd-draft                 # Claude Code, your user folder
npx skilldrop-cli install prd-draft --project       # Claude Code, this repo
npx skilldrop-cli install prd-draft --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Product manager pack: --pack product-manager installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "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"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Write the press release before the product exists"
• "Draft the engineering design doc for this"
• "Split this epic into INVEST user stories"

If another skill answers instead, ask for this one by name: "use prd-draft".

Check what you get

A good result:

• 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.

Use something else when

• The technical how — architecture, stack, data model → design-doc
• Splitting into sprint-sized work → user-story-splitter (after the PRD)
• Whether to invest at all → business-case; the PRD assumes the investment decision is made
• A tiny change that needs a ticket, not a doc → user-story-splitter or bug-triage

Where a loop runs it

• Stage specify of the discover loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: brief-intake, bug-triage, business-case, design-doc, nfr-spec, success-metrics, user-story-splitter

Edit this page on GitHub · View source