mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-09-19 08:11:52 +08:00
Brian Madison
d3c06add2e
- Scripts + tests: node type project -> initiative (both script homes, byte-identical)
- bmad-ticket: finalize_reviewers consolidated to skill:bmad-review with explicit lenses (V7-9); default tree root now {project-root}/.bmad-obeya with docs, help row, changelog and a new eval case updated (V7-14)
- bmad-build / build-auto: accept a story ticket as the work definition alongside stories.yaml; no-input halt explains both options; v6 stories.yaml path unchanged (V7-10)
- Translated docs (cs, fr, vi-vn, zh-cn): commands, workflow-map, getting-started rewired to bmad-ticket; register fixes (V7-11)
- Merge polish: SKILL.md verb list matches ticket_tree.py subcommands; module-help.csv row normalized (V7-12)
126 lines
9.9 KiB
Markdown
126 lines
9.9 KiB
Markdown
---
|
|
title: "Workflow Map"
|
|
description: Visual reference for BMad Method workflow phases and outputs
|
|
sidebar:
|
|
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.
|
|
|
|
<iframe src="/workflow-map-diagram.html" title="BMad Method Workflow Map Diagram" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
|
|
|
|
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
|
|
<a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">Open diagram in new tab ↗</a>
|
|
</p>
|
|
|
|
## 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**](../explanation/analysis-phase.md).
|
|
|
|
| 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](../explanation/deep-recon.md).
|
|
|
|
## 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](./build-auto.md).
|
|
:::
|
|
|
|
:::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](../explanation/sprint-planning.md).
|
|
|
|
## 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](./build-auto.md).
|
|
|
|
## 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**](../explanation/project-context.md)
|