External/BMAD-METHOD
1
0
Fork 0
mirror of https://github.com/bmadcode/BMAD-METHOD.git synced 2025-12-29 16:14:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs updates

Browse Source
This commit is contained in:
Brian Madison
2025-10-30 11:26:15 -05:00
parent ec111972a0
commit 663b76a072
13 changed files with 1492 additions and 1483 deletions
Download Patch File Download Diff File Expand all files Collapse all files

173
src/modules/bmm/README.md
View File

@@ -1,141 +1,144 @@
# BMM - BMad Method Module
The BMM (BMad Method Module) is the core orchestration system for the BMad Method, providing comprehensive software development lifecycle management through specialized agents, workflows, teams, and tasks.
Core orchestration system for AI-driven agile development, providing comprehensive lifecycle management through specialized agents and workflows.
## 📚 Essential Reading
## Table of Contents
**Before using BMM, you MUST read the [BMM v6 Workflows Guide](./workflows/README.md).** This document explains the revolutionary v6a workflow system and how all components work together.
- [Essential Reading](#essential-reading)
- [Module Structure](#module-structure)
- [Quick Start](#quick-start)
- [Key Concepts](#key-concepts)
- [Scale Levels](#scale-levels)
- [Story Lifecycle](#story-lifecycle)
- [Best Practices](#best-practices)
## Essential Reading
**[📖 BMM v6 Workflows Guide](./workflows/README.md)** - Required reading before using BMM. Explains the revolutionary workflow system and component integration.
## Module Structure
### 🤖 `/agents`
### 🤖 Agents
Specialized AI agents for different development roles:
**Core Development Roles:**
- **PM** (Product Manager) - Product planning and requirements
- **PM** - Product Manager for planning and requirements
- **Analyst** - Business analysis and research
- **Architect** - Technical architecture and design
- **SM** (Scrum Master) - Sprint and story management
- **DEV** (Developer) - Code implementation
- **TEA** (Test Architect) - Test Architect
- **SM** - Scrum Master for sprint and story management
- **DEV** - Developer for implementation
- **TEA** - Test Architect for quality assurance
- **UX** - User experience design
- And more specialized roles
**Game Development Agents** (Optional):
During installation, you can optionally include game development specialists:
**Game Development** (Optional):
- **Game Designer** - Creative vision and game design documents (GDD)
- **Game Designer** - Creative vision and GDD creation
- **Game Developer** - Game-specific implementation
- **Game Architect** - Game systems and technical infrastructure
- **Game Architect** - Game systems and infrastructure
These agents come with specialized workflows (`brainstorm-game`, `game-brief`, `gdd`) and are only installed if you select "Include Game Planning Agents and Workflows" during BMM installation.
### 📋 Workflows
### 📋 `/workflows`
Four-phase methodology adapting to project complexity:
The heart of BMM - structured workflows for the four development phases:
**1. Analysis** (Optional)
1. **Analysis Phase** (Optional)
- `brainstorm-project` - Project ideation
- `research` - Market/technical research
- `product-brief` - Product strategy
- `brainstorm-project` - Project ideation
- `research` - Market/technical research
- `product-brief` - Product strategy
2. **Planning Phase** (Required)
- `prd` - Scale-adaptive project planning
- Routes to appropriate documentation based on project complexity
**2. Planning** (Required)
3. **Solutioning Phase** (Level 3-4 projects)
- `3-solutioning` - Architecture design
- `tech-spec` - Epic-specific technical specifications
- `prd` - Scale-adaptive planning
- Routes to appropriate documentation level
4. **Implementation Phase** (Iterative)
- `create-story` - Story drafting (SM agent)
- `story-ready` - Approve story for development (SM agent)
- `story-context` - Expertise injection (SM agent)
- `dev-story` - Implementation (DEV agent)
- `story-done` - Mark story done (DEV agent)
- `code-review` - Quality validation (DEV/SR agent)
- `correct-course` - Issue resolution
- `retrospective` - Continuous improvement
**3. Solutioning** (Level 3-4)
### 👥 `/teams`
- `architecture` - System design
- `tech-spec` - Epic technical specifications
Pre-configured agent teams for different project types and phases. Teams coordinate multiple agents working together on complex tasks.
**4. Implementation** (Iterative)
### 📝 `/tasks`
- `create-story` - Draft stories
- `story-context` - Inject expertise
- `dev-story` - Implement
- `code-review` - Validate quality
Reusable task definitions that agents execute within workflows. These are the atomic units of work that compose into larger workflows.
### 👥 Teams
### 🔧 `/sub-modules`
Pre-configured agent groups for coordinated complex tasks.
Extension modules that add specialized capabilities to BMM.
### 📝 Tasks
### 🏗️ `/testarch`
Atomic work units composing into larger workflows.
Test architecture and quality assurance components. The **[Test Architect (TEA) Guide](./testarch/README.md)** provides comprehensive testing strategy across 9 workflows: framework setup, CI/CD, test design, ATDD, automation, traceability, NFR assessment, quality gates, and test review.
### 🏗️ Test Architecture
**[TEA Guide](./testarch/README.md)** - Comprehensive testing strategy across 9 specialized workflows.
## Quick Start
```bash
# Load the PM agent - either via slash command or drag and drop or @ the agent file.
# Once loaded, the agent should greet you and offer a menu of options. You can enter:
`*prd`
```
1. **Load PM agent** in your IDE
2. **Wait for menu** to appear
3. **Run workflow:**
```
*prd
```
**IDE Instructions:**
- [Claude Code](../../docs/ide-info/claude-code.md)
- [Cursor](../../docs/ide-info/cursor.md)
- [VS Code](../../docs/ide-info/windsurf.md)
- [Others](../../docs/ide-info/)
## Key Concepts
### Scale Levels
BMM automatically adapts to project complexity:
BMM automatically adapts complexity:
- **Level 0**: Single atomic change
- **Level 1**: 1-10 stories, minimal documentation
- **Level 2**: 5-15 stories, focused PRD
- **Level 3**: 12-40 stories, full architecture
- **Level 4**: 40+ stories, enterprise scale
| Level | Stories | Documentation |
| ----- | ------------- | ----------------- |
| 0 | Single change | Minimal |
| 1 | 1-10 | Light PRD |
| 2 | 5-15 | Focused PRD |
| 3 | 12-40 | Full architecture |
| 4 | 40+ | Enterprise scale |
### Just-In-Time Design
### Story Lifecycle
Technical specifications are created one epic at a time during implementation, not all upfront, allowing for learning and adaptation.
### Story State Machine
Stories flow through a 4-state lifecycle tracked in the status file:
Four-state machine tracked in status file:
```
BACKLOG → TODO → IN PROGRESS → DONE
```
- **BACKLOG**: Ordered list of stories to be drafted (populated at phase transition)
- **TODO**: Single story ready for SM to draft (or drafted, awaiting approval)
- **IN PROGRESS**: Single story approved for DEV to implement
- **DONE**: Completed stories with dates and points
- **BACKLOG** - Ordered stories to draft
- **TODO** - Ready for SM drafting
- **IN PROGRESS** - Approved for DEV
- **DONE** - Completed with metrics
Agents never search for "next story" - they always read the exact story from the status file. Simple workflows (`story-ready`, `story-done`) advance the queue automatically.
### Just-In-Time Design
Technical specifications created per epic during implementation, enabling learning and adaptation.
### Context Injection
Story-specific technical guidance is generated dynamically, providing developers with exactly the expertise needed for each task.
## Integration with BMad Core
BMM integrates seamlessly with the BMad Core framework, leveraging:
- The agent execution engine
- Workflow orchestration
- Task management
- Team coordination
## Related Documentation
- [BMM Workflows Guide](./workflows/README.md) - **Start here!**
- [Test Architect (TEA) Guide](./testarch/README.md) - Quality assurance and testing strategy
Dynamic technical guidance generated for each story, providing exact expertise when needed.
## Best Practices
1. **Always start with the workflows** - Let workflows guide your process
2. **Respect the scale** - Don't over-document small projects
3. **Trust the process** - The methodology has been carefully designed
1. **Start with workflows** - Let process guide you
2. **Respect scale** - Don't over-document small projects
3. **Trust the process** - Methodology carefully designed
4. **Use status file** - Single source of truth for stories
## Related Documentation
- **[Workflows Guide](./workflows/README.md)** - Complete workflow reference
- **[Test Architect Guide](./testarch/README.md)** - Testing strategy
- **[IDE Setup](../../docs/ide-info/)** - Environment configuration
---
For detailed information about the complete BMad Method workflow system, see the [BMM Workflows README](./workflows/README.md).
For complete BMad Method workflow system details, see the [BMM Workflows README](./workflows/README.md).

116
src/modules/bmm/workflows/1-analysis/brainstorm-project/README.md
View File

@@ -1,29 +1,113 @@
---
last-redoc-date: 2025-10-01
---
# Project Brainstorming Workflow
This workflow facilitates structured ideation for non-game software projects through systematic exploration of problem spaces, architectures, and implementation strategies. Unlike traditional requirement gathering, it employs creative techniques to uncover non-obvious approaches and identify innovative solutions that address core business needs while considering technical constraints and organizational capabilities.
Structured ideation for software projects exploring problem spaces, architectures, and innovative solutions beyond traditional requirements gathering.
The workflow operates through a project-specific context framework that captures business objectives, technical environment, stakeholder needs, and organizational constraints. It generates multiple solution vectors through parallel ideation tracks: architectural approaches, user experience paradigms, integration patterns, and value delivery mechanisms. Each track produces concrete proposals that are evaluated against feasibility, impact, and alignment with strategic objectives.
## Table of Contents
Critical differentiators include its focus on solution innovation rather than requirement enumeration, emphasis on technical-business alignment from inception, and structured approach to surfacing hidden assumptions. The workflow produces actionable outputs that directly feed into Product Brief development, ensuring that creative exploration translates into concrete planning artifacts.
- [Purpose](#purpose)
- [Usage](#usage)
- [Process](#process)
- [Inputs & Outputs](#inputs--outputs)
- [Integration](#integration)
## Purpose
Generate multiple solution approaches for software projects through:
- Parallel ideation tracks (architecture, UX, integration, value delivery)
- Technical-business alignment from inception
- Hidden assumption discovery
- Innovation beyond obvious solutions
## Usage
```bash
bmad bmm 1-analysis brainstorm-project
# Run brainstorming session
bmad bmm *brainstorm-project
# Or via Analyst agent
*brainstorm-project
```
## Inputs
## Process
- **Project Context Document**: Business objectives, technical environment, stakeholder landscape, organizational constraints, success criteria, and known pain points
- **Problem Statement** (optional): Core business challenge or opportunity driving the project
### 1. Context Capture
## Outputs
- Business objectives and constraints
- Technical environment
- Stakeholder needs
- Success criteria
- **Architecture Proposals**: Multiple technical approaches with trade-off analysis and feasibility assessments
- **Value Delivery Framework**: Prioritized feature concepts aligned with business objectives and user needs
- **Risk and Opportunity Analysis**: Identified technical dependencies, integration challenges, and innovation opportunities
- **Strategic Recommendation**: Synthesized direction with rationale and implementation considerations
### 2. Parallel Ideation
- **Architecture Track**: Technical approaches with trade-offs
- **UX Track**: Interface paradigms and user journeys
- **Integration Track**: System connection patterns
- **Value Track**: Feature prioritization and delivery
### 3. Solution Synthesis
- Evaluate feasibility and impact
- Align with strategic objectives
- Surface hidden assumptions
- Generate recommendations
## Inputs & Outputs
### Inputs
| Input | Type | Purpose |
| ----------------- | -------- | --------------------------------------------- |
| Project Context | Document | Business objectives, environment, constraints |
| Problem Statement | Optional | Core challenge or opportunity |
### Outputs
| Output | Content |
| ------------------------ | ------------------------------------------- |
| Architecture Proposals | Multiple approaches with trade-off analysis |
| Value Framework | Prioritized features aligned to objectives |
| Risk Analysis | Dependencies, challenges, opportunities |
| Strategic Recommendation | Synthesized direction with rationale |
## Integration
### Workflow Chain
1. **brainstorm-project** ← Current step
2. research (optional deep dive)
3. product-brief (strategic document)
4. Phase 2 planning (PRD/tech-spec)
### Feed Into
- Product Brief development
- Architecture decisions
- PRD requirements
- Epic prioritization
## Best Practices
1. **Prepare context** - Gather business and technical background
2. **Think broadly** - Explore non-obvious approaches
3. **Document assumptions** - Capture implicit beliefs
4. **Consider constraints** - Technical, organizational, resource
5. **Focus on value** - Align to business objectives
## Configuration
```yaml
# bmad/bmm/config.yaml
output_folder: ./output
project_name: Your Project
```
## Related Workflows
- [Research](../research/README.md) - Deep investigation
- [Product Brief](../product-brief/README.md) - Strategic planning
- [PRD](../../2-plan-workflows/prd/README.md) - Requirements document
---
Part of BMad Method v6 - Phase 1 Analysis workflows

197
src/modules/bmm/workflows/4-implementation/create-story/README.md
View File

@@ -1,129 +1,146 @@
---
last-redoc-date: 2025-10-01
---
# Create Story Workflow
The create-story workflow is the entry point for v6's just-in-time story generation approach, run exclusively by the Scrum Master (SM) agent. Unlike batch processing methodologies, this workflow generates exactly ONE story at a time based on the current epic backlog state, ensuring stories are created only when needed and with the most current context. The SM analyzes the epic's progress, identifies what needs to be built next based on epics.md enumeration, and generates a complete story specification including acceptance criteria, technical approach, and implementation guidance pulled directly from tech specs, PRD, and architecture documentation.
Just-in-time story generation creating one story at a time based on epic backlog state. Run by Scrum Master (SM) agent to ensure planned stories align with approved epics.
This workflow represents a fundamental shift from traditional upfront planning to adaptive story generation. By creating stories one at a time and enforcing strict verification against epics.md, the SM ensures that only planned and approved stories are created. The workflow operates in non-interactive "#yolo" mode by default, minimizing prompts while maintaining quality through rigorous source document grounding. It will HALT if epics.md doesn't explicitly enumerate the next story, forcing proper planning through the correct-course workflow rather than allowing ad-hoc story creation.
## Table of Contents
The workflow's intelligent document discovery system automatically finds the relevant tech spec for the current epic (using pattern `tech-spec-epic-{epic_num}-*.md`), loads all architecture documents from both docs/ and output folders, and synthesizes requirements from multiple sources in priority order. After story creation, it can optionally trigger the story-context workflow to generate just-in-time technical expertise for the developer.
- [Usage](#usage)
- [Key Features](#key-features)
- [Inputs & Outputs](#inputs--outputs)
- [Workflow Behavior](#workflow-behavior)
- [Integration](#integration)
## Usage
```bash
# SM initiates story creation for the next piece of work
# SM initiates next story creation
bmad sm *create-story
```
The SM runs this workflow when:
**When to run:**
- The current sprint has capacity for new work
- The previous story status is "Done" or "Approved"
- The team is ready for the next planned story in the epic
- Story preparation is needed before development
## Inputs
**Required Context Files:**
- **epics.md**: MANDATORY - Must explicitly enumerate the next story or workflow halts
- **tech-spec-epic-{N}-\*.md**: Epic-specific technical specification (auto-discovered)
- **PRD.md**: Product requirements document (fallback for requirements)
- **Architecture Documents**: Automatically discovered from docs/ and output folders:
- tech-stack.md, unified-project-structure.md, coding-standards.md
- testing-strategy.md, backend-architecture.md, frontend-architecture.md
- data-models.md, database-schema.md, rest-api-spec.md, external-apis.md
**Workflow Variables:**
- `story_dir`: From config `dev_story_location` - where stories are saved
- `epic_num`: Current epic number (auto-detected from existing stories)
- `story_num`: Next story number (incremented from last completed story)
- `auto_run_context`: Default true - runs story-context workflow after creation
- `non_interactive`: Default true - operates in "#yolo" mode with minimal prompts
## Outputs
**Primary Deliverable:**
- **Story Document** (`{story_dir}/story-{epic_num}.{story_num}.md`): Complete story specification including:
- User story statement (role, action, benefit)
- Acceptance criteria extracted from tech spec or epics.md
- Tasks and subtasks mapped to ACs
- Testing requirements per testing strategy
- Dev notes with source citations
- Status: "Draft" (requires approval before development)
**Validation Safeguards:**
- **Epic Enumeration Check**: If epics.md doesn't list the next story, workflow HALTS with:
```
"No planned next story found in epics.md for epic {epic_num}.
Please load either PM or SM agent and run *correct-course to add/modify epic stories."
```
- **Status Check**: Won't create new story if current story isn't Done/Approved
- **Document Grounding**: All requirements traced to source documents (no invention)
- Sprint has capacity for new work
- Previous story is Done/Approved
- Team ready for next planned story
## Key Features
**Strict Planning Enforcement**: The workflow will NOT create stories that aren't explicitly planned in epics.md. This prevents scope creep and ensures all work is properly approved through the planning process.
### Strict Planning Enforcement
**Intelligent Document Discovery**: Automatically finds the latest tech spec for the epic using glob patterns, discovers all architecture documents across multiple directories, and builds a prioritized document set for requirement extraction.
- **Only creates stories enumerated in epics.md**
- Halts if story not found in epic plan
- Prevents scope creep through validation
**Source Document Grounding**: Every requirement, acceptance criterion, and technical constraint is traced to a specific source document. The workflow explicitly forbids inventing domain facts not present in source materials.
### Intelligent Document Discovery
**Non-Interactive by Default**: Operates in "#yolo" mode to minimize interruptions, only prompting when absolutely necessary (like missing critical configuration). This enables smooth automated story preparation.
- Auto-finds tech spec: `tech-spec-epic-{N}-*.md`
- Discovers architecture docs across directories
- Builds prioritized requirement sources
**Automatic Context Generation**: When `auto_run_context` is true (default), automatically triggers the story-context workflow to generate developer expertise injection for the newly created story.
### Source Document Grounding
## Integration with v6 Flow
- Every requirement traced to source
- No invention of domain facts
- Citations included in output
The create-story workflow is step 1 in the v6 implementation cycle:
### Non-Interactive Mode
1. **SM: create-story** ← You are here
2. SM: story-context (adds JIT technical expertise)
3. DEV: dev-story (implements with generated context)
4. DEV/SR: code-review (validates completion)
5. If needed: correct-course (adjusts direction)
6. After epic: retrospective (captures learnings)
- Default "#yolo" mode minimizes prompts
- Smooth automated story preparation
- Only prompts when critical
This workflow establishes the "what" that needs to be built, strictly based on planned epics. The story-context workflow will later add the "how" through just-in-time technical expertise injection.
## Inputs & Outputs
## Document Priority Order
### Required Files
The workflow uses this priority for extracting requirements:
| File | Purpose | Priority |
| ------------------------ | ----------------------------- | -------- |
| epics.md | Story enumeration (MANDATORY) | Critical |
| tech-spec-epic-{N}-\*.md | Epic technical spec | High |
| PRD.md | Product requirements | Medium |
| Architecture docs | Technical constraints | Low |
1. **tech_spec_file**: Epic-scoped technical specification (highest priority)
2. **epics_file**: Acceptance criteria and story breakdown
3. **prd_file**: Business requirements and constraints
4. **Architecture docs**: Constraints, patterns, and technical guidance
### Auto-Discovered Docs
- `tech-stack.md`, `unified-project-structure.md`
- `testing-strategy.md`, `backend/frontend-architecture.md`
- `data-models.md`, `database-schema.md`, `api-specs.md`
### Output
**Story Document:** `{story_dir}/story-{epic}.{story}.md`
- User story statement (role, action, benefit)
- Acceptance criteria from tech spec/epics
- Tasks mapped to ACs
- Testing requirements
- Dev notes with sources
- Status: "Draft"
## Workflow Behavior
**Story Number Management:**
### Story Number Management
- Automatically detects next story number from existing files
- Won't skip numbers or create duplicates
- Maintains epic.story numbering convention
- Auto-detects next story number
- No duplicates or skipped numbers
- Maintains epic.story convention
**Update vs Create:**
### Update vs Create
- If latest story status != Done/Approved: Updates existing story
- If latest story status == Done/Approved: Creates next story (if enumerated in epics.md)
- **If current story not Done:** Updates existing
- **If current story Done:** Creates next (if planned)
**Epic Advancement:**
### Validation Safeguards
- In non-interactive mode: Stays within current epic
- Interactive mode: Can prompt for new epic number
**No Story Found:**
```
"No planned next story found in epics.md for epic {N}.
Run *correct-course to add/modify epic stories."
```
**Missing Config:**
Ensure `dev_story_location` set in config.yaml
## Integration
### v6 Implementation Cycle
1. **create-story** ← Current step (defines "what")
2. story-context (adds technical "how")
3. dev-story (implementation)
4. code-review (validation)
5. correct-course (if needed)
6. retrospective (after epic)
### Document Priority
1. **tech_spec_file** - Epic-specific spec
2. **epics_file** - Story breakdown
3. **prd_file** - Business requirements
4. **architecture_docs** - Technical guidance
## Configuration
```yaml
# bmad/bmm/config.yaml
dev_story_location: ./stories
output_folder: ./output
# workflow.yaml defaults
non_interactive: true
auto_run_context: true
```
## Troubleshooting
**"No planned next story found in epics.md"**: The next story isn't enumerated in epics.md. Run SM or PM agent's `*correct-course` to properly plan and add the story to the epic.
| Issue | Solution |
| ----------------------- | ------------------------------------------ |
| "No planned next story" | Run `*correct-course` to add story to epic |
| Missing story_dir | Set `dev_story_location` in config |
| Tech spec not found | Use naming: `tech-spec-epic-{N}-*.md` |
| No architecture docs | Add docs to docs/ or output/ folder |
**Missing story_dir Configuration**: Ensure `dev_story_location` is set in bmad/bmm/config.yaml
---
**Tech Spec Not Found**: The workflow looks for `tech-spec-epic-{N}-*.md` pattern. Ensure tech specs follow this naming convention.
**Architecture Documents Missing**: While not fatal, missing architecture docs reduce story context quality. Ensure key docs exist in docs/ or output folder.
For workflow details, see [instructions.md](./instructions.md) and [checklist.md](./checklist.md).

704
src/modules/bmm/workflows/README.md
View File

@@ -1,577 +1,215 @@
---
last-redoc-date: 2025-10-12
---
# BMM Workflows - Complete v6 Guide
# BMM Workflows - The Complete v6 Flow
Master guide for BMM's four-phase methodology that adapts to project scale (Level 0-4) and context (greenfield/brownfield).
The BMM (BMAD Method Module) orchestrates software development through four distinct phases, each with specialized workflows that adapt to project scale (Level 0-4) and context (greenfield vs brownfield). This document serves as the master guide for understanding how these workflows interconnect to deliver the revolutionary v6 methodology.
## Table of Contents
## Core v6 Innovations
- [Core Innovations](#core-innovations)
- [Universal Entry Point](#universal-entry-point)
- [Four Phases Overview](#four-phases-overview)
- [Phase Details](#phase-details)
- [Documentation Prerequisite](#documentation-prerequisite)
- [Phase 1: Analysis](#phase-1-analysis)
- [Phase 2: Planning](#phase-2-planning)
- [Phase 3: Solutioning](#phase-3-solutioning)
- [Phase 4: Implementation](#phase-4-implementation)
- [Scale Levels](#scale-levels)
- [Greenfield vs Brownfield](#greenfield-vs-brownfield)
- [Critical Rules](#critical-rules)
**Scale-Adaptive Planning**: Projects automatically route through different workflows based on complexity (Level 0-4), ensuring appropriate documentation and process overhead.
## Core Innovations
**Just-In-Time Design**: Technical specifications are created one epic at a time during implementation, not all upfront, incorporating learnings as the project evolves.
- **Scale-Adaptive Planning** - Automatic routing based on complexity (Level 0-4)
- **Just-In-Time Design** - Tech specs created per epic during implementation
- **Dynamic Expertise Injection** - Story-specific technical guidance
- **Continuous Learning Loop** - Retrospectives improve each cycle
**Dynamic Expertise Injection**: Story-context workflows provide targeted technical guidance per story, replacing static documentation with contextual expertise.
## Universal Entry Point
**Continuous Learning Loop**: Retrospectives feed improvements back into workflows, making each epic smoother than the last.
**Always start with `workflow-status` or `workflow-init`**
## The Four Phases (Plus Documentation Prerequisite)
### workflow-status
- Checks for existing workflow status file
- Displays current phase and progress
- Routes to appropriate next workflow
- Shows Phase 4 implementation state
### workflow-init
- Creates initial bmm-workflow-status.md
- Detects greenfield vs brownfield
- Routes undocumented brownfield to document-project
- Sets up workflow tracking
## Four Phases Overview
```
┌──────────────────────────────────────────────────────────────┐
│ PREREQUISITE: PROJECT DOCUMENTATION (Conditional) │
│ For brownfield projects without adequate docs │
│ OR post-completion cleanup │
├──────────────────────────────────────────────────────────────┤
│ document-project ──→ Comprehensive project documentation │
└────────────────────────────────────────────────────────┼─────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ PHASE 1: ANALYSIS │
│ (Optional) │
├──────────────────────────────────────────────────────────────┤
│ brainstorm-game ──┐ │
│ brainstorm-project ├──→ research ──→ product-brief ──┐ │
│ or game-brief │ │
└────────────────────────────────────────────────────────┼─────┘
↓
┌──────────────────────────────────────────────────────────────┐
│ PHASE 2: PLANNING │
│ (Scale-Adaptive Router - by type) │
├──────────────────────────────────────────────────────────────┤
│ SOFTWARE: prd/tech-spec GAMES: gdd/narrative │
│ ├──→ Level 0: tech-spec only ├──→ GDD (all levels) │
│ ├──→ Level 1: tech-spec only └──→ Narrative (opt) │
│ ├──→ Level 2: PRD + Epics ──────────────────────────┐ │
│ └──→ Level 3-4: PRD + Epics ────────────────────────┼┐ │
│ UX: create-ux-design (conditional) ││ │
└──────────────────────────────────────────────────────────┼┼──┘
↓↓
┌──────────────────────────────────────────────────────────────┐
│ PHASE 3: SOLUTIONING │
│ (Software Levels 2-4 / Complex Games) │
├──────────────────────────────────────────────────────────────┤
│ create-architecture ──→ architecture.md │
│ validate-architecture (optional) │
│ solutioning-gate-check (recommended/required) │
└────────────────────────────────────────────────────────────┬─┘
↓
┌──────────────────────────────────────────────────────────────┐
│ PHASE 4: IMPLEMENTATION │
│ (Sprint-Based Cycle) │
├──────────────────────────────────────────────────────────────┤
│ sprint-planning ──→ sprint-status.yaml │
│ ↓ │
│ ┌─→ epic-tech-context (per epic) │
│ │ ↓ │
│ │ create-story ──→ story-context ──→ dev-story ─┐ │
│ │ ↓ │
│ │ retrospective ←── [epic done] ←─── code-review │
│ │ ↓ │
│ └──────────── correct-course ←──[if issues]───────┘ │
└──────────────────────────────────────────────────────────────┘
PREREQUISITE: document-project (brownfield without docs)
↓
PHASE 1: Analysis (optional)
brainstorm → research → brief
↓
PHASE 2: Planning (required, scale-adaptive)
Level 0-1: tech-spec only
Level 2-4: PRD + epics
↓
PHASE 3: Solutioning (Level 2-4 only)
architecture → validation → gate-check
↓
PHASE 4: Implementation (iterative)
sprint-planning → epic-context → story cycle
```
## Universal Entry Point: workflow-status
## Phase Details
**Before starting any workflow, check your status!**
### Documentation Prerequisite
The `workflow-status` workflow is the **universal entry point** for all BMM workflows, if you have not already set up your workflow, run `workflow-init`, but even if you just run the workflow-status and the file does not exist you should still be directed to run workflow-init.
**When:** Brownfield projects without documentation OR post-completion cleanup
**What it does:**
| Workflow | Purpose | Output |
| ---------------- | ----------------------------- | ------------------ |
| document-project | Analyze and document codebase | Comprehensive docs |
- ✅ Checks for existing workflow status file
- ✅ Displays current phase, progress, and next action
- ✅ Helps new users plan their workflow approach
- ✅ Guides brownfield projects to documentation first
- ✅ Routes to appropriate workflows based on context
**Use Cases:**
**No status file?** It will:
1. **Pre-Phase 1**: Understand existing brownfield code
2. **Post-Phase 4**: Create clean documentation replacing scattered artifacts
1. Ask about project context (greenfield vs brownfield)
2. Generate your bmm-workflow-status.md file.
### Phase 1: Analysis
**Status file exists?** It will:
**Optional workflows for discovery and requirements gathering**
1. Display current phase and progress
2. Show Phase 4 implementation state (BACKLOG/TODO/IN PROGRESS/DONE)
3. Recommend exact next action
4. Offer to change workflow or display menu
| Workflow | Agent | Purpose | Output |
| ------------------ | ------------- | --------------------- | ---------------------- |
| brainstorm-project | Analyst | Software ideation | Architecture proposals |
| brainstorm-game | Game Designer | Game concept ideation | Concept proposals |
| research | Analyst | Multi-mode research | Research artifacts |
| product-brief | Analyst | Strategic planning | Product brief |
| game-brief | Game Designer | Game foundation | Game brief |
**All phase 1-3 workflows should check workflow-status on start of the workflow.**
### Phase 2: Planning
---
**Required phase with scale-adaptive routing**
## Documentation Prerequisite (Brownfield Projects)
| Workflow | Agent | Output | Levels |
| ---------------- | ------------- | -------------- | ----------- |
| prd | PM | PRD.md + epics | 2-4 |
| tech-spec | PM | tech-spec.md | 0-1 |
| gdd | Game Designer | GDD.md | Games |
| create-ux-design | UX | ux-design.md | Conditional |
**NOT a numbered phase** - this is a prerequisite workflow for brownfield projects without adequate documentation, OR a post-completion tool for creating clean source-of-truth documentation after Phases 1-4 are complete.
### Phase 3: Solutioning
### Purpose
**Architecture phase for Level 2-4 projects**
The `document-project` workflow serves TWO critical purposes:
| Workflow | Agent | Purpose | Output |
| ---------------------- | --------- | ----------------- | ---------------------- |
| create-architecture | Architect | System design | architecture.md + ADRs |
| validate-architecture | Architect | Design validation | Validation report |
| solutioning-gate-check | Architect | PRD/UX/arch check | Gate report |
1. **Pre-Phase 1 Prerequisite (Brownfield)**: Run BEFORE planning to understand existing codebases
2. **Post-Phase 4 Documentation (Any Project)**: Run AFTER completion to create superior documentation that replaces scattered PRD/architecture/story artifacts
### Phase 4: Implementation
### Workflows
**Sprint-based development cycle**
| Workflow | Agent | Purpose | Output | When to Use |
| -------------------- | ------- | ----------------------------------- | ----------------------------------- | -------------------------------------------------------------- |
| **document-project** | Analyst | Analyze and document entire project | Comprehensive project documentation | Brownfield without docs OR post-completion cleanup (any scale) |
#### Sprint Status System
### Use Cases
**Epic Flow:** `backlog → contexted`
**Use Case 1: Brownfield Prerequisite**
**Story Flow:** `backlog → drafted → ready-for-dev → in-progress → review → done`
#### Implementation Workflows
| Workflow | Agent | Purpose | Status Updates |
| ----------------- | ----- | ----------------------- | ------------------------------------------- |
| sprint-planning | SM | Initialize tracking | Creates sprint-status.yaml |
| epic-tech-context | SM | Epic technical context | Epic: backlog → contexted |
| create-story | SM | Draft story files | Story: backlog → drafted |
| story-context | SM | Implementation guidance | Story: drafted → ready-for-dev |
| dev-story | DEV | Implement | Story: ready-for-dev → in-progress → review |
| code-review | DEV | Quality validation | No auto update |
| retrospective | SM | Capture learnings | Retrospective: optional → completed |
| correct-course | SM | Handle issues | Adaptive |
#### Implementation Loop
```
workflow-init detects undocumented brownfield
sprint-planning (creates sprint-status.yaml)
↓
document-project (generates index.md, architecture.md, etc.)
For each epic:
epic-tech-context
↓
For each story:
create-story → story-context → dev-story → code-review
↓
Mark done in sprint-status.yaml
↓
Phase 1 (optional) → Phase 2 (planning with full context)
retrospective (epic complete)
```
**Use Case 2: Post-Completion Documentation**
## Scale Levels
| Level | Scope | Documentation | Path |
| ----- | ------------- | --------------------- | --------------- |
| 0 | Single change | tech-spec only | Phase 2 → 4 |
| 1 | 1-10 stories | tech-spec only | Phase 2 → 4 |
| 2 | 5-15 stories | PRD + architecture | Phase 2 → 3 → 4 |
| 3 | 12-40 stories | PRD + full arch | Phase 2 → 3 → 4 |
| 4 | 40+ stories | PRD + enterprise arch | Phase 2 → 3 → 4 |
## Greenfield vs Brownfield
### Greenfield (New Projects)
```
Phase 4 Implementation Complete
↓
document-project (scans final codebase)
↓
Produces clean, LLM-optimized docs > scattered phase artifacts
Phase 1 (optional) → Phase 2 → Phase 3 (L2-4) → Phase 4
```
**Why it's superior**: Creates comprehensive, consistent documentation that both humans and LLMs can use to understand projects of any size or complexity - often better than manually-maintained PRDs, architecture docs, and story files.
- Clean slate for design
- No existing constraints
- Direct to planning
### Brownfield (Existing Code)
```
document-project (if needed) → Phase 1 (optional) → Phase 2 → Phase 3 (L2-4) → Phase 4
```
- Must understand existing patterns
- Documentation prerequisite if undocumented
- Consider technical debt in planning
## Critical Rules
### Phase Transitions
1. **Check workflow-status** before any Phase 1-3 workflow
2. **Document brownfield** before planning if undocumented
3. **Complete planning** before solutioning
4. **Complete architecture** (L2-4) before implementation
### Implementation Rules
1. **Epic context first** - Must context epic before drafting stories
2. **Sequential by default** - Work stories in order within epic
3. **Learning transfer** - Draft next story after previous done
4. **Manual status updates** - Update sprint-status.yaml as needed
### Story Management
1. **Single source of truth** - sprint-status.yaml tracks everything
2. **No story search** - Agents read exact story from status file
3. **Context injection** - Each story gets specific technical guidance
4. **Retrospective learning** - Capture improvements per epic
### Best Practices
1. **Trust the process** - Let workflows guide you
2. **Respect scale** - Don't over-document small projects
3. **Use status tracking** - Always know where you are
4. **Iterate and learn** - Each epic improves the next
---
## Phase 1: Analysis (Optional)
Optional workflows for project discovery and requirements gathering. Output feeds into Phase 2 planning.
### Workflows
| Workflow | Agent | Purpose | Output | When to Use |
| ---------------------- | ------------- | ------------------------------------------- | ------------------------- | --------------------- |
| **workflow-status** | Analyst | Universal entry point and status checker | Status display + guidance | **Start here!** |
| **workflow-init** | Analyst | Generate an initial workflow status file | Status display + guidance | **OR start here!** |
| **brainstorm-game** | Game Designer | Game concept ideation using 5 methodologies | Concept proposals | New game projects |
| **brainstorm-project** | Analyst | Software solution exploration | Architecture proposals | New software projects |
| **game-brief** | Game Designer | Structured game design foundation | Game brief document | Before GDD creation |
| **product-brief** | Analyst | Strategic product planning culmination | Product brief | End of analysis phase |
| **research** | Analyst | Multi-mode research (market/technical/deep) | Research artifacts | When evidence needed |
### Flow
```
workflow-status (check) → Brainstorming → Research → Brief → Planning (Phase 2)
```
## Phase 2: Planning (Required)
### Scale Levels
| Level | Scope | Outputs | Next Phase |
| ----- | ------------------------ | ------------------------------ | ------------------------------ |
| **0** | Single atomic change | tech-spec + 1 story | → Implementation |
| **1** | 1-10 stories, 1 epic | tech-spec + epic + 2-3 stories | → Implementation |
| **2** | 5-15 stories, 1-2 epics | PRD + epics | → Solutioning → Implementation |
| **3** | 12-40 stories, 2-5 epics | PRD + epics | → Solutioning → Implementation |
| **4** | 40+ stories, 5+ epics | PRD + epics | → Solutioning → Implementation |
### Available Workflows
| Workflow | Agent | Purpose | Output | Levels |
| -------------------- | ----------- | ------------------------------------ | -------------- | ----------- |
| **prd** | PM | Product Requirements Document | PRD.md + epics | 2-4 |
| **tech-spec** | PM | Technical specification | tech-spec.md | 0-1 |
| **gdd** | PM | Game Design Document | GDD.md | Games (all) |
| **narrative** | PM | Game narrative design | narrative.md | Games (opt) |
| **create-ux-design** | UX Designer | User experience and interface design | ux-design.md | Conditional |
### Key Outputs
- **PRD.md**: Product Requirements Document (Levels 2-4)
- **Epics.md**: Epic breakdown with stories (Levels 2-4)
- **tech-spec.md**: Technical specification (Levels 0-1)
- **story-{slug}.md**: Single user story (Level 0)
- **story-{slug}-1.md, story-{slug}-2.md, story-{slug}-3.md**: User stories (Level 1)
- **GDD.md**: Game Design Document (game projects)
- **narrative.md**: Narrative design (game projects, optional)
- **ux-design.md**: UX specification (conditional, UI-heavy projects)
- **bmm-workflow-status.md**: Versioned workflow state tracking
## Phase 3: Solutioning (Levels 2-4)
Architecture and technical design phase for medium to complex projects.
### Workflows
| Workflow | Agent | Purpose | Output | When |
| -------------------------- | --------- | -------------------------------- | ------------------------- | ----------- |
| **create-architecture** | Architect | Create system-wide architecture | architecture.md with ADRs | Levels 2-4 |
| **validate-architecture** | Architect | Validate architecture design | Validation report | Optional |
| **solutioning-gate-check** | Architect | Validate PRD + UX + architecture | Gate check report | Recommended |
### Architecture Scope by Level
- **Level 2**: Lightweight architecture document focusing on key technical decisions
- **Level 3-4**: Comprehensive architecture with detailed ADRs, system diagrams, integration patterns
## Phase 4: Implementation (Iterative)
The core development cycle that transforms requirements into working software through sprint-based iteration.
### Sprint Planning - The Phase 4 Entry Point
Phase 4 begins with the **sprint-planning** workflow, which generates a `sprint-status.yaml` file that serves as the single source of truth for all implementation tracking.
**What sprint-planning does:**
1. Extracts all epics and stories from epic files
2. Creates ordered status tracking for every work item
3. Auto-detects existing story files and contexts
4. Maintains status through the development lifecycle
### The Sprint Status System
Phase 4 uses a 6-state lifecycle tracked in `sprint-status.yaml`:
**Epic Status Flow:**
```
backlog → contexted
```
**Story Status Flow:**
```
backlog → drafted → ready-for-dev → in-progress → review → done
```
**Retrospective Status:**
```
optional ↔ completed
```
#### Status Definitions
**Epic Statuses:**
- **backlog**: Epic exists in epic file but not yet contexted
- **contexted**: Epic technical context created (prerequisite for drafting stories)
**Story Statuses:**
- **backlog**: Story only exists in epic file, not yet drafted
- **drafted**: Story file created (e.g., `stories/1-3-plant-naming.md`)
- **ready-for-dev**: Draft approved + story context created
- **in-progress**: Developer actively working on implementation
- **review**: Under SM review (via code-review workflow)
- **done**: Story completed and deployed
**Retrospective Statuses:**
- **optional**: Can be done but not required
- **completed**: Retrospective has been completed
### Phase 4: The Implementation Loop
```
Phase Transition (Phase 2 or 3 → Phase 4)
↓
┌─────────────────────────────────────────────────┐
│ SM: sprint-planning │
│ Creates: sprint-status.yaml with all epics/ │
│ stories set to 'backlog' │
└───────────────────┬─────────────────────────────┘
↓
┌─────────────────────────────────────────────────┐
│ SM: epic-tech-context (for current epic) │
│ Creates: epic-N-context.md │
│ Updates: Epic status to 'contexted' │
└───────────────────┬─────────────────────────────┘
↓
┌─────────────────────────────────────────────────┐
│ SM: create-story (drafts next backlog story) │
│ Creates: story-{key}.md │
│ Updates: Story status to 'drafted' │
└───────────────────┬─────────────────────────────┘
↓
┌─────────────────────────────────────────────────┐
│ SM: story-context (creates implementation ctx) │
│ Creates: story-{key}-context.md │
│ Updates: Story status to 'ready-for-dev' │
└───────────────────┬─────────────────────────────┘
↓
┌─────────────────────────────────────────────────┐
│ DEV: dev-story (implements story) │
│ Reads: story + context files │
│ Updates: Story status to 'in-progress' │
│ then to 'review' when complete │
└───────────────────┬─────────────────────────────┘
↓
┌─────────────────────────────────────────────────┐
│ DEV: code-review (validates implementation) │
│ Reviews: Code changes against DoD │
│ Feedback: Iteration or approval │
└───────────────────┬─────────────────────────────┘
↓
┌─────────────────────────────────────────────────┐
│ DEV/SM: Updates story status to 'done' │
│ Manual update to sprint-status.yaml │
└───────────────────┬─────────────────────────────┘
↓
┌───────┴────────┐
│ More stories? │
└───────┬────────┘
┌───┴───┐
↓ ↓
[Yes: Loop] [No: Epic Complete]
↓
┌───────────────────┐
│ SM: retrospective│
│ Updates: epic-N- │
│ retrospective to │
│ 'completed' │
└───────────────────┘
```
### Workflow Responsibilities
| Workflow | Agent | Purpose | Status Updates |
| --------------------- | ----- | -------------------------------------- | ------------------------------------------- |
| **sprint-planning** | SM | Initialize sprint status tracking | Creates sprint-status.yaml |
| **epic-tech-context** | SM | Create epic-specific technical context | Epic: backlog → contexted |
| **create-story** | SM | Draft individual story files | Story: backlog → drafted |
| **story-context** | SM | Generate implementation context/XML | Story: drafted → ready-for-dev |
| **dev-story** | DEV | Implement story | Story: ready-for-dev → in-progress → review |
| **code-review** | DEV | Quality validation and feedback | (No automatic state change) |
| **retrospective** | SM | Capture epic learnings | Retrospective: optional → completed |
| **correct-course** | SM | Handle issues/scope changes | (Adaptive based on situation) |
### Key Guidelines
1. **Epic Context First**: Epics should be `contexted` before their stories can be `drafted`
2. **Sequential by Default**: Stories are typically worked in order within an epic
3. **Parallel Work Supported**: Multiple stories can be `in-progress` if team capacity allows
4. **Learning Transfer**: SM drafts next story after previous is `done` to incorporate learnings
5. **Flexible Status Updates**: Agents and users can manually update sprint-status.yaml as needed
## Greenfield vs Brownfield Paths
### Greenfield Projects (New Code)
**Path:** Phase 1 (optional) → Phase 2 → Phase 3 (Levels 2-4) → Phase 4
- **Level 0-1**: Skip Phase 3, go straight to implementation with tech-spec
- **Level 2-4**: Full solutioning with architecture before implementation
- Clean slate for architectural decisions
- No existing patterns to constrain design
### Brownfield Projects (Existing Code)
**Path:** Documentation Prerequisite (if undocumented) → Phase 1 (optional) → Phase 2 → Phase 3 (Levels 2-4) → Phase 4
**Documentation Prerequisite (Conditional):**
```
workflow-status/workflow-init
├─→ Check: Is existing codebase documented?
│ ├─→ YES: Proceed to Phase 1 or 2
│ └─→ NO: REQUIRED - Run document-project workflow first
│ ├─→ Analyzes existing code
│ ├─→ Documents current architecture
│ ├─→ Identifies technical debt
│ ├─→ Creates comprehensive baseline documentation
│ └─→ Produces superior docs for LLM + human understanding
└─→ Continue with scale-adaptive planning (Phases 1-4)
```
**Critical for Brownfield**:
- Must understand existing patterns before planning
- Integration points need documentation
- Technical debt must be visible in planning
- Constraints from existing system affect scale decisions
**Post-Completion Option**: After Phase 4 completes, run `document-project` again to create clean source-of-truth documentation that supersedes scattered phase artifacts.
## Agent Participation by Phase
| Phase/Step | Primary Agents | Supporting Agents | Key Workflows |
| ---------------------------------- | ---------------------- | -------------------- | ------------------------------------------- |
| **Prerequisite: Documentation** | Analyst | - | document-project (conditional) |
| **Phase 1: Analysis** | Analyst, Game Designer | PM, Researcher | brainstorm-_, research, _-brief |
| **Phase 2: Planning** | PM | UX Designer, Analyst | prd, tech-spec, gdd, narrative |
| **Phase 3: Solutioning** | Architect | PM, Tech Lead | create-architecture, solutioning-gate-check |
| **Phase 4: Implementation** | SM, DEV | SR (code-review) | sprint-planning, create-story, dev-story |
| **Post-Completion: Documentation** | Analyst | - | document-project (optional cleanup) |
## Key Files and Artifacts
### Tracking Documents
- **bmm-workflow-status.md**: Phase and workflow tracking (updated by workflow-status)
- Current phase and progress
- Workflow history
- Next recommended actions
- Project metadata and configuration
- **sprint-status.yaml**: Implementation tracking (Phase 4 only)
- All epics, stories, and retrospectives
- Current status for each item (backlog → done)
- Single source of truth for Phase 4 progression
- Updated by agents as work progresses
- **Epics.md**: Master epic/story definitions (source of truth for planning, Level 2-4)
### Phase Outputs
- **Documentation Prerequisite (if run)**:
- Comprehensive project documentation (index.md, architecture.md, source-tree-analysis.md, component-inventory.md, etc.)
- Superior to manually-maintained docs for LLM understanding
- **Phase 1**:
- Product briefs, game briefs, research documents
- **Phase 2**:
- Level 0: tech-spec.md + story-{slug}.md
- Level 1: tech-spec.md + epic breakdown + story-{slug}-N.md files
- Level 2-4: PRD.md + epics.md (+ optional ux-design.md, narrative.md)
- **Phase 3**:
- architecture.md (with ADRs)
- Validation reports
- Gate check documentation
- **Phase 4**:
- sprint-status.yaml (tracking file)
- epic-N-context.md files (per epic)
- story-{key}.md files (per story)
- story-{key}-context.md files (per story)
- Implemented code and tests
## Best Practices
### 1. Respect the Scale
- Don't create PRDs for Level 0-1 changes (use tech-spec only)
- Don't skip architecture for Level 2-4 projects
- Let the workflow paths determine appropriate artifacts
- Level 2 still requires Phase 3 solutioning (lighter than 3-4)
### 2. Use Sprint Planning Effectively
- Run sprint-planning at the start of Phase 4
- Context epics before drafting their stories (epic-tech-context)
- Update sprint-status.yaml as work progresses
- Re-run sprint-planning to auto-detect new files/contexts
### 3. Maintain Flow Integrity
- Stories must be defined in Epics.md before sprint-planning
- Complete epic context before story drafting
- Create story context before implementation
- Each phase completes before the next begins
### 4. Document Brownfield First (Prerequisite)
- Never plan without understanding existing code
- Run document-project if codebase is undocumented (PREREQUISITE, not Phase 0)
- Technical debt must be visible in planning
- Integration points need documentation
- Can also run post-Phase 4 for superior final documentation
### 5. Learn Continuously
- Run retrospectives after each epic
- Incorporate learnings into next story drafts
- Update workflows based on team feedback
- Share patterns across teams
## Common Pitfalls and Solutions
| Pitfall | Solution |
| ------------------------------------- | ----------------------------------------------------- |
| Skipping sprint-planning | Always run at Phase 4 start - it creates status file |
| Creating stories without epic context | Run epic-tech-context before create-story |
| Skipping story-context generation | Always run after create-story for better dev guidance |
| Not updating sprint-status.yaml | Update statuses as work progresses |
| Thinking Level 2 skips Phase 3 | Level 2 DOES require architecture (just lighter) |
| Planning brownfield without docs | Run document-project first if undocumented |
| Not running retrospectives | Complete after every epic for learning transfer |
| Manually tracking stories elsewhere | Use sprint-status.yaml as single source of truth |
## Quick Reference Commands
```bash
# Universal Entry Point (Start Here!)
bmad analyst workflow-status # Check status and get recommendations
# Documentation Prerequisite (Brownfield without docs OR post-completion cleanup)
bmad analyst document-project
# Phase 1: Analysis (Optional)
bmad analyst brainstorm-project # Software ideation
bmad game-designer brainstorm-game # Game ideation
bmad analyst research # Market/technical research
bmad analyst product-brief # Software brief
bmad game-designer game-brief # Game brief
# Phase 2: Planning (Required)
bmad pm prd # Level 2-4 software projects
bmad pm tech-spec # Level 0-1 software projects
bmad pm gdd # Game projects (all levels)
bmad pm narrative # Game narrative (optional)
bmad ux-designer create-ux-design # UI-heavy projects
# Phase 3: Solutioning (Levels 2-4)
bmad architect create-architecture # System architecture
bmad architect validate-architecture # Validation (optional)
bmad architect solutioning-gate-check # Gate check
# Phase 4: Implementation (Sprint-Based)
bmad sm sprint-planning # FIRST: Initialize sprint tracking
bmad sm epic-tech-context # Create epic context (per epic)
bmad sm create-story # Draft story file
bmad sm story-context # Create story context
bmad dev dev-story # Implement story
bmad sm code-review # Quality validation
# (Update sprint-status.yaml to 'done' manually or via workflow)
bmad sm retrospective # After epic complete
bmad sm correct-course # If issues arise
```
## Future Enhancements
### Coming Soon
- **Automated status updates**: Workflows automatically update sprint-status.yaml
- **Workflow orchestration**: Automatic phase transitions and validation
- **Progress dashboards**: Real-time workflow status visualization
- **Team synchronization**: Multi-developer story coordination
### Under Consideration
- AI-assisted retrospectives with pattern detection
- Automated story sizing based on historical data
- Predictive epic planning with risk assessment
- Cross-project learning transfer
- Enhanced brownfield analysis with architectural debt scoring
---
**Version**: v6-alpha
**Last Updated**: 2025-10-26
This document serves as the authoritative guide to BMM v6a workflow execution. For detailed information about individual workflows, see their respective README files in the workflow folders.
## Related Documentation
- **Workflow Paths**: See `workflow-status/paths/` for detailed greenfield/brownfield routing by level
- **Phase 2 Planning**: See `2-plan-workflows/README.md` for scale-adaptive planning details
- **Phase 4 Sprint Planning**: See `4-implementation/sprint-planning/README.md` for sprint status system
- **Individual Workflows**: Each workflow directory contains its own README with specific instructions
For specific workflow details, see individual workflow READMEs in their respective directories.