diff --git a/bmad/bmb/workflows/audit-workflow/instructions.md b/bmad/bmb/workflows/audit-workflow/instructions.md index 4fa293fb..467457a9 100644 --- a/bmad/bmb/workflows/audit-workflow/instructions.md +++ b/bmad/bmb/workflows/audit-workflow/instructions.md @@ -161,7 +161,7 @@ Do something ``` - Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|goto|step|elicit-required)> within text content + Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|invoke-task|goto|step)> within text content Record any instances of nested tag references with line numbers Scan instructions.md for conditional execution antipattern: self-closing check tags Detect pattern: `<check>.*</check>` on single line (self-closing check) diff --git a/bmad/core/tasks/workflow.xml b/bmad/core/tasks/workflow.xml index 76e0c81d..9edc0c4d 100644 --- a/bmad/core/tasks/workflow.xml +++ b/bmad/core/tasks/workflow.xml @@ -13,8 +13,7 @@ Steps execute in exact numerical order (1, 2, 3...) Optional steps: Ask user unless #yolo mode active Template-output tags: Save content → Show user → Get approval before continuing - Elicit tags: Execute immediately unless #yolo mode (which skips ALL elicitation) - User must approve each major section before continuing UNLESS #yolo mode active + User must approve each major section before continuing UNLESS #yolo mode active @@ -75,14 +74,6 @@ Display generated content Continue [c] or Edit [e]? WAIT for response - - - YOU MUST READ the file at {project-root}/bmad/core/tasks/adv-elicit.xml using Read tool BEFORE presenting - any elicitation menu - Load and run task {project-root}/bmad/core/tasks/adv-elicit.xml with current context - Show elicitation menu 5 relevant options (list 1-5 options, Continue [c] or Reshuffle [r]) - HALT and WAIT for user selection - @@ -123,7 +114,6 @@ template-output - Save content checkpoint - elicit-required - Trigger enhancement critical - Cannot be skipped example - Show example output diff --git a/src/core/tasks/workflow.xml b/src/core/tasks/workflow.xml index 76e0c81d..9edc0c4d 100644 --- a/src/core/tasks/workflow.xml +++ b/src/core/tasks/workflow.xml @@ -13,8 +13,7 @@ Steps execute in exact numerical order (1, 2, 3...) Optional steps: Ask user unless #yolo mode active Template-output tags: Save content → Show user → Get approval before continuing - Elicit tags: Execute immediately unless #yolo mode (which skips ALL elicitation) - User must approve each major section before continuing UNLESS #yolo mode active + User must approve each major section before continuing UNLESS #yolo mode active @@ -75,14 +74,6 @@ Display generated content Continue [c] or Edit [e]? WAIT for response - - - YOU MUST READ the file at {project-root}/bmad/core/tasks/adv-elicit.xml using Read tool BEFORE presenting - any elicitation menu - Load and run task {project-root}/bmad/core/tasks/adv-elicit.xml with current context - Show elicitation menu 5 relevant options (list 1-5 options, Continue [c] or Reshuffle [r]) - HALT and WAIT for user selection - @@ -123,7 +114,6 @@ template-output - Save content checkpoint - elicit-required - Trigger enhancement critical - Cannot be skipped example - Show example output diff --git a/src/modules/bmb/workflows/audit-workflow/instructions.md b/src/modules/bmb/workflows/audit-workflow/instructions.md index 4fa293fb..4a29b15d 100644 --- a/src/modules/bmb/workflows/audit-workflow/instructions.md +++ b/src/modules/bmb/workflows/audit-workflow/instructions.md @@ -161,7 +161,7 @@ Do something ``` - Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|goto|step|elicit-required)> within text content + Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|invoke-task|goto|step)> within text content Record any instances of nested tag references with line numbers Scan instructions.md for conditional execution antipattern: self-closing check tags Detect pattern: `<check>.*</check>` on single line (self-closing check) diff --git a/src/modules/bmm/workflows/2-plan-workflows/create-ux-design/instructions.md b/src/modules/bmm/workflows/2-plan-workflows/create-ux-design/instructions.md index ebfbc74a..f99d8fe5 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/create-ux-design/instructions.md +++ b/src/modules/bmm/workflows/2-plan-workflows/create-ux-design/instructions.md @@ -9,26 +9,8 @@ Communicate all responses in {communication_language} and tailor to {user_skill_level} Generate all documents in {document_output_language} SAVE PROGRESS after each major step - use tags throughout - DOCUMENT OUTPUT: Professional, specific, actionable UX design decisions WITH RATIONALE. User skill level ({user_skill_level}) affects conversation style ONLY, not document content. - -## 📚 Input Document Discovery - -This workflow requires: PRD or product brief, and may reference epics/stories, brainstorming documents, or brownfield project documentation. - -**Discovery Process** (execute for each referenced document): - -1. **Search for whole document first** - Use fuzzy file matching to find the complete document -2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md` -3. **If sharded version found**: - - Read `index.md` to understand the document structure - - Read ALL section files listed in the index - - Treat the combined content as if it were a single document -4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md` - -**Priority**: If both whole and sharded versions exist, use the whole document. - -**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions. +Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically Check if {output_folder}/bmm-workflow-status.yaml exists 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 cce5c539..42f84910 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/prd/checklist.md +++ b/src/modules/bmm/workflows/2-plan-workflows/prd/checklist.md @@ -234,21 +234,22 @@ - [ ] Dependencies on external systems documented - [ ] Data requirements specified -### Level-Appropriate Detail +### Track-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:** +**If BMad Method:** - [ ] PRD supports full architecture workflow - [ ] Epic structure supports phased delivery -- [ ] Scope appropriate for team-based development +- [ ] Scope appropriate for product/platform development - [ ] Clear value delivery through epic sequence +**If Enterprise Method:** + +- [ ] PRD addresses enterprise requirements (security, compliance, multi-tenancy) +- [ ] Epic structure supports extended planning phases +- [ ] Scope includes security, devops, and test strategy considerations +- [ ] Clear value delivery with enterprise gates + --- ## 10. Quality and Polish diff --git a/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md b/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md index 09faecd1..bc05342b 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md +++ b/src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md @@ -9,55 +9,44 @@ ## Overview -This document provides the detailed epic breakdown for {{project_name}}, expanding on the high-level epic list in the [PRD](./PRD.md). +This document provides the complete epic and story breakdown for {{project_name}}, decomposing the requirements from the [PRD](./PRD.md) into implementable stories. -Each epic includes: - -- Expanded goal and value proposition -- Complete story breakdown with user stories -- Acceptance criteria for each story -- Story sequencing and dependencies - -**Epic Sequencing Principles:** - -- Epic 1 establishes foundational infrastructure and initial functionality -- Subsequent epics build progressively, each delivering significant end-to-end value -- Stories within epics are vertically sliced and sequentially ordered -- No forward dependencies - each story builds only on previous work +{{epics_summary}} --- -{{epic_details}} + ---- +## Epic {{N}}: {{epic_title_N}} -## Story Guidelines Reference +{{epic_goal_N}} -**Story Format:** + -``` -**Story [EPIC.N]: [Story Title]** +### Story {{N}}.{{M}}: {{story_title_N_M}} -As a [user type], -I want [goal/desire], -So that [benefit/value]. +As a {{user_type}}, +I want {{capability}}, +So that {{value_benefit}}. **Acceptance Criteria:** -1. [Specific testable criterion] -2. [Another specific criterion] -3. [etc.] -**Prerequisites:** [Dependencies on previous stories, if any] -``` +**Given** {{precondition}} +**When** {{action}} +**Then** {{expected_outcome}} -**Story Requirements:** +**And** {{additional_criteria}} -- **Vertical slices** - Complete, testable functionality delivery -- **Sequential ordering** - Logical progression within epic -- **No forward dependencies** - Only depend on previous work -- **AI-agent sized** - Completable in 2-4 hour focused session -- **Value-focused** - Integrate technical enablers into value-delivering stories +**Prerequisites:** {{dependencies_on_previous_stories}} + +**Technical Notes:** {{implementation_guidance}} + + --- -**For implementation:** Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown. + + +--- + +_For implementation: Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown._ 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 index 0e5ab662..8d5157c7 100644 --- 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 @@ -1,395 +1,169 @@ -# Epic and Story Decomposition - Bite-Sized Implementation Planning +# Epic and Story Decomposition - Intent-Based 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} +This workflow transforms requirements into BITE-SIZED STORIES for development agents +EVERY story must be completable by a single dev agent in one focused session +Communicate all responses in {communication_language} and adapt 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 +Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically - -Welcome the {user_name} to the project inception high level epic and story planning. + +Welcome {user_name} to epic and story planning -Load required documents: +Load required documents (fuzzy match, handle both whole and sharded): -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) +- PRD.md (required) +- domain-brief.md (if exists) +- product-brief.md (if exists) Extract from PRD: -- Functional requirements +- All functional requirements - Non-functional requirements -- Domain considerations -- Project type -- MVP scope vs growth features +- Domain considerations and compliance needs +- Project type and complexity +- MVP vs growth vs vision scope boundaries -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." +Understand the context: -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." - +- What makes this product special (the magic) +- Technical constraints +- User types and their goals +- Success criteria + - -Transform requirements into epics organically + +Analyze requirements and identify natural epic boundaries -INTENT: Find natural boundaries that make sense for THIS product +INTENT: Find organic groupings that make sense for THIS product -Look at the requirements and find patterns: +Look for natural patterns: -- Features that work together +- Features that work together cohesively - User journeys that connect -- Technical systems that relate -- Business capabilities that group -- Domain requirements that cluster (compliance, validation, etc.) +- Business capabilities that cluster +- Domain requirements that relate (compliance, validation, security) +- Technical systems that should be built together -Examples of natural epic formation: +Name epics based on VALUE, not technical layers: -- 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 +- Good: "User Onboarding", "Content Discovery", "Compliance Framework" +- Avoid: "Database Layer", "API Endpoints", "Frontend" Each epic should: -- Have a clear business goal +- Have clear business goal and user value - Be independently valuable -- Contain 3-8 related features -- Be completable in 1-2 sprints +- Contain 3-8 related capabilities +- Be deliverable in cohesive phase -Name epics based on value, not technical components: -GOOD: "User Onboarding", "Content Discovery", "Team Collaboration" -NOT: "Database", "Frontend", "API" +For greenfield projects: -If domain considerations exist: +- First epic MUST establish foundation (project setup, core infrastructure, deployment pipeline) +- Foundation enables all subsequent work -- Create dedicated compliance/validation epics -- Note special expertise needed per epic -- Flag epics with regulatory dependencies +For complex domains: -Present epic groupings conversationally: -"Based on your requirements, I see these natural epic groupings: +- Consider dedicated compliance/regulatory epics +- Group validation and safety requirements logically +- Note expertise requirements -1. [Epic Name] - [Brief description] -2. [Epic Name] - [Brief description] -3. [Epic Name] - [Brief description] +Present proposed epic structure showing: -Does this organization make sense for how you think about the product?" +- Epic titles with clear value statements +- High-level scope of each epic +- Suggested sequencing +- Why this grouping makes sense -epics_structure +epics_summary +{project-root}/bmad/core/tasks/adv-elicit.xml - -Small vertical sliced small stories are best for agentic dumb developers to implement without forgetting things + +Break down Epic {{N}} into small, implementable stories -Break each epic into small, implementable stories +INTENT: Create stories sized for single dev agent completion -INTENT: Create stories that one dev agent can complete independently +For each epic, generate: -For each epic, decompose into stories that are: +- Epic title as `epic_title_{{N}}` +- Epic goal/value as `epic_goal_{{N}}` +- All stories as repeated pattern `story_title_{{N}}_{{M}}` for each story M -- Small enough for single context window +CRITICAL for Epic 1 (Foundation): + +- Story 1.1 MUST be project setup/infrastructure initialization +- Sets up: repo structure, build system, deployment pipeline basics, core dependencies +- Creates foundation for all subsequent stories +- Note: Architecture workflow will flesh out technical details + +Each story should follow BDD-style acceptance criteria: + +**Story Pattern:** +As a [user type], +I want [specific capability], +So that [clear value/benefit]. + +**Acceptance Criteria using BDD:** +Given [precondition or initial state] +When [action or trigger] +Then [expected outcome] + +And [additional criteria as needed] + +**Prerequisites:** Only previous stories (never forward dependencies) + +**Technical Notes:** Implementation guidance, affected components, compliance requirements + +Ensure stories are: + +- Vertically sliced (deliver complete functionality, not just one layer) +- Sequentially ordered (logical progression, no forward dependencies) +- Independently valuable when possible +- Small enough for single-session completion - Clear enough for autonomous implementation -- Independent enough to develop in parallel when possible -- Specific enough to have clear acceptance criteria -GOOD story examples: +For each story in epic {{N}}, output variables following this pattern: -- "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" +- story*title*{{N}}_1, story_title_{{N}}\_2, etc. +- Each containing: user story, BDD acceptance criteria, prerequisites, technical notes -BAD story examples: +epic*title*{{N}} +epic*goal*{{N}} -- "Build complete authentication system" (too big) -- "Handle user management" (too vague) -- "Make it secure" (not specific) -- "Integrate everything" (requires multiple contexts) +For each story M in epic {{N}}, generate story content +story*title*{{N}}\_{{M}} -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 - - +{project-root}/bmad/core/tasks/adv-elicit.xml - -Order stories for successful development + +Review the complete epic breakdown for quality and completeness -INTENT: Create a logical flow that minimizes blockers and maximizes progress +Validate: -Consider dependencies: -TECHNICAL: +- All functional requirements from PRD are covered by stories +- Epic 1 establishes proper foundation +- All stories are vertically sliced +- No forward dependencies exist +- Story sizing is appropriate for single-session completion +- BDD acceptance criteria are clear and testable +- Domain/compliance requirements are properly distributed +- Sequencing enables incremental value delivery -- Authentication before protected features -- Data models before business logic -- Core features before enhancements -- API before frontend that uses it +Confirm with {user_name}: -DOMAIN: +- Epic structure makes sense +- Story breakdown is actionable +- Dependencies are clear +- BDD format provides clarity +- Ready for architecture and implementation phases -- 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"! +epic_breakdown_summary 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 index 15ea09cf..4e7293a7 100644 --- 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 @@ -13,23 +13,35 @@ document_output_language: "{config_source}:document_output_language" user_skill_level: "{config_source}:user_skill_level" date: system-generated -# Workflow components +# Input requirements +recommended_inputs: + - prd: "Product Requirements Document with FRs and NFRs" + - product_brief: "Product Brief with vision and goals (optional)" + - domain_brief: "Domain-specific requirements and context (optional)" + +# Smart input file references - handles both whole docs and sharded docs +# Priority: Whole document first, then sharded version +input_file_patterns: + prd: + whole: "{output_folder}/*prd*.md" + sharded: "{output_folder}/*prd*/index.md" + + product_brief: + whole: "{output_folder}/*product*brief*.md" + sharded: "{output_folder}/*product*brief*/index.md" + + domain_brief: + whole: "{output_folder}/*domain*brief*.md" + sharded: "{output_folder}/*domain*brief*/index.md" + +# Module path and component files installed_path: "{project-root}/bmad/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 +# Output configuration 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: 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 608769ea..65d81cf0 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md +++ b/src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md @@ -7,24 +7,7 @@ Generate all documents in {document_output_language} LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end GUIDING PRINCIPLE: Find and weave the product's magic throughout - what makes it special should inspire every section - -## 📚 Input Document Discovery - -This workflow requires: product brief, and may reference market research or brownfield project documentation. - -**Discovery Process** (execute for each referenced document): - -1. **Search for whole document first** - Use fuzzy file matching to find the complete document -2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md` -3. **If sharded version found**: - - Read `index.md` to understand the document structure - - Read ALL section files listed in the index - - Treat the combined content as if it were a single document -4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md` - -**Priority**: If both whole and sharded versions exist, use the whole document. - -**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions. +Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically @@ -37,14 +20,14 @@ This workflow requires: product brief, and may reference market research or brow Load the FULL file: {status_file} Parse workflow_status section Check status of "prd" workflow - Get project_level from YAML metadata + Get project_track from YAML metadata Find first non-completed workflow (next expected workflow) - - **Level {{project_level}} Project - Redirecting** + + **Quick Flow Track - Redirecting** -Level 0-1 projects use tech-spec workflow for simpler planning. -PRD is for Level 2-4 projects that need comprehensive requirements. +Quick Flow projects use tech-spec workflow for implementation-focused planning. +PRD is for BMad Method and Enterprise Method tracks that need comprehensive requirements. Exit and suggest tech-spec workflow @@ -132,6 +115,7 @@ Weave in the magic: business_metrics +{project-root}/bmad/core/tasks/adv-elicit.xml @@ -156,6 +140,7 @@ For complex domains: mvp_scope growth_features vision_features +{project-root}/bmad/core/tasks/adv-elicit.xml @@ -256,8 +241,8 @@ Always relate back to the product magic: - -Only if product has a UI + + Only if product has a UI Light touch on UX - not full design: @@ -271,10 +256,10 @@ Light touch on UX - not full design: Connect to the magic: "The UI should reinforce [the special moment] through [design approach]" - - ux_principles - key_interactions - + + ux_principles + key_interactions + @@ -304,6 +289,7 @@ The magic thread: Highlight which requirements deliver the special experience functional_requirements_complete +{project-root}/bmad/core/tasks/adv-elicit.xml @@ -339,9 +325,6 @@ Skip categories that don't apply! integration_requirements - - no_nfrs - @@ -355,9 +338,13 @@ Skip categories that don't apply! - Requirements: [count] functional, [count] non-functional - Special considerations: [domain/innovation] -Does this capture your product vision?" +Does this capture your product vision?" + +prd_summary +{project-root}/bmad/core/tasks/adv-elicit.xml + +After PRD review and refinement complete: -After confirmation: "Excellent! Now we need to break these requirements into implementable epics and stories. For the epic breakdown, you have two options: @@ -379,12 +366,10 @@ 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 +Set project_track based on workflow status (BMad Method or Enterprise Method) Generate epic_details for the epics breakdown document -prd_summary -project_level -target_scale +project_track epic_details 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 7d6788d5..f6622e25 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml +++ b/src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml @@ -1,6 +1,6 @@ # Product Requirements Document (PRD) Workflow name: prd -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." +description: "Unified PRD workflow for BMad Method and Enterprise Method tracks. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Quick Flow track uses tech-spec workflow." author: "BMad" # Critical variables from config @@ -47,7 +47,7 @@ standalone: true web_bundle: name: "prd" - 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." + description: "Unified PRD workflow for BMad Method and Enterprise Method tracks. Produces strategic PRD and tactical epic breakdown. Hands off to architecture workflow for technical design. Note: Quick Flow track uses 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" diff --git a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/epics-template.md b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/epics-template.md index 0047785f..961f2642 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/epics-template.md +++ b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/epics-template.md @@ -5,51 +5,73 @@ --- -## Epic: {{epic_title}} + -**Slug:** {{epic_slug}} +## Epic {{N}}: {{epic_title_N}} + +**Slug:** {{epic_slug_N}} ### Goal -{{epic_goal}} +{{epic_goal_N}} ### Scope -{{epic_scope}} +{{epic_scope_N}} ### Success Criteria -{{epic_success_criteria}} +{{epic_success_criteria_N}} ### Dependencies -{{epic_dependencies}} +{{epic_dependencies_N}} --- -## Story Map +## Story Map - Epic {{N}} -{{story_map}} +{{story_map_N}} --- -## Story Summaries +## Stories - Epic {{N}} -{{story_summaries}} + + +### Story {{N}}.{{M}}: {{story_title_N_M}} + +As a {{user_type}}, +I want {{capability}}, +So that {{value_benefit}}. + +**Acceptance Criteria:** + +**Given** {{precondition}} +**When** {{action}} +**Then** {{expected_outcome}} + +**And** {{additional_criteria}} + +**Prerequisites:** {{dependencies_on_previous_stories}} + +**Technical Notes:** {{implementation_guidance}} + +**Estimated Effort:** {{story_points}} points ({{time_estimate}}) + + --- -## Implementation Timeline +## Implementation Timeline - Epic {{N}} -**Total Story Points:** {{total_points}} +**Total Story Points:** {{total_points_N}} -**Estimated Timeline:** {{estimated_timeline}} +**Estimated Timeline:** {{estimated_timeline_N}} --- -## Implementation Sequence - -{{implementation_sequence}} + --- diff --git a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md index 809ae627..04c1eb69 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md +++ b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md @@ -10,26 +10,8 @@ Level 0: tech-spec + single user story | Level 1: tech-spec + epic/stories LIVING DOCUMENT: Write to tech-spec.md continuously as you discover - never wait until the end CONTEXT IS KING: Gather ALL available context before generating specs - DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content. - -## 📚 Input Document Discovery - -This workflow intelligently discovers and loads all available context including: product brief, research documents, brownfield project documentation, and project setup files. - -**Discovery Process** (execute for each referenced document): - -1. **Search for whole document first** - Use fuzzy file matching to find the complete document -2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md` -3. **If sharded version found**: - - Read `index.md` to understand the document structure - - Read ALL section files listed in the index - - Treat the combined content as if it were a single document -4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md` - -**Priority**: If both whole and sharded versions exist, use the whole document. - -**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions. +Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically Check if {output_folder}/bmm-workflow-status.yaml exists diff --git a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/user-story-template.md b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/user-story-template.md index aae72447..2f28f10a 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/user-story-template.md +++ b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/user-story-template.md @@ -1,32 +1,53 @@ -# Story: {{story_title}} +# Story {{N}}.{{M}}: {{story_title}} -Status: Draft +**Status:** Draft -## Story +--- -As a {{role}}, +## User Story + +As a {{user_type}}, I want {{capability}}, -so that {{benefit}}. +So that {{value_benefit}}. + +--- ## Acceptance Criteria -{{acceptance_criteria}} +**Given** {{precondition}} +**When** {{action}} +**Then** {{expected_outcome}} -## Tasks / Subtasks +**And** {{additional_criteria}} + +--- + +## Implementation Details + +### Tasks / Subtasks {{tasks_subtasks}} -## Dev Notes - ### Technical Summary {{technical_summary}} -### Tech-Spec Reference +### Project Structure Notes -**Full details:** See [tech-spec.md](../tech-spec.md) +- **Files to modify:** {{files_to_modify}} +- **Expected test locations:** {{test_locations}} +- **Estimated effort:** {{story_points}} story points ({{time_estimate}}) +- **Prerequisites:** {{dependencies}} -The tech-spec contains comprehensive context including: +### Key Code References + +{{existing_code_references}} + +--- + +## Context References + +**Tech-Spec:** [tech-spec.md](../tech-spec.md) - Primary context document containing: - Brownfield codebase analysis (if applicable) - Framework and library details with versions @@ -34,32 +55,14 @@ The tech-spec contains comprehensive context including: - Integration points and dependencies - Complete implementation guidance -### Project Structure Notes +**Architecture:** {{architecture_references}} -- **Files to modify:** {{files_to_modify}} -- **Expected test locations:** {{test_locations}} -- **Estimated effort:** {{story_points}} story points ({{time_estimate}}) -- **Dependencies:** {{dependencies}} - -### Key Code References - -{{existing_code_references}} - -### References - -- **Tech Spec:** [tech-spec.md](../tech-spec.md) - Primary context document -- **Architecture:** {{architecture_references}} + --- ## Dev Agent Record -### Context Reference - -**Primary Context:** [tech-spec.md](../tech-spec.md) - Contains all brownfield analysis, framework details, and implementation guidance - - - ### Agent Model Used @@ -68,11 +71,11 @@ The tech-spec contains comprehensive context including: -### Completion Notes List +### Completion Notes -### File List +### Files Modified diff --git a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml index 39a65f2d..29eae4bc 100644 --- a/src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml +++ b/src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml @@ -1,5 +1,5 @@ -# Technical Specification Workflow (Level 0) -name: tech-spec-sm +# Technical Specification +name: tech-spec description: "Technical specification workflow for Level 0 projects (single atomic changes). Creates focused tech spec for bug fixes, single endpoint additions, or small isolated changes. Tech-spec only - no PRD needed." author: "BMad" diff --git a/src/modules/bmm/workflows/3-solutioning/architecture/instructions.md b/src/modules/bmm/workflows/3-solutioning/architecture/instructions.md index e1dae8d6..b78b74c5 100644 --- a/src/modules/bmm/workflows/3-solutioning/architecture/instructions.md +++ b/src/modules/bmm/workflows/3-solutioning/architecture/instructions.md @@ -9,24 +9,8 @@ Communicate all responses in {communication_language} and tailor to {user_skill_level} Generate all documents in {document_output_language} This workflow replaces architecture with a conversation-driven approach - -## 📚 Input Document Discovery - -This workflow requires: PRD and epics/stories, and may reference UX design specifications or brownfield project documentation. - -**Discovery Process** (execute for each referenced document): - -1. **Search for whole document first** - Use fuzzy file matching to find the complete document -2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md` -3. **If sharded version found**: - - Read `index.md` to understand the document structure - - Read ALL section files listed in the index - - Treat the combined content as if it were a single document -4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md` - -**Priority**: If both whole and sharded versions exist, use the whole document. - -**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions. +Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically +ELICITATION POINTS: After completing each major architectural decision area (identified by template-output tags for decision_record, project_structure, novel_pattern_designs, implementation_patterns, and architecture_document), invoke advanced elicitation to refine decisions before proceeding Check if {output_folder}/bmm-workflow-status.yaml exists @@ -379,6 +363,7 @@ Provided by Starter: {{yes_if_from_starter}} decision_record +{project-root}/bmad/core/tasks/adv-elicit.xml @@ -408,6 +393,7 @@ Provided by Starter: {{yes_if_from_starter}} project_structure +{project-root}/bmad/core/tasks/adv-elicit.xml @@ -481,6 +467,7 @@ Provided by Starter: {{yes_if_from_starter}} novel_pattern_designs +{project-root}/bmad/core/tasks/adv-elicit.xml @@ -573,6 +560,7 @@ Enforcement: "All agents MUST follow this pattern" implementation_patterns +{project-root}/bmad/core/tasks/adv-elicit.xml @@ -626,6 +614,7 @@ Enforcement: "All agents MUST follow this pattern" architecture_document +{project-root}/bmad/core/tasks/adv-elicit.xml diff --git a/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/instructions.md b/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/instructions.md index 25a6fdbc..b591e44d 100644 --- a/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/instructions.md +++ b/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/instructions.md @@ -3,24 +3,7 @@ The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml You MUST have already loaded and processed: {project-root}/bmad/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml Communicate all findings and analysis in {communication_language} throughout the assessment - -## 📚 Input Document Discovery - -This workflow validates: PRD, epics/stories, architecture, and may reference UX design, tech specs, or brownfield project documentation. - -**Discovery Process** (execute for each referenced document): - -1. **Search for whole document first** - Use fuzzy file matching to find the complete document -2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md` -3. **If sharded version found**: - - Read `index.md` to understand the document structure - - Read ALL section files listed in the index - - Treat the combined content as if it were a single document -4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md` - -**Priority**: If both whole and sharded versions exist, use the whole document. - -**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions. +Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically diff --git a/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml b/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml index 5bbb15b0..958199c8 100644 --- a/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml +++ b/src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml @@ -24,13 +24,13 @@ validation: "{installed_path}/checklist.md" # Output configuration default_output_file: "{output_folder}/implementation-readiness-report-{{date}}.md" -# Expected input documents (varies by project level) +# Input requirements recommended_inputs: - - prd: "{output_folder}/prd*.md" - - architecture: "{output_folder}/architecture*.md or {output_folder}/architecture*.md" - - tech_spec: "{output_folder}/tech-spec*.md" - - epics_stories: "{output_folder}/epic*.md" - - ux_artifacts: "{output_folder}/ux*.md" + - prd: "Product Requirements Document with FRs and NFRs" + - architecture: "System Architecture with decisions and patterns" + - tech_spec: "Technical Specification (for Quick Flow track)" + - epics: "Epic breakdown with user stories" + - ux_design: "UX design specification (if UI components)" # Smart input file references - handles both whole docs and sharded docs # Priority: Whole document first, then sharded version