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 + + + +**✅ Domain Research Complete, {user_name}!** + +We've explored the {domain} aspects of your project together and documented critical requirements. + +**Created:** + +- **domain-brief.md** - Complete domain analysis with requirements and recommendations + +**Key Findings:** + +- Primary domain: {domain} +- Complexity level: {complexity} +- Critical requirements: {count} identified +- Risks identified: {count} with mitigation strategies + +**Next Steps:** + +1. Return to PRD workflow with this domain context +2. Domain requirements will shape your functional requirements +3. Reference domain-brief.md for detailed requirements + +**Remember:** +{most_important_finding} + +The domain research will ensure your PRD captures not just what to build, but HOW to build it correctly for {domain}. + + + + 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 - - No workflow status file found. Product Brief is optional - you can continue without status tracking. - 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) - Note: Product Brief is most valuable for Level 2+ projects. Your project is Level {{project_level}}. - You may want to skip directly to technical planning instead. - + **Note: Level {{project_level}} Project** + +Product Brief is most valuable for Level 2+ projects, but can help clarify vision for any project. + ⚠️ Product Brief already completed: {{product-brief status}} @@ -38,7 +37,7 @@ - + ⚠️ Next expected workflow: {{next_workflow}}. Product Brief is out of sequence. 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 **✅ Product Brief Complete, {user_name}!** -**Brief Document:** +Your product vision has been captured in a document that reflects what matters most for your {{context_type}} project. -- Product brief saved to {output_folder}/bmm-product-brief-{{project_name}}-{{date}}.md +**Document saved:** {output_folder}/bmm-product-brief-{{project_name}}-{{date}}.md {{#if standalone_mode != true}} -**Status Updated:** +**What's next:** {{next_workflow}} ({{next_agent}} agent) -- Progress tracking updated: product-brief marked complete -- Next workflow: {{next_workflow}} - {{else}} - **Note:** Running in standalone mode (no progress tracking) - {{/if}} - -**Next Steps:** - -{{#if standalone_mode != true}} - -- **Next workflow:** {{next_workflow}} ({{next_agent}} agent) -- **Optional:** Gather additional stakeholder input or run research workflows before proceeding - -Check status anytime with: `workflow-status` +The next phase will take your brief and create the detailed planning artifacts needed for implementation. {{else}} -Since no workflow is in progress: +**Next steps:** -- Refer to the BMM workflow guide if unsure what to do next -- Or run `workflow-init` to create a workflow path and get guided next steps +- Run `workflow-init` to set up guided workflow tracking +- Or proceed directly to the PRD workflow if you know your path {{/if}} - - + +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) + +**✅ Epic Decomposition Complete, {user_name}!** + +Your requirements are now organized into **{epic_count} epics** with **{story_count} bite-sized stories**. + +**Created:** + +- **epics.md** - Complete epic breakdown with implementable stories + +**Key Stats:** + +- Average story size: Fits in 200k context +- Parallel stories: {parallel_count} can run simultaneously +- Sequential chains: {sequential_count} dependency chains +- Estimated velocity: {velocity_estimate} + +**Next Steps:** + +1. Review epics.md for the complete breakdown +2. Start Phase 1 implementation with parallel stories +3. Use story IDs for tracking progress + +Each story is crafted for a single dev agent to complete autonomously. No monoliths, no confusion, just clear implementation paths. + +Ready to begin development with any story marked "can start immediately"! + + + 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 - - No workflow status file found. PRD workflow can run standalone or as part of BMM workflow path. - **Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing. - 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) - **Incorrect Workflow for Level {{project_level}}** + **Level {{project_level}} Project - Redirecting** -PRD is for Level 2-4 projects. Level 0-1 should use tech-spec directly. - -**Correct workflow:** `tech-spec` (Architect agent) - -Exit and redirect to tech-spec +Level 0-1 projects use tech-spec workflow for simpler planning. +PRD is for Level 2-4 projects that need comprehensive requirements. +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"