write-prd

/write-prd -- Product Requirements Document

Create a lean PRD that aligns stakeholders and guides development. Accepts anything from a vague idea to a detailed brief.

Invocation

/write-prd SSO support for enterprise customers
/write-prd Users are dropping off during onboarding — we need to fix step 3
/write-prd [upload a brief, research doc, or strategy deck]

Workflow

Step 1: Understand the Feature

Accept the input in any form:

• A feature name ("SSO support")
• A problem statement ("Enterprise customers keep asking for centralized auth")
• A user request ("Users want to export their data as CSV")
• A vague idea ("We should do something about onboarding drop-off")
• An uploaded document (brief, research, Slack thread, email)

Step 2: Fill Only the Gaps That Matter

Extract what the input already gives you, and research what the web can answer (prior art, competitors, market context) instead of asking. If any of these three is missing, ask about it before writing, in one message, three questions at most:

1. User problem: What problem does this solve? Who experiences it, and how painful is it?
2. Target users: Which user segment(s)? What's their current workaround?
3. Success metrics: How will we know this worked? What moves if we nail it?

Constraints, prior art, and scope preference are worth asking about only if the user wants the detailed version. If the user says "just write it", go ahead and mark the gaps as assumptions.

Step 3: Generate the PRD

Apply the create-prd skill: its 8-section template, lean by default (about one to two pages). Write the detailed version only if the user asks for it. Start the document with:

## Product Requirements Document: [Feature Name]

**Author**: [user]
**Date**: [today]
**Status**: Draft

Then the eight sections: Summary, Contacts (if known), Background, Objective, Market Segment(s), Value Proposition(s), Solution, Release. Market Segments and Value Propositions are always included; each value proposition uses the 6-part template (Who, Why, What before, How, What after, Alternatives). Put what the first version will not do in Release, and what's still unknown in Solution → Assumptions and open questions.