diff --git a/bmad/core/agents/bmad-master.md b/bmad/core/agents/bmad-master.md
index 80f1ee61..5c5095b2 100644
--- a/bmad/core/agents/bmad-master.md
+++ b/bmad/core/agents/bmad-master.md
@@ -14,34 +14,32 @@ You must fully embody this agent's persona and follow all activation instruction
- Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
- VERIFY: If config not loaded, STOP and report error to user
- DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
- Remember: user's name is {user_name}
Load into memory {project-root}/bmad/core/config.yaml and set variable project_name, output_folder, user_name, communication_language
Remember the users name is {user_name}
ALWAYS communicate in {communication_language}
Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of
ALL menu items from menu section
- STOP and WAIT for user input - do NOT execute menu items automatically - accept number or trigger text
- On user input: Number → execute menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user
- to clarify | No match → show "Not recognized"
+ STOP and WAIT for user input - do NOT execute menu items automatically - accept number or trigger text or fuzzy matching from conversation
+ If you are unsure, verify the workflow the user wants to run - PLEASE PLEASE DO NOT JUST GUESS OR WORSE INVENT A WORKFLOW THAT YOU CANNOT REALLY FIND
When executing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item
- (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handler instructions
+ (workflow, exec, tmpl, data, action, validate-workflow) and follow the corresponding handlers instructions
-
+
When menu item has: action="#id" → Find prompt with id="id" in current agent XML, execute its content
When menu item has: action="text" → Execute the text directly as an inline instruction
-
- When menu item has: workflow="path/to/workflow.yaml"
- 1. CRITICAL: Always LOAD {project-root}/bmad/core/tasks/workflow.xml
- 2. Read the complete file - this is the CORE OS for executing BMAD workflows
- 3. Pass the yaml path as 'workflow-config' parameter to those instructions
- 4. Execute workflow.xml instructions precisely following all steps
- 5. Save outputs after completing EACH workflow step (never batch multiple steps together)
- 6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
-
+
+ When menu item has: workflow="path/to/workflow.yaml"
+ 1. CRITICAL: Always LOAD {project-root}/bmad/core/tasks/workflow.xml
+ 2. Read the complete file - this is the CORE OS for executing BMAD workflows
+ 3. Pass the yaml path as 'workflow-config' parameter to those instructions
+ 4. Execute workflow.xml instructions precisely following all steps
+ 5. Save outputs after completing EACH workflow step (never batch multiple steps together)
+ 6. If workflow.yaml path is "todo", inform user the workflow hasn't been implemented yet
+
diff --git a/src/modules/bmm/agents/game-designer.agent.yaml b/src/modules/bmm/agents/game-designer.agent.yaml
index a52bbf4c..3db30534 100644
--- a/src/modules/bmm/agents/game-designer.agent.yaml
+++ b/src/modules/bmm/agents/game-designer.agent.yaml
@@ -30,11 +30,11 @@ agent:
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/brainstorm-game/workflow.yaml"
description: Guide me through Game Brainstorming
- - trigger: game-brief
+ - trigger: create-game-brief
workflow: "{project-root}/bmad/bmm/workflows/1-analysis/game-brief/workflow.yaml"
description: Create Game Brief
- - trigger: gdd
+ - trigger: create-gdd
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/gdd/workflow.yaml"
description: Create Game Design Document (GDD)
diff --git a/src/modules/bmm/agents/pm.agent.yaml b/src/modules/bmm/agents/pm.agent.yaml
index aaff7060..f75e5cc8 100644
--- a/src/modules/bmm/agents/pm.agent.yaml
+++ b/src/modules/bmm/agents/pm.agent.yaml
@@ -31,10 +31,20 @@ agent:
workflow: "{project-root}/bmad/bmm/workflows/workflow-status/workflow.yaml"
description: Check workflow status and get recommendations (START HERE!)
- - trigger: prd
+ - trigger: create-prd
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml"
description: Create Product Requirements Document (PRD) for Level 2-4 projects
+ - trigger: create-epics-and-stories
+ workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
+ description: Break PRD requirements into implementable epics and stories
+
+ - trigger: validate-prd
+ validate-workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/workflow.yaml"
+ checklist: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/checklist.md"
+ document: "{output_folder}/PRD.md"
+ description: Validate PRD + Epics + Stories completeness and quality
+
- trigger: tech-spec
workflow: "{project-root}/bmad/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml"
description: Create Tech Spec for Level 0-1 (sometimes Level 2) projects
diff --git a/src/modules/bmm/workflows/1-analysis/domain-research/instructions.md b/src/modules/bmm/workflows/1-analysis/domain-research/instructions.md
new file mode 100644
index 00000000..ae3b30a3
--- /dev/null
+++ b/src/modules/bmm/workflows/1-analysis/domain-research/instructions.md
@@ -0,0 +1,423 @@
+# Domain Research - Collaborative Domain Exploration
+
+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 is COLLABORATIVE RESEARCH - engage the user as a partner, not just a data source
+The goal is PRACTICAL UNDERSTANDING that directly informs requirements and architecture
+Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}
+Generate all documents in {document_output_language}
+LIVING DOCUMENT: Write to domain-brief.md continuously as you discover - never wait until the end
+
+
+
+
+Welcome {user_name} to collaborative domain research
+
+Check for context:
+
+- Was this triggered from PRD workflow?
+- Is there a workflow-status.yaml with project context?
+- Did user provide initial domain/project description?
+
+If context exists, reflect it back:
+"I understand you're building [description]. Let's explore the [domain] aspects together to ensure we capture all critical requirements."
+
+If no context:
+"Let's explore your project's domain together. Tell me about what you're building and what makes it unique or complex."
+
+
+
+Through conversation, identify the domain and its complexity
+
+Listen for domain signals and explore:
+
+- "Is this in a regulated industry?"
+- "Are there safety or compliance concerns?"
+- "What could go wrong if this fails?"
+- "Who are the stakeholders beyond direct users?"
+- "Are there industry standards we need to follow?"
+
+Based on responses, identify primary domain(s):
+
+- Healthcare/Medical
+- Financial Services
+- Government/Public Sector
+- Education
+- Aerospace/Defense
+- Automotive
+- Energy/Utilities
+- Legal
+- Insurance
+- Scientific/Research
+- Other specialized domain
+
+Share your understanding:
+"Based on our discussion, this appears to be a [domain] project with [key characteristics]. The main areas we should research are:
+
+- [Area 1]
+- [Area 2]
+- [Area 3]
+
+What concerns you most about building in this space?"
+
+domain_overview
+
+
+
+Work WITH the user to identify critical concerns
+
+"Let's map out the important considerations together. I'll share what I typically see in [domain], and you tell me what applies to your case."
+
+For detected domain, explore relevant areas:
+
+HEALTHCARE:
+"In healthcare software, teams often worry about:
+
+- FDA approval pathways (510k, De Novo, PMA)
+- HIPAA compliance for patient data
+- Clinical validation requirements
+- Integration with hospital systems (HL7, FHIR, DICOM)
+- Patient safety and liability
+
+Which of these apply to you? What else concerns you?"
+
+FINTECH:
+"Financial software typically deals with:
+
+- KYC/AML requirements
+- Payment processing regulations (PCI DSS)
+- Regional compliance (US, EU, specific countries?)
+- Fraud prevention
+- Audit trails and reporting
+
+What's your situation with these? Any specific regions?"
+
+AEROSPACE:
+"Aerospace software often requires:
+
+- DO-178C certification levels
+- Safety analysis (FMEA, FTA)
+- Simulation validation
+- Real-time performance guarantees
+- Export control (ITAR)
+
+Which are relevant for your project?"
+
+[Continue for other domains...]
+
+Document concerns as the user shares them
+Ask follow-up questions to understand depth:
+
+- "How critical is this requirement?"
+- "Is this a must-have for launch or can it come later?"
+- "Do you have expertise here or need guidance?"
+
+concern_mapping
+
+
+
+Conduct research WITH the user watching and contributing
+
+"Let me research the current requirements for [specific concern]. You can guide me toward what's most relevant."
+
+{specific_requirement} requirements {date}
+
+Share findings immediately:
+"Here's what I found about [requirement]:
+
+- [Key point 1]
+- [Key point 2]
+- [Key point 3]
+
+Does this match your understanding? Anything surprising or concerning?"
+
+For each major concern:
+
+1. Research current standards/regulations
+2. Share findings with user
+3. Get their interpretation
+4. Note practical implications
+
+If user has expertise:
+"You seem knowledgeable about [area]. What should I know that might not be in public documentation?"
+
+If user is learning:
+"This might be new territory. Let me explain what this means practically for your development..."
+
+regulatory_requirements
+industry_standards
+
+
+
+Translate research into practical development impacts
+
+"Based on what we've learned, here's what this means for your project:
+
+ARCHITECTURE IMPLICATIONS:
+
+- [How this affects system design]
+- [Required components or patterns]
+- [Performance or security needs]
+
+DEVELOPMENT IMPLICATIONS:
+
+- [Additional development effort]
+- [Special expertise needed]
+- [Testing requirements]
+
+TIMELINE IMPLICATIONS:
+
+- [Certification/approval timelines]
+- [Validation requirements]
+- [Documentation needs]
+
+COST IMPLICATIONS:
+
+- [Compliance costs]
+- [Required tools or services]
+- [Ongoing maintenance]
+
+Does this align with your expectations? Any surprises we should dig into?"
+
+practical_implications
+
+
+
+Explore how others solve similar problems
+
+"Let's look at how successful [domain] products handle these challenges."
+
+best {domain} software architecture patterns {date}
+{domain} software case studies {date}
+
+Discuss patterns:
+"I found these common approaches in [domain]:
+
+Pattern 1: [Description]
+
+- Pros: [Benefits]
+- Cons: [Tradeoffs]
+- When to use: [Conditions]
+
+Pattern 2: [Description]
+
+- Pros: [Benefits]
+- Cons: [Tradeoffs]
+- When to use: [Conditions]
+
+Which resonates with your vision? Or are you thinking something different?"
+
+If user proposes novel approach:
+"That's interesting and different from the standard patterns. Let's explore:
+
+- What makes your approach unique?
+- What problem does it solve that existing patterns don't?
+- What are the risks?
+- How do we validate it?"
+
+domain_patterns
+innovation_notes
+
+
+
+Collaboratively identify and address risks
+
+"Every [domain] project has risks. Let's think through yours:
+
+REGULATORY RISKS:
+
+- What if regulations change during development?
+- What if approval/certification takes longer?
+- What if we misinterpret requirements?
+
+TECHNICAL RISKS:
+
+- What if the domain requirements conflict with user experience?
+- What if performance requirements are harder than expected?
+- What if integrations are more complex?
+
+MARKET RISKS:
+
+- What if competitors move faster?
+- What if domain experts are hard to find?
+- What if users resist domain-mandated workflows?
+
+For each risk you're concerned about, let's identify:
+
+1. How likely is it?
+2. What's the impact if it happens?
+3. How can we mitigate it?
+4. What's our plan B?"
+
+risk_assessment
+
+
+
+Plan how to ensure domain requirements are met
+
+"Let's plan how to validate that we're meeting [domain] requirements:
+
+COMPLIANCE VALIDATION:
+
+- How do we verify regulatory compliance?
+- Who needs to review/approve?
+- What documentation is required?
+
+TECHNICAL VALIDATION:
+
+- How do we prove the system works correctly?
+- What metrics matter?
+- What testing is required?
+
+DOMAIN EXPERT VALIDATION:
+
+- Who are the domain experts to involve?
+- When should they review?
+- What are their success criteria?
+
+USER VALIDATION:
+
+- How do we ensure it's still usable despite constraints?
+- What user testing is needed?
+- How do we balance domain requirements with UX?
+
+What validation is most critical for your confidence?"
+
+validation_strategy
+
+
+
+Capture key decisions and rationale
+
+"Let's document the important decisions we've made:
+
+DOMAIN APPROACH:
+
+- We're choosing [approach] because [rationale]
+- We're prioritizing [requirement] over [requirement] because [reason]
+- We're deferring [requirement] to Phase 2 because [justification]
+
+COMPLIANCE STRATEGY:
+
+- We'll pursue [pathway] for regulatory approval
+- We'll implement [standard] for industry compliance
+- We'll handle [requirement] by [approach]
+
+RISK DECISIONS:
+
+- We accept [risk] because [reason]
+- We'll mitigate [risk] through [approach]
+- We'll monitor [risk] by [method]
+
+Any decisions you want to revisit or rationale to add?"
+
+key_decisions
+
+
+
+Synthesize research into specific recommendations
+
+"Based on our research, here are my recommendations for your PRD and development:
+
+MUST HAVE (Domain Critical):
+
+1. [Specific requirement with why it's critical]
+2. [Specific requirement with why it's critical]
+3. [Specific requirement with why it's critical]
+
+SHOULD HAVE (Domain Important):
+
+1. [Requirement that's important but not blocking]
+2. [Requirement that's important but not blocking]
+
+CONSIDER (Domain Nice-to-Have):
+
+1. [Enhancement that would differentiate]
+2. [Enhancement that would differentiate]
+
+DEVELOPMENT SEQUENCE:
+
+1. First: [What to build first and why]
+2. Then: [What comes next and why]
+3. Later: [What can wait and why]
+
+EXPERTISE NEEDED:
+
+- [Domain expert role]: For [specific areas]
+- [Technical expert role]: For [specific requirements]
+
+TIMELINE CONSIDERATIONS:
+
+- Allow [time] for [process/approval]
+- Start [requirement] early because [reason]
+- [Requirement] can be parallel with development
+
+Do these recommendations feel right? What would you adjust?"
+
+recommendations
+
+
+
+Create clear handoff to PRD workflow
+
+"I've captured everything in domain-brief.md. Here's the summary for your PRD:
+
+DOMAIN: {identified_domain}
+COMPLEXITY: {high|medium}
+
+KEY REQUIREMENTS TO INCORPORATE:
+
+- [Requirement 1 - critical for domain]
+- [Requirement 2 - critical for domain]
+- [Requirement 3 - important consideration]
+
+IMPACTS ON:
+
+- Functional Requirements: [How domain affects features]
+- Non-Functional Requirements: [Performance, security, etc.]
+- Architecture: [System design considerations]
+- Development: [Process and timeline impacts]
+
+REFERENCE DOCS:
+
+- Full domain analysis: domain-brief.md
+- Regulations researched: [List with links]
+- Standards referenced: [List with links]
+
+When you return to PRD, reference this brief for domain context.
+
+Any final questions before we wrap up the domain research?"
+
+summary_for_prd
+
+
+
+
+
+
+
diff --git a/src/modules/bmm/workflows/1-analysis/domain-research/template.md b/src/modules/bmm/workflows/1-analysis/domain-research/template.md
new file mode 100644
index 00000000..37e50bf7
--- /dev/null
+++ b/src/modules/bmm/workflows/1-analysis/domain-research/template.md
@@ -0,0 +1,180 @@
+# Domain Brief - {project_name}
+
+Generated: {date}
+Domain: {primary_domain}
+Complexity: {complexity_level}
+
+## Executive Summary
+
+{brief_overview_of_domain_research_findings}
+
+## Domain Overview
+
+### Industry Context
+
+{domain_overview}
+
+### Regulatory Landscape
+
+{regulatory_environment}
+
+### Key Stakeholders
+
+{stakeholder_analysis}
+
+## Critical Concerns
+
+### Compliance Requirements
+
+{concern_mapping}
+
+### Technical Constraints
+
+{technical_limitations_from_domain}
+
+### Safety/Risk Considerations
+
+{safety_risk_factors}
+
+## Regulatory Requirements
+
+{regulatory_requirements}
+
+## Industry Standards
+
+{industry_standards}
+
+## Practical Implications
+
+### Architecture Impact
+
+{architecture_implications}
+
+### Development Impact
+
+{development_implications}
+
+### Timeline Impact
+
+{timeline_implications}
+
+### Cost Impact
+
+{cost_implications}
+
+## Domain Patterns
+
+### Established Patterns
+
+{domain_patterns}
+
+### Innovation Opportunities
+
+{innovation_notes}
+
+## Risk Assessment
+
+### Identified Risks
+
+{risk_assessment}
+
+### Mitigation Strategies
+
+{mitigation_approaches}
+
+## Validation Strategy
+
+### Compliance Validation
+
+{compliance_validation_approach}
+
+### Technical Validation
+
+{technical_validation_approach}
+
+### Domain Expert Validation
+
+{expert_validation_approach}
+
+## Key Decisions
+
+{key_decisions}
+
+## Recommendations
+
+### Must Have (Critical)
+
+{critical_requirements}
+
+### Should Have (Important)
+
+{important_requirements}
+
+### Consider (Nice-to-Have)
+
+{optional_enhancements}
+
+### Development Sequence
+
+{recommended_sequence}
+
+### Required Expertise
+
+{expertise_needed}
+
+## PRD Integration Guide
+
+### Summary for PRD
+
+{summary_for_prd}
+
+### Requirements to Incorporate
+
+- {requirement_1}
+- {requirement_2}
+- {requirement_3}
+
+### Architecture Considerations
+
+- {architecture_consideration_1}
+- {architecture_consideration_2}
+
+### Development Considerations
+
+- {development_consideration_1}
+- {development_consideration_2}
+
+## References
+
+### Regulations Researched
+
+- {regulation_1_with_link}
+- {regulation_2_with_link}
+
+### Standards Referenced
+
+- {standard_1_with_link}
+- {standard_2_with_link}
+
+### Additional Resources
+
+- {resource_1}
+- {resource_2}
+
+## Appendix
+
+### Research Notes
+
+{detailed_research_notes}
+
+### Conversation Highlights
+
+{key_discussion_points_with_user}
+
+### Open Questions
+
+{questions_requiring_further_research}
+
+---
+
+_This domain brief was created through collaborative research between {user_name} and the AI facilitator. It should be referenced during PRD creation and updated as new domain insights emerge._
diff --git a/src/modules/bmm/workflows/1-analysis/domain-research/workflow.yaml b/src/modules/bmm/workflows/1-analysis/domain-research/workflow.yaml
new file mode 100644
index 00000000..59e18e8d
--- /dev/null
+++ b/src/modules/bmm/workflows/1-analysis/domain-research/workflow.yaml
@@ -0,0 +1,36 @@
+workflow:
+ id: domain-research
+ name: "Domain Research"
+ module: bmm
+ version: "6.0.0-alpha"
+ description: "Collaborative exploration of domain-specific requirements, regulations, and patterns for complex projects"
+
+ environment:
+ # Inherit from parent workflow or set defaults
+ user_name: "partner"
+ user_skill_level: "intermediate"
+ communication_language: "English"
+ document_output_language: "English"
+ date: "{system.date}"
+
+ required_files:
+ - instructions.md
+ - template.md
+
+ optional_files:
+ - domain-knowledge-base.md
+
+ outputs:
+ - domain-brief.md
+
+ metadata:
+ category: "analysis"
+ complexity: "medium"
+ estimated_time: "30-45 minutes"
+ prerequisites:
+ - "Basic project understanding"
+ when_to_use:
+ - "Complex regulated domains (healthcare, finance, aerospace)"
+ - "Novel technical domains requiring deep understanding"
+ - "Before PRD when domain expertise needed"
+ - "When compliance and regulations matter"
diff --git a/src/modules/bmm/workflows/1-analysis/product-brief/instructions.md b/src/modules/bmm/workflows/1-analysis/product-brief/instructions.md
index b0fafa4f..f44c1423 100644
--- a/src/modules/bmm/workflows/1-analysis/product-brief/instructions.md
+++ b/src/modules/bmm/workflows/1-analysis/product-brief/instructions.md
@@ -1,21 +1,19 @@
-# Product Brief - Interactive Workflow Instructions
+# Product Brief - Context-Adaptive Discovery Instructions
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
-Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+This workflow uses INTENT-DRIVEN FACILITATION - adapt organically to what emerges
+The goal is DISCOVERING WHAT MATTERS through natural conversation, not filling a template
+Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}
Generate all documents in {document_output_language}
-
-DOCUMENT OUTPUT: Concise, professional, strategically focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.
+LIVING DOCUMENT: Write to the document continuously as you discover - never wait until the end
Check if {output_folder}/bmm-workflow-status.yaml exists
-
-
- Set standalone_mode = true
-
+Set standalone_mode = true
Load the FULL file: {output_folder}/bmm-workflow-status.yaml
@@ -25,9 +23,10 @@
Find first non-completed workflow (next expected workflow)
-
-
-
+
+
@@ -38,7 +37,7 @@
-
+
Continue with Product Brief anyway? (y/n)
@@ -51,241 +50,427 @@
-
-Welcome the user in {communication_language} to the Product Brief creation process
-Explain this is a collaborative process to define their product vision and strategic foundation
-Ask the user to provide the project name for this product brief
+
+Welcome {user_name} warmly in {communication_language}
+
+Adapt your tone to {user_skill_level}:
+
+- Expert: "Let's define your product vision. What are you building?"
+- Intermediate: "I'm here to help shape your product vision. Tell me about your idea."
+- Beginner: "Hi! I'm going to help you figure out exactly what you want to build. Let's start with your idea - what got you excited about this?"
+
+Start with open exploration:
+
+- What sparked this idea?
+- What are you hoping to build?
+- Who is this for - yourself, a business, users you know?
+
+CRITICAL: Listen for context clues that reveal their situation:
+
+- Personal/hobby project (fun, learning, small audience)
+- Startup/solopreneur (market opportunity, competition matters)
+- Enterprise/corporate (stakeholders, compliance, strategic alignment)
+- Technical enthusiasm (implementation focused)
+- Business opportunity (market/revenue focused)
+- Problem frustration (solution focused)
+
+Based on their initial response, sense:
+
+- How formal/casual they want to be
+- Whether they think in business or technical terms
+- If they have existing materials to share
+- Their confidence level with the domain
+
+What's the project name, and what got you excited about building this?
+
+From even this first exchange, create initial document sections
project_name
-
-
-
-Explore what existing materials the user has available to inform the brief
-Offer options for input sources: market research, brainstorming results, competitive analysis, initial ideas, or starting fresh
-If documents are provided, load and analyze them to extract key insights, themes, and patterns
-Engage the user about their core vision: what problem they're solving, who experiences it most acutely, and what sparked this product idea
-Build initial understanding through conversational exploration rather than rigid questioning
-
-initial_context
-
-
-
-How would you like to work through the brief?
-
-**1. Interactive Mode** - We'll work through each section together, discussing and refining as we go
-
-**2. YOLO Mode** - I'll generate a complete draft based on our conversation so far, then we'll refine it together
-
-Which approach works best for you?
-
-Store the user's preference for mode
-collaboration_mode
-
-
-
-Guide deep exploration of the problem: current state frustrations, quantifiable impact (time/money/opportunities), why existing solutions fall short, urgency of solving now
-Challenge vague statements and push for specificity with probing questions
-Help the user articulate measurable pain points with evidence
-Craft a compelling, evidence-based problem statement
-
-problem_statement
-
-
-
-Shape the solution vision by exploring: core approach to solving the problem, key differentiators from existing solutions, why this will succeed, ideal user experience
-Focus on the "what" and "why", not implementation details - keep it strategic
-Help articulate compelling differentiators that make this solution unique
-Craft a clear, inspiring solution vision
-
-proposed_solution
-
-
-
-Guide detailed definition of primary users: demographic/professional profile, current problem-solving methods, specific pain points, goals they're trying to achieve
-Explore secondary user segments if applicable and define how their needs differ
-Push beyond generic personas like "busy professionals" - demand specificity and actionable details
-Create specific, actionable user profiles that inform product decisions
-
-primary_user_segment
-secondary_user_segment
-
-
-
-Guide establishment of SMART goals across business objectives and user success metrics
-Explore measurable business outcomes (user acquisition targets, cost reductions, revenue goals)
-Define user success metrics focused on behaviors and outcomes, not features (task completion time, return frequency)
-Help formulate specific, measurable goals that distinguish between business and user success
-Identify top 3-5 Key Performance Indicators that will track product success
-
-business_objectives
-user_success_metrics
-key_performance_indicators
-
-
-
-Be ruthless about MVP scope - identify absolute MUST-HAVE features for launch that validate the core hypothesis
-For each proposed feature, probe why it's essential vs nice-to-have
-Identify tempting features that need to wait for v2 - what adds complexity without core value
-Define what constitutes a successful MVP launch with clear criteria
-Challenge scope creep aggressively and push for true minimum viability
-Clearly separate must-haves from nice-to-haves
-
-core_features
-out_of_scope
-mvp_success_criteria
-
-
-
-Explore financial considerations: development investment, revenue potential, cost savings opportunities, break-even timing, budget alignment
-Investigate strategic alignment: company OKRs, strategic objectives, key initiatives supported, opportunity cost of NOT doing this
-Help quantify financial impact where possible - both tangible and intangible value
-Connect this product to broader company strategy and demonstrate strategic value
-
-financial_impact
-company_objectives_alignment
-strategic_initiatives
-
-
-
-Guide exploration of post-MVP future: Phase 2 features, expansion opportunities, long-term vision (1-2 years)
-Ensure MVP decisions align with future direction while staying focused on immediate goals
-
-phase_2_features
-long_term_vision
-expansion_opportunities
-
-
-
-Capture technical context as preferences, not final decisions
-Explore platform requirements: web/mobile/desktop, browser/OS support, performance needs, accessibility standards
-Investigate technology preferences or constraints: frontend/backend frameworks, database needs, infrastructure requirements
-Identify existing systems requiring integration
-Check for technical-preferences.yaml file if available
-Note these are initial thoughts for PM and architect to consider during planning
-
-platform_requirements
-technology_preferences
-architecture_considerations
-
-
-
-Guide realistic expectations setting around constraints: budget/resource limits, timeline pressures, team size/expertise, technical limitations
-Explore assumptions being made about: user behavior, market conditions, technical feasibility
-Document constraints clearly and list assumptions that need validation during development
-
-constraints
-key_assumptions
-
-
-
-Facilitate honest risk assessment: what could derail the project, impact if risks materialize
-Document open questions: what still needs figuring out, what needs more research
-Help prioritize risks by impact and likelihood
-Frame unknowns as opportunities to prepare, not just worries
-
-key_risks
-open_questions
-research_areas
-
-
-
-
-Based on initial context and any provided documents, generate a complete product brief covering all sections
-Make reasonable assumptions where information is missing
-Flag areas that need user validation with [NEEDS CONFIRMATION] tags
-
-problem_statement
-proposed_solution
-primary_user_segment
-secondary_user_segment
-business_objectives
-user_success_metrics
-key_performance_indicators
-core_features
-out_of_scope
-mvp_success_criteria
-phase_2_features
-long_term_vision
-expansion_opportunities
-financial_impact
-company_objectives_alignment
-strategic_initiatives
-platform_requirements
-technology_preferences
-architecture_considerations
-constraints
-key_assumptions
-key_risks
-open_questions
-research_areas
-
-Present the complete draft to the user
-Here's the complete brief draft. What would you like to adjust or refine?
-
-
-
-Which section would you like to refine?
-1. Problem Statement
-2. Proposed Solution
-3. Target Users
-4. Goals and Metrics
-5. MVP Scope
-6. Post-MVP Vision
-7. Financial Impact and Strategic Alignment
-8. Technical Considerations
-9. Constraints and Assumptions
-10. Risks and Questions
-11. Save and continue
-
-Work with user to refine selected section
-Update relevant template outputs
-
-
-
-
-Synthesize all sections into a compelling executive summary
-Include:
-- Product concept in 1-2 sentences
-- Primary problem being solved
-- Target market identification
-- Key value proposition
-
executive_summary
+
+If they mentioned existing documents (research, brainstorming, etc.):
+
+- Load and analyze these materials
+- Extract key themes and insights
+- Reference these naturally in conversation: "I see from your research that..."
+- Use these to accelerate discovery, not repeat questions
+
+initial_vision
-
-If research documents were provided, create a summary of key findings
-Document any stakeholder input received during the process
-Compile list of reference documents and resources
+
+Guide problem discovery through natural conversation
-research_summary
-stakeholder_input
-references
-
+DON'T ask: "What problem does this solve?"
-
-Generate the complete product brief document
-Review all sections for completeness and consistency
-Flag any areas that need PM attention with [PM-TODO] tags
+DO explore conversationally based on their context:
-The product brief is complete! Would you like to:
+For hobby projects:
-1. Review the entire document
-2. Make final adjustments
-3. Generate an executive summary version (3-page limit)
-4. Save and prepare for handoff to PM
+- "What's annoying you that this would fix?"
+- "What would this make easier or more fun?"
+- "Show me what the experience is like today without this"
-This brief will serve as the primary input for creating the Product Requirements Document (PRD).
+For business ventures:
-
- Create condensed 3-page executive brief focusing on: problem statement, proposed solution, target users, MVP scope, financial impact, and strategic alignment
- Save as: {output_folder}/product-brief-executive-{{project_name}}-{{date}}.md
+- "Walk me through the frustration your users face today"
+- "What's the cost of this problem - time, money, opportunities?"
+- "Who's suffering most from this? Tell me about them"
+- "What solutions have people tried? Why aren't they working?"
+
+For enterprise:
+
+- "What's driving the need for this internally?"
+- "Which teams/processes are most affected?"
+- "What's the business impact of not solving this?"
+- "Are there compliance or strategic drivers?"
+
+Listen for depth cues:
+
+- Brief answers → dig deeper with follow-ups
+- Detailed passion → let them flow, capture everything
+- Uncertainty → help them explore with examples
+- Multiple problems → help prioritize the core issue
+
+Adapt your response:
+
+- If they struggle: offer analogies, examples, frameworks
+- If they're clear: validate and push for specifics
+- If they're technical: explore implementation challenges
+- If they're business-focused: quantify impact
+
+Immediately capture what emerges - even if preliminary
+problem_statement
+
+
+ Explore the measurable impact of the problem
+ problem_impact
-final_brief
-executive_brief
+
+ Understand why existing solutions fall short
+ existing_solutions_gaps
+
+
+Reflect understanding: "So the core issue is {{problem_summary}}, and {{impact_if_mentioned}}. Let me capture that..."
+
+
+
+Transition naturally from problem to solution
+
+Based on their energy and context, explore:
+
+For builders/makers:
+
+- "How do you envision this working?"
+- "Walk me through the experience you want to create"
+- "What's the 'magic moment' when someone uses this?"
+
+For business minds:
+
+- "What's your unique approach to solving this?"
+- "How is this different from what exists today?"
+- "What makes this the RIGHT solution now?"
+
+For enterprise:
+
+- "What would success look like for the organization?"
+- "How does this fit with existing systems/processes?"
+- "What's the transformation you're enabling?"
+
+Go deeper based on responses:
+
+- If innovative → explore the unique angle
+- If standard → focus on execution excellence
+- If technical → discuss key capabilities
+- If user-focused → paint the journey
+
+Web research when relevant:
+
+- If they mention competitors → research current solutions
+- If they claim innovation → verify uniqueness
+- If they reference trends → get current data
+
+
+ {{competitor/market}} latest features 2024
+ Use findings to sharpen differentiation discussion
+
+
+proposed_solution
+
+
+ key_differentiators
+
+
+Continue building the living document
+
+
+
+Discover target users through storytelling, not demographics
+
+Facilitate based on project type:
+
+Personal/hobby:
+
+- "Who else would love this besides you?"
+- "Tell me about someone who would use this"
+- Keep it light and informal
+
+Startup/business:
+
+- "Describe your ideal first customer - not demographics, but their situation"
+- "What are they doing today without your solution?"
+- "What would make them say 'finally, someone gets it!'?"
+- "Are there different types of users with different needs?"
+
+Enterprise:
+
+- "Which roles/departments will use this?"
+- "Walk me through their current workflow"
+- "Who are the champions vs skeptics?"
+- "What about indirect stakeholders?"
+
+Push beyond generic personas:
+
+- Not: "busy professionals" → "Sales reps who waste 2 hours/day on data entry"
+- Not: "tech-savvy users" → "Developers who know Docker but hate configuring it"
+- Not: "small businesses" → "Shopify stores doing $10-50k/month wanting to scale"
+
+For each user type that emerges:
+
+- Current behavior/workflow
+- Specific frustrations
+- What they'd value most
+- Their technical comfort level
+
+primary_user_segment
+
+
+ Explore secondary users only if truly different needs
+ secondary_user_segment
+
+
+
+ user_journey
+
+
+
+
+Explore success measures that match their context
+
+For personal projects:
+
+- "How will you know this is working well?"
+- "What would make you proud of this?"
+- Keep metrics simple and meaningful
+
+For startups:
+
+- "What metrics would convince you this is taking off?"
+- "What user behaviors show they love it?"
+- "What business metrics matter most - users, revenue, retention?"
+- Push for specific targets: "100 users" not "lots of users"
+
+For enterprise:
+
+- "How will the organization measure success?"
+- "What KPIs will stakeholders care about?"
+- "What are the must-hit metrics vs nice-to-haves?"
+
+Only dive deep into metrics if they show interest
+Skip entirely for pure hobby projects
+Focus on what THEY care about measuring
+
+
+ success_metrics
+
+
+ business_objectives
+
+
+
+ key_performance_indicators
+
+
+
+Keep the document growing with each discovery
+
+
+
+Focus on FEATURES not epics - that comes in Phase 2
+
+Guide MVP scoping based on their maturity
+
+For experimental/hobby:
+
+- "What's the ONE thing this must do to be useful?"
+- "What would make a fun first version?"
+- Embrace simplicity
+
+For business ventures:
+
+- "What's the smallest version that proves your hypothesis?"
+- "What features would make early adopters say 'good enough'?"
+- "What's tempting to add but would slow you down?"
+- Be ruthless about scope creep
+
+For enterprise:
+
+- "What's the pilot scope that demonstrates value?"
+- "Which capabilities are must-have for initial rollout?"
+- "What can we defer to Phase 2?"
+
+Use this framing:
+
+- Core features: "Without this, the product doesn't work"
+- Nice-to-have: "This would be great, but we can launch without it"
+- Future vision: "This is where we're headed eventually"
+
+Challenge feature creep:
+
+- "Do we need that for launch, or could it come later?"
+- "What if we started without that - what breaks?"
+- "Is this core to proving the concept?"
+
+core_features
+
+
+ out_of_scope
+
+
+
+ future_vision_features
+
+
+
+ mvp_success_criteria
+
+
+
+
+Only explore what emerges naturally - skip what doesn't matter
+
+Based on the conversation so far, selectively explore:
+
+IF financial aspects emerged:
+
+- Development investment needed
+- Revenue potential or cost savings
+- ROI timeline
+- Budget constraints
+
+ financial_considerations
+
+
+IF market competition mentioned:
+
+- Competitive landscape
+- Market opportunity size
+- Differentiation strategy
+- Market timing
+
+ {{market}} size trends 2024
+ market_analysis
+
+
+IF technical preferences surfaced:
+
+- Platform choices (web/mobile/desktop)
+- Technology stack preferences
+- Integration needs
+- Performance requirements
+
+ technical_preferences
+
+
+IF organizational context emerged:
+
+- Strategic alignment
+- Stakeholder buy-in needs
+- Change management considerations
+- Compliance requirements
+
+ organizational_context
+
+
+IF risks or concerns raised:
+
+- Key risks and mitigation
+- Critical assumptions
+- Open questions needing research
+
+ risks_and_assumptions
+
+
+IF timeline pressures mentioned:
+
+- Launch timeline
+- Critical milestones
+- Dependencies
+
+ timeline_constraints
+
+
+Skip anything that hasn't naturally emerged
+Don't force sections that don't fit their context
+
+
+
+Review what's been captured with the user
+
+"Let me show you what we've built together..."
+
+Present the actual document sections created so far
+
+- Not a summary, but the real content
+- Shows the document has been growing throughout
+
+Ask:
+"Looking at this, what stands out as most important to you?"
+"Is there anything critical we haven't explored?"
+"Does this capture your vision?"
+
+Based on their response:
+
+- Refine sections that need more depth
+- Add any missing critical elements
+- Remove or simplify sections that don't matter
+- Ensure the document fits THEIR needs, not a template
+
+Make final refinements based on feedback
+final_refinements
+
+Create executive summary that captures the essence
+executive_summary
+
+
+The document has been building throughout our conversation
+Now ensure it's complete and well-organized
+
+
+ Append summary of incorporated research
+ supporting_materials
+
+
+Ensure the document structure makes sense for what was discovered:
+
+- Hobbyist projects might be 2-3 pages focused on problem/solution/features
+- Startup ventures might be 5-7 pages with market analysis and metrics
+- Enterprise briefs might be 10+ pages with full strategic context
+
+The document should reflect their world, not force their world into a template
+
+Your product brief is ready! Would you like to:
+
+1. Review specific sections together
+2. Make any final adjustments
+3. Save and move forward
+
+What feels right?
+
+Make any requested refinements
+final_document
-
Load the FULL file: {output_folder}/bmm-workflow-status.yaml
Find workflow_status key "product-brief"
@@ -299,34 +484,23 @@ This brief will serve as the primary input for creating the Product Requirements
-
+
+Remember: This brief captures YOUR vision. It grew from our conversation, not from a rigid template. It's ready to guide the next phase of bringing your idea to life.
+
+
diff --git a/src/modules/bmm/workflows/1-analysis/product-brief/template.md b/src/modules/bmm/workflows/1-analysis/product-brief/template.md
index f8992424..4684bdc5 100644
--- a/src/modules/bmm/workflows/1-analysis/product-brief/template.md
+++ b/src/modules/bmm/workflows/1-analysis/product-brief/template.md
@@ -2,7 +2,7 @@
**Date:** {{date}}
**Author:** {{user_name}}
-**Status:** Draft for PM Review
+**Context:** {{context_type}}
---
@@ -12,154 +12,170 @@
---
-## Problem Statement
+## Core Vision
+
+### Problem Statement
{{problem_statement}}
----
+{{#if problem_impact}}
-## Proposed Solution
+### Problem Impact
+
+{{problem_impact}}
+{{/if}}
+
+{{#if existing_solutions_gaps}}
+
+### Why Existing Solutions Fall Short
+
+{{existing_solutions_gaps}}
+{{/if}}
+
+### Proposed Solution
{{proposed_solution}}
+{{#if key_differentiators}}
+
+### Key Differentiators
+
+{{key_differentiators}}
+{{/if}}
+
---
## Target Users
-### Primary User Segment
+### Primary Users
{{primary_user_segment}}
-### Secondary User Segment
+{{#if secondary_user_segment}}
+
+### Secondary Users
{{secondary_user_segment}}
+{{/if}}
+
+{{#if user_journey}}
+
+### User Journey
+
+{{user_journey}}
+{{/if}}
---
-## Goals and Success Metrics
+{{#if success_metrics}}
+
+## Success Metrics
+
+{{success_metrics}}
+
+{{#if business_objectives}}
### Business Objectives
{{business_objectives}}
+{{/if}}
-### User Success Metrics
+{{#if key_performance_indicators}}
-{{user_success_metrics}}
-
-### Key Performance Indicators (KPIs)
+### Key Performance Indicators
{{key_performance_indicators}}
-
----
-
-## Strategic Alignment and Financial Impact
-
-### Financial Impact
-
-{{financial_impact}}
-
-### Company Objectives Alignment
-
-{{company_objectives_alignment}}
-
-### Strategic Initiatives
-
-{{strategic_initiatives}}
+{{/if}}
+{{/if}}
---
## MVP Scope
-### Core Features (Must Have)
+### Core Features
{{core_features}}
+{{#if out_of_scope}}
+
### Out of Scope for MVP
{{out_of_scope}}
+{{/if}}
+
+{{#if mvp_success_criteria}}
### MVP Success Criteria
{{mvp_success_criteria}}
+{{/if}}
+
+{{#if future_vision_features}}
+
+### Future Vision
+
+{{future_vision_features}}
+{{/if}}
---
-## Post-MVP Vision
+{{#if market_analysis}}
-### Phase 2 Features
+## Market Context
-{{phase_2_features}}
+{{market_analysis}}
+{{/if}}
-### Long-term Vision
+{{#if financial_considerations}}
-{{long_term_vision}}
+## Financial Considerations
-### Expansion Opportunities
+{{financial_considerations}}
+{{/if}}
-{{expansion_opportunities}}
+{{#if technical_preferences}}
+
+## Technical Preferences
+
+{{technical_preferences}}
+{{/if}}
+
+{{#if organizational_context}}
+
+## Organizational Context
+
+{{organizational_context}}
+{{/if}}
+
+{{#if risks_and_assumptions}}
+
+## Risks and Assumptions
+
+{{risks_and_assumptions}}
+{{/if}}
+
+{{#if timeline_constraints}}
+
+## Timeline
+
+{{timeline_constraints}}
+{{/if}}
+
+{{#if supporting_materials}}
+
+## Supporting Materials
+
+{{supporting_materials}}
+{{/if}}
---
-## Technical Considerations
+_This Product Brief captures the vision and requirements for {{project_name}}._
-### Platform Requirements
+_It was created through collaborative discovery and reflects the unique needs of this {{context_type}} project._
-{{platform_requirements}}
-
-### Technology Preferences
-
-{{technology_preferences}}
-
-### Architecture Considerations
-
-{{architecture_considerations}}
-
----
-
-## Constraints and Assumptions
-
-### Constraints
-
-{{constraints}}
-
-### Key Assumptions
-
-{{key_assumptions}}
-
----
-
-## Risks and Open Questions
-
-### Key Risks
-
-{{key_risks}}
-
-### Open Questions
-
-{{open_questions}}
-
-### Areas Needing Further Research
-
-{{research_areas}}
-
----
-
-## Appendices
-
-### A. Research Summary
-
-{{research_summary}}
-
-### B. Stakeholder Input
-
-{{stakeholder_input}}
-
-### C. References
-
-{{references}}
-
----
-
-_This Product Brief serves as the foundational input for Product Requirements Document (PRD) creation._
-
-_Next Steps: Handoff to Product Manager for PRD development using the `workflow prd` command._
+{{#if next_workflow}}
+_Next: {{next_workflow}} will transform this brief into detailed planning artifacts._
+{{else}}
+_Next: Use the PRD workflow to create detailed product requirements from this brief._
+{{/if}}
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/checklist.md b/src/modules/bmm/workflows/2-plan-workflows/prd/checklist.md
index 36c41fff..cce5c539 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/prd/checklist.md
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/checklist.md
@@ -1,117 +1,349 @@
-# PRD Workflow Validation Checklist
+# PRD + Epics + Stories Validation Checklist
-**Purpose**: Validate PRD workflow outputs are complete, consistent, and ready for next phase.
+**Purpose**: Comprehensive validation that PRD, epics, and stories form a complete, implementable product plan.
-**Scope**: Levels 2-4 software projects
+**Scope**: Validates the complete planning output (PRD.md + epics.md) for Levels 2-4 software projects
-**Expected Outputs**: PRD.md, epics.md, updated bmm-workflow-status.md
+**Expected Outputs**:
+
+- PRD.md with complete requirements
+- epics.md with detailed epic and story breakdown
+- Updated bmm-workflow-status.yaml
---
-## 1. Output Files Exist
+## 1. PRD Document Completeness
-- [ ] PRD.md created in output folder
-- [ ] epics.md created in output folder (separate file)
-- [ ] bmm-workflow-status.md updated
-- [ ] No unfilled {{template_variables}}
+### Core Sections Present
+
+- [ ] Executive Summary with vision alignment
+- [ ] Product magic essence clearly articulated
+- [ ] Project classification (type, domain, complexity)
+- [ ] Success criteria defined
+- [ ] Product scope (MVP, Growth, Vision) clearly delineated
+- [ ] Functional requirements comprehensive and numbered
+- [ ] Non-functional requirements (when applicable)
+- [ ] References section with source documents
+
+### Project-Specific Sections
+
+- [ ] **If complex domain:** Domain context and considerations documented
+- [ ] **If innovation:** Innovation patterns and validation approach documented
+- [ ] **If API/Backend:** Endpoint specification and authentication model included
+- [ ] **If Mobile:** Platform requirements and device features documented
+- [ ] **If SaaS B2B:** Tenant model and permission matrix included
+- [ ] **If UI exists:** UX principles and key interactions documented
+
+### Quality Checks
+
+- [ ] No unfilled template variables ({{variable}})
+- [ ] All variables properly populated with meaningful content
+- [ ] Product magic woven throughout (not just stated once)
+- [ ] Language is clear, specific, and measurable
+- [ ] Project type correctly identified and sections match
+- [ ] Domain complexity appropriately addressed
---
-## 2. PRD.md Core Quality
+## 2. Functional Requirements Quality
-### Requirements Coverage
+### FR Format and Structure
-- [ ] Functional requirements describe WHAT capabilities (not HOW to implement)
-- [ ] Each FR has unique identifier (FR001, FR002, etc.)
-- [ ] Non-functional requirements (if any) have business justification
-- [ ] Requirements are testable and verifiable
+- [ ] Each FR has unique identifier (FR-001, FR-002, etc.)
+- [ ] FRs describe WHAT capabilities, not HOW to implement
+- [ ] FRs are specific and measurable
+- [ ] FRs are testable and verifiable
+- [ ] FRs focus on user/business value
+- [ ] No technical implementation details in FRs (those belong in architecture)
-### User Journeys
+### FR Completeness
-- [ ] User journeys reference specific FR numbers
-- [ ] Journeys show complete user paths through system
-- [ ] Success outcomes are clear
+- [ ] All MVP scope features have corresponding FRs
+- [ ] Growth features documented (even if deferred)
+- [ ] Vision features captured for future reference
+- [ ] Domain-mandated requirements included
+- [ ] Innovation requirements captured with validation needs
+- [ ] Project-type specific requirements complete
-### Strategic Focus
+### FR Organization
-- [ ] PRD focuses on WHAT and WHY (not technical HOW)
-- [ ] No specific technology choices in PRD (those belong in technical-decisions.md)
-- [ ] Goals are outcome-focused, not implementation-focused
+- [ ] FRs organized by capability/feature area (not by tech stack)
+- [ ] Related FRs grouped logically
+- [ ] Dependencies between FRs noted when critical
+- [ ] Priority/phase indicated (MVP vs Growth vs Vision)
---
-## 3. epics.md Story Quality
+## 3. Epics Document Completeness
-### Story Format
+### Required Files
-- [ ] All stories follow user story format: "As a [role], I want [capability], so that [benefit]"
-- [ ] Each story has numbered acceptance criteria
-- [ ] Prerequisites/dependencies explicitly stated
-
-### Story Sequencing (CRITICAL)
-
-- [ ] **Epic 1 establishes foundation** (infrastructure, initial deployable functionality)
- - Exception noted if adding to existing app
-- [ ] **Vertical slices**: Each story delivers complete, testable functionality (not horizontal layers)
-- [ ] **No forward dependencies**: No story depends on work from a LATER story or epic
-- [ ] Stories are sequentially ordered within each epic
-- [ ] Each story leaves system in working state
-
-### Coverage
-
-- [ ] All FRs from PRD.md are covered by stories in epics.md
+- [ ] epics.md exists in output folder
- [ ] Epic list in PRD.md matches epics in epics.md (titles and count)
+- [ ] All epics have detailed breakdown sections
+
+### Epic Quality
+
+- [ ] Each epic has clear goal and value proposition
+- [ ] Each epic includes complete story breakdown
+- [ ] Stories follow proper user story format: "As a [role], I want [goal], so that [benefit]"
+- [ ] Each story has numbered acceptance criteria
+- [ ] Prerequisites/dependencies explicitly stated per story
+- [ ] Stories are AI-agent sized (completable in 2-4 hour session)
---
-## 4. Cross-Document Consistency
+## 4. FR Coverage Validation (CRITICAL)
-- [ ] Epic titles consistent between PRD.md and epics.md
-- [ ] FR references in user journeys exist in requirements section
-- [ ] Terminology consistent across documents
+### Complete Traceability
+
+- [ ] **Every FR from PRD.md is covered by at least one story in epics.md**
+- [ ] Each story references relevant FR numbers
+- [ ] No orphaned FRs (requirements without stories)
+- [ ] No orphaned stories (stories without FR connection)
+- [ ] Coverage matrix verified (can trace FR → Epic → Stories)
+
+### Coverage Quality
+
+- [ ] Stories sufficiently decompose FRs into implementable units
+- [ ] Complex FRs broken into multiple stories appropriately
+- [ ] Simple FRs have appropriately scoped single stories
+- [ ] Non-functional requirements reflected in story acceptance criteria
+- [ ] Domain requirements embedded in relevant stories
+
+---
+
+## 5. Story Sequencing Validation (CRITICAL)
+
+### Epic 1 Foundation Check
+
+- [ ] **Epic 1 establishes foundational infrastructure**
+- [ ] Epic 1 delivers initial deployable functionality
+- [ ] Epic 1 creates baseline for subsequent epics
+- [ ] Exception: If adding to existing app, foundation requirement adapted appropriately
+
+### Vertical Slicing
+
+- [ ] **Each story delivers complete, testable functionality** (not horizontal layers)
+- [ ] No "build database" or "create UI" stories in isolation
+- [ ] Stories integrate across stack (data + logic + presentation when applicable)
+- [ ] Each story leaves system in working/deployable state
+
+### No Forward Dependencies
+
+- [ ] **No story depends on work from a LATER story or epic**
+- [ ] Stories within each epic are sequentially ordered
+- [ ] Each story builds only on previous work
+- [ ] Dependencies flow backward only (can reference earlier stories)
+- [ ] Parallel tracks clearly indicated if stories are independent
+
+### Value Delivery Path
+
+- [ ] Each epic delivers significant end-to-end value
+- [ ] Epic sequence shows logical product evolution
+- [ ] User can see value after each epic completion
+- [ ] MVP scope clearly achieved by end of designated epics
+
+---
+
+## 6. Scope Management
+
+### MVP Discipline
+
+- [ ] MVP scope is genuinely minimal and viable
+- [ ] Core features list contains only true must-haves
+- [ ] Each MVP feature has clear rationale for inclusion
+- [ ] No obvious scope creep in "must-have" list
+
+### Future Work Captured
+
+- [ ] Growth features documented for post-MVP
+- [ ] Vision features captured to maintain long-term direction
+- [ ] Out-of-scope items explicitly listed
+- [ ] Deferred features have clear reasoning for deferral
+
+### Clear Boundaries
+
+- [ ] Stories marked as MVP vs Growth vs Vision
+- [ ] Epic sequencing aligns with MVP → Growth progression
+- [ ] No confusion about what's in vs out of initial scope
+
+---
+
+## 7. Research and Context Integration
+
+### Source Document Integration
+
+- [ ] **If product brief exists:** Key insights incorporated into PRD
+- [ ] **If domain brief exists:** Domain requirements reflected in FRs and stories
+- [ ] **If research documents exist:** Research findings inform requirements
+- [ ] **If competitive analysis exists:** Differentiation strategy clear in PRD
+- [ ] All source documents referenced in PRD References section
+
+### Research Continuity to Architecture
+
+- [ ] Domain complexity considerations documented for architects
+- [ ] Technical constraints from research captured
+- [ ] Regulatory/compliance requirements clearly stated
+- [ ] Integration requirements with existing systems documented
+- [ ] Performance/scale requirements informed by research data
+
+### Information Completeness for Next Phase
+
+- [ ] PRD provides sufficient context for architecture decisions
+- [ ] Epics provide sufficient detail for technical design
+- [ ] Stories have enough acceptance criteria for implementation
+- [ ] Non-obvious business rules documented
+- [ ] Edge cases and special scenarios captured
+
+---
+
+## 8. Cross-Document Consistency
+
+### Terminology Consistency
+
+- [ ] Same terms used across PRD and epics for concepts
+- [ ] Feature names consistent between documents
+- [ ] Epic titles match between PRD and epics.md
- [ ] No contradictions between PRD and epics
----
+### Alignment Checks
-## 5. Readiness for Next Phase
-
-**Adapt based on project level from bmm-workflow-status.md:**
-
-### If Level 2:
-
-- [ ] PRD provides sufficient context for tech-spec workflow (lightweight solutioning)
-- [ ] Epic structure supports 5-15 story implementation scope
-
-### If Level 3-4:
-
-- [ ] PRD provides sufficient context for create-architecture workflow
-- [ ] Epic structure supports phased delivery approach
-- [ ] Clear value delivery path through epic sequence
+- [ ] Success metrics in PRD align with story outcomes
+- [ ] Product magic articulated in PRD reflected in epic goals
+- [ ] Technical preferences in PRD align with story implementation hints
+- [ ] Scope boundaries consistent across all documents
---
-## 6. Critical Failures (Auto-Fail)
+## 9. Readiness for Implementation
-- [ ] ❌ **No epics.md file** (two-file output is required)
-- [ ] ❌ **Epic 1 doesn't establish foundation** (violates core principle)
-- [ ] ❌ **Stories have forward dependencies** (would break sequential implementation)
+### Architecture Readiness (Next Phase)
+
+- [ ] PRD provides sufficient context for architecture workflow
+- [ ] Technical constraints and preferences documented
+- [ ] Integration points identified
+- [ ] Performance/scale requirements specified
+- [ ] Security and compliance needs clear
+
+### Development Readiness
+
+- [ ] Stories are specific enough to estimate
+- [ ] Acceptance criteria are testable
+- [ ] Technical unknowns identified and flagged
+- [ ] Dependencies on external systems documented
+- [ ] Data requirements specified
+
+### Level-Appropriate Detail
+
+**If Level 2:**
+
+- [ ] PRD supports lightweight tech-spec workflow
+- [ ] 5-15 story scope reasonable for project size
+- [ ] Complexity appropriate for small team/solo dev
+
+**If Level 3-4:**
+
+- [ ] PRD supports full architecture workflow
+- [ ] Epic structure supports phased delivery
+- [ ] Scope appropriate for team-based development
+- [ ] Clear value delivery through epic sequence
+
+---
+
+## 10. Quality and Polish
+
+### Writing Quality
+
+- [ ] Language is clear and free of jargon (or jargon is defined)
+- [ ] Sentences are concise and specific
+- [ ] No vague statements ("should be fast", "user-friendly")
+- [ ] Measurable criteria used throughout
+- [ ] Professional tone appropriate for stakeholder review
+
+### Document Structure
+
+- [ ] Sections flow logically
+- [ ] Headers and numbering consistent
+- [ ] Cross-references accurate (FR numbers, section references)
+- [ ] Formatting consistent throughout
+- [ ] Tables/lists formatted properly
+
+### Completeness Indicators
+
+- [ ] No [TODO] or [TBD] markers remain
+- [ ] No placeholder text
+- [ ] All sections have substantive content
+- [ ] Optional sections either complete or omitted (not half-done)
+
+---
+
+## Critical Failures (Auto-Fail)
+
+If ANY of these are true, validation FAILS:
+
+- [ ] ❌ **No epics.md file exists** (two-file output required)
+- [ ] ❌ **Epic 1 doesn't establish foundation** (violates core sequencing principle)
+- [ ] ❌ **Stories have forward dependencies** (breaks sequential implementation)
- [ ] ❌ **Stories not vertically sliced** (horizontal layers block value delivery)
-- [ ] ❌ **Technical decisions in PRD** (should be in technical-decisions.md)
- [ ] ❌ **Epics don't cover all FRs** (orphaned requirements)
-- [ ] ❌ **User journeys don't reference FR numbers** (missing traceability)
+- [ ] ❌ **FRs contain technical implementation details** (should be in architecture)
+- [ ] ❌ **No FR traceability to stories** (can't validate coverage)
+- [ ] ❌ **Template variables unfilled** (incomplete document)
---
-## Validation Notes
+## Validation Summary
-**Document any findings:**
+**Total Validation Points:** ~85
-- Strengths:
-- Issues to address:
-- Recommended actions:
+### Scoring Guide
-**Ready for next phase?** [Yes / No - explain]
+- **Pass Rate ≥ 95% (81+/85):** ✅ EXCELLENT - Ready for architecture phase
+- **Pass Rate 85-94% (72-80/85):** ⚠️ GOOD - Minor fixes needed
+- **Pass Rate 70-84% (60-71/85):** ⚠️ FAIR - Important issues to address
+- **Pass Rate < 70% (<60/85):** ❌ POOR - Significant rework required
+
+### Critical Issue Threshold
+
+- **0 Critical Failures:** Proceed to fixes
+- **1+ Critical Failures:** STOP - Must fix critical issues first
---
-_Adapt this checklist based on actual outputs. Not all sections may apply to every project._
+## Validation Execution Notes
+
+**When validating:**
+
+1. **Load ALL documents:**
+ - PRD.md (required)
+ - epics.md (required)
+ - product-brief.md (if exists)
+ - domain-brief.md (if exists)
+ - research documents (if referenced)
+
+2. **Validate in order:**
+ - Check critical failures first (immediate stop if any found)
+ - Verify PRD completeness
+ - Verify epics completeness
+ - Cross-reference FR coverage (most important)
+ - Check sequencing (second most important)
+ - Validate research integration
+ - Check polish and quality
+
+3. **Report findings:**
+ - List critical failures prominently
+ - Group issues by severity
+ - Provide specific line numbers/sections
+ - Suggest concrete fixes
+ - Highlight what's working well
+
+4. **Provide actionable next steps:**
+ - If validation passes: "Ready for architecture workflow"
+ - If minor issues: "Fix [X] items then re-validate"
+ - If major issues: "Rework [sections] then re-validate"
+ - If critical failures: "Must fix critical items before proceeding"
+
+---
+
+**Remember:** This validation ensures the entire planning phase is complete and the implementation phase has everything needed to succeed. Be thorough but fair - the goal is quality, not perfection.
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/epics-template.md b/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md
similarity index 100%
rename from src/modules/bmm/workflows/2-plan-workflows/prd/epics-template.md
rename to src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md b/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md
new file mode 100644
index 00000000..0e5ab662
--- /dev/null
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md
@@ -0,0 +1,395 @@
+# Epic and Story Decomposition - Bite-Sized Implementation 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 transforms requirements into BITE-SIZED STORIES for limited context agents
+EVERY story must be completable by a single limited context window dev agent in one session
+Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}
+Generate all documents in {document_output_language}
+LIVING DOCUMENT: Write to epics.md continuously as you work - never wait until the end
+
+
+
+
+Welcome the {user_name} to the project inception high level epic and story planning.
+
+Load required documents:
+
+1. PRD.md (must exist - fuzzy match on name, might be a folder with an index and smaller sharded files also)
+2. domain-brief.md (if exists)
+3. product-brief.md (if exists)
+
+Extract from PRD:
+
+- Functional requirements
+- Non-functional requirements
+- Domain considerations
+- Project type
+- MVP scope vs growth features
+
+If continuing from PRD workflow:
+"Great! Now let's break down your requirements into actionable epics and bite-sized stories that development agents can implement independently."
+
+If starting fresh:
+"I'll help you transform your PRD into organized epics with implementable stories. Each story will be small enough for a single dev agent to complete in one session."
+
+
+
+Transform requirements into epics organically
+
+INTENT: Find natural boundaries that make sense for THIS product
+
+Look at the requirements and find patterns:
+
+- Features that work together
+- User journeys that connect
+- Technical systems that relate
+- Business capabilities that group
+- Domain requirements that cluster (compliance, validation, etc.)
+
+Examples of natural epic formation:
+
+- Auth features → "User Management" epic
+- Payment features → "Monetization" epic
+- Social features → "Community" epic
+- Admin features → "Administration" epic
+- Compliance requirements → "Regulatory Compliance" epic
+- API endpoints → "API Infrastructure" epic
+
+But let the product guide you - don't force standard patterns
+
+Each epic should:
+
+- Have a clear business goal
+- Be independently valuable
+- Contain 3-8 related features
+- Be completable in 1-2 sprints
+
+Name epics based on value, not technical components:
+GOOD: "User Onboarding", "Content Discovery", "Team Collaboration"
+NOT: "Database", "Frontend", "API"
+
+If domain considerations exist:
+
+- Create dedicated compliance/validation epics
+- Note special expertise needed per epic
+- Flag epics with regulatory dependencies
+
+Present epic groupings conversationally:
+"Based on your requirements, I see these natural epic groupings:
+
+1. [Epic Name] - [Brief description]
+2. [Epic Name] - [Brief description]
+3. [Epic Name] - [Brief description]
+
+Does this organization make sense for how you think about the product?"
+
+epics_structure
+
+
+
+Small vertical sliced small stories are best for agentic dumb developers to implement without forgetting things
+
+Break each epic into small, implementable stories
+
+INTENT: Create stories that one dev agent can complete independently
+
+For each epic, decompose into stories that are:
+
+- Small enough for single context window
+- Clear enough for autonomous implementation
+- Independent enough to develop in parallel when possible
+- Specific enough to have clear acceptance criteria
+
+GOOD story examples:
+
+- "Create login API endpoint that accepts email/password and returns JWT"
+- "Build user profile component with avatar upload to S3"
+- "Add password reset email template and sending logic"
+- "Implement rate limiting on auth endpoints (5 attempts per minute)"
+- "Create HIPAA-compliant audit log for patient data access"
+- "Build FDA 21 CFR Part 11 electronic signature component"
+
+BAD story examples:
+
+- "Build complete authentication system" (too big)
+- "Handle user management" (too vague)
+- "Make it secure" (not specific)
+- "Integrate everything" (requires multiple contexts)
+
+Story format:
+"As a [user type], I want [specific feature], so that [clear value]"
+
+Technical notes to include:
+
+- Affected files/components if known
+- Required endpoints/methods
+- Data structures needed
+- Specific validation rules
+- Compliance requirements if applicable
+- Dependencies on other stories
+
+Domain-aware story creation:
+
+- For healthcare: Include specific regulations per story
+- For fintech: Note PCI/security requirements per story
+- For govtech: Flag accessibility needs per story
+- For aerospace: Include safety/validation requirements
+
+Check each story:
+
+- Can this be explained in <1000 words?
+- Can one agent complete without another's output?
+- Is the scope crystal clear?
+- Are success criteria obvious?
+- Are domain requirements specified?
+
+If too big → split into smaller stories
+If too vague → add specifics
+If dependent → note the dependency clearly
+If domain-critical → flag compliance needs
+
+epic_1_stories
+epic_2_stories
+epic_3_stories
+
+
+
+
+
+Order stories for successful development
+
+INTENT: Create a logical flow that minimizes blockers and maximizes progress
+
+Consider dependencies:
+TECHNICAL:
+
+- Authentication before protected features
+- Data models before business logic
+- Core features before enhancements
+- API before frontend that uses it
+
+DOMAIN:
+
+- Compliance infrastructure before features
+- Validation framework before clinical features
+- Audit logging before financial transactions
+- Safety systems before operational features
+
+PRACTICAL:
+
+- What gives visible progress early?
+- What reduces risk soonest?
+- What enables parallel work?
+- What delivers value fastest?
+
+Create implementation phases:
+
+Phase 1 - Foundation:
+
+- Core data models
+- Authentication/authorization
+- Basic infrastructure
+- Essential APIs
+- Compliance foundation (if domain requires)
+
+Phase 2 - Core Features:
+
+- MVP functionality
+- Key user flows
+- Basic UI/UX
+- Critical integrations
+- Domain validations (if applicable)
+
+Phase 3 - Enhancement:
+
+- Polish and refinement
+- Additional features
+- Performance optimization
+- Extended functionality
+- Advanced compliance features
+
+Phase 4 - Growth:
+
+- Analytics and monitoring
+- Advanced features
+- Scaling preparations
+- Nice-to-have additions
+
+For complex domains, add gates:
+
+- "Gate: Security audit before payment processing"
+- "Gate: Clinical validation before patient features"
+- "Gate: Compliance review before launch"
+
+Present the sequencing conversationally:
+"Here's a smart implementation order:
+
+**Phase 1 (Foundation) - Week 1-2:**
+
+- Story 1.1: [Description]
+- Story 1.2: [Description] (can parallel with 1.1)
+- Story 1.3: [Description] (depends on 1.1)
+
+**Phase 2 (Core) - Week 3-4:**
+[Continue...]
+
+This gives you something working by [milestone] and allows [X] stories to run in parallel."
+
+implementation_sequence
+development_phases
+dependency_graph
+
+
+
+Review all stories for dev agent compatibility
+
+Run through each story and verify:
+
+SIZE CHECK:
+
+- Story description < 500 words
+- Clear inputs and outputs defined
+- Single responsibility principle
+- No hidden complexity
+
+CLARITY CHECK:
+
+- Acceptance criteria explicit
+- Technical approach clear
+- No ambiguous requirements
+- Success measurable
+
+DEPENDENCY CHECK:
+
+- Dependencies documented
+- Can start with clear inputs
+- Outputs well-defined
+- Parallel opportunities noted
+
+DOMAIN CHECK (if applicable):
+
+- Compliance requirements stated
+- Validation criteria defined
+- Regulatory references included
+- Special expertise noted
+
+If any issues found:
+"Story [X] seems too large. Let me split it:
+
+- [Smaller story 1]
+- [Smaller story 2]"
+
+"Story [Y] needs clarification on [aspect]. How should we handle [specific question]?"
+
+Final validation:
+"All stories are now sized for 200k context limits.
+
+- Total stories: [count]
+- Can run in parallel: [count]
+- Sequential dependencies: [count]
+- Estimated completion: [timeframe]"
+
+story_validation
+
+
+
+Add practical guidance for implementation teams
+
+Create quick reference for development:
+
+GETTING STARTED:
+"Start with Phase 1 stories - multiple can run in parallel.
+Key files to create first: [list]
+Recommended agent allocation: [suggestion]"
+
+DOMAIN GUIDANCE (if applicable):
+"Critical compliance checkpoints:
+
+- After story [X]: Run [validation]
+- Before story [Y]: Review [regulation]
+- Throughout: Maintain [audit trail]"
+
+TECHNICAL NOTES:
+"Architecture decisions needed:
+
+- [Decision 1] affects stories [A, B, C]
+- [Decision 2] blocks story [D]
+
+Consider these patterns:
+
+- [Pattern] for [epic]
+- [Pattern] for [requirement]"
+
+RISK MITIGATION:
+"Watch out for:
+
+- [Risk] in story [X]
+- [Complexity] in epic [Y]
+- [Dependency] between [A] and [B]"
+
+SUCCESS METRICS:
+"You'll know Phase 1 is complete when:
+
+- [Measurable outcome]
+- [Testable feature]
+- [Validation passed]"
+
+implementation_guidance
+
+
+
+Complete the epics document and prepare for development
+
+Review what we've created:
+"We've successfully decomposed your requirements into:
+
+- [x] epics
+- [Y] total stories
+- [Z] phases of development
+
+Every story is sized for a single dev agent to complete independently."
+
+Highlight key achievements:
+
+- Stories respect 200k context limit
+- Dependencies clearly mapped
+- Domain requirements integrated
+- Parallel development enabled
+
+Save completed epics.md with:
+
+- Full epic descriptions
+- All stories with acceptance criteria
+- Implementation sequence
+- Development phases
+- Dependency notes
+- Domain compliance requirements (if applicable)
+
+
+
+
+
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml b/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml
new file mode 100644
index 00000000..15ea09cf
--- /dev/null
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml
@@ -0,0 +1,43 @@
+# Epic and Story Decomposition Workflow
+name: create-epics-and-stories
+description: "Transform PRD requirements into bite-sized stories organized in epics for 200k context dev agents"
+author: "BMad"
+
+# Critical variables from config
+config_source: "{project-root}/bmad/bmm/config.yaml"
+project_name: "{config_source}:project_name"
+output_folder: "{config_source}:output_folder"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+user_skill_level: "{config_source}:user_skill_level"
+date: system-generated
+
+# Workflow components
+installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories"
+instructions: "{installed_path}/instructions.md"
+template: "{installed_path}/epics-template.md"
+
+# Input files (from parent PRD workflow)
+prd_file: "{output_folder}/PRD.md"
+
+# Output files
+default_output_file: "{output_folder}/epics.md"
+
+# Optional input documents
+recommended_inputs:
+ - prd: "{output_folder}/PRD.md"
+ - product_brief: "{output_folder}/product-brief.md"
+ - domain_brief: "{output_folder}/domain-brief.md"
+
+standalone: true
+
+web_bundle:
+ name: "create-epics-and-stories"
+ description: "Transform PRD requirements into bite-sized stories organized in epics for 200k context dev agents"
+ author: "BMad"
+ instructions: "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
+ template: "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
+ web_bundle_files:
+ - "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
+ - "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/domain-complexity.csv b/src/modules/bmm/workflows/2-plan-workflows/prd/domain-complexity.csv
new file mode 100644
index 00000000..2e44a896
--- /dev/null
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/domain-complexity.csv
@@ -0,0 +1,13 @@
+domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
+healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
+fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
+govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
+edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
+aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
+automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
+scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
+legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
+insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
+energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
+gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
+general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
\ No newline at end of file
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md b/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md
index 0f37e366..acda9438 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md
@@ -1,47 +1,33 @@
-# PRD Workflow Instructions
+# 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
-Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
+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}
-This workflow is for Level 2-4 projects. Level 0-1 use tech-spec workflow.
-Produces TWO outputs: PRD.md (strategic) and epics.md (tactical implementation)
-TECHNICAL NOTES: If ANY technical details, preferences, or constraints are mentioned during PRD discussions, append them to {technical_decisions_file}. If file doesn't exist, create it from {technical_decisions_template}
-
-DOCUMENT OUTPUT: Concise, clear, actionable requirements. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.
+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
-Check if {output_folder}/bmm-workflow-status.yaml exists
+Check if {status_file} exists
-
-
-
- Continue in standalone mode or exit to run workflow-init? (continue/exit)
-
- Set standalone_mode = true
-
-
- Exit workflow
-
-
+Set standalone_mode = true
- Load the FULL file: {output_folder}/bmm-workflow-status.yaml
+ Load the FULL file: {status_file}
Parse workflow_status section
Check status of "prd" workflow
Get project_level from YAML metadata
Find first non-completed workflow (next expected workflow)
-
+Exit and suggest tech-spec workflow
@@ -53,379 +39,367 @@ PRD is for Level 2-4 projects. Level 0-1 should use tech-spec directly.
-
- ⚠️ Next expected workflow: {{next_workflow}}. PRD is out of sequence.
- Continue with PRD anyway? (y/n)
-
- Exiting. Run {{next_workflow}} instead.
- 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
-Use {{project_level}} from status data
-Check for existing PRD.md in {output_folder}
+Load references:
+{installed_path}/project-types.csv
+{installed_path}/domain-complexity.csv
-
- Found existing PRD.md. Would you like to:
-1. Continue where you left off
-2. Modify existing sections
-3. Start fresh (will archive existing file)
-
- Load existing PRD and skip to first incomplete section
- Load PRD and ask which section to modify
- Archive existing PRD and start fresh
+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 → Suggest game-brief and GDD workflows
+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
-
-Load PRD template: {prd_template}
-Load epics template: {epics_template}
-
-Do you have a Product Brief? (Strongly recommended for Level 3-4, helpful for Level 2)
-
-
- Load and review product brief: {output_folder}/product-brief.md
- Extract key elements: problem statement, target users, success metrics, MVP scope, constraints
-
-
-
- Product Brief is strongly recommended for Level 3-4 projects. Consider running the product-brief workflow first.
- Continue without Product Brief? (y/n)
- Exit to allow Product Brief creation
-
-
+product_magic_essence
+product_brief_path
+domain_brief_path
+research_documents
-
+
+Define what winning looks like for THIS specific product
-**Goals** - What success looks like for this project
+INTENT: Meaningful success criteria, not generic metrics
-
- Review goals from product brief and refine for PRD context
+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
-
-
- Gather goals through discussion with user, use probing questions and converse until you are ready to propose that you have enough information to proceed
-
-
-Create a bullet list of single-line desired outcomes that capture user and project goals.
-
-**Scale guidance:**
-
-- Level 2: 2-3 core goals
-- Level 3: 3-5 strategic goals
-- Level 4: 5-7 comprehensive goals
-
-goals
-
-**Background Context** - Why this matters now
-
-
- Summarize key context from brief without redundancy
-
-
-
- Gather context through discussion
-
-
-Write 1-2 paragraphs covering:
-
-- What problem this solves and why
-- Current landscape or need
-- Key insights from discovery/brief (if available)
-
-background_context
-
-
+
+Smart scope negotiation - find the sweet spot
-**Functional Requirements** - What the system must do
+The Scoping Game:
-Draft functional requirements as numbered items with FR prefix.
+1. "What must work for this to be useful?" → MVP
+2. "What makes it competitive?" → Growth
+3. "What's the dream version?" → Vision
-**Scale guidance:**
+Challenge scope creep conversationally:
-- Level 2: 8-15 FRs (focused MVP set)
-- Level 3: 12-25 FRs (comprehensive product)
-- Level 4: 20-35 FRs (enterprise platform)
+- "Could that wait until after launch?"
+- "Is that essential for proving the concept?"
-**Format:**
+For complex domains:
-- FR001: [Clear capability statement]
-- FR002: [Another capability]
-
-**Focus on:**
-
-- User-facing capabilities
-- Core system behaviors
-- Integration requirements
-- Data management needs
-
-Group related requirements logically.
-
-{project-root}/bmad/core/tasks/adv-elicit.xml
-
-functional_requirements
-
-**Non-Functional Requirements** - How the system must perform
-
-Draft non-functional requirements with NFR prefix.
-
-**Scale guidance:**
-
-- Level 2: 1-3 NFRs (critical MVP only)
-- Level 3: 2-5 NFRs (production quality)
-- Level 4: 3-7+ NFRs (enterprise grade)
-
-non_functional_requirements
+- Include compliance minimums in MVP
+- Note regulatory gates between phases
+mvp_scope
+growth_features
+vision_features
-
+
+Only if complex domain detected or domain-brief exists
-**Journey Guidelines (scale-adaptive):**
+Synthesize domain requirements that will shape everything:
-- **Level 2:** 1 simple journey (primary use case happy path)
-- **Level 3:** 2-3 detailed journeys (complete flows with decision points)
-- **Level 4:** 3-5 comprehensive journeys (all personas and edge cases)
+- Regulatory requirements
+- Compliance needs
+- Industry standards
+- Safety/risk factors
+- Required validations
+- Special expertise needed
-
- Would you like to document a user journey for the primary use case? (recommended but optional)
-
- Create 1 simple journey showing the happy path.
-
+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
-
- Map complete user flows with decision points, alternatives, and edge cases.
+
+ platform_requirements
+ device_features
-user_journeys
-
-
- {project-root}/bmad/core/tasks/adv-elicit.xml
+
+ tenant_model
+ permission_matrix
-
-
+
+Only if product has a UI
-**Purpose:** Capture essential UX/UI information needed for epic and story planning. A dedicated UX workflow will provide deeper design detail later.
+Light touch on UX - not full design:
-
- For backend-heavy or minimal UI projects, keep this section very brief or skip
+- 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
-
-**Gather high-level UX/UI information:**
-
-1. **UX Principles** (2-4 key principles that guide design decisions)
- - What core experience qualities matter most?
- - Any critical accessibility or usability requirements?
-
-2. **Platform & Screens**
- - Target platforms (web, mobile, desktop)
- - Core screens/views users will interact with
- - Key interaction patterns or navigation approach
-
-3. **Design Constraints**
- - Existing design systems or brand guidelines
- - Technical UI constraints (browser support, etc.)
-
-Keep responses high-level. Detailed UX planning happens in the UX workflow after PRD completion.
-
-{project-root}/bmad/core/tasks/adv-elicit.xml
-
-ux_principles
-ui_design_goals
-
-
+
+Transform everything discovered into clear functional requirements
-**Epic Structure** - Major delivery milestones
+Pull together:
-Create high-level epic list showing logical delivery sequence.
+- Core features from scope
+- Domain-mandated features
+- Project-type specific needs
+- Innovation requirements
-**Epic Sequencing Rules:**
+Organize by capability, not technology:
-1. **Epic 1 MUST establish foundation**
- - Project infrastructure (repo, CI/CD, core setup)
- - Initial deployable functionality
- - Development workflow established
- - Exception: If adding to existing app, Epic 1 can be first major feature
+- User Management (not "auth system")
+- Content Discovery (not "search algorithm")
+- Team Collaboration (not "websockets")
-2. **Subsequent Epics:**
- - Each delivers significant, end-to-end, fully deployable increment
- - Build upon previous epics (no forward dependencies)
- - Represent major functional blocks
- - Prefer fewer, larger epics over fragmentation
+Each requirement should:
-**Scale guidance:**
+- Be specific and measurable
+- Connect to user value
+- Include acceptance criteria
+- Note domain constraints
-- Level 2: 1-2 epics, 5-15 stories total
-- Level 3: 2-5 epics, 15-40 stories total
-- Level 4: 5-10 epics, 40-100+ stories total
-
-**For each epic provide:**
-
-- Epic number and title
-- Single-sentence goal statement
-- Estimated story count
-
-**Example:**
-
-- **Epic 1: Project Foundation & User Authentication**
-- **Epic 2: Core Task Management**
-
-Review the epic list. Does the sequence make sense? Any epics to add, remove, or resequence?
-Refine epic list based on feedback
-{project-root}/bmad/core/tasks/adv-elicit.xml
-
-epic_list
+The magic thread:
+Highlight which requirements deliver the special experience
+functional_requirements_complete
-
+
+Only document NFRs that matter for THIS product
-**Out of Scope** - What we're NOT doing (now)
+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
-Document what is explicitly excluded from this project:
+For each NFR:
-- Features/capabilities deferred to future phases
-- Adjacent problems not being solved
-- Integrations or platforms not supported
-- Scope boundaries that need clarification
+- Why it matters for THIS product
+- Specific measurable criteria
+- Domain-driven requirements
-This helps prevent scope creep and sets clear expectations.
-
-out_of_scope
+Skip categories that don't apply!
+
+
+ performance_requirements
+
+
+ security_requirements
+
+
+ scalability_requirements
+
+
+ accessibility_requirements
+
+
+ integration_requirements
+
+
+ no_nfrs
+
-
+
+Review the PRD we've built together
-Review all PRD sections for completeness and consistency
-Ensure all placeholders are filled
-Save final PRD.md to {default_output_file}
+"Let's review what we've captured:
-**PRD.md is complete!** Strategic document ready.
+- Vision: [summary]
+- Success: [key metrics]
+- Scope: [MVP highlights]
+- Requirements: [count] functional, [count] non-functional
+- Special considerations: [domain/innovation]
-Now we'll create the tactical implementation guide in epics.md.
+Does this capture your product vision?"
+After confirmation:
+"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_level and target_scale based on project analysis
+Generate epic_details for the epics breakdown document
+
+prd_summary
+project_level
+target_scale
+epic_details
-
-
-Now we create epics.md - the tactical implementation roadmap
-This is a SEPARATE FILE from PRD.md
-
-Load epics template: {epics_template}
-Initialize epics.md with project metadata
-
-For each epic from the epic list, expand with full story details:
-
-**Epic Expansion Process:**
-
-1. **Expanded Goal** (2-3 sentences)
- - Describe the epic's objective and value delivery
- - Explain how it builds on previous work
-
-2. **Story Breakdown**
-
- **Critical Story Requirements:**
- - **Vertical slices** - Each story delivers complete, testable functionality
- - **Sequential** - Stories must be logically ordered within epic
- - **No forward dependencies** - No story depends on work from a later story/epic
- - **AI-agent sized** - Completable in single focused session (2-4 hours)
- - **Value-focused** - Minimize pure enabler stories; integrate technical work into value delivery
-
- **Story Format:**
-
- ```
- **Story [EPIC.N]: [Story Title]**
-
- As a [user type],
- I want [goal/desire],
- So that [benefit/value].
-
- **Acceptance Criteria:**
- 1. [Specific testable criterion]
- 2. [Another specific criterion]
- 3. [etc.]
-
- **Prerequisites:** [Any dependencies on previous stories]
- ```
-
-3. **Story Sequencing Within Epic:**
- - Start with foundational/setup work if needed
- - Build progressively toward epic goal
- - Each story should leave system in working state
- - Final stories complete the epic's value delivery
-
-**Process each epic:**
-
-
-
-Ready to break down {{epic_title}}? (y/n)
-
-Discuss epic scope and story ideas with user
-Draft story list ensuring vertical slices and proper sequencing
-For each story, write user story format and acceptance criteria
-Verify no forward dependencies exist
-
-{{epic_title}}\_details
-
-Review {{epic_title}} stories. Any adjustments needed?
-
-Refine stories based on feedback
-
-
-
-Save complete epics.md to {epics_output_file}
-
-**Epic Details complete!** Implementation roadmap ready.
-
-
-
-
+
+product_magic_summary
- Load the FULL file: {output_folder}/bmm-workflow-status.yaml
- Find workflow_status key "prd"
- ONLY write the file path as the status value - no other text, notes, or metadata
+ Load the FULL file: {status_file}
Update workflow_status["prd"] = "{default_output_file}"
- Save file, preserving ALL comments and structure including STATUS DEFINITIONS
-
-Find first non-completed workflow in workflow_status (next workflow to do)
-Determine next agent from path file based on next workflow
+ Save file, preserving ALL comments and structure
-**✅ PRD Workflow Complete, {user_name}!**
+**✅ PRD Complete, {user_name}!**
-**Deliverables Created:**
+Your product requirements are documented and ready for implementation.
-1. ✅ bmm-PRD.md - Strategic product requirements document
-2. ✅ bmm-epics.md - Tactical implementation roadmap with story breakdown
+**Created:**
+
+- **PRD.md** - Complete requirements adapted to {project_type} and {domain}
**Next Steps:**
-- **Next required:** {{next_workflow}} ({{next_agent}} agent)
-- **Optional:** Review PRD and epics with stakeholders, or run `create-design` if you have UI requirements
+1. **Epic Breakdown** (Required)
+ Run: `workflow create-epics-and-stories` to decompose requirements into implementable stories
-Check status anytime with: `workflow-status`
+2. **UX Design** (If UI exists)
+ Run: `workflow ux-design` for detailed user experience design
-Would you like to:
-
-1. Review/refine any section
-2. Proceed to next phase
-3. Exit and review documents
-
+3. **Architecture** (Recommended)
+ Run: `workflow create-architecture` for technical architecture decisions
+The magic of your product - {product_magic_summary} - is woven throughout the PRD and will guide all subsequent work.
+
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/prd-template.md b/src/modules/bmm/workflows/2-plan-workflows/prd/prd-template.md
index 3552f381..3e23607a 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/prd/prd-template.md
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/prd-template.md
@@ -1,62 +1,237 @@
-# {{project_name}} Product Requirements Document (PRD)
+# {{project_name}} - Product Requirements Document
**Author:** {{user_name}}
**Date:** {{date}}
-**Project Level:** {{project_level}}
-**Target Scale:** {{target_scale}}
+**Version:** 1.0
---
-## Goals and Background Context
+## Executive Summary
-### Goals
+{{vision_alignment}}
-{{goals}}
+### What Makes This Special
-### Background Context
-
-{{background_context}}
+{{product_magic_essence}}
---
-## Requirements
+## Project Classification
-### Functional Requirements
+**Technical Type:** {{project_type}}
+**Domain:** {{domain_type}}
+**Complexity:** {{complexity_level}}
-{{functional_requirements}}
+{{project_classification}}
-### Non-Functional Requirements
+{{#if domain_context_summary}}
-{{non_functional_requirements}}
+### Domain Context
+
+{{domain_context_summary}}
+{{/if}}
---
-## User Journeys
+## Success Criteria
-{{user_journeys}}
+{{success_criteria}}
+
+{{#if business_metrics}}
+
+### Business Metrics
+
+{{business_metrics}}
+{{/if}}
---
-## UX Design Principles
+## Product Scope
+
+### MVP - Minimum Viable Product
+
+{{mvp_scope}}
+
+### Growth Features (Post-MVP)
+
+{{growth_features}}
+
+### Vision (Future)
+
+{{vision_features}}
+
+---
+
+{{#if domain_considerations}}
+
+## Domain-Specific Requirements
+
+{{domain_considerations}}
+
+This section shapes all functional and non-functional requirements below.
+{{/if}}
+
+---
+
+{{#if innovation_patterns}}
+
+## Innovation & Novel Patterns
+
+{{innovation_patterns}}
+
+### Validation Approach
+
+{{validation_approach}}
+{{/if}}
+
+---
+
+{{#if project_type_requirements}}
+
+## {{project_type}} Specific Requirements
+
+{{project_type_requirements}}
+
+{{#if endpoint_specification}}
+
+### API Specification
+
+{{endpoint_specification}}
+{{/if}}
+
+{{#if authentication_model}}
+
+### Authentication & Authorization
+
+{{authentication_model}}
+{{/if}}
+
+{{#if platform_requirements}}
+
+### Platform Support
+
+{{platform_requirements}}
+{{/if}}
+
+{{#if device_features}}
+
+### Device Capabilities
+
+{{device_features}}
+{{/if}}
+
+{{#if tenant_model}}
+
+### Multi-Tenancy Architecture
+
+{{tenant_model}}
+{{/if}}
+
+{{#if permission_matrix}}
+
+### Permissions & Roles
+
+{{permission_matrix}}
+{{/if}}
+{{/if}}
+
+---
+
+{{#if ux_principles}}
+
+## User Experience Principles
{{ux_principles}}
----
+### Key Interactions
-## User Interface Design Goals
-
-{{ui_design_goals}}
+{{key_interactions}}
+{{/if}}
---
-## Epic List
+## Functional Requirements
-{{epic_list}}
-
-> **Note:** Detailed epic breakdown with full story specifications is available in [epics.md](./epics.md)
+{{functional_requirements_complete}}
---
-## Out of Scope
+## Non-Functional Requirements
-{{out_of_scope}}
+{{#if performance_requirements}}
+
+### Performance
+
+{{performance_requirements}}
+{{/if}}
+
+{{#if security_requirements}}
+
+### Security
+
+{{security_requirements}}
+{{/if}}
+
+{{#if scalability_requirements}}
+
+### Scalability
+
+{{scalability_requirements}}
+{{/if}}
+
+{{#if accessibility_requirements}}
+
+### Accessibility
+
+{{accessibility_requirements}}
+{{/if}}
+
+{{#if integration_requirements}}
+
+### Integration
+
+{{integration_requirements}}
+{{/if}}
+
+{{#if no_nfrs}}
+_No specific non-functional requirements identified for this project type._
+{{/if}}
+
+---
+
+## Implementation Planning
+
+### Epic Breakdown Required
+
+Requirements must be decomposed into epics and bite-sized stories (200k context limit).
+
+**Next Step:** Run `workflow epics-stories` to create the implementation breakdown.
+
+---
+
+## References
+
+{{#if product_brief_path}}
+
+- Product Brief: {{product_brief_path}}
+ {{/if}}
+ {{#if domain_brief_path}}
+- Domain Brief: {{domain_brief_path}}
+ {{/if}}
+ {{#if research_documents}}
+- Research: {{research_documents}}
+ {{/if}}
+
+---
+
+## Next Steps
+
+1. **Epic & Story Breakdown** - Run: `workflow epics-stories`
+2. **UX Design** (if UI) - Run: `workflow ux-design`
+3. **Architecture** - Run: `workflow create-architecture`
+
+---
+
+_This PRD captures the essence of {{project_name}} - {{product_magic_summary}}_
+
+_Created through collaborative discovery between {{user_name}} and AI facilitator._
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/project-types.csv b/src/modules/bmm/workflows/2-plan-workflows/prd/project-types.csv
new file mode 100644
index 00000000..8472fb9b
--- /dev/null
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/project-types.csv
@@ -0,0 +1,11 @@
+project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
+api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
+mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
+saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
+developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
+cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
+web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
+game,"game,player,gameplay,level,character","REDIRECT TO GAME WORKFLOWS","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
+desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
+iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
+blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
\ No newline at end of file
diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml b/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml
index 3bd5fe93..66b994f7 100644
--- a/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml
+++ b/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml
@@ -19,14 +19,10 @@ instructions: "{installed_path}/instructions.md"
# Templates
prd_template: "{installed_path}/prd-template.md"
-epics_template: "{installed_path}/epics-template.md"
# Output files
-status_file: "{output_folder}/bmm-workflow-status.md"
+status_file: "{output_folder}/bmm-workflow-status.yaml"
default_output_file: "{output_folder}/PRD.md"
-epics_output_file: "{output_folder}/epics.md"
-technical_decisions_file: "{output_folder}/technical-decisions.md"
-technical_decisions_template: "{project-root}/bmad/bmm/_module-installer/assets/technical-decisions.md"
# Recommended input documents
recommended_inputs:
@@ -40,7 +36,15 @@ web_bundle:
description: "Unified PRD workflow for project levels 2-4. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Level 0-1 use tech-spec workflow."
author: "BMad"
instructions: "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
+ validation: "bmad/bmm/workflows/2-plan-workflows/prd/checklist.md"
web_bundle_files:
- "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
- "bmad/bmm/workflows/2-plan-workflows/prd/prd-template.md"
- - "bmad/bmm/workflows/2-plan-workflows/prd/epics-template.md"
+ - "bmad/bmm/workflows/2-plan-workflows/prd/project-types.csv"
+ - "bmad/bmm/workflows/2-plan-workflows/prd/domain-complexity.csv"
+ - "bmad/bmm/workflows/2-plan-workflows/prd/checklist.md"
+ - "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
+ - "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
+ - "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
+ child_workflows:
+ - create-epics-and-stories: "bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
diff --git a/src/modules/bmm/workflows/3-solutioning/architecture/architecture-template.md b/src/modules/bmm/workflows/3-solutioning/architecture/architecture-template.md
index ee97859a..5012469d 100644
--- a/src/modules/bmm/workflows/3-solutioning/architecture/architecture-template.md
+++ b/src/modules/bmm/workflows/3-solutioning/architecture/architecture-template.md
@@ -1,4 +1,4 @@
-# Decision Architecture
+# Architecture
## Executive Summary
diff --git a/src/modules/bmm/workflows/3-solutioning/architecture/instructions.md b/src/modules/bmm/workflows/3-solutioning/architecture/instructions.md
index bc75782f..314de829 100644
--- a/src/modules/bmm/workflows/3-solutioning/architecture/instructions.md
+++ b/src/modules/bmm/workflows/3-solutioning/architecture/instructions.md
@@ -35,7 +35,7 @@
**Note: Level {{project_level}} Project**
-Decision Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
+The Detailed Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
For Level {{project_level}}, we'll keep the architecture appropriately scoped.
@@ -70,11 +70,11 @@ For Level {{project_level}}, we'll keep the architecture appropriately scoped.
Decision Architecture works from your Product Requirements Document (PRD).
-Looking for: bmm-PRD.md, PRD.md, or product-requirements.md in {output_folder}
+Looking for: _PRD_, PRD.md, or prd/index.md + files in {output_folder}
Please run the PRD workflow first to define your requirements.
-Run: `workflow prd`
+Architect: `create-prd`
Exit workflow - PRD required
@@ -82,7 +82,7 @@ Run: `workflow prd`
- Load the PRD using fuzzy matching: {prd_file}
+ Load the PRD using fuzzy matching: {prd_file}, if the PRD is mulitple files in a folder, load the index file and all files associated with the PRD
Load epics file using fuzzy matching: {epics_file}
Check for UX specification using fuzzy matching:
@@ -96,7 +96,7 @@ Run: `workflow prd`
Extract and understand from PRD: - Functional Requirements (what it must do) - Non-Functional Requirements (performance, security, compliance, etc.) - Epic structure and user stories - Acceptance criteria - Any technical constraints mentioned
-Count and assess project scale: - Number of epics: {{epic_count}} - Number of stories: {{story_count}} - Complexity indicators (real-time, multi-tenant, regulated, etc.) - UX complexity level (if UX spec exists)
+Count and assess project scale: - Number of epics: {{epic_count}} - Number of stories: {{story_count}} - Complexity indicators (real-time, multi-tenant, regulated, etc.) - UX complexity level (if UX spec exists) - Novel features
Reflect understanding back to {user_name}:
@@ -135,8 +135,8 @@ I see {{epic_count}} epics with {{story_count}} total stories.
-Search for relevant starter templates:
-{{primary_technology}} starter template CLI create command latest 2024
+Search for relevant starter templates with websearch, examples:
+{{primary_technology}} starter template CLI create command latest {date}
{{primary_technology}} boilerplate generator latest options
@@ -206,7 +206,7 @@ I see {{epic_count}} epics with {{story_count}} total stories.
Note: No standard starter template found for this project type.
- Will need to make all architectural decisions explicitly.
+ We will make all architectural decisions explicitly.
starter_template_decision
@@ -285,34 +285,39 @@ Let's work through the remaining {{remaining_count}} decisions."
Present the decision based on mode:
"{{Decision_Category}}: {{Specific_Decision}}
-Options: {{concise_option_list_with_tradeoffs}}
-Recommendation: {{recommendation}} for {{reason}}"
-
-
- "Next decision: {{Human_Friendly_Category}}
+ Options: {{concise_option_list_with_tradeoffs}}
- We need to choose {{Specific_Decision}}.
+ Recommendation: {{recommendation}} for {{reason}}"
- Common options:
- {{option_list_with_brief_explanations}}
+
- For your project, {{recommendation}} would work well because {{reason}}."
-
+
+ "Next decision: {{Human_Friendly_Category}}
-
- "Let's talk about {{Human_Friendly_Category}}.
+ We need to choose {{Specific_Decision}}.
- {{Educational_Context_About_Why_This_Matters}}
+ Common options:
+ {{option_list_with_brief_explanations}}
- Think of it like {{real_world_analogy}}.
+ For your project, {{recommendation}} would work well because {{reason}}."
- Your main options:
- {{friendly_options_with_pros_cons}}
+
- My suggestion: {{recommendation}}
- This is good for you because {{beginner_friendly_reason}}."
-
+
+ "Let's talk about {{Human_Friendly_Category}}.
+
+ {{Educational_Context_About_Why_This_Matters}}
+
+ Think of it like {{real_world_analogy}}.
+
+ Your main options:
+ {{friendly_options_with_pros_cons}}
+
+ My suggestion: {{recommendation}}
+ This is good for you because {{beginner_friendly_reason}}."
+
+
@@ -365,11 +370,7 @@ Provided by Starter: {{yes_if_from_starter}}
- Explain why these matter:
- "These are rules that EVERY part of your app must follow.
- If we don't decide now, each AI agent will do it differently,
- and your app won't work properly when the pieces come together."
-
+ Explain why these matter why its critical to go through and decide these things now.
cross_cutting_decisions
diff --git a/src/modules/bmm/workflows/3-solutioning/architecture/workflow.yaml b/src/modules/bmm/workflows/3-solutioning/architecture/workflow.yaml
index 1b2fbce9..cce09463 100644
--- a/src/modules/bmm/workflows/3-solutioning/architecture/workflow.yaml
+++ b/src/modules/bmm/workflows/3-solutioning/architecture/workflow.yaml
@@ -19,7 +19,7 @@ recommended_inputs:
- ux_spec: "UX specification with interface designs and interaction patterns (optional)"
# Input file references (fuzzy matched from output folder)
-prd_file: "{output_folder}/bmm-PRD.md or PRD.md or product-requirements.md"
+prd_file: "{output_folder}/*PRD*, PRD.md, or prd/index.md + files"
epics_file: "{output_folder}/bmm-epics.md or epics.md or user-stories.md"
ux_spec_file: "{output_folder}/ux-spec.md or ux-specification.md or user-experience.md"