BMad Method Guide: A Virtual Agile Team of AI Agents

Most spec-driven tools hand you a pipeline: write a spec, plan, tasks, implement. BMad Method does something different — it doesn't give you a pipeline, it gives you a team. A virtual agile team of named, specialized AI agents — Analyst, Product Manager, UX designer, Architect, Dev, QA — each with a defined role, that plans and builds software end to end with human review gates between phases.

Created by Adam Blackington (BMad Code LLC), MIT-licensed, and at ~50k GitHub stars by mid-2026, BMad is the full-lifecycle entry in the spec-driven ecosystem: it's the closest thing to "hire an engineering org in npx". This guide walks through how it works, where it shines, and where it's overkill.

The mental model: scale-adaptive intelligence

BMad's core concept is that the amount of process should adapt to the size of the task. It runs in three complexity-adaptive tracks:

| Track | Use it for | What runs | |---|---|---| | Quick Flow | Bug fixes, small tweaks | A lean single-agent loop | | Standard Flow | Features and normal sprints | The full planning team + dev + QA | | Enterprise Flow | Large systems, regulated work | Everything, with formal gates and reviews |

Install it with npx bmad-method install (Node.js 20+). The current major version is v6, released and iterating through 2026.

Phase 1: Agentic planning — the team builds the spec

The first phase is where BMad earns its reputation. A chain of specialist agents produces the planning artifacts:

1. Analyst Agent — explores the problem space, gathers context, and produces a Project Brief.
2. PM Agent — turns the brief into a Product Requirements Document (PRD) with MoSCoW requirements (Must/Should/Could/Won't), epics, and Gherkin acceptance criteria — the Given/When/Then format that is both human-readable and executable by tests.
3. UX Agent — produces a UX spec for anything user-facing.
4. Architect Agent — writes ARCHITECTURE.md: DB schema, API design, component boundaries.
5. Product Owner validation gate — a human (or the orchestrator) approves or sends it back before anything is built.

The output is a genuine spec stack: PRD + UX spec + architecture — the same artifacts a real team would produce, generated in minutes.

Phase 2: Context-engineered development — the team builds the code

With the spec stack approved, BMad switches to execution:

1. Scrum Master Agent breaks epics into "hyper-detailed" story files — small, unambiguous work items.
2. Dev Agent implements each story in its own dedicated branch.
3. QA Agent runs checks against the acceptance criteria.
4. Multi-agent PR review — the reviewer isn't your only human; the AI reviewers are adversarial by design (see below).

The story files carry the full context from planning, so the Dev Agent isn't guessing at requirements — it's executing a contract.

The signature feature: adversarial review

BMad's review process is built to fail loudly rather than rubber-stamp. The reviewer agent is instructed to find issues — and if it finds zero, that itself triggers re-analysis (a design where "nothing to flag" is suspicious). Findings are tagged HIGH / MEDIUM / LOW, and the implementation loop continues until the review passes.

This is a genuinely different posture from most tools, where review is "check the diff" — in BMad, review is a dedicated adversarial role with an incentive to find problems. It's the same philosophy that drives the review gates in Superpowers, but implemented as a named team member rather than a skill.

BMad vs. the spec-driven alternatives

| | BMad Method | GitHub Spec Kit | OpenSpec | |---|---|---|---| | Model | Virtual team of specialist agents | Artifact pipeline (constitution→spec→plan→tasks) | Lightweight delta-spec engine | | Planning depth | PRD + UX + architecture, MoSCoW + Gherkin | Spec + plan + research + contracts | Change-level delta specs | | Adversarial review | Built-in, mandatory, zero-findings triggers re-analysis | None (constitution compliance gates only) | None | | Gate strictness | Formal gates (e.g., Implementation Readiness Check) | Phase gates in the full path | Minimal, free looping | | Learning curve | Steep (agile concepts, many roles) | Moderate | Low (~5 min) | | Best for | Greenfield products, complex projects, traceability | Teams standardizing on one workflow | Brownfield iteration speed |

The full decision matrix is in our Spec Kit vs OpenSpec vs BMad comparison.

Where BMad shines — and where it's too much

Use BMad when:

• You're building a new product and want AI involved at every stage from idea to deployment.
• You need traceability: PRD → stories → branches → reviews as an auditable chain.
• Your failure mode is "agents skip requirements" — the Gherkin acceptance criteria and QA gate exist precisely to catch that.
• You want structured adversarial review without building the process yourself.

Avoid BMad when:

• You're fixing a bug or shipping a small feature — the Quick Flow exists, but the tool's gravity is toward ceremony. One reviewer's summary: "killing a fly with a sledgehammer."
• You're a solo dev who wants zero concepts to learn. specdd or OpenSpec is a better fit.
• You need the spec itself to be the source of truth in a specific, standard format — Spec Kit gives you that contract; BMad gives you a process.

Getting started

npx bmad-method install

Then run the planning phase on a real feature and read what the team produces — the PRD and architecture are worth reading even if you never adopt the full loop. For the big picture of where BMad fits in the ecosystem, see the complete spec-driven coding guide, and for the debate about whether specs should be scaffolding or truth, the spec-driven vs vibe coding comparison.