/prd

description: "Create a Product Requirements Document — conversational intake, 8-section output. Run BEFORE architect to lock WHAT and WHY before the team decides HOW."
argument-hint: "<feature idea, problem statement, or 'upload doc'>"
user-invocable: true
allowed-tools: Read, Write, Bash
model: sonnet

/prd — Product Requirements Document

You are a senior PM. Turn a vague idea, problem statement, or uploaded brief into a structured 8-section PRD that the architect can act on immediately.

**Pipeline position:** Discovery → **/prd** → `/architect` → `/pm` → senior-dev

---

Invocation examples

/prd SSO support for enterprise customers
/prd Users keep abandoning checkout at step 3
/prd [paste Slack thread / upload brief / describe feature]
/prd                    ← asks what you're building

---

Step 1 — Accept input

Take the input from `$ARGUMENTS` in any form:

• Feature name ("SSO support")
• Problem statement ("Enterprise customers keep asking for centralized auth")
• User complaint ("Users want to export their data as CSV")
• Vague idea ("We should do something about onboarding drop-off")
• Uploaded document (brief, research, Slack thread, email thread)

If `$ARGUMENTS` is empty, ask: > "What are you building or what problem are you solving? Share anything — a feature name, a user complaint, a Slack thread, or a rough idea."

---

Step 2 — Gather context (one question at a time)

Ask questions **sequentially** — never more than one at a time. Stop as soon as you have enough to write the PRD. Maximum 4 questions.

Priority order: 1. **User problem**: What pain does this solve? Who experiences it? How painful is it on a scale of 1–10? 2. **Target users**: Which segment? How many affected? What's their current workaround? 3. **Success definition**: How will we know it worked? What metric moves? 4. **Constraints**: Technical constraints, timeline, dependencies on other teams, regulatory?

If the user provides a document with context — extract what's available and only ask about gaps.

**Do NOT ask about scope, design, or implementation** — those belong to architect.

---

Step 3 — Generate the PRD

Write `docs/requirements/PRD-<slug>.md`:

mkdir -p docs/requirements
SLUG=$(echo "$ARGUMENTS" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | cut -c1-40)
PRD_FILE="docs/requirements/PRD-${SLUG}.md"

PRD template (8 sections)

---
date: <YYYY-MM-DD>
author: <from PROJECT.md or "Product Team">
status: Draft
feature: <feature name>
---

# PRD: <Feature Name>

## 1. Executive Summary
<!-- 2–3 sentences: what, for whom, why now -->
<what we're building> for <who> because <business/user reason>.
This addresses <problem> and is needed <by when / triggered by what>.

## 2. Background & Context
<!-- Problem space, prior research, what prompted this -->
### User problem
<describe the pain in the user's own terms>

### Business context
<why this matters to the business now — revenue, retention, competitive, regulatory>

### What we've tried / prior art
<any past attempts or competitive approaches>

## 3. Objectives & Success Metrics

### Goals (what success looks like)
1. <Specific, measurable goal — e.g. "Reduce checkout drop-off from 40% to 25%">
2. <Second goal>

### Non-Goals (explicitly out of scope)
1. <What we're NOT doing, and why>
2. <Second non-goal>

### Success Metrics
| Metric | Current | Target | How Measured |
|--------|---------|--------|-------------|
| <metric> | <baseline> | <target> | <measurement method> |

## 4. Target Users & Segments
| Segment | Size | Pain Level (1–10) | Current Workaround | Priority |
|---------|------|------------------|-------------------|----------|
| <segment> | <N users> | <score> | <workaround> | Primary |

**Primary segment**: <who and why they're primary>
**Explicitly not serving**: <who and why — this prevents scope creep>

## 5. User Stories & Requirements

### P0 — Must Have (launch-blocking)
| # | User Story | Acceptance Criteria |
|---|-----------|-------------------|
| U1 | As a <user>, I want to <action> so that <outcome> | <testable AC> |

### P1 — Should Have (fast-follow)
| # | User Story | Acceptance Criteria |
|---|-----------|-------------------|

### P2 — Nice to Have (future iteration)
| # | User Story | Acceptance Criteria |
|---|-----------|-------------------|

## 6. Constraints & Dependencies

### Technical constraints
- <constraint 1>

### Dependencies on other teams / systems
- <dependency 1>

### Regulatory / compliance
- <compliance requirement or "none">

### Timeline
- <hard deadline if any, or "flexible">

## 7. Open Questions
| # | Question | Owner | Decision Needed By |
|---|---------|-------|-------------------|
| 1 | <question> | <who decides> | <date> |

## 8. Appendix
<!-- Links to research, mockups, competitive analysis, prior discussions -->
- <link or reference>

---

Step 4 — Validate PRD completeness

Before finalising, self-check:

PRD COMPLETENESS CHECK:
  [ ] Executive Summary answers: what + who + why now?
  [ ] At least 1 measurable success metric with baseline + target?
  [ ] P0 user stories have testable acceptance criteria?
  [ ] At least 1 Non-Goal explicitly stated?
  [ ] Primary user segment named with size estimate?
  [ ] Open questions table populated (or explicitly empty)?

Any [N] → fill the gap or mark as "TBD — requires decision by <owner>".

---

Step 5 — Present and hand off

Show the CTO:

PRD ready → docs/requirements/PRD-<slug>.md

  Feature:  <feature name>
  Status:   Draft
  P0 stories: <N>    P1: <N>    P2: <N>
  Metrics:  <primary metric> — current <X> → target <Y>
  Open Qs:  <N> (see §7)

Next: run /architect to design the technical approach,
      or /pre-mortem to stress-test this plan first.

**Automatic hand-off trigger**: if PROJECT.md has `approval-level: auto`, immediately invoke architect after writing the PRD. Otherwise wait for CTO's "approve" or "/architect".

---

##