BMad Method

Turn intent into enterprise-ready software.

BMad is an open-source, customizable set of agents and workflows built on agile practice. Clarify the work, approve the plan, build it, and verify the result.

v6.12.0

Get started$npx bmad-method install

Community snapshot · live from npm and GitHub

52,865GitHub stars5,980 forks
45+Supported AI coding toolsClaude Code, Codex, Cursor, Copilot and more
80,992npm installs / 30 days11 Aug to 9 Sept
MITLicenseCommercial use. Your changes stay yours.

The philosophy

The method is a philosophy.
The product is how it is practised.

Everything on this page - the phases, the agents, the artifacts, the gate - exists to carry one argument: AI is the facilitator and the human is the expert. The spec is the work, agile evolved rather than being abandoned, and the rigour should match the work in front of you.

Read the philosophy

A whole leaf skeleton, every vein intact, a single point on the midrib picked out in blue — **The structure that remains**

01 The problem

AI assistants turn unstated assumptions into code.

They are effective at implementation. What they cannot do is notice the decision nobody made: the compliance constraint never written down, the non-goal that was assumed, the interface contract that lived in someone's head.

BMad makes those decisions explicit before implementation starts, and preserves them as durable context for the work that follows.

Planes of a system, one constraint left unlit between them — Fig. 2 / **The unstated constraint**Never written down

02 How it works

Four phases. You enter where the work starts.

Enter at Analysis, Plan, or Implement according to how much is known. Verification closes the loop. Rigor scales to the work, not the org chart.

Two routes bending into a single convergence point — Fig. 3 / **Every path converges**Routing is mechanical

Phase 1 · optional

Analysis

Explore the problem space and validate the idea before committing to a plan.

Phase 2

Plan

Define what to build, for whom, and how it holds together: requirements, UX, architecture, epics and stories.

Phase 3

Implement

Every path converges on one workflow. Planning artifacts add context; they never select a different path.

Phase 4

Verification

Discharge what the spec promised. Review, tests mapped back to requirements, a retrospective that feeds the next plan.

03 The agents

Named agents, each anchored to a phase.

Bring in product, architecture, UX, development, and testing expertise when it helps. Agents hand work off through files, not chat history, and teams can extend the roster.

BA-01Analysis

Mary

Business Analyst

Brainstorming, research, and the project context everything downstream inherits.

PM-02Plan

John

Product Manager

Requirements, epics and stories, and the readiness gate into implementation.

UX-03Plan

Sally

UX Designer

The design spine pair, so experience decisions are recorded rather than assumed.

SA-04Plan

Winston

System Architect

Architecture decisions with stable numbers that epics inherit as binding constraints.

SE-05Implement · Verification

Amelia

Senior Software Engineer

Specs, code, tests, review and retrospectives, across both sides of the implementation boundary.

TA-06Add-on module

Murat

Master Test Architect

Test-to-requirement traceability and risk prioritization. Ships in the Test Architect module.

04 What it leaves behind

Decisions become files in your repository.

Every artifact is plain text, version-controlled beside your code, reviewable in a pull request, and inheritable by whoever picks the work up next. There is no BMad-hosted storage of any kind.

Stacked planes threaded by a single continuous line — Fig. 4 / **Durable planes**Version-controlled beside your code

The kernel

A five-field spec

Why, Capabilities, Constraints, Non-goals, Success signal. Derived from the plan and never hand-edited, so it cannot drift from what was agreed.

SPEC.md

The record

An append-only log

Every decision, constraint, assumption and open question, one line each, in the order it happened. Never edited, never reordered.

.memlog.md

The trail

Traceable both ways

Capabilities and architecture decisions carry stable identifiers, so a requirement can be followed forward into a diff and back again. Orphans are flagged in both directions.

CAP-N · AD numbers

05 Governance and control

No runtime service. No telemetry. No new data path.

BMad installs markdown and configuration into your repository, then your approved coding tool executes it. No BMad runtime ever sees your code, prompts, or data.

Data path

Nothing phones home

No telemetry, no analytics, no account, no runtime service. Outbound calls happen at install time only: the npm registry for a version lookup, the GitHub API to resolve release tags, and git against the remote you named if you install an external module.

Audited as of v6.12.0

Residency

Everything stays in the repo

Artifacts, configuration and skills are all version-controlled alongside your code. Nothing is stored anywhere else, because there is nowhere else.

No BMad-hosted storage

Control point

A gate into implementation

Before any sprint tracking exists, one adversarial question: could a developer implement these epics without inventing decisions nothing records? Gaps are listed with where each one lives.

PASS · CONCERNS · FAIL

Auditability

Reviewable before it runs

Every skill is a markdown file in your repository. What an agent is going to do can be read, diffed and approved in a pull request before anyone runs it.

Plain text, in your VCS

06 Make it yours

Customization and modularity, without forking.

Install only the modules you need. Team and personal overrides live outside installed skills, survive updates, and avoid forks.

Six modules arranged as linked blocks, two of them dark — Fig. 5 / **The module array**Install only what you need

Modularity

Install what you need

Core and BMad Method ship with the installer. Test Architect, Builder, Creative Intelligence and Loop are separate repositories, resolved at install time and pinnable to an explicit version for CI.

6 modules · --pin bmb=v1.7.0

Precedence

Three override layers

Personal preferences beat team settings beat the defaults a skill ships with. Personal files are gitignored; team files are committed and inherited by every engineer who pulls the repo.

_bmad/custom/

Org standards

Your conventions, carried

Required fields on an artifact, your own PRD template pinned org-wide, an internal compliance reference the workflow consults before drafting. Injected as persistent context at the step where it matters, rather than left to whoever remembers.

additional_sections · external_sources

Deliberate limit

Overrides cannot delete

You can add and replace, but there is no removal mechanism. That stops a local override from quietly stripping a step somebody else relies on.

No silent subtraction

Get started

Install it into one repository and run a single change through it.

Node.js 20.12+, uv, and Git for external modules. Nothing to procure, nothing to provision, nothing to sign.

Read the docs View source

$ npx bmad-method install