Initial commit: BMAD framework + Story 1.1 Component Trait Definition
Features: - BMAD (Build Modular AI-driven Development) framework setup - BMM, BMB, CIS, Core modules configured - Story 1.1: Component trait with error handling - Workspace Cargo.toml with components crate - 31 tests passing (19 unit + 12 doc tests) Technical: - Component trait with compute_residuals, jacobian_entries, n_equations - ComponentError enum with thiserror - JacobianBuilder for sparse matrix construction - Object-safe trait supporting Box<dyn Component> - Comprehensive documentation and examples
This commit is contained in:
Sepehr
179
_bmad/bmb/workflows/module/data/agent-architecture.md
Normal file
179
_bmad/bmb/workflows/module/data/agent-architecture.md
Normal file
@@ -0,0 +1,179 @@
|
||||
# Agent Architecture for Modules
|
||||
|
||||
**Purpose:** High-level guidance for planning agents in your module — not implementation details (that's what the agent-builder workflow is for).
|
||||
|
||||
---
|
||||
|
||||
## Single Agent vs. Multi-Agent Module
|
||||
|
||||
### Single Agent Module
|
||||
|
||||
**Use when:** One persona can handle the module's purpose.
|
||||
|
||||
**Characteristics:**
|
||||
- Simpler, focused
|
||||
- Clear single point of contact
|
||||
- Good for narrow domains
|
||||
|
||||
**Question:** Could one expert agent with a sidecar handle this entire module?
|
||||
|
||||
---
|
||||
|
||||
### Multi-Agent Module
|
||||
|
||||
**Use when:** Different expertise areas justify specialized personas.
|
||||
|
||||
**Characteristics:**
|
||||
- Each agent has a distinct role and expertise
|
||||
- Agents form a cohesive team around the module's theme
|
||||
- Menus coordinate to guide users to the right agent
|
||||
|
||||
**Why multi-agent?**
|
||||
- Different workflows need different expert perspectives
|
||||
- Users expect to talk to "the right expert" for each task
|
||||
- The module covers a domain too broad for one persona
|
||||
|
||||
---
|
||||
|
||||
## Flagship Example: BMM Agent Team
|
||||
|
||||
BMM demonstrates a multi-agent module with **9 specialized agents** forming a complete software development team.
|
||||
|
||||
### The BMM Theme
|
||||
|
||||
**"Agile software delivery, AI-driven"**
|
||||
|
||||
Every agent serves this theme — they're a complete team working together.
|
||||
|
||||
### BMM Agent Overview
|
||||
|
||||
| Agent | Name | Role | Responsible For |
|
||||
|-------|------|------|-----------------|
|
||||
| PM | John | Product Manager | PRDs, requirements, user stories |
|
||||
| Architect | Winston | System Architect | Technical design, architecture |
|
||||
| UX | | UX Designer | User research, UX design |
|
||||
| Dev | | Developer | Implementation, coding |
|
||||
| TEA | | Test Engineer Architect | Test architecture, QA |
|
||||
| SM | | Scrum Master | Sprint planning, workflow status |
|
||||
| Tech Writer | | Technical Writer | Documentation |
|
||||
| Analyst | | Business Analyst | Analysis, metrics |
|
||||
| Quick Flow | | Solo Developer | Quick standalone work |
|
||||
|
||||
### Key Patterns
|
||||
|
||||
1. **Shared commands** — All agents have `[WS]` Workflow Status
|
||||
2. **Specialty commands** — Each agent has unique commands (PM→PRD, Architect→Architecture)
|
||||
3. **No overlap** — Each command has one clear owner
|
||||
4. **Collaboration** — Agents reference each other's work (PRD → Architecture → Implementation)
|
||||
|
||||
---
|
||||
|
||||
## Planning Your Agents
|
||||
|
||||
### For Each Agent, Document:
|
||||
|
||||
1. **Role** — What is this agent responsible for?
|
||||
2. **Workflows** — Which workflows will this agent trigger/own?
|
||||
3. **Human Name** — What's their persona name? (e.g., "John", "Winston")
|
||||
4. **Communication Style** — How do they talk? (e.g., "Direct and data-sharp", "Calm and pragmatic")
|
||||
5. **Skills/Expertise** — What knowledge does this agent bring?
|
||||
6. **Memory/Learning** — Does this agent need to remember things over time? (hasSidecar)
|
||||
|
||||
That's it! The agent-builder workflow will handle the detailed implementation.
|
||||
|
||||
---
|
||||
|
||||
## Agent Memory & Learning
|
||||
|
||||
### Sidecar Agents (hasSidecar: true)
|
||||
|
||||
**Use when:** The agent needs to remember context across sessions.
|
||||
|
||||
**Characteristics:**
|
||||
- Has a sidecar file that persists between conversations
|
||||
- Learns from user interactions
|
||||
- Remembers project details, preferences, past work
|
||||
|
||||
**Examples:**
|
||||
- An agent that tracks project decisions over time
|
||||
- An agent that learns user preferences
|
||||
- An agent that maintains ongoing project context
|
||||
|
||||
### Stateless Agents (hasSidecar: false)
|
||||
|
||||
**Use when:** The agent doesn't need persistent memory.
|
||||
|
||||
**Characteristics:**
|
||||
- Each conversation starts fresh
|
||||
- Relies on shared context files (like project-context.md)
|
||||
- Simpler, more predictable
|
||||
|
||||
**Most module agents are stateless** — they reference shared project context rather than maintaining their own memory.
|
||||
|
||||
---
|
||||
|
||||
## Agent-Workflow Coordination
|
||||
|
||||
### Menu Triggers
|
||||
|
||||
Each agent has menu items that trigger workflows:
|
||||
|
||||
| Trigger Type | Pattern | Example |
|
||||
|--------------|---------|---------|
|
||||
| Shared | Same across all agents | `[WS]` Workflow Status |
|
||||
| Specialty | Unique to this agent | `[PR]` Create PRD (PM only) |
|
||||
| Cross-reference | Points to another agent's workflow | "See architecture" |
|
||||
|
||||
### Simple Planning Format
|
||||
|
||||
For each agent, just document:
|
||||
|
||||
```
|
||||
Agent: PM (John)
|
||||
Role: Product Manager, requirements, PRDs
|
||||
Triggers:
|
||||
- WS → Workflow Status (shared)
|
||||
- PR → Create PRD (specialty)
|
||||
- ES → Epics and Stories (specialty)
|
||||
Memory: No (uses shared project-context)
|
||||
```
|
||||
|
||||
The agent-builder workflow will convert this into the proper format.
|
||||
|
||||
---
|
||||
|
||||
## When to Use Multiple Agents
|
||||
|
||||
**Consider multiple agents when:**
|
||||
- Different workflows require different expertise
|
||||
- The domain has clear specialization areas
|
||||
- Users would expect to talk to different "experts"
|
||||
- The module covers a broad process (like software development)
|
||||
|
||||
**Use a single agent when:**
|
||||
- The domain is focused and narrow
|
||||
- One expertise area covers all workflows
|
||||
- Simplicity is preferred
|
||||
- The agent could reasonably handle everything with a sidecar
|
||||
|
||||
---
|
||||
|
||||
## Quick Agent Planning Checklist
|
||||
|
||||
For each agent in your module:
|
||||
|
||||
- [ ] Role defined (what they're responsible for)
|
||||
- [ ] Workflows assigned (which workflows they trigger)
|
||||
- [ ] Human name chosen (persona)
|
||||
- [ ] Communication style described
|
||||
- [ ] Skills/expertise identified
|
||||
- [ ] Memory decision (hasSidecar: true/false)
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **Don't worry about the exact YAML format** — agent-builder handles that
|
||||
- **Focus on the planning** — who does what, how they work together
|
||||
- **Keep it high-level** — this is about the module's agent architecture, not implementation details
|
||||
- **BMM is the reference** — look at how their agents form a cohesive team
|
||||
79
_bmad/bmb/workflows/module/data/agent-spec-template.md
Normal file
79
_bmad/bmb/workflows/module/data/agent-spec-template.md
Normal file
@@ -0,0 +1,79 @@
|
||||
# Agent Specification: {agent_name}
|
||||
|
||||
**Module:** {module_code}
|
||||
**Status:** Placeholder — To be created via create-agent workflow
|
||||
**Created:** {date}
|
||||
|
||||
---
|
||||
|
||||
## Agent Metadata
|
||||
|
||||
```yaml
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/{module_code}/agents/{agent_file_name}.md"
|
||||
name: {agent_human_name}
|
||||
title: {agent_title}
|
||||
icon: {agent_icon}
|
||||
module: {module_code}
|
||||
hasSidecar: false
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Persona
|
||||
|
||||
### Role
|
||||
|
||||
{agent_role}
|
||||
|
||||
### Identity
|
||||
|
||||
{agent_identity}
|
||||
|
||||
### Communication Style
|
||||
|
||||
{agent_communication_style}
|
||||
|
||||
### Principles
|
||||
|
||||
{agent_principles}
|
||||
|
||||
---
|
||||
|
||||
## Agent Menu
|
||||
|
||||
### Planned Commands
|
||||
|
||||
| Trigger | Command | Description | Workflow |
|
||||
|---------|---------|-------------|----------|
|
||||
{agent_menu_table}
|
||||
|
||||
---
|
||||
|
||||
## Agent Integration
|
||||
|
||||
### Shared Context
|
||||
|
||||
- References: `{shared_context_files}`
|
||||
- Collaboration with: {collaborating_agents}
|
||||
|
||||
### Workflow References
|
||||
|
||||
{workflow_references}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Use the create-agent workflow to build this agent.**
|
||||
|
||||
Inputs needed:
|
||||
- Agent name and human name
|
||||
- Role and expertise area
|
||||
- Communication style preferences
|
||||
- Menu commands and workflow mappings
|
||||
|
||||
---
|
||||
|
||||
_Spec created on {date} via BMAD Module workflow_
|
||||
263
_bmad/bmb/workflows/module/data/module-standards.md
Normal file
263
_bmad/bmb/workflows/module/data/module-standards.md
Normal file
@@ -0,0 +1,263 @@
|
||||
# Module Standards
|
||||
|
||||
**Purpose:** Defines what a BMAD module is, its structure, and the three types of modules.
|
||||
|
||||
---
|
||||
|
||||
## What is a BMAD Module?
|
||||
|
||||
A **BMAD module** is a self-contained package of functionality that extends the BMAD framework. Modules provide:
|
||||
- **Agents** — AI personas with specialized expertise and menu-driven commands
|
||||
- **Workflows** — Structured processes for accomplishing complex tasks
|
||||
- **Configuration** — module.yaml for user customization
|
||||
|
||||
---
|
||||
|
||||
## Module Types
|
||||
|
||||
### 1. Standalone Module
|
||||
|
||||
A new, independent module focused on a specific domain.
|
||||
|
||||
**Characteristics:**
|
||||
- Own module code (e.g., `healthcare-ai`, `legal-assist`)
|
||||
- Independent of other modules
|
||||
- Can be installed alongside any other modules
|
||||
- Has its own agents, workflows, configuration
|
||||
|
||||
**Location:** `src/modules/{module-code}/`
|
||||
|
||||
**Example:** CIS (Creative Innovation Suite) — a standalone module for innovation workflows
|
||||
|
||||
---
|
||||
|
||||
### 2. Extension Module
|
||||
|
||||
Extends an existing BMAD module with additional functionality.
|
||||
|
||||
**Characteristics:**
|
||||
- Builds upon an existing module's agents and workflows
|
||||
- May add new agents or workflows that complement the base module
|
||||
- Shares configuration context with the extended module
|
||||
- Typically installed alongside the module it extends
|
||||
|
||||
**Location:** `src/modules/{base-module}/extensions/{extension-code}/`
|
||||
|
||||
**Example:** An extension to BMM that adds specialized security review workflows
|
||||
|
||||
---
|
||||
|
||||
### Extension Module: Override & Merge Pattern
|
||||
|
||||
When an extension module is installed, its files merge with the base module following these rules:
|
||||
|
||||
#### Code Matching
|
||||
|
||||
The extension's `module.yaml` `code:` field matches the base module's code:
|
||||
|
||||
```yaml
|
||||
# Base module: src/modules/bmm/module.yaml
|
||||
code: bmm
|
||||
|
||||
# Extension: src/modules/bmm/extensions/security/module.yaml
|
||||
code: bmm # SAME CODE — extends BMM
|
||||
```
|
||||
|
||||
The **folder name** is unique (e.g., `bmm-security`) but the `code:` matches the base module.
|
||||
|
||||
#### File Merge Rules
|
||||
|
||||
| File Type | Same Name | Different Name |
|
||||
|-----------|-----------|----------------|
|
||||
| Agent file | **OVERRIDE** — replaces the base agent | **ADD** — new agent added |
|
||||
| Workflow folder | **OVERRIDE** — replaces the base workflow | **ADD** — new workflow added |
|
||||
| Other files | **OVERRIDE** — replaces base file | **ADD** — new file added |
|
||||
|
||||
#### Examples
|
||||
|
||||
**Override scenario:**
|
||||
```
|
||||
Base module (BMM):
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Original PM agent
|
||||
|
||||
Extension (bmm-security):
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Security-focused PM — REPLACES original
|
||||
|
||||
Result after installation:
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Now the security version
|
||||
```
|
||||
|
||||
**Add scenario:**
|
||||
```
|
||||
Base module (BMM):
|
||||
├── agents/
|
||||
│ ├── pm.agent.yaml
|
||||
│ └── architect.agent.yaml
|
||||
|
||||
Extension (bmm-security):
|
||||
├── agents/
|
||||
│ └── security-auditor.agent.yaml # NEW agent
|
||||
|
||||
Result after installation:
|
||||
├── agents/
|
||||
│ ├── pm.agent.yaml
|
||||
│ ├── architect.agent.yaml
|
||||
│ └── security-auditor.agent.yaml # ADDED
|
||||
```
|
||||
|
||||
**Mixed scenario:**
|
||||
```
|
||||
Extension contains both overrides and new files — applies rules per file
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Global Module
|
||||
|
||||
Affects the entire BMAD framework and all modules.
|
||||
|
||||
**Characteristics:**
|
||||
- Core functionality that impacts all modules
|
||||
- Often provides foundational services or utilities
|
||||
- Installed at the framework level
|
||||
- Use sparingly — only for truly global concerns
|
||||
|
||||
**Location:** `src/modules/{module-code}/` with `global: true` in module.yaml
|
||||
|
||||
**Example:** A module that provides universal logging or telemetry across BMAD
|
||||
|
||||
---
|
||||
|
||||
## Required Module Structure
|
||||
|
||||
```
|
||||
{module-code}/
|
||||
├── module.yaml # Module configuration (REQUIRED)
|
||||
├── README.md # Module documentation (REQUIRED)
|
||||
├── agents/ # Agent definitions (if any)
|
||||
│ └── {agent-name}.agent.yaml
|
||||
├── workflows/ # Workflow definitions (if any)
|
||||
│ └── {workflow-name}/
|
||||
│ └── workflow.md
|
||||
└── {other folders} # Tasks, templates, data as needed
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Required Files
|
||||
|
||||
### module.yaml (REQUIRED)
|
||||
|
||||
Every module MUST have a `module.yaml` file with at minimum:
|
||||
|
||||
```yaml
|
||||
code: {module-code}
|
||||
name: "Module Display Name"
|
||||
header: "Brief module description"
|
||||
subheader: "Additional context"
|
||||
default_selected: false
|
||||
```
|
||||
|
||||
See: `module-yaml-conventions.md` for full specification.
|
||||
|
||||
---
|
||||
|
||||
### README.md (REQUIRED)
|
||||
|
||||
Every module MUST have a README.md with:
|
||||
- Module name and purpose
|
||||
- Installation instructions
|
||||
- Components section (agents, workflows)
|
||||
- Quick start guide
|
||||
- Module structure diagram
|
||||
- Configuration section
|
||||
- Usage examples
|
||||
- Author information
|
||||
|
||||
---
|
||||
|
||||
## Optional Components
|
||||
|
||||
### Agents
|
||||
|
||||
Agents are AI personas with:
|
||||
- Metadata (id, name, title, icon, module)
|
||||
- Persona (role, identity, communication_style, principles)
|
||||
- Menu (trigger → workflow/exec mappings)
|
||||
|
||||
See: `agent-architecture.md` for design guidance.
|
||||
|
||||
---
|
||||
|
||||
### Workflows
|
||||
|
||||
Workflows are structured processes with:
|
||||
- workflow.md (entry point)
|
||||
- steps/ folder with step files
|
||||
- data/ folder with shared reference
|
||||
- templates/ folder if needed
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Module Type Decision Tree
|
||||
|
||||
```
|
||||
START: Creating a module
|
||||
│
|
||||
├─ Is this a brand new independent domain?
|
||||
│ └─ YES → Standalone Module
|
||||
│
|
||||
├─ Does this extend an existing module?
|
||||
│ └─ YES → Extension Module
|
||||
│
|
||||
└─ Does this affect all modules globally?
|
||||
└─ YES → Global Module (use sparingly)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
### Module Code
|
||||
|
||||
- **kebab-case** (e.g., `bmm`, `cis`, `bmgd`, `healthcare-ai`)
|
||||
- Short, memorable, descriptive
|
||||
- 2-20 characters
|
||||
- Lowercase letters, numbers, hyphens only
|
||||
|
||||
### Agent Files
|
||||
|
||||
- Format: `{role-name}.agent.yaml`
|
||||
- Example: `pm.agent.yaml`, `architect.agent.yaml`
|
||||
|
||||
### Workflow Folders
|
||||
|
||||
- Format: `{workflow-name}/`
|
||||
- Example: `prd/`, `create-architecture/`
|
||||
|
||||
---
|
||||
|
||||
## Module Dependencies
|
||||
|
||||
Modules can depend on:
|
||||
- **Core BMAD** — Always available
|
||||
- **Other modules** — Specify in module.yaml as `dependencies:`
|
||||
- **External tools** — Document in README
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Question | Answer |
|
||||
|----------|--------|
|
||||
| What's a module? | Self-contained package of agents, workflows, config |
|
||||
| What are the types? | Standalone, Extension, Global |
|
||||
| What's required? | module.yaml, README.md |
|
||||
| Where do modules live? | `src/modules/{code}/` |
|
||||
| How do agents work? | Menu triggers → workflow/exec |
|
||||
| How does installation work? | module.yaml prompts |
|
||||
392
_bmad/bmb/workflows/module/data/module-yaml-conventions.md
Normal file
392
_bmad/bmb/workflows/module/data/module-yaml-conventions.md
Normal file
@@ -0,0 +1,392 @@
|
||||
# module.yaml Conventions
|
||||
|
||||
**Purpose:** Defines how module.yaml works, including variables, templates, and how they provide context to agents and workflows.
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
`module.yaml` is the configuration file for a BMAD module. It:
|
||||
- Defines module metadata (code, name, description)
|
||||
- Collects user input via prompts during installation
|
||||
- Makes those inputs available to agents and workflows as variables
|
||||
- Specifies which module should be selected by default
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Fields
|
||||
|
||||
### Required Fields
|
||||
|
||||
```yaml
|
||||
code: {module-code} # kebab-case identifier
|
||||
name: "Display Name" # Human-readable name
|
||||
header: "Brief description" # One-line summary
|
||||
subheader: "Additional context" # More detail
|
||||
default_selected: false # Auto-select on install?
|
||||
```
|
||||
|
||||
### `default_selected` Guidelines
|
||||
|
||||
| Module Type | default_selected | Example |
|
||||
|-------------|------------------|---------|
|
||||
| Core/Primary | `true` | BMM (agile software delivery) |
|
||||
| Specialized | `false` | CIS (creative innovation), BMGD (game dev) |
|
||||
| Experimental | `false` | New modules in development |
|
||||
|
||||
---
|
||||
|
||||
## Variables System
|
||||
|
||||
### Core Config Variables (Always Available)
|
||||
|
||||
These variables are automatically available to ALL modules:
|
||||
|
||||
```yaml
|
||||
# Variables from Core Config inserted:
|
||||
## user_name # User's name
|
||||
## communication_language # Preferred language
|
||||
## document_output_language # Output document language
|
||||
## output_folder # Default output location
|
||||
```
|
||||
|
||||
No need to define these — they're injected automatically.
|
||||
|
||||
---
|
||||
|
||||
### Custom Variables
|
||||
|
||||
Define custom variables for user input:
|
||||
|
||||
```yaml
|
||||
variable_name:
|
||||
prompt: "Question to ask the user?"
|
||||
default: "{default_value}"
|
||||
result: "{template_for_final_value}"
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```yaml
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
### Variable Templates
|
||||
|
||||
In `prompt` and `result`, you can use templates:
|
||||
|
||||
| Template | Expands To |
|
||||
|----------|------------|
|
||||
| `{value}` | The user's input |
|
||||
| `{directory_name}` | Current directory name |
|
||||
| `{output_folder}` | Output folder from core config |
|
||||
| `{project-root}` | Project root path |
|
||||
| `{variable_name}` | Another variable's value |
|
||||
|
||||
---
|
||||
|
||||
## Variable Types
|
||||
|
||||
### 1. Simple Text Input
|
||||
|
||||
```yaml
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Boolean/Flag
|
||||
|
||||
```yaml
|
||||
enable_feature:
|
||||
prompt: "Enable this feature?"
|
||||
default: false
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Single Select
|
||||
|
||||
```yaml
|
||||
skill_level:
|
||||
prompt: "What is your experience level?"
|
||||
default: "intermediate"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "beginner"
|
||||
label: "Beginner - Explains concepts clearly"
|
||||
- value: "intermediate"
|
||||
label: "Intermediate - Balanced approach"
|
||||
- value: "expert"
|
||||
label: "Expert - Direct and technical"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. Multi Select
|
||||
|
||||
```yaml
|
||||
platforms:
|
||||
prompt: "Which platforms do you need?"
|
||||
default: ["unity", "unreal"]
|
||||
result: "{value}"
|
||||
multi-select:
|
||||
- value: "unity"
|
||||
label: "Unity"
|
||||
- value: "unreal"
|
||||
label: "Unreal Engine"
|
||||
- value: "godot"
|
||||
label: "Godot"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. Multi-Line Prompt
|
||||
|
||||
```yaml
|
||||
complex_variable:
|
||||
prompt:
|
||||
- "First question?"
|
||||
- "Second context?"
|
||||
- "Third detail?"
|
||||
default: "default_value"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. Required Variable
|
||||
|
||||
```yaml
|
||||
critical_variable:
|
||||
prompt: "Required information:"
|
||||
required: true
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. Path Variable
|
||||
|
||||
```yaml
|
||||
artifacts_folder:
|
||||
prompt: "Where should artifacts be stored?"
|
||||
default: "{output_folder}/artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Variable Inheritance / Aliasing
|
||||
|
||||
Create an alias for another variable:
|
||||
|
||||
```yaml
|
||||
primary_artifacts:
|
||||
prompt: "Where should primary artifacts be stored?"
|
||||
default: "{output_folder}/artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
# Alias for workflow compatibility
|
||||
sprint_artifacts:
|
||||
inherit: "primary_artifacts"
|
||||
```
|
||||
|
||||
Now `sprint_artifacts` and `primary_artifacts` reference the same value.
|
||||
|
||||
---
|
||||
|
||||
## How Variables Become Available
|
||||
|
||||
### To Agents
|
||||
|
||||
After installation, variables are available in agent frontmatter/context:
|
||||
|
||||
```yaml
|
||||
# In agent.agent.yaml or workflow execution
|
||||
{variable_name} # Expands to the user's configured value
|
||||
```
|
||||
|
||||
**Example:** If the user configured `project_name: "MyApp"`, agents can reference `{project_name}` and it will expand to `"MyApp"`.
|
||||
|
||||
### To Workflows
|
||||
|
||||
Workflows can reference module variables in their step files:
|
||||
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{implementation_artifacts}/my-output.md'
|
||||
---
|
||||
```
|
||||
|
||||
This expands the `implementation_artifacts` variable from module.yaml.
|
||||
|
||||
---
|
||||
|
||||
## Real-World Examples
|
||||
|
||||
### BMM (BMad Method) — Complex Configuration
|
||||
|
||||
```yaml
|
||||
code: bmm
|
||||
name: "BMM: BMad Method Agile-AI Driven-Development"
|
||||
header: "BMad Method™: Breakthrough Method of Agile-Ai Driven-Dev"
|
||||
subheader: "Agent and Workflow Configuration for this module"
|
||||
default_selected: true
|
||||
|
||||
# Variables from Core Config inserted:
|
||||
## user_name
|
||||
## communication_language
|
||||
## document_output_language
|
||||
## output_folder
|
||||
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
|
||||
user_skill_level:
|
||||
prompt:
|
||||
- "What is your development experience level?"
|
||||
- "This affects how agents explain concepts."
|
||||
default: "intermediate"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "beginner"
|
||||
label: "Beginner - Explain concepts clearly"
|
||||
- value: "intermediate"
|
||||
label: "Intermediate - Balanced approach"
|
||||
- value: "expert"
|
||||
label: "Expert - Direct and technical"
|
||||
|
||||
planning_artifacts:
|
||||
prompt: "Where should planning artifacts be stored?"
|
||||
default: "{output_folder}/planning-artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
implementation_artifacts:
|
||||
prompt: "Where should implementation artifacts be stored?"
|
||||
default: "{output_folder}/implementation-artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
project_knowledge:
|
||||
prompt: "Where should project knowledge be stored?"
|
||||
default: "docs"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
tea_use_mcp_enhancements:
|
||||
prompt: "Enable MCP enhancements in Test Architect?"
|
||||
default: false
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### CIS (Creative Innovation Suite) — Minimal Configuration
|
||||
|
||||
```yaml
|
||||
code: cis
|
||||
name: "CIS: Creative Innovation Suite"
|
||||
header: "Creative Innovation Suite (CIS) Module"
|
||||
subheader: "No custom configuration - uses Core settings only"
|
||||
default_selected: false
|
||||
|
||||
# Variables from Core Config inserted:
|
||||
## user_name
|
||||
## communication_language
|
||||
## document_output_language
|
||||
## output_folder
|
||||
```
|
||||
|
||||
Some modules don't need custom variables — core config is enough!
|
||||
|
||||
---
|
||||
|
||||
### BMGD (Game Development) — Multi-Select Example
|
||||
|
||||
```yaml
|
||||
code: bmgd
|
||||
name: "BMGD: BMad Game Development"
|
||||
header: "BMad Game Development Module"
|
||||
subheader: "Configure game development settings"
|
||||
default_selected: false
|
||||
|
||||
project_name:
|
||||
prompt: "What is the name of your game project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
|
||||
primary_platform:
|
||||
prompt: "Which game engine do you use?"
|
||||
default: ["unity", "unreal"]
|
||||
required: true
|
||||
result: "{value}"
|
||||
multi-select:
|
||||
- value: "unity"
|
||||
label: "Unity"
|
||||
- value: "unreal"
|
||||
label: "Unreal Engine"
|
||||
- value: "godot"
|
||||
label: "Godot"
|
||||
- value: "other"
|
||||
label: "Custom / Other"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO:
|
||||
- Keep prompts clear and concise
|
||||
- Provide sensible defaults
|
||||
- Use `result: "{project-root}/{value}"` for paths
|
||||
- Use single/multi-select for structured choices
|
||||
- Group related variables logically
|
||||
|
||||
### DON'T:
|
||||
- Overwhelm users with too many questions
|
||||
- Ask for information that could be inferred
|
||||
- Use technical jargon in prompts
|
||||
- Create variables that are never used
|
||||
|
||||
---
|
||||
|
||||
## Variable Naming
|
||||
|
||||
- **kebab-case** (e.g., `planning_artifacts`, `user_skill_level`)
|
||||
- Descriptive but concise
|
||||
- Avoid conflicts with core variables
|
||||
|
||||
---
|
||||
|
||||
## Testing Your module.yaml
|
||||
|
||||
After creating module.yaml, test it:
|
||||
|
||||
1. Run `bmad install` in a test project
|
||||
2. Verify prompts appear correctly
|
||||
3. Check that variables expand in agents/workflows
|
||||
4. Test default values
|
||||
5. Validate path templates resolve correctly
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Pattern | Use Case |
|
||||
|---------|----------|
|
||||
| Simple text input | Names, titles, descriptions |
|
||||
| Boolean/Flag | Enable/disable features |
|
||||
| Single select | Experience levels, categories |
|
||||
| Multi select | Platforms, frameworks, options |
|
||||
| Multi-line prompt | Complex questions needing context |
|
||||
| Required | Must-have information |
|
||||
| Path variable | Directory locations |
|
||||
| Inherit/Alias | Compatibility, references |
|
||||
Reference in New Issue
Block a user