There was a sixth, Paige the technical writer - she was retired in release 6.11.0 and is promised back as a separate installable agent. Her project-context function did not disappear; it moved to the analyst.

The point of the personas is not decoration. The README's core claim: coding assistants are effective at implementation, but they regularly turn unstated assumptions into code. The BMAD agents exist so the important decisions get said out loud and preserved as context for the work that follows.

Four Phases

Planning is laid out in phases, and each produces documents that become the context for the next one.

The first phase is entirely optional. More than that, you can start anywhere: clear work enters phase four directly.

Two individual skills deserve a mention. bmad-forge-idea pressure-tests an idea until it hardens, proves out, or dies cheaply. And bmad-spec produces a machine contract of five fields - why, capabilities, constraints, non-goals, success signal - and it is the only skill allowed to write SPEC.md; the others invoke it headless when they need to express or update intent.

Everything Converges on bmad-build

Phase four is a single chain: sprint planning, build, code review. And bmad-build accepts anything - free-form intent, a link to a tracker issue, a specification, or a fully planned story. It then decides for itself how much clarification, planning and review that particular input needs.

The reasoning is stated in the documentation without ornament: human-in-the-loop turns are necessary and expensive. Models fail in predictable ways - they misread intent, fill gaps with confident guesses, drift into unrelated work, generate noisy review output. But constant human intervention makes the human the speed limit. The direct quote: human attention is the bottleneck.

bmad-build rebalances that tradeoff. It lets the model run unsupervised for longer, but only after building a boundary strong enough to make that safe. Human control does not disappear; it relocates to a few expensive moments: clarifying intent, approving the spec, and reviewing the finished result.

The failure-diagnosis logic from the same page is worth copying down: if the implementation is wrong because the intent was wrong, patching the code is pointless. If the code is wrong because the spec was weak, patching the diff is also pointless. The job is to work out which layer the failure entered through, go back there, and regenerate from that point. Only what is genuinely local gets patched locally.

Review noise is handled separately. Agentic reviews usually go wrong in two ways: too many findings, and dragging the current task into an unrelated cleanup. BMAD treats review as triage: a finding not causally tied to the current work is deferred rather than dumped on the human immediately. The authors admit outright that the triage will sometimes be wrong and consider that acceptable - the system optimises for signal quality, not exhaustive recall.

Installation

You need Node.js 20.12 or later, Python 3.10 or later, and uv.

The interactive install asks six things: the directory, the module set, whether to take the latest stable release of everything, which tools to integrate with, per-module config, and whether you want the deprecated compatibility shim skills.

For CI the same thing happens through flags:

--tools is required for a fresh install with --yes, and --list-tools prints the valid values. Module settings are set through a repeatable --set, and --list-options prints every available key:

Prerelease builds install under a separate tag:

The installer puts two directories into the project: _bmad/ with agents, workflows, tasks and configuration, and _bmad-output/ for artifacts.

The First Run

The tutorial walks through the Mars Rover kata in an empty directory - a small exercise that shows how bmad-build behaves.

Then you launch your agent and talk to it in one sentence:

The phrasing deliberately leaves room, and the skill opens with a question - which language, for instance. You answer, read the plan it proposes, approve it or ask for changes. After that the skill writes the program, checks its own work, fixes what it finds, and shows you what changed.

A separate skill exists for working out what happened and what to do next:

It inspects the project state, understands questions in plain language, and recommends the next step based on which modules you have installed.

Skills and Menu Triggers

There are two ways to start work, and they differ in intent.

A skill is invoked by name right in your environment - bmad-help, bmad-prd, bmad-build. It immediately loads an agent, runs a workflow or executes a task. That is convenient when you know what you want.

A menu trigger requires loading an agent first and then typing a short code: PRD for the product manager, CA for the architect, BD for the developer. The agent interprets the code and starts the matching workflow while staying in character. That is convenient when you are already working with an agent and would rather not leave the conversation.

The skill files themselves are generated by the installer from the manifests of the selected modules - one per agent, workflow, task and tool. Each skill is a directory containing a SKILL.md, and they land per environment: Claude Code gets .claude/skills/, Cursor and Windsurf get .agents/skills/.

What Happened in Version 6.11

This is the largest release in recent memory, and without it the picture does not add up: half the commands you will meet in older guides now work only through forwarding shims.

Implementation collapsed into one path. bmad-quick-dev became bmad-build, bmad-dev-auto became bmad-build-auto, and the bmad-create-story / bmad-dev-story pair was deprecated. Amelia the developer's menu code changed from QD to BD.

The core skill catalog shrank almost by half - from fourteen to eight. Three review skills and two editorial ones merged into a single bmad-review, where the previous behaviour became configurable lenses. Three research skills became one bmad-deep-recon with six research types. And bmad-document-project plus bmad-generate-project-context became bmad-project-context.

Not a single old identifier broke in the process: every retired skill is kept as a forwarding shim in the v6-shims directory and still runs when invoked by name, right up to the v7 cut. There are fourteen such shims at the moment. On a fresh install they are not added by default, but the question is asked, and on an update the installer lists every one that remains along with what it forwards to.

By volume the release was subtractive: across 560 files touched, it deletes about 1,900 more lines than it adds.

Modules

The core and the main module install together; everything else is opt-in.

Each external module installs on one of three channels: stable, prerelease, or pinned to a specific tag. This is driven by --channel, --next=<code> and --pin <code>=<tag>, and their precedence runs in reverse order - pinning wins.

An important detail about updates: patch and minor versions apply automatically, while majors are frozen by default, because breaking changes usually surface as unexpected instability. To accept a major upgrade non-interactively you have to name the tag explicitly.

Existing Code

There is a separate entry point for someone else's codebase, and the approach there is unusual.

bmad-project-context does not generate a mountain of documentation. It reads what you already have, tells you how it measures up, asks which rules to follow, and works out the rest itself - running every command before writing it down as fact. The result is one small verified block inside your AGENTS.md.

The admission rule for that block is one test: anything derivable from source is read live and never stored. So the line pnpm test does not go in, while "the suite takes eleven minutes" does.

The skill shows every write before making it, runs standalone with no BMAD install, and fires only when you name it - it never routes on inferred intent.

What to Know in Advance

uv is now mandatory. Since 6.11.0 this is a hard requirement for rendered skills with no interpreter fallback: bmad-build and bmad-build-auto simply halt if uv is unavailable. Python has to be 3.11 or later for those, even though the README names 3.10 as the general requirement.

The installer does not delete old skills. This is stated in plain words: the files of a removed module stay where they are. The fix is deleting the stale directories, or the whole skills directory, then re-running the installer.

After adding or removing a module the installer has to be run again, or the skill set drifts away from the module set.

Configuration moved to layered TOML, and the renderer no longer forgives mistakes. A missing key used to render as an empty string, and an unparseable override file used to be silently ignored. Both are now a clean halt with an error code.

The numbers from older write-ups cannot be checked. The README used to promise twelve-plus specialists and thirty-four-plus workflows; those figures are gone from it entirely. In fact the main module has five agents, the core has eight tools, and the workflow map lists fifteen named entries plus fourteen shims.

MIT licence, but the name is protected. BMad, BMad Method and BMad Core are trademarks of BMad Code, LLC in every casing. That does not affect the code; it does affect what you may call your fork.