---
title: "Workflow Map"
description: Visual reference for BMad Method workflow phases and outputs
---

BMAD is a context management system. AI agents work best with clear, structured context. The BMM workflow builds that context progressively - each phase produces documents that inform the next, so agents always know what to build and why.

![BMad Method Workflow Map](/img/workflow-map.png)

## Phase 1: Analysis (Optional)

Explore the problem space and validate ideas before committing to planning.

| Workflow | Purpose | Produces |
|----------|---------|----------|
| `research` | Validate market, technical, or domain assumptions | Research findings |
| `create-product-brief` | Capture strategic vision | `product-brief.md` |

## Phase 2: Planning

Define what to build and for whom.

| Workflow | Purpose | Produces |
|----------|---------|----------|
| `prd` | Define requirements (FRs/NFRs) | `PRD.md` |
| `create-ux-design` | Design user experience (when UX matters) | `ux-spec.md` |

## Phase 3: Solutioning

Decide how to build it and break work into stories.

| Workflow | Purpose | Produces |
|----------|---------|----------|
| `create-architecture` | Make technical decisions explicit | `architecture.md` with ADRs |
| `create-epics-and-stories` | Break requirements into implementable work | Epic files with stories |
| `check-implementation-readiness` | Gate check before implementation | PASS/CONCERNS/FAIL decision |

## Phase 4: Implementation

Build it, one story at a time.

| Workflow | Purpose | Produces |
|----------|---------|----------|
| `sprint-planning` | Initialize tracking (once per project) | `sprint-status.yaml` |
| `create-story` | Prepare next story for implementation | `story-[slug].md` |
| `dev-story` | Implement the story | Working code + tests |
| `code-review` | Validate implementation quality | Approved or changes requested |
| `correct-course` | Handle significant mid-sprint changes | Updated plan or re-routing |
| `retrospective` | Review after epic completion | Lessons learned |

## Quick Flow (Parallel Track)

Skip phases 1-3 for small, well-understood work.

| Workflow | Purpose | Produces |
|----------|---------|----------|
| `quick-spec` | Define an ad-hoc change | `tech-spec.md` (story file for small changes) |
| `quick-dev` | Implement from spec or direct instructions | Working code + tests |

## Context Management

Each document becomes context for the next phase. The PRD tells the architect what constraints matter. The architecture tells the dev agent which patterns to follow. Story files give focused, complete context for implementation. Without this structure, agents make inconsistent decisions.

For brownfield projects, `document-project` creates or updates `project-context.md` - what exists in the codebase and the rules all implementation workflows must observe. Run it just before Phase 4, and again when something significant changes - structure, architecture, or those rules. You can also edit `project-context.md` by hand.

All implementation workflows load `project-context.md` if it exists. Additional context per workflow:

| Workflow | Also Loads |
|----------|------------|
| `create-story` | epics, PRD, architecture, UX |
| `dev-story` | story file |
| `code-review` | architecture, story file |
| `quick-spec` | planning docs (if exist) |
| `quick-dev` | tech-spec |