ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

refactor: comprehensive workflow modernization and standardization 

## Major Improvements

### 1. Elicitation System Modernization
- Removed legacy `<elicit-required />` tag from workflow.xml
- Replaced with direct `<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>` pattern
- More explicit, self-documenting, and eliminates indirection layer
- Added strategic elicitation points across all planning workflows:
  - PRD: After success criteria, scope, functional requirements, and final review
  - Create-Epics-And-Stories: After epic proposals and each epic's stories
  - Architecture: After decisions, structure, patterns, implementation patterns, and final doc
  - Updated audit-workflow tag scanner to remove obsolete elicit-required reference

### 2. Input Document Discovery Streamlined
- Replaced verbose 19-line "Input Document Discovery" sections with single critical tag
- New format: `<critical>Input documents specified in workflow.yaml input_file_patterns...</critical>`
- Eliminates duplication - workflow.yaml already defines patterns
- Updated across 6 workflows (PRD, create-epics-and-stories, architecture, tech-spec, UX, gate-check)
- Saved ~114 lines of repeated bloat

### 3. Scale System Migration (Levels 0-4 → 3 Tracks)
- Updated PRD workflow from "Level 0-4" to "Quick Flow / BMad Method / Enterprise Method"
- Changed `project_level` variable to `project_track`
- Removed `target_scale` variable (no longer needed)
- Updated workflow.yaml descriptions to reference tracks not levels
- Updated checklist from "Level 2" and "Level 3-4" to "BMad Method" and "Enterprise Method"
- Aligns with new scale-adaptive-system.md (3-track methodology)

### 4. Epic/Story Template Standardization
- Replaced hardcoded 8-epic template with clean repeating pattern using N/M variables
- Added BDD-style acceptance criteria (Given/When/Then/And)
- Removed instructional bloat from templates (moved to instructions.md where it belongs)
- Template shows OUTPUT structure, instructions show PROCESS
- Applied to both create-epics-and-stories and tech-spec workflows
- Templates now use HTML comments to indicate repeating sections

### 5. Workflow.yaml Pattern Consistency
- Standardized input_file_patterns across all workflows
- Separated `recommended_inputs` (semantic WHAT) from `input_file_patterns` (file discovery WHERE)
- Removed duplication between recommended_inputs file paths and input_file_patterns
- Create-epics-and-stories now uses proper whole/sharded pattern like architecture workflow
- Solutioning-gate-check cleaned up to use semantic descriptions not file paths

## Files Changed (18)
- Core: workflow.xml (removed elicit-required tag and references)
- Audit workflow: Updated tag pattern scanner
- PRD workflow: Elicitation points, track migration, input discovery
- Create-epics-and-stories: Template rebuild, BDD format, elicitation, input patterns
- Tech-spec: Template rebuild, BDD format, input discovery
- UX Design: Input discovery streamlined
- Architecture: Elicitation at 5 key decision points, input discovery
- Gate-check: Input pattern cleanup, input discovery

## Impact
- More consistent elicitation across workflows
- Cleaner, more maintainable templates
- Better separation of concerns (templates vs instructions)
- Aligned with v6 3-track scale system
- Reduced bloat and duplication significantly
This commit is contained in:
Brian Madison 2025-11-04 00:09:19 -06:00
parent c5117e5382
commit accae5d789
18 changed files with 292 additions and 590 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
bmad/bmb/workflows/audit-workflow/instructions.md
View File

@ -161,7 +161,7 @@
<action if="condition met">Do something</action> <action if="condition met">Do something</action>
``` ```
<action>Scan instructions.md for nested tag references using pattern: &lt;(action|ask|check|template-output|invoke-workflow|goto|step|elicit-required)&gt; within text content</action> <action>Scan instructions.md for nested tag references using pattern: &lt;(action|ask|check|template-output|invoke-workflow|invoke-task|goto|step)&gt; within text content
<action>Record any instances of nested tag references with line numbers</action> <action>Record any instances of nested tag references with line numbers</action>
<action>Scan instructions.md for conditional execution antipattern: self-closing check tags</action> <action>Scan instructions.md for conditional execution antipattern: self-closing check tags</action>
<action>Detect pattern: `&lt;check&gt;.*&lt;/check&gt;` on single line (self-closing check)</action> <action>Detect pattern: `&lt;check&gt;.*&lt;/check&gt;` on single line (self-closing check)</action>

12
bmad/core/tasks/workflow.xml
View File

@ -13,8 +13,7 @@
<rule n="1">Steps execute in exact numerical order (1, 2, 3...)</rule> <rule n="1">Steps execute in exact numerical order (1, 2, 3...)</rule>
<rule n="2">Optional steps: Ask user unless #yolo mode active</rule> <rule n="2">Optional steps: Ask user unless #yolo mode active</rule>
<rule n="3">Template-output tags: Save content → Show user → Get approval before continuing</rule> <rule n="3">Template-output tags: Save content → Show user → Get approval before continuing</rule>
<rule n="4">Elicit tags: Execute immediately unless #yolo mode (which skips ALL elicitation)</rule> <rule n="4">User must approve each major section before continuing UNLESS #yolo mode active</rule>
<rule n="5">User must approve each major section before continuing UNLESS #yolo mode active</rule>
</WORKFLOW-RULES> </WORKFLOW-RULES>
<flow> <flow>
@ -75,14 +74,6 @@
<action>Display generated content</action> <action>Display generated content</action>
<ask>Continue [c] or Edit [e]? WAIT for response</ask> <ask>Continue [c] or Edit [e]? WAIT for response</ask>
</if> </if>
<if tag="elicit-required">
<mandate critical="true">YOU MUST READ the file at {project-root}/bmad/core/tasks/adv-elicit.xml using Read tool BEFORE presenting
any elicitation menu</mandate>
<action>Load and run task {project-root}/bmad/core/tasks/adv-elicit.xml with current context</action>
<action>Show elicitation menu 5 relevant options (list 1-5 options, Continue [c] or Reshuffle [r])</action>
<mandate>HALT and WAIT for user selection</mandate>
</if>
</substep> </substep>
<substep n="2d" title="Step Completion"> <substep n="2d" title="Step Completion">
@ -123,7 +114,6 @@
</execution> </execution>
<output> <output>
<tag>template-output - Save content checkpoint</tag> <tag>template-output - Save content checkpoint</tag>
<tag>elicit-required - Trigger enhancement</tag>
<tag>critical - Cannot be skipped</tag> <tag>critical - Cannot be skipped</tag>
<tag>example - Show example output</tag> <tag>example - Show example output</tag>
</output> </output>

12
src/core/tasks/workflow.xml
View File

@ -13,8 +13,7 @@
<rule n="1">Steps execute in exact numerical order (1, 2, 3...)</rule> <rule n="1">Steps execute in exact numerical order (1, 2, 3...)</rule>
<rule n="2">Optional steps: Ask user unless #yolo mode active</rule> <rule n="2">Optional steps: Ask user unless #yolo mode active</rule>
<rule n="3">Template-output tags: Save content → Show user → Get approval before continuing</rule> <rule n="3">Template-output tags: Save content → Show user → Get approval before continuing</rule>
<rule n="4">Elicit tags: Execute immediately unless #yolo mode (which skips ALL elicitation)</rule> <rule n="4">User must approve each major section before continuing UNLESS #yolo mode active</rule>
<rule n="5">User must approve each major section before continuing UNLESS #yolo mode active</rule>
</WORKFLOW-RULES> </WORKFLOW-RULES>
<flow> <flow>
@ -75,14 +74,6 @@
<action>Display generated content</action> <action>Display generated content</action>
<ask>Continue [c] or Edit [e]? WAIT for response</ask> <ask>Continue [c] or Edit [e]? WAIT for response</ask>
</if> </if>
<if tag="elicit-required">
<mandate critical="true">YOU MUST READ the file at {project-root}/bmad/core/tasks/adv-elicit.xml using Read tool BEFORE presenting
any elicitation menu</mandate>
<action>Load and run task {project-root}/bmad/core/tasks/adv-elicit.xml with current context</action>
<action>Show elicitation menu 5 relevant options (list 1-5 options, Continue [c] or Reshuffle [r])</action>
<mandate>HALT and WAIT for user selection</mandate>
</if>
</substep> </substep>
<substep n="2d" title="Step Completion"> <substep n="2d" title="Step Completion">
@ -123,7 +114,6 @@
</execution> </execution>
<output> <output>
<tag>template-output - Save content checkpoint</tag> <tag>template-output - Save content checkpoint</tag>
<tag>elicit-required - Trigger enhancement</tag>
<tag>critical - Cannot be skipped</tag> <tag>critical - Cannot be skipped</tag>
<tag>example - Show example output</tag> <tag>example - Show example output</tag>
</output> </output>

2
src/modules/bmb/workflows/audit-workflow/instructions.md
View File

@ -161,7 +161,7 @@
<action if="condition met">Do something</action> <action if="condition met">Do something</action>
``` ```
<action>Scan instructions.md for nested tag references using pattern: &lt;(action|ask|check|template-output|invoke-workflow|goto|step|elicit-required)&gt; within text content</action> <action>Scan instructions.md for nested tag references using pattern: &lt;(action|ask|check|template-output|invoke-workflow|invoke-task|goto|step)&gt; within text content</action>
<action>Record any instances of nested tag references with line numbers</action> <action>Record any instances of nested tag references with line numbers</action>
<action>Scan instructions.md for conditional execution antipattern: self-closing check tags</action> <action>Scan instructions.md for conditional execution antipattern: self-closing check tags</action>
<action>Detect pattern: `&lt;check&gt;.*&lt;/check&gt;` on single line (self-closing check)</action> <action>Detect pattern: `&lt;check&gt;.*&lt;/check&gt;` on single line (self-closing check)</action>

20
src/modules/bmm/workflows/2-plan-workflows/create-ux-design/instructions.md
View File

@ -9,26 +9,8 @@
<critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical> <critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical> <critical>Generate all documents in {document_output_language}</critical>
<critical>SAVE PROGRESS after each major step - use <template-output> tags throughout</critical> <critical>SAVE PROGRESS after each major step - use <template-output> tags throughout</critical>
<critical>DOCUMENT OUTPUT: Professional, specific, actionable UX design decisions WITH RATIONALE. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical> <critical>DOCUMENT OUTPUT: Professional, specific, actionable UX design decisions WITH RATIONALE. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
## 📚 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.
<step n="0" goal="Validate workflow readiness" tag="workflow-status"> <step n="0" goal="Validate workflow readiness" tag="workflow-status">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action> <action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>

19
src/modules/bmm/workflows/2-plan-workflows/prd/checklist.md
View File

@ -234,21 +234,22 @@
- [ ] Dependencies on external systems documented - [ ] Dependencies on external systems documented
- [ ] Data requirements specified - [ ] Data requirements specified
### Level-Appropriate Detail ### Track-Appropriate Detail
**If Level 2:** **If BMad Method:**
- [ ] 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 - [ ] PRD supports full architecture workflow
- [ ] Epic structure supports phased delivery - [ ] Epic structure supports phased delivery
- [ ] Scope appropriate for team-based development - [ ] Scope appropriate for product/platform development
- [ ] Clear value delivery through epic sequence - [ ] 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 ## 10. Quality and Polish

59
src/modules/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md
View File

@ -9,55 +9,44 @@
## Overview ## 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: {{epics_summary}}
- 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
--- ---
{{epic_details}} <!-- Repeat for each epic (N = 1, 2, 3...) -->
--- ## Epic {{N}}: {{epic_title_N}}
## Story Guidelines Reference {{epic_goal_N}}
**Story Format:** <!-- Repeat for each story (M = 1, 2, 3...) within epic N -->
``` ### Story {{N}}.{{M}}: {{story_title_N_M}}
**Story [EPIC.N]: [Story Title]**
As a [user type], As a {{user_type}},
I want [goal/desire], I want {{capability}},
So that [benefit/value]. So that {{value_benefit}}.
**Acceptance Criteria:** **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 **Prerequisites:** {{dependencies_on_previous_stories}}
- **Sequential ordering** - Logical progression within epic
- **No forward dependencies** - Only depend on previous work **Technical Notes:** {{implementation_guidance}}
- **AI-agent sized** - Completable in 2-4 hour focused session
- **Value-focused** - Integrate technical enablers into value-delivering stories <!-- End story repeat -->
--- ---
**For implementation:** Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown. <!-- End epic repeat -->
---
_For implementation: Use the `create-story` workflow to generate individual story implementation plans from this epic breakdown._

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

@ -1,395 +1,169 @@
# Epic and Story Decomposition - Bite-Sized Implementation Planning # Epic and Story Decomposition - Intent-Based Implementation Planning
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical> <critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical> <critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow transforms requirements into BITE-SIZED STORIES for limited context agents</critical> <critical>This workflow transforms requirements into BITE-SIZED STORIES for development agents</critical>
<critical>EVERY story must be completable by a single limited context window dev agent in one session</critical> <critical>EVERY story must be completable by a single dev agent in one focused session</critical>
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical> <critical>Communicate all responses in {communication_language} and adapt to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical> <critical>Generate all documents in {document_output_language}</critical>
<critical>LIVING DOCUMENT: Write to epics.md continuously as you work - never wait until the end</critical> <critical>LIVING DOCUMENT: Write to epics.md continuously as you work - never wait until the end</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<workflow> <workflow>
<step n="0" goal="Load context and requirements"> <step n="1" goal="Load PRD and extract requirements">
<action>Welcome the {user_name} to the project inception high level epic and story planning. <action>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) - PRD.md (required)
2. domain-brief.md (if exists) - domain-brief.md (if exists)
3. product-brief.md (if exists) - product-brief.md (if exists)
Extract from PRD: Extract from PRD:
- Functional requirements - All functional requirements
- Non-functional requirements - Non-functional requirements
- Domain considerations - Domain considerations and compliance needs
- Project type - Project type and complexity
- MVP scope vs growth features - MVP vs growth vs vision scope boundaries
If continuing from PRD workflow: Understand the context:
"Great! Now let's break down your requirements into actionable epics and bite-sized stories that development agents can implement independently."
If starting fresh: - What makes this product special (the magic)
"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."</action> - Technical constraints
</step> - User types and their goals
- Success criteria</action>
</step>
<step n="1" goal="Form epics from natural groupings"> <step n="2" goal="Propose epic structure from natural groupings">
<action>Transform requirements into epics organically <action>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 - User journeys that connect
- Technical systems that relate - Business capabilities that cluster
- Business capabilities that group - Domain requirements that relate (compliance, validation, security)
- Domain requirements that cluster (compliance, validation, etc.) - 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 - Good: "User Onboarding", "Content Discovery", "Compliance Framework"
- Payment features → "Monetization" epic - Avoid: "Database Layer", "API Endpoints", "Frontend"
- 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: Each epic should:
- Have a clear business goal - Have clear business goal and user value
- Be independently valuable - Be independently valuable
- Contain 3-8 related features - Contain 3-8 related capabilities
- Be completable in 1-2 sprints - Be deliverable in cohesive phase
Name epics based on value, not technical components: For greenfield projects:
GOOD: "User Onboarding", "Content Discovery", "Team Collaboration"
NOT: "Database", "Frontend", "API"
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 For complex domains:
- Note special expertise needed per epic
- Flag epics with regulatory dependencies
Present epic groupings conversationally: - Consider dedicated compliance/regulatory epics
"Based on your requirements, I see these natural epic groupings: - Group validation and safety requirements logically
- Note expertise requirements
1. [Epic Name] - [Brief description] Present proposed epic structure showing:
2. [Epic Name] - [Brief description]
3. [Epic Name] - [Brief description]
Does this organization make sense for how you think about the product?"</action> - Epic titles with clear value statements
- High-level scope of each epic
- Suggested sequencing
- Why this grouping makes sense</action>
<template-output>epics_structure</template-output> <template-output>epics_summary</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="2" goal="Decompose into bite-sized stories"> <step n="3" goal="Decompose each epic into bite-sized stories" repeat="for-each-epic">
<critical>Small vertical sliced small stories are best for agentic dumb developers to implement without forgetting things</critical> <action>Break down Epic {{N}} into small, implementable stories
<action>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 - 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" - story*title*{{N}}_1, story_title_{{N}}\_2, etc.
- "Build user profile component with avatar upload to S3" - Each containing: user story, BDD acceptance criteria, prerequisites, technical notes</action>
- "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: <template-output>epic*title*{{N}}</template-output>
<template-output>epic*goal*{{N}}</template-output>
- "Build complete authentication system" (too big) <action>For each story M in epic {{N}}, generate story content</action>
- "Handle user management" (too vague) <template-output>story*title*{{N}}\_{{M}}</template-output>
- "Make it secure" (not specific)
- "Integrate everything" (requires multiple contexts)
Story format: <invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
"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</action>
<template-output>epic_1_stories</template-output>
<template-output>epic_2_stories</template-output>
<template-output>epic_3_stories</template-output>
<!-- Continue for each epic discovered -->
</step> </step>
<step n="3" goal="Sequence for smart implementation"> <step n="4" goal="Review and finalize epic breakdown">
<action>Order stories for successful development <action>Review the complete epic breakdown for quality and completeness
INTENT: Create a logical flow that minimizes blockers and maximizes progress Validate:
Consider dependencies: - All functional requirements from PRD are covered by stories
TECHNICAL: - 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 Confirm with {user_name}:
- Data models before business logic
- Core features before enhancements
- API before frontend that uses it
DOMAIN: - Epic structure makes sense
- Story breakdown is actionable
- Dependencies are clear
- BDD format provides clarity
- Ready for architecture and implementation phases</action>
- Compliance infrastructure before features <template-output>epic_breakdown_summary</template-output>
- 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."</action>
<template-output>implementation_sequence</template-output>
<template-output>development_phases</template-output>
<template-output>dependency_graph</template-output>
</step>
<step n="4" goal="Validate story sizing and clarity">
<action>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]"</action>
<template-output>story_validation</template-output>
</step>
<step n="5" goal="Create development guidance">
<action>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]"</action>
<template-output>implementation_guidance</template-output>
</step>
<step n="6" goal="Finalize and prepare handoff">
<action>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)</action>
<output>**✅ 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"!</output>
</step> </step>
</workflow> </workflow>

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

@ -13,23 +13,35 @@ document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level" user_skill_level: "{config_source}:user_skill_level"
date: system-generated 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" installed_path: "{project-root}/bmad/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories"
instructions: "{installed_path}/instructions.md" instructions: "{installed_path}/instructions.md"
template: "{installed_path}/epics-template.md" template: "{installed_path}/epics-template.md"
# Input files (from parent PRD workflow) # Output configuration
prd_file: "{output_folder}/PRD.md"
# Output files
default_output_file: "{output_folder}/epics.md" 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 standalone: true
web_bundle: web_bundle:

61
src/modules/bmm/workflows/2-plan-workflows/prd/instructions.md
View File

@ -7,24 +7,7 @@
<critical>Generate all documents in {document_output_language}</critical> <critical>Generate all documents in {document_output_language}</critical>
<critical>LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end</critical> <critical>LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end</critical>
<critical>GUIDING PRINCIPLE: Find and weave the product's magic throughout - what makes it special should inspire every section</critical> <critical>GUIDING PRINCIPLE: Find and weave the product's magic throughout - what makes it special should inspire every section</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
## 📚 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.
<workflow> <workflow>
@ -37,14 +20,14 @@ This workflow requires: product brief, and may reference market research or brow
<action>Load the FULL file: {status_file}</action> <action>Load the FULL file: {status_file}</action>
<action>Parse workflow_status section</action> <action>Parse workflow_status section</action>
<action>Check status of "prd" workflow</action> <action>Check status of "prd" workflow</action>
<action>Get project_level from YAML metadata</action> <action>Get project_track from YAML metadata</action>
<action>Find first non-completed workflow (next expected workflow)</action> <action>Find first non-completed workflow (next expected workflow)</action>
<check if="project_level < 2"> <check if="project_track is Quick Flow">
<output>**Level {{project_level}} Project - Redirecting** <output>**Quick Flow Track - Redirecting**
Level 0-1 projects use tech-spec workflow for simpler planning. Quick Flow projects use tech-spec workflow for implementation-focused planning.
PRD is for Level 2-4 projects that need comprehensive requirements.</output> PRD is for BMad Method and Enterprise Method tracks that need comprehensive requirements.</output>
<action>Exit and suggest tech-spec workflow</action> <action>Exit and suggest tech-spec workflow</action>
</check> </check>
@ -132,6 +115,7 @@ Weave in the magic:
<check if="business focus"> <check if="business focus">
<template-output>business_metrics</template-output> <template-output>business_metrics</template-output>
</check> </check>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="3" goal="Scope Definition"> <step n="3" goal="Scope Definition">
@ -156,6 +140,7 @@ For complex domains:
<template-output>mvp_scope</template-output> <template-output>mvp_scope</template-output>
<template-output>growth_features</template-output> <template-output>growth_features</template-output>
<template-output>vision_features</template-output> <template-output>vision_features</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="4" goal="Domain-Specific Exploration" optional="true"> <step n="4" goal="Domain-Specific Exploration" optional="true">
@ -256,8 +241,8 @@ Always relate back to the product magic:
</check> </check>
</step> </step>
<step n="7" goal="UX Principles" optional="true"> <step n="7" goal="UX Principles" if="project has UI or UX">
<action>Only if product has a UI <action>Only if product has a UI
Light touch on UX - not full design: Light touch on UX - not full design:
@ -271,10 +256,10 @@ Light touch on UX - not full design:
Connect to the magic: Connect to the magic:
"The UI should reinforce [the special moment] through [design approach]"</action> "The UI should reinforce [the special moment] through [design approach]"</action>
<check if="has UI"> <check if="has UI">
<template-output>ux_principles</template-output> <template-output>ux_principles</template-output>
<template-output>key_interactions</template-output> <template-output>key_interactions</template-output>
</check> </check>
</step> </step>
<step n="8" goal="Functional Requirements Synthesis"> <step n="8" goal="Functional Requirements Synthesis">
@ -304,6 +289,7 @@ The magic thread:
Highlight which requirements deliver the special experience</action> Highlight which requirements deliver the special experience</action>
<template-output>functional_requirements_complete</template-output> <template-output>functional_requirements_complete</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="9" goal="Non-Functional Requirements Discovery"> <step n="9" goal="Non-Functional Requirements Discovery">
@ -339,9 +325,6 @@ Skip categories that don't apply!</action>
<check if="integration matters"> <check if="integration matters">
<template-output>integration_requirements</template-output> <template-output>integration_requirements</template-output>
</check> </check>
<check if="no NFRs discussed">
<template-output>no_nfrs</template-output>
</check>
</step> </step>
<step n="10" goal="Review PRD and transition to epics"> <step n="10" goal="Review PRD and transition to epics">
@ -355,9 +338,13 @@ Skip categories that don't apply!</action>
- Requirements: [count] functional, [count] non-functional - Requirements: [count] functional, [count] non-functional
- Special considerations: [domain/innovation] - Special considerations: [domain/innovation]
Does this capture your product vision?" Does this capture your product vision?"</action>
<template-output>prd_summary</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
<action>After PRD review and refinement complete:
After confirmation:
"Excellent! Now we need to break these requirements into implementable epics and stories. "Excellent! Now we need to break these requirements into implementable epics and stories.
For the epic breakdown, you have two options: For the epic breakdown, you have two options:
@ -379,12 +366,10 @@ This keeps each session focused and manageable."
If continue: If continue:
"Let's continue with epic breakdown here..." "Let's continue with epic breakdown here..."
[Proceed with epics-stories subworkflow] [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</action> Generate epic_details for the epics breakdown document</action>
<template-output>prd_summary</template-output> <template-output>project_track</template-output>
<template-output>project_level</template-output>
<template-output>target_scale</template-output>
<template-output>epic_details</template-output> <template-output>epic_details</template-output>
</step> </step>

4
src/modules/bmm/workflows/2-plan-workflows/prd/workflow.yaml
View File

@ -1,6 +1,6 @@
# Product Requirements Document (PRD) Workflow # Product Requirements Document (PRD) Workflow
name: prd 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" author: "BMad"
# Critical variables from config # Critical variables from config
@ -47,7 +47,7 @@ standalone: true
web_bundle: web_bundle:
name: "prd" 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" author: "BMad"
instructions: "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md" instructions: "bmad/bmm/workflows/2-plan-workflows/prd/instructions.md"
validation: "bmad/bmm/workflows/2-plan-workflows/prd/checklist.md" validation: "bmad/bmm/workflows/2-plan-workflows/prd/checklist.md"

54
src/modules/bmm/workflows/2-plan-workflows/tech-spec/epics-template.md
View File

@ -5,51 +5,73 @@
--- ---
## Epic: {{epic_title}} <!-- Repeat for each epic (N = 1, 2, 3...) -->
**Slug:** {{epic_slug}} ## Epic {{N}}: {{epic_title_N}}
**Slug:** {{epic_slug_N}}
### Goal ### Goal
{{epic_goal}} {{epic_goal_N}}
### Scope ### Scope
{{epic_scope}} {{epic_scope_N}}
### Success Criteria ### Success Criteria
{{epic_success_criteria}} {{epic_success_criteria_N}}
### Dependencies ### Dependencies
{{epic_dependencies}} {{epic_dependencies_N}}
--- ---
## Story Map ## Story Map - Epic {{N}}
{{story_map}} {{story_map_N}}
--- ---
## Story Summaries ## Stories - Epic {{N}}
{{story_summaries}} <!-- Repeat for each story (M = 1, 2, 3...) within epic N -->
### 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}})
<!-- End story repeat -->
--- ---
## 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 <!-- End epic repeat -->
{{implementation_sequence}}
--- ---

20
src/modules/bmm/workflows/2-plan-workflows/tech-spec/instructions.md
View File

@ -10,26 +10,8 @@
<critical>Level 0: tech-spec + single user story | Level 1: tech-spec + epic/stories</critical> <critical>Level 0: tech-spec + single user story | Level 1: tech-spec + epic/stories</critical>
<critical>LIVING DOCUMENT: Write to tech-spec.md continuously as you discover - never wait until the end</critical> <critical>LIVING DOCUMENT: Write to tech-spec.md continuously as you discover - never wait until the end</critical>
<critical>CONTEXT IS KING: Gather ALL available context before generating specs</critical> <critical>CONTEXT IS KING: Gather ALL available context before generating specs</critical>
<critical>DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical> <critical>DOCUMENT OUTPUT: Technical, precise, definitive. Specific versions only. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
## 📚 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.
<step n="0" goal="Validate workflow readiness and detect project level" tag="workflow-status"> <step n="0" goal="Validate workflow readiness and detect project level" tag="workflow-status">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action> <action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>

71
src/modules/bmm/workflows/2-plan-workflows/tech-spec/user-story-template.md
View File

@ -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}}, I want {{capability}},
so that {{benefit}}. So that {{value_benefit}}.
---
## Acceptance Criteria ## Acceptance Criteria
{{acceptance_criteria}} **Given** {{precondition}}
**When** {{action}}
**Then** {{expected_outcome}}
## Tasks / Subtasks **And** {{additional_criteria}}
---
## Implementation Details
### Tasks / Subtasks
{{tasks_subtasks}} {{tasks_subtasks}}
## Dev Notes
### Technical Summary ### Technical Summary
{{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) - Brownfield codebase analysis (if applicable)
- Framework and library details with versions - Framework and library details with versions
@ -34,32 +55,14 @@ The tech-spec contains comprehensive context including:
- Integration points and dependencies - Integration points and dependencies
- Complete implementation guidance - Complete implementation guidance
### Project Structure Notes **Architecture:** {{architecture_references}}
- **Files to modify:** {{files_to_modify}} <!-- Additional context XML paths will be added here if story-context workflow is run -->
- **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 ## Dev Agent Record
### Context Reference
**Primary Context:** [tech-spec.md](../tech-spec.md) - Contains all brownfield analysis, framework details, and implementation guidance
<!-- Additional context XML paths will be added here if story-context workflow is run -->
### Agent Model Used ### Agent Model Used
<!-- Will be populated during dev-story execution --> <!-- Will be populated during dev-story execution -->
@ -68,11 +71,11 @@ The tech-spec contains comprehensive context including:
<!-- Will be populated during dev-story execution --> <!-- Will be populated during dev-story execution -->
### Completion Notes List ### Completion Notes
<!-- Will be populated during dev-story execution --> <!-- Will be populated during dev-story execution -->
### File List ### Files Modified
<!-- Will be populated during dev-story execution --> <!-- Will be populated during dev-story execution -->

4
src/modules/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml
View File

@ -1,5 +1,5 @@
# Technical Specification Workflow (Level 0) # Technical Specification
name: tech-spec-sm 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." 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" author: "BMad"

25
src/modules/bmm/workflows/3-solutioning/architecture/instructions.md
View File

@ -9,24 +9,8 @@
<critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical> <critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical> <critical>Generate all documents in {document_output_language}</critical>
<critical>This workflow replaces architecture with a conversation-driven approach</critical> <critical>This workflow replaces architecture with a conversation-driven approach</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
## 📚 Input Document Discovery <critical>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</critical>
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.
<step n="0" goal="Validate workflow readiness" tag="workflow-status"> <step n="0" goal="Validate workflow readiness" tag="workflow-status">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action> <action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
@ -379,6 +363,7 @@ Provided by Starter: {{yes_if_from_starter}}
</action> </action>
<template-output>decision_record</template-output> <template-output>decision_record</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="5" goal="Address cross-cutting concerns"> <step n="5" goal="Address cross-cutting concerns">
@ -408,6 +393,7 @@ Provided by Starter: {{yes_if_from_starter}}
</action> </action>
<template-output>project_structure</template-output> <template-output>project_structure</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="7" goal="Design novel architectural patterns" optional="true"> <step n="7" goal="Design novel architectural patterns" optional="true">
@ -481,6 +467,7 @@ Provided by Starter: {{yes_if_from_starter}}
</check> </check>
<template-output>novel_pattern_designs</template-output> <template-output>novel_pattern_designs</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="8" goal="Define implementation patterns to prevent agent conflicts"> <step n="8" goal="Define implementation patterns to prevent agent conflicts">
@ -573,6 +560,7 @@ Enforcement: "All agents MUST follow this pattern"
</action> </action>
<template-output>implementation_patterns</template-output> <template-output>implementation_patterns</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="9" goal="Validate architectural coherence"> <step n="9" goal="Validate architectural coherence">
@ -626,6 +614,7 @@ Enforcement: "All agents MUST follow this pattern"
</action> </action>
<template-output>architecture_document</template-output> <template-output>architecture_document</template-output>
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
</step> </step>
<step n="11" goal="Validate document completeness"> <step n="11" goal="Validate document completeness">

19
src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/instructions.md
View File

@ -3,24 +3,7 @@
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical> <critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/bmad/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml</critical> <critical>You MUST have already loaded and processed: {project-root}/bmad/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml</critical>
<critical>Communicate all findings and analysis in {communication_language} throughout the assessment</critical> <critical>Communicate all findings and analysis in {communication_language} throughout the assessment</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
## 📚 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.
<workflow> <workflow>

12
src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml
View File

@ -24,13 +24,13 @@ validation: "{installed_path}/checklist.md"
# Output configuration # Output configuration
default_output_file: "{output_folder}/implementation-readiness-report-{{date}}.md" default_output_file: "{output_folder}/implementation-readiness-report-{{date}}.md"
# Expected input documents (varies by project level) # Input requirements
recommended_inputs: recommended_inputs:
- prd: "{output_folder}/prd*.md" - prd: "Product Requirements Document with FRs and NFRs"
- architecture: "{output_folder}/architecture*.md or {output_folder}/architecture*.md" - architecture: "System Architecture with decisions and patterns"
- tech_spec: "{output_folder}/tech-spec*.md" - tech_spec: "Technical Specification (for Quick Flow track)"
- epics_stories: "{output_folder}/epic*.md" - epics: "Epic breakdown with user stories"
- ux_artifacts: "{output_folder}/ux*.md" - ux_design: "UX design specification (if UI components)"
# Smart input file references - handles both whole docs and sharded docs # Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version # Priority: Whole document first, then sharded version