prd

# Product Requirements Document (PRD)

## Overview

Design comprehensive, production-grade Product Requirements Documents (PRDs) that bridge the gap between business vision and technical execution. This skill works for modern software systems, ensuring that requirements are clearly defined.

## When to Use

Use this skill when:

- Starting a new product or feature development cycle
- Translating a vague idea into a concrete technical specification
- Defining requirements for AI-powered features
- Stakeholders need a unified "source of truth" for project scope
- User asks to "write a PRD", "document requirements", or "plan a feature"

---

## Operational Workflow

### Phase 1: Deep Discovery (The Interview)

Before writing a single line of the PRD, you **MUST** conduct an in-depth, multi-round interview with the user using `AskUserQuestion`. Do not assume context. Do not settle for surface-level answers.

**Interview Protocol:**

1. **Start broad, then drill deep.** Begin with the core problem, then follow each answer with probing follow-ups that surface hidden assumptions, edge cases, and trade-offs.
2. **Ask non-obvious questions.** Avoid generic checklist questions. Tailor each question to what the user just said. Challenge vague or contradictory statements.
3. **Continue until saturation.** Keep interviewing until no new information emerges. Minimum 3 rounds of questions — more if the domain is complex or ambiguous.
4. **Surface gray zones explicitly.** For every major feature or requirement, ask: "What happens when [unexpected scenario]?" and "What should we NOT do here?"

**Interview Dimensions (cover all that apply):**

- **The Core Problem**: Why now? What happens if we don't build this? Who suffers most?
- **Success Metrics**: How do we know it worked? What's the minimum bar vs. aspirational target?
- **User Context**: Who are the actual users? What are their current workarounds? What will frustrate them?
- **Scope Boundaries**: What's explicitly out of scope? What adjacent features will users expect but we won't deliver?
- **Edge Cases & Failure Modes**: What inputs or states break the happy path? What does graceful degradation look like?
- **Trade-offs**: Speed vs. accuracy? Flexibility vs. simplicity? Build vs. buy?
- **Constraints**: Budget, tech stack, timeline, team size, compliance requirements?
- **Dependencies & Integration**: What existing systems does this touch? Who else needs to agree?
- **Evolution**: How might requirements change in 3-6 months? What's the most likely pivot?

**Anti-Patterns for Discovery:**

- ❌ Asking all questions in one giant batch (overwhelms the user, loses follow-up depth)
- ❌ Accepting "it should be fast" or "it should be easy" without pressing for numbers
- ❌ Skipping edge cases because the user didn't mention them
- ❌ Moving to Phase 2 before the user confirms "I think that covers it"

### Phase 1.5: Technical Feasibility Research

Before drafting, verify that key technical assumptions actually hold. **Do not rely on training knowledge alone** — use WebSearch to check official docs, changelogs, and known compatibility issues.

**When to run this phase:**
- Any time the PRD involves an external API, third-party service, or library
- When the tech stack has version constraints or ecosystem compatibility concerns
- When the user hasn't specified a tech stack (research viable options before proposing)

**Research Checklist:**
- [ ] **External APIs**: Confirm endpoint availability, auth method, rate limits, and known breaking changes
- [ ] **Client/Platform Compatibility**: Does this work across all target clients (web, mobile, desktop, CLI)?
- [ ] **Library/Framework Versions**: Are the required features available in the project's current version?
- [ ] **Known Failure Patterns**: Search for "[library] [feature] issues" to surface gotchas before coding

**Output**: Add a `## Technical Feasibility` section to the PRD that lists:
- Verified assumptions (with source)
- Unverified assumptions (flagged as `TBD — verify before planning`)
- Identified risks with mitigation options

**Anti-Patterns:**
- ❌ Assuming Claude's training knowledge is current for fast-moving ecosystems (OAuth flows, mobile browser behavior, API schemas)
- ❌ Skipping this phase because "it's a well-known library" — that's exactly when hidden version gaps appear

### Phase 2: Analysis & Scoping

Synthesize the user's input and feasibility findings. Identify dependencies and hidden complexities.

- Map out the **User Flow**.
- Define **Non-Goals** to protect the timeline.

### Phase 3: Technical Drafting

Generate the document using the **Strict PRD Schema** below.

---

## PRD Quality Standards

### Requirements Quality

Use concrete, measurable criteria. Avoid "fast", "easy", or "intuitive".

```diff
# Vague (BAD)
- The search should be fast and return relevant results.
- The UI must look modern and be easy to use.

# Concrete (GOOD)
+ The search must return results within 200ms for a 10k record dataset.
+ The search algorithm must achieve >= 85% Precision@10 in benchmark evals.
+ The UI must follow the 'Vercel/Next.js' design system and achieve 100% Lighthouse Accessibility score.
```

---

## Strict PRD Schema

You **MUST** follow this exact structure for the output:

### 1. Executive Summary

- **Problem Statement**: 1-2 sentences on the pain point.
- **Proposed Solution**: 1-2 sentences on the fix.
- **Success Criteria**: 3-5 measurable KPIs.

### 2. User Experience & Functionality

- **User Personas**: Who is this for?
- **User Stories**: `As a [user], I want to [action] so that [benefit].`
- **Acceptance Criteria**: Bulleted list of "Done" definitions for each story.
- **Non-Goals**: What are we NOT building?

### 3. AI System Requirements (If Applicable)

- **Tool Requirements**: What tools and APIs are needed?
- **Evaluation Strategy**: How to measure output quality and accuracy.

### 4. Technical Feasibility

- **Verified Assumptions**: What was confirmed via research (cite source).
- **Unverified Assumptions**: Flagged as `TBD — verify before planning`.
- **Compatibility Risks**: Client/platform/version gaps found during Phase 1.5.

### 5. Technical Specifications

- **Architecture Overview**: Data flow and component interaction.
- **Integration Points**: APIs, DBs, and Auth.
- **Security & Privacy**: Data handling and compliance.

### 5. Risks & Roadmap

- **Phased Rollout**: MVP -> v1.1 -> v2.0.
- **Technical Risks**: Latency, cost, or dependency failures.

---

## Implementation Guidelines

### DO (Always)

- **Define Testing**: For AI systems, specify how to test and validate output quality.
- **Iterate**: Present a draft and ask for feedback on specific sections.

### DON'T (Avoid)

- **Skip Discovery**: Never write a PRD without asking at least 2 clarifying questions first.
- **Hallucinate Constraints**: If the user didn't specify a tech stack, ask or label it as `TBD`.

---

## Example: Intelligent Search System

### 1. Executive Summary

**Problem**: Users struggle to find specific documentation snippets in massive repositories.
**Solution**: An intelligent search system that provides direct answers with source citations.
**Success**:

- Reduce search time by 50%.
- Citation accuracy >= 95%.

### 2. User Stories

- **Story**: As a developer, I want to ask natural language questions so I don't have to guess keywords.
- **AC**:
  - Supports multi-turn clarification.
  - Returns code blocks with "Copy" button.

### 3. AI System Architecture

- **Tools Required**: `codesearch`, `grep`, `webfetch`.

### 4. Evaluation

- **Benchmark**: Test with 50 common developer questions.
- **Pass Rate**: 90% must match expected citations.