bmad-plugins-marketplace: The Registry That Treats Prompts Like Supply Chain Code

Inside BMad’s AI workflow marketplace, where modules are versioned, classified, and pinned like software artifacts, and where trust matters more than freshness.

8 min read • View on GitHub • More from bmad-code-org

A reference desk with two stacks of catalog cards, one stack stamped with live branch markers and another sealed with Git SHA tags. The scene explains that the marketplace is split between fast-moving official modules and immutable community modules, with trust treated as the primary design constraint. — BMad’s marketplace behaves less like an app store and more like a trust registry.

Key Takeaways

BMad’s marketplace is really a governance layer that decides which AI behaviors can be trusted, not just a directory of plugins.
The repo treats prompt content, provenance, and update policy like supply-chain concerns, with official modules tracking branches and community modules pinned to immutable SHAs.
Its indexer turns YAML into a reproducible registry, so discovery, validation, and publication all come from the same source of truth.
The taxonomy suggests a bigger ambition than distribution: BMad is trying to define the ontology of AI workflows.

The first surprise in bmad-plugins-marketplace is that it is not mainly about discovery. It is about restraint. The repo draws a hard line between official modules that can follow main and community modules that must be pinned to immutable Git SHAs, which means the real product is trust, not freshness.

That matters because the artifact being governed is not a binary. It is behavior. In BMad’s world, a plugin can contain prompts, workflow steps, file access, and network calls, so the review surface looks much closer to software supply-chain control than to a normal marketplace listing.

The real product is trust

The registry’s design makes a sharp distinction: official modules can track a branch, while community modules are locked to a specific approved commit. That split is the editorial thesis of the repo. If prompt content can steer an agent, then a prompt bundle without provenance is not a convenience artifact, it is a risk surface.

This repository serves as a marketplace for multiple plugins. Each plugin is developed and maintained in its own repository, but they are all listed here for easy discovery and installation.

Stefano Ginella, Maintainer, claude-code-plugins · stefanoginella/claude-code-plugins

That quote describes the basic marketplace pattern. BMad adds a stricter layer on top of it. Discovery is still there, but the module is only accepted into the ecosystem if its identity, trust tier, and versioning rules can survive registry policy.

A close-up of a registry assembly line where taxonomy files and module metadata enter a validating gate and emerge as two synchronized outputs. The image explains how the marketplace is generated from structured source data rather than edited by hand. — The index is synthesized from metadata, not curated one row at a time.

How the registry turns YAML into a marketplace

The repo is built as data-as-code. The core files live under registry/, with separate paths for official, community, and utility modules, while categories.yaml provides the taxonomy. The important thing is not the folder tree itself. It is that the folder tree is the database.

A single script turns taxonomy and module metadata into synchronized public outputs.

At the schema level, registry-schema.yaml defines identity fields, trust tier, and versioning behavior. That gives each module a policy wrapper, not just a record. The schema is doing governance work before a human ever opens a pull request.

name: bmad-builder
code: bmb
display_name: BMad Builder
trust_tier: bmad-certified
approved_tag: v1.2.0
approved_sha: 7e3c2f1a9b8d4c0f2d6f1a8b9c0d7e6f5a4b3c2d1

That shape matters because it makes the marketplace reproducible. A community module is not just "available." It is anchored. The registry can resolve it the same way every time, which is exactly what you want when the thing being installed can alter an agent’s behavior.

The indexer is the product’s hidden engine

The hidden engine is .github/scripts/generate-index.py. It crawls the registry tree, injects provenance with a directory marker, joins that data to the category taxonomy, and emits both human and machine outputs. In practice, that means the marketplace behaves like a static site generator for trust.

This is the most elegant part of the repository. The registry is not maintained in two places, one for humans and one for machines. The script compiles one source of truth into both forms, which keeps drift low and review simple.

Source YAML files define the module record.
The generator adds provenance and classification.
Validation checks the schema before publish.
Two outputs keep humans and tools in sync.

Why prompt governance matters more than package versions

Traditional package managers care a lot about dependency graphs, binaries, and API compatibility. BMad cares about those things too, but it cares more about prompt content and script behavior. That is because a prompt can be both product and attack surface. If it changes, the agent changes.

Dimension	Traditional package manager	BMad registry
Artifact type	Binary or library package	Prompt bundle, workflow, agent module
Trust model	Version numbers and release tags	Pinned SHAs, approved tags, trust tiers
Review surface	Code and API compatibility	Prompt content, file access, network calls
Update policy	Latest release is often preferred	Official modules may track a branch, community modules stay pinned
User intent	Install software	Install behavior

That is why the contribution templates matter so much. They turn review into a security ritual. A new module is not accepted because it looks useful. It is accepted because its behavior is understandable, auditable, and stable enough to trust.

Where BMad fits in the Claude Code ecosystem

BMad is designed to plug into Claude Code through marketplace configuration, which makes it an extension layer for AI development workflows rather than a generic app store. The ecosystem goal is simple: let teams add specialized behavior without turning the base agent into a custom fork.

That positioning also explains the registry architecture. If the marketplace is meant to feed an agent runtime, then discoverability alone is not enough. The system has to preserve the exact module that was reviewed, approved, and installed.

The taxonomy reveals the ambition

The category map matters because it shows BMad thinking in terms of roles and domains, not just features. A taxonomy turns a pile of modules into a model of the AI engineering world. That is a bigger ambition than distribution. It is ontology.

Once you do that, the marketplace stops being a shelf and starts looking like a language. Each category says what kinds of agent behavior the ecosystem thinks are worth naming, reviewing, and reusing.

What the taxonomy does	Why it matters
Groups modules by domain	Helps users find the right behavior fast
Encodes trust and classification	Makes governance visible in the listing itself
Normalizes AI workflow roles	Suggests the ecosystem is becoming a vocabulary, not a catalog

What this marketplace is really becoming

The direction is clear. BMad is building a registry for executable AI behavior, with provenance, taxonomy, and trust policies baked in from the start. That is a different mental model from package distribution. It is closer to a governed marketplace of constrained agent capabilities.

If the rest of the software world learned to treat dependencies like supply-chain assets, AI toolchains may need to go one step further. They will need to treat instructions as the package, and trust as part of the install.