BMAD keeps decisions in files across four delivery phases
BMAD-METHOD is for developers who like AI coding but dislike how quickly a chat forgets the reason behind a change. Its workflows create artifacts that carry product intent, UX decisions, architecture, stories, and implementation context forward. The method has 4 phases: optional analysis, planning, solutioning, and implementation. You can enter at bmad-build for a clear fix or use the earlier phases for a larger project. That adjustable depth is the project's best idea.
Installation adds named skills, shared configuration, and supporting scripts to a target repository. bmad-help reads the installed modules and suggests the next available workflow. For an existing codebase, bmad-project-context builds a verified block in AGENTS.md from repository evidence and team rules. This gives agents a durable operating brief without asking every developer to paste the same background into each session.
One build path replaces several v6 workflows
Release v6.11.0 makes bmad-build the official implementation path. Clear work can start there, while PRDs, UX material, architecture, epics, and sprint planning remain optional context for bigger changes. The release also reduces the core catalog from 14 skills to 8, combines several review modes behind bmad-review, and consolidates three research skills into bmad-deep-recon. Old names mostly continue through forwarding shims until v7.
That cleanup has a cost for existing users. Customization files for renamed skills must move, some skills were removed, and layered TOML configuration is replacing older behavior. The release notes are candid about these changes, including cases where legacy customization can halt an unattended run. A team adopting BMAD should pin a version, review release notes before updating, and treat _bmad changes like a framework migration rather than a harmless prompt refresh.
What happened when we ran it
Our sandbox cloned commit 11bfd36 into a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. The npm install succeeded in 26 seconds, adding 786 packages and consuming 346 MB on disk. The checkout itself contained 597 files, about 37,856 lines of source, and occupied 6.5 MB. No build script or target existed, so there was no build step to run.
The test command failed with exit code 1 after 21 seconds. Its final output listed installation component suites 43 through 52, then ended with Some installation component tests failed. Those lines do not identify a failing assertion or a cause, so we cannot tell whether the problem is the code, a missing system dependency, or our container environment. The defensible finding is simple: the checked-out commit did not pass its own tests under the stated conditions.
Npm audit reported 10 known vulnerabilities in the installed tree: 0 critical, 8 high, 1 moderate, and 1 low. The repository has 5 CI workflow files and a tests directory, which shows that maintainers have automated checks, but our result still matters to an adopter. There is no Dockerfile to define a known container environment. Before adding BMAD to a company repository, reproduce the test failure and inspect the audit paths rather than accepting 786 dependencies on trust.
The installer can finish before the build skills are usable
The short command is npx bmad-method install, yet the useful path has more prerequisites than that line suggests. Node.js 20.12 or later runs the installer. The main README also lists Python 3.10+ and uv. The detailed guide sharpens the warning: installation can finish without uv, while bmad-build and bmad-build-auto cannot run their Python-backed rendering without it. A green installer summary therefore does not prove that the main implementation skills are ready.
You also need a supported AI coding tool. The installer can list current tool IDs and has a headless example for Claude Code. Core BMAD does not require a hosted BMAD credential, though your chosen assistant has its own account and model setup. Git becomes another prerequisite when external or custom modules are involved. For CI, containers, or locked-down workstations, capture Node, Python, uv, and tool integration in your own bootstrap script.
Open v6.11.0 reports make unattended review a risky choice
BMAD's review design sounds careful: implementation can fan out to adversarial, edge-case, and verification-gap reviewers, then triage their findings. Issue 2772 provides a sobering real-project report. Across 9 stories and 21 triage passes, the reporter recorded 733 findings. Every pass that patched something recommended another review, and the default blind reviewer was instructed to find at least 10 items. That combination can spend time and tokens after useful findings have thinned out.
Issue 2760 identifies a related seam. It says bmad-build and bmad-code-review repeat 3 identical review layers when both run on the same diff, while the former leaves sprint status at review rather than done. We did not reproduce these open reports. They concern the advertised delivery path directly. Teams should begin with supervised runs, inspect the triage log, and decide which review skill owns the final pass.
Reference-heavy design contracts need an explicit override
Structured context only helps when the right material survives compression. Issue 2767 describes a case where epic compilation dropped references to DESIGN.md and EXPERIENCE.md. The implementing agent then missed visual rules because the source pointer had vanished. The reporter fixed that project by loading both files as persistent facts through a team override. If your requirements depend on source documents instead of repeated text, verify the compiled context before implementation.
Activity around those reports is healthy. GitHub showed 52,315 stars, a last push on August 26, 2026, and 128 open issues and pull requests combined. Release v6.11.0 was published on August 10, and current discussions contain specific reproductions rather than empty complaints. BMAD deserves a trial when process drift is costing the team real work. Its own 21-second test failure and the open review-loop reports argue for a controlled project first, with version pinning and human approval still in the loop.