bmad-method 6.0.0-alpha.8 → 6.0.1

package/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md

@@ -1,169 +0,0 @@
-# Epic and Story Decomposition - Intent-Based Implementation Planning
-
-<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
-<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>This workflow transforms requirements into BITE-SIZED STORIES for development agents</critical>
-<critical>EVERY story must be completable by a single dev agent in one focused session</critical>
-<critical>Communicate all responses in {communication_language} and adapt to {user_skill_level}</critical>
-<critical>Generate all documents in {document_output_language}</critical>
-<critical>LIVING DOCUMENT: Write to epics.md continuously as you work - never wait until the end</critical>
-<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
-
-<workflow>
-
-<step n="1" goal="Load PRD and extract requirements">
-<action>Welcome {user_name} to epic and story planning
-
-Load required documents (fuzzy match, handle both whole and sharded):
-
-- PRD.md (required)
-- domain-brief.md (if exists)
-- product-brief.md (if exists)
-
-Extract from PRD:
-
-- All functional requirements
-- Non-functional requirements
-- Domain considerations and compliance needs
-- Project type and complexity
-- MVP vs growth vs vision scope boundaries
-
-Understand the context:
-
-- What makes this product special (the magic)
-- Technical constraints
-- User types and their goals
-- Success criteria</action>
-  </step>
-
-<step n="2" goal="Propose epic structure from natural groupings">
-<action>Analyze requirements and identify natural epic boundaries
-
-INTENT: Find organic groupings that make sense for THIS product
-
-Look for natural patterns:
-
-- Features that work together cohesively
-- User journeys that connect
-- Business capabilities that cluster
-- Domain requirements that relate (compliance, validation, security)
-- Technical systems that should be built together
-
-Name epics based on VALUE, not technical layers:
-
-- Good: "User Onboarding", "Content Discovery", "Compliance Framework"
-- Avoid: "Database Layer", "API Endpoints", "Frontend"
-
-Each epic should:
-
-- Have clear business goal and user value
-- Be independently valuable
-- Contain 3-8 related capabilities
-- Be deliverable in cohesive phase
-
-For greenfield projects:
-
-- First epic MUST establish foundation (project setup, core infrastructure, deployment pipeline)
-- Foundation enables all subsequent work
-
-For complex domains:
-
-- Consider dedicated compliance/regulatory epics
-- Group validation and safety requirements logically
-- Note expertise requirements
-
-Present proposed epic structure showing:
-
-- Epic titles with clear value statements
-- High-level scope of each epic
-- Suggested sequencing
-- Why this grouping makes sense</action>
-
-<template-output>epics_summary</template-output>
-<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
-</step>
-
-<step n="3" goal="Decompose each epic into bite-sized stories" repeat="for-each-epic">
-<action>Break down Epic {{N}} into small, implementable stories
-
-INTENT: Create stories sized for single dev agent completion
-
-For each epic, generate:
-
-- Epic title as `epic_title_{{N}}`
-- Epic goal/value as `epic_goal_{{N}}`
-- All stories as repeated pattern `story_title_{{N}}_{{M}}` for each story M
-
-CRITICAL for Epic 1 (Foundation):
-
-- Story 1.1 MUST be project setup/infrastructure initialization
-- Sets up: repo structure, build system, deployment pipeline basics, core dependencies
-- Creates foundation for all subsequent stories
-- Note: Architecture workflow will flesh out technical details
-
-Each story should follow BDD-style acceptance criteria:
-
-**Story Pattern:**
-As a [user type],
-I want [specific capability],
-So that [clear value/benefit].
-
-**Acceptance Criteria using BDD:**
-Given [precondition or initial state]
-When [action or trigger]
-Then [expected outcome]
-
-And [additional criteria as needed]
-
-**Prerequisites:** Only previous stories (never forward dependencies)
-
-**Technical Notes:** Implementation guidance, affected components, compliance requirements
-
-Ensure stories are:
-
-- Vertically sliced (deliver complete functionality, not just one layer)
-- Sequentially ordered (logical progression, no forward dependencies)
-- Independently valuable when possible
-- Small enough for single-session completion
-- Clear enough for autonomous implementation
-
-For each story in epic {{N}}, output variables following this pattern:
-
-- story*title*{{N}}_1, story_title_{{N}}\_2, etc.
-- Each containing: user story, BDD acceptance criteria, prerequisites, technical notes</action>
-
-<template-output>epic*title*{{N}}</template-output>
-<template-output>epic*goal*{{N}}</template-output>
-
-<action>For each story M in epic {{N}}, generate story content</action>
-<template-output>story*title*{{N}}\_{{M}}</template-output>
-
-<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
-</step>
-
-<step n="4" goal="Review and finalize epic breakdown">
-<action>Review the complete epic breakdown for quality and completeness
-
-Validate:
-
-- All functional requirements from PRD are covered by stories
-- Epic 1 establishes proper foundation
-- All stories are vertically sliced
-- No forward dependencies exist
-- Story sizing is appropriate for single-session completion
-- BDD acceptance criteria are clear and testable
-- Domain/compliance requirements are properly distributed
-- Sequencing enables incremental value delivery
-
-Confirm with {user_name}:
-
-- Epic structure makes sense
-- Story breakdown is actionable
-- Dependencies are clear
-- BDD format provides clarity
-- Ready for architecture and implementation phases</action>
-
-<template-output>epic_breakdown_summary</template-output>
-</step>
-
-</workflow>

package/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml

@@ -1,55 +0,0 @@
-# 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_folder}/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
-
-# Input requirements
-recommended_inputs:
-  - prd: "Product Requirements Document with FRs and NFRs"
-  - product_brief: "Product Brief with vision and goals (optional)"
-  - domain_brief: "Domain-specific requirements and context (optional)"
-
-# Smart input file references - handles both whole docs and sharded docs
-# Priority: Whole document first, then sharded version
-input_file_patterns:
-  prd:
-    whole: "{output_folder}/*prd*.md"
-    sharded: "{output_folder}/*prd*/index.md"
-
-  product_brief:
-    whole: "{output_folder}/*product*brief*.md"
-    sharded: "{output_folder}/*product*brief*/index.md"
-
-  domain_brief:
-    whole: "{output_folder}/*domain*brief*.md"
-    sharded: "{output_folder}/*domain*brief*/index.md"
-
-# Module path and component files
-installed_path: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories"
-instructions: "{installed_path}/instructions.md"
-template: "{installed_path}/epics-template.md"
-
-# Output configuration
-default_output_file: "{output_folder}/epics.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_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
-  template: "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
-  web_bundle_files:
-    - "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
-    - "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"

package/src/modules/bmm/workflows/2-plan-workflows/prd/domain-complexity.csv

@@ -1,13 +0,0 @@
-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"

package/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md

@@ -1,408 +0,0 @@
-# PRD Workflow - Intent-Driven Product Planning
-
-<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
-<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
-<critical>This workflow uses INTENT-DRIVEN PLANNING - adapt organically to product type and context</critical>
-<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
-<critical>Generate all documents in {document_output_language}</critical>
-<critical>LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end</critical>
-<critical>GUIDING PRINCIPLE: Find and weave the product's magic throughout - what makes it special should inspire every section</critical>
-<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
-
-<workflow>
-
-<step n="0" goal="Validate workflow readiness" tag="workflow-status">
-<action>Check if {status_file} exists</action>
-
-<action if="status file not found">Set standalone_mode = true</action>
-
-<check if="status file found">
-  <action>Load the FULL file: {status_file}</action>
-  <action>Parse workflow_status section</action>
-  <action>Check status of "prd" workflow</action>
-  <action>Get project_track from YAML metadata</action>
-  <action>Find first non-completed workflow (next expected workflow)</action>
-
-  <check if="project_track is Quick Flow">
-    <output>**Quick Flow Track - Redirecting**
-
-Quick Flow projects use tech-spec workflow for implementation-focused planning.
-PRD is for BMad Method and Enterprise Method tracks that need comprehensive requirements.</output>
-<action>Exit and suggest tech-spec workflow</action>
-</check>
-
-  <check if="prd status is file path (already completed)">
-    <output>⚠️ PRD already completed: {{prd status}}</output>
-    <ask>Re-running will overwrite the existing PRD. Continue? (y/n)</ask>
-    <check if="n">
-      <output>Exiting. Use workflow-status to see your next step.</output>
-      <action>Exit workflow</action>
-    </check>
-  </check>
-
-<action>Set standalone_mode = false</action>
-</check>
-</step>
-
-<step n="1" goal="Discovery - Project, Domain, and Vision">
-<action>Welcome {user_name} and begin comprehensive discovery, and then start to GATHER ALL CONTEXT:
-1. Check workflow-status.yaml for project_context (if exists)
-2. Look for existing documents (Product Brief, Domain Brief, research)
-3. Detect project type AND domain complexity
-
-Load references:
-{installed_path}/project-types.csv
-{installed_path}/domain-complexity.csv
-
-Through natural conversation:
-"Tell me about what you want to build - what problem does it solve and for whom?"
-
-DUAL DETECTION:
-Project type signals: API, mobile, web, CLI, SDK, SaaS
-Domain complexity signals: medical, finance, government, education, aerospace
-
-SPECIAL ROUTING:
-If game detected → Inform user that game development requires the BMGD module (BMad Game Development)
-If complex domain detected → Offer domain research options:
-A) Run domain-research workflow (thorough)
-B) Quick web search (basic)
-C) User provides context
-D) Continue with general knowledge
-
-CAPTURE THE MAGIC EARLY with a few questions such as for example: "What excites you most about this product?", "What would make users love this?", "What's the moment that will make people go 'wow'?"
-
-This excitement becomes the thread woven throughout the PRD.</action>
-
-<template-output>vision_alignment</template-output>
-<template-output>project_classification</template-output>
-<template-output>project_type</template-output>
-<template-output>domain_type</template-output>
-<template-output>complexity_level</template-output>
-<check if="complex domain">
-<template-output>domain_context_summary</template-output>
-</check>
-<template-output>product_magic_essence</template-output>
-<template-output>product_brief_path</template-output>
-<template-output>domain_brief_path</template-output>
-<template-output>research_documents</template-output>
-</step>
-
-<step n="2" goal="Success Definition">
-<action>Define what winning looks like for THIS specific product
-
-INTENT: Meaningful success criteria, not generic metrics
-
-Adapt to context:
-
-- Consumer: User love, engagement, retention
-- B2B: ROI, efficiency, adoption
-- Developer tools: Developer experience, community
-- Regulated: Compliance, safety, validation
-
-Make it specific:
-
-- NOT: "10,000 users"
-- BUT: "100 power users who rely on it daily"
-
-- NOT: "99.9% uptime"
-- BUT: "Zero data loss during critical operations"
-
-Weave in the magic:
-
-- "Success means users experience [that special moment] and [desired outcome]"</action>
-
-<template-output>success_criteria</template-output>
-<check if="business focus">
-<template-output>business_metrics</template-output>
-</check>
-<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
-</step>
-
-<step n="3" goal="Scope Definition">
-<action>Smart scope negotiation - find the sweet spot
-
-The Scoping Game:
-
-1. "What must work for this to be useful?" → MVP
-2. "What makes it competitive?" → Growth
-3. "What's the dream version?" → Vision
-
-Challenge scope creep conversationally:
-
-- "Could that wait until after launch?"
-- "Is that essential for proving the concept?"
-
-For complex domains:
-
-- Include compliance minimums in MVP
-- Note regulatory gates between phases</action>
-
-<template-output>mvp_scope</template-output>
-<template-output>growth_features</template-output>
-<template-output>vision_features</template-output>
-<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
-</step>
-
-<step n="4" goal="Domain-Specific Exploration" optional="true">
-<action>Only if complex domain detected or domain-brief exists
-
-Synthesize domain requirements that will shape everything:
-
-- Regulatory requirements
-- Compliance needs
-- Industry standards
-- Safety/risk factors
-- Required validations
-- Special expertise needed
-
-These inform:
-
-- What features are mandatory
-- What NFRs are critical
-- How to sequence development
-- What validation is required</action>
-
-<check if="complex domain">
-  <template-output>domain_considerations</template-output>
-</check>
-</step>
-
-<step n="5" goal="Innovation Discovery" optional="true">
-<action>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?
-
-<WebSearch if="novel">{concept} innovations {date}</WebSearch></action>
-
-<check if="innovation detected">
-  <template-output>innovation_patterns</template-output>
-  <template-output>validation_approach</template-output>
-</check>
-</step>
-
-<step n="6" goal="Project-Specific Deep Dive">
-<action>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]?"</action>
-
-<template-output>project_type_requirements</template-output>
-
-<!-- Dynamic sections based on project type -->
-<check if="API/Backend project">
-  <template-output>endpoint_specification</template-output>
-  <template-output>authentication_model</template-output>
-</check>
-
-<check if="Mobile project">
-  <template-output>platform_requirements</template-output>
-  <template-output>device_features</template-output>
-</check>
-
-<check if="SaaS B2B project">
-  <template-output>tenant_model</template-output>
-  <template-output>permission_matrix</template-output>
-</check>
-</step>
-
-<step n="7" goal="UX Principles" if="project has UI or UX">
-  <action>Only if product has a UI
-
-Light touch on UX - not full design:
-
-- Visual personality
-- Key interaction patterns
-- Critical user flows
-
-"How should this feel to use?"
-"What's the vibe - professional, playful, minimal?"
-
-Connect to the magic:
-"The UI should reinforce [the special moment] through [design approach]"</action>
-
-  <check if="has UI">
-    <template-output>ux_principles</template-output>
-    <template-output>key_interactions</template-output>
-  </check>
-</step>
-
-<step n="8" goal="Functional Requirements Synthesis">
-<action>Transform everything discovered into clear functional requirements
-
-Pull together:
-
-- Core features from scope
-- Domain-mandated features
-- Project-type specific needs
-- Innovation requirements
-
-Organize by capability, not technology:
-
-- User Management (not "auth system")
-- Content Discovery (not "search algorithm")
-- Team Collaboration (not "websockets")
-
-Each requirement should:
-
-- Be specific and measurable
-- Connect to user value
-- Include acceptance criteria
-- Note domain constraints
-
-The magic thread:
-Highlight which requirements deliver the special experience</action>
-
-<template-output>functional_requirements_complete</template-output>
-<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
-</step>
-
-<step n="9" goal="Non-Functional Requirements Discovery">
-<action>Only document NFRs that matter for THIS product
-
-Performance: Only if user-facing impact
-Security: Only if handling sensitive data
-Scale: Only if growth expected
-Accessibility: Only if broad audience
-Integration: Only if connecting systems
-
-For each NFR:
-
-- Why it matters for THIS product
-- Specific measurable criteria
-- Domain-driven requirements
-
-Skip categories that don't apply!</action>
-
-<!-- Only output sections that were discussed -->
-<check if="performance matters">
-  <template-output>performance_requirements</template-output>
-</check>
-<check if="security matters">
-  <template-output>security_requirements</template-output>
-</check>
-<check if="scale matters">
-  <template-output>scalability_requirements</template-output>
-</check>
-<check if="accessibility matters">
-  <template-output>accessibility_requirements</template-output>
-</check>
-<check if="integration matters">
-  <template-output>integration_requirements</template-output>
-</check>
-</step>
-
-<step n="10" goal="Review PRD and transition to epics">
-<action>Review the PRD we've built together
-
-"Let's review what we've captured:
-
-- Vision: [summary]
-- Success: [key metrics]
-- Scope: [MVP highlights]
-- Requirements: [count] functional, [count] non-functional
-- Special considerations: [domain/innovation]
-
-Does this capture your product vision?"</action>
-
-<template-output>prd_summary</template-output>
-<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/adv-elicit.xml</invoke-task>
-
-<action>After PRD review and refinement complete:
-
-"Excellent! Now we need to break these requirements into implementable epics and stories.
-
-For the epic breakdown, you have two options:
-
-1. Start a new session focused on epics (recommended for complex projects)
-2. Continue here (I'll transform requirements into epics now)
-
-Which would you prefer?"
-
-If new session:
-"To start epic planning in a new session:
-
-1. Save your work here
-2. Start fresh and run: workflow epics-stories
-3. It will load your PRD and create the epic breakdown
-
-This keeps each session focused and manageable."
-
-If continue:
-"Let's continue with epic breakdown here..."
-[Proceed with epics-stories subworkflow]
-Set project_track based on workflow status (BMad Method or Enterprise Method)
-Generate epic_details for the epics breakdown document</action>
-
-<template-output>project_track</template-output>
-<template-output>epic_details</template-output>
-</step>
-
-<step n="11" goal="Complete PRD and suggest next steps">
-<template-output>product_magic_summary</template-output>
-
-<check if="standalone_mode != true">
-  <action>Load the FULL file: {status_file}</action>
-  <action>Update workflow_status["prd"] = "{default_output_file}"</action>
-  <action>Save file, preserving ALL comments and structure</action>
-</check>
-
-<output>**✅ PRD Complete, {user_name}!**
-
-Your product requirements are documented and ready for implementation.
-
-**Created:**
-
-- **PRD.md** - Complete requirements adapted to {project_type} and {domain}
-
-**Next Steps:**
-
-1. **Epic Breakdown** (Required)
-   Run: `workflow create-epics-and-stories` to decompose requirements into implementable stories
-
-2. **UX Design** (If UI exists)
-   Run: `workflow ux-design` for detailed user experience design
-
-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.
-</output>
-</step>
-
-</workflow>