BMAD Method · BMad Code, LLC (Brian Madison) · as of September 30, 2026

BMAD Method never edits its spec. It rebuilds it.

Every decision goes into a log that only grows, and the spec is rebuilt from that log. That is how a PRD, a UX design and an architecture can each feed one contract, in whatever order you write them, without the documents drifting apart.

This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.

Two philosophies at a glance

BMAD Method

Keep the thinking yours, make the important decisions explicit, and write down only as much as the work needs, around one living spec.

The Enso Method

Keep the requirements as the source of truth for the life of the system, and keep building on recorded assumptions while the people who decide confirm them.

Where they differ

Specs serve one change Specs live as long as the system BMAD Method sits in the middle; the Enso Method sits at the “Specs live as long as the system” end.
Stops and asks Decides, records it, keeps going BMAD Method sits toward “Stops and asks”; the Enso Method sits at the “Decides, records it, keeps going” end.
The developer at the keyboard decides Someone who isn’t at the keyboard decides BMAD Method sits toward “The developer at the keyboard decides”; the Enso Method sits at the “Someone who isn’t at the keyboard decides” end.
Builds what is asked Challenges what to build BMAD Method sits toward “Challenges what to build”; the Enso Method sits toward “Builds what is asked”.

What they share

Starts from a prompt Intent written down first BMAD Method sits at the “Intent written down first” end; the Enso Method sits at the “Intent written down first” end.
Light, few gates Heavy: roles and approvals BMAD Method sits in the middle; the Enso Method sits in the middle.

Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.

Keep the thinking, and size the process to the work

“Turn an idea or change request into working software without giving up the thinking.” That is BMAD’s promise, and its README names the risk it guards against: coding assistants “often turn unstated assumptions into code.”

So BMAD makes the important decisions explicit and keeps you making them. Its PRD, UX and architecture skills coach by default rather than write for you; the PRD skill tells the agent to “fight the urge to do the thinking for them” unless you choose its fast path. And the process sizes itself: “Small changes go straight to build. Complex work gets the depth it needs.”

The spec holds it together. It is the hub: a short contract of why, capabilities, constraints, non-goals and a success signal. Nobody edits it by hand. Its decisions are appended to a log and the spec is rebuilt from the log, so the planning skills can run in any order, before or after the spec exists.

Start anywhere; every path uses the same build

Think, if you need to. Brainstorm, pressure-test the idea, write a press release for the finished product, research the market. All optional.
Spec. bmad-spec distills whatever you have into the contract every build reads.
Slice. bmad-ticket turns work bigger than one session into an epic of stories in build order, starting with a thin end-to-end “tracer bullet”.
Build. One story per fresh chat: bmad-build investigates the code, plans, implements, has it reviewed and commits locally.
Look back. A retrospective judges the finished epic against its own definition of done.

Your part is answering its questions and approving plans. In the build guide’s words: “Approve the plan when it describes the right thing to build. Push back if it does not — fixing the plan is cheaper than fixing the code.”

One method from a weekend prototype to a long-lived system

BMAD fits someone whose work runs from small fixes to multi-epic products and who wants one method for all of it, with the product thinking kept in their own hands. Teams can use it too: each document has one owner, and stories can publish to Jira or GitHub.

It asks for conversation time in planning, and review takes time and tokens: its own help says a thorough code review “can take half an hour or more”; the build’s default is now a single quick reviewer. It needs a coding tool that supports skills, plus uv, a Python package manager.

It suits you less if you want the agent to settle open questions and keep going while you’re away: its unattended builder stops at any gap in intent, by design.

Where the Enso Method made a different call

They share a lot: both write intent down before code, give requirements stable IDs, keep later work as outlines until its turn, size each build to one session, and check the code before asking you anything it could find there. They part ways on three things.

What the documents are for

BMAD Method

Documents are written when the stakes call for them, to serve the work under way; a small change goes straight to a build. Once the work ships, the code is the record, and its docs advise archiving the PRD “out of reach of an ordinary change”.

The Enso Method

The requirements and design stay the source of truth; any change to what the system should do, however small, amends them first.

Choose by situation: BMAD’s way keeps paperwork and agents’ context small. The Enso Method’s takes upkeep, and pays off when someone asks, years later, what the system is supposed to do.

When the intent leaves something out

BMAD Method

You answer. A build stops at each gap, and once you approve a larger change’s plan, only you can change its intent.

The Enso Method

It proposes the best-supported answer, records it with a confidence level, and keeps building.

Choose by situation: if you decide, BMAD won’t build on a guess about what you meant. If the people who decide aren’t in the chat, the Enso Method keeps the work moving.

Whether to build it at all

BMAD Method

It can put the idea on trial first: a press release for the finished product, then the hardest questions customers would ask.

The Enso Method

It starts from what the people who decide want, and puts their open questions to them.

Choose by situation: if you’re unsure the idea deserves building, BMAD helps you test it. If someone else has decided, the Enso Method starts from there.

Where BMAD Method shines

Review that doubts its own plan. On the thorough setting, four independent reviewers check each change, one reading the plan only at the end, as “testimony, not evidence”. A flaw traced to the plan means amending the plan and rebuilding.
A retrospective across the whole epic. It hunts for what no single session could see, like duplication and files that quietly grew huge, citing a source for every finding. The Enso Method has no equivalent yet.
Agent instructions that stay small and true. A short, verified rule block in AGENTS.md gains a line when agents repeat a costly mistake, and an audit never leaves it longer.
Reach: plugins for Claude Code and Codex, planning bundles for ChatGPT and Gemini, and a large community.

How the Enso Method differs, and why

BMAD Method writes down only as much as each piece of work needs and, once the work ships, treats the code as the record, while the product decisions stay with the person building. The Enso Method keeps its requirements as the system’s source of truth, amended before every change, and when they leave something open it proposes an answer and keeps building while the people who decide confirm it.

How the Enso Method works Compare all the methods

Get started

BMAD Method is free and open source (MIT; the name is a trademark of BMad Code, LLC), and its install instructions are in the README at github.com/bmad-code-org/BMAD-METHOD. This page describes the main branch, which npx skills add installs; the npm installer (v6.12.0) still plans with an epics file and sprint tracking.