agile-product-brainstorm

name	agile:product:brainstorm
description	Interactive brainstorming session to create, refine, review, and specify a Product Requirements Document (PRD). Guides users through progressive disclosure to capture product vision, target users, features, requirements, and success metrics. Produces a comprehensive PRD saved to agile/product/ that can spawn multiple epics. Use when starting a new product initiative, defining product scope, or creating product specifications before epic planning.
user-invocable	true
disable-model-invocation	false
allowed-tools	["Read","Edit","Write","Glob","Grep","Bash","Skill","AskUserQuestion","TaskCreate","TaskList","TaskGet","TaskUpdate"]

Product Brainstorm

Transform product ideas into comprehensive, implementation-ready Product Requirements Documents (PRDs) through natural collaborative dialogue. This skill guides users through a structured yet flexible brainstorming process that captures the full product context — from vision to detailed requirements.

What This Skill Creates

A Product Requirements Document (PRD) that serves as the authoritative source for:

• Product vision and strategic direction
• Target user segments and personas
• Feature inventory with prioritization
• Functional and non-functional requirements
• Success metrics and KPIs
• Release roadmap and phasing
• Domain model (bounded contexts, entity catalog, domain events)
• System interaction map (service communication patterns, external integrations)
• Ubiquitous language (shared terminology glossary)

The PRD lives in agile/product/ and can spawn multiple epics in agile/epics/.

---

Clean-Room Context (MANDATORY when invoked from agile-clean-room)

When this skill is invoked as part of a clean-room reverse engineering process:

Functional Naming Protocol

• MANDATORY: Use ONLY functional naming throughout the PRD
• ❌ NEVER use product names, code names, or proper nouns in folder names or file paths
• ✅ ALWAYS use descriptive terms that describe WHAT the system does

The Red Line

These are ABSOLUTE PROHIBITIONS that would compromise legal defensibility:

Prohibited	Required Alternative
Product names in folder/file paths	Functional names: ai-assistant-cli, query-engine
Code names like "Superwhisper"	Functional descriptions of capabilities
Original company name	"the vendor" or "the provider" or omit
References to "porting", "migrating", "converting"	"building", "creating", "developing"
Mentions of original codebase or file paths	Generic, platform-agnostic descriptions
"Matching feature parity with [original]"	"Feature requirements for [functional description]"
"Similar to [original product]"	"A product that" or omit comparison

PRD Cleanliness Requirements

All content MUST be:

• Written as if creating a new product from scratch
• Using independent, original naming for all concepts
• Describing WHAT the product does, not HOW it was derived
• Free of any references to the original implementation
• Using functional naming: NNN-[capability-name] for epics

The Implementation Team will receive this PRD with ZERO knowledge of the original product.

IP Cleanliness Check (before PRD commit)

Before writing the PRD to disk:

• Only functional naming used — no product names in paths
• No company names or trademarks referenced
• Language frames this as building a new product
• All feature names are independently chosen
• No references to "reverse engineering" or "porting"
• Target users and use cases described generically

---

Invocation

• /agile:product:brainstorm — Interactive mode, discovers what product to build
• /agile:product:brainstorm a project management tool for remote teams — Interactive with seed description
• /agile:product:brainstorm @agile/ideas/product-vision.md — File reference mode

Entry Mode Detection

Parse $ARGUMENTS to determine entry mode:

Pattern	Mode	Behavior
Starts with @ or contains file path	File reference	Read file as brainstorm seed
Text description	Interactive with seed	Use as starting context
No argument	Interactive	Ask user what product to build

Hard Gate

Do NOT proceed to PRD generation until the user has explicitly approved the product direction through all interactive checkpoints. This applies to EVERY product regardless of perceived simplicity. Even "simple" products require full specification to prevent unexamined assumptions.

Phase Overview

Phase 0: Entry & Context Discovery
    ↓
Phase 1: Product Vision (Why)
    ↓
Phase 2: Target Users (Who)
    ↓
Phase 3: Problem & Solution (What)
    ↓
Phase 4: Competitive Landscape
    ↓
Phase 5: Feature Exploration
    ↓
Phase 6: Requirements & Constraints
    ↓
Phase 7: Risk Assessment & Mitigation
    ↓
Phase 8: Success Metrics
    ↓
Phase 9: Key Assumptions Validation
    ↓
Phase 10: Roadmap & Phasing
    ↓
Phase 11: Domain Discovery
    ↓
Phase 12: System Interactions
    ↓
Phase 13: PRD Generation & Commit

---

Phase 0: Entry & Context Discovery

Step 0: Resume Detection (Pre-Entry Gate)

Before starting a new session, check for existing state:

if [ -f "agile/product/state/latest-session.json" ]; then
    # Read state file and offer resume
fi

State file location: agile/product/state/latest-session.json

Resume Logic:

1. Check if state file exists
2. If exists and status is "in_progress":
   • Read currentPhase and capturedData
   • Display resume prompt with timestamp of last activity
3. If user chooses resume:
   • Jump to saved phase
   • Offer "Review previous answers" option before continuing
4. If user chooses start fresh:
   • Archive old state to agile/product/state/archive/
   • Continue with new session

Use AskUserQuestion:

Question: "Found in-progress session from [timestamp]. Resume or start fresh?" Options:

• "Resume from [current phase]"
• "Review previous answers first"
• "Start fresh (archive old session)"

Step 0b: State Persistence Convention

After EVERY AskUserQuestion: Save state to file

State file schema (agile/product/state/latest-session.json):

{
  "version": "1.0",
  "sessionId": "uuid",
  "startedAt": "ISO timestamp",
  "lastActivity": "ISO timestamp",
  "status": "in_progress | completed | abandoned",
  "currentPhase": "phase4_step2",
  "capturedData": {
    "PRODUCT_CATEGORY": "...",
    "PROBLEM_STATEMENT": "...",
    "VISION_STATEMENT": "...",
    "PRIMARY_USER": "...",
    "USER_SCENARIOS": [...],
    "CAPABILITIES": [...],
    "FEATURE_CANDIDATES": [...],
    "ACCEPTANCE_CRITERIA": [...],
    "OUT_OF_SCOPE": [...],
    "KNOWN_COMPETITORS": [...],
    "RISKS": [...],
    "KEY_ASSUMPTIONS": [...],
    "MVP_FEATURES": [...],
    "PRODUCT_NAME": "...",
    "DOMAIN_ENTITIES": [...],
    "BOUNDED_CONTEXTS": [...],
    "DOMAIN_EVENTS": [...],
    "SERVICE_INTERACTIONS": [...],
    "EXTERNAL_SYSTEMS": [...]
  },
  "history": [
    {"phase": "phase1", "timestamp": "...", "action": "completed"}
  ]
}

Phase Identifiers:

• phase0_resume - Resume detection
• phase0_entry - Entry mode detection
• phase1_vision - Product vision
• phase1_validation - Vision validation
• phase2_users - Target users
• phase2_scenarios - User scenarios
• phase2_secondary - Secondary users
• phase3_solution - Problem & solution
• phase3_capabilities - Key capabilities
• phase4_competitive - Competitive landscape
• phase5_features - Feature exploration
• phase5_acceptance - Acceptance criteria
• phase5_moscow - MoSCoW prioritization
• phase6_requirements - Requirements & constraints
• phase7_risks - Risk assessment
• phase8_metrics - Success metrics
• phase9_assumptions - Key assumptions validation
• phase10_roadmap - Roadmap & phasing
• phase11_domain - Domain discovery
• phase11_entities - Entity catalog
• phase11_contexts - Bounded contexts
• phase12_interactions - System interactions
• phase12_external - External system integrations
• phase13_naming - Product naming
• phase13_preview - PRD preview
• phase13_commit - Commit PRD

Step 1: Detect Entry Mode

Parse $ARGUMENTS:

• If starts with @ or contains / or .md: File reference mode
• If contains text: Interactive with seed
• If empty: Interactive mode

Step 1: Load Context

File reference mode:

1. Extract file path from arguments
2. Verify file exists with Bash test -f
3. If not found: report error, switch to interactive mode
4. If found: read content as BRAINSTORM_CONTEXT

Interactive with seed:

1. Use provided text as BRAINSTORM_CONTEXT

Interactive mode:

1. Use AskUserQuestion with open-ended question:
   • "What product would you like to build? Describe the idea or problem you want to solve."
   • No predefined options — capture free-form input
2. Store response as BRAINSTORM_CONTEXT

Step 2: Initial Clarification

Use AskUserQuestion to establish product category:

Question: "What type of product is this?" Options:

• "B2B SaaS application"
• "Consumer mobile app"
• "Developer tool / API"
• "Internal productivity tool"
• "Platform / Infrastructure"
• "Other — let me describe"

Store as PRODUCT_CATEGORY.

---

Phase 1: Product Vision (Why)

Establish the fundamental purpose and strategic direction.

Step 1: Problem Discovery

Use AskUserQuestion:

Question: "What problem does this product solve? Who currently feels this pain?" Guidance: Think about the core frustration or unmet need.

Capture as PROBLEM_STATEMENT.

Step 2: Vision Statement

Use AskUserQuestion:

Question: "In one sentence, what does success look like? What will be different in the world when this product exists?" Example: "Every remote team can collaborate as effectively as if they were in the same room."

Capture as VISION_STATEMENT.

Step 3: Validate Vision Alignment

Use AskUserQuestion:

Question: "Does this capture your intent?" Display:

Product Vision Summary:
- Problem: [PROBLEM_STATEMENT]
- Vision: [VISION_STATEMENT]
- Category: [PRODUCT_CATEGORY]

Options:

• "Yes — continue to users"
• "Refine problem statement"
• "Refine vision statement"
• "Start over"

If refinement selected: return to appropriate step.

---

Phase 2: Target Users (Who)

Define who will use this product and what they need.

Step 1: Primary User Segment

Use AskUserQuestion:

Question: "Who is the primary user? Describe them in detail." Guidance: Job title, industry, company size, technical sophistication.

Capture as PRIMARY_USER.

Step 2: User Scenarios

Use AskUserQuestion:

Question: "Describe 2-3 scenarios where this user would use your product." Example format: "As a [user], when I [situation], I want to [action], so I can [outcome]."

Capture each as USER_SCENARIO_1, USER_SCENARIO_2, USER_SCENARIO_3.

Step 3: Secondary Users (Optional)

Use AskUserQuestion:

Question: "Are there other types of users?" Options:

• "Yes — admin/managers"
• "Yes — end consumers"
• "Yes — integration partners"
• "No — single user type"

If yes, capture secondary user types and their needs.

Step 4: Validate User Understanding

Use AskUserQuestion:

Question: "Primary user: [summary]. Key scenarios: [N] identified. Continue?" Options:

• "Yes — continue to solution"
• "Add more scenarios"
• "Refine primary user"
• "Add secondary users"

---

Phase 3: Problem & Solution (What)

Define what the product actually does.

Step 1: Current Workaround

Use AskUserQuestion:

Question: "How do users solve this problem today without your product?" Guidance: Understanding the current solution reveals the switching cost.

Capture as CURRENT_SOLUTION.

Step 2: Core Value Proposition

Use AskUserQuestion:

Question: "What makes your approach 10x better than the current solution?" Guidance: Focus on the key differentiator.

Capture as VALUE_PROPOSITION.

Step 3: Key Capabilities

Brainstorm 5-7 key capabilities the product needs.

Use AskUserQuestion for each:

Question: "Capability [N]: What must the product enable users to do?" Example: "Create project tasks with deadlines and assignments"

Continue until user says "no more" or reaches 7 capabilities.

Store as CAPABILITIES[].

Step 4: Validate Solution Direction

Use AskUserQuestion:

Question: "Solution summary: [N] capabilities identified. Top 3: [list]. Continue?" Options:

• "Yes — continue to features"
• "Add more capabilities"
• "Remove/refine capabilities"
• "Revisit value proposition"

---

Phase 4: Competitive Landscape

Understand the competitive environment to differentiate effectively.

Step 1: Known Competitors

Use AskUserQuestion:

Question: "What existing solutions do users currently use for this problem?" Guidance: List products, services, or workarounds that address the same need.

Capture as KNOWN_COMPETITORS[].

Step 2: Competitor Analysis

For top 2-3 competitors, capture:

Use AskUserQuestion:

Question: "For [competitor], what are their strengths and weaknesses?" Capture:

• Strengths: What do they do well?
• Weaknesses: Where do they fall short?
• Price point: Free / Freemium / Paid
• Target segment: Who do they serve best?

Store as COMPETITOR_ANALYSIS[].

Step 3: Differentiation Strategy

Use AskUserQuestion:

Question: "Based on competitor gaps, how will you differentiate?" Options:

• "Better user experience"
• "Lower price / different pricing model"
• "Focus on underserved segment"
• "Superior performance / features"
• "Integration with existing tools"
• "Other — specify"

Capture as DIFFERENTIATION_STRATEGY.

Step 4: Validate Competitive Position

Use AskUserQuestion:

Question: "Competitive landscape: [N] competitors analyzed. Differentiation: [strategy]. Continue?" Options:

• "Yes — continue to features"
• "Add more competitors"
• "Refine differentiation strategy"

---

Phase 5: Feature Exploration

Translate capabilities into specific features.

Step 1: Feature Brainstorm

For each capability in CAPABILITIES[], use AskUserQuestion:

Question: "For '[capability]', what features would enable this?" Example: "Capability: Manage tasks → Features: Create task, Assign task, Set due date, Add labels"

Collect features in FEATURE_CANDIDATES[] with:

• Feature name
• Brief description
• Parent capability
• Priority guess (Must/Should/Could)
• Acceptance criteria draft

Step 2: Acceptance Criteria

For each Must/Should feature, capture acceptance criteria:

Use AskUserQuestion:

Question: "For '[feature]', what would 'done' look like? How would you verify it works?" Example: "User can create a task with title, assignee, and due date; task appears in task list immediately"

Store as ACCEPTANCE_CRITERIA[] linked to features.

Step 3: Priority Calibration (MoSCoW)

Present feature candidates as table using MoSCoW prioritization:

| Priority | Feature | Description |
|----------|---------|-------------|
| Must | [name] | [desc] |
| Should | [name] | [desc] |
| Could | [name] | [desc] |
| Won't | [name] | [desc] |

MoSCoW Legend:

• Must: Required for product to have value; MVP
• Should: Important but not blocking; V1.0
• Could: Desirable if time permits; Future release
• Won't: Explicitly out of scope for planning purposes

Use AskUserQuestion:

Question: "Adjust priorities using MoSCoW?" Options:

• "Looks good — continue"
• "Promote features to Must"
• "Demote features to Should/Could"
• "Mark as Won't (out of scope)"
• "Add missing features"
• "Remove features"

Step 4: Out of Scope Definition

Use AskUserQuestion:

Question: "What features or capabilities are explicitly NOT included? (Helps prevent scope creep)" Guidance: What do stakeholders often ask for that you're choosing not to build?

Capture as OUT_OF_SCOPE[].

Step 5: Validate Feature Set

Use AskUserQuestion:

Question: "Final feature set: [N] features ([X] Must, [Y] Should, [Z] Could, [W] Won't). Continue?" Options:

• "Yes — continue to requirements"
• "Adjust priorities again"
• "Add/remove features"
• "Adjust out of scope"

---

Phase 6: Requirements & Constraints

Capture non-functional requirements and limitations.

Step 1: Platform/Technical Constraints

Use AskUserQuestion:

Question: "What technical constraints exist?" **Options (multi-select):

• "Must work on mobile"
• "Must work offline"
• "Must integrate with [specify]"
• "Must be self-hosted"
• "Must meet compliance (SOC2, GDPR, etc.)"
• "Performance critical (sub-second response)"
• "Other — let me specify"

Capture as TECHNICAL_CONSTRAINTS[].

Step 2: Business Constraints

Use AskUserQuestion:

Question: "What business constraints exist?" **Options (multi-select):

• "Fixed launch deadline"
• "Limited budget"
• "Small team size"
• "Must generate revenue within [timeframe]"
• "Competitive pressure"
• "Other — let me specify"

Capture as BUSINESS_CONSTRAINTS[].

Step 3: Security/Compliance

Use AskUserQuestion:

Question: "What security or compliance requirements apply?" **Options (multi-select):

• "SOC 2 Type II"
• "GDPR"
• "HIPAA"
• "Data encryption at rest"
• "Data encryption in transit"
• "Audit logging"
• "SSO/SAML required"
• "None currently"

Capture as COMPLIANCE_REQUIREMENTS[].

---

Phase 7: Risk Assessment & Mitigation

Identify potential risks and develop mitigation strategies.

Step 1: Risk Brainstorm

Use AskUserQuestion:

Question: "What could go wrong with this product? Consider technical, market, and execution risks." Guidance: Think about: Can we build it? Will users want it? Can we compete?

Capture risks in RISKS[] with:

• Risk description
• Category: Technical / Market / Execution / Regulatory
• Likelihood: High / Medium / Low
• Impact: High / Medium / Low

Step 2: Mitigation Planning

For each High likelihood OR High impact risk:

Use AskUserQuestion:

Question: "For [risk], how can we mitigate or reduce this risk?" Capture: Mitigation strategy and contingency plan

Store as RISK_MITIGATIONS[].

Step 3: Validate Risk Coverage

Use AskUserQuestion:

Question: "Risks: [N] identified ([X] high-priority). Mitigations: [Y] defined. Continue?" Options:

• "Yes — continue to metrics"
• "Add more risks"
• "Refine mitigations"

---

Phase 8: Success Metrics

Define how to measure product success.

Step 1: Primary Success Metric

Use AskUserQuestion:

Question: "What is the ONE metric that matters most for success?" Examples:

• "Monthly active users (MAU)"
• "Task completion rate"
• "Revenue"
• "NPS score"
• "Time saved per user"

Capture as PRIMARY_METRIC.

Step 2: Supporting Metrics

Use AskUserQuestion:

Question: "What other metrics would indicate healthy product adoption? (Select up to 3)" Options:

• "Daily/weekly active users"
• "User retention (day 7, day 30)"
• "Feature adoption rate"
• "Error rate / uptime"
• "Support ticket volume"
• "Time to value"
• "Other — specify"

Capture as SECONDARY_METRICS[].

Step 3: Target Values

Use AskUserQuestion:

Question: "What are realistic targets for month 1, month 6, and month 12 for [PRIMARY_METRIC]?" Guidance: Month 1: baseline, Month 6: growth, Month 12: scale

Capture as METRIC_TARGETS.

---

Phase 9: Key Assumptions Validation

Identify and validate the critical assumptions underlying the product.

Step 1: Assumption Discovery

Use AskUserQuestion:

Question: "What must be true for this product to succeed? List your key assumptions." Guidance: Examples: Users want this problem solved. We can build the technology. The price point is acceptable.

Capture as KEY_ASSUMPTIONS[].

Step 2: Assumption Testing

For each assumption, determine:

Use AskUserQuestion:

Question: "For '[assumption]', how can we validate this before building?" Capture:

• Validation method (user interview, prototype test, market research)
• Success criteria (what would confirm/disprove this)
• Priority: Critical / Important / Nice to know

Store as ASSUMPTION_TESTS[].

Step 3: Validation Plan

Use AskUserQuestion:

Question: "Assumptions: [N] identified ([X] critical). Tests: [Y] defined. Continue?" Options:

• "Yes — continue to roadmap"
• "Add more assumptions"
• "Refine validation approach"

---

Phase 10: Roadmap & Phasing

Plan how to release the product over time.

Step 1: MVP Definition

Use AskUserQuestion:

Question: "What is the smallest set of Must-have features that could deliver value?" **Display Must features and ask which constitute MVP.

Capture as MVP_FEATURES[].

Step 2: Release Phases

Use AskUserQuestion:

Question: "How should releases be structured?" Options:

• "MVP → V1 → V2 (3 phases)"
• "MVP → Full release (2 phases)"
• "Continuous deployment (no phases)"
• "Custom — let me specify"

If custom, ask for phase names and which features go in each.

Capture as RELEASE_PHASES[].

Step 3: Timeline Expectations

Use AskUserQuestion:

Question: "What is the target timeline for MVP?" Options:

• "1-2 months"
• "3-4 months"
• "6 months"
• "1 year"
• "No fixed timeline"

Capture as TIMELINE_ESTIMATE.

---

Phase 11: Domain Discovery

Capture the core domain model to provide shared context for downstream initiative and epic planning.

Step 1: Domain Entities

Use AskUserQuestion:

Question: "What are the core business objects/entities in this system? List the key things the system manages." Guidance: Think about the nouns in the business domain — the objects that have identity, lifecycle, and relationships. Example: "Customer, Order, Payment, Product, Subscription"

Capture as DOMAIN_ENTITIES[] with:

• Entity name
• Brief description
• Key attributes (top 3-5)
• Lifecycle states (e.g., Draft → Active → Archived)

Step 2: Entity Relationships

Use AskUserQuestion:

Question: "How do these entities relate to each other? Describe key relationships." Guidance: Think about: which entities own or contain others, which entities reference each other, one-to-many vs. many-to-many.

Capture relationships between entities identified in Step 1.

Step 3: Bounded Contexts

Use AskUserQuestion:

Question: "Are there distinct areas/modules/services that own different groups of entities?" Guidance: In a large system, different teams or services own different parts of the domain. These are bounded contexts (DDD concept). Options:

• "Yes — let me describe the boundaries"
• "Single context — this is a simple system"
• "Not sure yet — mark as TBD"

If yes, capture BOUNDED_CONTEXTS[] with:

• Context name
• Owned entities
• Relationship to other contexts (upstream/downstream, shared kernel, ACL)

Step 4: Domain Events (Optional)

Use AskUserQuestion:

Question: "What key events happen in the system that other parts need to react to?" Guidance: Examples: "Order placed", "Payment received", "User registered". These are important for understanding system integration. Options:

• "Let me list key events"
• "Skip — too early to define events"

If provided, capture DOMAIN_EVENTS[] with:

• Event name
• Source context/entity
• Consumer context(s)
• Trigger condition

Step 5: Validate Domain Model

Use AskUserQuestion:

Question: "Domain model summary: [N] entities across [M] bounded contexts, [P] domain events. Continue?" Display: Entity catalog table and bounded context map Options:

• "Yes — continue to system interactions"
• "Add more entities"
• "Refine relationships"
• "Adjust bounded contexts"

---

Phase 12: System Interactions

Capture how services and external systems communicate.

Step 1: Service Communication Patterns

Use AskUserQuestion:

Question: "How will the services/components in this system communicate with each other?" Options:

• "REST APIs (synchronous)"
• "Message queue / Event bus (asynchronous, e.g., Kafka, RabbitMQ)"
• "Shared database"
• "Mixed — REST for queries, events for state changes"
• "Not sure yet — mark as TBD"

Capture as SERVICE_INTERACTIONS[] with:

• From service/context
• To service/context
• Communication pattern (REST/Kafka/gRPC/shared DB)
• Purpose
• Frequency (per request / periodic / event-driven)

Step 2: External System Integrations

Use AskUserQuestion:

Question: "Does this product integrate with external systems or third-party services?" Guidance: Think about: payment gateways, identity providers, government systems, email/SMS services, analytics, monitoring. Options:

• "Yes — let me list them"
• "No external integrations"
• "Not sure yet — mark as TBD"

If yes, capture EXTERNAL_SYSTEMS[] with:

• System name
• Protocol (REST API, SFTP, SOAP, etc.)
• Direction (inbound/outbound/bidirectional)
• Data exchanged

Step 3: Validate System Interactions

Use AskUserQuestion:

Question: "System interactions: [N] internal communication patterns, [M] external integrations. Continue?" Options:

• "Yes — continue to PRD generation"
• "Add more interactions"
• "Refine patterns"

---

Phase 13: PRD Generation & Commit

Step 1: Generate Product Identifier

Derive a kebab-case functional identifier from the vision or value proposition:

• 2-4 words describing the core capability
• Descriptive and functional
• No proper nouns or product names
• Examples: ai-assistant-cli, query-engine, terminal-ui-framework

Use AskUserQuestion:

Question: "Product identifier suggestion: [generated-functional-name]. Accept or modify?" Options:

• "Accept: [name]"
• "Modify — suggest: [input]"

Store as PRODUCT_IDENTIFIER.

Step 2: Get Next Product Number

Run script to get next product number:

scripts/next-product-number.sh

Store as PRODUCT_NUMBER (3-digit, zero-padded).

Step 3: Generate PRD

1. Read templates/prd-template.md
2. Enforce Functional Naming Protocol (clean-room context):
   • Replace any accidental product references with functional descriptions
   • Ensure no company names or trademarks appear
   • Verify language frames this as building a new product
   • Use NNN-[functional-name] format for all epic references
3. Fill template with all captured data:
   • Product metadata (number, functional identifier, date, status, author)
   • Vision section (problem, vision, category)
   • Users section (primary, scenarios, secondary)
   • Solution section (current workaround, value prop, capabilities)
   • Features section (MoSCoW prioritized with acceptance criteria)
   • Out of scope section (explicitly not building)
   • Requirements section (technical, business, compliance)
   • Success metrics section (primary, secondary, targets)
   • Roadmap section (MVP, phases, timeline)
   • Traceability chain (PRD → Epics mapping)
   • Epic candidates (derived from Must/Should features)
   • Domain model section (bounded context map, entity catalog, domain events)
   • System interaction map (service communication patterns, external integrations)
   • Ubiquitous language (project glossary link, product-specific terminology)

Step 4: Create Directory and Write PRD

mkdir -p agile/product/NNN-[functional-identifier]/

Write PRD to agile/product/NNN-[functional-identifier]/prd.md

Step 5: Preview and Confirm

Display PRD summary:

PRD Preview: NNN-[functional-identifier]

| Section | Content |
|---------|---------|
| Product | [functional identifier] |
| Vision | [vision summary] |
| Users | [primary user] |
| Features | [N] total ([X] Must, [Y] Should, [Z] Could) |
| Out of Scope | [W] items explicitly excluded |
| Timeline | [MVP target] |
| Epic Candidates | [N] potential epics |

Use AskUserQuestion:

Question: "Create and commit this PRD?" Options:

• "Yes — create and commit"
• "Preview full PRD first"
• "Go back and adjust"
• "Cancel — discard"

If preview: show full PRD content, then ask again.

Step 6: Commit

If approved:

1. Write PRD to disk
2. Git commit:

   git add agile/product/NNN-[functional-identifier]/prd.md
   git commit -m "docs(agile): add PRD for product NNN-[functional-identifier]"
   

Step 7: Present Next Steps

Display:

PRD Created: agile/product/NNN-[functional-identifier]/prd.md

Next steps:
1. Create epics from this PRD:
   /agile:epic:brainstorm @agile/product/NNN-[functional-identifier]/prd.md

2. View the PRD:
   [file path shown]

3. Iterate on the PRD:
   Edit the file directly or re-run this skill

---

Key Principles

1. One question at a time — Every question via AskUserQuestion
2. Multiple choice preferred — Use options when choices are natural
3. Progressive disclosure — Broad → Narrow → Specific
4. Validate at each phase — User confirms before proceeding
5. Allow backtracking — Can return to previous phases
6. YAGNI ruthlessly — Question every feature and requirement
7. Capture measurable criteria — Vague adjectives → Specific metrics

Templates

Template	Purpose
templates/prd-template.md	Full PRD structure
templates/prd-validation-checklist.md	Quality validation criteria and scoring rubric

Scripts

Script	Purpose
scripts/next-product-number.sh	Get next 3-digit product number

Output Location

PRDs are saved to: agile/product/NNN-[functional-identifier]/prd.md

Relationship to Epics

A PRD can spawn multiple epics. When creating epics from a PRD:

• Each P0 feature group may become an epic
• Reference the PRD in epic design.md: **Derived from**: PRD NNN-[functional-identifier]
• Link back: PRD tracks "Implemented in Epics" section
• Epic names MUST use functional naming: NNN-[capability-description]

Terminal State

The terminal state is a committed PRD at agile/product/NNN-product-name/prd.md. Do NOT automatically create epics. The user will manually invoke /agile:epic:brainstorm with a reference to the PRD if desired.