BMAD-METHOD: An Agile Workflow Layer for AI Coding Agents

What BMAD-METHOD Actually Solves

The problem is not code generation. Coding assistants write functions well. The problem is that they write the wrong ones, because the assumption behind a request was never stated out loud. The README puts it plainly: assistants "often turn unstated assumptions into code." BMAD-METHOD is a response to that, and it targets people who are already using an AI coding tool and are tired of re-explaining the same product decisions in every new chat.

It is aimed at two groups. The first is someone starting from nothing who wants a weekend prototype to stay coherent as it grows. The second is someone dropped into an inherited codebase who needs to establish what is actually there before touching it. The repository ships a dedicated how-to page for that second case, which tells you the maintainers consider it a first-class path rather than an afterthought.

The method covers the whole effort, not just implementation: what to build, how it holds together, and how it changes as you learn. That scope is the differentiator. Most agent tooling stops at the editor boundary. This one claims to carry decisions forward as durable context, so the next session starts where the last one ended.

How the Agents, Workflows and Artifacts Fit Together

BMAD-METHOD is not a library you import. The repository tree is the product: the pyproject.toml states outright that the tree itself is what the plugin marketplaces install. There is no published Python package and no bundled runtime. What you get is a set of skills, workflows and agent definitions that your AI coding tool reads.

Each shipped script under skills/*/scripts declares its own dependencies inline using PEP 723, so `uv run` resolves them without any central dependency file. The pyproject.toml at the root is development tooling only and pins version 0. The release version lives in skills/*/module-manifest.toml. That split matters when you upgrade: the version you care about is not in the file most people open first.

The workflow model is right-sizing. Small, clear changes go straight to implementation. Larger initiatives pull in deeper planning, and the README lists the perspectives available: product, architecture, UX, development and testing. The entry point is a skill called bmad-build, which you invoke with a description of what you want to change. A second skill, bmad-help, answers questions about what comes next and what is optional. The outputs are artifacts you can keep: briefs, specifications and architecture documents. Those are portable. The README explicitly says you can carry them into an existing delivery workflow instead of running BMAD end to end.

Installing BMAD-METHOD and Running a First Change

The README lists three prerequisites: Node.js 20.12 or newer, Python 3.10 or newer, and uv. Install uv first if it is missing, because the shipped scripts rely on it to resolve their inline dependencies.

npx bmad-method install

That single command is the documented install path. It writes the skills and workflows into your project. The README does not describe a global install or a system-wide binary, so treat this as a per-project operation.

Once the installer finishes, open the project in your AI coding tool. Then invoke the build skill with a plain description of the change.

bmad-build

What you should see is the agent working through the change rather than jumping to a diff. For a small, clear request the README says the process goes directly to implementation. If you are unsure what the next step is, or which steps are optional, the help skill is the documented escape hatch.

bmad-help

The README also points to a web-bundles route: selected workflows are packaged as Google Gemini Gems and ChatGPT Custom GPTs at bmadcode.com/web-bundles. That lets you do the planning inside a web subscription and then bring the resulting artifacts into your coding tool for implementation. The README does not state which specific workflows are bundled, so check the page before assuming a given one is available.

Where the Method Breaks Down

The prerequisite chain is the first real cost. You need Node.js, Python and uv present before the installer will do anything useful. On a locked-down corporate machine where you cannot add a Python toolchain, that is the end of the evaluation. The README does not offer an alternative install path for that situation.

The second limitation is structural. BMAD-METHOD assumes an AI coding tool that can invoke skills by name. The README never enumerates which tools qualify. Search interest around Cursor, Claude Code, Codex and Antigravity is high, but the README itself does not confirm support for any of them by name, so treat tool compatibility as something you verify locally rather than something the documentation promises.

The third is that the method is deliberately heavier than a chat prompt. Every workflow step is a decision you are asked to make and an artifact you are asked to keep. For a one-line fix in a file you understand, that overhead is pure cost. The README's own framing supports this: small changes go straight to build, and the depth only appears when the work is complex. If most of your work is small, you are paying for a structure you will not use.

Finally, the repository does not document rollback or uninstall. There is an Upgrade to V6 page, but nothing in the README describes cleanly reversing the installer's changes. Plan for that before you run it on a repository you care about.

BMAD-METHOD Compared with Plain Prompting and Spec Kit Style Tools

The honest alternative is your existing chat window. You describe the change, the assistant writes it, you review the diff. The difference in approach is where the decisions live. In a chat, the reasoning behind a choice exists only in that thread's context, and it evaporates. BMAD-METHOD externalizes it: briefs, specifications and architecture documents persist as files, and agents read them on the next pass. That is the whole trade. You spend time writing down what you already decided, and you get continuity back.

The second alternative is a specification-first toolchain in the style of GitHub's Spec Kit, where a written spec is the source of truth and the implementation follows from it. The difference is scope. A spec-first tool centres on one artifact type and one flow. BMAD-METHOD ships a menu of perspectives (product, architecture, UX, development, testing) and a workflow map with several entry points, plus optional modules for testing, game development, creative work and unattended epic execution. More surface area, more to learn, more places for the process to feel heavier than the work.

There is also a narrower option worth naming: doing nothing but writing better prompts. If your team already keeps design notes in the repository and your assistant reads them, BMAD-METHOD duplicates machinery you have. The README's claim that context is durable is only valuable if context was previously being lost.

Maintenance, Upgrades and the MIT Licence

The last push to the default branch was on 2026-08-10, the same day as the v6.11.0 release. Before that, v6.10.0 landed on 2026-07-03 and v6.9.0 on 2026-06-22. That is a steady release cadence across the summer, and the repository is not archived.

The upgrade cost is the part worth budgeting. The README links a dedicated Upgrade to V6 page for migrating from an earlier version, which implies the move to V6 was not drop-in. Because the release version lives in skills/*/module-manifest.toml rather than in pyproject.toml, an upgrade script that inspects the root Python metadata will read version 0 and conclude nothing has changed. Check the manifest files instead.

Licensing is MIT, per the README and the LICENSE file. That is permissive: you can use, modify and redistribute it, including commercially. Two caveats sit alongside it. The README states that BMad and BMAD-METHOD are trademarks of BMad Code, LLC, with details in TRADEMARK.md, so the licence covers the code and not the name. And the project asks for contributions to go through CONTRIBUTING.md first. None of this is legal advice; read LICENSE and TRADEMARK.md yourself if you plan to redistribute or rebrand.

Editorial conclusion

Adopt BMAD-METHOD if you already drive an AI coding assistant and keep losing decisions between sessions, or if you are inheriting a codebase and need verified context before changing it. Skip it for single-file fixes and throwaway scripts, where the installer plus the workflow overhead costs more than the change itself. Before committing, verify three things: that Node.js is at 20.12 or newer, that Python is at 3.10 or newer with uv present, and that your coding tool can invoke a skill named bmad-build. Then read the Upgrade to V6 page and confirm which module-manifest.toml version your install actually wrote.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes