# PRD Workflow - Intent-Driven Product Planning
The workflow execution engine is governed by: {project-root}/.bmad/core/tasks/workflow.xml
You MUST have already loaded and processed: {installed_path}/workflow.yaml
This workflow uses INTENT-DRIVEN PLANNING - adapt organically to product type and context
Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}
Generate all documents in {document_output_language}
LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end
GUIDING PRINCIPLE: Find and weave the product's magic throughout - what makes it special should inspire every section
Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically
Check if {status_file} exists
Set standalone_mode = true
Load the FULL file: {status_file}
Parse workflow_status section
Check status of "prd" workflow
Get project_track from YAML metadata
Find first non-completed workflow (next expected workflow)
Exit and suggest tech-spec workflow
Re-running will overwrite the existing PRD. Continue? (y/n)
Exit workflow
Set standalone_mode = false
Welcome {user_name} and begin comprehensive discovery, and then start to GATHER ALL CONTEXT:
1. Check workflow-status.yaml for project_context (if exists)
2. Look for existing documents (Product Brief, Domain Brief, research)
3. Detect project type AND domain complexity
Load references:
{installed_path}/project-types.csv
{installed_path}/domain-complexity.csv
Through natural conversation:
"Tell me about what you want to build - what problem does it solve and for whom?"
DUAL DETECTION:
Project type signals: API, mobile, web, CLI, SDK, SaaS
Domain complexity signals: medical, finance, government, education, aerospace
SPECIAL ROUTING:
If game detected → Inform user that game development requires the BMGD module (BMad Game Development)
If complex domain detected → Offer domain research options:
A) Run domain-research workflow (thorough)
B) Quick web search (basic)
C) User provides context
D) Continue with general knowledge
CAPTURE THE MAGIC EARLY with a few questions such as for example: "What excites you most about this product?", "What would make users love this?", "What's the moment that will make people go 'wow'?"
This excitement becomes the thread woven throughout the PRD.
vision_alignment
project_classification
project_type
domain_type
complexity_level
domain_context_summary
product_magic_essence
product_brief_path
domain_brief_path
research_documents
Define what winning looks like for THIS specific product
INTENT: Meaningful success criteria, not generic metrics
Adapt to context:
- Consumer: User love, engagement, retention
- B2B: ROI, efficiency, adoption
- Developer tools: Developer experience, community
- Regulated: Compliance, safety, validation
Make it specific:
- NOT: "10,000 users"
- BUT: "100 power users who rely on it daily"
- NOT: "99.9% uptime"
- BUT: "Zero data loss during critical operations"
Weave in the magic:
- "Success means users experience [that special moment] and [desired outcome]"
success_criteria
business_metrics
{project-root}/.bmad/core/tasks/adv-elicit.xml
Smart scope negotiation - find the sweet spot
The Scoping Game:
1. "What must work for this to be useful?" → MVP
2. "What makes it competitive?" → Growth
3. "What's the dream version?" → Vision
Challenge scope creep conversationally:
- "Could that wait until after launch?"
- "Is that essential for proving the concept?"
For complex domains:
- Include compliance minimums in MVP
- Note regulatory gates between phases
mvp_scope
growth_features
vision_features
{project-root}/.bmad/core/tasks/adv-elicit.xml
Only if complex domain detected or domain-brief exists
Synthesize domain requirements that will shape everything:
- Regulatory requirements
- Compliance needs
- Industry standards
- Safety/risk factors
- Required validations
- Special expertise needed
These inform:
- What features are mandatory
- What NFRs are critical
- How to sequence development
- What validation is required
domain_considerations
Identify truly novel patterns if applicable
Listen for innovation signals:
- "Nothing like this exists"
- "We're rethinking how [X] works"
- "Combining [A] with [B] for the first time"
Explore deeply:
- What makes it unique?
- What assumption are you challenging?
- How do we validate it?
- What's the fallback?
{concept} innovations {date}
innovation_patterns
validation_approach
Based on detected project type, dive deep into specific needs
Load project type requirements from CSV and expand naturally.
FOR API/BACKEND:
- Map out endpoints, methods, parameters
- Define authentication and authorization
- Specify error codes and rate limits
- Document data schemas
FOR MOBILE:
- Platform requirements (iOS/Android/both)
- Device features needed
- Offline capabilities
- Store compliance
FOR SAAS B2B:
- Multi-tenant architecture
- Permission models
- Subscription tiers
- Critical integrations
[Continue for other types...]
Always relate back to the product magic:
"How does [requirement] enhance [the special thing]?"
project_type_requirements
endpoint_specification
authentication_model
platform_requirements
device_features
tenant_model
permission_matrix
Only if product has a UI
Light touch on UX - not full design:
- Visual personality
- Key interaction patterns
- Critical user flows
"How should this feel to use?"
"What's the vibe - professional, playful, minimal?"
Connect to the magic:
"The UI should reinforce [the special moment] through [design approach]"
ux_principles
key_interactions
Transform everything discovered into clear functional requirements
Pull together:
- Core features from scope
- Domain-mandated features
- Project-type specific needs
- Innovation requirements
Organize by capability, not technology:
- User Management (not "auth system")
- Content Discovery (not "search algorithm")
- Team Collaboration (not "websockets")
Each requirement should:
- Be specific and measurable
- Connect to user value
- Include acceptance criteria
- Note domain constraints
The magic thread:
Highlight which requirements deliver the special experience
functional_requirements_complete
{project-root}/.bmad/core/tasks/adv-elicit.xml
Only document NFRs that matter for THIS product
Performance: Only if user-facing impact
Security: Only if handling sensitive data
Scale: Only if growth expected
Accessibility: Only if broad audience
Integration: Only if connecting systems
For each NFR:
- Why it matters for THIS product
- Specific measurable criteria
- Domain-driven requirements
Skip categories that don't apply!
performance_requirements
security_requirements
scalability_requirements
accessibility_requirements
integration_requirements
Review the PRD we've built together
"Let's review what we've captured:
- Vision: [summary]
- Success: [key metrics]
- Scope: [MVP highlights]
- Requirements: [count] functional, [count] non-functional
- Special considerations: [domain/innovation]
Does this capture your product vision?"
prd_summary
{project-root}/.bmad/core/tasks/adv-elicit.xml
After PRD review and refinement complete:
"Excellent! Now we need to break these requirements into implementable epics and stories.
For the epic breakdown, you have two options:
1. Start a new session focused on epics (recommended for complex projects)
2. Continue here (I'll transform requirements into epics now)
Which would you prefer?"
If new session:
"To start epic planning in a new session:
1. Save your work here
2. Start fresh and run: workflow epics-stories
3. It will load your PRD and create the epic breakdown
This keeps each session focused and manageable."
If continue:
"Let's continue with epic breakdown here..."
[Proceed with epics-stories subworkflow]
Set project_track based on workflow status (BMad Method or Enterprise Method)
Generate epic_details for the epics breakdown document
project_track
epic_details
product_magic_summary
Load the FULL file: {status_file}
Update workflow_status["prd"] = "{default_output_file}"
Save file, preserving ALL comments and structure