Skip to main content
BMad modules are configured using module.yaml files that define module metadata, user prompts, variables, and installation behavior. This reference documents the configuration schema and available options.

Configuration File Location

Each module contains a module.yaml file in its root directory:

Schema Overview

A module.yaml file consists of:
  1. Module metadata - Identification and description
  2. Header configuration - Display text during installation
  3. Variable definitions - User-configurable settings with prompts
  4. Installation directives - Directories to create, files to copy, etc.

Module Metadata

code

string
required
Unique identifier for the module. Used in command names and internal references.Naming convention: Lowercase, 2-4 charactersExample:

name

string
required
Human-readable module name displayed during installation and in status output.Example:

description

string
Brief description of the module’s purpose and features.Example:

default_selected

boolean
default:"false"
Whether this module should be pre-selected during installation. Only the core module and primary modules should use this.Example:

Header Configuration

Headers provide context to users during the installation prompts.
string
Main heading displayed before module configuration prompts.Example:

subheader

string
Additional explanatory text displayed below the header. Supports multi-line strings.Example:

Variable Definitions

Variables collect user input and configure module behavior. Each variable has a unique key and configuration object.

Variable Structure

Variable Properties

string | array
required
Question(s) to ask the user. Can be:
  • Single string for simple prompts
  • Array of strings for multi-line prompts
Examples:
string | boolean
Default value if user accepts the default. Supports:
  • Literal values: "English", true, false
  • Variable references: "{directory_name}"
  • Path templates: "{output_folder}/planning-artifacts"
Examples:
string
required
Template for the final value stored in the configuration. Supports:
  • {value} - User’s input or selected value
  • {project-root} - Absolute path to project root
  • Other variable references: {output_folder}
Examples:

Selection Types

Variables can provide predefined options for users to choose from.

single-select

array
Array of options where user selects exactly one. Each option has value and label.Structure:
Example:

multi-select

array
Array of options where user can select multiple. Same structure as single-select.Note: Multi-select is available but less commonly used. Refer to single-select structure.

Installation Directives

directories

array
List of directories to create during installation. Supports variable interpolation.Example:
This creates:

Variable Interpolation

Configuration values support template variables that are resolved during installation:

Resolution Order

  1. Core module variables are resolved first
  2. Module-specific variables are resolved next
  3. Variables can reference previously-defined variables
  4. Path templates are expanded using resolved values
Example chain:

Variable Inheritance

Modules can reference variables defined in the core module:
Core variables are automatically available to all modules without re-prompting the user.

Complete Examples

Core Module Configuration

BMM Module Configuration


Best Practices

Naming Conventions

  • Module codes: Short (2-4 chars), lowercase, memorable (bmm, core, tea)
  • Variable names: Snake_case, descriptive (user_name, planning_artifacts)
  • Paths: Use underscores or hyphens, avoid spaces

User Experience

  • Provide sensible defaults - Most users should be able to accept defaults
  • Use clear prompts - Explain what the setting affects
  • Group related settings - Use headers and subheaders
  • Avoid redundancy - Reference core variables instead of re-prompting

Path Management

  • Use relative paths in defaults - Let users customize the base
  • Always resolve with project-root - Ensures absolute paths in manifest
  • Create directories declaratively - Use directories array

Variable Dependencies

  • Define base paths first - output_folder before planning_artifacts
  • Reference existing variables - "{output_folder}/planning-artifacts"
  • Document inherited variables - Add comments showing core variables

Validation

The installer validates configuration files during installation:
  • Required fields: code, name
  • Variable references must resolve
  • Directory paths must be valid
  • Selection options must include the default value
Validation errors are displayed with clear messages during installation.