Small qupaya logo Large qupaya logo
  • Blog
  • About
  • Careers
  • Book intro call
Book intro call
    • Guided Program The program at a glance
    • Guided AI Your permanent Engineering Guide
    • Guided Angular Specialized for Angular teams
    • Consulting
    • Software Engineering
    • AngularJS Migration
    • From Planning to Delivery
    • All Services →
  • Blog
  • About
  • Careers
  • Guided Program The program at a glance
  • Guided AI Your permanent Engineering Guide
  • Guided Angular Specialized for Angular teams

More Services

  • Consulting
  • Software Engineering
  • AngularJS Migration
  • From Planning to Delivery
  • All Services →

Blog

BMAD Completely Changes How You Install It, and That's Great News

The installer is on its way out, and plain skills take its place. Here is why we think that is the best decision the project has made in a while.

Markus Ende
·September 24, 2026·6 min read
AI-generated

If you use the BMAD Method with an AI coding assistant, you probably installed it like this:

npx bmad-method install

That command is going away. On the dev branch, BMAD no longer ships with its own installer. It is now a flat tree of skills that you add with the generic Skills CLI, or through a plugin marketplace in Claude Code or Codex:

npx skills add bmad-code-org/BMAD-METHOD

We think this is a good move. Here is what changed, and why.

What happened

The change landed on 5 September 2026 with PR #2768, “distribute BMAD as a flat skills tree via npx skills and plugin marketplaces” (merge commit 255c651). A few of the commits inside it tell the story:

  • 3018779 drops the installer entry point and its dependencies.
  • 3c12a07 drops the npm publish workflow.
  • 636f8e2 removes the publish script and the deprecated v6 shim skills.

The repository now has a skills/ folder with one directory per skill, each carrying its own instructions and a small manifest. The dev branch doesn’t even have a package.json any more. The Python tooling runs through uv, which is now a prerequisite.

What the installer used to do moved into a skill of its own. The new bmad hub skill has two commands. bmad setup creates what is missing and repairs what is stale, so you run it after the first install and after every update. bmad status only reads: it shows installed versions and what to run next. The updates themselves come from the channel you installed with: npx skills update, or your plugin marketplace.

There are three install routes now:

# Skills CLI, any tool that supports skills
npx skills add bmad-code-org/BMAD-METHOD

# Claude Code, inside a session
/plugin marketplace add bmad-code-org/bmad-plugins

# Codex, from the terminal
codex plugin marketplace add bmad-code-org/bmad-plugins

Why we like it

BMAD is one way to give AI-assisted development some structure, and it is not the only one. If your team works with AI assistants but without any framework yet, try one. The difference shows up quickly, in the code and in the reviews.

As for the move away from the installer, here is why we think it is the right one.

One format instead of one integration per tool. The old installer knew about each coding tool individually and wrote files into each one’s specific folder. Every new assistant meant new installer code, and the list of supported tools only ever grew. Skills are a shared format. A community tester confirmed the new tree works end-to-end in opencode without any BMAD-specific support for it.

It plugs into what teams already run. Many developers already use npx skills for skills from other sources, and so do we: we use it in several projects, and we also share our own internal skills across teams with it. So we benefit directly: BMAD is no longer a separate tool with its own installer, its own update routine and its own idea of where files go. It becomes one more source in a setup we already have. BMAD is also not breaking new ground here: Matt Pocock’s skills already ship exactly this way, through npx skills or a Claude Code plugin, with a setup skill you run once, just like bmad setup. npx skills list shows BMAD next to everything else, npx skills update updates it along with the rest, and project-scoped skills get committed with the repository like any other skill. Teams on Claude Code or Codex get the same through the plugin marketplace they already use. There is no separate installer version to keep in sync with the skills it installs, either.

You pick what you need. The installer thought in modules: you picked a module and got all of its skills. With the Skills CLI you choose individual skills. If all you want is bmad-build and the hub, that is all that lands in your project:

npx skills add bmad-code-org/BMAD-METHOD --skill bmad --skill bmod-core-tools --skill bmod-method --skill bmad-build

The repository is the release. Before, what you read on GitHub was source that the installer transformed into an installation. Now what you read is what you get. When a skill surprises you, you open the same file your agent is reading. For a tool whose whole job is steering an AI agent, that transparency matters.

A whole class of bugs disappears. As long as there are two ways to install something, there are two layouts on disk, and every skill has to work with both. BMAD ran into exactly that. Its skills called helper scripts under _bmad/scripts/, a folder that only the npm installer creates. Install the same skills through the plugin marketplace, and that folder simply isn’t there. The scripts never ran, and nobody noticed, because the skills fell back to a path that produced the same-looking output. When two installation paths produce two different layouts, one of them eventually rots quietly. Removing the second path is the honest fix.

What to keep in mind

This is not released yet. The latest release is still v6.12.0 from 4 September, which uses the old installer, and fixes for it continue on the V6.12 branch. The placeholder version on dev reads 6.13.0-next. In parallel, the maintainers are previewing a larger planning overhaul they call v7: a new “initiative” layout with tickets instead of epics.md and sprint-status.yaml, plus a v6-to-v7 migration for existing projects. Whether the new distribution ships as 6.13 or together with v7 has not been announced.

Some rough edges are still open:

  • The official add-on modules (Test Architect, Creative Intelligence Suite, Builder and others) still point to the old installer, so there is no documented way yet to add them to a core installed through the new routes (#2841).
  • The BMAD scripts want to own the project’s .venv, which clashes with Python projects that manage their own (#2823).
  • You need Node.js, Git and uv now.

Our advice: keep production projects on 6.12 for now, and try the new route in a throwaway branch or worktree. That way you are ready when the release lands.

Conclusion

An installer is a promise that the project knows your environment better than you do. For a tool that runs inside half a dozen AI assistants, each changing monthly, that promise got harder and harder to keep. BMAD’s answer is to stop making it: ship plain skills, let standard tools install them, and put setup into a skill the agent can run and repair itself. It is less magic and more choice, and that is exactly the right trade.

If you want support bringing that kind of structure into your own team’s AI work, that is what our Guided AI program is for.

Large qupaya logo

Company

  • About
  • Case study
  • Careers
  • Contact

Services

  • Guided Program
  • Guided AI
  • Guided Angular
  • Consulting
  • Software Engineering
  • From Planning to Delivery
  • AngularJS Migration
  • Angular Health Check

Legal

  • Site Notice
  • Privacy
  • Accessibility

Languages

  • English
  • German

Copyright © 2026 qupaya. All rights reserved.