prd-builder

Core Philosophy: A PRD defines WHAT a product should do, WHO it is for, and WHY it matters. It is NOT a technical specification — that is left to engineering (and your spec-driven-dev skill). The PRD is a strategic anchor that prevents costly miscommunication and keeps user needs at the center.

Sub-Skills

Component	Purpose
discovery	Phase 1: Codebase scan (existing) + structured interview → raw context
researcher	Phase 2: Web research for market, competitive, and user context
generator	Phase 3: Synthesize all context into the full PRD document
reviewer	Phase 4: Self-review, pressure-test, and refinement loop

Dependency Chain:

• New product: discovery → researcher → generator → reviewer → finalize
• Existing product: discovery (with codebase scan) → researcher → generator → reviewer → finalize

The Solution: A structured, interview-driven PRD process that:

1. Scans existing code to understand what's already built (if applicable)
2. Walks the user through focused discovery questions
3. Researches market context, competitors, and user patterns
4. Generates a comprehensive PRD using the 7-section framework + AI-native sections
5. Self-reviews for gaps, assumptions, and engineering pushback points
6. Hands off cleanly to spec-driven-dev for technical specification

Relationship to Spec-Driven Development:

• PRD = strategic/product side (what, who, why)
• SDD SPEC.md = technical side (how, architecture, implementation)
• The PRD feeds directly into SDD Phase 1 (specifier) as input context
• After finalizing a PRD, offer to kick off spec-driven-dev

When to Use This Skill:

• Starting a new product or product idea
• An existing project that never had a formal PRD
• Pivoting or redefining an existing product
• Adding a major new product area to an existing project
• When the user needs clarity on what to build before building it

When NOT to Use This Skill:

• Adding a feature to an already-defined product → use spec-driven-dev directly
• Bug fixes, refactors, or small changes → just build
• Technical architecture decisions → use spec-driven-dev Phase 2

STEP 1: Detect project state

CHECK for existing project indicators:
  - package.json, requirements.txt, Cargo.toml, go.mod, pyproject.toml
  - .git directory with meaningful history
  - src/ or app/ directory with application code
  - README.md with product description
  - Any existing PRD, SPEC.md, or product documentation
  - CLAUDE.md or project context files

IF existing project with code detected:
  mode = EXISTING_PRODUCT
  INFORM user: "I see an existing codebase. I'll scan it first to understand
  what's already built, then walk you through discovery questions."
ELSE:
  mode = NEW_PRODUCT
  INFORM user: "Starting fresh. I'll walk you through discovery questions
  to define your product, then research the market context."

STEP 2: Check for existing PRD

IF PRD.md or similar document exists:
  READ it
  ASK user: "I found an existing PRD. Would you like to:
    (a) Start fresh and replace it
    (b) Use it as a starting point and refine it
    (c) Create a PRD for a different product area"

STEP 3: Route to Phase 1
  PROCEED to Phase 1 with mode = EXISTING_PRODUCT or NEW_PRODUCT