## Overview
This commit represents a complete overhaul of the BMAD agent creation system, establishing clear standards for agent development, installation workflows, and persona design. The changes span documentation, tooling, reference implementations, and field-specific guidance.
## Key Components
### 1. Agent Installation Infrastructure
**New CLI Command: `agent-install`**
- Interactive agent installation with persona customization
- Supports Simple (single YAML), Expert (sidecar files), and Module agents
- Template variable processing with Handlebars-style syntax
- Automatic compilation from YAML to XML (.md) format
- Manifest tracking and IDE integration (Claude Code, Cursor, Windsurf, etc.)
- Source preservation in `_cfg/custom/agents/` for reinstallation
**Files Created:**
- `tools/cli/commands/agent-install.js` - Main CLI command
- `tools/cli/lib/agent/compiler.js` - YAML to XML compilation engine
- `tools/cli/lib/agent/installer.js` - Installation orchestration
- `tools/cli/lib/agent/template-engine.js` - Handlebars template processing
**Compiler Features:**
- Auto-injects frontmatter, activation, handlers, help/exit menu items
- Smart handler inclusion (only includes action/workflow/exec/tmpl handlers actually used)
- Proper XML escaping and formatting
- Persona name customization (e.g., "Fred the Commit Poet")
### 2. Documentation Overhaul
**Deleted Bloated/Outdated Docs (2,651 lines removed):**
- Old verbose architecture docs
- Redundant pattern files
- Outdated workflow guides
**Created Focused, Type-Specific Docs:**
- `src/modules/bmb/docs/understanding-agent-types.md` - Architecture vs capability distinction
- `src/modules/bmb/docs/simple-agent-architecture.md` - Self-contained agents
- `src/modules/bmb/docs/expert-agent-architecture.md` - Agents with sidecar files
- `src/modules/bmb/docs/module-agent-architecture.md` - Workflow-integrated agents
- `src/modules/bmb/docs/agent-compilation.md` - YAML → XML process
- `src/modules/bmb/docs/agent-menu-patterns.md` - Menu design patterns
- `src/modules/bmb/docs/index.md` - Documentation hub
**Net Result:** ~1,930 line reduction while adding MORE value through focused content
### 3. Create-Agent Workflow Enhancements
**Critical Persona Field Guidance Added to Step 4:**
Explains how the LLM interprets each persona field when the agent activates:
- **role** → "What knowledge, skills, and capabilities do I possess?"
- **identity** → "What background, experience, and context shape my responses?"
- **communication_style** → "What verbal patterns, word choice, quirks, and phrasing do I use?"
- **principles** → "What beliefs and operating philosophy drive my choices?"
**Key Insight:** `communication_style` should ONLY describe HOW the agent talks, not restate role/identity/principles. The `communication-presets.csv` provides 60 pure communication styles with NO role/identity/principles mixed in.
**Files Updated:**
- `src/modules/bmb/workflows/create-agent/instructions.md` - Added persona field interpretation guide
- `src/modules/bmb/workflows/create-agent/brainstorm-context.md` - Refined to 137 lines
- `src/modules/bmb/workflows/create-agent/communication-presets.csv` - 60 styles across 13 categories
### 4. Reference Agent Cleanup
**Removed install_config Personality Bloat:**
Understanding: Future installer will handle personality customization, so stripped all personality toggles from reference agents.
**commit-poet.agent.yaml** (Simple Agent):
- BEFORE: 36 personality combinations (3 enthusiasm × 3 depths × 4 styles) = decision fatigue
- AFTER: Single concise persona with pure communication style
- Changed from verbose conditionals to: "Poetic drama and flair with every turn of a phrase. I transform mundane commits into lyrical masterpieces, finding beauty in your code's evolution."
- Reduction: 248 lines → 153 lines (38% reduction)
**journal-keeper.agent.yaml** (Expert Agent):
- Stripped install_config, simplified communication_style
- Shows proper Expert agent structure with sidecar files
**security-engineer.agent.yaml & trend-analyst.agent.yaml** (Module Agents):
- Added header comments explaining WHY Module Agent (design intent, not just location)
- Clarified: Module agents are designed FOR ecosystem integration, not capability-limited
**Files Updated:**
- `src/modules/bmb/reference/agents/simple-examples/commit-poet.agent.yaml`
- `src/modules/bmb/reference/agents/expert-examples/journal-keeper/journal-keeper.agent.yaml`
- `src/modules/bmb/reference/agents/module-examples/security-engineer.agent.yaml`
- `src/modules/bmb/reference/agents/module-examples/trend-analyst.agent.yaml`
### 5. BMM Agent Voice Enhancement
**Gave all 9 BMM agents distinct, memorable communication voices:**
**Mary (analyst)** - The favorite! Changed from generic "systematic and probing" to:
"Treats analysis like a treasure hunt - excited by every clue, thrilled when patterns emerge. Asks questions that spark 'aha!' moments while structuring insights with precision."
**Other Notable Voices:**
- **John (pm):** "Asks 'WHY?' relentlessly like a detective on a case. Direct and data-sharp, cuts through fluff to what actually matters."
- **Winston (architect):** "Speaks in calm, pragmatic tones, balancing 'what could be' with 'what should be.' Champions boring technology that actually works."
- **Amelia (dev):** "Ultra-succinct. Speaks in file paths and AC IDs - every statement citable. No fluff, all precision."
- **Bob (sm):** "Crisp and checklist-driven. Every word has a purpose, every requirement crystal clear. Zero tolerance for ambiguity."
- **Sally (ux-designer):** "Paints pictures with words, telling user stories that make you FEEL the problem. Empathetic advocate with creative storytelling flair."
**Pattern Applied:** Moved behaviors from communication_style to principles, keeping communication_style as PURE verbal patterns.
**Files Updated:**
- `src/modules/bmm/agents/analyst.agent.yaml`
- `src/modules/bmm/agents/pm.agent.yaml`
- `src/modules/bmm/agents/architect.agent.yaml`
- `src/modules/bmm/agents/dev.agent.yaml`
- `src/modules/bmm/agents/sm.agent.yaml`
- `src/modules/bmm/agents/tea.agent.yaml`
- `src/modules/bmm/agents/tech-writer.agent.yaml`
- `src/modules/bmm/agents/ux-designer.agent.yaml`
- `src/modules/bmm/agents/frame-expert.agent.yaml`
### 6. Linting Fixes
**ESLint Compliance:**
- Replaced all `'utf-8'` with `'utf8'` (unicorn/text-encoding-identifier-case)
- Changed `variables.hasOwnProperty(varName)` to `Object.hasOwn(variables, varName)` (unicorn/prefer-object-has-own)
- Replaced `JSON.parse(JSON.stringify(...))` with `structuredClone(...)` (unicorn/prefer-structured-clone)
- Fixed empty YAML mapping values in sample files
**Files Fixed:**
- 7 JavaScript files across agent tooling (compiler, installer, commands, IDE integration)
- 1 YAML sample file
## Architecture Decisions
### Agent Types Are About Architecture, Not Capability
- **Simple:** Self-contained in single YAML (NOT limited in capability)
- **Expert:** Includes sidecar files (templates, docs, etc.)
- **Module:** Designed for BMAD ecosystem integration (workflows, cross-agent coordination)
### Persona Field Separation Critical for LLM Interpretation
The LLM needs distinct fields to understand its role:
- Mixing role/identity/principles into communication_style confuses the persona
- Pure communication styles (from communication-presets.csv) have ZERO role/identity/principles content
- Example DON'T: "Experienced analyst who uses systematic approaches..." (mixing identity + style)
- Example DO: "Systematic and probing. Structures findings hierarchically." (pure style)
### Install-Time vs Runtime Configuration
- Template variables ({{var}}) resolve at compile-time
- Runtime variables ({user_name}, {bmad_folder}) resolve when agent activates
- Future installer will handle personality customization, so agents should ship with single default persona
## Testing
- All linting passes (ESLint with max-warnings=0)
- Agent compilation tested with commit-poet, journal-keeper examples
- Install workflow validated with Simple and Expert agent types
- Manifest tracking and IDE integration verified
## Impact
This establishes BMAD as having a complete, production-ready agent creation and installation system with:
- Clear documentation for all agent types
- Automated compilation and installation
- Strong persona design guidance
- Reference implementations showing best practices
- Distinct, memorable agent voices throughout BMM module
Co-Authored-By: BMad Builder <builder@bmad.dev>
Co-Authored-By: Mary the Analyst <analyst@bmad.dev>
Co-Authored-By: Paige the Tech Writer <tech-writer@bmad.dev>
|
||
|---|---|---|
| .. | ||
| bundlers | ||
| commands | ||
| installers/lib | ||
| lib | ||
| README.md | ||
| bmad-cli.js | ||
| regenerate-manifests.js | ||
| test-yaml-builder.js | ||
README.md
BMad CLI Tool
The BMad CLI handles installation and web bundling for the BMAD-METHOD framework. It compiles YAML agents into two distinct formats: IDE-integrated agents (filesystem-aware, customizable) and web bundles (self-contained, dependency-embedded).
Table of Contents
- BMad CLI Tool
Overview
The CLI provides two primary functions:
- Installation: Compiles agents from YAML and installs to IDE environments with full customization support
- Bundling: Packages agents and dependencies into standalone web-ready XML files
Both use the same YAML→XML compilation engine but produce different outputs optimized for their environments.
Commands
Installation
# Interactive installation
npm run install:bmad
# Direct CLI usage
node tools/cli/bmad-cli.js install --target /path/to/project --modules bmm,bmb --ides codex
# Flags:
# --target <path> Target project directory
# --modules <list> Comma-separated: bmm, bmb, cis
# --ides <list> Comma-separated IDE codes (see IDE Support)
# --non-interactive Skip all prompts
Bundling
# Bundle all modules
npm run bundle
# Bundle specific items
node tools/cli/bundlers/bundle-web.js all # Everything
node tools/cli/bundlers/bundle-web.js module bmm # One module
node tools/cli/bundlers/bundle-web.js agent bmm pm # One agent
Utilities
npm run bmad:status # Installation status
npm run validate:bundles # Validate web bundles
node tools/cli/regenerate-manifests.js # Regenerate agent-manifest.csv files
Installation System
The installer is a multi-stage system that handles agent compilation, IDE integration, module configuration, platform-specific behaviors, and manifest generation.
Installation Flow
1. Collect User Input
- Target directory, modules, IDEs
- Custom module configuration (via install-config.yaml)
2. Pre-Installation
- Validate target, check conflicts, backup existing installations
- Resolve module dependencies (4-pass system)
3. Install Core + Modules
- Copy files to {target}/{bmad_folder}/
- Compile agents: YAML → Markdown/XML (forWebBundle: false)
- Merge customize.yaml files if they exist
- Inject activation blocks based on agent capabilities
4. IDE Integration
- Initialize selected IDE handlers
- Generate IDE-specific artifacts (commands/rules/workflows)
- Execute platform-specific hooks (IDE+module combinations)
5. Generate Manifests
- manifest.yaml (installation metadata)
- workflow-manifest.csv (workflow catalog)
- agent-manifest.csv (agent metadata)
- task-manifest.csv (legacy)
- files-manifest.csv (all files with SHA256 hashes)
6. Validate & Finalize
- Verify file integrity, agent compilation, IDE artifacts
- Display summary and next steps
Output Structure:
{target}/
├── {bmad_folder}/
│ ├── core/ # Always installed
│ ├── {module}/ # Selected modules
│ │ ├── agents/ # Compiled .md files
│ │ ├── workflows/
│ │ └── config.yaml
│ └── _cfg/ # Manifests
└── .{ide}/ # IDE-specific artifacts
└── ... # Format varies by IDE
IDE Support
The installer supports 15 IDE environments through a base-derived architecture. Each IDE handler extends BaseIDE and implements IDE-specific artifact generation.
Supported IDEs (as of v6-alpha):
| Code | Name | Artifact Location |
|---|---|---|
codex |
Claude Code | .claude/commands/ |
claude-code |
Claude Code (alt) | .claude/commands/ |
opencode |
OpenCode | .opencode |
windsurf |
Windsurf | .windsurf/workflows/ |
cursor |
Cursor | .cursor/rules/ |
cline |
Cline | .clinerules/workflows/ |
github-copilot |
GitHub Copilot | .github/copilot/ |
crush |
Crush | .crush/ |
auggie |
Auggie | .auggie/ |
gemini |
Google Gemini | .gemini/ |
qwen |
Qwen | .qwen/ |
roo |
Roo | .roo/ |
trae |
Trae | .trae/ |
iflow |
iFlow | .iflow/ |
kilo |
Kilo | .kilo/ |
Handler Architecture:
- Base class:
tools/cli/installers/lib/ide/_base-ide.js - Handler implementations:
tools/cli/installers/lib/ide/{ide-code}.js - Dynamic discovery: IDE manager scans directory and auto-registers handlers
- Each handler implements:
setup(),createArtifacts(),cleanup(),getAgentsFromBmad()
Adding New IDE Support:
- Create handler file:
tools/cli/installers/lib/ide/your-ide.js - Extend
BaseIDE, setideCode,ideName,artifactType - Implement artifact generation methods
- IDE auto-discovered on next run
Custom Module Configuration
Modules define interactive configuration menus via install-config.yaml files in their _module-installer/ directories.
Config File Location:
- Core:
src/core/_module-installer/install-config.yaml - Modules:
src/modules/{module}/_module-installer/install-config.yaml
Configuration Types:
select: Radio button choicesmultiselect: Checkboxesinput: Text input with validationconfirm: Yes/no
Variable Substitution:
{project-root}→ Absolute target path{directory_name}→ Project directory basename{module}→ Current module name{value:config_id}→ Reference another config value
Config Persistence:
- Values saved to module's
config.yaml - Existing values detected on reinstall
- User prompted: "Use existing or change?"
Processor: tools/cli/installers/lib/core/config-collector.js
Platform Specifics
Platform specifics are IDE+module combination hooks that execute custom logic when specific IDE and module are installed together.
Two-Layer Architecture:
-
Module-Level:
src/modules/{module}/_module-installer/platform-specifics/{ide}.js- Module provides custom behavior for specific IDEs
- Example: BMM creates subagents when installed with Claude Code
-
IDE-Level: Embedded in IDE handler's
createArtifacts()method- IDE provides custom handling for specific modules
- Example: Windsurf configures cascade workflows for BMM
Execution Timing: After standard installation, before validation
Common Use Cases:
- Creating subagent variations (PM-technical, PM-market)
- Configuring IDE-specific workflow integrations
- Adding custom commands or rules based on module features
- Adjusting UI/UX for module-specific patterns
Platform Registry: tools/cli/installers/lib/ide/shared/platform-codes.js
Manifest System
The installer generates 5 manifest files in {target}/{bmad_folder}/_cfg/:
1. Installation Manifest (manifest.yaml)
- Installation metadata: version, timestamps, target directory
- Installed modules and versions
- Integrated IDEs and their configurations
- User configuration values
2. Workflow Manifest (workflow-manifest.csv)
- Columns: module, workflow_path, workflow_name, description, scale_level
- Used by workflow command generators
- RFC 4180 compliant CSV format
3. Agent Manifest (agent-manifest.csv)
- Columns: module, agent_path, agent_name, role, identity_summary, communication_style, expertise, approach, responsibilities, workflows
- 10-column metadata for each agent
- Used by IDE integrations and documentation
4. Task Manifest (task-manifest.csv)
- Legacy compatibility (deprecated in v6)
- Columns: module, task_path, task_name, objective, agent
5. Files Manifest (files-manifest.csv)
- Complete file tracking with SHA256 hashes
- Columns: file_path, file_type, module, hash
- Enables integrity validation and change detection
Generator: tools/cli/installers/lib/core/manifest-generator.js
Use Cases:
- Update detection (compare current vs manifest hashes)
- Workflow command generation for IDEs
- Installation validation and integrity checks
- Rollback capability
Advanced Features
Dependency Resolution (4-Pass System):
- Pass 1: Explicit dependencies from module metadata
- Pass 2: Template references in workflows
- Pass 3: Cross-module workflow/agent references
- Pass 4: Transitive dependencies
Agent Activation Injection:
- Detects which handlers each agent uses (workflow, exec, tmpl, data, action)
- Injects only needed handler fragments from
src/utility/models/fragments/ - Keeps compiled agents lean and purpose-built
Module Injection System:
- Conditional content injection based on user config
- Can inject menu items, text blocks, workflow steps
- File:
tools/cli/installers/lib/ide/shared/module-injections.js
Conflict Resolution:
- Detects existing installations
- Options: Update (preserve customizations), Backup (timestamp), Cancel
- Auto-backup to
.bmad-backup-{timestamp}if selected
Workflow Command Auto-Generation:
- Reads workflow-manifest.csv
- Generates IDE commands for each workflow
- IDE-specific formatting (Claude Code .md, Windsurf YAML, etc.)
Validation & Integrity:
- Verifies all manifest files exist
- Validates file hashes against files-manifest.csv
- Checks agent compilation completeness
- Confirms IDE artifacts created
Bundling System
Web bundling creates self-contained XML packages with all dependencies embedded for web deployment.
Bundling Flow
1. Discover modules and agents from src/modules/
2. For each agent:
- Compile with YamlXmlBuilder (forWebBundle: true)
- Use web-bundle-activation-steps.xml fragment
- Resolve ALL dependencies recursively:
- Scan menu items for workflow references
- Load workflows → extract web_bundle section
- Find all file references (templates, data, sub-workflows)
- Wrap each in <file id="path"><![CDATA[...]]></file>
- Build consolidated bundle: agent + all deps
3. Output to: web-bundles/{module}/agents/{name}.xml
Key Differences from Installation:
- No customize.yaml merging (base agents only)
- No metadata (reduces file size)
- All dependencies bundled inline (no filesystem access)
- Uses web-specific activation fragment
- Output: Standalone XML files
Output Structure:
web-bundles/
├── bmm/
│ ├── agents/
│ │ ├── pm.xml
│ │ ├── architect.xml
│ │ ├── sm.xml
│ │ └── dev.xml
│ └── teams/
│ └── dev-team.xml
├── bmb/
│ └── agents/
│ └── bmad-builder.xml
└── cis/
└── agents/
└── creative-director.xml
Bundler: tools/cli/bundlers/web-bundler.js
Agent Compilation
Both installation and bundling use the same YAML→XML compiler with different configurations.
Compilation Engine
Core File: tools/cli/lib/yaml-xml-builder.js
Process:
- Load YAML agent definition
- Merge with customize.yaml (installation only)
- Analyze agent to detect required handlers
- Build activation block:
- IDE: Uses
activation-steps.xml(filesystem-aware) - Web: Uses
web-bundle-activation-steps.xml(bundled files)
- IDE: Uses
- Convert to XML structure
- Output as markdown (IDE) or standalone XML (web)
Key Option Flags:
forWebBundle: true- Use web activation, omit metadataincludeMetadata: true- Include build hash (IDE only)skipActivation: true- Omit activation (team bundles)
Fragment System
Reusable XML fragments in src/utility/models/fragments/:
activation-steps.xml- IDE activation (loads config.yaml at runtime)web-bundle-activation-steps.xml- Web activation (uses bundled files)activation-rules.xml- Validation rules (IDE only)menu-handlers.xml- Menu handler wrapperhandler-workflow.xml- Workflow handlerhandler-exec.xml- Exec command handlerhandler-tmpl.xml- Template handlerhandler-data.xml- Data handlerhandler-action.xml- Action handler
Dynamic Injection: Agent analyzer detects which handlers are used, activation builder injects only those fragments.
Input: Agent YAML
agent:
metadata:
id: 'bmad/bmm/agents/pm.md'
name: 'PM'
title: 'Product Manager'
persona:
role: 'Product Manager'
identity: 'You are an experienced PM...'
menu:
- trigger: '*create-brief'
workflow: '{project-root}/{bmad_folder}/bmm/workflows/.../workflow.yaml'
Output: IDE (Markdown with XML)
<!-- Powered by BMAD-CORE™ -->
# Product Manager
```xml
<agent id="..." name="PM">
<activation critical="MANDATORY">
<step n="2">Load {project-root}/{bmad_folder}/bmm/config.yaml at runtime</step>
...
</activation>
<persona>...</persona>
<menu>...</menu>
</agent>
```
### Output: Web (Standalone XML)
```xml
<agent id="..." name="PM">
<activation critical="MANDATORY">
<step n="2">All dependencies bundled inline below</step>
...
</activation>
<persona>...</persona>
<menu>...</menu>
<bundled-files>
<file id="bmad/bmm/config.yaml"><![CDATA[...]]></file>
<file id="bmad/bmm/workflows/.../workflow.yaml"><![CDATA[...]]></file>
...
</bundled-files>
</agent>
Architecture
Directory Structure
tools/cli/
├── bmad-cli.js # Main CLI entry
├── commands/ # CLI command handlers
│ ├── install.js
│ ├── status.js
│ ├── list.js
│ ├── update.js
│ └── uninstall.js
├── bundlers/ # Web bundling
│ ├── bundle-web.js # CLI entry
│ └── web-bundler.js # WebBundler class
├── installers/
│ └── lib/
│ ├── core/ # Core installer logic
│ │ ├── installer.js
│ │ ├── manifest-generator.js
│ │ ├── manifest.js
│ │ ├── dependency-resolver.js
│ │ ├── config-collector.js
│ │ └── csv-parser.js
│ ├── modules/ # Module processing
│ │ └── manager.js
│ └── ide/ # IDE integrations
│ ├── _base-ide.js
│ ├── {14 IDE handlers}.js
│ ├── manager.js
│ └── shared/
│ ├── bmad-artifacts.js
│ ├── platform-codes.js
│ ├── module-injections.js
│ └── workflow-command-generator.js
├── lib/ # Shared compilation
│ ├── yaml-xml-builder.js # YAML→XML compiler
│ ├── activation-builder.js # Activation generator
│ ├── agent-analyzer.js # Handler detection
│ ├── xml-handler.js # Builder wrapper
│ └── paths.js
├── regenerate-manifests.js
└── test-yaml-builder.js
Fragment Library
src/utility/models/fragments/
├── activation-steps.xml
├── web-bundle-activation-steps.xml
├── activation-rules.xml
├── menu-handlers.xml
└── handler-*.xml # 5 handler types
Key Differences: Installation vs Bundling
| Aspect | Installation (IDE) | Bundling (Web) |
|---|---|---|
| Trigger | npm run install:bmad |
npm run bundle |
| Entry Point | commands/install.js |
bundlers/bundle-web.js |
| Compiler Flag | forWebBundle: false |
forWebBundle: true |
| Output Format | Markdown .md |
Standalone XML .xml |
| Output Location | {target}/{bmad_folder}/ + IDE dirs |
web-bundles/ |
| Customization | Merges customize.yaml |
Base agents only |
| Dependencies | Referenced by path | Bundled inline (CDATA) |
| Activation Fragment | activation-steps.xml |
web-bundle-activation-steps.xml |
| Filesystem Access | Required | Not needed |
| Build Metadata | Included (hash) | Excluded |
| Path Format | {project-root} placeholders |
Stripped, wrapped as <file> |
| Use Case | Local IDE development | Web deployment |
Activation Differences:
- IDE: Loads config.yaml at runtime from filesystem
- Web: Accesses bundled content via
<file id>references
Development Workflows
Testing Compilation
# Test YAML→XML compiler
node tools/cli/test-yaml-builder.js
# Test installation
node tools/cli/bmad-cli.js install --target ./test-project --modules bmm --ides codex
# Test bundling
node tools/cli/bundlers/bundle-web.js agent bmm pm
# Validate bundles
npm run validate:bundles
Adding New Menu Handlers
To add a new handler type (e.g., validate-workflow):
- Create fragment:
src/utility/models/fragments/handler-validate-workflow.xml - Update
agent-analyzer.jsto detect the new attribute - Update
activation-builder.jsto load/inject the fragment - Test with an agent using the handler
Regenerating Manifests
# Regenerate agent-manifest.csv for all modules
node tools/cli/regenerate-manifests.js
# Location: src/modules/{module}/agents/agent-manifest.csv
Related Documentation
- Project Guide:
CLAUDE.md - BMM Workflows:
src/modules/bmm/workflows/README.md - Module Structure:
src/modules/bmb/workflows/create-module/module-structure.md - Agent Creation:
src/modules/bmb/workflows/create-agent/README.md
Support
- Issues: https://github.com/bmad-code-org/BMAD-METHOD/issues
- Discord: https://discord.gg/gk8jAdXWmj (#general-dev, #bugs-issues)
- YouTube: https://www.youtube.com/@BMadCode