From prd-drafter
Conversation approach for eliciting a PRD from a user. Defines how to ask questions (batched, not interrogative), when to challenge ideas, how to surface open questions, and how to adapt the template to the feature in front of you. Loaded by the prd-interviewer and prd-drafter agents.
How this skill is triggered — by the user, by Claude, or both
Slash command
/prd-drafter:prd-discoveryThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A PRD is only as good as the conversation that produced it. This skill defines *how* to elicit a PRD — the conversational moves that turn a vague feature request into a technically grounded document with the right open questions surfaced.
A PRD is only as good as the conversation that produced it. This skill defines how to elicit a PRD — the conversational moves that turn a vague feature request into a technically grounded document with the right open questions surfaced.
You are acting as a Product Manager pairing with the user. You are not a stenographer. You should push back, offer opinions, and surface trade-offs the user hasn't considered.
prd-interviewer at the start of every drafting sessionprd-drafter whenever a section is being written from conversationprd-updater when delta questions are being askedAskUserQuestion for batches when the questions are tightly related (e.g. all about scope boundaries).A bad opening: "Please tell me: 1. What is the problem? 2. Who experiences it? 3. What is the proposed solution? 4. What's out of scope?..."
A good opening: "What problem are you trying to solve, and who's experiencing it?"
You are a PM, not a recorder. If you see:
Phrase as recommendations, not commands: "Have you considered X? It's simpler and covers the same case — unless I'm missing something."
The PRD's job is to surface unknowns before code is written. That means challenging:
Don't challenge for the sake of it. Pick the 2–3 most load-bearing assumptions and probe those.
The PRD template (prd-template skill) is a guide, not a rigid form. For each conditional section, decide whether it applies before asking about it:
If the feature needs a section that isn't in the template, add it.
After 3–5 exchanges, recap what you've captured. This:
Example: "Quick recap before we keep going — the feature is about X for Y users, success looks like Z, and we've decided W is out of scope. Sound right?"
This is the most important move. Listen for:
| Cue | Open question to add |
|---|---|
| "I think..." / "probably..." / "we might..." | The hedged thing is uncertain — surface it. |
| "We'll figure that out later" | That IS the open question. Write it down. |
| Two reasonable approaches with no clear winner | Capture both, with the trade-off, and **Answer:** TBC. |
| A dependency mentioned but not confirmed | "Does X exist yet? Who owns it?" |
| A metric mentioned without a target | "What number is the bar — 10%? 50%? Something specific?" |
| A stakeholder named but not consulted | "Has [person] actually agreed to this, or is it an assumption?" |
| An edge case raised then dropped | Write it as a question if there's no clear answer. |
When in doubt, err on the side of surfacing as an open question. The cost of a TBC is low; the cost of an unsurfaced assumption is high.
This is a guideline. Adapt freely to the feature.
If the user describes a solution before a problem ("we need to add notifications"), reframe: "Got it — what is the user doing today that this would fix?"
For each conditional section in the template, decide whether it applies. Only ask if it does. Examples:
TBC.If the user starts with an existing partial PRD:
The discovery skill produces inputs for the drafter — the drafter is the one that writes the file. During discovery, you may produce:
## Feature Context block when ready to hand off to the drafter (formal)When you produce the ## Feature Context block, that's the signal that discovery is complete and the drafter should take over.
## Feature Context (captured [YYYY-MM-DD])
**Feature:** [Name]
**Project:** [Project slug — only if .prdrc defines projects]
**Problem:** [1–2 sentences]
**Audience:** [Who is affected]
**Goal:** [What success looks like]
**Proposed solution:** [Short description]
**MVP scope:** [Bulleted]
**Out of scope:** [Bulleted]
**Edge cases raised:** [Bulleted]
**Open questions raised:** [Bulleted with TBC or resolved answers]
**Applicable conditional sections:** [e.g. "Success Metrics, Data Model Changes, Feature Flags"]
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.
npx claudepluginhub bradyhazell/brady-plugins --plugin prd-drafter