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

Merge branch 'main' into ide-bmad-folder-compile-fix

This commit is contained in:
Phil 2025-11-16 08:22:44 -05:00 committed by GitHub
parent 6a3ad2412d 0ca164de34
commit 31b8e15b31
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
170 changed files with 3781 additions and 51233 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.gitignore vendored
View File

@ -63,4 +63,7 @@ src/modules/bmb/sub-modules/
src/modules/cis/sub-modules/
src/modules/bmgd/sub-modules/
z*/
z*/
.bmad
.claude

4
.prettierignore
View File

@ -1,2 +1,6 @@
# Test fixtures with intentionally broken/malformed files
test/fixtures/**
# BMAD runtime folders (user-specific, not in repo)
.bmad/
.bmad*/

1
.vscode/settings.json vendored
View File

@ -21,6 +21,7 @@
"Decisioning",
"eksctl",
"elicitations",
"Excalidraw",
"filecomplete",
"fintech",
"fluxcd",

221
CHANGELOG.md
View File

@ -2,6 +2,227 @@
## [Unreleased]
## [6.0.0-alpha.10]
**Release: November 16, 2025**
This alpha release introduces a new specialized agent for visual diagramming, major epic creation workflow improvements, platform-specific filtering capabilities, and critical time estimate prohibition guidance across all workflows.
### 🎯 MAJOR MILESTONE: Epics & Stories Now Generated AFTER Architecture
**A Key v6 Goal Realized!**
One of the most important goals for BMad Method v6 has been achieved: **epic and story generation now occurs AFTER architecture completion** in the full BMad Method flow.
**Why This Matters:**
- Stories are now **technically informed** - they reference actual architectural decisions, patterns, and constraints
- No more architectural surprises mid-implementation - stories already account for the chosen tech stack
- Better story estimation (complexity-based, not time-based) because technical approach is known
- Acceptance criteria can reference specific architectural patterns and integration points
- Reduces story rewrites that previously occurred when architecture revealed new complexity
**Workflow Sequence (Full BMad Method):**
```
PRD → UX Design → Architecture → Epics & Stories
↑
NOW HERE (informed by all prior context)
```
**Flexibility Preserved:**
You can still generate epics at earlier stages if your project requires it:
- After PRD (basic structure, feature-focused)
- After UX Design (with interaction context)
- After Architecture (RECOMMENDED - fully informed)
The workflow now supports progressive enhancement, allowing you to create basic epics early and enrich them as more context becomes available. However, for most projects, **waiting until after architecture completion** produces the highest quality, most actionable stories.
This represents a fundamental shift from "plan everything upfront" to "plan informed by technical reality."
### 🎨 New Agent Saif the Frame Expert (Excalidraw Specialist)
Thank you Saif for the new initial addition of this new agent, that will soon be further integrated into other workflows for the BMad Method and the CIS. This works great also if you install the excalidraw VSCode plugin to view the files easily.
**Visual Diagramming Specialist:**
- New frame-expert agent specialized in Excalidraw visual representations - use this agent or the workflows at any point to produce architcure visualizations, mock ups, visual ideas to share with the other agents and so much more. Many udpates will come to further integrate this powerful tool.
- **Four specialized workflows:**
- `create-flowchart` - Process flow visualization
- `create-diagram` - General architectural diagrams
- `create-dataflow` - Data flow and pipeline visualization
- `create-wireframe` - UI/UX wireframe creation
- Includes shared Excalidraw helpers, templates, and validation
- Integrated into default-party.csv and team-fullstack configurations
- Icon: 📐 with webskip flag for IDE-only functionality
### 🚀 Epic Creation Workflow Revolution
**User-Value Focused Epic Structure:**
- Added comprehensive principles for user-value focused epic breakdown
- Explicit anti-pattern examples showing wrong vs right epic structure
- **NO technical layer breakdown** - epics must deliver user value
- Multi-mode detection: CONTINUE, REPLACE, or UPDATE existing epics
- Epics now created AFTER architecture for technically-informed story breakdown
- Added checkpoint protocol for interactive workflow progression
**Progressive Enhancement Pattern:**
- Intelligent UPDATE vs CREATE mode detection
- Detects available context (UX, Architecture, Domain brief, Product brief)
- Living document approach with continuous updates
- Creates basic epics, then enriches with UX/Architecture context
### ⏰ Time Estimate Prohibition (Critical Update)
**AI-Age Development Reality:**
- Added **critical warnings** against providing ANY time estimates (hours/days/weeks/months)
- Applied across **33 workflow instruction files** in BMB, BMGD, BMM, and CIS modules
- Acknowledges AI has fundamentally changed development speed
- Updated workflow creation guide with prohibition guidelines
- Recognizes traditional estimation methods are obsolete in AI-augmented development
**Rationale:** Time estimates based on pre-AI development patterns are actively harmful and misleading. AI-driven development exhibits non-linear productivity patterns that make traditional estimation unreliable.
### 🎯 Platform-Specific Command Filtering
**IDE-Only and Web-Only Support:**
- New `ide-only` and `web-only` boolean fields in agent menu schema
- Menu items filtered based on build target (web bundle vs local IDE)
- Examples:
- `workflow-init` and `correct-course` marked as IDE-only
- `advanced-elicitation` marked as web-only
- Enables platform-appropriate functionality across different environments
**Agent Updates:**
- PM: workflow-init and correct-course as ide-only
- UX Designer: Renamed trigger to create-ux-design
- SM: Renamed triggers for consistency (story-context → create-story-context)
- Analyst: Added research workflow after brainstorm
- Architect: Removed document field from validate-architecture
- Dev: Updated persona and critical actions for clarity
- Tech-writer: Added party-mode workflow
- All agents: Standardized party-mode descriptions
### 🔧 Agent Customization Enhancement
**Prompts and Memories Merging:**
- Added merging logic for `customizeYaml.prompts` and `customizeYaml.memories` in agent loading
- New `buildMemoriesXml()` method for XML output
- Updated `buildPromptsXml()` to use `<content>` wrapper for better compatibility
- Memories output integrated between persona and prompts sections
- Users can now customize agents via `bmad/_cfg/agents/*.customize.yaml` with:
- `prompts`: Array of {id, content} objects for action handlers
- `memories`: Array of strings for persistent agent memories
### 📋 Workflow Configuration Standardization
**Input File Patterns Cleanup:**
- Removed 32 `recommended_inputs:` sections (redundant with input_file_patterns)
- Added `description:` fields to all input_file_patterns (25 workflows)
- Added missing `load_strategy` fields (5 workflows)
- Fixed BMB workflows with proper reference doc variables
- Updated BMB instructions to use new variables
**Workflow Path Enhancements:**
- Updated all 4 workflow paths (enterprise/method × brownfield/greenfield)
- Added multiple optional epic creation steps at different phases:
- After PRD (basic structure)
- After UX Design (with interaction context)
- After Architecture (final with full context)
- Changed PRD output description from "with epics and stories" to "with FRs and NFRs"
### 🗂️ Documentation & Architecture Updates
**Solutioning Gate Check Removal:**
- Deleted entire solutioning-gate-check workflow (682 lines)
- Replaced by new implementation-readiness pattern
- Cleaner separation of concerns in solutioning phase
**PRD Template Simplification:**
- Removed hardcoded "Implementation Planning", "References", and "Next Steps" sections
- PRD now focuses purely on requirements, not workflow orchestration
- Epics/stories created as separate step after architecture
**Documentation Overhaul:**
- 15+ documentation files updated across modules
- Updated quick-start guide with v6 workflow sequence
- Clarified that epics are created AFTER architecture, not during PRD
- Updated solutioning docs to reflect implementation-readiness pattern
- Improved agents-guide, brownfield-guide, enterprise docs
- Enhanced glossary, FAQ, and workflow reference documentation
### 🐛 Bug Fixes & Installer Improvements
**Critical Fixes:**
- Fixed installer blocking issues when folder name is changed during install
- Updated file paths in agent and workflow configurations to use `{bmad_folder}` variable (#917)
- Fixed shard-doc to use proper command for markdown-tree-parser (#911)
- PRD workflow now properly uses project-types CSV
- Web bundler fixes and bundle link updates in documentation
**Architecture Workflow:**
- Made epics input optional (falls back to PRD FRs)
- Updated innovation strategy phases to remove time-based language
- Phases now: Immediate Impact → Foundation Building → Scale & Optimization
### 📊 Impact Summary
- **65+ files modified** across all modules
- **682 lines removed** from deprecated solutioning-gate-check workflow
- **33 instruction files** updated with time estimate prohibition
- **4 new workflows** added for frame-expert agent
- **32 recommended_inputs sections** cleaned up for standardization
- **Net reduction of ~500+ lines** through consolidation and cleanup
### ⚠️ Breaking Changes
**Workflow Changes:**
- Solutioning-gate-check workflow removed (replaced by implementation-readiness)
- PRD no longer includes epic/story generation (separate workflow step)
- Some workflow triggers renamed for consistency
**Variable Updates:**
- Agent and workflow configurations now require `{bmad_folder}` variable support
- PRD output format changed (FRs and NFRs focus, not epics/stories)
### 🔄 Migration Notes
**For Existing Projects:**
1. **Epic Creation:** Epics are now created as a separate workflow step AFTER architecture
- Update any automation scripts that expected epics in PRD output
- Use `create-epics-and-stories` workflow explicitly
2. **Time Estimates:** Focus on value delivery, not time predictions
3. **Agent Customization:** New customization options available
- Add memories via `*.customize.yaml` files
- Custom prompts can extend agent capabilities
4. **Platform-Specific Commands:** Some commands now platform-restricted
- workflow-init only available in IDE environments
5. **Frame Expert:** New agent available for visual diagramming
- Install/reinstall to get new workflows
- Four specialized Excalidraw workflows available
## [6.0.0-alpha.9]
**Release: November 12, 2025**

24
docs/document-sharding-guide.md
View File

@ -176,10 +176,11 @@ Workflows load entire sharded documents:
- `product-brief` - Research, brainstorming docs
- `prd` - Product brief, research
- `gdd` - Game brief, research
- `create-ux-design` - PRD, brief, epics
- `create-ux-design` - PRD, brief, architecture (if available)
- `tech-spec` - Brief, research
- `architecture` - PRD, epics, UX design
- `solutioning-gate-check` - All planning docs
- `architecture` - PRD, UX design (if available)
- `create-epics-and-stories` - PRD, architecture
- `implementation-readiness` - All planning docs
#### Phase 4 (Selective Load)
@ -284,8 +285,8 @@ input_file_patterns:
```
Every workflow loads entire 45k token PRD
Epic-tech-context for Epic 3: 45k tokens
Create-story for Epic 3: 45k tokens
Architecture workflow: 45k tokens
UX design workflow: 45k tokens
```
**After Sharding:**
@ -298,17 +299,18 @@ Destination: docs/prd/
Created:
prd/index.md
prd/overview.md (3k tokens)
prd/epic-1-auth.md (3k tokens)
prd/epic-2-dashboard.md (3k tokens)
prd/epic-3-reports.md (3k tokens)
...15 epic files
prd/functional-requirements.md (8k tokens)
prd/non-functional-requirements.md (6k tokens)
prd/user-personas.md (4k tokens)
...additional FR/NFR sections
```
**Result:**
```
Epic-tech-context for Epic 3: 3k tokens (93% reduction!)
Create-story for Epic 3: 3k tokens (93% reduction!)
Architecture workflow: Can load specific sections needed
UX design workflow: Can load specific sections needed
Significant token reduction for large requirement docs!
```
### Example 2: Sharding Epics File

2
eslint.config.mjs
View File

@ -16,6 +16,8 @@ export default [
'test/template-test-generator/**/*.md',
'test/fixtures/**',
'test/fixtures/**/*.yaml',
'.bmad/**',
'.bmad*/**',
],
},

4
package-lock.json generated
View File

@ -1,12 +1,12 @@
{
"name": "bmad-method",
"version": "6.0.0-alpha.6",
"version": "6.0.0-alpha.10",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"name": "bmad-method",
"version": "6.0.0-alpha.6",
"version": "6.0.0-alpha.10",
"license": "MIT",
"dependencies": {
"@kayvan/markdown-tree-parser": "^1.6.1",

2
package.json
View File

@ -1,7 +1,7 @@
{
"$schema": "https://json.schemastore.org/package.json",
"name": "bmad-method",
"version": "6.0.0-alpha.9",
"version": "6.0.0-alpha.10",
"description": "Breakthrough Method of Agile AI-driven Development",
"keywords": [
"agile",

5
src/core/workflows/brainstorming/workflow.yaml
View File

@ -9,11 +9,6 @@ output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
date: system-generated
# Optional inputs for guided brainstorming
recommended_inputs:
- session_context: "Context document passed via data attribute"
- previous_results: "{output_folder}/brainstorming-*.md"
# Context can be provided via data attribute when invoking
# Example: data="{path}/context.md" provides domain-specific guidance

4
src/modules/bmb/workflows/convert-legacy/workflow.yaml
View File

@ -10,10 +10,6 @@ user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
date: system-generated
# Optional docs that can be provided as input
recommended_inputs:
- legacy_file: "Path to v4 agent, workflow, or module to convert"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/convert-legacy"
template: false # This is an action/meta workflow - no template needed

4
src/modules/bmb/workflows/create-agent/instructions.md
View File

@ -2,8 +2,10 @@
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/create-agent/workflow.yaml</critical>
<critical>Study YAML agent examples in: {project-root}/{bmad_folder}/bmm/agents/ for patterns</critical>
<critical>Study YAML agent examples in: {example_agents_dir} for patterns</critical>
<critical>Reference activation conventions from: {agent_activation_rules}</critical>
<critical>Communicate in {communication_language} throughout the agent creation process</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<workflow>

7
src/modules/bmb/workflows/create-agent/workflow.yaml
View File

@ -15,10 +15,9 @@ agent_architecture: "{installed_path}/agent-architecture.md"
agent_commands: "{installed_path}/agent-command-patterns.md"
communication_styles: "{installed_path}/communication-styles.md"
# Optional docs that help understand agent patterns
recommended_inputs:
- example_agents: "{project-root}/{bmad_folder}/bmm/agents/"
- agent_activation_rules: "{project-root}/src/utility/models/agent-activation-ide.xml"
# Reference examples and conventions
example_agents_dir: "{project-root}/{bmad_folder}/bmm/agents/"
agent_activation_rules: "{project-root}/src/utility/models/agent-activation-ide.xml"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/create-agent"

1
src/modules/bmb/workflows/create-module/instructions.md
View File

@ -4,6 +4,7 @@
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/create-module/workflow.yaml</critical>
<critical>Study existing modules in: {project-root}/{bmad_folder}/ for patterns</critical>
<critical>Communicate in {communication_language} throughout the module creation process</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<workflow>

24
src/modules/bmb/workflows/create-module/workflow.yaml
View File

@ -19,14 +19,22 @@ workflow_builder: "{project-root}/{bmad_folder}/bmb/workflows/create-workflow/wo
brainstorming_workflow: "{project-root}/{bmad_folder}/core/workflows/brainstorming/workflow.yaml"
brainstorming_context: "{installed_path}/brainstorm-context.md"
# Optional docs that help understand module patterns
recommended_inputs:
- module_brief: "{output_folder}/module-brief-*.md"
- brainstorming_results: "{output_folder}/brainstorming-*.md"
- bmm_module: "{project-root}/{bmad_folder}/bmm/"
- cis_module: "{project-root}/{bmad_folder}/cis/"
- existing_agents: "{project-root}/{bmad_folder}/*/agents/"
- existing_workflows: "{project-root}/{bmad_folder}/*/workflows/"
# Reference examples - for learning patterns
bmm_module_dir: "{project-root}/{bmad_folder}/bmm/"
cis_module_dir: "{project-root}/{bmad_folder}/cis/"
existing_agents_dir: "{project-root}/{bmad_folder}/*/agents/"
existing_workflows_dir: "{project-root}/{bmad_folder}/*/workflows/"
# Optional user inputs - discovered if they exist
input_file_patterns:
module_brief:
description: "Module brief with vision and requirements (optional)"
whole: "{output_folder}/module-brief-*.md"
load_strategy: "FULL_LOAD"
brainstorming:
description: "Brainstorming session outputs (optional)"
whole: "{output_folder}/brainstorming-*.md"
load_strategy: "FULL_LOAD"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/create-module"

1
src/modules/bmb/workflows/create-workflow/instructions.md
View File

@ -5,6 +5,7 @@
<critical>You MUST fully understand the workflow creation guide at: {workflow_creation_guide}</critical>
<critical>Study the guide thoroughly to follow ALL conventions for optimal human-AI collaboration</critical>
<critical>Communicate in {communication_language} throughout the workflow creation process</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<workflow>

25
src/modules/bmb/workflows/create-workflow/workflow-creation-guide.md
View File

@ -974,6 +974,27 @@ _Generated on {{date}}_
3. **Set limits** - "3-5 items maximum"
4. **Explain why** - Context helps AI make better decisions
### Time Estimate Prohibition
**CRITICAL:** For all planning, analysis, and estimation workflows, include this prohibition:
```xml
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
```
**When to include this:**
- Planning workflows (PRDs, tech specs, architecture)
- Analysis workflows (research, brainstorming, product briefs)
- Retrospective workflows (reviews, post-mortems)
- Any workflow discussing project scope or complexity
**When NOT needed:**
- Pure implementation workflows (code generation, refactoring)
- Simple action workflows (file operations, status updates)
- Workflows that only process existing data
### Conditional Execution Best Practices
**✅ DO:**
@ -1067,7 +1088,7 @@ input_file_patterns:
sharded: '{output_folder}/*architecture*/index.md'
document_project:
sharded: '{output_folder}/docs/index.md' # Brownfield always uses index
sharded: '{output_folder}/index.md' # Brownfield always uses index
```
#### 2. Add Discovery Instructions to instructions.md
@ -1087,7 +1108,7 @@ This workflow requires: [list required documents]
- Read `index.md` to understand the document structure
- Read ALL section files listed in the index (or specific sections for selective load)
- Treat the combined content as if it were a single document
4. **Brownfield projects**: The `document-project` workflow creates `{output_folder}/docs/index.md`
4. **Brownfield projects**: The `document-project` workflow creates `{output_folder}/index.md`
**Priority**: If both whole and sharded versions exist, use the whole document.

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

@ -4,6 +4,8 @@
<critical>You MUST have already loaded and processed: {project-related}/{bmad_folder}/{module-code}/workflows/{workflow}/workflow.yaml</critical>
<critical>Communicate in {communication_language} throughout the workflow process</critical>
<!-- For planning/analysis workflows, add: <critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical> -->
<workflow>
<step n="1" goal="">

4
src/modules/bmb/workflows/create-workflow/workflow-template/workflow.yaml
View File

@ -15,10 +15,6 @@ date: system-generated
# optional, can be omitted
brain_techniques: "{installed_path}/{critical-data-file.csv}" # example, can be other formats or URLs
# Optional docs that if loaded on start to kickstart this workflow or used at some point, these are meant to be suggested inputs for the user
recommended_inputs: # optional, can be omitted
- example_input: "{project-root}/{path/to/file.md}"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/{module-code}/workflows/{workflow-code}"
template: "{installed_path}/template.md" # optional, can be omitted

9
src/modules/bmb/workflows/create-workflow/workflow.yaml
View File

@ -15,11 +15,6 @@ template_instructions: "{workflow_template_path}/instructions.md"
template_template: "{workflow_template_path}/template.md"
template_checklist: "{workflow_template_path}/checklist.md"
# Optional input docs
recommended_inputs:
- existing_workflows: "{project-root}/{bmad_folder}/*/workflows/"
- bmm_workflows: "{project-root}/{bmad_folder}/bmm/workflows/"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/create-workflow"
template: false # This is an action workflow - no template needed
@ -30,6 +25,10 @@ validation: "{installed_path}/checklist.md"
workflow_creation_guide: "{installed_path}/workflow-creation-guide.md"
workflow_template_path: "{installed_path}/workflow-template"
# Reference examples - for learning patterns
existing_workflows_dir: "{project-root}/{bmad_folder}/*/workflows/"
bmm_workflows_dir: "{project-root}/{bmad_folder}/bmm/workflows/"
# Output configuration - Creates the new workflow folder with all files
# If workflow belongs to a module: Save to module's workflows folder
# If standalone workflow: Save to custom_workflow_location/{{workflow_name}}

8
src/modules/bmb/workflows/edit-agent/workflow.yaml
View File

@ -17,11 +17,9 @@ communication_styles: "{project-root}/{bmad_folder}/bmb/workflows/create-agent/c
# Workflow execution engine reference
workflow_execution_engine: "{project-root}/{bmad_folder}/core/tasks/workflow.xml"
# Optional docs that can be used to understand the target agent
recommended_inputs:
- target_agent: "Path to the agent.yaml or agent.md file to edit"
- example_agents: "{project-root}/{bmad_folder}/bmm/agents/"
- agent_activation_rules: "{project-root}/src/utility/models/agent-activation-ide.xml"
# Reference examples and conventions
example_agents_dir: "{project-root}/{bmad_folder}/bmm/agents/"
agent_activation_rules: "{project-root}/src/utility/models/agent-activation-ide.xml"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/edit-agent"

4
src/modules/bmb/workflows/edit-module/instructions.md
View File

@ -123,7 +123,9 @@ Let the conversation flow naturally. Build a shared vision of what "better" look
2. **Propose improvements with rationale**
- Suggest specific changes that align with best practices
- Explain WHY each change helps
- Provide examples from reference modules when helpful
- Provide examples from reference modules: {bmm_module_dir}, {bmb_module_dir}, {cis_module_dir}
- Reference agents from: {existing_agents_dir}
- Reference workflows from: {existing_workflows_dir}
- Reference the structure guide's patterns naturally
3. **Collaborate on the approach**

14
src/modules/bmb/workflows/edit-module/workflow.yaml
View File

@ -15,14 +15,12 @@ module_structure_guide: "{project-root}/{bmad_folder}/bmb/workflows/create-modul
agent_editor: "{project-root}/{bmad_folder}/bmb/workflows/edit-agent/workflow.yaml"
workflow_editor: "{project-root}/{bmad_folder}/bmb/workflows/edit-workflow/workflow.yaml"
# Optional docs that can be used to understand the target module
recommended_inputs:
- target_module: "Path to the module directory to edit"
- bmm_module: "{project-root}/{bmad_folder}/bmm/"
- bmb_module: "{project-root}/{bmad_folder}/bmb/"
- cis_module: "{project-root}/{bmad_folder}/cis/"
- existing_agents: "{project-root}/{bmad_folder}/*/agents/"
- existing_workflows: "{project-root}/{bmad_folder}/*/workflows/"
# Reference examples - for learning patterns
bmm_module_dir: "{project-root}/{bmad_folder}/bmm/"
bmb_module_dir: "{project-root}/{bmad_folder}/bmb/"
cis_module_dir: "{project-root}/{bmad_folder}/cis/"
existing_agents_dir: "{project-root}/{bmad_folder}/*/agents/"
existing_workflows_dir: "{project-root}/{bmad_folder}/*/workflows/"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/edit-module"

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

@ -24,7 +24,7 @@
- Workflow creation guide: {workflow_creation_guide}
- Workflow execution engine: {workflow_execution_engine}
- Study example workflows from: {project-root}/{bmad_folder}/bmm/workflows/
- Study example workflows from: {workflow_examples_dir}
</action>
<action>Analyze the workflow deeply:

6
src/modules/bmb/workflows/edit-workflow/workflow.yaml
View File

@ -12,10 +12,8 @@ user_name: "{config_source}:user_name"
workflow_creation_guide: "{project-root}/{bmad_folder}/bmb/workflows/create-workflow/workflow-creation-guide.md"
workflow_execution_engine: "{project-root}/{bmad_folder}/core/tasks/workflow.xml"
# Optional docs that can be used to understand the target workflow
recommended_inputs:
- target_workflow: "Path to the workflow.yaml file to edit"
- workflow_examples: "{project-root}/{bmad_folder}/bmm/workflows/"
# Reference examples
workflow_examples_dir: "{project-root}/{bmad_folder}/bmm/workflows/"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/edit-workflow"

1
src/modules/bmb/workflows/module-brief/instructions.md
View File

@ -3,6 +3,7 @@
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/module-brief/workflow.yaml</critical>
<critical>Communicate in {communication_language} throughout the module brief creation process</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<workflow>

15
src/modules/bmb/workflows/module-brief/workflow.yaml
View File

@ -10,11 +10,16 @@ user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
date: system-generated
# Optional input docs that enhance module planning
recommended_inputs:
- brainstorming_results: "{output_folder}/brainstorming-*.md"
- existing_modules: "{project-root}/{bmad_folder}/"
- module_examples: "{project-root}/{bmad_folder}/bmb/workflows/create-module/module-structure.md"
# Reference examples and documentation
existing_modules_dir: "{project-root}/{bmad_folder}/"
module_structure_guide: "{project-root}/{bmad_folder}/bmb/workflows/create-module/module-structure.md"
# Optional user inputs - discovered if they exist
input_file_patterns:
brainstorming:
description: "Brainstorming session outputs (optional)"
whole: "{output_folder}/brainstorming-*.md"
load_strategy: "FULL_LOAD"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/module-brief"

2
src/modules/bmgd/workflows/1-preproduction/brainstorm-game/instructions.md
View File

@ -2,6 +2,8 @@
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language}</critical>
<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with game-specific context and additional game design techniques</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>

2
src/modules/bmgd/workflows/1-preproduction/game-brief/instructions.md
View File

@ -4,8 +4,10 @@
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>DOCUMENT OUTPUT: Concise, professional, game-design focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>

8
src/modules/bmgd/workflows/1-preproduction/game-brief/workflow.yaml
View File

@ -12,14 +12,6 @@ document_output_language: "{config_source}:document_output_language"
game_dev_experience: "{config_source}:game_dev_experience"
date: system-generated
# Optional input documents
recommended_inputs:
- market_research: "Market research document (optional)"
- brainstorming_results: "Brainstorming session outputs (optional)"
- competitive_analysis: "Competitive game analysis (optional)"
- initial_ideas: "Initial game ideas or notes (optional)"
- reference_games: "List of inspiration games (optional)"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmgd/workflows/1-preproduction/game-brief"
template: "{installed_path}/template.md"

3
src/modules/bmgd/workflows/2-design/gdd/instructions-gdd.md
View File

@ -13,6 +13,7 @@
<critical>If users mention technical details, append to technical_preferences with timestamp</critical>
<critical>DOCUMENT OUTPUT: Concise, clear, actionable game design specs. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
## Input Document Discovery
@ -26,7 +27,7 @@ This workflow requires: game brief, and may reference market research or brownfi
- 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`
4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/index.md`
**Priority**: If both whole and sharded versions exist, use the whole document.

14
src/modules/bmgd/workflows/2-design/gdd/workflow.yaml
View File

@ -24,25 +24,25 @@ default_output_file: "{output_folder}/GDD.md"
# Game type references (loaded based on game type selection)
game_type_guides: "{installed_path}/game-types/"
# Recommended input documents
recommended_inputs:
- game_brief: "{output_folder}/game-brief.md"
- narrative_design: "{output_folder}/narrative-design.md"
- market_research: "{output_folder}/market-research.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
game_brief:
description: "Game vision and core concept (optional)"
whole: "{output_folder}/*game-brief*.md"
sharded: "{output_folder}/*game-brief*/index.md"
load_strategy: "INDEX_GUIDED"
research:
description: "Market or domain research (optional)"
whole: "{output_folder}/*research*.md"
sharded: "{output_folder}/*research*/index.md"
load_strategy: "FULL_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
standalone: true

1
src/modules/bmgd/workflows/2-design/narrative/instructions-narrative.md
View File

@ -9,6 +9,7 @@
<critical>Uses narrative_template for output</critical>
<critical>If users mention gameplay mechanics, note them but keep focus on narrative</critical>
<critical>Facilitate good brainstorming techniques throughout with the user, pushing them to come up with much of the narrative you will help weave together. The goal is for the user to feel that they crafted the narrative and story arc unless they push you to do it all or indicate YOLO</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<step n="0" goal="Check for workflow status" tag="workflow-status">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>

6
src/modules/bmgd/workflows/2-design/narrative/workflow.yaml
View File

@ -20,12 +20,6 @@ template: "{installed_path}/narrative-template.md"
# Output configuration
default_output_file: "{output_folder}/narrative-design.md"
# Recommended input documents
recommended_inputs:
- game_brief: "{output_folder}/game-brief.md"
- gdd: "{output_folder}/GDD.md"
- product_brief: "{output_folder}/product-brief.md"
standalone: true
web_bundle:

6
src/modules/bmgd/workflows/3-technical/game-architecture/checklist.md
View File

@ -2,7 +2,7 @@
**Purpose**: Validate the architecture document itself is complete, implementable, and provides clear guidance for AI agents.
**Note**: This checklist validates the ARCHITECTURE DOCUMENT only. For cross-workflow validation (PRD → Architecture → Stories alignment), use the solutioning-gate-check workflow.
**Note**: This checklist validates the ARCHITECTURE DOCUMENT only. For cross-workflow validation (PRD → Architecture → Stories alignment), use the implementation-readiness workflow.
---
@ -233,8 +233,8 @@
---
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, Architecture, and Stories before beginning implementation.
**Next Step**: Run the **implementation-readiness** workflow to validate alignment between PRD, Architecture, and Stories before beginning implementation.
---
_This checklist validates architecture document quality only. Use solutioning-gate-check for comprehensive readiness validation._
_This checklist validates architecture document quality only. Use implementation-readiness for comprehensive readiness validation._

2
src/modules/bmgd/workflows/3-technical/game-architecture/instructions.md
View File

@ -11,6 +11,8 @@
<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>
<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>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>

16
src/modules/bmgd/workflows/3-technical/game-architecture/workflow.yaml
View File

@ -12,29 +12,31 @@ document_output_language: "{config_source}:document_output_language"
game_dev_experience: "{config_source}:game_dev_experience"
date: system-generated
# Input requirements - We work from GDD, Epics, and optionally Narrative Design
recommended_inputs:
- gdd: "Game Design Document with mechanics, systems, and features"
- epics: "Epic definitions with user stories and acceptance criteria"
- narrative: "Narrative design document with story and character systems (optional)"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
gdd:
description: "Game Design Document with mechanics and systems"
whole: "{output_folder}/*gdd*.md"
sharded: "{output_folder}/*gdd*/index.md"
load_strategy: "INDEX_GUIDED"
epics:
description: "Epic definitions with user stories"
whole: "{output_folder}/*epic*.md"
sharded: "{output_folder}/*epic*/index.md"
load_strategy: "FULL_LOAD"
narrative:
description: "Narrative design with story and characters (optional)"
whole: "{output_folder}/*narrative*.md"
sharded: "{output_folder}/*narrative*/index.md"
load_strategy: "INDEX_GUIDED"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmgd/workflows/3-technical/game-architecture"

6
src/modules/bmgd/workflows/4-production/code-review/workflow.yaml
View File

@ -37,20 +37,24 @@ variables:
# Strategy: SELECTIVE LOAD - only load the specific epic needed for this story review
input_file_patterns:
architecture:
description: "System architecture and decisions"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "All epics with user stories"
whole: "{output_folder}/*epic*.md"
sharded_index: "{output_folder}/*epic*/index.md"
sharded_single: "{output_folder}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
standalone: true

8
src/modules/bmgd/workflows/4-production/correct-course/workflow.yaml
View File

@ -18,26 +18,32 @@ sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-
# Strategy: Load project context for impact analysis
input_file_patterns:
prd:
description: "Product requirements (optional)"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "All epics with user stories"
whole: "{output_folder}/*epic*.md"
sharded: "{output_folder}/*epic*/*.md"
load_strategy: "FULL_LOAD"
architecture:
description: "System architecture and decisions"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/*.md"
load_strategy: "FULL_LOAD"
tech_spec:
description: "Technical specification"
whole: "{output_folder}/tech-spec*.md"
load_strategy: "FULL_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/correct-course"

6
src/modules/bmgd/workflows/4-production/create-story/workflow.yaml
View File

@ -40,26 +40,32 @@ default_output_file: "{story_dir}/{{story_key}}.md"
# Strategy: SELECTIVE LOAD - only load the specific epic needed for this story
input_file_patterns:
prd:
description: "Product requirements (optional)"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/*.md"
load_strategy: "FULL_LOAD"
tech_spec:
description: "Technical specification"
whole: "{output_folder}/tech-spec.md"
load_strategy: "FULL_LOAD"
architecture:
description: "System architecture and decisions"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "All epics with user stories"
whole: "{output_folder}/*epic*.md"
sharded_index: "{output_folder}/*epic*/index.md"
sharded_single: "{output_folder}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"
document_project:
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"

7
src/modules/bmgd/workflows/4-production/dev-story/workflow.yaml
View File

@ -23,24 +23,29 @@ sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-
# Strategy: Load necessary context for story implementation
input_file_patterns:
architecture:
description: "System architecture and decisions"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
tech_spec:
description: "Technical specification"
whole: "{output_folder}/tech-spec*.md"
sharded: "{sprint_artifacts}/tech-spec-epic-*.md"
load_strategy: "SELECTIVE_LOAD"
ux_design:
description: "UX design specification (if UI)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "All epics with user stories"
whole: "{output_folder}/*epic*.md"
sharded_index: "{output_folder}/*epic*/index.md"
sharded_single: "{output_folder}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
# Workflow components

6
src/modules/bmgd/workflows/4-production/epic-tech-context/workflow.yaml
View File

@ -16,27 +16,33 @@ sprint_status: "{sprint_artifacts}/sprint-status.yaml || {output_folder}/sprint-
# Strategy: SELECTIVE LOAD - only load the specific epic needed (epic_num from context)
input_file_patterns:
prd:
description: "Product requirements (optional)"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/*.md"
load_strategy: "FULL_LOAD"
gdd:
description: "Game Design Document (optional)"
whole: "{output_folder}/*gdd*.md"
sharded: "{output_folder}/*gdd*/*.md"
load_strategy: "FULL_LOAD"
architecture:
description: "System architecture and decisions"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "All epics with user stories"
whole: "{output_folder}/*epic*.md"
sharded_index: "{output_folder}/*epic*/index.md"
sharded_single: "{output_folder}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"
document_project:
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"

1
src/modules/bmgd/workflows/4-production/retrospective/instructions.md
View File

@ -4,6 +4,7 @@
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmm/workflows/4-implementation/retrospective/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>
DOCUMENT OUTPUT: Retrospective analysis. Concise insights, lessons learned, action items. User skill level ({user_skill_level}) affects conversation style ONLY, not retrospective content.

5
src/modules/bmgd/workflows/4-production/retrospective/workflow.yaml
View File

@ -24,22 +24,27 @@ required_inputs:
# Strategy: SELECTIVE LOAD - only load the completed epic and relevant retrospectives
input_file_patterns:
epics:
description: "All epics with user stories"
whole: "{output_folder}/*epic*.md"
sharded_index: "{output_folder}/*epic*/index.md"
sharded_single: "{output_folder}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"
previous_retrospective:
description: "Previous retrospective (optional)"
pattern: "{sprint_artifacts}/**/epic-{{prev_epic_num}}-retro-*.md"
load_strategy: "SELECTIVE_LOAD"
architecture:
description: "System architecture and decisions"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
prd:
description: "Product requirements (optional)"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/*.md"
load_strategy: "FULL_LOAD"
document_project:
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/*.md"
load_strategy: "INDEX_GUIDED"

1
src/modules/bmgd/workflows/4-production/sprint-planning/workflow.yaml
View File

@ -38,6 +38,7 @@ variables:
# Strategy: FULL LOAD - sprint planning needs ALL epics to build complete status
input_file_patterns:
epics:
description: "All epics with user stories"
whole: "{output_folder}/*epic*.md"
sharded: "{output_folder}/*epic*/*.md"
load_strategy: "FULL_LOAD"

8
src/modules/bmgd/workflows/4-production/story-context/workflow.yaml
View File

@ -25,27 +25,33 @@ validation: "{installed_path}/checklist.md"
# Strategy: SELECTIVE LOAD - only load the specific epic needed for this story
input_file_patterns:
prd:
description: "Product requirements (optional)"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/*.md"
load_strategy: "FULL_LOAD"
tech_spec:
description: "Technical specification"
whole: "{output_folder}/tech-spec.md"
load_strategy: "FULL_LOAD"
architecture:
description: "System architecture and decisions"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "All epics with user stories"
whole: "{output_folder}/*epic*.md"
sharded_index: "{output_folder}/*epic*/index.md"
sharded_single: "{output_folder}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
# Output configuration

15
src/modules/bmm/agents/analyst.agent.yaml
View File

@ -25,24 +25,25 @@ agent:
- trigger: brainstorm-project
workflow: "{project-root}/{bmad_folder}/bmm/workflows/1-analysis/brainstorm-project/workflow.yaml"
description: Guide me through Brainstorming
description: Guided Brainstorming
- trigger: research
workflow: "{project-root}/{bmad_folder}/bmm/workflows/1-analysis/research/workflow.yaml"
description: Guided Research
- trigger: product-brief
workflow: "{project-root}/{bmad_folder}/bmm/workflows/1-analysis/product-brief/workflow.yaml"
description: Produce Project Brief
description: Create a Project Brief
- trigger: document-project
workflow: "{project-root}/{bmad_folder}/bmm/workflows/document-project/workflow.yaml"
description: Generate comprehensive documentation of an existing Project
- trigger: research
workflow: "{project-root}/{bmad_folder}/bmm/workflows/1-analysis/research/workflow.yaml"
description: Guide me through Research
- trigger: party-mode
workflow: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml"
description: Consult with other expert agents from the party
description: Bring the whole team in to chat with other expert agents from the party
- trigger: advanced-elicitation
exec: "{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml"
description: Advanced elicitation techniques to challenge the LLM to get better results
web-only: true

10
src/modules/bmm/agents/architect.agent.yaml
View File

@ -26,17 +26,17 @@ agent:
- trigger: validate-architecture
validate-workflow: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/architecture/workflow.yaml"
checklist: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/architecture/checklist.md"
document: "{output_folder}/architecture.md"
description: Validate Architecture Document
- trigger: solutioning-gate-check
workflow: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml"
description: Validate solutioning complete, ready for Phase 4 (Level 2-4 only)
- trigger: implementation-readiness
workflow: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness/workflow.yaml"
description: Validate implementation readiness - PRD, UX, Architecture, Epics aligned
- trigger: party-mode
workflow: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml"
description: Consult with other expert agents from the party
description: Bring the whole team in to chat with other expert agents from the party
- trigger: advanced-elicitation
exec: "{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml"
description: Advanced elicitation techniques to challenge the LLM to get better results
web-only: true

10
src/modules/bmm/agents/dev.agent.yaml
View File

@ -10,15 +10,15 @@ agent:
module: bmm
persona:
role: Senior Implementation Engineer
role: Senior Software Engineer
identity: Executes approved stories with strict adherence to acceptance criteria, using Story Context XML and existing code to minimize rework and hallucinations.
communication_style: Succinct and checklist-driven. Cites specific paths and AC IDs. Asks clarifying questions only when inputs missing. Refuses to invent when info lacking.
principles: Story Context XML is the single source of truth. Reuse existing interfaces over rebuilding. Every change maps to specific AC. Tests pass 100% or story isn't done.
communication_style: Succinct. Cites specific paths and AC IDs. Asks clarifying questions only when inputs missing. Refuses to invent when info lacking.
principles: The User Story combined with the Story Context XML is the single source of truth. Reuse existing interfaces over rebuilding. Every change maps to specific AC. ALL past and current tests pass 100% or story isn't ready for review.
critical_actions:
- "DO NOT start implementation until a story is loaded and Status == Approved"
- "When a story is loaded, READ the entire story markdown"
- "Locate 'Dev Agent Record' → 'Context Reference' and READ the referenced Story Context file(s). If none present, HALT and ask user to run @spec-context → *story-context"
- "When a story is loaded, READ the entire story markdown, it is all CRITICAL information you must adhere to when implementing the software solution. Do not skip any sections."
- "Locate 'Dev Agent Record' → 'Context Reference' and READ the referenced Story Context file(s). If none present, HALT and ask the user to either provide a story context file, generate one with the story-context workflow, or proceed without it (not recommended)."
- "Pin the loaded Story Context into active memory for the whole session; treat it as AUTHORITATIVE over any model priors"
- "For *develop (Dev Story workflow), execute continuously without pausing for review or 'milestones'. Only halt for explicit blocker conditions (e.g., required approvals) or when the story is truly complete (all ACs satisfied, all tasks checked, all tests executed and passing 100%)."

42
src/modules/bmm/agents/frame-expert.agent.yaml Normal file
View File

@ -0,0 +1,42 @@
# Frame Expert Agent Definition
agent:
webskip: true
metadata:
id: "{bmad_folder}/bmm/agents/frame-expert.md"
name: Saif
title: Visual Design & Diagramming Expert
icon: 📐
module: bmm
persona:
role: Expert Visual Designer & Diagramming Specialist
identity: Expert who creates visual representations using Excalidraw with optimized, reusable components. Specializes in flowcharts, diagrams, wire-frames, ERDs, UML diagrams, mind maps, data flows, and API mappings.
communication_style: Visual-first, structured, detail-oriented, composition-focused. Presents options as numbered lists for easy selection.
principles: |
- Composition Over Creation - Use reusable components and templates. Minimal Payload - Strip unnecessary metadata, optimize serialization.
- Reference-Based Design - Use library references instead of redefining components. Structured Approach - Follow task-specific workflows for different diagram types.
- Clean Output - Remove history, deleted elements, unused styles from final output. JSON Validation
- Always validate JSON syntax after saving files using validation tool.
- Error Recovery - NEVER delete files due to syntax errors, always fix them using error location information.
menu:
- trigger: flowchart
workflow: "{project-root}/{bmad_folder}/bmm/workflows/frame-expert/create-flowchart/workflow.yaml"
description: Create flowchart for processes, pipelines, or logic flows
- trigger: diagram
workflow: "{project-root}/{bmad_folder}/bmm/workflows/frame-expert/create-diagram/workflow.yaml"
description: Create system architecture or general technical diagram
- trigger: dataflow
workflow: "{project-root}/{bmad_folder}/bmm/workflows/frame-expert/create-dataflow/workflow.yaml"
description: Create data flow diagram
- trigger: wireframe
workflow: "{project-root}/{bmad_folder}/bmm/workflows/frame-expert/create-wireframe/workflow.yaml"
description: Create website or app wireframe
- trigger: party-mode
workflow: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml"
description: Bring the whole team in to chat with other expert agents from the party

13
src/modules/bmm/agents/pm.agent.yaml
View File

@ -18,7 +18,8 @@ agent:
menu:
- trigger: workflow-init
workflow: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/init/workflow.yaml"
description: Start a new sequenced workflow path (START HERE!)
description: Start a new sequenced workflow path
ide-only: true
- trigger: workflow-status
workflow: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/workflow.yaml"
@ -26,10 +27,10 @@ agent:
- trigger: create-prd
workflow: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/prd/workflow.yaml"
description: Create Product Requirements Document (PRD) for Level 2-4 projects
description: Create Product Requirements Document (PRD)
- trigger: create-epics-and-stories
workflow: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
workflow: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/workflow.yaml"
description: Break PRD requirements into implementable epics and stories
- trigger: validate-prd
@ -40,7 +41,7 @@ agent:
- trigger: tech-spec
workflow: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml"
description: Create Tech Spec for Level 0-1 (sometimes Level 2) projects
description: Create Tech Spec (Simple work efforts, no PRD or Architecture docs)
- trigger: validate-tech-spec
validate-workflow: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/tech-spec/workflow.yaml"
@ -51,11 +52,13 @@ agent:
- trigger: correct-course
workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/correct-course/workflow.yaml"
description: Course Correction Analysis
ide-only: true
- trigger: party-mode
workflow: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml"
description: Consult with other expert agents from the party
description: Bring the whole team in to chat with other expert agents from the party
- trigger: advanced-elicitation
exec: "{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml"
description: Advanced elicitation techniques to challenge the LLM to get better results
web-only: true

11
src/modules/bmm/agents/sm.agent.yaml
View File

@ -15,7 +15,7 @@ agent:
principles: Strict boundaries between story prep and implementation. Stories are single source of truth. Perfect alignment between PRD and dev execution. Enable efficient sprints.
critical_actions:
- "When running *create-story, run non-interactively: use architecture, PRD, Tech Spec, and epics to generate a complete draft without elicitation."
- "When running *create-story, always run as *yolo. Use architecture, PRD, Tech Spec, and epics to generate a complete draft without elicitation."
menu:
- trigger: workflow-status
@ -26,7 +26,7 @@ agent:
workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
description: Generate or update sprint-status.yaml from epic files
- trigger: epic-tech-context
- trigger: create-epic-tech-context
workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/epic-tech-context/workflow.yaml"
description: (Optional) Use the PRD and Architecture to create a Epic-Tech-Spec for a specific epic
@ -42,11 +42,11 @@ agent:
validate-workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/create-story/workflow.yaml"
description: (Optional) Validate Story Draft with Independent Review
- trigger: story-context
- trigger: create-story-context
workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/story-context/workflow.yaml"
description: (Optional) Assemble dynamic Story Context (XML) from latest docs and code and mark story ready for dev
- trigger: validate-story-context
- trigger: validate-create-story-context
validate-workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/story-context/workflow.yaml"
description: (Optional) Validate latest Story Context XML against checklist
@ -65,8 +65,9 @@ agent:
- trigger: party-mode
workflow: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml"
description: Consult with other expert agents from the party
description: Bring the whole team in to chat with other expert agents from the party
- trigger: advanced-elicitation
exec: "{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml"
description: Advanced elicitation techniques to challenge the LLM to get better results
web-only: true

3
src/modules/bmm/agents/tea.agent.yaml
View File

@ -59,8 +59,9 @@ agent:
- trigger: party-mode
workflow: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml"
description: Consult with other expert agents from the party
description: Bring the whole team in to chat with other expert agents from the party
- trigger: advanced-elicitation
exec: "{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml"
description: Advanced elicitation techniques to challenge the LLM to get better results
web-only: true

3
src/modules/bmm/agents/tech-writer.agent.yaml
View File

@ -60,8 +60,9 @@ agent:
- trigger: party-mode
workflow: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml"
description: Consult with other expert agents from the party
description: Bring the whole team in to chat with other expert agents from the party
- trigger: advanced-elicitation
exec: "{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml"
description: Advanced elicitation techniques to challenge the LLM to get better results
web-only: true

5
src/modules/bmm/agents/ux-designer.agent.yaml
View File

@ -19,7 +19,7 @@ agent:
workflow: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/workflow.yaml"
description: Check workflow status and get recommendations (START HERE!)
- trigger: create-design
- trigger: create-ux-design
workflow: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/create-ux-design/workflow.yaml"
description: Conduct Design Thinking Workshop to Define the User Specification
@ -31,8 +31,9 @@ agent:
- trigger: party-mode
workflow: "{project-root}/{bmad_folder}/core/workflows/party-mode/workflow.yaml"
description: Consult with other expert agents from the party
description: Bring the whole team in to chat with other expert agents from the party
- trigger: advanced-elicitation
exec: "{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml"
description: Advanced elicitation techniques to challenge the LLM to get better results
web-only: true

3
src/modules/bmm/docs/README.md
View File

@ -117,7 +117,8 @@ Comprehensive documentation for all BMM workflows organized by phase:
- Which planning workflow to use
- **[Phase 3: Solutioning Workflows](./workflows-solutioning.md)** - Architecture and validation (638 lines)
- architecture, solutioning-gate-check
- architecture, create-epics-and-stories, implementation-readiness
- V6: Epics created AFTER architecture for better quality
- Required for BMad Method and Enterprise Method tracks
- Preventing agent conflicts

46
src/modules/bmm/docs/agents-guide.md
View File

@ -63,7 +63,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
- Creating Product Requirements Documents (PRD) for Level 2-4 projects
- Creating technical specifications for small projects (Level 0-1)
- Breaking down requirements into epics and stories
- Breaking down requirements into epics and stories (after architecture)
- Validating planning documents
- Course correction during implementation
@ -72,10 +72,10 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
**Workflows:**
- `workflow-status` - Check what to do next
- `create-prd` - Create PRD for Level 2-4 projects
- `create-prd` - Create PRD for Level 2-4 projects (creates FRs/NFRs only)
- `tech-spec` - Quick spec for Level 0-1 projects
- `create-epics-and-stories` - Break PRD into implementable pieces
- `validate-prd` - Validate PRD + Epics completeness
- `create-epics-and-stories` - Break PRD into implementable pieces (runs AFTER architecture)
- `validate-prd` - Validate PRD completeness
- `validate-tech-spec` - Validate Technical Specification
- `correct-course` - Handle mid-project changes
- `workflow-init` - Initialize workflow tracking
@ -136,7 +136,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
- Creating system architecture for Level 2-4 projects
- Making technical design decisions
- Validating architecture documents
- Solutioning gate checks (Phase 3→4 transition)
- Validating readiness for implementation phase (Phase 3→4 transition)
- Course correction during implementation
**Primary Phase:** Phase 3 (Solutioning)
@ -146,7 +146,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
- `workflow-status` - Check what to do next
- `create-architecture` - Produce a Scale Adaptive Architecture
- `validate-architecture` - Validate architecture document
- `solutioning-gate-check` - Validate readiness for Phase 4
- `implementation-readiness` - Validate readiness for Phase 4
**Communication Style:** Comprehensive yet pragmatic. Uses architectural metaphors. Balances technical depth with accessibility. Connects decisions to business value.
@ -482,7 +482,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
- Game system architecture
- Technical foundation design for games
- Solutioning gate checks for game projects
- Validating readiness for implementation phase (game projects)
- Course correction during game development
**Primary Phase:** Phase 3 (Solutioning - Games)
@ -491,7 +491,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
- `workflow-status` - Check what to do next
- `create-architecture` - Game systems architecture
- `solutioning-gate-check` - Validate Phase 3→4 transition
- `implementation-readiness` - Validate Phase 3→4 transition
- `correct-course` - Handle technical changes
**Communication Style:** Calm and measured. Systematic thinking about complex systems. Uses chess metaphors and military strategy. Emphasizes balance and elegance.
@ -604,15 +604,15 @@ Some workflows are available to multiple agents:
Many workflows have optional validation workflows that perform independent review:
| Validation | Agent | Validates |
| ---------------------------- | ----------- | ---------------------------------- |
| `validate-prd` | PM | PRD + Epics + Stories completeness |
| `validate-tech-spec` | PM | Technical specification quality |
| `validate-architecture` | Architect | Architecture document |
| `validate-design` | UX Designer | UX specification and artifacts |
| `validate-epic-tech-context` | SM | Epic technical context |
| `validate-create-story` | SM | Story draft |
| `validate-story-context` | SM | Story context XML |
| Validation | Agent | Validates |
| ---------------------------- | ----------- | -------------------------------- |
| `validate-prd` | PM | PRD completeness (FRs/NFRs only) |
| `validate-tech-spec` | PM | Technical specification quality |
| `validate-architecture` | Architect | Architecture document |
| `validate-design` | UX Designer | UX specification and artifacts |
| `validate-epic-tech-context` | SM | Epic technical context |
| `validate-create-story` | SM | Story draft |
| `validate-story-context` | SM | Story context XML |
**When to use validation:**
@ -849,7 +849,8 @@ Load the customized agent and verify the changes are reflected in its behavior a
2. Analyst: *brainstorm-project or *product-brief (optional)
3. PM: *create-prd (Level 2-4) or *tech-spec (Level 0-1)
4. Architect: *create-architecture (Level 3-4 only)
5. SM: *sprint-planning
5. PM: *create-epics-and-stories (after architecture)
6. SM: *sprint-planning
```
**Starting with Existing Code (Brownfield):**
@ -859,7 +860,8 @@ Load the customized agent and verify the changes are reflected in its behavior a
2. PM or Analyst: *workflow-init
3. PM: *create-prd or *tech-spec
4. Architect: *create-architecture (if needed)
5. SM: *sprint-planning
5. PM: *create-epics-and-stories (after architecture)
6. SM: *sprint-planning
```
**Story Development Cycle:**
@ -911,7 +913,7 @@ Agent analyzes project state → recommends next workflow
```
Each phase has validation gates:
- Phase 2→3: validate-prd, validate-tech-spec
- Phase 3→4: solutioning-gate-check
- Phase 3→4: implementation-readiness
Run validation before advancing
```
@ -943,14 +945,14 @@ Quick reference for agent selection:
| **Analyst** | 📊 | 1 (Analysis) | brainstorm, brief, research, document-project | Discovery, requirements, brownfield |
| **PM** | 📋 | 2 (Planning) | prd, tech-spec, epics-stories | Planning, requirements docs |
| **UX Designer** | 🎨 | 2 (Planning) | create-design, validate-design | UX-heavy projects, design |
| **Architect** | 🏗️ | 3 (Solutioning) | architecture, gate-check | Technical design, architecture |
| **Architect** | 🏗️ | 3 (Solutioning) | architecture, implementation-readiness | Technical design, architecture |
| **SM** | 🏃 | 4 (Implementation) | sprint-planning, create-story, story-context | Story management, sprint coordination |
| **DEV** | 💻 | 4 (Implementation) | develop-story, code-review, story-done | Implementation, coding |
| **TEA** | 🧪 | All Phases | framework, atdd, automate, trace, ci | Testing, quality assurance |
| **Paige (Tech Writer)** | 📚 | All Phases | document-project, diagrams, validation | Documentation, diagrams |
| **Game Designer** | 🎲 | 1-2 (Games) | brainstorm-game, gdd, narrative | Game design, creative vision |
| **Game Developer** | 🕹️ | 4 (Games) | develop-story, story-done, code-review | Game implementation |
| **Game Architect** | 🏛️ | 3 (Games) | architecture, gate-check | Game systems architecture |
| **Game Architect** | 🏛️ | 3 (Games) | architecture, implementation-readiness | Game systems architecture |
| **BMad Master** | 🧙 | Meta | party-mode, list tasks/workflows | Orchestration, multi-agent |
### Agent Capabilities Summary

30
src/modules/bmm/docs/brownfield-guide.md
View File

@ -291,9 +291,10 @@ See the [Workflows section in BMM README](../README.md) for details.
**BMad Method/Enterprise:** Use `prd` workflow
- Creates PRD.md + epic breakdown
- Creates PRD.md with FRs/NFRs only
- References existing architecture
- Plans integration points
- Epics+Stories created AFTER architecture phase
**Brownfield-specific:** See [Scale Adaptive System](./scale-adaptive-system.md) for complete workflow paths by track.
@ -309,7 +310,8 @@ See the [Workflows section in BMM README](../README.md) for details.
**Workflows:**
- `create-architecture` - Extend architecture docs (BMad Method/Enterprise)
- `solutioning-gate-check` - Validate before implementation (BMad Method/Enterprise)
- `create-epics-and-stories` - Create epics and stories AFTER architecture
- `implementation-readiness` - Validate before implementation (BMad Method/Enterprise)
### Phase 4: Implementation (All Tracks)
@ -473,8 +475,8 @@ Document in tech-spec/architecture:
1. **Document:** Run `document-project` (Deep scan) - Critical for understanding existing UI patterns
2. **Analyze:** Load Analyst → `research` (if evaluating analytics libraries)
3. **Plan:** Load PM → `prd`
4. **Solution:** Load Architect → `create-architecture` → `solutioning-gate-check`
3. **Plan:** Load PM → `prd` (creates FRs/NFRs)
4. **Solution:** Load Architect → `create-architecture` → `create-epics-and-stories` → `implementation-readiness`
5. **Implement:** Sprint-based (10-15 stories)
- Load SM → `sprint-planning`
- Per epic: `epic-tech-context` → stories
@ -495,10 +497,11 @@ Document in tech-spec/architecture:
1. **Document:** Run `document-project` (Exhaustive if not documented) - **Mandatory**
2. **Analyze:** Load Analyst → `research` (WebSocket vs WebRTC vs CRDT)
3. **Plan:** Load PM → `prd`
3. **Plan:** Load PM → `prd` (creates FRs/NFRs)
4. **Solution:**
- Load Architect → `create-architecture` (extend for real-time layer)
- Load Architect → `solutioning-gate-check`
- Load Architect → `create-epics-and-stories`
- Load Architect → `implementation-readiness`
5. **Implement:** Sprint-based (20-30 stories)
**Time:** 3-6 weeks
@ -518,13 +521,14 @@ Document in tech-spec/architecture:
- `brainstorm-project` - Explore multi-tenancy approaches
- `research` - Database sharding, tenant isolation, pricing
- `product-brief` - Strategic document
3. **Plan:** Load PM → `prd` (comprehensive)
3. **Plan:** Load PM → `prd` (comprehensive FRs/NFRs)
4. **Solution:**
- `create-architecture` - Full system architecture
- `integration-planning` - Phased migration strategy
- `create-architecture` - Multi-tenancy architecture
- `validate-architecture` - External review
- `solutioning-gate-check` - Executive approval
- `create-epics-and-stories` - Create epics and stories
- `implementation-readiness` - Executive approval
5. **Implement:** Phased sprint-based (50+ stories)
**Time:** 3-6 months
@ -634,7 +638,8 @@ prd # BMad Method/Enterprise tracks
# Phase 3: Solutioning (BMad Method/Enterprise)
# Architect agent:
create-architecture # Extend architecture
solutioning-gate-check # Final validation
create-epics-and-stories # Create epics and stories (after architecture)
implementation-readiness # Final validation
# Phase 4: Implementation (All Tracks)
# SM agent:
@ -668,8 +673,11 @@ correct-course # If issues
**Phase 2 Planning:**
- `docs/tech-spec.md` (Quick Flow track)
- `docs/PRD.md` (BMad Method/Enterprise tracks)
- Epic breakdown
- `docs/PRD.md` (BMad Method/Enterprise tracks - FRs/NFRs only)
**Phase 3 Solutioning:**
- Epic breakdown (created after architecture)
**Phase 3 Architecture:**

66
src/modules/bmm/docs/enterprise-agentic-development.md
View File

@ -140,34 +140,15 @@ bmad pm *create-prd
**BMad produces:**
- Structured, machine-readable requirements
- Testable acceptance criteria per requirement
- Clear epic/story decomposition
- Functional Requirements (FRs) with testable acceptance criteria
- Non-Functional Requirements (NFRs) with measurable targets
- Technical context for AI agents
**Why it matters:** Traditional PRDs are human-readable prose. BMad PRDs are **AI-executable work packages**.
**Why it matters:** Traditional PRDs are human-readable prose. BMad PRDs are **AI-executable requirement specifications**.
**PM Value:** Write once, automatically translated into agent-ready stories. No engineering bottleneck for translation.
**PM Value:** Clear requirements that feed into architecture decisions, then into story breakdown. No ambiguity.
### 2. Automated Epic/Story Breakdown
**PM Workflow:**
```bash
bmad pm *create-epics-and-stories
```
**BMad produces:**
- Epic files with clear objectives
- Story files with acceptance criteria, context, technical guidance
- Priority assignments (P0-P3)
- Dependency mapping
**Why it matters:** Stories become **work packages for cloud AI agents**. Each story is self-contained with full context.
**PM Value:** No more "story refinement sessions" with engineering. AI agents execute directly from BMad stories.
### 3. Human-in-the-Loop Architecture
### 2. Human-in-the-Loop Architecture
**Architect/PM Workflow:**
@ -177,23 +158,46 @@ bmad architect *create-architecture
**BMad produces:**
- System architecture aligned with PRD
- System architecture aligned with PRD's FRs/NFRs
- Architecture Decision Records (ADRs)
- Epic-specific technical guidance
- FR/NFR-specific technical guidance
- Integration patterns and standards
**Why it matters:** PMs can **understand and validate** technical decisions. Architecture is conversational, not template-driven.
**PM Value:** Technical fluency built through guided architecture process. PMs learn while creating.
### 3. Automated Epic/Story Breakdown (AFTER Architecture)
**PM Workflow:**
```bash
bmad pm *create-epics-and-stories
```
**V6 Improvement:** Epics and stories are now created AFTER architecture for better quality. The workflow uses both PRD (FRs/NFRs) and Architecture to create technically-informed stories.
**BMad produces:**
- Epic files with clear objectives
- Story files with acceptance criteria, context, technical guidance
- Priority assignments (P0-P3)
- Dependency mapping informed by architectural decisions
**Why it matters:** Stories become **work packages for cloud AI agents**. Each story is self-contained with full context AND aligned with architecture.
**PM Value:** No more "story refinement sessions" with engineering. Stories are technically grounded from the start.
### 4. Cloud Agentic Pipeline (Emerging Pattern)
**Current State (2025):**
```
PM writes BMad PRD
PM writes BMad PRD (FRs/NFRs)
↓
create-epics-and-stories generates story queue
Architect creates architecture (technical decisions)
↓
create-epics-and-stories generates story queue (informed by architecture)
↓
Stories loaded by human developers + BMad agents
↓
@ -207,9 +211,11 @@ Merge and deploy
**Near Future (2026):**
```
PM writes BMad PRD
PM writes BMad PRD (FRs/NFRs)
↓
create-epics-and-stories generates story queue
Architecture auto-generated with PM approval
↓
create-epics-and-stories generates story queue (informed by architecture)
↓
Stories automatically fed to cloud AI agent pool
↓

7
src/modules/bmm/docs/faq.md
View File

@ -147,7 +147,7 @@ If status file exists, use workflow-status. If not, use workflow-init.
### Q: How do I know when Phase 3 is complete and I can start Phase 4?
**A:** For Level 3-4, run the solutioning-gate-check workflow. It validates that PRD, architecture, and UX (if applicable) are cohesive before implementation. Pass the gate check = ready for Phase 4.
**A:** For Level 3-4, run the implementation-readiness workflow. It validates that PRD (FRs/NFRs), architecture, epics+stories, and UX (if applicable) are cohesive before implementation. Pass the gate check = ready for Phase 4.
### Q: Can I run workflows in parallel or do they have to be sequential?
@ -155,7 +155,7 @@ If status file exists, use workflow-status. If not, use workflow-init.
- Phase 1: brainstorm → research → product-brief (optional order)
- Phase 2: PRD must complete before moving forward
- Phase 3: architecture → validate → gate-check (sequential)
- Phase 3: architecture → epics+stories → implementation-readiness (sequential)
- Phase 4: Stories within an epic should generally be sequential, but stories in different epics can be parallel if you have capacity
---
@ -175,8 +175,9 @@ Think of it as: tech-spec is for small projects (replaces PRD and architecture),
**A:** Level 2+ projects need product-level planning (PRD) and system-level design (Architecture), which tech-spec doesn't provide. Tech-spec is too narrow for coordinating multiple features. Instead, Level 2-4 uses:
- PRD (product vision, requirements, epics)
- PRD (product vision, functional requirements, non-functional requirements)
- Architecture (system design)
- Epics+Stories (created AFTER architecture is complete)
- Epic-tech-context (detailed implementation per epic, created just-in-time)
### Q: When do I create epic-tech-context?

4
src/modules/bmm/docs/glossary.md
View File

@ -77,7 +77,7 @@ The methodology path (Quick Flow, BMad Method, or Enterprise Method) chosen for
### PRD (Product Requirements Document)
**BMad Method/Enterprise tracks.** Product-level planning document containing vision, goals, feature requirements, epic breakdown, success criteria, and UX considerations. Replaces tech-spec for larger projects that need product planning.
**BMad Method/Enterprise tracks.** Product-level planning document containing vision, goals, Functional Requirements (FRs), Non-Functional Requirements (NFRs), success criteria, and UX considerations. Replaces tech-spec for larger projects that need product planning. **V6 Note:** PRD focuses on WHAT to build (requirements). Epic+Stories are created separately AFTER architecture via create-epics-and-stories workflow.
### Architecture Document
@ -263,7 +263,7 @@ Workflow that initializes Phase 4 implementation by creating sprint-status.yaml,
### Gate Check
Validation workflow (solutioning-gate-check) run before Phase 4 to ensure PRD, architecture, and UX documents are cohesive with no gaps or contradictions. Required for BMad Method and Enterprise Method tracks.
Validation workflow (implementation-readiness) run before Phase 4 to ensure PRD, architecture, and UX documents are cohesive with no gaps or contradictions. Required for BMad Method and Enterprise Method tracks.
### DoD (Definition of Done)

24
src/modules/bmm/docs/quick-start.md
View File

@ -122,7 +122,7 @@ For v4 users or those who prefer to skip workflow-status guidance:
- **Analyst** → Brainstorming, Product Brief
- **PM** → PRD (BMad Method/Enterprise tracks) OR tech-spec (Quick Flow track)
- **UX-Designer** → UX Design Document (if UI-heavy)
- **UX-Designer** → UX Design Document (if UI part of the project)
- **Architect** → Architecture (BMad Method/Enterprise tracks)
#### Phase 2: Planning - Creating the PRD
@ -133,7 +133,6 @@ For v4 users or those who prefer to skip workflow-status guidance:
2. Tell it to run the PRD workflow
3. Once complete, you'll have:
- **PRD.md** - Your Product Requirements Document
- Epic breakdown
**For Quick Flow track:**
@ -145,7 +144,7 @@ If your project has a user interface:
1. Load the **UX-Designer agent** in a new chat
2. Tell it to run the UX design workflow
3. After completion, run validations to ensure the Epics file stays updated
3. After completion, you'll have your UX specification document
#### Phase 3: Architecture
@ -153,14 +152,25 @@ If your project has a user interface:
1. Load the **Architect agent** in a new chat
2. Tell it to run the create-architecture workflow
3. After completion, run validations to ensure the Epics file stays updated
3. After completion, you'll have your architecture document with technical decisions
#### Phase 3: Solutioning Gate Check (Highly Recommended)
#### Phase 3: Create Epics and Stories (REQUIRED after Architecture)
Once architecture is complete:
**V6 Improvement:** Epics and stories are now created AFTER architecture for better quality!
1. Load the **PM agent** in a new chat
2. Tell it to run "create-epics-and-stories"
3. This breaks down your PRD's FRs/NFRs into implementable epics and stories
4. The workflow uses both PRD and Architecture to create technically-informed stories
**Why after architecture?** Architecture decisions (database, API patterns, tech stack) directly affect how stories should be broken down and sequenced.
#### Phase 3: Implementation Readiness Check (Highly Recommended)
Once epics and stories are created:
1. Load the **Architect agent** in a new chat
2. Tell it to run "solutioning-gate-check"
2. Tell it to run "implementation-readiness"
3. This validates cohesion across all your planning documents (PRD, UX, Architecture, Epics)
4. This was called the "PO Master Checklist" in v4

55
src/modules/bmm/docs/scale-adaptive-system.md
View File

@ -154,10 +154,10 @@ Tech-Spec → Implement
**Planning Docs**:
- PRD.md (product requirements)
- PRD.md (functional and non-functional requirements)
- Architecture.md (system design)
- UX Design (if UI components)
- Epic breakdown with stories
- Epics and Stories (created after architecture)
**Workflow Path**:
@ -166,7 +166,7 @@ Tech-Spec → Implement
↓
(Optional: Analysis phase - brainstorm, research, product brief)
↓
PRD → (Optional UX) → Architecture → Gate Check → Implement
PRD → (Optional UX) → Architecture → Create Epics and Stories → Implementation Readiness Check → Implement
```
**Use For**:
@ -228,9 +228,11 @@ Your brownfield documentation might be huge. Architecture workflow distills mass
↓
Analysis (recommended/required) → PRD → UX → Architecture
↓
Create Epics and Stories
↓
Security Architecture → DevOps Strategy → Test Strategy
↓
Gate Check → Implement
Implementation Readiness Check → Implement
```
**Use For**:
@ -287,12 +289,14 @@ Gate Check → Implement
**PRD (Product Requirements Document)**:
- Product vision and goals
- Feature requirements
- Epic breakdown with stories
- Functional requirements (FRs)
- Non-functional requirements (NFRs)
- Success criteria
- User experience considerations
- Business context
**Note**: Epics and stories are created AFTER architecture in the create-epics-and-stories workflow
**Architecture Document**:
- System components and responsibilities
@ -444,11 +448,12 @@ flowchart TD
**Workflow**:
1. (Recommended) Product Brief
2. PRD with epics
2. PRD (FRs/NFRs)
3. (If UI) UX Design
4. Architecture (system design)
5. Gate Check
6. Implement with sprint planning
5. Create Epics and Stories
6. Implementation Readiness Check
7. Implement with sprint planning
**Time**: 1-2 weeks
@ -465,11 +470,12 @@ flowchart TD
**Workflow**:
1. Research + Product Brief
2. Comprehensive PRD
2. Comprehensive PRD (FRs/NFRs)
3. UX Design (recommended)
4. System Architecture (required)
5. Gate check
6. Implement with phased approach
5. Create Epics and Stories
6. Implementation Readiness Check
7. Implement with phased approach
**Time**: 3-6 weeks
@ -487,7 +493,13 @@ flowchart TD
1. **Run document-project** to analyze existing codebase
**Then Workflow**: 2. PRD for search feature 3. Architecture (integration design - highly recommended) 4. Implement following existing patterns
**Then Workflow**:
2. PRD for search feature (FRs/NFRs)
3. Architecture (integration design - highly recommended)
4. Create Epics and Stories
5. Implementation Readiness Check
6. Implement following existing patterns
**Time**: 1-2 weeks
@ -507,13 +519,14 @@ flowchart TD
1. Document-project (mandatory)
2. Research (compliance, security)
3. PRD (multi-tenancy requirements)
3. PRD (multi-tenancy requirements - FRs/NFRs)
4. Architecture (tenant isolation design)
5. Security Architecture (data isolation, auth)
6. DevOps Strategy (tenant provisioning, monitoring)
7. Test Strategy (tenant isolation testing)
8. Gate check
9. Phased implementation
5. Create Epics and Stories
6. Security Architecture (data isolation, auth)
7. DevOps Strategy (tenant provisioning, monitoring)
8. Test Strategy (tenant isolation testing)
9. Implementation Readiness Check
10. Phased implementation
**Time**: 3-6 months
@ -533,9 +546,9 @@ If `workflow-init` suggests BMad Method, there's probably complexity you haven't
Uncertain between Quick Flow and Method? Start with Quick Flow. You can create PRD later if needed.
### 4. Don't Skip Gate Checks
### 4. Don't Skip Implementation Readiness Check
For BMad Method and Enterprise, gate checks prevent costly mistakes. Invest the time.
For BMad Method and Enterprise, implementation readiness checks prevent costly mistakes. Invest the time.
### 5. Architecture is Optional but Recommended for Brownfield

88
src/modules/bmm/docs/test-architecture.md
View File

@ -18,21 +18,23 @@ TEA integrates into the BMad development lifecycle during Solutioning (Phase 3)
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#fff','primaryTextColor':'#000','primaryBorderColor':'#000','lineColor':'#000','secondaryColor':'#fff','tertiaryColor':'#fff','fontSize':'16px','fontFamily':'arial'}}}%%
graph TB
subgraph Phase2["<b>Phase 2: PLANNING</b>"]
PM["<b>PM: *prd (creates PRD + epics)</b>"]
PM["<b>PM: *prd (creates PRD with FRs/NFRs)</b>"]
PlanNote["<b>Business requirements phase</b>"]
PM -.-> PlanNote
end
subgraph Phase3["<b>Phase 3: SOLUTIONING</b>"]
Architecture["<b>Architect: *architecture</b>"]
EpicsStories["<b>PM/Architect: *create-epics-and-stories</b>"]
Framework["<b>TEA: *framework</b>"]
CI["<b>TEA: *ci</b>"]
GateCheck["<b>Architect: *solutioning-gate-check</b>"]
Architecture --> Framework
GateCheck["<b>Architect: *implementation-readiness</b>"]
Architecture --> EpicsStories
EpicsStories --> Framework
Framework --> CI
CI --> GateCheck
Phase3Note["<b>Test infrastructure AFTER architecture</b><br/>defines technology stack"]
Framework -.-> Phase3Note
Phase3Note["<b>Epics created AFTER architecture,</b><br/><b>then test infrastructure setup</b>"]
EpicsStories -.-> Phase3Note
end
subgraph Phase4["<b>Phase 4: IMPLEMENTATION - Per Epic Cycle</b>"]
@ -90,8 +92,8 @@ graph TB
- **Phase 0** (Optional): Documentation (brownfield prerequisite - `*document-project`)
- **Phase 1** (Optional): Discovery/Analysis (`*brainstorm`, `*research`, `*product-brief`)
- **Phase 2** (Required): Planning (`*prd` creates PRD + epics)
- **Phase 3** (Track-dependent): Solutioning (`*architecture` → TEA: `*framework`, `*ci` → `*solutioning-gate-check`)
- **Phase 2** (Required): Planning (`*prd` creates PRD with FRs/NFRs)
- **Phase 3** (Track-dependent): Solutioning (`*architecture` → `*create-epics-and-stories` → TEA: `*framework`, `*ci` → `*implementation-readiness`)
- **Phase 4** (Required): Implementation (`*sprint-planning` → per-epic: `*test-design` → per-story: dev workflows)
**TEA workflows:** `*framework` and `*ci` run once in Phase 3 after architecture. `*test-design` runs per-epic in Phase 4. Output: `test-design-epic-N.md`.
@ -191,16 +193,16 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
**Planning Track:** BMad Method (PRD + Architecture)
**Use Case:** New projects with standard complexity
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| -------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------- |
| **Phase 1**: Discovery | - | Analyst `*product-brief` (optional) | `product-brief.md` |
| **Phase 2**: Planning | - | PM `*prd` (creates PRD + epics) | PRD, epics |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture | Architect `*architecture`, `*solutioning-gate-check` | Architecture, test scaffold, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint status file with all epics and stories |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic (per-epic test plan) | Review epic scope | `test-design-epic-N.md` with risk assessment and test plan |
| **Phase 4**: Story Dev | (Optional) `*atdd` before dev, then `*automate` after | SM `*create-story`, DEV implements | Tests, story implementation |
| **Phase 4**: Story Review | Execute `*test-review` (optional), re-run `*trace` | Address recommendations, update code/tests | Quality report, refreshed coverage matrix |
| **Phase 4**: Release Gate | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Confirm Definition of Done, share release notes | Quality audit, Gate YAML + release summary |
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| -------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| **Phase 1**: Discovery | - | Analyst `*product-brief` (optional) | `product-brief.md` |
| **Phase 2**: Planning | - | PM `*prd` (creates PRD with FRs/NFRs) | PRD with functional/non-functional requirements |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture and epic creation | Architect `*architecture`, `*create-epics-and-stories`, `*implementation-readiness` | Architecture, epics/stories, test scaffold, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint status file with all epics and stories |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic (per-epic test plan) | Review epic scope | `test-design-epic-N.md` with risk assessment and test plan |
| **Phase 4**: Story Dev | (Optional) `*atdd` before dev, then `*automate` after | SM `*create-story`, DEV implements | Tests, story implementation |
| **Phase 4**: Story Review | Execute `*test-review` (optional), re-run `*trace` | Address recommendations, update code/tests | Quality report, refreshed coverage matrix |
| **Phase 4**: Release Gate | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Confirm Definition of Done, share release notes | Quality audit, Gate YAML + release summary |
<details>
<summary>Execution Notes</summary>
@ -218,8 +220,8 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
<details>
<summary>Worked Example – “Nova CRM” Greenfield Feature</summary>
1. **Planning (Phase 2):** Analyst runs `*product-brief`; PM executes `*prd` to produce PRD and epics.
2. **Solutioning (Phase 3):** Architect completes `*architecture` for the new module; TEA sets up test infrastructure via `*framework` and `*ci` based on architectural decisions; gate check validates planning completeness.
1. **Planning (Phase 2):** Analyst runs `*product-brief`; PM executes `*prd` to produce PRD with FRs/NFRs.
2. **Solutioning (Phase 3):** Architect completes `*architecture` for the new module; `*create-epics-and-stories` generates epics/stories based on architecture; TEA sets up test infrastructure via `*framework` and `*ci` based on architectural decisions; gate check validates planning completeness.
3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load all epics into sprint status.
4. **Epic 1 Planning (Phase 4):** TEA runs `*test-design` to create test plan for Epic 1, producing `test-design-epic-1.md` with risk assessment.
5. **Story Implementation (Phase 4):** For each story in Epic 1, SM generates story via `*create-story`; TEA optionally runs `*atdd`; Dev implements with guidance from failing tests.
@ -240,17 +242,17 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
- 🔄 Phase 4: `*test-design` - Focus on regression hotspots and brownfield risks
- 🔄 Phase 4: Story Review - May include `*nfr-assess` if not done earlier
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| ----------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------------------------- |
| **Phase 0**: Documentation ➕ | - | Analyst `*document-project` (if undocumented) | Comprehensive project documentation |
| **Phase 1**: Discovery | - | Analyst/PM/Architect rerun planning workflows | Updated planning artifacts in `{output_folder}` |
| **Phase 2**: Planning | Run ➕ `*trace` (baseline coverage) | PM `*prd` (creates PRD + epics) | PRD, epics, ➕ coverage baseline |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture | Architect `*architecture`, `*solutioning-gate-check` | Architecture, test framework, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint status file with all epics and stories |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic 🔄 (regression hotspots) | Review epic scope and brownfield risks | `test-design-epic-N.md` with brownfield risk assessment and mitigation |
| **Phase 4**: Story Dev | (Optional) `*atdd` before dev, then `*automate` after | SM `*create-story`, DEV implements | Tests, story implementation |
| **Phase 4**: Story Review | Apply `*test-review` (optional), re-run `*trace`, ➕ `*nfr-assess` if needed | Resolve gaps, update docs/tests | Quality report, refreshed coverage matrix, NFR report |
| **Phase 4**: Release Gate | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Capture sign-offs, share release notes | Quality audit, Gate YAML + release summary |
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| ----------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **Phase 0**: Documentation ➕ | - | Analyst `*document-project` (if undocumented) | Comprehensive project documentation |
| **Phase 1**: Discovery | - | Analyst/PM/Architect rerun planning workflows | Updated planning artifacts in `{output_folder}` |
| **Phase 2**: Planning | Run ➕ `*trace` (baseline coverage) | PM `*prd` (creates PRD with FRs/NFRs) | PRD with FRs/NFRs, ➕ coverage baseline |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture and epic creation | Architect `*architecture`, `*create-epics-and-stories`, `*implementation-readiness` | Architecture, epics/stories, test framework, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint status file with all epics and stories |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic 🔄 (regression hotspots) | Review epic scope and brownfield risks | `test-design-epic-N.md` with brownfield risk assessment and mitigation |
| **Phase 4**: Story Dev | (Optional) `*atdd` before dev, then `*automate` after | SM `*create-story`, DEV implements | Tests, story implementation |
| **Phase 4**: Story Review | Apply `*test-review` (optional), re-run `*trace`, ➕ `*nfr-assess` if needed | Resolve gaps, update docs/tests | Quality report, refreshed coverage matrix, NFR report |
| **Phase 4**: Release Gate | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Capture sign-offs, share release notes | Quality audit, Gate YAML + release summary |
<details>
<summary>Execution Notes</summary>
@ -268,8 +270,8 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
<details>
<summary>Worked Example – “Atlas Payments” Brownfield Story</summary>
1. **Planning (Phase 2):** PM executes `*prd` to update PRD and `epics.md` (Epic 1: Payment Processing); TEA runs `*trace` to baseline existing coverage.
2. **Solutioning (Phase 3):** Architect triggers `*architecture` capturing legacy payment flows and integration architecture; TEA sets up `*framework` and `*ci` based on architectural decisions; gate check validates planning.
1. **Planning (Phase 2):** PM executes `*prd` to create PRD with FRs/NFRs; TEA runs `*trace` to baseline existing coverage.
2. **Solutioning (Phase 3):** Architect triggers `*architecture` capturing legacy payment flows and integration architecture; `*create-epics-and-stories` generates Epic 1 (Payment Processing) based on architecture; TEA sets up `*framework` and `*ci` based on architectural decisions; gate check validates planning.
3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load Epic 1 into sprint status.
4. **Epic 1 Planning (Phase 4):** TEA runs `*test-design` for Epic 1 (Payment Processing), producing `test-design-epic-1.md` that flags settlement edge cases, regression hotspots, and mitigation plans.
5. **Story Implementation (Phase 4):** For each story in Epic 1, SM generates story via `*create-story`; TEA runs `*atdd` producing failing Playwright specs; Dev implements with guidance from tests and checklist.
@ -290,15 +292,15 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
- 🔄 Phase 4: `*test-design` - Enterprise focus (compliance, security architecture alignment)
- 📦 Release Gate - Archive artifacts and compliance evidence for audits
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| -------------------------- | ------------------------------------------------------------------------ | ---------------------------------------------------- | ------------------------------------------------------------------ |
| **Phase 1**: Discovery | - | Analyst ➕ `*research`, `*product-brief` | Domain research, compliance analysis, product brief |
| **Phase 2**: Planning | Run ➕ `*nfr-assess` | PM `*prd` (creates PRD + epics), UX `*create-design` | Enterprise PRD, epics, UX design, ➕ NFR documentation |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture | Architect `*architecture`, `*solutioning-gate-check` | Architecture, test framework, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint plan with all epics |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic 🔄 (compliance focus) | Review epic scope and compliance requirements | `test-design-epic-N.md` with security/performance/compliance focus |
| **Phase 4**: Story Dev | (Optional) `*atdd`, `*automate`, `*test-review`, `*trace` per story | SM `*create-story`, DEV implements | Tests, fixtures, quality reports, coverage matrices |
| **Phase 4**: Release Gate | Final `*test-review` audit, Run `*trace` (Phase 2), 📦 archive artifacts | Capture sign-offs, 📦 compliance evidence | Quality audit, updated assessments, gate YAML, 📦 audit trail |
| Workflow Stage | Test Architect | Dev / Team | Outputs |
| -------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| **Phase 1**: Discovery | - | Analyst ➕ `*research`, `*product-brief` | Domain research, compliance analysis, product brief |
| **Phase 2**: Planning | Run ➕ `*nfr-assess` | PM `*prd` (creates PRD with FRs/NFRs), UX `*create-design` | Enterprise PRD with FRs/NFRs, UX design, ➕ NFR documentation |
| **Phase 3**: Solutioning | Run `*framework`, `*ci` AFTER architecture and epic creation | Architect `*architecture`, `*create-epics-and-stories`, `*implementation-readiness` | Architecture, epics/stories, test framework, CI pipeline |
| **Phase 4**: Sprint Start | - | SM `*sprint-planning` | Sprint plan with all epics |
| **Phase 4**: Epic Planning | Run `*test-design` for THIS epic 🔄 (compliance focus) | Review epic scope and compliance requirements | `test-design-epic-N.md` with security/performance/compliance focus |
| **Phase 4**: Story Dev | (Optional) `*atdd`, `*automate`, `*test-review`, `*trace` per story | SM `*create-story`, DEV implements | Tests, fixtures, quality reports, coverage matrices |
| **Phase 4**: Release Gate | Final `*test-review` audit, Run `*trace` (Phase 2), 📦 archive artifacts | Capture sign-offs, 📦 compliance evidence | Quality audit, updated assessments, gate YAML, 📦 audit trail |
<details>
<summary>Execution Notes</summary>
@ -316,8 +318,8 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
<details>
<summary>Worked Example – “Helios Ledger” Enterprise Release</summary>
1. **Planning (Phase 2):** Analyst runs `*research` and `*product-brief`; PM completes `*prd` creating PRD and epics; TEA runs `*nfr-assess` to establish NFR targets.
2. **Solutioning (Phase 3):** Architect completes `*architecture` with enterprise considerations; TEA sets up `*framework` and `*ci` with enterprise-grade configurations based on architectural decisions; gate check validates planning completeness.
1. **Planning (Phase 2):** Analyst runs `*research` and `*product-brief`; PM completes `*prd` creating PRD with FRs/NFRs; TEA runs `*nfr-assess` to establish NFR targets.
2. **Solutioning (Phase 3):** Architect completes `*architecture` with enterprise considerations; `*create-epics-and-stories` generates epics/stories based on architecture; TEA sets up `*framework` and `*ci` with enterprise-grade configurations based on architectural decisions; gate check validates planning completeness.
3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load all epics into sprint status.
4. **Per-Epic (Phase 4):** For each epic, TEA runs `*test-design` to create epic-specific test plan (e.g., `test-design-epic-1.md`, `test-design-epic-2.md`) with compliance-focused risk assessment.
5. **Per-Story (Phase 4):** For each story, TEA uses `*atdd`, `*automate`, `*test-review`, and `*trace`; Dev teams iterate on the findings.

9
src/modules/bmm/docs/workflow-architecture-reference.md
View File

@ -72,7 +72,7 @@ The Decision Architecture workflow is a complete reimagining of how architectura
```
Step 0: Validate workflow and extract project configuration
Step 0.5: Validate workflow sequencing
Step 1: Load PRD and understand project context
Step 1: Load PRD (with FRs/NFRs) and understand project context
Step 2: Discover and evaluate starter templates ⭐ NEW
Step 3: Adapt facilitation style and identify remaining decisions
Step 4: Facilitate collaborative decision making (with version verification)
@ -122,11 +122,6 @@ Step 12: Final review and update workflow status
- Non-Functional Requirements
- Performance and compliance needs
- **Epics** file with:
- User stories
- Acceptance criteria
- Dependencies
- **UX Spec** (Optional but valuable) with:
- Interface designs and interaction patterns
- Accessibility requirements (WCAG levels)
@ -280,7 +275,7 @@ workflow architecture
The AI agent will:
1. Load your PRD and epics
1. Load your PRD (with FRs/NFRs)
2. Identify critical decisions needed
3. Facilitate discussion on each decision
4. Generate a comprehensive architecture document

4
src/modules/bmm/docs/workflow-document-project-reference.md
View File

@ -202,7 +202,9 @@ PRD Workflow: Loads docs/index.md
→ Understands existing architecture
→ Identifies reusable components
→ Plans integration with existing APIs
→ Creates contextual PRD with epics and stories
→ Creates contextual PRD with FRs and NFRs
Architecture Workflow: Creates architecture design
Create-Epics-and-Stories Workflow: Breaks down into epics and stories
```
### Other Use Cases

8
src/modules/bmm/docs/workflows-implementation.md
View File

@ -162,7 +162,8 @@ Stories move through these states in the sprint status file:
### Sprint 0 (Planning Phase)
- Complete Phases 1-3 (Analysis, Planning, Solutioning)
- PRD/GDD + Architecture + Epics ready
- PRD/GDD + Architecture complete
- **V6: Epics+Stories created via create-epics-and-stories workflow (runs AFTER architecture)**
### Sprint 1+ (Implementation Phase)
@ -235,8 +236,9 @@ tech-spec (PM)
### Level 2-4 (BMad Method / Enterprise)
```
PRD + Architecture (PM/Architect)
→ solutioning-gate-check (Architect)
PRD (PM) → Architecture (Architect)
→ create-epics-and-stories (PM) ← V6: After architecture!
→ implementation-readiness (Architect)
→ sprint-planning (SM, once)
→ [Per Epic]:
epic-tech-context (SM)

95
src/modules/bmm/docs/workflows-planning.md
View File

@ -26,13 +26,17 @@ graph TB
subgraph BMadMethod["<b>BMAD METHOD (Recommended)</b>"]
direction TB
PRD["<b>PM: prd</b><br/>Strategic PRD"]
PRD["<b>PM: prd</b><br/>Strategic PRD with FRs/NFRs"]
GDD["<b>Game Designer: gdd</b><br/>Game design doc"]
Narrative["<b>Game Designer: narrative</b><br/>Story-driven design"]
Epics["<b>PM: create-epics-and-stories</b><br/>Epic+Stories breakdown<br/>10-50+ stories typically"]
UXDesign["<b>UX Designer: create-ux-design</b><br/>Optional UX specification"]
end
UXDesign["<b>UX Designer: ux</b><br/>Optional UX specification"]
subgraph Solutioning["<b>PHASE 3: SOLUTIONING</b>"]
direction TB
Architecture["<b>Architect: architecture</b><br/>System design + decisions"]
Epics["<b>PM: create-epics-and-stories</b><br/>Epic+Stories breakdown<br/>(10-50+ stories typically)"]
end
subgraph Enterprise["<b>ENTERPRISE METHOD</b>"]
@ -51,17 +55,20 @@ graph TB
Start -->|Story-driven| Narrative
Start -->|Enterprise needs| Enterprise
PRD --> Epics
GDD --> Epics
Narrative --> Epics
Epics -.->|Optional| UXDesign
UXDesign -.->|May update| Epics
PRD -.->|Optional| UXDesign
GDD -.->|Optional| UXDesign
Narrative -.->|Optional| UXDesign
PRD --> Architecture
GDD --> Architecture
Narrative --> Architecture
UXDesign --> Architecture
Architecture --> Epics
QuickFlow --> Phase4["<b>Phase 4: Implementation</b>"]
Epics --> Phase3["<b>Phase 3: Architecture</b>"]
Enterprise -.->|Uses BMad planning| Epics
Epics --> ReadinessCheck["<b>Architect: implementation-readiness</b><br/>Gate check"]
Enterprise -.->|Uses BMad planning| Architecture
Enterprise --> Phase3Ext["<b>Phase 3: Extended</b><br/>(Arch + Sec + DevOps)"]
Phase3 --> Phase4
ReadinessCheck --> Phase4
Phase3Ext --> Phase4
Phase4 -.->|Significant changes| CorrectCourse
@ -90,18 +97,18 @@ graph TB
## Quick Reference
| Workflow | Agent | Track | Purpose | Typical Stories |
| ---------------------------- | ------------- | ----------- | ------------------------------------------ | --------------- |
| **workflow-init** | PM/Analyst | All | Entry point: discovery + routing | N/A |
| **tech-spec** | PM | Quick Flow | Technical document → Story or Epic+Stories | 1-15 |
| **prd** | PM | BMad Method | Strategic PRD | 10-50+ |
| **gdd** | Game Designer | BMad Method | Game Design Document | 10-50+ |
| **narrative** | Game Designer | BMad Method | Story-driven game/experience design | 10-50+ |
| **create-epics-and-stories** | PM | BMad Method | Break PRD/GDD into Epic+Stories | N/A |
| **ux** | UX Designer | BMad Method | Optional UX specification | N/A |
| **correct-course** | PM/SM | All | Mid-stream requirement changes | N/A |
| Workflow | Agent | Track | Purpose | Typical Stories |
| ---------------------------- | ------------- | ----------- | --------------------------------------------------------- | --------------- |
| **workflow-init** | PM/Analyst | All | Entry point: discovery + routing | N/A |
| **tech-spec** | PM | Quick Flow | Technical document → Story or Epic+Stories | 1-15 |
| **prd** | PM | BMad Method | Strategic PRD with FRs/NFRs (no epic breakdown) | 10-50+ |
| **gdd** | Game Designer | BMad Method | Game Design Document with requirements | 10-50+ |
| **narrative** | Game Designer | BMad Method | Story-driven game/experience design | 10-50+ |
| **create-ux-design** | UX Designer | BMad Method | Optional UX specification (after PRD) | N/A |
| **create-epics-and-stories** | PM | BMad Method | Break requirements into Epic+Stories (AFTER architecture) | N/A |
| **correct-course** | PM/SM | All | Mid-stream requirement changes | N/A |
**Note:** Story counts are guidance based on typical usage, not strict definitions.
**Note:** Story counts are guidance. V6 improvement: Epic+Stories are created AFTER architecture for better quality.
---
@ -135,11 +142,11 @@ BMM uses three distinct planning tracks that adapt to project complexity:
**Story Count:** Typically 10-50+ (guidance)
**Documents:** PRD.md (or GDD.md) + architecture.md + epic files + story files
**Documents:** PRD.md (FRs/NFRs) + architecture.md + epics.md + epic files
**Greenfield:** Product Brief (optional) → PRD → UX (optional) → Architecture → Implementation
**Greenfield:** Product Brief (optional) → PRD (FRs/NFRs) → UX (optional) → Architecture → Epics+Stories → Implementation
**Brownfield:** document-project → PRD → Architecture (recommended) → Implementation
**Brownfield:** document-project → PRD (FRs/NFRs) → Architecture (recommended) → Epics+Stories → Implementation
**Example:** "Customer dashboard", "E-commerce platform", "Add search to existing app"
@ -151,17 +158,17 @@ BMM uses three distinct planning tracks that adapt to project complexity:
**Best For:** Enterprise requirements, multi-tenant, compliance, security-sensitive
**Planning (Phase 2):** Uses BMad Method planning (PRD + Epic+Stories)
**Planning (Phase 2):** Uses BMad Method planning (PRD with FRs/NFRs)
**Solutioning (Phase 3):** Extended workflows (Architecture + Security + DevOps + SecOps as optional additions)
**Solutioning (Phase 3):** Extended workflows (Architecture + Security + DevOps + SecOps as optional additions) → Epics+Stories
**Time:** 3-7 days total (1-3 days planning + 2-4 days extended solutioning)
**Story Count:** Typically 30+ (but defined by enterprise needs)
**Documents Phase 2:** PRD.md + epics + epic files + story files
**Documents Phase 2:** PRD.md (FRs/NFRs)
**Documents Phase 3:** architecture.md + security-architecture.md (optional) + devops-strategy.md (optional) + secops-strategy.md (optional)
**Documents Phase 3:** architecture.md + epics.md + epic files + security-architecture.md (optional) + devops-strategy.md (optional) + secops-strategy.md (optional)
**Example:** "Multi-tenant SaaS", "HIPAA-compliant portal", "Add SOC2 audit logging"
@ -231,7 +238,7 @@ The system guides but never forces. You can override recommendations.
### prd (Product Requirements Document)
**Purpose:** Strategic PRD with epic breakdown for software products (BMad Method track).
**Purpose:** Strategic PRD with Functional Requirements (FRs) and Non-Functional Requirements (NFRs) for software products (BMad Method track).
**Agent:** PM (with Architect and Analyst support)
@ -245,19 +252,19 @@ The system guides but never forces. You can override recommendations.
**Scale-Adaptive Structure:**
- **Light:** Single epic, 5-10 stories, simplified analysis (10-15 pages)
- **Standard:** 2-4 epics, 15-30 stories, comprehensive analysis (20-30 pages)
- **Comprehensive:** 5+ epics, 30-50+ stories, multi-phase, extensive stakeholder analysis (30-50+ pages)
- **Light:** Focused FRs/NFRs, simplified analysis (10-15 pages)
- **Standard:** Comprehensive FRs/NFRs, thorough analysis (20-30 pages)
- **Comprehensive:** Extensive FRs/NFRs, multi-phase, stakeholder analysis (30-50+ pages)
**Key Outputs:**
- PRD.md (complete requirements)
- epics.md (epic breakdown)
- Epic files (epic-1-_.md, epic-2-_.md, etc.)
- PRD.md (complete requirements with FRs and NFRs)
**Note:** V6 improvement - PRD focuses on WHAT to build (requirements). Epic+Stories are created AFTER architecture via `create-epics-and-stories` workflow for better quality.
**Integration:** Feeds into Architecture (Phase 3)
**Example:** E-commerce checkout → 3 epics (Guest Checkout, Payment Processing, Order Management), 21 stories, 4-6 week delivery.
**Example:** E-commerce checkout → PRD with 15 FRs (user account, cart management, payment flow) and 8 NFRs (performance, security, scalability).
---
@ -362,22 +369,26 @@ The system guides but never forces. You can override recommendations.
### create-epics-and-stories
**Purpose:** Break PRD/GDD requirements into bite-sized stories organized in epics (BMad Method track).
**Purpose:** Break requirements into bite-sized stories organized in epics (BMad Method track).
**Agent:** PM
**When to Use:**
- After PRD/GDD complete (often run automatically)
- Can also run standalone later to re-generate epics/stories
- When planning story breakdown outside main PRD workflow
- **REQUIRED:** After Architecture workflow is complete (Phase 3)
- After PRD defines FRs/NFRs and Architecture defines HOW to build
- Optional: Can also run earlier (after PRD, after UX) for basic structure, then refined after Architecture
**Key Outputs:**
- epics.md (all epics with story breakdown)
- Epic files (epic-1-\*.md, etc.)
**Note:** PRD workflow often creates epics automatically. This workflow can be run standalone if needed later.
**V6 Improvement:** Epics+Stories are now created AFTER architecture for better quality:
- Architecture decisions inform story breakdown (tech choices affect implementation)
- Stories have full context (PRD + UX + Architecture)
- Better sequencing with technical dependencies considered
---

151
src/modules/bmm/docs/workflows-solutioning.md
View File

@ -19,7 +19,7 @@ Phase 3 (Solutioning) workflows translate **what** to build (from Planning) into
```mermaid
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#fff','primaryTextColor':'#000','primaryBorderColor':'#000','lineColor':'#000','fontSize':'16px','fontFamily':'arial'}}}%%
graph TB
FromPlanning["<b>FROM Phase 2 Planning</b><br/>PRD/GDD/Tech-Spec complete"]
FromPlanning["<b>FROM Phase 2 Planning</b><br/>PRD (FRs/NFRs) complete"]
subgraph QuickFlow["<b>QUICK FLOW PATH</b>"]
direction TB
@ -28,6 +28,7 @@ graph TB
subgraph BMadEnterprise["<b>BMAD METHOD + ENTERPRISE (Same Start)</b>"]
direction TB
OptionalUX["<b>UX Designer: create-ux-design</b><br/>(Optional)"]
Architecture["<b>Architect: architecture</b><br/>System design + ADRs"]
subgraph Optional["<b>ENTERPRISE ADDITIONS (Optional)</b>"]
@ -36,11 +37,14 @@ graph TB
DevOps["<b>Architect: devops-strategy</b><br/>(Future)"]
end
GateCheck["<b>Architect: solutioning-gate-check</b><br/>Validation before Phase 4"]
EpicsStories["<b>PM: create-epics-and-stories</b><br/>Break down FRs/NFRs into epics"]
GateCheck["<b>Architect: implementation-readiness</b><br/>Validation before Phase 4"]
OptionalUX -.-> Architecture
Architecture -.->|Enterprise only| Optional
Architecture --> GateCheck
Optional -.-> GateCheck
Architecture --> EpicsStories
Optional -.-> EpicsStories
EpicsStories --> GateCheck
end
subgraph Result["<b>GATE CHECK RESULTS</b>"]
@ -51,7 +55,7 @@ graph TB
end
FromPlanning -->|Quick Flow| QuickFlow
FromPlanning -->|BMad Method<br/>or Enterprise| Architecture
FromPlanning -->|BMad Method<br/>or Enterprise| OptionalUX
QuickFlow --> Phase4["<b>Phase 4: Implementation</b>"]
GateCheck --> Result
@ -67,9 +71,11 @@ graph TB
style Phase4 fill:#ffcc80,stroke:#e65100,stroke-width:2px,color:#000
style SkipArch fill:#aed581,stroke:#1b5e20,stroke-width:2px,color:#000
style OptionalUX fill:#64b5f6,stroke:#0d47a1,stroke-width:2px,color:#000
style Architecture fill:#42a5f5,stroke:#0d47a1,stroke-width:2px,color:#000
style SecArch fill:#ef9a9a,stroke:#c62828,stroke-width:2px,color:#000
style DevOps fill:#ef9a9a,stroke:#c62828,stroke-width:2px,color:#000
style EpicsStories fill:#42a5f5,stroke:#0d47a1,stroke-width:2px,color:#000
style GateCheck fill:#42a5f5,stroke:#0d47a1,stroke-width:2px,color:#000
style Pass fill:#81c784,stroke:#388e3c,stroke-width:2px,color:#000
style Concerns fill:#ffb74d,stroke:#f57f17,stroke-width:2px,color:#000
@ -80,10 +86,12 @@ graph TB
## Quick Reference
| Workflow | Agent | Track | Purpose |
| -------------------------- | --------- | ------------------------ | ------------------------------------------- |
| **architecture** | Architect | BMad Method, Enterprise | Technical architecture and design decisions |
| **solutioning-gate-check** | Architect | BMad Complex, Enterprise | Validate planning/solutioning completeness |
| Workflow | Agent | Track | Purpose |
| ---------------------------- | ----------- | ------------------------ | -------------------------------------------- |
| **create-ux-design** | UX Designer | BMad Method, Enterprise | Optional UX design (after PRD, before arch) |
| **architecture** | Architect | BMad Method, Enterprise | Technical architecture and design decisions |
| **create-epics-and-stories** | PM | BMad Method, Enterprise | Break FRs/NFRs into epics after architecture |
| **implementation-readiness** | Architect | BMad Complex, Enterprise | Validate planning/solutioning completeness |
**When to Skip Solutioning:**
@ -116,14 +124,14 @@ Result: Consistent implementation, no conflicts
### Solutioning vs Planning
| Aspect | Planning (Phase 2) | Solutioning (Phase 3) |
| -------- | ------------------ | ------------------------ |
| Question | What and Why? | How? |
| Output | Requirements | Technical Design |
| Agent | PM | Architect |
| Audience | Stakeholders | Developers |
| Document | PRD/GDD | Architecture + Tech Spec |
| Level | Business logic | Implementation detail |
| Aspect | Planning (Phase 2) | Solutioning (Phase 3) |
| -------- | ----------------------- | --------------------------------- |
| Question | What and Why? | How? Then What units of work? |
| Output | FRs/NFRs (Requirements) | Architecture + Epics/Stories |
| Agent | PM | Architect → PM |
| Audience | Stakeholders | Developers |
| Document | PRD (FRs/NFRs) | Architecture + Epic Files |
| Level | Business logic | Technical design + Work breakdown |
---
@ -171,7 +179,7 @@ This is NOT a template filler. The architecture workflow:
7. **Security Architecture** - Auth/authorization, data protection, security boundaries
8. **Deployment Architecture** - Deployment model, CI/CD, environment strategy, monitoring
9. **Architecture Decision Records (ADRs)** - Key decisions with context, options, trade-offs, rationale
10. **Epic-Specific Guidance** - Technical notes per epic, implementation priorities, dependencies
10. **FR/NFR-Specific Guidance** - Technical approach per functional requirement, implementation priorities, dependencies
11. **Standards and Conventions** - Directory structure, naming conventions, code organization, testing
**ADR Format (Brief):**
@ -203,28 +211,69 @@ This is NOT a template filler. The architecture workflow:
- Negative: Caching complexity, N+1 query risk
- Mitigation: Use DataLoader for batching
**Implications for Epics:**
**Implications for FRs:**
- Epic 1: User Management → GraphQL mutations
- Epic 2: Mobile App → Optimized queries
- FR-001: User Management → GraphQL mutations
- FR-002: Mobile App → Optimized queries
```
**Example:** E-commerce platform → Monolith + PostgreSQL + Redis + Next.js + GraphQL, with ADRs explaining each choice and epic-specific guidance.
**Example:** E-commerce platform → Monolith + PostgreSQL + Redis + Next.js + GraphQL, with ADRs explaining each choice and FR/NFR-specific guidance.
**Integration:** Feeds into Phase 4 (Implementation). All dev agents reference architecture during implementation.
**Integration:** Feeds into create-epics-and-stories workflow. Architecture provides the technical context needed for breaking FRs/NFRs into implementable epics and stories. All dev agents reference architecture during Phase 4 implementation.
---
### solutioning-gate-check
### create-epics-and-stories
**Purpose:** Systematically validate that planning and solutioning are complete and aligned before Phase 4 implementation. Ensures PRD, architecture, and stories are cohesive with no gaps.
**Purpose:** Transform PRD's functional and non-functional requirements into bite-sized stories organized into deliverable functional epics. This workflow runs AFTER architecture so epics/stories are informed by technical decisions.
**Agent:** PM (Product Manager)
**When to Use:**
- After architecture workflow completes
- When PRD contains FRs/NFRs ready for implementation breakdown
- Before implementation-readiness gate check
**Key Inputs:**
- PRD (FRs/NFRs) from Phase 2 Planning
- architecture.md with ADRs and technical decisions
- Optional: UX design artifacts
**Why After Architecture:**
The create-epics-and-stories workflow runs AFTER architecture because:
1. **Informed Story Sizing:** Architecture decisions (database choice, API style, etc.) affect story complexity
2. **Dependency Awareness:** Architecture reveals technical dependencies between stories
3. **Technical Feasibility:** Stories can be properly scoped knowing the tech stack
4. **Consistency:** All stories align with documented architectural patterns
**Key Outputs:**
Epic files (one per epic) containing:
1. Epic objective and scope
2. User stories with acceptance criteria
3. Story priorities (P0/P1/P2/P3)
4. Dependencies between stories
5. Technical notes referencing architecture decisions
**Example:** E-commerce PRD with FR-001 (User Registration), FR-002 (Product Catalog) → Epic 1: User Management (3 stories), Epic 2: Product Display (4 stories), each story referencing relevant ADRs.
---
### implementation-readiness
**Purpose:** Systematically validate that planning and solutioning are complete and aligned before Phase 4 implementation. Ensures PRD, architecture, and epics are cohesive with no gaps.
**Agent:** Architect
**When to Use:**
- **Always** before Phase 4 for BMad Complex and Enterprise projects
- After architecture workflow completes
- After create-epics-and-stories workflow completes
- Before sprint-planning workflow
- When stakeholders request readiness check
@ -237,14 +286,14 @@ This is NOT a template filler. The architecture workflow:
**Prevents:**
- ❌ Architecture doesn't address all epics
- ❌ Stories conflict with architecture decisions
- ❌ Architecture doesn't address all FRs/NFRs
- ❌ Epics conflict with architecture decisions
- ❌ Requirements ambiguous or contradictory
- ❌ Missing critical dependencies
**Ensures:**
- ✅ PRD → Architecture → Stories alignment
- ✅ PRD → Architecture → Epics alignment
- ✅ All epics have clear technical approach
- ✅ No contradictions or gaps
- ✅ Team ready to implement
@ -256,8 +305,7 @@ This is NOT a template filler. The architecture workflow:
- Problem statement clear and evidence-based
- Success metrics defined
- User personas identified
- Feature requirements complete
- All epics defined with objectives
- Functional requirements (FRs) complete
- Non-functional requirements (NFRs) specified
- Risks and assumptions documented
@ -268,7 +316,7 @@ This is NOT a template filler. The architecture workflow:
- API architecture decided
- Key ADRs documented
- Security architecture addressed
- Epic-specific guidance provided
- FR/NFR-specific guidance provided
- Standards and conventions defined
**Epic/Story Completeness:**
@ -281,8 +329,8 @@ This is NOT a template filler. The architecture workflow:
**Alignment Checks:**
- Architecture addresses all PRD requirements
- Stories align with architecture decisions
- Architecture addresses all PRD FRs/NFRs
- Epics align with architecture decisions
- No contradictions between epics
- NFRs have technical approach
- Integration points clear
@ -305,16 +353,16 @@ This is NOT a template filler. The architecture workflow:
- Critical gaps or contradictions
- Architecture missing key decisions
- Stories conflict with PRD/architecture
- Epics conflict with PRD/architecture
- **Action:** BLOCK Phase 4, resolve issues first
**Key Outputs:**
**solutioning-gate-check.md** containing:
**implementation-readiness.md** containing:
1. Executive Summary (PASS/CONCERNS/FAIL)
2. Completeness Assessment (scores for PRD, Architecture, Epics)
3. Alignment Assessment (PRD↔Architecture, Architecture↔Epics, cross-epic consistency)
3. Alignment Assessment (PRD↔Architecture, Architecture↔Epics/Stories, cross-epic consistency)
4. Quality Assessment (story quality, dependencies, risks)
5. Gaps and Recommendations (critical/minor gaps, remediation)
6. Gate Decision with rationale
@ -339,26 +387,30 @@ Planning (tech-spec by PM)
**BMad Method:**
```
Planning (prd by PM)
Planning (prd by PM - FRs/NFRs only)
→ Optional: create-ux-design (UX Designer)
→ architecture (Architect)
→ solutioning-gate-check (Architect)
→ create-epics-and-stories (PM)
→ implementation-readiness (Architect)
→ Phase 4 (Implementation)
```
**Enterprise:**
```
Planning (prd by PM - same as BMad Method)
Planning (prd by PM - FRs/NFRs only)
→ Optional: create-ux-design (UX Designer)
→ architecture (Architect)
→ Optional: security-architecture (Architect, future)
→ Optional: devops-strategy (Architect, future)
→ solutioning-gate-check (Architect)
→ create-epics-and-stories (PM)
→ implementation-readiness (Architect)
→ Phase 4 (Implementation)
```
**Note on TEA (Test Architect):** TEA is fully operational with 8 workflows across all phases. TEA validates architecture testability during Phase 3 reviews but does not have a dedicated solutioning workflow. TEA's primary setup occurs in Phase 2 (`*framework`, `*ci`, `*test-design`) and testing execution in Phase 4 (`*atdd`, `*automate`, `*test-review`, `*trace`, `*nfr-assess`).
**Note:** Enterprise uses the same planning and architecture as BMad Method. The only difference is optional extended workflows added AFTER architecture but BEFORE gate check.
**Note:** Enterprise uses the same planning and architecture as BMad Method. The only difference is optional extended workflows added AFTER architecture but BEFORE create-epics-and-stories.
### Solutioning → Implementation Handoff
@ -366,11 +418,12 @@ Planning (prd by PM - same as BMad Method)
1. **architecture.md** → Guides all dev agents during implementation
2. **ADRs** (in architecture) → Referenced by agents for technical decisions
3. **solutioning-gate-check.md** → Confirms readiness for Phase 4
3. **Epic files** (from create-epics-and-stories) → Work breakdown into implementable units
4. **implementation-readiness.md** → Confirms readiness for Phase 4
**How Implementation Uses Solutioning:**
- **sprint-planning** - Loads architecture for epic sequencing
- **sprint-planning** - Loads architecture and epic files for sprint organization
- **dev-story** - References architecture decisions and ADRs
- **code-review** - Validates code follows architectural standards
@ -414,17 +467,17 @@ Architecture documents are living. Update them as you learn during implementatio
### BMad Method
- **Planning:** prd (PM)
- **Solutioning:** architecture (Architect) → solutioning-gate-check (Architect)
- **Planning:** prd (PM) - creates FRs/NFRs only, NOT epics
- **Solutioning:** Optional UX → architecture (Architect) → create-epics-and-stories (PM) → implementation-readiness (Architect)
- **Implementation:** sprint-planning → epic-tech-context → dev-story
### Enterprise
- **Planning:** prd (PM) - same as BMad Method
- **Solutioning:** architecture (Architect) → Optional extended workflows (security-architecture, devops-strategy) → solutioning-gate-check (Architect)
- **Planning:** prd (PM) - creates FRs/NFRs only (same as BMad Method)
- **Solutioning:** Optional UX → architecture (Architect) → Optional extended workflows (security-architecture, devops-strategy) → create-epics-and-stories (PM) → implementation-readiness (Architect)
- **Implementation:** sprint-planning → epic-tech-context → dev-story
**Key Difference:** Enterprise adds optional extended workflows AFTER architecture but BEFORE gate check. Everything else is identical to BMad Method.
**Key Difference:** Enterprise adds optional extended workflows AFTER architecture but BEFORE create-epics-and-stories. Everything else is identical to BMad Method.
**Note:** TEA (Test Architect) operates across all phases and validates architecture testability but is not a Phase 3-specific workflow. See [Test Architecture Guide](./test-architecture.md) for TEA's full lifecycle integration.

1
src/modules/bmm/teams/default-party.csv
View File

@ -17,3 +17,4 @@ name,displayName,title,icon,role,identity,communicationStyle,principles,module,p
"lateral-thinker","Edward de Bono","Lateral Thinking Pioneer","🧩","Creator of Creative Thinking Tools","Inventor of lateral thinking and Six Thinking Hats methodology. Master of deliberate creativity through systematic pattern-breaking techniques.","Talks in structured thinking frameworks - uses colored hat metaphors, proposes deliberate provocations, breaks patterns methodically","Logic gets you from A to B. Creativity gets you everywhere else. Use tools to escape habitual thinking patterns.","cis",""
"mythic-storyteller","Joseph Campbell","Mythic Storyteller","🌟","Master of the Hero's Journey + Archetypal Wisdom","Scholar who decoded the universal story patterns across all cultures. Expert in mythology, comparative religion, and archetypal narratives.","Speaks in mythological metaphors and archetypal patterns - EVERY story is a hero's journey, references ancient wisdom","Follow your bliss. All stories share the monomyth. Myths reveal universal human truths. The call to adventure is irresistible.","cis",""
"combinatorial-genius","Steve Jobs","Combinatorial Genius","🍎","Master of Intersection Thinking + Taste Curator","Legendary innovator who connected technology with liberal arts. Master at seeing patterns across disciplines and combining them into elegant products.","Talks in reality distortion field mode - insanely great, magical, revolutionary, makes impossible seem inevitable","Innovation happens at intersections. Taste is about saying NO to 1000 things. Stay hungry stay foolish. Simplicity is sophistication.","cis",""
"frame-expert","Saif Ullah","Visual Design & Diagramming Expert","🎨","Expert Visual Designer & Diagramming Specialist","Expert who creates visual representations using Excalidraw with optimized, reusable components. Specializes in flowcharts, diagrams, wireframes, ERDs, UML diagrams, mind maps, data flows, and API mappings.","Visual-first, structured, detail-oriented, composition-focused. Presents options as numbered lists for easy selection.","Composition Over Creation - Use reusable components and templates. Minimal Payload - Strip unnecessary metadata. Reference-Based Design - Use library references. Structured Approach - Follow task-specific workflows. Clean Output - Remove history and unused styles.","bmm","bmad/bmm/agents/frame-expert.md"

1 name displayName title icon role identity communicationStyle principles module path
17 lateral-thinker Edward de Bono Lateral Thinking Pioneer 🧩 Creator of Creative Thinking Tools Inventor of lateral thinking and Six Thinking Hats methodology. Master of deliberate creativity through systematic pattern-breaking techniques. Talks in structured thinking frameworks - uses colored hat metaphors, proposes deliberate provocations, breaks patterns methodically Logic gets you from A to B. Creativity gets you everywhere else. Use tools to escape habitual thinking patterns. cis
18 mythic-storyteller Joseph Campbell Mythic Storyteller 🌟 Master of the Hero's Journey + Archetypal Wisdom Scholar who decoded the universal story patterns across all cultures. Expert in mythology, comparative religion, and archetypal narratives. Speaks in mythological metaphors and archetypal patterns - EVERY story is a hero's journey, references ancient wisdom Follow your bliss. All stories share the monomyth. Myths reveal universal human truths. The call to adventure is irresistible. cis
19 combinatorial-genius Steve Jobs Combinatorial Genius 🍎 Master of Intersection Thinking + Taste Curator Legendary innovator who connected technology with liberal arts. Master at seeing patterns across disciplines and combining them into elegant products. Talks in reality distortion field mode - insanely great, magical, revolutionary, makes impossible seem inevitable Innovation happens at intersections. Taste is about saying NO to 1000 things. Stay hungry stay foolish. Simplicity is sophistication. cis
20 frame-expert Saif Ullah Visual Design & Diagramming Expert 🎨 Expert Visual Designer & Diagramming Specialist Expert who creates visual representations using Excalidraw with optimized, reusable components. Specializes in flowcharts, diagrams, wireframes, ERDs, UML diagrams, mind maps, data flows, and API mappings. Visual-first, structured, detail-oriented, composition-focused. Presents options as numbered lists for easy selection. Composition Over Creation - Use reusable components and templates. Minimal Payload - Strip unnecessary metadata. Reference-Based Design - Use library references. Structured Approach - Follow task-specific workflows. Clean Output - Remove history and unused styles. bmm bmad/bmm/agents/frame-expert.md

1
src/modules/bmm/teams/team-fullstack.yaml
View File

@ -9,4 +9,5 @@ agents:
- pm
- sm
- ux-designer
- frame-expert
party: "./default-party.csv"

2
src/modules/bmm/workflows/1-analysis/brainstorm-project/instructions.md
View File

@ -5,6 +5,8 @@
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>Communicate all responses in {communication_language}</critical>
<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with project-specific context</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>

2
src/modules/bmm/workflows/1-analysis/domain-research/instructions.md
View File

@ -7,6 +7,8 @@
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>LIVING DOCUMENT: Write to domain-brief.md continuously as you discover - never wait until the end</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>

2
src/modules/bmm/workflows/1-analysis/product-brief/instructions.md
View File

@ -7,6 +7,8 @@
<critical>Communicate all responses in {communication_language} and adapt deeply to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>LIVING DOCUMENT: Write to the document continuously as you discover - never wait until the end</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
## Input Document Discovery

12
src/modules/bmm/workflows/1-analysis/product-brief/workflow.yaml
View File

@ -12,29 +12,25 @@ document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
date: system-generated
# Optional input documents
recommended_inputs:
- market_research: "Market research document (optional)"
- brainstorming_results: "Brainstorming session outputs (optional)"
- competitive_analysis: "Competitive analysis (optional)"
- initial_ideas: "Initial product ideas or notes (optional)"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
input_file_patterns:
research:
description: "Market research or competitive analysis (optional)"
whole: "{output_folder}/*research*.md"
sharded: "{output_folder}/*research*/index.md"
load_strategy: "FULL_LOAD"
brainstorming:
description: "Brainstorming session outputs (optional)"
whole: "{output_folder}/*brainstorm*.md"
sharded: "{output_folder}/*brainstorm*/index.md"
load_strategy: "FULL_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
# Module path and component files

1
src/modules/bmm/workflows/1-analysis/research/instructions-deep-prompt.md
View File

@ -14,6 +14,7 @@
<critical>Add explicit instructions: "If you cannot find reliable data, state 'No verified data found for [X]'"</critical>
<critical>Require confidence indicators in prompts: "Mark each claim with confidence level and source quality"</critical>
<critical>Include fact-checking instructions: "Distinguish between verified facts, analysis, and speculation"</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>

1
src/modules/bmm/workflows/1-analysis/research/instructions-market.md
View File

@ -17,6 +17,7 @@
<critical>Clearly label: FACT (sourced data), ANALYSIS (your interpretation), PROJECTION (forecast/speculation)</critical>
<critical>After each WebSearch, extract and store source URLs - include them in the report</critical>
<critical>If a claim seems suspicious or too convenient, STOP and cross-verify with additional searches</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<!-- IDE-INJECT-POINT: market-research-subagents -->

1
src/modules/bmm/workflows/1-analysis/research/instructions-router.md
View File

@ -13,6 +13,7 @@
<critical>Flag any data you are uncertain about with confidence levels: [High Confidence], [Medium Confidence], [Low Confidence - verify]</critical>
<critical>Distinguish clearly between: FACTS (from sources), ANALYSIS (your interpretation), and SPECULATION (educated guesses)</critical>
<critical>When using WebSearch results, ALWAYS extract and include the source URL for every claim</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<!-- IDE-INJECT-POINT: research-subagents -->

1
src/modules/bmm/workflows/1-analysis/research/instructions-technical.md
View File

@ -18,6 +18,7 @@
<critical>Distinguish: FACT (from official docs/sources), OPINION (from community/reviews), SPECULATION (your analysis)</critical>
<critical>If you cannot find current information about a technology, state: "I could not find recent {{current_year}} data on [X]"</critical>
<critical>Extract and include source URLs in all technology profiles and comparisons</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>

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

616
src/modules/bmm/workflows/2-plan-workflows/create-epics-and-stories/instructions.md Normal file
View File

@ -0,0 +1,616 @@
# Epic and Story Decomposition - Intent-Based Implementation Planning
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow transforms requirements into BITE-SIZED STORIES for development agents</critical>
<critical>EVERY story must be completable by a single dev agent in one focused session</critical>
<critical>⚠️ EPIC STRUCTURE PRINCIPLE: Each epic MUST deliver USER VALUE, not just technical capability. Epics are NOT organized by technical layers (database, API, frontend). Each epic should result in something USERS can actually use or benefit from. Exception: Foundation/setup stories at the start of first epic are acceptable. Another valid exception: API-first epic ONLY when the API itself has standalone value (e.g., will be consumed by third parties or multiple frontends).</critical>
<critical>BMAD METHOD WORKFLOW POSITION: This workflow can be invoked at multiple points - after PRD only, after PRD+UX, after PRD+UX+Architecture, or to update existing epics. If epics.md already exists, ASK the user: (1) CONTINUING - previous run was incomplete, (2) REPLACING - starting fresh/discarding old, (3) UPDATING - new planning document created since last epic generation</critical>
<critical>This is a LIVING DOCUMENT that evolves through the BMad Method workflow chain</critical>
<critical>Phase 4 Implementation pulls context from: PRD + epics.md + UX + Architecture</critical>
<critical>Communicate all responses in {communication_language} and adapt to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>LIVING DOCUMENT: Write to epics.md continuously as you work - never wait until the end</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>
<step n="0" goal="Detect workflow mode and available context">
<action>Determine if this is initial creation or update mode
**Check for existing epics.md:**
</action>
<action>Check if {default_output_file} exists (epics.md)</action>
<check if="epics.md exists">
<action>Load existing epics.md completely</action>
<action>Extract existing:
- Epic structure and titles
- Story breakdown
- FR coverage mapping
- Existing acceptance criteria
</action>
<output>📝 **Existing epics.md found!**
Current structure:
- {{epic_count}} epics defined
- {{story_count}} total stories
</output>
<ask>What would you like to do?
1. **CONTINUING** - Previous run was incomplete, continue where we left off
2. **REPLACING** - Start fresh, discard existing epic structure
3. **UPDATING** - New planning document created (UX/Architecture), enhance existing epics
Enter your choice (1-3):</ask>
<action>Set mode based on user choice:
- Choice 1: mode = "CONTINUE" (resume incomplete work)
- Choice 2: mode = "CREATE" (start fresh, ignore existing)
- Choice 3: mode = "UPDATE" (enhance with new context)
</action>
</check>
<check if="epics.md does not exist">
<action>Set mode = "CREATE"</action>
<output>🆕 **INITIAL CREATION MODE**
No existing epics found - I'll create the initial epic breakdown.
</output>
</check>
<action>**Detect available context documents:**</action>
<action>Check which documents exist:
- UX Design specification ({ux_design_content})
- Architecture document ({architecture_content})
- Domain brief ({domain_brief_content})
- Product brief ({product_brief_content})
</action>
<check if="mode == 'UPDATE'">
<action>Identify what's NEW since last epic update:
- If UX exists AND not previously incorporated:
- Flag: "ADD_UX_DETAILS = true"
- Note UX sections to extract (interaction patterns, mockup references, responsive breakpoints)
- If Architecture exists AND not previously incorporated:
- Flag: "ADD_ARCH_DETAILS = true"
- Note Architecture sections to extract (tech stack, API contracts, data models)
</action>
<output>**Context Analysis:**
{{if ADD_UX_DETAILS}}
✅ UX Design found - will add interaction details to stories
{{/if}}
{{if ADD_ARCH_DETAILS}}
✅ Architecture found - will add technical implementation notes
{{/if}}
{{if !ADD_UX_DETAILS && !ADD_ARCH_DETAILS}}
⚠️ No new context documents found - reviewing for any PRD changes
{{/if}}
</output>
</check>
<check if="mode == 'CREATE'">
<output>**Available Context:**
- ✅ PRD (required)
{{if ux_design_content}}
- ✅ UX Design (will incorporate interaction patterns)
{{/if}}
{{if architecture_content}}
- ✅ Architecture (will incorporate technical decisions)
{{/if}}
{{if !ux_design_content && !architecture_content}}
- ℹ️ Creating basic epic structure (can be enhanced later with UX/Architecture)
{{/if}}
</output>
</check>
<template-output>workflow_mode</template-output>
<template-output>available_context</template-output>
</step>
<step n="1" goal="Load PRD and extract requirements">
<action>
<check if="mode == 'CREATE'">
Welcome {user_name} to epic and story planning
</check>
<check if="mode == 'UPDATE'">
Welcome back {user_name} - let's enhance your epic breakdown with new context
</check>
Load required documents (fuzzy match, handle both whole and sharded):
- PRD.md (required)
- domain-brief.md (if exists)
- product-brief.md (if exists)
**CRITICAL - PRD FRs Are Now Flat and Strategic:**
The PRD contains FLAT, capability-level functional requirements (FR1, FR2, FR3...).
These are STRATEGIC (WHAT capabilities exist), NOT tactical (HOW they're implemented).
Example PRD FRs:
- FR1: Users can create accounts with email or social authentication
- FR2: Users can log in securely and maintain sessions
- FR6: Users can create, edit, and delete content items
**Your job in THIS workflow:**
1. Map each FR to one or more epics
2. Break each FR into stories with DETAILED acceptance criteria
3. Add ALL the implementation details that were intentionally left out of PRD
Extract from PRD:
- ALL functional requirements (flat numbered list)
- Non-functional requirements
- Domain considerations and compliance needs
- Project type and complexity
- MVP vs growth vs vision scope boundaries
- Product differentiator (what makes it special)
- Technical constraints
- User types and their goals
- Success criteria
**Create FR Inventory:**
List all FRs to ensure coverage:
- FR1: [description]
- FR2: [description]
- ...
- FRN: [description]
This inventory will be used to validate complete coverage in Step 4.
</action>
<template-output>fr_inventory</template-output>
</step>
<step n="2" goal="Propose epic structure from natural groupings">
<check if="mode == 'UPDATE'">
<action>**MAINTAIN existing epic structure:**
Use the epic structure already defined in epics.md:
- Keep all existing epic titles and goals
- Preserve epic sequencing
- Maintain FR coverage mapping
Note: We're enhancing stories within existing epics, not restructuring.
</action>
<output>**Using existing epic structure:**
{{list_existing_epics_with_titles}}
Will enhance stories within these epics using new context.
</output>
<template-output>epics_summary</template-output>
<template-output>fr_coverage_map</template-output>
<goto step="3">Skip to story enhancement</goto>
</check>
<check if="mode == 'CREATE'">
<action>Analyze requirements and identify natural epic boundaries
INTENT: Find organic groupings that make sense for THIS product
Look for natural patterns:
- Features that work together cohesively
- User journeys that connect
- Business capabilities that cluster
- Domain requirements that relate (compliance, validation, security)
- Technical systems that should be built together
Name epics based on VALUE, not technical layers:
- Good: "User Onboarding", "Content Discovery", "Compliance Framework"
- Avoid: "Database Layer", "API Endpoints", "Frontend"
**⚠️ ANTI-PATTERN EXAMPLES (DO NOT DO THIS):**
❌ **WRONG - Technical Layer Breakdown:**
- Epic 1: Database Schema & Models
- Epic 2: API Layer / Backend Services
- Epic 3: Frontend UI Components
- Epic 4: Integration & Testing
WHY IT'S WRONG: User gets ZERO value until ALL epics complete. No incremental delivery.
✅ **CORRECT - User Value Breakdown:**
- Epic 1: Foundation (project setup - necessary exception)
- Epic 2: User Authentication (user can register/login - VALUE DELIVERED)
- Epic 3: Content Management (user can create/edit content - VALUE DELIVERED)
- Epic 4: Social Features (user can share/interact - VALUE DELIVERED)
WHY IT'S RIGHT: Each epic delivers something users can USE. Incremental value.
**Valid Exceptions:**
1. **Foundation Epic**: First epic CAN be setup/infrastructure (greenfield projects need this)
2. **API-First Epic**: ONLY valid if the API has standalone value (third-party consumers, multiple frontends, API-as-product). If it's just "backend for our frontend", that's the WRONG pattern.
Each epic should:
- Have clear business goal and user value
- Be independently valuable
- Contain 3-8 related capabilities
- Be deliverable in cohesive phase
For greenfield projects:
- First epic MUST establish foundation (project setup, core infrastructure, deployment pipeline)
- Foundation enables all subsequent work
For complex domains:
- Consider dedicated compliance/regulatory epics
- Group validation and safety requirements logically
- Note expertise requirements
Present proposed epic structure showing:
- Epic titles with clear value statements
- High-level scope of each epic
- **FR COVERAGE MAP: Which FRs does each epic address?**
- Example: "Epic 1 (Foundation): Covers infrastructure needs for all FRs"
- Example: "Epic 2 (User Management): FR1, FR2, FR3, FR4, FR5"
- Example: "Epic 3 (Content System): FR6, FR7, FR8, FR9"
- Suggested sequencing
- Why this grouping makes sense
**Validate FR Coverage:**
Check that EVERY FR from Step 1 inventory is mapped to at least one epic.
If any FRs are unmapped, add them now or explain why they're deferred.
</action>
<template-output>epics_summary</template-output>
<template-output>fr_coverage_map</template-output>
</check>
</step>
<step n="3" goal="Decompose each epic into bite-sized stories with DETAILED AC" repeat="for-each-epic">
<check if="mode == 'UPDATE'">
<action>**ENHANCE Epic {{N}} stories with new context:**
For each existing story in Epic {{N}}:
1. Preserve core story structure (title, user story statement)
2. Add/enhance based on available NEW context:
<check if="ADD_UX_DETAILS">
**Add from UX Design:**
- Specific mockup/wireframe references
- Exact interaction patterns
- Animation/transition specifications
- Responsive breakpoints
- Component specifications
- Error states and feedback patterns
- Accessibility requirements (WCAG compliance)
Example enhancement:
BEFORE: "User can log in"
AFTER: "User can log in via modal (UX pg 12-15) with email/password fields,
password visibility toggle, remember me checkbox,
loading state during auth (spinner overlay),
error messages below fields (red, 14px),
success redirects to dashboard with fade transition"
</check>
<check if="ADD_ARCH_DETAILS">
**Add from Architecture:**
- Specific API endpoints and contracts
- Data model references
- Tech stack implementation details
- Performance requirements
- Security implementation notes
- Cache strategies
- Error handling patterns
Example enhancement:
BEFORE: "System authenticates user"
AFTER: "System authenticates user via POST /api/v1/auth/login,
validates against users table (see Arch section 6.2),
returns JWT token (expires 7d) + refresh token (30d),
rate limited to 5 attempts/hour/IP,
logs failures to security_events table"
</check>
3. Update acceptance criteria with new details
4. Preserve existing prerequisites
5. Enhance technical notes with new context
</action>
</check>
<check if="mode == 'CREATE'">
<action>Break down Epic {{N}} into small, implementable stories
INTENT: Create stories sized for single dev agent completion
**CRITICAL - ALTITUDE SHIFT FROM PRD:**
PRD FRs are STRATEGIC (WHAT capabilities):
- ✅ "Users can create accounts"
Epic Stories are TACTICAL (HOW it's implemented):
- Email field with RFC 5322 validation
- Password requirements: 8+ chars, 1 uppercase, 1 number, 1 special
- Password strength meter with visual feedback
- Email verification within 15 minutes
- reCAPTCHA v3 integration
- Account creation completes in < 2 seconds
- Mobile responsive with 44x44px touch targets
- WCAG 2.1 AA compliant
**THIS IS WHERE YOU ADD ALL THE DETAILS LEFT OUT OF PRD:**
- UI specifics (exact field counts, validation rules, layout details)
- Performance targets (< 2s, 60fps, etc.)
- Technical implementation hints (libraries, patterns, APIs)
- Edge cases (what happens when...)
- Validation rules (regex patterns, constraints)
- Error handling (specific error messages, retry logic)
- Accessibility requirements (ARIA labels, keyboard nav, screen readers)
- Platform specifics (mobile responsive, browser support)
For each epic, generate:
- Epic title as `epic_title_{{N}}`
- Epic goal/value as `epic_goal_{{N}}`
- All stories as repeated pattern `story_title_{{N}}_{{M}}` for each story M
CRITICAL for Epic 1 (Foundation):
- Story 1.1 MUST be project setup/infrastructure initialization
- Sets up: repo structure, build system, deployment pipeline basics, core dependencies
- Creates foundation for all subsequent stories
- Note: Architecture workflow will flesh out technical details
Each story should follow BDD-style acceptance criteria:
**Story Pattern:**
As a [user type],
I want [specific capability],
So that [clear value/benefit].
**Acceptance Criteria using BDD:**
Given [precondition or initial state]
When [action or trigger]
Then [expected outcome]
And [additional criteria as needed]
**Prerequisites:** Only previous stories (never forward dependencies)
**Technical Notes:** Implementation guidance, affected components, compliance requirements
Ensure stories are:
- Vertically sliced (deliver complete functionality, not just one layer)
- Sequentially ordered (logical progression, no forward dependencies)
- Independently valuable when possible
- Small enough for single-session completion
- Clear enough for autonomous implementation
For each story in epic {{N}}, output variables following this pattern:
- story*title*{{N}}_1, story_title_{{N}}\*2, etc.
- Each containing: user story, BDD acceptance criteria, prerequisites, technical notes</action>
<template-output>epic*title*{{N}}</template-output>
<template-output>epic*goal*{{N}}</template-output>
<action>For each story M in epic {{N}}, generate story content</action>
<template-output>story-title-{{N}}-{{M}}</template-output>
</check>
<action>**EPIC {{N}} REVIEW - Present for Checkpoint:**
Summarize the COMPLETE epic breakdown:
**Epic {{N}}: {{epic_title}}**
Goal: {{epic_goal}}
Stories ({{count}} total):
{{for each story, show:}}
- Story {{N}}.{{M}}: {{story_title}}
- User Story: As a... I want... So that...
- Acceptance Criteria: (BDD format summary)
- Prerequisites: {{list}}
**Review Questions to Consider:**
- Is the story sequence logical?
- Are acceptance criteria clear and testable?
- Are there any missing stories for the FRs this epic covers?
- Are the stories sized appropriately (single dev agent session)?
- FRs covered by this epic: {{FR_list}}
**NOTE:** At the checkpoint prompt, select [a] for Advanced Elicitation if you want to refine stories, add missing ones, or reorder. Select [c] to approve this epic and continue to the next one.
</action>
<template-output>epic\_{{N}}\_complete_breakdown</template-output>
</step>
<step n="4" goal="Review epic breakdown and completion">
<check if="mode == 'UPDATE'">
<action>Review the ENHANCED epic breakdown for completeness
**Validate Enhancements:**
- All stories now have context-appropriate details
- UX references added where applicable
- Architecture decisions incorporated where applicable
- Acceptance criteria updated with new specifics
- Technical notes enhanced with implementation details
**Quality Check:**
- Stories remain bite-sized for single dev agent sessions
- No forward dependencies introduced
- All new context properly integrated
</action>
<template-output>epic_breakdown_summary</template-output>
<template-output>enhancement_summary</template-output>
<output>✅ **Epic Enhancement Complete!**
**Updated:** epics.md with enhanced context
**Enhancements Applied:**
{{if ADD_UX_DETAILS}}
- ✅ UX interaction patterns and mockup references added
{{/if}}
{{if ADD_ARCH_DETAILS}}
- ✅ Architecture technical decisions and API contracts added
{{/if}}
The epic breakdown now includes all available context for Phase 4 implementation.
**Next Steps:**
{{if !architecture_content}}
- Run Architecture workflow for technical decisions
{{/if}}
{{if architecture_content}}
- Ready for Phase 4: Sprint Planning
{{/if}}
</output>
</check>
<check if="mode == 'CREATE'">
<action>Review the complete epic breakdown for quality and completeness
**Validate Epic Structure (USER VALUE CHECK):**
For each epic, answer: "What can USERS do after this epic is complete that they couldn't do before?"
- Epic 1: [Must have clear user value OR be Foundation exception]
- Epic 2: [Must deliver user-facing capability]
- Epic N: [Must deliver user-facing capability]
⚠️ RED FLAG: If an epic only delivers technical infrastructure (database layer, API without users, component library without features), RESTRUCTURE IT. Each epic should enable users to accomplish something.
Exception validation:
- Foundation epic: Acceptable as first epic for greenfield projects
- API-first epic: Acceptable ONLY if API has standalone consumers (third-party integrations, multiple frontends, API-as-product)
If any epic fails this check, restructure before proceeding.
**Validate FR Coverage:**
Create FR Coverage Matrix showing each FR mapped to epic(s) and story(ies):
- FR1: [description] → Epic X, Story X.Y
- FR2: [description] → Epic X, Story X.Z
- FR3: [description] → Epic Y, Story Y.A
- ...
- FRN: [description] → Epic Z, Story Z.B
Confirm: EVERY FR from Step 1 inventory is covered by at least one story.
If any FRs are missing, add stories now.
**Validate Story Quality:**
- All functional requirements from PRD are covered by stories
- Epic 1 establishes proper foundation (if greenfield)
- All stories are vertically sliced (deliver complete functionality, not just one layer)
- No forward dependencies exist (only backward references)
- Story sizing is appropriate for single-session completion
- BDD acceptance criteria are clear and testable
- Details added (what was missing from PRD FRs: UI specifics, performance targets, etc.)
- Domain/compliance requirements are properly distributed
- Sequencing enables incremental value delivery
Confirm with {user_name}:
- Epic structure makes sense
- All FRs covered by stories (validated via coverage matrix)
- Story breakdown is actionable
<check if="ux_design_content && architecture_content">
- All available context has been incorporated (PRD + UX + Architecture)
- Ready for Phase 4 Implementation
</check>
<check if="ux_design_content && !architecture_content">
- UX context has been incorporated
- Ready for Architecture workflow (recommended next step)
</check>
<check if="!ux_design_content && architecture_content">
- Architecture context has been incorporated
- Consider running UX Design workflow if UI exists
</check>
<check if="!ux_design_content && !architecture_content">
- Basic epic structure created from PRD
- Ready for next planning phase (UX Design or Architecture)
</check>
</action>
<template-output>epic_breakdown_summary</template-output>
<template-output>fr_coverage_matrix</template-output>
<check if="mode == 'CREATE'">
<output>**✅ Epic Breakdown Complete**
**Created:** epics.md with epic and story breakdown
**FR Coverage:** All functional requirements from PRD mapped to stories
**Context Incorporated:**
{{if ux_design_content && architecture_content}}
- ✅ PRD requirements
- ✅ UX interaction patterns
- ✅ Architecture technical decisions
**Status:** COMPLETE - Ready for Phase 4 Implementation!
{{/if}}
{{if ux_design_content && !architecture_content}}
- ✅ PRD requirements
- ✅ UX interaction patterns
**Next:** Run Architecture workflow for technical decisions
{{/if}}
{{if !ux_design_content && architecture_content}}
- ✅ PRD requirements
- ✅ Architecture technical decisions
**Next:** Consider UX Design workflow if UI needed
{{/if}}
{{if !ux_design_content && !architecture_content}}
- ✅ PRD requirements (basic structure)
**Next:** Run UX Design (if UI) or Architecture workflow
**Note:** Epics will be enhanced with additional context later
{{/if}}
</output>
</check>
</check>
</step>
</workflow>

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

@ -13,27 +13,37 @@ document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
date: system-generated
# Input requirements
recommended_inputs:
- prd: "Product Requirements Document with FRs and NFRs"
- product_brief: "Product Brief with vision and goals (optional)"
- domain_brief: "Domain-specific requirements and context (optional)"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
input_file_patterns:
prd:
description: "Product Requirements Document with FRs and NFRs"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/index.md"
load_strategy: "INDEX_GUIDED"
product_brief:
description: "Product vision and goals (optional)"
whole: "{output_folder}/*product*brief*.md"
sharded: "{output_folder}/*product*brief*/index.md"
load_strategy: "INDEX_GUIDED"
domain_brief:
description: "Domain-specific requirements and context (optional)"
whole: "{output_folder}/*domain*brief*.md"
sharded: "{output_folder}/*domain*brief*/index.md"
load_strategy: "INDEX_GUIDED"
ux_design:
description: "UX design specification for interaction patterns (optional)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/index.md"
load_strategy: "FULL_LOAD"
architecture:
description: "Architecture decisions and technical design (optional)"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/index.md"
load_strategy: "FULL_LOAD"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories"
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories"
instructions: "{installed_path}/instructions.md"
template: "{installed_path}/epics-template.md"
@ -46,8 +56,8 @@ web_bundle:
name: "create-epics-and-stories"
description: "Transform PRD requirements into bite-sized stories organized in epics for 200k context dev agents"
author: "BMad"
instructions: "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
template: "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
instructions: "{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/instructions.md"
template: "{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/epics-template.md"
web_bundle_files:
- "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
- "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
- "{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/instructions.md"
- "{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/epics-template.md"

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

@ -11,6 +11,8 @@
<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>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>

18
src/modules/bmm/workflows/2-plan-workflows/create-ux-design/workflow.yaml
View File

@ -12,43 +12,37 @@ document_output_language: "{config_source}:document_output_language"
user_skill_level: "{config_source}:user_skill_level"
date: system-generated
# Input requirements - We work from PRD, Brief, or Brainstorming docs
recommended_inputs:
- prd: "Product Requirements Document with features and user journeys"
- product_brief: "Product brief with vision and target users"
- brainstorming: "Brainstorming documents with ideas and concepts"
# Input file references (fuzzy matched from output folder)
prd_file: "{output_folder}/bmm-PRD.md or PRD.md or product-requirements.md"
brief_file: "{output_folder}/product-brief.md or brief.md or project-brief.md"
brainstorm_file: "{output_folder}/brainstorming.md or brainstorm.md or ideation.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
input_file_patterns:
prd:
description: "Features and user journeys (optional)"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/index.md"
load_strategy: "FULL_LOAD"
product_brief:
description: "Product vision and target users (optional)"
whole: "{output_folder}/*brief*.md"
sharded: "{output_folder}/*brief*/index.md"
load_strategy: "FULL_LOAD"
epics:
description: "Epic and story breakdown (optional)"
whole: "{output_folder}/*epic*.md"
sharded: "{output_folder}/*epic*/index.md"
load_strategy: "FULL_LOAD"
brainstorming:
description: "Brainstorming ideas and concepts (optional)"
whole: "{output_folder}/*brainstorm*.md"
sharded: "{output_folder}/*brainstorm*/index.md"
load_strategy: "FULL_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
# Module path and component files

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

@ -1,292 +0,0 @@
# Epic and Story Decomposition - Intent-Based Implementation Planning
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
<critical>This workflow transforms requirements into BITE-SIZED STORIES for development agents</critical>
<critical>EVERY story must be completable by a single dev agent in one focused session</critical>
<critical>BMAD METHOD WORKFLOW POSITION: This is the FIRST PASS at epic breakdown</critical>
<critical>After this workflow: UX Design will add interaction details → UPDATE epics.md</critical>
<critical>After UX: Architecture will add technical decisions → UPDATE epics.md AGAIN</critical>
<critical>Phase 4 Implementation pulls context from: PRD + epics.md + UX + Architecture</critical>
<critical>This is a LIVING DOCUMENT that evolves through the BMad Method workflow chain</critical>
<critical>Communicate all responses in {communication_language} and adapt to {user_skill_level}</critical>
<critical>Generate all documents in {document_output_language}</critical>
<critical>LIVING DOCUMENT: Write to epics.md continuously as you work - never wait until the end</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<workflow>
<step n="1" goal="Load PRD and extract requirements">
<action>Welcome {user_name} to epic and story planning
Load required documents (fuzzy match, handle both whole and sharded):
- PRD.md (required)
- domain-brief.md (if exists)
- product-brief.md (if exists)
**CRITICAL - PRD FRs Are Now Flat and Strategic:**
The PRD contains FLAT, capability-level functional requirements (FR1, FR2, FR3...).
These are STRATEGIC (WHAT capabilities exist), NOT tactical (HOW they're implemented).
Example PRD FRs:
- FR1: Users can create accounts with email or social authentication
- FR2: Users can log in securely and maintain sessions
- FR6: Users can create, edit, and delete content items
**Your job in THIS workflow:**
1. Map each FR to one or more epics
2. Break each FR into stories with DETAILED acceptance criteria
3. Add ALL the implementation details that were intentionally left out of PRD
Extract from PRD:
- ALL functional requirements (flat numbered list)
- Non-functional requirements
- Domain considerations and compliance needs
- Project type and complexity
- MVP vs growth vs vision scope boundaries
- Product differentiator (what makes it special)
- Technical constraints
- User types and their goals
- Success criteria
**Create FR Inventory:**
List all FRs to ensure coverage:
- FR1: [description]
- FR2: [description]
- ...
- FRN: [description]
This inventory will be used to validate complete coverage in Step 4.
</action>
<template-output>fr_inventory</template-output>
</step>
<step n="2" goal="Propose epic structure from natural groupings">
<action>Analyze requirements and identify natural epic boundaries
INTENT: Find organic groupings that make sense for THIS product
Look for natural patterns:
- Features that work together cohesively
- User journeys that connect
- Business capabilities that cluster
- Domain requirements that relate (compliance, validation, security)
- Technical systems that should be built together
Name epics based on VALUE, not technical layers:
- Good: "User Onboarding", "Content Discovery", "Compliance Framework"
- Avoid: "Database Layer", "API Endpoints", "Frontend"
Each epic should:
- Have clear business goal and user value
- Be independently valuable
- Contain 3-8 related capabilities
- Be deliverable in cohesive phase
For greenfield projects:
- First epic MUST establish foundation (project setup, core infrastructure, deployment pipeline)
- Foundation enables all subsequent work
For complex domains:
- Consider dedicated compliance/regulatory epics
- Group validation and safety requirements logically
- Note expertise requirements
Present proposed epic structure showing:
- Epic titles with clear value statements
- High-level scope of each epic
- **FR COVERAGE MAP: Which FRs does each epic address?**
- Example: "Epic 1 (Foundation): Covers infrastructure needs for all FRs"
- Example: "Epic 2 (User Management): FR1, FR2, FR3, FR4, FR5"
- Example: "Epic 3 (Content System): FR6, FR7, FR8, FR9"
- Suggested sequencing
- Why this grouping makes sense
**Validate FR Coverage:**
Check that EVERY FR from Step 1 inventory is mapped to at least one epic.
If any FRs are unmapped, add them now or explain why they're deferred.
</action>
<template-output>epics_summary</template-output>
<template-output>fr_coverage_map</template-output>
</step>
<step n="3" goal="Decompose each epic into bite-sized stories with DETAILED AC" repeat="for-each-epic">
<action>Break down Epic {{N}} into small, implementable stories
INTENT: Create stories sized for single dev agent completion
**CRITICAL - ALTITUDE SHIFT FROM PRD:**
PRD FRs are STRATEGIC (WHAT capabilities):
- ✅ "Users can create accounts"
Epic Stories are TACTICAL (HOW it's implemented):
- Email field with RFC 5322 validation
- Password requirements: 8+ chars, 1 uppercase, 1 number, 1 special
- Password strength meter with visual feedback
- Email verification within 15 minutes
- reCAPTCHA v3 integration
- Account creation completes in < 2 seconds
- Mobile responsive with 44x44px touch targets
- WCAG 2.1 AA compliant
**THIS IS WHERE YOU ADD ALL THE DETAILS LEFT OUT OF PRD:**
- UI specifics (exact field counts, validation rules, layout details)
- Performance targets (< 2s, 60fps, etc.)
- Technical implementation hints (libraries, patterns, APIs)
- Edge cases (what happens when...)
- Validation rules (regex patterns, constraints)
- Error handling (specific error messages, retry logic)
- Accessibility requirements (ARIA labels, keyboard nav, screen readers)
- Platform specifics (mobile responsive, browser support)
For each epic, generate:
- Epic title as `epic_title_{{N}}`
- Epic goal/value as `epic_goal_{{N}}`
- All stories as repeated pattern `story_title_{{N}}_{{M}}` for each story M
CRITICAL for Epic 1 (Foundation):
- Story 1.1 MUST be project setup/infrastructure initialization
- Sets up: repo structure, build system, deployment pipeline basics, core dependencies
- Creates foundation for all subsequent stories
- Note: Architecture workflow will flesh out technical details
Each story should follow BDD-style acceptance criteria:
**Story Pattern:**
As a [user type],
I want [specific capability],
So that [clear value/benefit].
**Acceptance Criteria using BDD:**
Given [precondition or initial state]
When [action or trigger]
Then [expected outcome]
And [additional criteria as needed]
**Prerequisites:** Only previous stories (never forward dependencies)
**Technical Notes:** Implementation guidance, affected components, compliance requirements
Ensure stories are:
- Vertically sliced (deliver complete functionality, not just one layer)
- Sequentially ordered (logical progression, no forward dependencies)
- Independently valuable when possible
- Small enough for single-session completion
- Clear enough for autonomous implementation
For each story in epic {{N}}, output variables following this pattern:
- story*title*{{N}}_1, story_title_{{N}}\*2, etc.
- Each containing: user story, BDD acceptance criteria, prerequisites, technical notes</action>
<template-output>epic*title*{{N}}</template-output>
<template-output>epic*goal*{{N}}</template-output>
<action>For each story M in epic {{N}}, generate story content</action>
<template-output>story-title-{{N}}-{{M}}</template-output>
</step>
<step n="4" goal="Review initial epic breakdown and prepare for updates">
<action>Review the complete epic breakdown for quality and completeness
**Validate FR Coverage:**
Create FR Coverage Matrix showing each FR mapped to epic(s) and story(ies):
- FR1: [description] → Epic X, Story X.Y
- FR2: [description] → Epic X, Story X.Z
- FR3: [description] → Epic Y, Story Y.A
- ...
- FRN: [description] → Epic Z, Story Z.B
Confirm: EVERY FR from Step 1 inventory is covered by at least one story.
If any FRs are missing, add stories now.
**Validate Story Quality:**
- All functional requirements from PRD are covered by stories
- Epic 1 establishes proper foundation (if greenfield)
- All stories are vertically sliced (deliver complete functionality, not just one layer)
- No forward dependencies exist (only backward references)
- Story sizing is appropriate for single-session completion
- BDD acceptance criteria are clear and testable
- Details added (what was missing from PRD FRs: UI specifics, performance targets, etc.)
- Domain/compliance requirements are properly distributed
- Sequencing enables incremental value delivery
**BMad Method Next Steps:**
This epic breakdown is the INITIAL VERSION. It will be updated as you progress:
1. **After UX Design Workflow:**
- UX Designer will design interactions for capabilities
- UPDATE story acceptance criteria with UX specs (mockup references, flow details)
- Add interaction patterns, visual design decisions, responsive breakpoints
2. **After Architecture Workflow:**
- Architect will define technical implementation approach
- UPDATE story technical notes with architecture decisions
- Add references to data models, API contracts, tech stack choices, deployment patterns
3. **During Phase 4 Implementation:**
- Each story pulls context from: PRD (why) + epics.md (what/how) + UX (interactions) + Architecture (technical)
- Stories may be further refined as implementation uncovers edge cases
- This document remains the single source of truth for story details
Confirm with {user_name}:
- Epic structure makes sense
- All FRs covered by stories (validated via coverage matrix)
- Story breakdown is actionable with detailed acceptance criteria
- Ready for UX Design workflow (next BMad Method step)
</action>
<template-output>epic_breakdown_summary</template-output>
<template-output>fr_coverage_matrix</template-output>
<output>**✅ Epic Breakdown Complete (Initial Version)**
**Created:** epics.md with epic and story breakdown
**FR Coverage:** All functional requirements from PRD mapped to stories (see coverage matrix in document)
**Next Steps in BMad Method:**
1. **UX Design** (if UI exists) - Run: `workflow ux-design`
→ Will add interaction details to stories in epics.md
2. **Architecture** - Run: `workflow create-architecture`
→ Will add technical details to stories in epics.md
3. **Phase 4 Implementation** - Stories ready for context assembly
**Important:** This is a living document that will be updated as you progress through the workflow chain. The epics.md file will evolve with UX and Architecture inputs before implementation begins.
</output>
</step>
</workflow>

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

@ -8,6 +8,8 @@
<critical>LIVING DOCUMENT: Write to PRD.md continuously as you discover - never wait until the end</critical>
<critical>GUIDING PRINCIPLE: Identify what makes this product special and ensure it's reflected throughout the PRD</critical>
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>
@ -53,37 +55,90 @@ PRD is for BMad Method and Enterprise Method tracks that need comprehensive requ
<action>Welcome {user_name} and begin comprehensive discovery, and then start to GATHER ALL CONTEXT:
1. Check workflow-status.yaml for project_context (if exists)
2. Review loaded content: {product_brief_content}, {research_content}, {document_project_content} (auto-loaded in Step 0.5)
3. Detect project type AND domain complexity
3. Detect project type AND domain complexity using data-driven classification
</action>
Load references:
{installed_path}/project-types.csv
{installed_path}/domain-complexity.csv
<action>Load classification data files COMPLETELY:
Through natural conversation:
- Load {project_types_data} - contains project type definitions, detection signals, and requirements
- Load {domain_complexity_data} - contains domain classifications, complexity levels, and special requirements
Parse CSV structure:
- project_types_data has columns: project_type, detection_signals, key_questions, required_sections, skip_sections, web_search_triggers, innovation_signals
- domain_complexity_data has columns: domain, signals, complexity, key_concerns, required_knowledge, suggested_workflow, web_searches, special_sections
Store these in memory for use throughout the workflow.
</action>
<action>Begin natural discovery conversation:
"Tell me about what you want to build - what problem does it solve and for whom?"
DUAL DETECTION:
Project type signals: API, mobile, web, CLI, SDK, SaaS
Domain complexity signals: medical, finance, government, education, aerospace
As the user describes their product, listen for signals to classify:
SPECIAL ROUTING:
If game detected → Inform user that game development requires the BMGD module (BMad Game Development)
If complex domain detected → Offer domain research options:
A) Run domain-research workflow (thorough)
B) Quick web search (basic)
C) User provides context
1. PROJECT TYPE classification
2. DOMAIN classification
</action>
<action>DUAL DETECTION - Use CSV data to match:
**Project Type Detection:**
- Compare user's description against detection_signals from each row in project_types_data
- Look for keyword matches (semicolon-separated in CSV)
- Identify best matching project_type (api_backend, mobile_app, saas_b2b, developer_tool, cli_tool, web_app, game, desktop_app, iot_embedded, blockchain_web3)
- If multiple matches, ask clarifying question
- Store matched project_type value
**Domain Detection:**
- Compare user's description against signals from each row in domain_complexity_data
- Match domain keywords (semicolon-separated in CSV)
- Identify domain (healthcare, fintech, govtech, edtech, aerospace, automotive, scientific, legaltech, insuretech, energy, gaming, general)
- Get complexity level from matched row (high/medium/low/redirect)
- Store matched domain and complexity_level values
**Special Cases from CSV:**
- If project_type = "game" → Use project_types_data row to get redirect message
- If domain = "gaming" → Use domain_complexity_data redirect action
- If complexity = "high" → Note suggested_workflow and web_searches from domain row
</action>
<action>SPECIAL ROUTING based on detected values:
**If game detected (from project_types_data):**
"Game development requires the BMGD module (BMad Game Development) which has specialized workflows for game design."
Exit workflow and redirect to BMGD.
**If complex domain detected (complexity = "high" from domain_complexity_data):**
Extract suggested_workflow and web_searches from the matched domain row.
Offer domain research options:
A) Run {suggested_workflow} workflow (thorough) - from CSV
B) Quick web search using {web_searches} queries - from CSV
C) User provides their own domain context
D) Continue with general knowledge
IDENTIFY WHAT MAKES IT SPECIAL early with questions such as: "What excites you most about this product?", "What would make users love this?", "What's the unique value or compelling moment?"
Present the options and WAIT for user choice.
</action>
This becomes a thread that connects throughout the PRD.</action>
<action>IDENTIFY WHAT MAKES IT SPECIAL early in conversation:
Ask questions like:
- "What excites you most about this product?"
- "What would make users love this?"
- "What's the unique value or compelling moment?"
- "What makes this different from alternatives?"
Capture this differentiator - it becomes a thread connecting throughout the PRD.
</action>
<template-output>vision_alignment</template-output>
<template-output>project_classification</template-output>
<template-output>project_type</template-output>
<template-output>domain_type</template-output>
<template-output>complexity_level</template-output>
<check if="complex domain">
<check if="complexity_level == 'high'">
<template-output>domain_context_summary</template-output>
</check>
<template-output>product_differentiator</template-output>
@ -147,46 +202,122 @@ For complex domains:
</step>
<step n="4" goal="Domain-Specific Exploration" optional="true">
<action>Only if complex domain detected or domain-brief exists
<critical>This step is DATA-DRIVEN using domain_complexity_data CSV loaded in Step 1</critical>
<action>Execute only if complexity_level = "high" OR domain-brief exists</action>
<action>Retrieve domain-specific configuration from CSV:
1. Find the row in {domain_complexity_data} where domain column matches the detected {domain} from Step 1
2. Extract these columns from the matched row:
- key_concerns (semicolon-separated list)
- required_knowledge (describes what expertise is needed)
- web_searches (suggested search queries if research needed)
- special_sections (semicolon-separated list of domain-specific sections to document)
3. Parse the semicolon-separated values into lists
4. Store for use in this step
</action>
<action>Explore domain-specific requirements using key_concerns from CSV:
Parse key_concerns into individual concern areas.
For each concern:
- Ask the user about their approach to this concern
- Discuss implications for the product
- Document requirements, constraints, and compliance needs
Example for healthcare domain:
If key_concerns = "FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability"
Then explore:
- "Will this product require FDA approval? What classification?"
- "How will you validate clinical accuracy and safety?"
- "What HIPAA compliance measures are needed?"
- "What patient safety protocols must be in place?"
- "What liability considerations affect the design?"
Synthesize domain requirements that will shape everything:
- Regulatory requirements
- Compliance needs
- Industry standards
- Safety/risk factors
- Required validations
- Special expertise needed
- Regulatory requirements (from key_concerns)
- Compliance needs (from key_concerns)
- Industry standards (from required_knowledge)
- Safety/risk factors (from key_concerns)
- Required validations (from key_concerns)
- Special expertise needed (from required_knowledge)
These inform:
- What features are mandatory
- What NFRs are critical
- How to sequence development
- What validation is required</action>
- What validation is required
</action>
<check if="complex domain">
<check if="complexity_level == 'high'">
<template-output>domain_considerations</template-output>
</check>
</step>
<action>Generate domain-specific special sections if defined:
Parse special_sections list from the matched CSV row.
For each section name, generate corresponding template-output.
Example mappings from CSV:
- "clinical_requirements" → <template-output>clinical_requirements</template-output>
- "regulatory_pathway" → <template-output>regulatory_pathway</template-output>
- "safety_measures" → <template-output>safety_measures</template-output>
- "compliance_matrix" → <template-output>compliance_matrix</template-output>
</action>
</check>
</step>
<step n="5" goal="Innovation Discovery" optional="true">
<action>Identify truly novel patterns if applicable
<critical>This step uses innovation_signals from project_types_data CSV loaded in Step 1</critical>
Listen for innovation signals:
<action>Check for innovation in this product:
1. Retrieve innovation_signals from the project_type row in {project_types_data}
2. Parse the semicolon-separated innovation signals specific to this project type
3. Listen for these signals in user's description and throughout conversation
Example for api_backend:
innovation_signals = "API composition;New protocol"
Example for mobile_app:
innovation_signals = "Gesture innovation;AR/VR features"
Example for saas_b2b:
innovation_signals = "Workflow automation;AI agents"
</action>
<action>Listen for general innovation signals in conversation:
User language indicators:
- "Nothing like this exists"
- "We're rethinking how [X] works"
- "Combining [A] with [B] for the first time"
- "Novel approach to [problem]"
- "No one has done [concept] before"
Project-type-specific signals (from CSV innovation_signals column):
- Match user's descriptions against the innovation_signals for their project_type
- If matches found, flag as innovation opportunity
</action>
<action>If innovation detected (general OR project-type-specific):
Explore deeply:
- What makes it unique?
- What assumption are you challenging?
- How do we validate it?
- What's the fallback?
- How do we validate it works?
- What's the fallback if it doesn't?
- Has anyone tried this before?
<WebSearch if="novel">{concept} innovations {date}</WebSearch></action>
Use web_search_triggers from project_types_data CSV if relevant:
<WebSearch if="novel">{web_search_triggers} {concept} innovations {date}</WebSearch>
</action>
<check if="innovation detected">
<template-output>innovation_patterns</template-output>
@ -195,53 +326,101 @@ Explore deeply:
</step>
<step n="6" goal="Project-Specific Deep Dive">
<action>Based on detected project type, dive deep into specific needs
<critical>This step is DATA-DRIVEN using project_types_data CSV loaded in Step 1</critical>
Load project type requirements from CSV and expand naturally.
<action>Retrieve project-specific configuration from CSV:
FOR API/BACKEND:
1. Find the row in {project_types_data} where project_type column matches the detected {project_type} from Step 1
2. Extract these columns from the matched row:
- key_questions (semicolon-separated list)
- required_sections (semicolon-separated list)
- skip_sections (semicolon-separated list)
- innovation_signals (semicolon-separated list)
3. Parse the semicolon-separated values into lists
4. Store for use in this step
</action>
- Map out endpoints, methods, parameters
- Define authentication and authorization
- Specify error codes and rate limits
- Document data schemas
<action>Conduct guided discovery using key_questions from CSV:
FOR MOBILE:
Parse key_questions into individual questions.
For each question:
- Platform requirements (iOS/Android/both)
- Device features needed
- Offline capabilities
- Store compliance
- Ask the user naturally in conversational style
- Listen for their response
- Ask clarifying follow-ups as needed
- Connect answers to product value proposition
FOR SAAS B2B:
Example flow:
If key_questions = "Endpoints needed?;Authentication method?;Data formats?"
Then ask:
- Multi-tenant architecture
- Permission models
- Subscription tiers
- Critical integrations
- "What are the main endpoints your API needs to expose?"
- "How will you handle authentication and authorization?"
- "What data formats will you support for requests and responses?"
[Continue for other types...]
Adapt questions to the user's context and skill level.
</action>
<action>Document project-type-specific requirements:
Based on the user's answers to key_questions, synthesize comprehensive requirements for this project type.
Cover the areas indicated by required_sections from CSV (semicolon-separated list).
Skip areas indicated by skip_sections from CSV.
For each required section:
- Summarize what was discovered
- Document specific requirements, constraints, and decisions
- Connect to product differentiator when relevant
Always connect requirements to product value:
"How does [requirement] support the product's core value proposition?"</action>
"How does [requirement] support the product's core value proposition?"
</action>
<template-output>project_type_requirements</template-output>
<!-- Dynamic sections based on project type -->
<check if="API/Backend project">
<template-output>endpoint_specification</template-output>
<template-output>authentication_model</template-output>
</check>
<!-- Dynamic template outputs based on required_sections from CSV -->
<check if="Mobile project">
<template-output>platform_requirements</template-output>
<template-output>device_features</template-output>
</check>
<action>Generate dynamic template outputs based on required_sections:
<check if="SaaS B2B project">
<template-output>tenant_model</template-output>
<template-output>permission_matrix</template-output>
</check>
Parse required_sections list from the matched CSV row.
For each section name in the list, generate a corresponding template-output.
Common mappings (adapt based on actual CSV values):
- "endpoint_specs" or "endpoint_specification" → <template-output>endpoint_specification</template-output>
- "auth_model" or "authentication_model" → <template-output>authentication_model</template-output>
- "platform_reqs" or "platform_requirements" → <template-output>platform_requirements</template-output>
- "device_permissions" or "device_features" → <template-output>device_features</template-output>
- "tenant_model" → <template-output>tenant_model</template-output>
- "rbac_matrix" or "permission_matrix" → <template-output>permission_matrix</template-output>
Generate all outputs dynamically - do not hardcode specific project types.
</action>
<note>Example CSV row for api_backend:
key_questions = "Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?"
required_sections = "endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs"
skip_sections = "ux_ui;visual_design;user_journeys"
The LLM should parse these and generate corresponding template outputs dynamically.
**Template Variable Strategy:**
The prd-template.md has common template variables defined (endpoint_specification, authentication_model, platform_requirements, device_features, tenant_model, permission_matrix).
For required_sections that match these common variables:
- Generate the specific template-output (e.g., endpoint_specs → endpoint_specification)
- These will render in their own subsections in the template
For required_sections that DON'T have matching template variables:
- Include the content in the main project_type_requirements variable
- This ensures all requirements are captured even if template doesn't have dedicated sections
This hybrid approach balances template structure with CSV-driven flexibility.
</note>
</step>
<step n="7" goal="UX Principles" if="project has UI or UX">
@ -403,8 +582,7 @@ Number sequentially across all groups (FR1, FR2... FR47).
2. "Is each FR independent (not dependent on reading other FRs to understand)?"
3. "Did I avoid vague terms like 'good', 'fast', 'easy'?" (Use NFRs for quality attributes)
COMPLETENESS GATE: Review your FR list against the entire PRD written so far.
Did you miss anything? Add it now before proceeding.
COMPLETENESS GATE: Review your FR list against the entire PRD written so far and think hard - did you miss anything? Add it now before proceeding.
</action>
<template-output>functional_requirements_complete</template-output>
@ -445,80 +623,80 @@ Skip categories that don't apply!</action>
</check>
</step>
<step n="10" goal="Review PRD and transition to epics">
<action>Review the PRD we've built together
<step n="10" goal="Complete PRD and determine next steps">
<action>Quick review of captured requirements:
"Let's review what we've captured:
"We've captured:
- Vision: [summary]
- Success: [key metrics]
- Scope: [MVP highlights]
- Requirements: [count] functional, [count] non-functional
- Special considerations: [domain/innovation]
- {{fr_count}} functional requirements
- {{nfr_count}} non-functional requirements
- MVP scope defined
{{if domain_complexity == 'high'}}
- Domain-specific requirements addressed
{{/if}}
{{if innovation_detected}}
- Innovation patterns documented
{{/if}}
Does this capture your product vision?"</action>
Your PRD is complete!"
</action>
<template-output>prd_summary</template-output>
<action>After PRD review and refinement complete:
"Excellent! Now we need to break these requirements into implementable epics and stories.
For the epic breakdown, you have two options:
1. Start a new session focused on epics (recommended for complex projects)
2. Continue here (I'll transform requirements into epics now)
Which would you prefer?"
If new session:
"To start epic planning in a new session:
1. Save your work here
2. Start fresh and run: workflow epics-stories
3. It will load your PRD and create the epic breakdown
This keeps each session focused and manageable."
If continue:
"Let's continue with epic breakdown here..."
[Proceed with epics-stories subworkflow]
Set project_track based on workflow status (BMad Method or Enterprise Method)
Generate epic_details for the epics breakdown document</action>
<template-output>project_track</template-output>
<template-output>epic_details</template-output>
</step>
<step n="11" goal="Complete PRD and suggest next steps">
<template-output>product_value_summary</template-output>
<check if="standalone_mode != true">
<action>Load the FULL file: {status_file}</action>
<action>Update workflow_status["prd"] = "{default_output_file}"</action>
<action>Save file, preserving ALL comments and structure</action>
</check>
<action>Check workflow path to determine next expected workflows:
- Look for "create-epics-and-stories" as optional after PRD
- Look for "create-design" as conditional (if_has_ui)
- Look for "create-epics-and-stories-after-ux" as optional
- Identify the required next phase workflow
</action>
</check>
<output>**✅ PRD Complete, {user_name}!**
Your product requirements are documented and ready for implementation.
**Created:**
- **PRD.md** - Complete requirements adapted to {project_type} and {domain}
**Created:** PRD.md with {{fr_count}} FRs and NFRs
**Next Steps:**
1. **Epic Breakdown** (Required)
Run: `workflow create-epics-and-stories` to decompose requirements into implementable stories
<check if="standalone_mode != true">
Based on your {{project_track}} workflow path, you can:
2. **UX Design** (If UI exists)
Run: `workflow ux-design` for detailed user experience design
**Option A: Create Epic Breakdown Now** (Optional)
`workflow create-epics-and-stories`
3. **Architecture** (Recommended)
Run: `workflow create-architecture` for technical architecture decisions
- Creates basic epic structure from PRD
- Can be enhanced later with UX/Architecture context
What makes your product special - {product_value_summary} - is captured throughout the PRD and will guide all subsequent work.
<check if="UI_exists">
**Option B: UX Design First** (Recommended if UI)
`workflow create-design`
- Design user experience and interactions
- Epic breakdown can incorporate UX details later
</check>
**Option C: Skip to Architecture**
`workflow create-architecture`
- Define technical decisions
- Epic breakdown created after with full context
**Recommendation:** {{if UI_exists}}Do UX Design first, then Architecture, then create epics with full context{{else}}Go straight to Architecture, then create epics{{/if}}
</check>
<check if="standalone_mode == true">
**Typical next workflows:**
1. `workflow create-design` - UX Design (if UI exists)
2. `workflow create-architecture` - Technical architecture
3. `workflow create-epics-and-stories` - Epic breakdown
**Note:** Epics can be created at any point but have richer detail when created after UX/Architecture.
</check>
</output>
</step>

33
src/modules/bmm/workflows/2-plan-workflows/prd/prd-template.md
View File

@ -199,39 +199,6 @@ _No specific non-functional requirements identified for this project type._
---
## Implementation Planning
### Epic Breakdown Required
Requirements must be decomposed into epics and bite-sized stories (200k context limit).
**Next Step:** Run `workflow epics-stories` to create the implementation breakdown.
---
## References
{{#if product_brief_path}}
- Product Brief: {{product_brief_path}}
{{/if}}
{{#if domain_brief_path}}
- Domain Brief: {{domain_brief_path}}
{{/if}}
{{#if research_documents}}
- Research: {{research_documents}}
{{/if}}
---
## Next Steps
1. **Epic & Story Breakdown** - Run: `workflow epics-stories`
2. **UX Design** (if UI) - Run: `workflow ux-design`
3. **Architecture** - Run: `workflow create-architecture`
---
_This PRD captures the essence of {{project_name}} - {{product_value_summary}}_
_Created through collaborative discovery between {{user_name}} and AI facilitator._

2
src/modules/bmm/workflows/2-plan-workflows/prd/project-types.csv
View File

@ -5,7 +5,7 @@ saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permissio
developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
game,"game,player,gameplay,level,character","REDIRECT TO GAME WORKFLOWS","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
game,"game,player,gameplay,level,character","REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
1 project_type detection_signals key_questions required_sections skip_sections web_search_triggers innovation_signals
5 developer_tool SDK,library,package,npm,pip,framework Language support?;Package managers?;IDE integration?;Documentation?;Examples? language_matrix;installation_methods;api_surface;code_examples;migration_guide visual_design;store_compliance package manager best practices;API design patterns New paradigm;DSL creation
6 cli_tool CLI,command,terminal,bash,script Interactive or scriptable?;Output formats?;Config method?;Shell completion? command_structure;output_formats;config_schema;scripting_support visual_design;ux_principles;touch_interactions CLI design patterns;shell integration Natural language CLI;AI commands
7 web_app website,webapp,browser,SPA,PWA SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility? browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level native_features;cli_commands web standards;WCAG guidelines New interaction;WebAssembly use
8 game game,player,gameplay,level,character REDIRECT TO GAME WORKFLOWS REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT game-brief;GDD most_sections game design patterns Novel mechanics;Genre mixing
9 desktop_app desktop,Windows,Mac,Linux,native Cross-platform?;Auto-update?;System integration?;Offline? platform_support;system_integration;update_strategy;offline_capabilities web_seo;mobile_features desktop guidelines;platform requirements Desktop AI;System automation
10 iot_embedded IoT,embedded,device,sensor,hardware Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates? hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism visual_ui;browser_support IoT standards;protocol specs Edge AI;New sensors
11 blockchain_web3 blockchain,crypto,DeFi,NFT,smart contract Chain selection?;Wallet integration?;Gas optimization?;Security audit? chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization traditional_auth;centralized_db blockchain standards;security patterns Novel tokenomics;DAO structure

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

@ -20,31 +20,33 @@ instructions: "{installed_path}/instructions.md"
# Templates
prd_template: "{installed_path}/prd-template.md"
# Data files for data-driven behavior
project_types_data: "{installed_path}/project-types.csv"
domain_complexity_data: "{installed_path}/domain-complexity.csv"
# Output files
status_file: "{output_folder}/bmm-workflow-status.yaml"
default_output_file: "{output_folder}/PRD.md"
# Recommended input documents
recommended_inputs:
- product_brief: "{output_folder}/product-brief.md"
- market_research: "{output_folder}/market-research.md"
default_output_file: "{output_folder}/prd.md"
# Smart input file references - handles both whole docs and sharded docs
# Priority: Whole document first, then sharded version
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
input_file_patterns:
product_brief:
description: "Product vision and goals (optional)"
whole: "{output_folder}/*brief*.md"
sharded: "{output_folder}/*brief*/index.md"
load_strategy: "FULL_LOAD"
research:
description: "Market or domain research (optional)"
whole: "{output_folder}/*research*.md"
sharded: "{output_folder}/*research*/index.md"
load_strategy: "FULL_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
standalone: true
@ -64,13 +66,13 @@ web_bundle:
- "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/checklist.md"
# Child workflow and its files
- "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
- "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/instructions.md"
- "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/epics-template.md"
- "{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/workflow.yaml"
- "{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/instructions.md"
- "{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/epics-template.md"
# Task dependencies (referenced in instructions.md)
- "{bmad_folder}/core/tasks/workflow.xml"
- "{bmad_folder}/core/tasks/advanced-elicitation.xml"
- "{bmad_folder}/core/tasks/advanced-elicitation-methods.csv"
child_workflows:
- create-epics-and-stories: "{bmad_folder}/bmm/workflows/2-plan-workflows/prd/create-epics-and-stories/workflow.yaml"
- create-epics-and-stories: "{bmad_folder}/bmm/workflows/2-plan-workflows/create-epics-and-stories/workflow.yaml"

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

@ -28,7 +28,7 @@
### Document Discovery
- [ ] **Existing documents loaded**: Product brief, research docs found and incorporated (if they exist)
- [ ] **Document-project output**: Checked for {output_folder}/docs/index.md (brownfield codebase map)
- [ ] **Document-project output**: Checked for {output_folder}/index.md (brownfield codebase map)
- [ ] **Sharded documents**: If sharded versions found, ALL sections loaded and synthesized
- [ ] **Context summary**: loaded_documents_summary lists all sources used

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

@ -1,5 +1,7 @@
# Unified Epic and Story Generation
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>
<critical>This generates epic + stories for ALL quick-flow projects</critical>

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

@ -12,6 +12,8 @@
<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>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<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>
@ -134,7 +136,7 @@ Search for and load (using dual-strategy: whole first, then sharded):
- If found: Load completely and extract insights
3. **Document-Project Output (CRITICAL for brownfield):**
- Always check: {output_folder}/docs/index.md
- Always check: {output_folder}/index.md
- If found: This is the brownfield codebase map - load ALL shards!
- Extract: File structure, key modules, existing patterns, naming conventions

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

@ -41,15 +41,18 @@ sprint_artifacts: "{output_folder}/sprint_artifacts"
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
input_file_patterns:
product_brief:
description: "Product vision and goals (optional)"
whole: "{output_folder}/*brief*.md"
sharded: "{output_folder}/*brief*/index.md"
load_strategy: "FULL_LOAD"
research:
description: "Market or domain research (optional)"
whole: "{output_folder}/*research*.md"
sharded: "{output_folder}/*research*/index.md"
load_strategy: "FULL_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
standalone: true

6
src/modules/bmm/workflows/3-solutioning/architecture/checklist.md
View File

@ -2,7 +2,7 @@
**Purpose**: Validate the architecture document itself is complete, implementable, and provides clear guidance for AI agents.
**Note**: This checklist validates the ARCHITECTURE DOCUMENT only. For cross-workflow validation (PRD → Architecture → Stories alignment), use the solutioning-gate-check workflow.
**Note**: This checklist validates the ARCHITECTURE DOCUMENT only. For cross-workflow validation (PRD → Architecture → Stories alignment), use the implementation-readiness workflow.
---
@ -233,8 +233,8 @@
---
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, UX, Architecture, and Stories before beginning implementation.
**Next Step**: Run the **implementation-readiness** workflow to validate alignment between PRD, UX, Architecture, and Stories before beginning implementation.
---
_This checklist validates architecture document quality only. Use solutioning-gate-check for comprehensive readiness validation._
_This checklist validates architecture document quality only. Use implementation-readiness for comprehensive readiness validation._

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

@ -11,6 +11,8 @@
<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>
<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>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
@ -55,7 +57,7 @@
<action>Set standalone_mode = false</action>
<action>Check for existing PRD and epics files using fuzzy matching</action>
<action>Check for existing PRD file using fuzzy matching</action>
<action>Fuzzy match PRD file: {prd_file}</action>
<check if="PRD_not_found">
@ -82,7 +84,10 @@ Please talk to the PM Agent to run the Create PRD workflow first to define your
<step n="1" goal="Load and understand project context">
<action>Review loaded PRD: {prd_content} (auto-loaded in Step 0.5 - handles both whole and sharded documents)</action>
<action>Review loaded epics: {epics_content}</action>
<check if="{epics_content} is not empty">
<action>Review loaded epics: {epics_content}</action>
</check>
<action>Check for UX specification:
<check if="{ux_design_content} is not empty">
@ -91,15 +96,43 @@ Please talk to the PM Agent to run the Create PRD workflow first to define your
</check>
</action>
<action>Extract and understand from {prd_content}: - Functional Requirements (what it must do) - Non-Functional Requirements (performance, security, compliance, etc.) - Epic structure and user stories - Acceptance criteria - Any technical constraints mentioned
</action>
<action>Extract and understand from {prd_content}:
<action>Count and assess project scale: - Number of epics: {{epic_count}} - Number of stories: {{story_count}} - Complexity indicators (real-time, multi-tenant, regulated, etc.) - UX complexity level (if UX spec exists) - Novel features
</action>
- Functional Requirements (FRs) - the complete list of capabilities
- Non-Functional Requirements (performance, security, compliance, etc.)
- Any technical constraints mentioned
</action>
<check if="{epics_content} is not empty">
<action>Extract from {epics_content}:
- Epic structure and user stories
- Acceptance criteria
</action>
</check>
<action>Count and assess project scale:
<check if="{epics_content} is not empty">
- Number of epics: {{epic_count}}
- Number of stories: {{story_count}}
</check>
<check if="{epics_content} is empty">
- Number of functional requirements: {{fr_count}} (from PRD)
- FR categories: {{fr_category_list}} (capability groups from PRD)
</check>
- Complexity indicators (real-time, multi-tenant, regulated, etc.)
- UX complexity level (if UX spec exists)
- Novel features
</action>
<action>Reflect understanding back to {user_name}:
"I'm reviewing your project documentation for {{project_name}}.
<check if="{epics_content} is not empty">
I see {{epic_count}} epics with {{story_count}} total stories.
</check>
<check if="{epics_content} is empty">
I found {{fr_count}} functional requirements organized into {{fr_category_list}}.
</check>
{{if_ux_spec}}I also found your UX specification which defines the user experience requirements.{{/if_ux_spec}}
Key aspects I notice:
@ -349,7 +382,12 @@ Let's work through the remaining {{remaining_count}} decisions."
Category: {{category}}
Decision: {{user_choice}}
Version: {{verified_version_if_applicable}}
<check if="{epics_content} is not empty">
Affects Epics: {{list_of_affected_epics}}
</check>
<check if="{epics_content} is empty">
Affects FR Categories: {{list_of_affected_fr_categories}}
</check>
Rationale: {{user_reasoning_or_default}}
Provided by Starter: {{yes_if_from_starter}}
</action>
@ -380,9 +418,16 @@ Provided by Starter: {{yes_if_from_starter}}
<action>Create comprehensive source tree: - Root configuration files - Source code organization - Test file locations - Build/dist directories - Documentation structure
</action>
<action>Map epics to architectural boundaries:
"Epic: {{epic_name}} → Lives in {{module/directory/service}}"
</action>
<check if="{epics_content} is not empty">
<action>Map epics to architectural boundaries:
"Epic: {{epic_name}} → Lives in {{module/directory/service}}"
</action>
</check>
<check if="{epics_content} is empty">
<action>Map FR categories to architectural boundaries:
"FR Category: {{fr_category_name}} → Lives in {{module/directory/service}}"
</action>
</check>
<action>Define integration points: - Where do components communicate? - What are the API boundaries? - How do services interact?
</action>
@ -393,15 +438,22 @@ Provided by Starter: {{yes_if_from_starter}}
<step n="7" goal="Design novel architectural patterns" optional="true">
<critical>Some projects require INVENTING new patterns, not just choosing existing ones</critical>
<action>Scan PRD for concepts that don't have standard solutions: - Novel interaction patterns (e.g., "swipe to match" before Tinder existed) - Unique multi-component workflows (e.g., "viral invitation system") - New data relationships (e.g., "social graph" before Facebook) - Unprecedented user experiences (e.g., "ephemeral messages" before Snapchat) - Complex state machines crossing multiple epics
</action>
<action>Scan PRD for concepts that don't have standard solutions: - Novel interaction patterns (e.g., "swipe to match" before Tinder existed) - Unique multi-component workflows (e.g., "viral invitation system") - New data relationships (e.g., "social graph" before Facebook) - Unprecedented user experiences (e.g., "ephemeral messages" before Snapchat)
<check if="{epics_content} is not empty">
- Complex state machines crossing multiple epics
</check>
<check if="{epics_content} is empty">
- Complex state machines crossing multiple FR categories
</check>
</action>
<check if="novel_patterns_detected">
<action>For each novel pattern identified:</action>
<action>Engage user in design collaboration:
<check if="{user_skill_level} == 'expert'">
"The {{pattern_name}} concept requires architectural innovation.
<action>Engage user in design collaboration:
<check if="{user_skill_level} == 'expert'">
"The {{pattern_name}} concept requires architectural innovation.
Core challenge: {{challenge_description}}
@ -415,39 +467,44 @@ Provided by Starter: {{yes_if_from_starter}}
Let me help you think through how this should work:"
</check>
</action>
<action>Facilitate pattern design:
1. Identify core components involved
2. Map data flow between components
3. Design state management approach
4. Create sequence diagrams for complex flows
5. Define API contracts for the pattern
6. Consider edge cases and failure modes
</action>
<action>Facilitate pattern design: 1. Identify core components involved 2. Map data flow between components 3. Design state management approach 4. Create sequence diagrams for complex flows 5. Define API contracts for the pattern 6. Consider edge cases and failure modes
</action>
<action>Use advanced elicitation for innovation:
"What if we approached this differently?
- What would the ideal user experience look like?
- Are there analogies from other domains we could apply?
- What constraints can we challenge?"
</action>
<action>Use advanced elicitation for innovation:
"What if we approached this differently? - What would the ideal user experience look like? - Are there analogies from other domains we could apply? - What constraints can we challenge?"
</action>
<action>Document the novel pattern:
Pattern Name: {{pattern_name}}
Purpose: {{what_problem_it_solves}}
Components:
{{component_list_with_responsibilities}}
Data Flow:
{{sequence_description_or_diagram}}
Implementation Guide:
{{how_agents_should_build_this}}
<action>Document the novel pattern:
Pattern Name: {{pattern_name}}
Purpose: {{what_problem_it_solves}}
Components:
{{component_list_with_responsibilities}}
Data Flow:
{{sequence_description_or_diagram}}
Implementation Guide:
{{how_agents_should_build_this}}
<check if="{epics_content} is not empty">
Affects Epics:
{{epics_that_use_this_pattern}}
</check>
<check if="{epics_content} is empty">
Affects FR Categories:
{{fr_categories_that_use_this_pattern}}
</check>
</action>
<action>Validate pattern completeness:
<check if="{epics_content} is not empty">
"Does this {{pattern_name}} design cover all the use cases in your epics?
</check>
<check if="{epics_content} is empty">
"Does this {{pattern_name}} design cover all the use cases in your requirements?
</check>
- {{use_case_1}}: ✓ Handled by {{component}}
- {{use_case_2}}: ✓ Handled by {{component}}
..."
@ -561,8 +618,14 @@ Enforcement: "All agents MUST follow this pattern"
<action>Check decision compatibility: - Do all decisions work together? - Are there any conflicting choices? - Do the versions align properly?
</action>
<action>Verify epic coverage: - Does every epic have architectural support? - Are all user stories implementable with these decisions? - Are there any gaps?
</action>
<check if="{epics_content} is not empty">
<action>Verify epic coverage: - Does every epic have architectural support? - Are all user stories implementable with these decisions? - Are there any gaps?
</action>
</check>
<check if="{epics_content} is empty">
<action>Verify FR coverage: - Does every functional requirement have architectural support? - Are all capabilities implementable with these decisions? - Are there any gaps?
</action>
</check>
<action>Validate pattern completeness: - Are there any patterns we missed that agents would need? - Do novel patterns integrate with standard architecture? - Are implementation patterns comprehensive enough?
</action>
@ -585,7 +648,11 @@ Enforcement: "All agents MUST follow this pattern"
<action>Load template: {architecture_template}</action>
<action>Generate sections: 1. Executive Summary (2-3 sentences about the architecture approach) 2. Project Initialization (starter command if applicable) 3. Decision Summary Table (with verified versions and epic mapping) 4. Complete Project Structure (full tree, no placeholders) 5. Epic to Architecture Mapping (every epic placed) 6. Technology Stack Details (versions, configurations) 7. Integration Points (how components connect) 8. Novel Pattern Designs (if any were created) 9. Implementation Patterns (all consistency rules) 10. Consistency Rules (naming, organization, formats) 11. Data Architecture (models and relationships) 12. API Contracts (request/response formats) 13. Security Architecture (auth, authorization, data protection) 14. Performance Considerations (from NFRs) 15. Deployment Architecture (where and how) 16. Development Environment (setup and prerequisites) 17. Architecture Decision Records (key decisions with rationale)
<action>Generate sections: 1. Executive Summary (2-3 sentences about the architecture approach) 2. Project Initialization (starter command if applicable) 3. Decision Summary Table (with verified versions and coverage mapping) 4. Complete Project Structure (full tree, no placeholders)
<check if="{epics_content} is not empty"> 5. Epic to Architecture Mapping (every epic placed)
</check>
<check if="{epics_content} is empty"> 5. FR Category to Architecture Mapping (every FR category placed)
</check> 6. Technology Stack Details (versions, configurations) 7. Integration Points (how components connect) 8. Novel Pattern Designs (if any were created) 9. Implementation Patterns (all consistency rules) 10. Consistency Rules (naming, organization, formats) 11. Data Architecture (models and relationships) 12. API Contracts (request/response formats) 13. Security Architecture (auth, authorization, data protection) 14. Performance Considerations (from NFRs) 15. Deployment Architecture (where and how) 16. Development Environment (setup and prerequisites) 17. Architecture Decision Records (key decisions with rationale)
</action>
<action>Fill template with all collected decisions and patterns</action>
@ -616,7 +683,12 @@ Enforcement: "All agents MUST follow this pattern"
<action>Verify MANDATORY items:
- [] Decision table has Version column with specific versions
<check if="{epics_content} is not empty">
- [] Every epic is mapped to architecture components
</check>
<check if="{epics_content} is empty">
- [] Every FR category is mapped to architecture components
</check>
- [] Source tree is complete, not generic
- [] No placeholder text remains
- [] All FRs from PRD have architectural support

4
src/modules/bmm/workflows/3-solutioning/architecture/workflow.yaml
View File

@ -17,18 +17,22 @@ date: system-generated
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
input_file_patterns:
prd:
description: "Product requirements and features"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/index.md"
load_strategy: "FULL_LOAD"
epics:
description: "Epic and story breakdown (optional - uses PRD FRs if not present)"
whole: "{output_folder}/*epic*.md"
sharded: "{output_folder}/*epic*/index.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (optional)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/index.md"
load_strategy: "FULL_LOAD"
document_project:
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"

0
src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/checklist.md → src/modules/bmm/workflows/3-solutioning/implementation-readiness/checklist.md
View File

60
src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/instructions.md → src/modules/bmm/workflows/3-solutioning/implementation-readiness/instructions.md
View File

@ -1,9 +1,11 @@
# Implementation Ready Check - Workflow Instructions
# Implementation Readiness - Workflow Instructions
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml</critical>
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness/workflow.yaml</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>
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
<critical>⚠️ CHECKPOINT PROTOCOL: After EVERY <template-output> tag, you MUST follow workflow.xml substep 2c: SAVE content to file immediately → SHOW checkpoint separator (━━━━━━━━━━━━━━━━━━━━━━━) → DISPLAY generated content → PRESENT options [a]Advanced Elicitation/[c]Continue/[p]Party-Mode/[y]YOLO → WAIT for user response. Never batch saves or skip checkpoints.</critical>
<workflow>
@ -11,7 +13,7 @@
<action>Check if {workflow_status_file} exists</action>
<check if="status file not found">
<output>No workflow status file found. Implementation Ready Check can run standalone or as part of BMM workflow path.</output>
<output>No workflow status file found. Implementation Readiness check can run standalone or as part of BMM workflow path.</output>
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
<check if="continue">
@ -25,14 +27,14 @@
<check if="status file found">
<action>Load the FULL file: {workflow_status_file}</action>
<action>Parse workflow_status section</action>
<action>Check status of "solutioning-gate-check" workflow</action>
<action>Check status of "implementation-readiness" workflow</action>
<action>Get {selected_track} (quick-flow, bmad-method, or enterprise-bmad-method)</action>
<action>Find first non-completed workflow (next expected workflow)</action>
<action>Based on the selected_track, understand what artifacts should exist: - quick-flow: Tech spec and simple stories in an epic only (no PRD, minimal solutioning) - bmad-method and enterprise-bmad-method: PRD, tech spec, epics/stories, architecture, possible UX artifacts</action>
<action>Based on the selected_track, understand what artifacts should exist: - quick-flow: Tech spec and simple stories in an epic only (no PRD, minimal solutioning) - bmad-method and enterprise-bmad-method: PRD, UX design, epics/stories, architecture</action>
<check if="solutioning-gate-check status is file path (already completed)">
<output>⚠️ Gate check already completed: {{solutioning-gate-check status}}</output>
<check if="implementation-readiness status is file path (already completed)">
<output>⚠️ Implementation readiness check already completed: {{implementation-readiness status}}</output>
<ask>Re-running will create a new validation report. Continue? (y/n)</ask>
<check if="n">
<output>Exiting. Use workflow-status to see your next step.</output>
@ -40,9 +42,9 @@
</check>
</check>
<check if="solutioning-gate-check is not the next expected workflow">
<output>⚠️ Next expected workflow: {{next_workflow}}. Gate check is out of sequence.</output>
<ask>Continue with gate check anyway? (y/n)</ask>
<check if="implementation-readiness is not the next expected workflow">
<output>⚠️ Next expected workflow: {{next_workflow}}. Implementation readiness check is out of sequence.</output>
<ask>Continue with readiness check anyway? (y/n)</ask>
<check if="n">
<output>Exiting. Run {{next_workflow}} instead.</output>
<action>Exit workflow</action>
@ -256,25 +258,27 @@
<step n="7" goal="Update status and complete" tag="workflow-status">
<check if="standalone_mode != true">
<action>Load the FULL file: {workflow_status_file}</action>
<action>Find workflow_status key "solutioning-gate-check"</action>
<action>Find workflow_status key "implementation-readiness"</action>
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
<action>Update workflow_status["solutioning-gate-check"] = "{output_folder}/bmm-readiness-assessment-{{date}}.md"</action>
<action>Update workflow_status["implementation-readiness"] = "{output_folder}/implementation-readiness-report-{{date}}.md"</action>
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
<action>Determine next agent from path file based on next workflow</action>
</check>
<output>**✅ Implementation Ready Check Complete!**
<action>Determine overall readiness status from the readiness_assessment (Ready, Ready with Conditions, or Not Ready)</action>
<output>**✅ Implementation Readiness Check Complete!**
**Assessment Report:**
- Readiness assessment saved to: {output_folder}/bmm-readiness-assessment-{{date}}.md
- Readiness assessment saved to: {output_folder}/implementation-readiness-report-{{date}}.md
{{#if standalone_mode != true}}
**Status Updated:**
- Progress tracking updated: solutioning-gate-check marked complete
- Progress tracking updated: implementation-readiness marked complete
- Next workflow: {{next_workflow}}
{{else}}
**Note:** Running in standalone mode (no progress tracking)
@ -296,6 +300,32 @@ Since no workflow is in progress:
{{/if}}
</output>
<check if="overall readiness status is Ready OR Ready with Conditions">
<output>**🚀 Ready for Implementation!**
Your project artifacts are aligned and complete. You can now proceed to Phase 4: Implementation.
</output>
<ask>Would you like to run the **sprint-planning** workflow to initialize your sprint tracking and prepare for development? (yes/no)</ask>
<check if="yes">
<action>Inform user that sprint-planning workflow will be invoked</action>
<invoke-workflow path="{project-root}/{bmad_folder}/bmm/workflows/4-implementation/sprint-planning/workflow.yaml" />
</check>
<check if="no">
<output>You can run sprint-planning later when ready: `sprint-planning`</output>
</check>
</check>
<check if="overall readiness status is Not Ready">
<output>**⚠️ Not Ready for Implementation**
Critical issues must be resolved before proceeding. Review the assessment report and address the identified gaps.
Once issues are resolved, re-run implementation-readiness to validate again.
</output>
</check>
<template-output>status_update_result</template-output>
</step>

2
src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/template.md → src/modules/bmm/workflows/3-solutioning/implementation-readiness/template.md
View File

@ -143,4 +143,4 @@ _Minor items for consideration_
---
_This readiness assessment was generated using the BMad Method Implementation Ready Check workflow (v6-alpha)_
_This readiness assessment was generated using the BMad Method Implementation Readiness workflow (v6-alpha)_

26
src/modules/bmm/workflows/3-solutioning/solutioning-gate-check/workflow.yaml → src/modules/bmm/workflows/3-solutioning/implementation-readiness/workflow.yaml
View File

@ -1,7 +1,7 @@
# Implementation Ready Check - Workflow Configuration
name: solutioning-gate-check
description: "Systematically validate that all planning and solutioning phases are complete and properly aligned before transitioning to Phase 4 implementation. Ensures PRD, architecture, and stories are cohesive with no gaps or contradictions."
author: "BMad Builder"
# Implementation Readiness - Workflow Configuration
name: implementation-readiness
description: "Validate that PRD, UX Design, Architecture, Epics and Stories are complete and aligned before Phase 4 implementation. Ensures all artifacts cover the MVP requirements with no gaps or contradictions."
author: "BMad"
# Critical variables from config
config_source: "{project-root}/{bmad_folder}/bmm/config.yaml"
@ -17,7 +17,7 @@ workflow_paths_dir: "{project-root}/{bmad_folder}/bmm/workflows/workflow-status/
workflow_status_file: "{output_folder}/bmm-workflow-status.yaml"
# Module path and component files
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/solutioning-gate-check"
installed_path: "{project-root}/{bmad_folder}/bmm/workflows/3-solutioning/implementation-readiness"
template: "{installed_path}/template.md"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
@ -25,40 +25,38 @@ validation: "{installed_path}/checklist.md"
# Output configuration
default_output_file: "{output_folder}/implementation-readiness-report-{{date}}.md"
# Input requirements
recommended_inputs:
- 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
# Strategy: How to load sharded documents (FULL_LOAD, SELECTIVE_LOAD, INDEX_GUIDED)
input_file_patterns:
prd:
description: "Product Requirements with FRs and NFRs"
whole: "{output_folder}/*prd*.md"
sharded: "{output_folder}/*prd*/index.md"
load_strategy: "FULL_LOAD"
epics:
description: "Epic breakdown with user stories"
whole: "{output_folder}/*epic*.md"
sharded: "{output_folder}/*epic*/index.md"
load_strategy: "FULL_LOAD"
architecture:
description: "System architecture with decisions and patterns"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/index.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI components)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/index.md"
load_strategy: "FULL_LOAD"
tech_spec:
description: "Technical specification (for Quick Flow track)"
whole: "{output_folder}/*tech-spec*.md"
sharded: "{output_folder}/*tech-spec*/index.md"
load_strategy: "FULL_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
standalone: true

6
src/modules/bmm/workflows/4-implementation/code-review/workflow.yaml
View File

@ -37,20 +37,24 @@ variables:
# Strategy: SELECTIVE LOAD - only load the specific epic needed for this story review
input_file_patterns:
architecture:
description: "System architecture for review context"
whole: "{output_folder}/*architecture*.md"
sharded: "{output_folder}/*architecture*/*.md"
load_strategy: "FULL_LOAD"
ux_design:
description: "UX design specification (if UI review)"
whole: "{output_folder}/*ux*.md"
sharded: "{output_folder}/*ux*/*.md"
load_strategy: "FULL_LOAD"
epics:
description: "Epic containing story being reviewed"
whole: "{output_folder}/*epic*.md"
sharded_index: "{output_folder}/*epic*/index.md"
sharded_single: "{output_folder}/*epic*/epic-{{epic_num}}.md"
load_strategy: "SELECTIVE_LOAD"
document_project:
sharded: "{output_folder}/docs/index.md"
description: "Brownfield project documentation (optional)"
sharded: "{output_folder}/index.md"
load_strategy: "INDEX_GUIDED"
standalone: true

Some files were not shown because too many files have changed in this diff Show More