BMad Method Has Three Flows Now. Here's What Actually Changes Between Them.

BMad Method now ships three separate paths from a described piece of work to reviewed, committed code: the full method, Quick Dev, and BMad Loop. The natural read is that these sit on a single speed dial, full ceremony at one end and something looser and faster at the other, with BMad Loop as the quick, careless option. That read is wrong: the axis that actually changes across the three is how much of the spec context expansion, implementation and reviewing you personally sit and watch, not how carefully the work gets planned or reviewed.

The full method is still the heaviest path, and for good reason. It runs a document all the way down: a PRD file, an architecture spine, an epics-and-stories breakdown, all written before a line of implementation code exists, with state tracked in a sprint-status.yaml that says which story comes next. Each story gets its own file, built by a skill that mines the PRD, the architecture doc, and the previous story for context before writing anything, and a person reviews the diff before the next story starts. That’s the right call whenever the shape of the work is still an open question: a new subsystem, a feature nobody on the team has scoped correctly yet, anything where finding out you were wrong should happen at the planning stage rather than three stories into the wrong direction.

Quick Dev exists for the case where you don’t want to run create-story, dev-story, and review-story as three separate manual steps for every piece of work. Full planning is still available if you want it: write a PRD, break it into epics, and hand Quick Dev a story straight out of that breakdown. What changes is that you don’t have to. Give it a story’s intent and it drafts its own implementation plan before writing any code; give it a plan you already wrote and it uses that instead. Anything whose failure would reach beyond the one change still stops once, at spec approval, before a line of code changes. For the genuinely trivial cases, a rename, a typo fix, a change where the codebase’s behavior isn’t actually in question (the kind of diff a senior engineer approves without really reading it), it skips even that checkpoint, runs its own adversarial review pass on the result, and patches, defers, or rejects whatever that review turns up before committing. The three-skill split still exists today, kept for compatibility, but it’s being folded into this single dev-agent shape for v7: one skill that plans and implements together turns out to work better than three that hand off between each other by hand.

BMad Loop is where the mechanism gets genuinely interesting: rather than being a third, separately built implementation sitting alongside the other two, it runs on bmad-dev-auto, a skill that sits right next to Quick Dev in BMad Method’s implementation folder and shares its spec format and its epic-context compiler line for line. The only structural difference between the two is that bmad-dev-auto has no approval checkpoint anywhere in it: it plans, implements, reviews, and finalizes in a single unattended pass, and instead of stopping to ask a person, it writes its status straight into the spec’s own frontmatter (draft, in-progress, in-review, done, blocked) so that something else can poll it. BMad Loop is that something else: an orchestrator, installed as its own module, that calls bmad-dev-auto once per story and supplies the parts a lone unattended skill can’t provide for itself.

What it supplies is real, and none of it is fixed. A gates.mode setting decides how far the leash actually extends: none runs a whole epic without a single stop, per-epic (the default) pauses between epics, and per-story-spec-approval puts a checkpoint back in front of every individual story, if that’s what a particular piece of work calls for. Whatever the loop can’t resolve on its own, a flaky test, a genuinely ambiguous requirement, a call that’s actually yours to make, gets caught by a deferred-work sweep that sorts every open item into what’s already been resolved, what can run as a follow-up batch, what’s blocked, and what needs you specifically. You can also run different models for different roles inside the same loop, one model writing the code, a different one doing the adversarial review, a third doing triage, set per stage in a policy file instead of hardcoded into the tool. None of it locks you to a single coding agent either; Claude, Codex, Gemini, and GitHub Copilot are all supported on day one.

Manufacturing already has a name for where this is headed: the dark factory, a production line automated enough that the lights can go off because no one needs to be on the floor. Software’s version of that shift moves a person from human-in-the-loop, required inside every cycle, to human-on-the-loop, supervising several cycles at once and stepping in only when one of them raises a hand. The quality bar stays where it was; only the vantage point moves. The gates.mode setting is that shift made concrete: dial it toward none per epic and you’ve moved yourself from inside the loop to above it, watching a fleet of them rather than running one.

Setting It Up

Getting from a defined epic to a running loop is short if Python, tmux, and a coding CLI are already on your machine; the module lists those as plain prerequisites rather than something it installs for you. Once BMad Loop is added through the BMAD Method installer, one skill invocation finishes the rest:

claude "/bmad-loop-setup accept all defaults"

That single command installs the orchestrator tool from Git, asks which coding CLIs you want it to drive, registers their hooks, and runs the same preflight bmad-loop validate runs on its own: config, sprint-status, git, the CLI binary, hook registration, and the multiplexer. tmux is that multiplexer, the only backend bmad-loop ships today for launching, attaching to, and driving a session, so if setup flags it missing, that’s the one thing worth installing yourself before trying again. Running the same skill later (/bmad-loop-setup upgrade) is also how you upgrade: it reinstalls the tool, re-lays the per-project skills, and reports the version change, so there’s rarely a reason to reach for the underlying uv commands by hand. Once sprint-status.yaml exists from BMad Method’s sprint planning, point the loop at an epic:

bmad-loop run --epic 2 --dry-run   # see the plan before anything runs
bmad-loop run --epic 2             # go
bmad-loop tui                      # watch or drive it from the dashboard

bmad-loop resume <run-id> picks a paused run back up, and bmad-loop status and bmad-loop list cover the rest of day-to-day operation.

Everything discussed so far, the gate mode, the deferred-work sweep, the per-role model adapters, is one section of a larger policy file. The rest is worth knowing exists even as a short list: retry and timeout limits per story, a token budget cap that stops a runaway story before it burns real money, git isolation settings that run each story in its own worktree and can roll back a failed in-place attempt automatically, and desktop or file-based notifications for anything that needs your attention. None of it needs tuning on day one; the knobs exist for when a specific project’s risk tolerance calls for something tighter or looser than the defaults.

Two things worth knowing before you start. bmad-loop is pre-1.0 (0.8.0 as of this writing), and its own changelog reserves the right to ship breaking changes in a minor release, so read the release notes when you upgrade rather than assuming it’s safe to skip ahead. Windows support today runs through WSL rather than natively: WSL is Linux as far as bmad-loop is concerned, so nothing about the setup above changes, but a native Windows backend is still on the roadmap, not shipped. Four coding agents are supported end to end right now, Claude, Codex, Gemini, and GitHub Copilot (the standalone CLI, not the VS Code extension), with more likely to follow.

All three paths end up writing to the same kind of artifact, a story or a spec, checked by the same adversarial review process, landing in the same repository structure. What you’re actually choosing, every time you reach for one of the three, is how much certainty you already have about the work and how much of the reviewing you want to do yourself before it ships. That’s worth deciding deliberately, per piece of work, rather than by habit. A team that reaches for the full method on a two-line bug fix is paying for planning it doesn’t need. A team that points BMad Loop at a genuinely unscoped feature is asking an unattended process to make product decisions nobody has actually made yet, which was never what the gate setting was for.

Reach for the full method when you don’t yet know the shape of what you’re building, for Quick Dev when you do and the plan would cost more than the code, and for BMad Loop once your specs are solid enough that you’d rather read the result of a finished epic than watch each story go by; set the gate to match how much you trust that particular epic, not how much you trust the tool in general.

BMad Method and bmad-loop are both free and open source: github.com/bmad-code-org/BMAD-METHOD and github.com/bmad-code-org/bmad-loop.