What is the BMAD Method? Five agents, one Build loop

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.

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#

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.

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.

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.

Key takeaways#

1. BMAD is skills in your coding tool: five named agents and one Build loop.
2. Each skill writes a document the next one reads, so decisions stay explicit.
3. It sizes itself: use the full trail where people must agree or an auditor reads it, never because "we are a BMAD shop".

FAQ#

What does BMAD stand for?#

The Breakthrough Method of Agile AI-Driven Development. Brian Madison created it; BMad Code publishes it under the MIT licence.

What are the BMAD agents?#

Five in v6.12.1: the Analyst (Mary), the Product Manager (John), the UX Designer (Sally), the Architect (Winston) and the Developer (Amelia). The scrum master, QA and quick-flow agents of earlier releases were merged into the Developer in April 2026.

BMAD vs spec-driven development: which should I use?#

They overlap: BMAD now has a five-field spec that Build reads. Use spec-driven development on every change, and add BMAD's document trail on multi-team or audited work.

What is extended BMAD?#

This manual's name for BMAD carried past launch, with three more hand-offs: the weekly drift report, the two-number report, and the incident as the next brief.

Does BMAD work with Claude Code or Cursor?#

Yes: it installs into .claude/skills/ for Claude Code and .agents/skills/ for Cursor. On 8 October 2026 its docs site already described the next version, with a ticket skill in place of sprint planning: check which version you installed.

Apply it in your role#

Across the enterprise. Its five sign-offs leave the audit trail regulated work needs; small changes still go straight to Build.

The ten-minute workflow. Ask for the two decisions the method does not ask for, before the spine:

Run bmad-architecture on this spec: <paste>. Before you draft the spine, ask me, one question at a
time, for two decisions the method does not ask for: the authority budget (each tool the agent may
call, what it may do, its cap, where the cap is enforced) and the bar per slice (for each kind of
case, the damage of a wrong answer, the saving of a right one, the pass mark). Never guess a cap or
a pass mark: leave it blank and ask. Output: the spine, with these as decisions with stable IDs,
then a table of every tool that still has no cap.

Sources and credits#