Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
bmad-code-org avatar

Bmad Module Builder

  • 8 installs
  • 186 repo stars
  • Updated June 22, 2026
  • bmad-code-org/bmad-builder

bmad-module-builder is a Claude skill that plans, creates, and validates BMad modules, turning skills into an installable module package.

About

bmad-module-builder plans, scaffolds, and validates BMad modules. A developer uses its Ideate path to brainstorm a module and produce a plan, the Create path to package built skills into an installable module, and the Validate path to check that structure and capability registration are complete. It supports --headless mode for the Create and Validate paths.

  • Plans, creates, and validates BMad modules from idea to installable package
  • Three paths: Ideate (brainstorm + plan), Create (scaffold installable module), Validate (check structure)
  • Scaffolds a -setup skill for multi-skill modules and self-registration for single skills

Bmad Module Builder by the numbers

  • 8 all-time installs (skills.sh)
  • Ranked #545 of 782 Skill Development skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
At a glance

bmad-module-builder capabilities & compatibility

Capabilities
module scaffolding · skill packaging · module validation
Use cases
orchestration
From the docs

What bmad-module-builder says it does

This skill helps you bring BMad modules to life — from the first spark of an idea to a fully scaffolded, installable module.
SKILL.md
Takes an existing folder of built skills (or a single skill) and scaffolds the module infrastructure that makes it installable.
SKILL.md
Checks that a module's structure is complete and correct — every skill has its capabilities registered, entries are accurate and well-crafted, and structural integrity is sound.
SKILL.md
npx skills add https://github.com/bmad-code-org/bmad-builder --skill bmad-module-builder

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs8
repo stars186
Last updatedJune 22, 2026
Repositorybmad-code-org/bmad-builder

What it does

Ideate, scaffold, or validate a BMad module that packages one or more skills into an installable unit.

Who is it for?

Packaging built BMad skills into an installable module and validating its structure

Skip if: Authoring the individual skill or workflow logic itself (that is the Agent Builder / Workflow Builder job)

When should I use this skill?

The user asks to ideate, plan, create, build, or validate a BMad module

What you get

A fully scaffolded, installable BMad module with a plan document or validated structure.

  • A module plan document
  • A scaffolded installable module
  • A module validation report

By the numbers

  • 3 paths (Ideate, Create, Validate)

Files

assets/setup-skill-template/SKILL.mdMarkdownGitHub ↗

Module Setup

Overview

Installs and configures a BMad module into a project. Module identity (name, code, version) comes from ./assets/module.yaml. Collects user preferences and writes them to three files:

  • `{project-root}/_bmad/config.yaml` — shared project config: core settings at root (e.g. output_folder, document_output_language) plus a section per module with metadata and module-specific values. User-only keys (user_name, communication_language) are never written here.
  • `{project-root}/_bmad/config.user.yaml` — personal settings intended to be gitignored: user_name, communication_language, and any module variable marked user_setting: true in ./assets/module.yaml. These values live exclusively here.
  • `{project-root}/_bmad/module-help.csv` — registers module capabilities for the help system.

Both config scripts use an anti-zombie pattern — existing entries for this module are removed before writing fresh ones, so stale values never persist.

{project-root} is a literal token in config values — never substitute it with an actual path. It signals to the consuming LLM that the value is relative to the project root, not the skill root.

On Activation

1. Read ./assets/module.yaml for module metadata and variable definitions (the code field is the module identifier) 2. Check if {project-root}/_bmad/config.yaml exists — if a section matching the module's code is already present, inform the user this is an update 3. Check for per-module configuration at {project-root}/_bmad/{module-code}/config.yaml and {project-root}/_bmad/core/config.yaml. If either file exists:

  • If {project-root}/_bmad/config.yaml does not yet have a section for this module: this is a fresh install. Inform the user that installer config was detected and values will be consolidated into the new format.
  • If {project-root}/_bmad/config.yaml already has a section for this module: this is a legacy migration. Inform the user that legacy per-module config was found alongside existing config, and legacy values will be used as fallback defaults.
  • In both cases, per-module config files and directories will be cleaned up after setup.

If the user provides arguments (e.g. accept all defaults, --headless, or inline values like user name is BMad, I speak Swahili), map any provided values to config keys, use defaults for the rest, and skip interactive prompting. Still display the full confirmation summary at the end.

Collect Configuration

Ask the user for values. Show defaults in brackets. Present all values together so the user can respond once with only the values they want to change (e.g. "change language to Swahili, rest are fine"). Never tell the user to "press enter" or "leave blank" — in a chat interface they must type something to respond.

Default priority (highest wins): existing new config values > legacy config values > ./assets/module.yaml defaults. When legacy configs exist, read them and use matching values as defaults instead of module.yaml defaults. Only keys that match the current schema are carried forward — changed or removed keys are ignored.

Core config (only if no core keys exist yet): user_name (default: BMad), communication_language and document_output_language (default: English — ask as a single language question, both keys get the same answer), output_folder (default: {project-root}/_bmad-output). Of these, user_name and communication_language are written exclusively to config.user.yaml. The rest go to config.yaml at root and are shared across all modules.

Module config: Read each variable in ./assets/module.yaml that has a prompt field. Ask using that prompt with its default value (or legacy value if available).

Write Files

Write a temp JSON file with the collected answers structured as {"core": {...}, "module": {...}} (omit core if it already exists). Then run both scripts — they can run in parallel since they write to different files:

python3 ./scripts/merge-config.py --config-path "{project-root}/_bmad/config.yaml" --user-config-path "{project-root}/_bmad/config.user.yaml" --module-yaml ./assets/module.yaml --answers {temp-file} --legacy-dir "{project-root}/_bmad"
python3 ./scripts/merge-help-csv.py --target "{project-root}/_bmad/module-help.csv" --source ./assets/module-help.csv --legacy-dir "{project-root}/_bmad" --module-code {module-code}

Both scripts output JSON to stdout with results. If either exits non-zero, surface the error and stop. The scripts automatically read legacy config values as fallback defaults, then delete the legacy files after a successful merge. Check legacy_configs_deleted and legacy_csvs_deleted in the output to confirm cleanup.

Run ./scripts/merge-config.py --help or ./scripts/merge-help-csv.py --help for full usage.

Create Output Directories

After writing config, create any output directories that were configured. For filesystem operations only (such as creating directories), resolve the {project-root} token to the actual project root and create each path-type value from config.yaml that does not yet exist — this includes output_folder and any module variable whose value starts with {project-root}/. The paths stored in the config files must continue to use the literal {project-root} token; only the directories on disk should use the resolved paths. Use mkdir -p or equivalent to create the full path.

Cleanup Legacy Directories

After both merge scripts complete successfully, remove the installer's package directories. Skills and agents in these directories are already installed at .claude/skills/ — the _bmad/ directory should only contain config files.

python3 ./scripts/cleanup-legacy.py --bmad-dir "{project-root}/_bmad" --module-code {module-code} --also-remove _config --skills-dir "{project-root}/.claude/skills"

The script verifies that every skill in the legacy directories exists at .claude/skills/ before removing anything. Directories without skills (like _config/) are removed directly. If the script exits non-zero, surface the error and stop. Missing directories (already cleaned by a prior run) are not errors — the script is idempotent.

Check directories_removed and files_removed_count in the JSON output for the confirmation step. Run ./scripts/cleanup-legacy.py --help for full usage.

Confirm

Use the script JSON output to display what was written — config values set (written to config.yaml at root for core, module section for module values), user settings written to config.user.yaml (user_keys in result), help entries added, fresh install vs update. If legacy files were deleted, mention the migration. If legacy directories were removed, report the count and list (e.g. "Cleaned up 106 installer package files from bmb/, core/, \_config/ — skills are installed at .claude/skills/"). Then display the module_greeting from ./assets/module.yaml to the user.

Outcome

Once the user's user_name and communication_language are known (from collected input, arguments, or existing config), use them consistently for the remainder of the session: address the user by their configured name and communicate in their configured communication_language.

Related skills

FAQ

What are the three paths in bmad-module-builder?

Ideate Module (brainstorm and produce a plan), Create Module (scaffold installable infrastructure from built skills), and Validate Module (check structure and capability registration).

Does it support non-interactive use?

Yes. The Create and Validate paths accept --headless / -H for non-interactive execution.

Skill Developmentagentsautomation

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.