bmad-code-org__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-ticket	Break requirements into implementable work	Ticket tree of epic folders and story files
bmad-sprint-planning	Readiness gate before implementation, then story tracking and status view	PASS/CONCERNS/FAIL + sprint-status.yaml

bmad-create-epics-and-stories is retained as a v6 compatibility shim that forwards to bmad-ticket.

The ticket tree is what Phase 3 hands to Phase 4: each workable story leaf (KEY-n-slug.md under a tickets/ folder) is a complete work definition — behavior, acceptance criteria with verification, boundaries, and typed pointers back to the planning documents — so bmad-build is pointed at the leaf path and needs nothing exported from the tree. Ask bmad-ticket which leaves are workable now with ticket_tree.py frontier; the tree lives in the work store (.bmad-obeya by default).

For how the readiness gate, deterministic tracking, and status view work together, see Sprint Planning.

Phase 4: Implementation

Every implementation path converges on bmad-build. It accepts direct intent, an issue, a specification, a ticket from the ticket tree, 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-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-retrospective	Evidence-based review of a completed epic against its acceptance criteria	Retro document, action items, acceptance verdict

Direct and Planned Entry

Clear work can enter bmad-build directly. Larger initiatives can first produce a PRD, UX design, architecture, a ticket tree of epics and stories, readiness results, and a sprint plan. Those artifacts add context; they do not select another implementation workflow. On the ticket path, hand bmad-build (or bmad-build-auto unattended) the story leaf's path: it reads the ticket's frontmatter and body as the whole work definition, carries every acceptance criterion into the spec it writes, and leaves the ticket itself untouched — a stories.yaml entry remains an equally valid input for in-flight v6 work.

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] Set up your repo so AI agents follow your project's rules across all workflows: a small verified block in AGENTS.md, maintained by bmad-project-context. Seed it from your architecture at the end of planning, or discover it from an existing codebase at any time. :::

How to create it:

• Run bmad-project-context — greenfield (seeded from your spec or architecture) or brownfield (discovered from the codebase, verified, then confirmed with you). The earlier bmad-generate-project-context is deprecated and forwards there; an existing project-context.md is offered up for absorption.

Learn more about project context