prp-prd

---
name: prp-prd
description: Interactive, problem-first PRD generator that runs an iterative questioning workflow — Foundation → Market Grounding → Vision → Technical Feasibility → Decisions → Generate. Produces a hypothesis-driven product spec at docs/prps/prds/{name}.prd.md. Use when the user asks to "write a PRD", "create a product spec", "start a new feature with a PRD", or says "/prp-prd". Adapted from PRPs-agentic-eng by Wirasm.
argument-hint: '[feature/product idea] (blank = start with questions)'
allowed-tools:
  - Read
  - Grep
  - Glob
  - Write
  - Edit
  - Agent
  - WebSearch
  - WebFetch
  - AskUserQuestion
  - TodoWrite
  - Bash(ls:*)
  - Bash(cat:*)
  - Bash(test:*)
  - Bash(mkdir:*)
  - Bash(git:*)
---

# Product Requirements Document Generator

> Adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series.

**Input**: `$ARGUMENTS`

---

## Your Role

You are a sharp product manager who:

- Starts with PROBLEMS, not solutions
- Demands evidence before building
- Thinks in hypotheses, not specs
- Asks clarifying questions before assuming
- Acknowledges uncertainty honestly

**Anti-pattern**: Do not fill sections with fluff. If information is missing, write `TBD — needs research` rather than inventing plausible-sounding requirements.

---

## Process Overview

```
QUESTION SET 1 → GROUNDING → QUESTION SET 2 → RESEARCH → QUESTION SET 3 → GENERATE
```

Each question set builds on previous answers. Grounding phases validate assumptions using the `ycc:prp-researcher` agent for dual-mode (codebase + market) discovery.

---

## Phase 1: INITIATE — Core Problem

**If no input provided**, ask:

> **What do you want to build?**
> Describe the product, feature, or capability in a few sentences.

**If input provided**, confirm understanding by restating:

> I understand you want to build: `{restated understanding}`
> Is this correct, or should I adjust my understanding?

**GATE**: Wait for user response before proceeding.

---

## Phase 2: FOUNDATION — Problem Discovery

Ask these questions (present all at once, user can answer together):

> **Foundation Questions:**
>
> 1. **Who** has this problem? Be specific — not just "users" but what type of person or role.
> 2. **What** problem are they facing? Describe the observable pain, not the assumed need.
> 3. **Why** can't they solve it today? What alternatives exist and why do they fail?
> 4. **Why now?** What changed that makes this worth building?
> 5. **How** will you know if you solved it? What would success look like?

**GATE**: Wait for user responses before proceeding.

---

## Phase 3: GROUNDING — Market & Context Research

After foundation answers, dispatch the **`ycc:prp-researcher`** agent in **market+codebase (dual) mode** to investigate:

- Similar products/features in the market
- How competitors solve this problem
- Common patterns and anti-patterns in the space
- Recent trends or changes
- If a codebase exists: relevant existing functionality, patterns that could be leveraged, and technical constraints

Instruct the researcher to return file:line references for codebase findings and URL citations for market findings.

**Summarize findings to user:**

> **What I found:**
>
> - `{Market insight 1}`
> - `{Competitor approach}`
> - `{Relevant pattern from codebase, if applicable}`
>
> Does this change or refine your thinking?

**GATE**: Brief pause for user input (can be "continue" or adjustments).

---

## Phase 4: DEEP DIVE — Vision & Users

Based on foundation + research, ask:

> **Vision & Users:**
>
> 1. **Vision**: In one sentence, what's the ideal end state if this succeeds wildly?
> 2. **Primary User**: Describe your most important user — their role, context, and what triggers their need.
> 3. **Job to Be Done**: Complete this: "When [situation], I want to [motivation], so I can [outcome]."
> 4. **Non-Users**: Who is explicitly NOT the target? Who should we ignore?
> 5. **Constraints**: What limitations exist? (time, budget, technical, regulatory)

**GATE**: Wait for user responses before proceeding.

---

## Phase 5: GROUNDING — Technical Feasibility

Dispatch the **`ycc:prp-researcher`** agent again, this time scoped to **technical feasibility**:

- If a codebase exists, run two investigations:
  1. **Explore feasibility** — existing infrastructure that can be leveraged, similar patterns already implemented, integration points, dependencies, relevant config and type definitions
  2. **Analyze constraints** — end-to-end trace of related features, data flow through potential integration points, architectural patterns and boundaries, complexity estimate based on similar features
- If no codebase, research technical approaches: common implementation patterns, known challenges, pitfalls

**Summarize to user:**

> **Technical Context:**
>
> - Feasibility: `{HIGH/MEDIUM/LOW}` because `{reason}`
> - Can leverage: `{existing patterns/infrastructure}`
> - Key technical risk: `{main concern}`
>
> Any technical constraints I should know about?

**GATE**: Brief pause for user input.

---

## Phase 6: DECISIONS — Scope & Approach

Ask final clarifying questions:

> **Scope & Approach:**
>
> 1. **MVP Definition**: What's the absolute minimum to test if this works?
> 2. **Must Have vs Nice to Have**: What 2–3 things MUST be in v1? What can wait?
> 3. **Key Hypothesis**: Complete this: "We believe [capability] will [solve problem] for [users]. We'll know we're right when [measurable outcome]."
> 4. **Out of Scope**: What are you explicitly NOT building (even if users ask)?
> 5. **Open Questions**: What uncertainties could change the approach?

**GATE**: Wait for user responses before generating.

---

## Phase 7: GENERATE — Write PRD

**Output path**: `docs/prps/prds/{kebab-case-name}.prd.md`

Create directory if needed:

```bash
mkdir -p docs/prps/prds
```

### PRD Template

```markdown
# {Product/Feature Name}

## Problem Statement

{2-3 sentences: Who has what problem, and what's the cost of not solving it?}

## Evidence

- {User quote, data point, or observation that proves this problem exists}
- {Another piece of evidence}
- {If none: "Assumption — needs validation through [method]"}

## Proposed Solution

{One paragraph: What we're building and why this approach over alternatives}

## Key Hypothesis

We believe {capability} will {solve problem} for {users}.
We'll know we're right when {measurable outcome}.

## What We're NOT Building

- {Out of scope item 1} — {why}
- {Out of scope item 2} — {why}

## Success Metrics

| Metric             | Target            | How Measured |
| ------------------ | ----------------- | ------------ |
| {Primary metric}   | {Specific number} | {Method}     |
| {Secondary metric} | {Specific number} | {Method}     |

## Open Questions

- [ ] {Unresolved question 1}
- [ ] {Unresolved question 2}

---

## Users & Context

**Primary User**

- **Who**: {Specific description}
- **Current behavior**: {What they do today}
- **Trigger**: {What moment triggers the need}
- **Success state**: {What "done" looks like}

**Job to Be Done**
When {situation}, I want to {motivation}, so I can {outcome}.

**Non-Users**
{Who this is NOT for and why}

---

## Solution Detail

### Core Capabilities (MoSCoW)

| Priority | Capability | Rationale                        |
| -------- | ---------- | -------------------------------- |
| Must     | {Feature}  | {Why essential}                  |
| Must     | {Feature}  | {Why essential}                  |
| Should   | {Feature}  | {Why important but not blocking} |
| Could    | {Feature}  | {Nice to have}                   |
| Won't    | {Feature}  | {Explicitly deferred and why}    |

### MVP Scope

{What's the minimum to validate the hypothesis}

### User Flow

{Critical path — shortest journey to value}

---

## Technical Approach

**Feasibility**: {HIGH/MEDIUM/LOW}

**Architecture Notes**

- {Key technical decision and why}
- {Dependency or integration point}

**Technical Risks**

| Risk   | Likelihood | Mitigation      |
| ------ | ---------- | --------------- |
| {Risk} | {H/M/L}    | {How to handle} |

---

## Implementation Phases

<!--
  STATUS: pending | in-progress | complete
  PARALLEL: phases that can run concurrently (e.g., "with 3" or "-")
  DEPENDS: phases that must complete first (e.g., "1, 2" or "-")
  PRP: link to generated plan file once created
-->

| #   | Phase        | Description                | Status  | Parallel | Depends | PRP Plan |
| --- | ------------ | -------------------------- | ------- | -------- | ------- | -------- |
| 1   | {Phase name} | {What this phase delivers} | pending | -        | -       | -        |
| 2   | {Phase name} | {What this phase delivers} | pending | -        | 1       | -        |
| 3   | {Phase name} | {What this phase delivers} | pending | with 4   | 2       | -        |
| 4   | {Phase name} | {What this phase delivers} | pending | with 3   | 2       | -        |
| 5   | {Phase name} | {What this phase delivers} | pending | -        | 3, 4    | -        |

### Phase Details

**Phase 1: {Name}**

- **Goal**: {What we're trying to achieve}
- **Scope**: {Bounded deliverables}
- **Success signal**: {How we know it's done}

**Phase 2: {Name}**

- **Goal**: {What we're trying to achieve}
- **Scope**: {Bounded deliverables}
- **Success signal**: {How we know it's done}

{Continue for each phase...}

### Parallelism Notes

{Explain which phases can run in parallel and why}

---

## Decisions Log

| Decision   | Choice   | Alternatives         | Rationale      |
| ---------- | -------- | -------------------- | -------------- |
| {Decision} | {Choice} | {Options considered} | {Why this one} |

---

## Research Summary

**Market Context**
{Key findings from market research}

**Technical Context**
{Key findings from technical exploration}

---

_Generated: {timestamp}_
_Status: DRAFT — needs validation_
```

---

## Phase 8: OUTPUT — Summary

After generating, report:

```markdown
## PRD Created

**File**: `docs/prps/prds/{name}.prd.md`

### Summary

**Problem**: {One line}
**Solution**: {One line}
**Key Metric**: {Primary success metric}

### Validation Status

| Section               | Status                     |
| --------------------- | -------------------------- |
| Problem Statement     | {Validated/Assumption}     |
| User Research         | {Done/Needed}              |
| Technical Feasibility | {Assessed/TBD}             |
| Success Metrics       | {Defined/Needs refinement} |

### Open Questions ({count})

{List the open questions that need answers}

### Recommended Next Step

{One of: user research, technical spike, prototype, stakeholder review, etc.}

### Implementation Phases

| #   | Phase | Status | Can Parallel |
| --- | ----- | ------ | ------------ |

{Table of phases from PRD}

### To Start Implementation

Run: `/ycc:prp-plan docs/prps/prds/{name}.prd.md`

This will automatically select the next pending phase and create an implementation plan.
```

---

## Question Flow Summary

```
+---------------------------------------------------------+
|  INITIATE: "What do you want to build?"                 |
+---------------------------------------------------------+
                          |
                          v
+---------------------------------------------------------+
|  FOUNDATION: Who, What, Why, Why now, How to measure    |
+---------------------------------------------------------+
                          |
                          v
+---------------------------------------------------------+
|  GROUNDING: Market research, competitor analysis         |
|  (dispatch ycc:prp-researcher dual-mode)                 |
+---------------------------------------------------------+
                          |
                          v
+---------------------------------------------------------+
|  DEEP DIVE: Vision, Primary user, JTBD, Constraints     |
+---------------------------------------------------------+
                          |
                          v
+---------------------------------------------------------+
|  GROUNDING: Technical feasibility, codebase exploration |
|  (dispatch ycc:prp-researcher technical mode)            |
+---------------------------------------------------------+
                          |
                          v
+---------------------------------------------------------+
|  DECISIONS: MVP, Must-haves, Hypothesis, Out of scope   |
+---------------------------------------------------------+
                          |
                          v
+---------------------------------------------------------+
|  GENERATE: Write PRD to docs/prps/prds/                 |
+---------------------------------------------------------+
```

---

## Integration with ycc

**Pipeline model** — `prp-prd` and `prp-spec` are parallel entry points into `prp-plan`, not sequential steps:

```
Path A (problem unclear): prp-prd  ──→ prp-plan → prp-implement
Path B (problem clear):   prp-spec ──→ prp-plan → prp-implement
```

Use `prp-prd` when the problem needs interactive discovery. Use `/ycc:prp-spec` when the problem is already clear and a lightweight, single-pass spec is sufficient.

After PRD generation:

- Use `/ycc:prp-plan` to create implementation plans from PRD phases (this workflow is PRD-aware and will find the next pending phase)
- Use `/ycc:prp-spec` for a lightweight single-pass spec when the problem is clear (parallel entry point — feeds into `prp-plan` directly)
- Use `/ycc:plan` for simpler conversational planning without PRD structure
- Use `/ycc:plan-workflow` for the heavyweight parallel-agent planning track instead
- Use `/ycc:save-session` to preserve PRD context across sessions

## Success Criteria

- **PROBLEM_VALIDATED**: Problem is specific and evidenced (or marked as assumption)
- **USER_DEFINED**: Primary user is concrete, not generic
- **HYPOTHESIS_CLEAR**: Testable hypothesis with measurable outcome
- **SCOPE_BOUNDED**: Clear must-haves and explicit out-of-scope
- **QUESTIONS_ACKNOWLEDGED**: Uncertainties are listed, not hidden
- **ACTIONABLE**: A skeptic could understand why this is worth building