# What Is the BMAD Method? Five Agents, One Build Loop
Skills in your coding tool, five named agents and one Build loop that sizes itself: a document trail for audited, multi-team work, and none at all for a one-line fix.
7 min read · Beginner · Lesson 4 of 7 in Methods decoded · Updated 2026-10-08 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/what-is-the-bmad-method/
> **In short.** BMAD (the *Breakthrough Method of Agile AI-Driven Development*, from BMad Code) installs named
> commands, called skills, into your AI coding tool. Five named agents turn an idea into a brief, a
> requirements document, an architecture spine, a spec and stories, and one skill, Build, turns each
> story into reviewed code. The process sizes itself: a small change goes straight to Build, and work
> that several teams share gets the full document trail.
**In this lesson** you'll learn:
- what BMAD installs, and what Build does with a change;
- how it grows from one session to a project without changing its unit;
- when its document trail pays, and when BMAD says to skip it.
## Sound familiar?
- A single long AI conversation "designed" the system, and nobody can find where any decision was made.
- An auditor asks who approved the architecture, and the answer is a chat log.
- The coding agent builds each story in isolation, and the pieces do not fit.
BMAD was built against the first two, and its spec and stories are designed to prevent the third.
## What is the BMAD Method?
The BMAD Method is a set of skills that BMad Code's open-source installer adds to your AI coding tool,
where five named agents and one Build skill turn an idea into documents and reviewed code. It is not a
separate app or a fixed line of agents that every change must pass: a change gets only the skills it
needs, down to none.
The agents are the Analyst, the Product Manager, the UX Designer, the Architect and the Developer, and
each skill writes a document the next one reads. This lesson describes v6.12.1, of 4 October 2026.
## How BMAD works, step by step
### Step 1 · Install it, then ask it what to do
`npx bmad-method install` needs Node.js 20.12 or later, and `uv` for Build. It writes one folder per
skill into your tool's skills directory, and `bmad-help` then recommends the next skill.
SkyWays, this manual's fictional airline, starts its rebooking team with `bmad-project-context`: a
verified block in `AGENTS.md` for what the code cannot say, such as that the tests take eleven minutes
and the refund module is frozen.
### Step 2 · One session: Build plans, builds and reviews
Build (`bmad-build`) is the unit everything else repeats. Give it any intent, from a sentence or an
issue to a planned story: it reads the code first, then reports intent gaps, irreversible actions and
its footprint. Clean on all three, it writes a minimal spec and the code in one session; anything
flagged gets a written plan, and your answers, first. Independent reviewers check the diff, and Build
commits with an implementation record. A session is about 500 lines of code, not counting tests.
Showing the wheelchair-assistance flag on SkyWays' rebooking summary is clean on all three, so no
planning document is written.
### Step 3 · An epic: one spec and its stories
An epic is one outcome that needs several sessions. `bmad-spec` writes its contract in five fields
(why, capabilities, constraints, non-goals, the success signal), and Story Breakdown orders its
stories, a Build each: the job this manual's story file does. `bmad-retrospective` then judges the
epic on its evidence: accepted, accepted with open items, or rejected.
SkyWays' goodwill voucher, within a cap, is three stories: the offer, the cap check, the ledger line.
Each passed review alone; the retrospective found the cap checked twice and the ledger line missing on
the retry path.
### Step 4 · A project: the documents the organisation owns
Several epics, or roughly 20 sessions, make a project, and the documents become contracts between
people: the PRD, the UX pair (`DESIGN.md` and `EXPERIENCE.md`), and the Architect's spine, which records
only the decisions two teams would otherwise make differently. Epics and stories follow, then a
readiness gate asks whether a developer could build them without inventing decisions: PASS, CONCERNS
or FAIL. With the brief and the sprint status, that is **six documents** before any code.
BMAD names five sign-off moments: the PRFAQ's verdict, the PRD's validation, the spine's review, the
readiness gate and each retrospective. In a regulated setting their results are the audit trail. For
SkyWays' disruption agent, built by three teams and read by auditors, the spine is also where this
manual adds the authority budget: each tool the agent may call, and its cap.
### Step 5 · Let it size itself, and know the two failures
BMAD's own advice is the smallest amount of it that safely fits: an obvious, low-risk edit you will
review yourself needs no BMAD, and Build is worth it once a bug could escape into production. The
common failure is the opposite: "we are a BMAD shop" puts six documents in front of a typo fix, and
within a month the team skips the trail everywhere, audited work included.
*Six documents suit a product three teams build. For a typo fix, BMAD's own advice is to skip it.*
The quieter failure: Build flags an irreversible action, but cannot know your limits. The voucher cap
sat in a slide deck until the authority budget put it in the tool's signature.
## When BMAD pays, and when it does not
| The change | BMAD's own path | This manual adds |
| --- | --- | --- |
| A log field renamed | Trivial: edit it yourself, no BMAD | A spec update, if the field is in it |
| The wheelchair flag | One session: Build | The slice's bar, if a model call is touched |
| The voucher within a cap | Epic: a spec, three stories, a Build each | The cap in the authority budget |
| The agent across three teams, audited | Project: the six documents, the five sign-offs | A bar per slice; the trail kept for the auditor |
For one team, spec-driven development and the gates usually suffice; add BMAD's document trail when the
work crosses teams or an auditor reads it. [How much process a change needs](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/how-much-process-does-a-change-need/).
## Extended BMAD: one more hand-off, after launch
BMAD's learn step is the epic's retrospective, and nothing in it watches production. This manual carries
the trail into Run & Learn and calls it **extended BMAD**.
| Hand-off | Who writes it | To |
| --- | --- | --- |
| The retrospective's verdict | The Developer agent | The next epic (BMAD's own) |
| The weekly drift report, slice by slice | The QA lead | The product manager |
| The two-number report | The product manager | The sponsor |
| The incident, as the next brief | The Analyst's brief skill | The next P0 |
The extension is this manual's own and is not part of BMAD as published.
## Why it matters
Prompt-driven AI development leaves decisions nobody can find. BMAD writes them down, and sizes the
ceremony to the change.
## Try it
Your team maintains a payments service. This week: (a) a cross-border payout feature that touches three
teams and is reviewed by compliance; (b) renaming a log field; (c) a retry on one timed-out partner
call. **Which BMAD path does each get?**
Show the answer
**(a) The project path:** three teams, and the five sign-offs become compliance's review points.
**(b) Trivial:** edit it yourself. **(c) One session with Build:** it is small, but a bug in a payment
retry could reach production.