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.

Core v6 Innovations

Scale-Adaptive Planning: Projects automatically route through different workflows based on complexity (Level 0-4), ensuring appropriate documentation and process overhead.

Just-In-Time Design: Technical specifications are created one epic at a time during implementation, not all upfront, incorporating learnings as the project evolves.

Dynamic Expertise Injection: Story-context workflows provide targeted technical guidance per story, replacing static documentation with contextual expertise.

Continuous Learning Loop: Retrospectives feed improvements back into workflows, making each epic smoother than the last.

The Four Phases

┌──────────────────────────────────────────────────────────────┐
│                    PHASE 1: ANALYSIS                         │
│                      (Optional)                              │
├──────────────────────────────────────────────────────────────┤
│  brainstorm-game ──┐                                         │
│  brainstorm-project ├──→ research ──→ product-brief  ──┐     │
│  game-brief ────────┘                                  │     │
└────────────────────────────────────────────────────────┼─────┘
                                                         ↓
┌──────────────────────────────────────────────────────────────┐
│                    PHASE 2: PLANNING                         │
│                  (Scale-Adaptive Router)                     │
├──────────────────────────────────────────────────────────────┤
│                    plan-project                              │
│                         ├──→ Level 0: tech-spec only         │
│                         ├──→ Level 1-2: PRD + tech-spec      │
│                         ├──→ Level 3-4: PRD + Epics ──────┐  │
│                         └──→ Game: GDD                    │  │
└───────────────────────────────────────────────────────────┼──┘
                                                            ↓
┌──────────────────────────────────────────────────────────────┐
│                   PHASE 3: SOLUTIONING                       │
│                    (Levels 3-4 Only)                         │
├──────────────────────────────────────────────────────────────┤
│  3-solutioning ──→ Architecture.md                           │
│       ↓                                                      │
│  tech-spec (per epic, JIT during implementation)             │
└────────────────────────────────────────────────────────────┬─┘
                                                             ↓
┌──────────────────────────────────────────────────────────────┐
│                  PHASE 4: IMPLEMENTATION                     │
│                    (Iterative Cycle)                         │
├──────────────────────────────────────────────────────────────┤
│  ┌─→ create-story ──→ story-context ──→ dev-story ──┐        │
│  │                                                  ↓        │
│  │   retrospective ←── [epic done] ←────── review-story      │
│  │                                            ↓              │
│  └──────────── correct-course ←──[if issues]──┘              │
└──────────────────────────────────────────────────────────────┘

Phase 1: Analysis (Optional)

Optional workflows for project discovery and requirements gathering. Output feeds into Phase 2 planning.

Workflows

Workflow	Purpose	Output	When to Use
brainstorm-game	Game concept ideation using 5 methodologies	Concept proposals	New game projects
brainstorm-project	Software solution exploration	Architecture proposals	New software projects
game-brief	Structured game design foundation	Game brief document	Before GDD creation
product-brief	Strategic product planning culmination	Product brief	End of analysis phase
research	Multi-mode research (market/technical/deep)	Research artifacts	When evidence needed

Flow

Brainstorming → Research → Brief → Planning (Phase 2)

Phase 2: Planning (Required)

The central orchestrator that determines project scale and generates appropriate planning artifacts.

Scale Levels

Level	Scope	Outputs	Next Phase
0	Single atomic change	tech-spec only	→ Implementation
1	1-10 stories, 1 epic	Minimal PRD + tech-spec	→ Implementation
2	5-15 stories, 1-2 epics	Focused PRD + tech-spec	→ Implementation
3	12-40 stories, 2-5 epics	Full PRD + Epics list	→ Solutioning
4	40+ stories, 5+ epics	Enterprise PRD + Epics	→ Solutioning

Routing Logic

plan-project
    ├─→ Detect project type (game/web/mobile/backend/etc)
    ├─→ Assess complexity → assign Level 0-4
    ├─→ Check context (greenfield/brownfield)
    │   └─→ If brownfield & undocumented:
    │       └─→ HALT: "Generate brownfield documentation first"
    │           └─→ (TBD workflow for codebase analysis)
    ├─→ Route to appropriate sub-workflow:
    │   ├─→ Game → GDD workflow
    │   ├─→ Level 0 → tech-spec workflow
    │   ├─→ Level 1-2 → PRD + embedded tech-spec
    │   └─→ Level 3-4 → PRD + epics → Solutioning
    └─→ Generate project-workflow-analysis.md (tracking doc)

Key Outputs

PRD.md: Product Requirements Document (Levels 1-4)
Epics.md: Epic breakdown with stories (Levels 2-4)
tech-spec.md: Technical specification (Levels 0-2 only)
GDD.md: Game Design Document (game projects)
project-workflow-analysis.md: Workflow state tracking

Phase 3: Solutioning (Levels 3-4 Only)

Architecture and technical design phase for complex projects.

Workflows

Workflow	Owner	Purpose	Output	Timing
3-solutioning	Architect	Create overall architecture	Architecture.md with ADRs	Once per project
tech-spec	Architect	Create epic-specific tech spec	tech-spec-epic-N.md	One per epic, JIT

Just-In-Time Tech Specs

FOR each epic in sequence:
    WHEN ready to implement epic:
        Architect: Run tech-spec workflow for THIS epic only
        → Creates tech-spec-epic-N.md
        → Hands off to implementation
    IMPLEMENT epic completely
    THEN move to next epic

Critical: Tech specs are created ONE AT A TIME as epics are ready for implementation, not all upfront. This prevents over-engineering and incorporates learning.

Phase 4: Implementation (Iterative)

The core development cycle that transforms requirements into working software.

The Implementation Loop

┌─────────────────────────────────────────┐
│            SM: create-story             │
│   (Generate next story from epics.md)   │
└─────────────────────┬───────────────────┘
                      ↓
┌─────────────────────────────────────────┐
│           SM: story-context             │
│  (Generate expertise injection XML)     │
└─────────────────────┬───────────────────┘
                      ↓
┌─────────────────────────────────────────┐
│            DEV: dev-story               │
│  (Implement with context injection)     │
└─────────────────────┬───────────────────┘
                      ↓
┌─────────────────────────────────────────┐
│         SR/DEV: review-story            │
│     (Validate against criteria)         │
└─────────────────────┬───────────────────┘
                      ↓
            ┌─────────┴─────────┐
            │    Issues Found?   │
            └─────────┬─────────┘
                ┌─────┴─────┐
                ↓           ↓
        [No: Next Story]  [Yes: correct-course]
                              ↓
                      [Return to appropriate step]

Workflow Responsibilities

Workflow	Agent	Purpose	Key Innovation
create-story	SM	Generate ONE story at a time	Enforces epics.md planning
story-context	SM	Create expertise injection	JIT technical guidance
dev-story	DEV	Implement with context	Resumable after review
review-story	SR/DEV	Comprehensive validation	Fresh context review
correct-course	SM	Handle issues/changes	Adaptive response
retrospective	SM	Capture epic learnings	Continuous improvement

Story Flow States

Draft (create-story)
  → Approved (SM approval)
    → In Progress (dev-story)
      → Ready for Review (dev complete)
        → Done (review passed)
        OR
        → In Progress (review failed, back to dev)

Greenfield vs Brownfield Considerations

Greenfield Projects

Start with Phase 1 (Analysis) or Phase 2 (Planning)
Clean architecture decisions in Phase 3
Straightforward implementation in Phase 4

Brownfield Projects

plan-project (Phase 2)
    ├─→ Check: Is existing codebase documented?
    │   ├─→ YES: Proceed with planning
    │   └─→ NO: HALT with message:
    │       "Brownfield project requires documentation.
    │        Please run codebase-analysis workflow first."
    │        └─→ [TBD: brownfield-analysis workflow]
    │            ├─→ Analyzes existing code
    │            ├─→ Documents current architecture
    │            ├─→ Identifies technical debt
    │            └─→ Creates baseline documentation
    └─→ Continue with scale-adaptive planning

Critical for Brownfield: Without adequate documentation of the existing system, the planning phase cannot accurately assess scope or create meaningful requirements. The brownfield-analysis workflow (coming soon) will:

Map existing architecture
Document current patterns
Identify integration points
Assess technical debt
Create the baseline needed for planning

Agent Participation by Phase

Phase	Primary Agents	Supporting Agents
Analysis	Analyst, Researcher	PM, PO
Planning	PM	Analyst, UX Expert
Solutioning	Architect	PM, Tech Lead
Implementation	SM, DEV	SR, PM (for correct-course)

Key Files and Artifacts

Tracking Documents

project-workflow-analysis.md: Maintains workflow state, level, and progress
Epics.md: Master list of epics and stories (source of truth for planning)

Phase Outputs

Phase 1: Briefs and research documents
Phase 2: PRD, Epics, or tech-spec based on level
Phase 3: Architecture.md, epic-specific tech specs
Phase 4: Story files, context XMLs, implemented code

Best Practices

1. Respect the Scale

Don't create PRDs for Level 0 changes
Don't skip architecture for Level 3-4 projects
Let the workflow determine appropriate artifacts

2. Embrace Just-In-Time

Create tech specs one epic at a time
Generate stories as needed, not in batches
Build context injections per story

3. Maintain Flow Integrity

Stories must be enumerated in Epics.md
Each phase completes before the next begins
Use fresh context windows for reviews

4. Document Brownfield First

Never plan without understanding existing code
Technical debt must be visible in planning
Integration points need documentation

5. Learn Continuously

Run retrospectives after each epic
Update workflows based on learnings
Share patterns across teams

Common Pitfalls and Solutions

Pitfall	Solution
Creating all tech specs upfront	Use JIT approach - one epic at a time
Skipping story-context generation	Always run after create-story
Batching story creation	Create one story at a time
Ignoring scale levels	Let plan-project determine level
Planning brownfield without docs	Run brownfield-analysis first
Not running retrospectives	Schedule after every epic

Quick Reference Commands

# Phase 1: Analysis (Optional)
bmad analyst brainstorm-project
bmad analyst research
bmad analyst product-brief

# Phase 2: Planning
bmad pm plan-project

# Phase 3: Solutioning (L3-4)
bmad architect solution-architecture
bmad architect tech-spec  # Per epic, JIT

# Phase 4: Implementation
bmad sm create-story      # One at a time
bmad sm story-context     # After each story
bmad dev develop          # With context loaded
bmad dev review-story     # Or SR agent
bmad sm correct-course    # If issues
bmad sm retrospective     # After epic

Future Enhancements

Coming Soon

brownfield-analysis: Automated codebase documentation generator
Workflow orchestration: Automatic phase transitions
Progress dashboards: Real-time workflow status
Team synchronization: Multi-developer story coordination

Under Consideration

AI-assisted retrospectives
Automated story sizing
Predictive epic planning
Cross-project learning transfer

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.