prd-generator

name	prd-generator
description	Generates a comprehensive Product Requirements Document from a research dossier or raw idea. Takes structured research (from idea-scout) or a direct problem statement and produces a full PRD with vision, user journeys, functional and non-functional requirements, architecture sketch, risk matrix, prioritized roadmap, and validation plan. If no idea-scout research dossier exists, automatically triggers idea-scout first. Integrates with idea-forge for adversarial validation of the solution direction before finalizing. Outputs a structured PRD to /docs/prd/. Use this skill whenever the user wants to create a PRD, product spec, requirements document, or formalize an idea into a buildable plan. Triggers on: 'create a PRD', 'write a PRD', 'generate PRD', 'product requirements', 'prd-generator', 'turn this into a spec', 'write the requirements', 'make this into a plan', 'formalize this idea', 'I want to build this — what do I need?', 'create a product spec', 'write requirements for', 'spec this out', 'product specification for'.
argument-hint	<idea, problem statement, or path to idea-scout dossier>

PRD Generator — From Research to Product Requirements

Why This Skill Exists

The gap between "I understand the landscape" and "I know what to build" is where most projects lose their way. Teams either skip requirements entirely and start coding (then discover missing pieces mid-build), or write vague, aspirational documents that don't constrain anything.

This skill bridges that gap. It takes structured research (ideally from idea-scout) and produces a PRD that is specific enough to build from, honest about risks, and grounded in real research rather than assumptions.

Core Principle: Start From The Narrowest Wedge

The MVP is NOT a stripped-down version of the full vision. It IS the narrowest wedge — the smallest thing someone would pay for this week. If idea-scout identified a narrowest wedge, the entire PRD should be structured around it: Phase 1 delivers the wedge, Phase 2 expands from strength, Phase 3 builds the platform.

This inverts the typical PRD anti-pattern of designing the platform first and then "cutting scope" for MVP. Instead: nail the wedge, prove value, expand.

Prerequisites: Research First

Before generating a PRD, the problem landscape needs to be understood. This skill checks for an existing idea-scout dossier at docs/idea-scout/. If it exists, the PRD is built on that foundation. If it doesn't, the skill automatically invokes idea-scout first — because writing requirements without understanding the landscape leads to requirements that solve the wrong problem.

If idea-scout's verdict was DON'T BUILD: Surface this prominently. Ask yourself — and be honest in the PRD — whether proceeding makes sense. The PRD should acknowledge the research verdict and explain why the user is proceeding despite it (or recommend they don't).

How It Works: Six Phases, Fully Autonomous

Research Dossier (from idea-scout)
    |
    v
+--- PHASE 1: VISION & SCOPE ----------------+
|  Product vision, anti-goals, primary user,   |
|  success criteria                            |
+----------------------------------------------+
    |
    v
+--- PHASE 2: USER JOURNEYS ------------------+
|  3-5 core scenarios, magic moment,           |
|  competitive advantage flows                 |
+----------------------------------------------+
    |
    v
+--- PHASE 3: REQUIREMENTS -------------------+
|  Functional, non-functional, data,           |
|  integration, constraints                    |
+----------------------------------------------+
    |
    v
+--- PHASE 4: ARCHITECTURE SKETCH -----------+
|  System components, key decisions,           |
|  build/buy/integrate, data flow              |
+----------------------------------------------+
    |
    v
+--- PHASE 5: RISK & PRIORITIZATION ---------+
|  Risk matrix, MoSCoW, MVP definition,        |
|  phased roadmap                              |
|  + idea-forge adversarial validation         |
+----------------------------------------------+
    |
    v
+--- PHASE 6: VALIDATION PLAN ---------------+
|  Assumptions, test methods, kill criteria     |
+----------------------------------------------+
    |
    v
  Full PRD in /docs/prd/

Execution Instructions

Step 0: Check for Research & Setup

First, check whether an idea-scout dossier exists:

ls docs/idea-scout/summary.md 2>/dev/null

If it exists: Read the dossier to understand the research foundation:

• docs/idea-scout/summary.md — Extract: VERDICT, eureka moments, demand reality, premise scorecard, narrowest wedge
• docs/idea-scout/decomposition.md — Extract: premises (which were CONFIRMED/CHALLENGED/INCONCLUSIVE)
• docs/idea-scout/solution-directions.md — Extract: recommended direction, narrowest wedge
• docs/idea-scout/gap-analysis.md — Extract: demand reality, status quo, blind spots, opportunities
• docs/idea-scout/open-questions.md — Extract: unvalidated assumptions, bear case arguments
• docs/idea-scout/landscape.md — Extract: competitive landscape, status quo workflow

Critical handoff data from idea-scout v2:

• Narrowest wedge → becomes the foundation of MVP/Phase 1
• Premise scorecard → CHALLENGED premises become risks; INCONCLUSIVE premises become validation items
• Demand reality → shapes success criteria and kill criteria
• Eureka moments → inform the product's key differentiator
• Status quo → becomes the "before" in user journeys

If it doesn't exist: Tell the user and invoke idea-scout:

No research dossier found. Running idea-scout first to understand the landscape.
This adds a few minutes but produces a much stronger PRD.

Then invoke /idea-scout {user's idea} and wait for it to complete before proceeding.

Set up the working and output directories:

mkdir -p /tmp/prd-generator/{idea-slug}
mkdir -p docs/prd

Acknowledge to the user:

Generating PRD for: "{idea}"

Building on idea-scout research dossier.
Running 6-phase PRD generation. This will take several minutes.

Phase 1: VISION & SCOPE FRAMING

Spawn an agent that reads the research and frames the product vision.

You are a product strategist defining the vision and scope for a new product.

Read the research dossier:
- {cwd}/docs/idea-scout/summary.md
- {cwd}/docs/idea-scout/decomposition.md
- {cwd}/docs/idea-scout/solution-directions.md
- {cwd}/docs/idea-scout/gap-analysis.md

Produce a clear vision and scope document:

## Research Foundation
Summarize what idea-scout found:
- **Verdict:** {BUILD/PIVOT/VALIDATE FIRST/DON'T BUILD}
- **Demand reality:** {STRONG/MODERATE/WEAK/UNPROVEN}
- **Eureka moments:** {key insights, if any}
- **Narrowest wedge:** {from solution-directions.md}
- **Premise status:** {X of Y confirmed, Z challenged}

If the verdict was PIVOT or VALIDATE FIRST, explain how this PRD addresses those concerns. If DON'T BUILD, flag this prominently and explain the rationale for proceeding.

## Product Vision
One sentence that captures what this product will be and why it matters.
Format: "For {target user} who {pain point}, {product name} is a {category} that {key benefit}. Unlike {alternatives}, it {key differentiator}."

If eureka moments were found, the key differentiator should build on them — they represent the insight nobody else has.

## Problem Statement
2-3 paragraphs grounding the problem in research. What specifically is broken or missing today? Who suffers and how? Use data points from the research dossier. Reference the status quo workflow from gap-analysis.md — this is what users actually do today, and it's the real competitor.

## Anti-Goals (What This Is NOT)
5-7 specific things this product will NOT do. These are critical for preventing scope creep. Base them on the research — if there's a crowded space for feature X, and the opportunity is in feature Y, anti-goals should exclude X.

Format each as:
- **{Anti-goal}** — Why: {reason, referencing research}

## Primary User
- Who is the single most important user?
- What is their #1 job-to-be-done?
- What's their current workflow? (from user sentiment research)
- What's their willingness to pay / switch? (from research)

## Secondary Users
- Other user segments that benefit
- How their needs differ from the primary user
- Which ones to address in V1 vs later

## Success Criteria
Define 5-7 measurable outcomes that would tell you this product is working:
- **North star metric:** The single most important measure of value delivery
- **Supporting metrics:** 4-6 metrics that indicate health across different dimensions
- **Timeframe:** When should each metric show movement?

For each metric, explain WHY it matters (not just what to measure).

## Stakeholder Impact Map
Who benefits from this product? Who might resist? Who needs to approve?
- Beneficiaries: {who gains value}
- Threatened parties: {who loses if this succeeds}
- Gatekeepers: {who must approve or cooperate}

Write to: /tmp/prd-generator/{idea-slug}/vision-scope.md
Confirm: "Vision and scope framed: {N} anti-goals, {M} success criteria defined."

Phase 2: USER JOURNEY MAPPING

Spawn an agent that maps the core user scenarios.

You are a UX strategist mapping user journeys for a new product.

Read:
- /tmp/prd-generator/{idea-slug}/vision-scope.md
- {cwd}/docs/idea-scout/decomposition.md (for user understanding)
- {cwd}/docs/idea-scout/gap-analysis.md (for friction points)

Map 3-5 core user scenarios end-to-end. These are the make-or-break flows — if these don't work well, nothing else matters.

For each scenario:

## Scenario [N]: {Descriptive Name}

### Trigger
What causes the user to start this flow? What state are they in?

### Current State (Before Our Product)
How does the user handle this today? Step by step, with pain points marked.

### Desired State (With Our Product)
Step-by-step flow through our product:
1. {Step} — User does: {action} / System does: {response}
2. {Step} — ...
...

For each step, note:
- What data is needed
- What decisions the user makes
- What could go wrong
- What the user sees/feels

### The Magic Moment
The specific point in this flow where the user gets clear value. This is the moment that should be as fast and frictionless as possible.

### Competitive Advantage
What makes this flow better than the current alternative? Reference specific friction points from the research.

### Edge Cases
- What if the user does something unexpected?
- What if the data is incomplete or wrong?
- What if the system is slow or unavailable?

## "Day in the Life" Narrative
Write a short (1 paragraph) before/after story for the primary user:
- **Before:** A specific day where the user struggles with the current workflow
- **After:** The same day with the product in place

## Critical Path
Which of these scenarios is the one that MUST work perfectly on day one? Why? What's the minimum viable version of this scenario?

Write to: /tmp/prd-generator/{idea-slug}/user-journeys.md
Confirm: "User journeys mapped: {N} scenarios, {M} edge cases identified."

Phase 3: REQUIREMENTS STRUCTURING

Spawn an agent that translates the vision and journeys into concrete requirements.

You are a technical product manager translating product vision and user journeys into structured requirements.

Read:
- /tmp/prd-generator/{idea-slug}/vision-scope.md
- /tmp/prd-generator/{idea-slug}/user-journeys.md
- {cwd}/docs/idea-scout/technical-foundations.md (if available, from the research files at /tmp/idea-scout/{idea-slug}/)
- {cwd}/docs/idea-scout/gap-analysis.md

Produce structured requirements:

## Functional Requirements

Group by feature area. For each requirement:

### {Feature Area}

| ID | Requirement | Priority | Scenario | Notes |
|----|------------|----------|----------|-------|
| FR-{area}-{N} | {What the system must do — specific and testable} | Must/Should/Could | {Which user scenario needs this} | {Implementation notes or constraints} |

Cover every step of every user scenario. If a scenario step needs something from the system, it should be a functional requirement.

## Non-Functional Requirements

| ID | Category | Requirement | Target | Rationale |
|----|----------|------------|--------|-----------|
| NFR-{N} | Performance | {specific requirement} | {measurable target} | {why this target matters} |
| NFR-{N} | Security | ... | ... | ... |
| NFR-{N} | Scalability | ... | ... | ... |
| NFR-{N} | Accessibility | ... | ... | ... |
| NFR-{N} | Reliability | ... | ... | ... |

Only include NFRs that actually matter for this product. Don't add generic "must be secure" requirements — be specific about what security means here.

## Data Requirements

| Data Entity | Source | Format | Volume | Privacy | Storage |
|------------|--------|--------|--------|---------|---------|
| {what data} | {where from} | {structure} | {expected scale} | {PII? regulated?} | {how long to keep} |

## Integration Requirements

| System | Direction | Protocol | Auth | Data Exchanged | Frequency |
|--------|-----------|----------|------|---------------|-----------|
| {external system} | inbound/outbound/bidirectional | REST/GraphQL/webhook/etc | {auth mechanism} | {what data flows} | {real-time/batch/periodic} |

Reference the api-database-scout findings if available.

## Constraints

| Constraint | Type | Impact | Source |
|-----------|------|--------|--------|
| {what limits us} | Technical/Business/Regulatory/Resource | {how it shapes the solution} | {where this constraint comes from} |

Write to: /tmp/prd-generator/{idea-slug}/requirements.md
Confirm: "Requirements structured: {N} functional, {M} non-functional, {K} data, {J} integration requirements."

Phase 4: ARCHITECTURE SKETCH

Spawn an agent that outlines the high-level technical shape.

You are a systems architect sketching the high-level architecture for a new product.

Read:
- /tmp/prd-generator/{idea-slug}/vision-scope.md
- /tmp/prd-generator/{idea-slug}/requirements.md
- {cwd}/docs/idea-scout/solution-directions.md
- {cwd}/docs/idea-scout/landscape.md (if available)

Produce an architecture sketch. This is NOT a detailed design — it's the conceptual shape that guides implementation decisions.

## System Overview
ASCII diagram showing the major components and how they connect. Keep it readable.

## Component Inventory

For each major component:

### {Component Name}
- **Purpose:** What it does in one sentence
- **Responsibilities:** Specific things it handles
- **Inputs/Outputs:** What goes in, what comes out
- **Technology candidates:** 2-3 options with brief tradeoff notes
- **Build/Buy/Integrate:** Recommendation with rationale

## Data Flow
How does information move through the system? Trace the path from user input to stored data to output. Use a simple diagram or numbered steps.

## Key Technical Decisions

Identify 3-5 decisions that need to be made early because they're hard to change later:

| Decision | Options | Recommendation | Why It Matters |
|----------|---------|---------------|----------------|
| {what to decide} | {2-3 options} | {recommendation} | {consequences of getting it wrong} |

## Build vs Buy vs Integrate Analysis

For each major capability the system needs:

| Capability | Build | Buy | Integrate | Recommendation |
|-----------|-------|-----|-----------|---------------|
| {what's needed} | {effort + tradeoff} | {options + cost} | {existing service + tradeoff} | {recommendation + why} |

## Cost Estimation Signals
Not exact numbers, but complexity indicators:
- Infrastructure shape (serverless / single server / distributed)
- Expected API costs (if using third-party AI, data services, etc.)
- Team skills needed (frontend, backend, ML, DevOps, etc.)
- Operational burden (monitoring, on-call, data management)

Write to: /tmp/prd-generator/{idea-slug}/architecture-sketch.md
Confirm: "Architecture sketched: {N} components, {M} key decisions, build/buy analysis complete."

Phase 5: RISK & PRIORITIZATION

This phase has two parts that run in parallel:

1. A risk and prioritization agent
2. An adversarial validation via the idea-forge skill

Agent: RISK & PRIORITIZATION

You are a product strategist creating the risk matrix and prioritized roadmap.

Read:
- /tmp/prd-generator/{idea-slug}/vision-scope.md
- /tmp/prd-generator/{idea-slug}/requirements.md
- /tmp/prd-generator/{idea-slug}/architecture-sketch.md
- {cwd}/docs/idea-scout/open-questions.md

## Risk Matrix

| Risk | Category | Likelihood (1-5) | Impact (1-5) | Score | Mitigation | Owner |
|------|----------|-----------------|-------------|-------|------------|-------|
| {specific risk} | Technical/Market/Regulatory/Team/Dependency | {1-5} | {1-5} | {L*I} | {specific mitigation action} | {who handles this} |

Sort by score descending. Include at least 10 risks covering all categories.

## MoSCoW Prioritization

Take ALL functional requirements from requirements.md and categorize:

### Must Have (MVP — without these, the product doesn't work)
- FR-{ID}: {requirement} — Why Must: {reason}

### Should Have (V1 — significantly improves the product)
- FR-{ID}: {requirement} — Why Should: {reason}

### Could Have (V2 — nice to have, adds polish)
- FR-{ID}: {requirement} — Why Could: {reason}

### Won't Have (Not this product — explicitly out of scope)
- FR-{ID}: {requirement} — Why Won't: {reason, referencing anti-goals}

## MVP Definition — Start From The Narrowest Wedge

If idea-scout identified a narrowest wedge, the MVP IS that wedge. Don't redesign it — build it. The wedge was chosen because it's the fastest path to proving value with real users.

- **The wedge:** {from idea-scout's solution-directions.md}
- Which user scenario does the wedge serve? (map to scenarios above)
- Which Must Have requirements does it need? (and ONLY those)
- What's the simplest architecture? (might be a script, a daily email, a single page — not a platform)
- Expected time to build: {days, not months — if it's months, the wedge isn't narrow enough}
- **What the wedge validates:** {which CHALLENGED/INCONCLUSIVE premises does it test?}
- **What the wedge does NOT validate:** {be explicit about what you still won't know}

## Phased Roadmap

### Phase 1: MVP
- Goal: {what value is delivered}
- Requirements: {list of Must Have FR IDs}
- Validation: {how to know this phase works}
- Estimated complexity: {S/M/L}

### Phase 2: V1
- Goal: {what value is added}
- Requirements: {list of Should Have FR IDs}
- Depends on: {what must be learned from MVP}
- Estimated complexity: {S/M/L}

### Phase 3: V2
- Goal: {what value is added}
- Requirements: {list of Could Have FR IDs}
- Depends on: {what must be learned from V1}
- Estimated complexity: {S/M/L}

For each phase, describe the specific VALUE unlocked — not just the features shipped.

## Metrics Framework
For each roadmap phase, what metrics should move?
- **Phase 1 signals:** {what tells you MVP is working}
- **Phase 2 signals:** {what tells you V1 is adding value}
- **Phase 3 signals:** {what tells you V2 is worth the investment}

Write to: /tmp/prd-generator/{idea-slug}/risks-priorities.md
Confirm: "Risks and priorities complete: {N} risks, MoSCoW categorization done, {M}-phase roadmap defined."

Adversarial Validation via idea-forge:

In parallel with the risk agent, invoke the idea-forge skill to adversarially validate the solution direction. Use the recommended direction from the research and the architecture sketch as input.

The idea-forge output provides an independent stress test. After both complete, the compiler will incorporate any concerns idea-forge raised that the risk matrix didn't catch.

Phase 6: VALIDATION PLAN

Spawn an agent that creates the validation plan.

You are a product validation strategist. Your job is to define what needs to be true for this product to succeed — and how to test each assumption before committing to a full build.

Read:
- /tmp/prd-generator/{idea-slug}/vision-scope.md
- /tmp/prd-generator/{idea-slug}/risks-priorities.md
- {cwd}/docs/idea-scout/open-questions.md
- {cwd}/docs/idea-scout/decomposition.md (for premise scorecard)
- {cwd}/docs/idea-scout/gap-analysis.md (for demand reality)
- /tmp/prd-generator/{idea-slug}/user-journeys.md

## Inherited From Research

Start by pulling forward what idea-scout already found:
- **CHALLENGED premises** → these are your highest-priority validation targets
- **INCONCLUSIVE premises** → these need investigation before building
- **Demand reality assessment** → if WEAK or UNPROVEN, validation must prove demand before anything else
- **Bear case arguments** → each valid bear case is a risk that needs a kill criterion

## Critical Assumptions

Every product bets on certain things being true. List each assumption explicitly. Include BOTH the premises from idea-scout AND any NEW assumptions introduced by the PRD (architecture choices, user journey assumptions, pricing assumptions):

| # | Assumption | Confidence | Evidence | What Breaks If Wrong |
|---|-----------|-----------|---------|---------------------|
| 1 | {what we're assuming} | High/Medium/Low | {what supports this from research} | {consequences if wrong} |

## Validation Methods

For each Medium or Low confidence assumption, define a validation approach:

### Assumption {N}: {name}

- **Method:** {user interviews / prototype test / landing page / data analysis / expert consultation / competitive analysis / technical spike}
- **What to do:** {specific steps}
- **Sample size / scope:** {how much is enough}
- **Success signal:** {what would confirm the assumption}
- **Failure signal:** {what would disprove it}
- **Time to validate:** {hours / days / weeks}
- **Cost to validate:** {free / minimal / significant}

Prioritize validation by: (risk if wrong) x (uncertainty). High-risk, high-uncertainty assumptions get validated first.

## Kill Criteria

What signals should make you stop building and reconsider?

| Signal | Threshold | Action |
|--------|----------|--------|
| {what to watch} | {specific number or condition} | {stop / pivot / investigate} |

Be honest — what would tell you this idea isn't worth pursuing? The courage to define kill criteria upfront prevents sunk cost fallacy later.

## Pre-Build Validation Sequence

Ordered list of what to validate before writing code:
1. {assumption to validate} — Method: {X} — Time: {Y}
2. {assumption to validate} — Method: {X} — Time: {Y}
...

## Post-MVP Validation
What should you measure and learn after the MVP is live?
- User behavior to track
- Feedback channels to establish
- Metrics to monitor
- Decision points (what data triggers Phase 2)

Write to: /tmp/prd-generator/{idea-slug}/validation-plan.md
Confirm: "Validation plan complete: {N} assumptions, {M} validation methods, {K} kill criteria defined."

Step 7: COMPILE THE PRD

After all phases complete, spawn a compiler agent to produce the final documents.

You are compiling a Product Requirements Document from multiple working files. Your job is to produce a polished, opinionated, buildable set of documents.

CRITICAL: The PRD should feel like it was written by someone who deeply understands the problem and has a strong opinion about what to build. Not a generic template filled in — a document with conviction.

Read ALL files in /tmp/prd-generator/{idea-slug}/.
Also read {cwd}/docs/idea-scout/summary.md for research context.
If idea-forge produced a blueprint, read it as well for adversarial findings.

Produce the following files in {cwd}/docs/prd/:

### 1. PRD.md — The Master Document
This is the main PRD. It should be comprehensive but scannable:

# Product Requirements Document: {Product Name}
*Generated: {date}*
*Based on: idea-scout research dossier*

## 0. Research Verdict & Premises
Before anything else, ground the PRD in what the research found:
- **idea-scout verdict:** {BUILD/PIVOT/VALIDATE FIRST} — {one sentence why}
- **Demand reality:** {STRONG/MODERATE/WEAK/UNPROVEN}
- **Key eureka insight:** {the most important non-obvious finding, if any}
- **Premise scorecard:** {X confirmed, Y challenged, Z inconclusive}
- **Biggest risk from research:** {the bear case argument that's hardest to dismiss}

This section exists so anyone reading the PRD knows what evidence it's built on — and where the evidence is thin.

## 1. Executive Summary
- Problem (2-3 sentences, grounded in research — reference the status quo)
- Solution (2-3 sentences — if built on a eureka moment, say so)
- Target user (1 sentence — a specific person, not a category)
- Key differentiator (1 sentence)
- The narrowest wedge (what to build FIRST, in days not months)

## 2. Vision & Scope
{From vision-scope.md — clean and formatted}

## 3. User Journeys
{Summary of journeys with links to detailed doc}

## 4. Requirements Overview
- {N} functional requirements across {M} feature areas
- {K} non-functional requirements
- {J} integration points
{Summary tables — full details in requirements.md}

## 5. Architecture Overview
{High-level diagram and component list from architecture sketch}

## 6. Roadmap
{Phased roadmap from risks-priorities.md}

## 7. Risks
{Top 10 risks from risk matrix}

## 8. Validation Plan
{Summary of what to validate before building}

## 9. Open Questions
{Consolidated from all phases}

## Appendix
- Full research dossier: docs/idea-scout/
- Detailed requirements: docs/prd/requirements.md
- Detailed user journeys: docs/prd/user-journeys.md
- Architecture details: docs/prd/architecture-sketch.md
- Risk matrix & priorities: docs/prd/risks-and-priorities.md
- Validation plan: docs/prd/validation-plan.md

### 2. user-journeys.md
{Clean, formatted version of user journeys}

### 3. requirements.md
{Clean, formatted version of requirements}

### 4. architecture-sketch.md
{Clean, formatted version of architecture sketch}

### 5. risks-and-priorities.md
{Clean, formatted version of risk matrix, MoSCoW, and roadmap}

### 6. validation-plan.md
{Clean, formatted version of validation plan}

## Quality Standards
- Every requirement must be testable (someone should be able to read it and write a test)
- Every risk must have a mitigation (even if the mitigation is "accept and monitor")
- Every user journey must trace back to requirements
- Cross-references between documents should use relative links
- No orphaned requirements (every requirement maps to a user journey)
- No vague language ("fast", "user-friendly", "scalable" — always specify what these mean with numbers)

Write all 6 files to {cwd}/docs/prd/.
Confirm: "PRD compiled: 6 documents written to docs/prd/."

After the compiler finishes, report to the user:

PRD generated for "{product name}".

## Summary
{2-3 sentence executive summary}

## Scope
- {N} functional requirements
- {M} user journeys
- {K} risks identified
- MVP estimated complexity: {S/M/L}

## Recommended Next Steps
1. Review the validation plan (docs/prd/validation-plan.md) — {N} assumptions to validate before building
2. Review the risk matrix (docs/prd/risks-and-priorities.md) — {M} risks above threshold
3. Start with MVP Phase 1: {one-line description}

## Files
- docs/prd/PRD.md — Master PRD document
- docs/prd/user-journeys.md — Detailed user scenarios
- docs/prd/requirements.md — Full requirements specification
- docs/prd/architecture-sketch.md — High-level technical shape
- docs/prd/risks-and-priorities.md — Risk matrix + roadmap
- docs/prd/validation-plan.md — What to validate before building

Research foundation: docs/idea-scout/

Principles

• Narrowest wedge first. The MVP IS the narrowest wedge from idea-scout. Don't design a platform and then "cut scope." Design the wedge, prove it works, expand from strength.
• Research-grounded. Every requirement, risk, and decision traces back to research findings. No "I think" — only "the research shows." Challenged premises become risks. Eureka moments become differentiators.
• Premise continuity. The premise scorecard flows from idea-scout through the entire PRD. CONFIRMED premises are load-bearing. CHALLENGED premises are risks with mitigations. INCONCLUSIVE premises are validation items with kill criteria.
• Specific over vague. "The system must respond in under 200ms for 95th percentile queries" not "the system must be fast." If you can't make it specific, flag it as an open question.
• Kill criteria are features. Every PRD should define what would make you STOP building. This takes courage but prevents sunk cost fallacy. Elevate kill criteria — they're as important as requirements.
• Status quo is the UX baseline. User journeys must show the "before" (current workaround workflow) alongside the "after." If the "after" isn't dramatically better at the pain point, the user won't switch.
• Anti-goals are features. Saying what the product won't do is as important as what it will do.
• Honest about unknowns. If demand reality is WEAK or UNPROVEN, the PRD should say so and structure Phase 1 as a validation exercise, not a product launch.
• Adversarial validation. idea-forge stress-tests the solution direction. The PRD is stronger for having survived scrutiny.
• Build on idea-scout. The PRD doesn't repeat research — it builds on it. The dossier is the foundation, the PRD is the blueprint.
• Re-runnable. If the research changes, the PRD can be regenerated.