Module Setup

Overview

Installs, configures, and upgrades a BMad module in a project. This module is special: alongside the four automation skills it relies on the bmad-auto orchestrator tool (the Python program that drives the loop), installed as the bmad-auto package from its public Git repository. So setup does two jobs — (1) register module config + help entries, and (2) install or upgrade the orchestrator tool and bootstrap the project so it is ready to run.

The same skill handles both first-time setup and upgrades. When it detects an existing bmad-auto install (or you ask it to upgrade), it upgrades the orchestrator tool, refreshes the per-project bmad-auto-* skill copies, and re-stamps config — the two-step upgrade ritual, run for you. A plain re-run on an already-installed project is treated as an upgrade.

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 (the data written into the files above) — never substitute it there. It signals to the consuming LLM that the value is relative to the project root, not the skill root. This does not apply to the filesystem path arguments passed to the scripts below (the --*-path, --*-dir, and --target arguments): those are real paths, so you must resolve {project-root} to the actual project root before running, or the scripts will write to a literal {project-root}/ directory under the skill folder. The scripts reject an unresolved token with an error.

On Activation