create-prd

What this skill does

# Create PRD

Generate a comprehensive Product Requirements Document through adaptive conversation. The PRD produced is optimized for AI coding agents to build from — structured with clear sections, testable acceptance criteria, explicit scope boundaries, and implementation-ready technical detail.

## Who This Is For

Solo founders, entrepreneurs, and vibe coders who have a product idea and want to turn it into a document that any AI building tool can execute from. Users range from non-technical ("I've never heard of a database") to technical ("I want Next.js + Convex + Clerk"). Adapt to their level.

## Conversation Flow

When triggered, run through these phases. Ask ONE question at a time. Offer suggested answers where helpful. Move faster with technical users, slower with non-technical ones.

If the user provides extensive notes, a document, or multi-topic answers, skip questions already answered. Consolidate remaining gaps into fewer questions. The goal is a complete PRD, not completing every phase sequentially.

### Phase 1: Vision & Context

Start with an open-ended question to understand what they want to build.

- "What are you building? Describe it like you'd explain it to a friend."
- If the user provides a document, notes, or prior research, read and incorporate it.
- Listen for clues about their technical level. If they mention frameworks, databases, or APIs, they're technical. If they say "an app" or "a website," they may be non-technical.

Follow up with:
- "What problem does this solve? Why does it need to exist?"
- "Who is this for? Describe your ideal user."
- "What makes your approach different or better than what already exists?"

### Phase 2: Technical Assessment

Adapt based on detected technical level.

**Non-technical users** — Ask in plain language:
- "Will this be a website, a phone app, or both?"
- "Do users need to create an account or log in?"
- "Will people pay for this? If so, how — subscription, one-time purchase, free with upgrades?"
- "Does it need to connect to any outside services?" (give examples relevant to their idea: payments, email, maps, AI, etc.)
- If they say "I don't know" to stack questions, make a recommendation based on what they described and explain why in one sentence. Use popular, well-supported stacks that AI agents work with well (Next.js, React, Supabase, Vercel, Clerk, Stripe, etc.).

**Technical users** — Ask directly:
- "What stack are you thinking? Frontend, backend, database, hosting?"
- "Any specific integrations or APIs?"
- "Any constraints I should know about — performance requirements, compliance, budget?"
- Move quickly through what they already know. Don't re-explain their own choices.

### Phase 3: Features & Scope

Extract the core features for MVP. Probe for completeness without overwhelming.

- "What are the 3-5 core things this product must do on day one?"
- For each feature: "How would a user interact with this? What does success look like?"
- "What should this product explicitly NOT do in version 1?" (This is critical — probe for scope boundaries the user hasn't considered. AI agents cannot infer boundaries from omission.)
- "Is there anything you're unsure about — decisions that still need to be made?"

### Phase 4: User Experience

Extract enough detail for an AI agent to build the UI.

- "Walk me through the main flow — what happens from the moment someone opens the app to when they accomplish their goal?"
- "Are there other important flows? (onboarding, payments, sharing, admin, etc.)"
- "Any design preferences — minimal, playful, professional? Any apps you admire the look of?"

### Phase 5: Business Context (Optional)

Offer this section. Include if the user engages, skip if they decline.

- "Have you thought about how this makes money? (subscription, freemium, one-time purchase, marketplace fees, ads, etc.)"
- "Do you have a sense of pricing?"
- "How will people find out about this product?"
- "What metrics would tell you this is working?"

If the user says "I'll figure that out later," respect it. Note it in Open Questions.

### Phase 6: Generate the PRD

Once enough information is gathered, generate the complete PRD document. Follow the structure defined below. For expected output format and depth, see the sample PRD at `${CLAUDE_PLUGIN_ROOT}/examples/sample_prd.md`. Fill in reasonable defaults for any gaps — but clearly mark assumptions with "(Recommended)" or "(Default — verify)" so the user and the builder know what was inferred vs. stated.

**Before delivering the PRD, run a quality check:**

1. Does every MVP feature have at least one user story with testable acceptance criteria?
2. Is Out of Scope explicitly stated with concrete items?
3. Is the tech stack specified (even if recommended by the skill)?
4. Are user flows written out step by step?
5. Are data models or schema defined (even if high-level for non-technical users)?
6. Is there at least one open question flagged?
7. Would an AI coding agent reading only this document know what to build, what NOT to build, what tools to use, and in what order to build it?

If any check fails, go back and fill the gap — either by asking the user or by providing a reasonable default marked as such.

**Save the PRD** to the user's project directory as `PRD.md` (or a name they prefer). Confirm the file path.

### Phase 7: Refine

After presenting the PRD, ask: "Anything you'd like to change, add, or remove?" Iterate until the user is satisfied.

## PRD Output Structure

Use this section ordering. Include all Core sections. Include Optional sections only if the conversation surfaced relevant information.

### Core Sections (Always Include)

**1. Executive Summary**
Product name, one-line pitch, 2-3 sentence description of what it does and for whom.

**2. Problem Statement**
What specific problem exists, how people solve it today, why current solutions fall short.

**3. Solution & Value Proposition**
Core solution description, unique differentiators, value to the customer.

**4. Target Users & Personas**
Primary user description with goals, pain points, and motivations. Include a concrete persona with a name and a "moment" showing how they'd use the product. Keep it behavioral, not demographic essays.

**5. User Stories**
Organized by epic/feature area. Each story follows: "As a [user], I want to [action] so that [benefit]." Each story includes testable acceptance criteria — specific, measurable conditions (not vague prose like "works well"). Use bullet checklists for acceptance criteria.

**6. MVP Feature Scope**
Table or list of must-have features for launch vs. features deferred to later phases. Be explicit about priority (P0 = launch day, P1 = soon after).

**7. User Flows**
Plain-text flow diagrams showing step-by-step user journeys. Use indented arrow notation:
```
Landing Page
  -> "Get Started" CTA
  -> Upload Screen
    -> Upload file
    -> Preview + confirm
  -> Processing (loading state)
  -> Results Screen
    -> Download / Share / Purchase
```
Cover the primary flow and any important secondary flows (onboarding, checkout, sharing, admin).

**8. Tech Stack & Architecture**
Technology choices in a table with rationale. Include: framework, language, styling, auth, database, hosting, key integrations. For technical users, include architecture diagrams in plain text and actual schema code if the conversation went deep enough. For non-technical users, include recommended choices with brief justifications.

**9. Data Models**
Database schema or data structure. For technical users who specified a database, write actual schema code (SQL, Convex, Prisma, etc.). For non-technical users, describe the key data entities and their relationships in plain language or a simple table.

**10. UI/UX Requirements**
Screen-by-screen requirements covering key screens. Include design principles, mobile/responsive requirements, and any specific UI patterns. Not wireframes — written descriptions that an AI agent can implement from.

**11.