BMAD-METHOD/docs/reference/workflow-map.md

title, description, sidebar

title	description	sidebar
Workflow Map	Visual reference for BMad Method workflow phases and outputs	order 1

The BMad Method (BMM) is a module in the BMad Ecosystem, targeted at following the best practices of context engineering and planning. AI agents work best with clear, structured context. The BMM system builds that context progressively across 4 distinct phases - each phase, and multiple workflows optionally within each phase, produce documents that inform the next, so agents always know what to build and why.

The rationale and concepts come from agile methodologies that have been used across the industry with great success as a mental framework.

If at any time you are unsure what to do, the bmad-help skill will help you stay on track or know what to do next. You can always refer to this for reference also - but bmad-help is fully interactive and much quicker if you have already installed the BMad Method. Additionally, if you are using different modules that have extended the BMad Method or added other complementary non-extension modules - bmad-help evolves to know all that is available to give you the best in-the-moment advice.

Final important note: Every workflow below can be run directly with your tool of choice via skill or by loading an agent first and using the entry from the agents menu.

Open diagram in new tab ↗

Phase 1: Analysis (Optional)

Explore the problem space and validate ideas before committing to planning. Learn what each tool does and when to use it.

Workflow	Purpose	Produces
bmad-brainstorming	Brainstorm Project Ideas with guided facilitation of a brainstorming coach	brainstorm.html keepsake plus an optional brainstorm-intent.md
bmad-forge-idea	Pressure-test an idea until it hardens, proves out, or dies cheaply	forge-report.html every run; forged-idea.md when an idea hardens
bmad-deep-recon	Research any subject for a decision — draft a prompt for your deep-research tool, process its report, or run the research here; six typed packs, verified and cited	Research report or summary + optional HTML briefing
bmad-product-brief	Capture strategic vision — best when your concept is clear	brief.md + addendum.md, plus any desired HTML or presentation output
bmad-prfaq	Working Backwards — stress-test your product concept customer-first	prfaq-{project}.md

For Deep Recon's three modes and how a research run works inside, see Deep Recon.

Phase 2: Planning

Define what to build and for whom.

Workflow	Purpose	Produces
bmad-prd	Create, update, or validate a PRD — facilitated discovery, three intents in one skill	Create/Update: prd.md, addendum.md, .memlog.md; Validate: validation-report.html + .md
bmad-ux	Design user experience (when UX matters) — DESIGN.md (visual) + EXPERIENCE.md (behavioral) spine pair	DESIGN.md, EXPERIENCE.md, .memlog.md
bmad-spec	Distill any intent input (brief, PRD, transcript, brain dump, design folder) into a succinct SPEC.md contract + companions — locks the WHAT before the HOW	SPEC.md + companions under {output_folder}/specs/spec-{slug}/; optional stories.yaml

:::tip[Three intents in one skill] bmad-prd handles the full PRD lifecycle. State your intent when invoking or the skill will ask:

• Create — new PRD from scratch via coached discovery; produces prd.md, addendum.md, and .memlog.md
• Update — reconcile an existing PRD with a change signal, surfacing conflicts before applying changes
• Validate — critique a PRD against a configurable checklist and produce a structured HTML findings report :::

:::note[bmad-spec] bmad-spec produces the canonical machine contract: a five-field kernel (Why, Capabilities, Constraints, Non-goals, Success signal) plus companion files, validated so every load-bearing source claim is preserved. It is the only writer of SPEC.md; other skills invoke it headless when they need to express or update intent. On request it can also break a spec into an ordered stories.yaml for autonomous dispatch — see Autonomous Development Loops. :::

:::tip[Upstream: bmad-product-brief] bmad-product-brief (Phase 1) produces a product-brief.md that bmad-prd can source-extract during Discovery, reducing re-explanation and keeping the two documents aligned. Neither skill requires the other — start with bmad-prd directly if you already know what you're building. :::

Phase 3: Solutioning

Decide how to build it and break work into stories.

Workflow	Purpose	Produces
bmad-architecture	Make technical decisions explicit	ARCHITECTURE-SPINE.md is the spine by default but can hydrate to your desired output or presentation needs also
bmad-create-epics-and-stories	Break requirements into implementable work	Epic files with stories
bmad-check-implementation-readiness	Gate check before implementation	PASS/CONCERNS/FAIL decision

Phase 4: Implementation

Every implementation path converges on bmad-build. It accepts direct intent, an issue, a specification, or a planned story, then chooses the clarification, planning, implementation, and review depth needed for that input.

Workflow	Purpose	Produces
bmad-build	Turn direct intent or a planned story into implemented, reviewed code	spec-*.md + code
bmad-sprint-planning	Initialize tracking (once per project to sequence the dev cycle)	sprint-status.yaml
bmad-code-review	Ad hoc review of any code change	Findings + applied patches
bmad-correct-course	Handle significant mid-sprint changes	Updated plan or re-routing
bmad-sprint-status	Track sprint progress and story status	Sprint status update
bmad-retrospective	Review after epic completion	Lessons learned

Direct and Planned Entry

Clear work can enter bmad-build directly. Larger initiatives can first produce a PRD, UX design, architecture, epics, stories, readiness results, and sprint plan. Those artifacts add context; they do not select another implementation workflow.

bmad-build-auto can orchestrate unattended iterations of the same development model when autonomous execution is appropriate.

For the reference on unattended development loops with bmad-build-auto, see Autonomous Development Loops.

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. Spec files give focused, complete context for implementation. Without this structure, agents make inconsistent decisions.

Project Context

:::tip[Recommended] Create project-context.md to ensure AI agents follow your project's rules and preferences. This file works like a constitution for your project — it guides implementation decisions across all workflows. This optional file can be generated at the end of Architecture Creation, or in an existing project it can be generated also to capture whats important to keep aligned with current conventions. :::

How to create it:

• Manually — Create _bmad-output/project-context.md with your technology stack and implementation rules
• Generate it — Run bmad-generate-project-context to auto-generate from your architecture or codebase

Learn more about project-context.md