research will use the web more, use system date to understand what the read current date is.

This commit is contained in:
Brian Madison
2025-11-01 00:14:41 -05:00
parent a1be5d7292
commit 4f4b191e8f
79 changed files with 1498 additions and 8553 deletions

View File

@@ -1,21 +0,0 @@
# Audit Workflow Configuration
name: "audit-workflow"
description: "Comprehensive workflow quality audit - validates structure, config standards, variable usage, bloat detection, and web_bundle completeness. Performs deep analysis of workflow.yaml, instructions.md, template.md, and web_bundle configuration against BMAD v6 standards."
author: "BMad"
# Critical variables from config
config_source: "{project-root}/bmad/bmb/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
date: system-generated
# Module path and component files
installed_path: "{project-root}/bmad/bmb/workflows/audit-workflow"
template: false
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Output configuration
default_output_file: "{output_folder}/audit-report-{{workflow_name}}-{{date}}.md"
# Web bundle configuration

View File

@@ -1,320 +1,203 @@
# Build Agent
# Create Agent Workflow
## Overview
Interactive agent builder creating BMad Core compliant agents as YAML source files that compile to .md during installation.
The Build Agent workflow is an interactive agent builder that guides you through creating BMAD Core compliant agents as YAML source files that compile to final `.md` during install. It supports three agent types: Simple (self-contained), Expert (with sidecar resources), and Module (full-featured with workflows).
## Table of Contents
## Key Features
- [Quick Start](#quick-start)
- [Agent Types](#agent-types)
- [Workflow Phases](#workflow-phases)
- [Output Structure](#output-structure)
- [Installation](#installation)
- [Examples](#examples)
- **Optional Brainstorming**: Creative ideation session before agent building to explore concepts and personalities
- **Three Agent Types**: Simple, Expert, and Module agents with appropriate structures
- **Persona Development**: Guided creation of role, identity, communication style, and principles
- **Command Builder**: Interactive command definition with workflow/task/action patterns
- **Validation Built-In**: Ensures YAML structure and BMAD Core compliance
- **Customize Support**: Optional `customize.yaml` for persona/menu overrides and critical actions
- **Sidecar Resources**: Setup for Expert agents with domain-specific data
## Usage
### Basic Invocation
## Quick Start
```bash
# Direct workflow
workflow create-agent
```
### Through BMad Builder Agent
```
# Via BMad Builder
*create-agent
```
### With Brainstorming Session
## Agent Types
The workflow includes an optional brainstorming phase (Step -1) that helps you explore agent concepts, personalities, and capabilities before building. This is particularly useful when you have a vague idea and want to develop it into a concrete agent concept.
### Simple Agent
### What You'll Be Asked
- Self-contained functionality
- Basic command structure
- No external resources
0. **Optional brainstorming** (vague idea → refined concept)
1. Agent type (Simple, Expert, or Module)
2. Basic identity (name, title, icon, filename)
3. Module assignment (for Module agents)
4. Sidecar resources (for Expert agents)
5. Persona elements (role, identity, style, principles)
6. Commands and their implementations
7. Critical actions (optional)
8. Activation rules (optional, rarely needed)
### Expert Agent
## Workflow Structure
- Sidecar resources for domain knowledge
- Extended capabilities
- Knowledge base integration
### Files Included
### Module Agent
```
create-agent/
├── workflow.yaml # Configuration
├── instructions.md # Step-by-step guide
├── checklist.md # Validation criteria
├── README.md # This file
├── agent-types.md # Agent type documentation
├── agent-architecture.md # Architecture patterns
├── agent-command-patterns.md # Command patterns reference
└── communication-styles.md # Style examples
```
- Full-featured with workflows
- Module-specific commands
- Integrated with module structure
## Workflow Process
## Workflow Phases
### Phase 0: Optional Brainstorming (Step -1)
### Phase 0: Optional Brainstorming
- Creative ideation session using diverse brainstorming techniques
- Explore agent concepts, personalities, and capabilities
- Generate character ideas, expertise areas, and command concepts
- Output feeds directly into agent identity and persona development
- Creative ideation session
- Explore concepts and personalities
- Generate command ideas
- Output feeds into persona development
### Phase 1: Agent Setup (Steps 0-2)
### Phase 1: Agent Setup
- Load agent building documentation and patterns
- Choose agent type (Simple/Expert/Module)
- Define basic identity (name, title, icon, filename) - informed by brainstorming if completed
- Assign to module (for Module agents)
1. Choose agent type (Simple/Expert/Module)
2. Define identity (name, title, icon, filename)
3. Assign to module (if Module agent)
### Phase 2: Persona Development (Steps 2-3)
### Phase 2: Persona Development
- Define role and responsibilities - leveraging brainstorming insights if available
- Craft unique identity and backstory
- Select communication style - can use brainstormed personality concepts
- Define role and responsibilities
- Craft unique identity/backstory
- Select communication style
- Establish guiding principles
- Add critical actions (optional)
### Phase 3: Command Building (Step 4)
### Phase 3: Command Building
- Add *help and *exit commands (required)
- Define workflow commands (most common)
- Add task commands (for single operations)
- Create action commands (inline logic)
- Configure command attributes
- Add required commands (*help, *exit)
- Define workflow commands
- Add task commands
- Create action commands
- Configure attributes
### Phase 4: Finalization (Steps 5-10)
### Phase 4: Finalization
- Confirm activation behavior (mostly automatic)
- Generate `.agent.yaml` file
- Optionally create a customize file for overrides
- Setup sidecar resources (for Expert agents)
- Validate YAML and compile to `.md`
- Generate .agent.yaml file
- Create customize file (optional)
- Setup sidecar resources (Expert agents)
- Validate and compile
- Provide usage instructions
## Output
## Output Structure
### Generated Files
#### For Standalone Agents (not part of a module)
**Standalone Agents:**
- **YAML Source**: `{custom_agent_location}/{{agent_filename}}.agent.yaml` (default: `bmad/agents/`)
- **Installation Location**: `{project-root}/bmad/agents/{{agent_filename}}.md`
- **Compilation**: Run the BMAD Method installer and select "Compile Agents (Quick rebuild of all agent .md files)"
- Source: `bmad/agents/{filename}.agent.yaml`
- Compiled: `bmad/agents/{filename}.md`
#### For Module Agents
**Module Agents:**
- **YAML Source**: `src/modules/{{target_module}}/agents/{{agent_filename}}.agent.yaml`
- **Installation Location**: `{project-root}/bmad/{{module}}/agents/{{agent_filename}}.md`
- **Compilation**: Automatic during module installation
- Source: `src/modules/{module}/agents/{filename}.agent.yaml`
- Compiled: `bmad/{module}/agents/{filename}.md`
### YAML Agent Structure (simplified)
### YAML Structure
```yaml
agent:
metadata:
id: bmad/{{module}}/agents/{{agent_filename}}.md
name: { { agent_name } }
title: { { agent_title } }
icon: { { agent_icon } }
module: { { module } }
id: bmad/{module}/agents/{filename}.md
name: Agent Name
title: Agent Title
icon: 🤖
module: module-name
persona:
role: '...'
identity: '...'
communication_style: '...'
principles: ['...', '...']
menu:
- trigger: example
workflow: '{project-root}/path/to/workflow.yaml'
description: Do the thing
- trigger: command-name
workflow: path/to/workflow.yaml
description: Command description
```
### Optional Customize File
If created, generates at:
`{project-root}/bmad/_cfg/agents/{{module}}-{{agent_filename}}.customize.yaml`
Location: `bmad/_cfg/agents/{module}-{filename}.customize.yaml`
## Installation and Compilation
Allows persona and menu overrides that persist through updates.
### Agent Installation Locations
## Installation
Agents are installed to different locations based on their type:
### Compilation Methods
1. **Standalone Agents** (not part of a module)
- Source: Created in your custom agent location (default: `bmad/agents/`)
- Installed to: `{project-root}/bmad/agents/`
- Compilation: Run BMAD Method installer and select "Compile Agents"
2. **Module Agents** (part of BMM, BMB, or custom modules)
- Source: Created in `src/modules/{module}/agents/`
- Installed to: `{project-root}/bmad/{module}/agents/`
- Compilation: Automatic during module installation
### Compilation Process
The installer compiles YAML agent definitions to Markdown:
**Quick Rebuild:**
```bash
# For standalone agents
npm run build:agents
# For all BMad components (includes agents)
npm run install:bmad
# Using the installer menu
npm run installer
# Then select: Compile Agents
bmad compile-agents
```
### Build Commands
**During Module Install:**
Automatic compilation when installing modules
Additional build commands for agent management:
**Manual Compilation:**
```bash
# Build specific agent types
npx bmad-method build:agents # Build standalone agents
npx bmad-method build:modules # Build module agents (with modules)
# Full rebuild
npx bmad-method build:all # Rebuild everything
node tools/cli/bmad-cli.js compile-agents
```
## Requirements
## Examples
- BMAD Core v6 project structure
- Module to host the agent (for Module agents)
- Understanding of agent purpose and commands
- Workflows/tasks to reference in commands (or mark as "todo")
### Creating a Code Review Agent
## Brainstorming Integration
```
User: I need a code review agent
Builder: Let's brainstorm first...
The optional brainstorming phase (Step -1) provides a seamless path from vague idea to concrete agent concept:
[Brainstorming generates ideas for strict vs friendly reviewer]
### When to Use Brainstorming
Builder: Now let's build your agent:
- Type: Simple
- Name: Code Reviewer
- Role: Senior developer conducting thorough reviews
- Style: Professional but approachable
- Commands:
- *review-pr: Review pull request
- *review-file: Review single file
- *review-standards: Check coding standards
```
- **Vague concept**: "I want an agent that helps with data stuff"
- **Creative exploration**: Want to discover unique personality and approach
- **Team building**: Creating agents for a module with specific roles
- **Character development**: Need to flesh out agent personality and voice
### Creating a Domain Expert
### Brainstorming Flow
```
Type: Expert
Name: Legal Advisor
Sidecar: legal-knowledge/
Commands:
- *contract-review
- *compliance-check
- *risk-assessment
```
1. **Step -1**: Optional brainstorming session
- Uses CIS brainstorming workflow with agent-specific context
- Explores identity, personality, expertise, and command concepts
- Generates detailed character and capability ideas
## Workflow Files
2. **Steps 0-2**: Agent setup informed by brainstorming
- Brainstorming output guides agent type selection
- Character concepts inform basic identity choices
- Personality insights shape persona development
3. **Seamless transition**: Vague idea → brainstormed concept → built agent
### Key Principle
Users can go from **vague idea → brainstormed concept → built agent** in one continuous flow, with brainstorming output directly feeding into agent development.
```
create-agent/
├── workflow.yaml # Configuration
├── instructions.md # Step guide
├── checklist.md # Validation
├── README.md # This file
├── agent-types.md # Type details
├── agent-architecture.md # Patterns
├── agent-command-patterns.md # Commands
└── communication-styles.md # Styles
```
## Best Practices
### Before Starting
1. **Use brainstorming** for complex agents
2. **Start simple** - Add commands incrementally
3. **Test commands** before finalizing
4. **Document thoroughly** in descriptions
5. **Follow naming conventions** consistently
1. Review example agents in `/bmad/bmm/agents/` for patterns
2. Consider using brainstorming if you have a vague concept to develop
3. Have a clear vision of the agent's role and personality (or use brainstorming to develop it)
4. List the commands/capabilities the agent will need
5. Identify any workflows or tasks the agent will invoke
## Related Documentation
### During Execution
1. **Agent Names**: Use memorable names that reflect personality
2. **Icons**: Choose an emoji that represents the agent's role
3. **Persona**: Make it distinct and consistent with communication style
4. **Commands**: Use kebab-case, start custom commands with letter (not \*)
5. **Workflows**: Reference existing workflows or mark as "todo" to implement later
### After Completion
1. **Compile the agent**:
- For standalone agents: Run `npm run build:agents` or use the installer menu
- For module agents: Automatic during module installation
2. **Test the agent**: Use the compiled `.md` agent in your IDE
3. **Implement placeholders**: Complete any "todo" workflows referenced
4. **Refine as needed**: Use customize file for persona adjustments
5. **Evolve over time**: Add new commands as requirements emerge
## Agent Types
### Simple Agent
- **Best For**: Self-contained utilities, simple assistants
- **Characteristics**: Embedded logic, no external dependencies
- **Example**: Calculator agent, random picker, simple formatter
### Expert Agent
- **Best For**: Domain-specific agents with data/memory
- **Characteristics**: Sidecar folders, domain restrictions, memory files
- **Example**: Diary keeper, project journal, personal knowledge base
### Module Agent
- **Best For**: Full-featured agents with workflows
- **Characteristics**: Part of module, commands invoke workflows
- **Example**: Product manager, architect, research assistant
## Troubleshooting
### Issue: Agent won't load
- **Solution**: Validate XML structure is correct
- **Check**: Ensure all required tags present (persona, cmds)
### Issue: Commands don't work
- **Solution**: Verify workflow paths are correct or marked "todo"
- **Check**: Test workflow invocation separately first
### Issue: Persona feels generic
- **Solution**: Review communication styles guide
- **Check**: Make identity unique and specific to role
## Customization
To modify agent building process:
1. Edit `instructions.md` to change steps
2. Update `agent-types.md` to add new agent patterns
3. Modify `agent-command-patterns.md` for new command types
4. Edit `communication-styles.md` to add personality examples
## Version History
- **v6.0.0** - BMAD Core v6 compatible
- Three agent types (Simple/Expert/Module)
- Enhanced persona development
- Command pattern library
- Validation framework
## Support
For issues or questions:
- Review example agents in `/bmad/bmm/agents/`
- Check agent documentation in this workflow folder
- Test with simple agents first, then build complexity
- Consult BMAD Method v6 documentation
---
_Part of the BMad Method v6 - BMB (BMad Builder) Module_
- [Agent Types](./agent-types.md)
- [Command Patterns](./agent-command-patterns.md)
- [Communication Styles](./communication-styles.md)
- [BMB Module](../../README.md)

View File

@@ -1,412 +0,0 @@
# BMAD Agent Architecture Reference
_LLM-Optimized Technical Documentation for Agent Building_
## Core Agent Structure
### Minimal Valid Agent
```xml
<!-- Powered by BMAD-CORE™ -->
# Agent Name
<agent id="path/to/agent.md" name="Name" title="Title" icon="🤖">
<persona>
<role>My primary function</role>
<identity>My background and expertise</identity>
<communication_style>How I interact</communication_style>
<principles>My core beliefs and methodology</principles>
</persona>
<menu>
<item cmd="*help">Show numbered menu</item>
<item cmd="*exit">Exit with confirmation</item>
</menu>
</agent>
```
## Agent XML Schema
### Root Element: `<agent>`
**Required Attributes:**
- `id` - Unique path identifier (e.g., "bmad/bmm/agents/analyst.md")
- `name` - Agent's name (e.g., "Mary", "John", "Helper")
- `title` - Professional title (e.g., "Business Analyst", "Security Engineer")
- `icon` - Single emoji representing the agent
### Core Sections
#### 1. Persona Section (REQUIRED)
```xml
<persona>
<role>1-2 sentences: Professional title and primary expertise, use first-person voice</role>
<identity>2-5 sentences: Background, experience, specializations, use first-person voice</identity>
<communication_style>1-3 sentences: Interaction approach, tone, quirks, use first-person voice</communication_style>
<principles>2-5 sentences: Core beliefs, methodology, philosophy, use first-person voice</principles>
</persona>
```
**Best Practices:**
- Role: Be specific about expertise area
- Identity: Include experience indicators (years, depth)
- Communication: Describe HOW they interact, not just tone and quirks
- Principles: Start with "I believe" or "I operate" for first-person voice
#### 2. Critical Actions Section
```xml
<critical-actions>
<i>Load into memory {project-root}/bmad/{module}/config.yaml and set variables</i>
<i>Remember the users name is {user_name}</i>
<i>ALWAYS communicate in {communication_language}</i>
<!-- Custom initialization actions -->
</critical-actions>
```
**For Expert Agents with Sidecars (CRITICAL):**
```xml
<critical-actions>
<!-- CRITICAL: Load sidecar files FIRST -->
<i critical="MANDATORY">Load COMPLETE file {agent-folder}/instructions.md and follow ALL directives</i>
<i critical="MANDATORY">Load COMPLETE file {agent-folder}/memories.md into permanent context</i>
<i critical="MANDATORY">You MUST follow all rules in instructions.md on EVERY interaction</i>
<!-- Standard initialization -->
<i>Load into memory {project-root}/bmad/{module}/config.yaml and set variables</i>
<i>Remember the users name is {user_name}</i>
<i>ALWAYS communicate in {communication_language}</i>
<!-- Domain restrictions -->
<i>ONLY read/write files in {user-folder}/diary/ - NO OTHER FOLDERS</i>
</critical-actions>
```
**Common Patterns:**
- Config loading for module agents
- User context initialization
- Language preferences
- **Sidecar file loading (Expert agents) - MUST be explicit and CRITICAL**
- **Domain restrictions (Expert agents) - MUST be enforced**
#### 3. Menu Section (REQUIRED)
```xml
<menu>
<item cmd="*trigger" [attributes]>Description</item>
</menu>
```
**Command Attributes:**
- `run-workflow="{path}"` - Executes a workflow
- `exec="{path}"` - Executes a task
- `tmpl="{path}"` - Template reference
- `data="{path}"` - Data file reference
**Required Menu Items:**
- `*help` - Always first, shows command list
- `*exit` - Always last, exits agent
## Advanced Agent Patterns
### Activation Rules (OPTIONAL)
```xml
<activation critical="true">
<initialization critical="true" sequential="MANDATORY">
<step n="1">Load configuration</step>
<step n="2">Apply overrides</step>
<step n="3">Execute critical actions</step>
<step n="4" critical="BLOCKING">Show greeting with menu</step>
<step n="5" critical="BLOCKING">AWAIT user input</step>
</initialization>
<command-resolution critical="true">
<rule>Numeric input → Execute command at cmd_map[n]</rule>
<rule>Text input → Fuzzy match against commands</rule>
</command-resolution>
</activation>
```
### Expert Agent Sidecar Pattern
```xml
<!-- DO NOT use sidecar-resources tag - Instead use critical-actions -->
<!-- Sidecar files MUST be loaded explicitly in critical-actions -->
<!-- Example Expert Agent with Diary domain -->
<agent id="diary-keeper" name="Personal Assistant" title="Diary Keeper" icon="📔">
<critical-actions>
<!-- MANDATORY: Load all sidecar files -->
<i critical="MANDATORY">Load COMPLETE file {agent-folder}/diary-rules.md</i>
<i critical="MANDATORY">Load COMPLETE file {agent-folder}/user-memories.md</i>
<i critical="MANDATORY">Follow ALL rules from diary-rules.md</i>
<!-- Domain restriction -->
<i critical="MANDATORY">ONLY access files in {user-folder}/diary/</i>
<i critical="MANDATORY">NEVER access files outside diary folder</i>
</critical-actions>
<persona>...</persona>
<menu>...</menu>
</agent>
```
### Module Agent Integration
```xml
<module-integration>
<module-path>{project-root}/bmad/{module-code}</module-path>
<config-source>{module-path}/config.yaml</config-source>
<workflows-path>{project-root}/bmad/{module-code}/workflows</workflows-path>
</module-integration>
```
## Variable System
### System Variables
- `{project-root}` - Root directory of project
- `{user_name}` - User's name from config
- `{communication_language}` - Language preference
- `{date}` - Current date
- `{module}` - Current module code
### Config Variables
Format: `{config_source}:variable_name`
Example: `{config_source}:output_folder`
### Path Construction
```
Good: {project-root}/bmad/{module}/agents/
Bad: /absolute/path/to/agents/
Bad: ../../../relative/paths/
```
## Command Patterns
### Workflow Commands
```xml
<!-- Full path -->
<item cmd="*create-prd" run-workflow="{project-root}/bmad/bmm/workflows/prd/workflow.yaml">
Create Product Requirements Document
</item>
<!-- Placeholder for future -->
<item cmd="*analyze" run-workflow="todo">
Perform analysis (workflow to be created)
</item>
```
### Task Commands
```xml
<item cmd="*validate" exec="{project-root}/bmad/core/tasks/validate-workflow.xml">
Validate document
</item>
```
### Template Commands
```xml
<item cmd="*brief"
exec="{project-root}/bmad/core/tasks/create-doc.md"
tmpl="{project-root}/bmad/bmm/templates/brief.md">
Create project brief
</item>
```
### Data-Driven Commands
```xml
<item cmd="*standup"
exec="{project-root}/bmad/bmm/tasks/daily-standup.xml"
data="{project-root}/bmad/_cfg/agent-manifest.csv">
Run daily standup
</item>
```
## Agent Type Specific Patterns
### Simple Agent
- Self-contained logic
- Minimal or no external dependencies
- May have embedded functions
- Good for utilities and converters
### Expert Agent
- Domain-specific with sidecar resources
- Restricted access patterns
- Memory/context files
- Good for specialized domains
### Module Agent
- Full integration with module
- Multiple workflows and tasks
- Config-driven behavior
- Good for professional tools
## Common Anti-Patterns to Avoid
### ❌ Bad Practices
```xml
<!-- Missing required persona elements -->
<persona>
<role>Helper</role>
<!-- Missing identity, style, principles -->
</persona>
<!-- Hard-coded paths -->
<item cmd="*run" exec="/Users/john/project/task.md">
<!-- No help command -->
<menu>
<item cmd="*do-something">Action</item>
<!-- Missing *help -->
</menu>
<!-- Duplicate command triggers -->
<item cmd="*analyze">First</item>
<item cmd="*analyze">Second</item>
```
### ✅ Good Practices
```xml
<!-- Complete persona -->
<persona>
<role>Data Analysis Expert</role>
<identity>Senior analyst with 10+ years...</identity>
<communication_style>Analytical and precise...</communication_style>
<principles>I believe in data-driven...</principles>
</persona>
<!-- Variable-based paths -->
<item cmd="*run" exec="{project-root}/bmad/module/task.md">
<!-- Required commands present -->
<menu>
<item cmd="*help">Show commands</item>
<item cmd="*analyze">Perform analysis</item>
<item cmd="*exit">Exit</item>
</menu>
```
## Agent Lifecycle
### 1. Initialization
1. Load agent file
2. Parse XML structure
3. Load critical-actions
4. Apply config overrides
5. Present greeting
### 2. Command Loop
1. Show numbered menu
2. Await user input
3. Resolve command
4. Execute action
5. Return to menu
### 3. Termination
1. User enters \*exit
2. Cleanup if needed
3. Exit persona
## Testing Checklist
Before deploying an agent:
- [ ] Valid XML structure
- [ ] All persona elements present
- [ ] *help and *exit commands exist
- [ ] All paths use variables
- [ ] No duplicate commands
- [ ] Config loading works
- [ ] Commands execute properly
## LLM Building Tips
When building agents:
1. Start with agent type (Simple/Expert/Module)
2. Define complete persona first
3. Add standard critical-actions
4. Include *help and *exit
5. Add domain commands
6. Test command execution
7. Validate with checklist
## Integration Points
### With Workflows
- Agents invoke workflows via run-workflow
- Workflows can be incomplete (marked "todo")
- Workflow paths must be valid or "todo"
### With Tasks
- Tasks are single operations
- Executed via exec attribute
- Can include data files
### With Templates
- Templates define document structure
- Used with create-doc task
- Variables passed through
## Quick Reference
### Minimal Commands
```xml
<menu>
<item cmd="*help">Show numbered cmd list</item>
<item cmd="*exit">Exit with confirmation</item>
</menu>
```
### Standard Critical Actions
```xml
<critical-actions>
<i>Load into memory {project-root}/bmad/{module}/config.yaml</i>
<i>Remember the users name is {user_name}</i>
<i>ALWAYS communicate in {communication_language}</i>
</critical-actions>
```
### Module Agent Pattern
```xml
<agent id="bmad/{module}/agents/{name}.md"
name="{Name}"
title="{Title}"
icon="{emoji}">
<persona>...</persona>
<critical-actions>...</critical-actions>
<menu>
<item cmd="*help">...</item>
<item cmd="*{command}" run-workflow="{path}">...</item>
<item cmd="*exit">...</item>
</menu>
</agent>
```

View File

@@ -1,759 +0,0 @@
# BMAD Agent Command Patterns Reference
_LLM-Optimized Guide for Command Design_
## Important: How to Process Action References
When executing agent commands, understand these reference patterns:
```xml
<!-- Pattern 1: Inline action -->
<item cmd="*example" action="do this specific thing">Description</item>
→ Execute the text "do this specific thing" directly
<!-- Pattern 2: Internal reference with # prefix -->
<item cmd="*example" action="#prompt-id">Description</item>
→ Find <prompt id="prompt-id"> in the current agent and execute its content
<!-- Pattern 3: External file reference -->
<item cmd="*example" exec="{project-root}/path/to/file.md">Description</item>
→ Load and execute the external file
```
**The `#` prefix is your signal that this is an internal XML node reference, not a file path.**
## Command Anatomy
### Basic Structure
```xml
<menu>
<item cmd="*trigger" [attributes]>Description</item>
</menu>
```
**Components:**
- `cmd` - The trigger word (always starts with \*)
- `attributes` - Action directives (optional):
- `run-workflow` - Path to workflow YAML
- `exec` - Path to task/operation
- `tmpl` - Path to template (used with exec)
- `action` - Embedded prompt/instruction
- `data` - Path to supplementary data (universal)
- `Description` - What shows in menu
## Command Types
**Quick Reference:**
1. **Workflow Commands** - Execute multi-step workflows (`run-workflow`)
2. **Task Commands** - Execute single operations (`exec`)
3. **Template Commands** - Generate from templates (`exec` + `tmpl`)
4. **Meta Commands** - Agent control (no attributes)
5. **Action Commands** - Embedded prompts (`action`)
6. **Embedded Commands** - Logic in persona (no attributes)
**Universal Attributes:**
- `data` - Can be added to ANY command type for supplementary info
- `if` - Conditional execution (advanced pattern)
- `params` - Runtime parameters (advanced pattern)
### 1. Workflow Commands
Execute complete multi-step processes
```xml
<!-- Standard workflow -->
<item cmd="*create-prd"
run-workflow="{project-root}/bmad/bmm/workflows/prd/workflow.yaml">
Create Product Requirements Document
</item>
<!-- Workflow with validation -->
<item cmd="*validate-prd"
validate-workflow="{output_folder}/prd-draft.md"
workflow="{project-root}/bmad/bmm/workflows/prd/workflow.yaml">
Validate PRD Against Checklist
</item>
<!-- Auto-discover validation workflow from document -->
<item cmd="*validate-doc"
validate-workflow="{output_folder}/document.md">
Validate Document (auto-discover checklist)
</item>
<!-- Placeholder for future development -->
<item cmd="*analyze-data"
run-workflow="todo">
Analyze dataset (workflow coming soon)
</item>
```
**Workflow Attributes:**
- `run-workflow` - Execute a workflow to create documents
- `validate-workflow` - Validate an existing document against its checklist
- `workflow` - (optional with validate-workflow) Specify the workflow.yaml directly
**Best Practices:**
- Use descriptive trigger names
- Always use variable paths
- Mark incomplete as "todo"
- Description should be clear action
- Include validation commands for workflows that produce documents
### 2. Task Commands
Execute single operations
```xml
<!-- Simple task -->
<item cmd="*validate"
exec="{project-root}/bmad/core/tasks/validate-workflow.xml">
Validate document against checklist
</item>
<!-- Task with data -->
<item cmd="*standup"
exec="{project-root}/bmad/mmm/tasks/daily-standup.xml"
data="{project-root}/bmad/_cfg/agent-manifest.csv">
Run agile team standup
</item>
```
**Data Property:**
- Can be used with any command type
- Provides additional reference or context
- Path to supplementary files or resources
- Loaded at runtime for command execution
### 3. Template Commands
Generate documents from templates
```xml
<item cmd="*brief"
exec="{project-root}/bmad/core/tasks/create-doc.md"
tmpl="{project-root}/bmad/bmm/templates/brief.md">
Produce Project Brief
</item>
<item cmd="*competitor-analysis"
exec="{project-root}/bmad/core/tasks/create-doc.md"
tmpl="{project-root}/bmad/bmm/templates/competitor.md"
data="{project-root}/bmad/_data/market-research.csv">
Produce Competitor Analysis
</item>
```
### 4. Meta Commands
Agent control and information
```xml
<!-- Required meta commands -->
<item cmd="*help">Show numbered cmd list</item>
<item cmd="*exit">Exit with confirmation</item>
<!-- Optional meta commands -->
<item cmd="*yolo">Toggle Yolo Mode</item>
<item cmd="*status">Show current status</item>
<item cmd="*config">Show configuration</item>
```
### 5. Action Commands
Direct prompts embedded in commands (Simple agents)
#### Simple Action (Inline)
```xml
<!-- Short action attribute with embedded prompt -->
<item cmd="*list-tasks"
action="list all tasks from {project-root}/bmad/_cfg/task-manifest.csv">
List Available Tasks
</item>
<item cmd="*summarize"
action="summarize the key points from the current document">
Summarize Document
</item>
```
#### Complex Action (Referenced)
For multiline/complex prompts, define them separately and reference by id:
```xml
<agent name="Research Assistant">
<!-- Define complex prompts as separate nodes -->
<prompts>
<prompt id="deep-analysis">
Perform a comprehensive analysis following these steps:
1. Identify the main topic and key themes
2. Extract all supporting evidence and data points
3. Analyze relationships between concepts
4. Identify gaps or contradictions
5. Generate insights and recommendations
6. Create an executive summary
Format the output with clear sections and bullet points.
</prompt>
<prompt id="literature-review">
Conduct a systematic literature review:
1. Summarize each source's main arguments
2. Compare and contrast different perspectives
3. Identify consensus points and controversies
4. Evaluate the quality and relevance of sources
5. Synthesize findings into coherent themes
6. Highlight research gaps and future directions
Include proper citations and references.
</prompt>
</prompts>
<!-- Commands reference the prompts by id -->
<menu>
<item cmd="*help">Show numbered cmd list</item>
<item cmd="*deep-analyze"
action="#deep-analysis">
<!-- The # means: use the <prompt id="deep-analysis"> defined above -->
Perform Deep Analysis
</item>
<item cmd="*review-literature"
action="#literature-review"
data="{project-root}/bmad/_data/sources.csv">
Conduct Literature Review
</item>
<item cmd="*exit">Exit with confirmation</item>
</menu>
</agent>
```
**Reference Convention:**
- `action="#prompt-id"` means: "Find and execute the <prompt> node with id='prompt-id' within this agent"
- `action="inline text"` means: "Execute this text directly as the prompt"
- `exec="{path}"` means: "Load and execute external file at this path"
- The `#` prefix signals to the LLM: "This is an internal reference - look for a prompt node with this ID within the current agent XML"
**LLM Processing Instructions:**
When you see `action="#some-id"` in a command:
1. Look for `<prompt id="some-id">` within the same agent
2. Use the content of that prompt node as the instruction
3. If not found, report error: "Prompt 'some-id' not found in agent"
**Use Cases:**
- Quick operations (inline action)
- Complex multi-step processes (referenced prompt)
- Self-contained agents with task-like capabilities
- Reusable prompt templates within agent
### 6. Embedded Commands
Logic embedded in agent persona (Simple agents)
```xml
<!-- No exec/run-workflow/action attribute -->
<item cmd="*calculate">Perform calculation</item>
<item cmd="*convert">Convert format</item>
<item cmd="*generate">Generate output</item>
```
## Command Naming Conventions
### Action-Based Naming
```xml
*create- <!-- Generate new content -->
*build- <!-- Construct components -->
*analyze- <!-- Examine and report -->
*validate- <!-- Check correctness -->
*generate- <!-- Produce output -->
*update- <!-- Modify existing -->
*review- <!-- Examine quality -->
*test- <!-- Verify functionality -->
```
### Domain-Based Naming
```xml
*brainstorm <!-- Creative ideation -->
*architect <!-- Design systems -->
*refactor <!-- Improve code -->
*deploy <!-- Release to production -->
*monitor <!-- Watch systems -->
```
### Naming Anti-Patterns
```xml
<!-- ❌ Too vague -->
<item cmd="*do">Do something</item>
<!-- ❌ Too long -->
<item cmd="*create-comprehensive-product-requirements-document-with-analysis">
<!-- ❌ No verb -->
<item cmd="*prd">Product Requirements</item>
<!-- ✅ Clear and concise -->
<item cmd="*create-prd">Create Product Requirements Document</item>
```
## Command Organization
### Standard Order
```xml
<menu>
<!-- 1. Always first -->
<item cmd="*help">Show numbered cmd list</item>
<!-- 2. Primary workflows -->
<item cmd="*create-prd" run-workflow="...">Create PRD</item>
<item cmd="*create-module" run-workflow="...">Build module</item>
<!-- 3. Secondary actions -->
<item cmd="*validate" exec="...">Validate document</item>
<item cmd="*analyze" exec="...">Analyze code</item>
<!-- 4. Utility commands -->
<item cmd="*config">Show configuration</item>
<item cmd="*yolo">Toggle Yolo Mode</item>
<!-- 5. Always last -->
<item cmd="*exit">Exit with confirmation</item>
</menu>
```
### Grouping Strategies
**By Lifecycle:**
```xml
<menu>
<item cmd="*help">Help</item>
<!-- Planning -->
<item cmd="*brainstorm">Brainstorm ideas</item>
<item cmd="*plan">Create plan</item>
<!-- Building -->
<item cmd="*build">Build component</item>
<item cmd="*test">Test component</item>
<!-- Deployment -->
<item cmd="*deploy">Deploy to production</item>
<item cmd="*monitor">Monitor system</item>
<item cmd="*exit">Exit</item>
</menu>
```
**By Complexity:**
```xml
<menu>
<item cmd="*help">Help</item>
<!-- Simple -->
<item cmd="*quick-review">Quick review</item>
<!-- Standard -->
<item cmd="*create-doc">Create document</item>
<!-- Complex -->
<item cmd="*full-analysis">Comprehensive analysis</item>
<item cmd="*exit">Exit</item>
</menu>
```
## Command Descriptions
### Good Descriptions
```xml
<!-- Clear action and object -->
<item cmd="*create-prd">Create Product Requirements Document</item>
<!-- Specific outcome -->
<item cmd="*analyze-security">Perform security vulnerability analysis</item>
<!-- User benefit -->
<item cmd="*optimize">Optimize code for performance</item>
```
### Poor Descriptions
```xml
<!-- Too vague -->
<item cmd="*process">Process</item>
<!-- Technical jargon -->
<item cmd="*exec-wf-123">Execute WF123</item>
<!-- Missing context -->
<item cmd="*run">Run</item>
```
## The Data Property
### Universal Data Attribute
The `data` attribute can be added to ANY command type to provide supplementary information:
```xml
<!-- Workflow with data -->
<item cmd="*brainstorm"
run-workflow="{project-root}/bmad/core/workflows/brainstorming/workflow.yaml"
data="{project-root}/bmad/core/workflows/brainstorming/brain-methods.csv">
Creative Brainstorming Session
</item>
<!-- Action with data -->
<item cmd="*analyze-metrics"
action="analyze these metrics and identify trends"
data="{project-root}/bmad/_data/performance-metrics.json">
Analyze Performance Metrics
</item>
<!-- Template with data -->
<item cmd="*report"
exec="{project-root}/bmad/core/tasks/create-doc.md"
tmpl="{project-root}/bmad/bmm/templates/report.md"
data="{project-root}/bmad/_data/quarterly-results.csv">
Generate Quarterly Report
</item>
```
**Common Data Uses:**
- Reference tables (CSV files)
- Configuration data (YAML/JSON)
- Agent manifests (XML)
- Historical context
- Domain knowledge
- Examples and patterns
## Advanced Patterns
### Conditional Commands
```xml
<!-- Only show if certain conditions met -->
<item cmd="*advanced-mode"
if="user_level == 'expert'"
run-workflow="...">
Advanced configuration mode
</item>
<!-- Environment specific -->
<item cmd="*deploy-prod"
if="environment == 'production'"
exec="...">
Deploy to production
</item>
```
### Parameterized Commands
```xml
<!-- Accept runtime parameters -->
<item cmd="*create-agent"
run-workflow="..."
params="agent_type,agent_name">
Create new agent with parameters
</item>
```
### Command Aliases
```xml
<!-- Multiple triggers for same action -->
<item cmd="*prd|*create-prd|*product-requirements"
run-workflow="...">
Create Product Requirements Document
</item>
```
## Module-Specific Patterns
### BMM (Business Management)
```xml
<item cmd="*create-prd">Product Requirements</item>
<item cmd="*market-research">Market Research</item>
<item cmd="*competitor-analysis">Competitor Analysis</item>
<item cmd="*brief">Project Brief</item>
```
### BMB (Builder)
```xml
<item cmd="*create-agent">Build Agent</item>
<item cmd="*create-module">Build Module</item>
<item cmd="*create-workflow">Create Workflow</item>
<item cmd="*module-brief">Module Brief</item>
```
### CIS (Creative Intelligence)
```xml
<item cmd="*brainstorm">Brainstorming Session</item>
<item cmd="*ideate">Ideation Workshop</item>
<item cmd="*storytell">Story Creation</item>
```
## Command Menu Presentation
### How Commands Display
```
1. *help - Show numbered cmd list
2. *create-prd - Create Product Requirements Document
3. *create-agent - Build new BMAD agent
4. *validate - Validate document
5. *exit - Exit with confirmation
```
### Menu Customization
```xml
<!-- Group separator (visual only) -->
<item cmd="---">━━━━━━━━━━━━━━━━━━━━</item>
<!-- Section header (non-executable) -->
<item cmd="SECTION">═══ Workflows ═══</item>
```
## Error Handling
### Missing Resources
```xml
<!-- Workflow not yet created -->
<item cmd="*future-feature"
run-workflow="todo">
Coming soon: Advanced feature
</item>
<!-- Graceful degradation -->
<item cmd="*analyze"
run-workflow="{optional-path|fallback-path}">
Analyze with available tools
</item>
```
## Testing Commands
### Command Test Checklist
- [ ] Unique trigger (no duplicates)
- [ ] Clear description
- [ ] Valid path or "todo"
- [ ] Uses variables not hardcoded paths
- [ ] Executes without error
- [ ] Returns to menu after execution
### Common Issues
1. **Duplicate triggers** - Each cmd must be unique
2. **Missing paths** - File must exist or be "todo"
3. **Hardcoded paths** - Always use variables
4. **No description** - Every command needs text
5. **Wrong order** - help first, exit last
## Quick Templates
### Workflow Command
```xml
<!-- Create document -->
<item cmd="*{action}-{object}"
run-workflow="{project-root}/bmad/{module}/workflows/{workflow}/workflow.yaml">
{Action} {Object Description}
</item>
<!-- Validate document -->
<item cmd="*validate-{object}"
validate-workflow="{output_folder}/{document}.md"
workflow="{project-root}/bmad/{module}/workflows/{workflow}/workflow.yaml">
Validate {Object Description}
</item>
```
### Task Command
```xml
<item cmd="*{action}"
exec="{project-root}/bmad/{module}/tasks/{task}.md">
{Action Description}
</item>
```
### Template Command
```xml
<item cmd="*{document}"
exec="{project-root}/bmad/core/tasks/create-doc.md"
tmpl="{project-root}/bmad/{module}/templates/{template}.md">
Create {Document Name}
</item>
```
## Self-Contained Agent Patterns
### When to Use Each Approach
**Inline Action (`action="prompt"`)**
- Prompt is < 2 lines
- Simple, direct instruction
- Not reused elsewhere
- Quick transformations
**Referenced Prompt (`action="#prompt-id"`)**
- Prompt is multiline/complex
- Contains structured steps
- May be reused by multiple commands
- Maintains readability
**External Task (`exec="path/to/task.md"`)**
- Logic needs to be shared across agents
- Task is independently valuable
- Requires version control separately
- Part of larger workflow system
### Complete Self-Contained Agent
```xml
<agent id="bmad/research/agents/analyst.md" name="Research Analyst" icon="🔬">
<!-- Embedded prompt library -->
<prompts>
<prompt id="swot-analysis">
Perform a SWOT analysis:
STRENGTHS (Internal, Positive)
- What advantages exist?
- What do we do well?
- What unique resources?
WEAKNESSES (Internal, Negative)
- What could improve?
- Where are resource gaps?
- What needs development?
OPPORTUNITIES (External, Positive)
- What trends can we leverage?
- What market gaps exist?
- What partnerships are possible?
THREATS (External, Negative)
- What competition exists?
- What risks are emerging?
- What could disrupt us?
Provide specific examples and actionable insights for each quadrant.
</prompt>
<prompt id="competitive-intel">
Analyze competitive landscape:
1. Identify top 5 competitors
2. Compare features and capabilities
3. Analyze pricing strategies
4. Evaluate market positioning
5. Assess strengths and vulnerabilities
6. Recommend competitive strategies
</prompt>
</prompts>
<menu>
<item cmd="*help">Show numbered cmd list</item>
<!-- Simple inline actions -->
<item cmd="*summarize"
action="create executive summary of findings">
Create Executive Summary
</item>
<!-- Complex referenced prompts -->
<item cmd="*swot"
action="#swot-analysis">
Perform SWOT Analysis
</item>
<item cmd="*compete"
action="#competitive-intel"
data="{project-root}/bmad/_data/market-data.csv">
Analyze Competition
</item>
<!-- Hybrid: external task with internal data -->
<item cmd="*report"
exec="{project-root}/bmad/core/tasks/create-doc.md"
tmpl="{project-root}/bmad/research/templates/report.md">
Generate Research Report
</item>
<item cmd="*exit">Exit with confirmation</item>
</menu>
</agent>
```
## Simple Agent Example
For agents that primarily use embedded logic:
```xml
<agent name="Data Analyst">
<menu>
<item cmd="*help">Show numbered cmd list</item>
<!-- Action commands for direct operations -->
<item cmd="*list-metrics"
action="list all available metrics from the dataset">
List Available Metrics
</item>
<item cmd="*analyze"
action="perform statistical analysis on the provided data"
data="{project-root}/bmad/_data/dataset.csv">
Analyze Dataset
</item>
<item cmd="*visualize"
action="create visualization recommendations for this data">
Suggest Visualizations
</item>
<!-- Embedded logic commands -->
<item cmd="*calculate">Perform calculations</item>
<item cmd="*interpret">Interpret results</item>
<item cmd="*exit">Exit with confirmation</item>
</menu>
</agent>
```
## LLM Building Guide
When creating commands:
1. Start with *help and *exit
2. Choose appropriate command type:
- Complex multi-step? Use `run-workflow`
- Single operation? Use `exec`
- Need template? Use `exec` + `tmpl`
- Simple prompt? Use `action`
- Agent handles it? Use no attributes
3. Add `data` attribute if supplementary info needed
4. Add primary workflows (main value)
5. Add secondary tasks
6. Include utility commands
7. Test each command works
8. Verify no duplicates
9. Ensure clear descriptions

View File

@@ -20,8 +20,6 @@
<check if="user answered no">
<action>Proceed directly to Step 0</action>
</check>
<template-output>brainstorming_results</template-output>
</step>
<step n="0" goal="Load technical documentation">
@@ -103,9 +101,24 @@
7. Wise Sage/Yoda - Cryptic wisdom, inverted syntax
8. Game Show Host - Enthusiastic, game show tropes
**Professional Presets:** 9. Analytical Expert - Systematic, data-driven, hierarchical 10. Supportive Mentor - Patient guidance, celebrates wins 11. Direct Consultant - Straight to the point, efficient 12. Collaborative Partner - Team-oriented, inclusive
**Professional Presets:**
**Quirky Presets:** 13. Cooking Show Chef - Recipe metaphors, culinary terms 14. Sports Commentator - Play-by-play, excitement 15. Nature Documentarian - Wildlife documentary style 16. Time Traveler - Temporal references, timeline talk 17. Conspiracy Theorist - Everything is connected 18. Zen Master - Philosophical, paradoxical 19. Star Trek Captain - Space exploration protocols 20. Soap Opera Drama - Dramatic reveals, gasps 21. Reality TV Contestant - Confessionals, drama
9. Analytical Expert - Systematic, data-driven, hierarchical
10. Supportive Mentor - Patient guidance, celebrates wins
11. Direct Consultant - Straight to the point, efficient
12. Collaborative Partner - Team-oriented, inclusive
**Quirky Presets:**
13. Cooking Show Chef - Recipe metaphors, culinary terms
14. Sports Commentator - Play-by-play, excitement
15. Nature Documentarian - Wildlife documentary style
16. Time Traveler - Temporal references, timeline talk
17. Conspiracy Theorist - Everything is connected
18. Zen Master - Philosophical, paradoxical
19. Star Trek Captain - Space exploration protocols
20. Soap Opera Drama - Dramatic reveals, gasps
21. Reality TV Contestant - Confessionals, drama
<action>If user wants to see more examples or create custom styles, show relevant sections from {communication_styles} guide and help them craft their unique style</action>
@@ -352,16 +365,16 @@ Add domain-specific resources here.
<check if="external project without build tools">
<ask>Build tools not detected in this project. Would you like me to:
1. Generate the compiled agent (.md with XML) ready to use
2. Keep the YAML and build it elsewhere
3. Provide both formats
1. Generate the compiled agent (.md with XML) ready to use
2. Keep the YAML and build it elsewhere
3. Provide both formats
</ask>
<check if="option 1 or 3 selected">
<action>Generate compiled agent XML with proper structure including activation rules, persona sections, and menu items</action>
<action>Save compiled version as {{agent_filename}}.md</action>
<action>Provide path for .claude/commands/ or similar</action>
</check>
<check if="option 1 or 3 selected">
<action>Generate compiled agent XML with proper structure including activation rules, persona sections, and menu items</action>
<action>Save compiled version as {{agent_filename}}.md</action>
<action>Provide path for .claude/commands/ or similar</action>
</check>
</check>

View File

@@ -1,220 +1,229 @@
# Build Module Workflow
# Create Module Workflow
## Overview
Interactive scaffolding system creating complete BMad modules with agents, workflows, tasks, and installation infrastructure.
The Build Module workflow is an interactive scaffolding system that creates complete BMAD modules with agents, workflows, tasks, and installation infrastructure. It serves as the primary tool for building new modules in the BMAD ecosystem, guiding users through the entire module creation process from concept to deployment-ready structure.
## Table of Contents
## Key Features
- [Quick Start](#quick-start)
- [Workflow Phases](#workflow-phases)
- [Output Structure](#output-structure)
- [Module Components](#module-components)
- [Best Practices](#best-practices)
- **Interactive Module Planning** - Collaborative session to define module concept, scope, and architecture
- **Intelligent Scaffolding** - Automatic creation of proper directory structures and configuration files
- **Component Integration** - Seamless integration with create-agent and create-workflow workflows
- **Installation Infrastructure** - Complete installer setup with configuration templates
- **Module Brief Integration** - Can use existing module briefs as blueprints for accelerated development
- **Validation and Documentation** - Built-in validation checks and comprehensive README generation
## Usage
### Basic Invocation
## Quick Start
```bash
# Basic invocation
workflow create-module
# With module brief input
workflow create-module --input module-brief-{name}-{date}.md
# Via BMad Builder
*create-module
```
### With Module Brief Input
## Workflow Phases
```bash
# If you have a module brief from the module-brief workflow
workflow create-module --input module-brief-my-module-2024-09-26.md
```
### Phase 1: Concept Definition
### Configuration
- Define module purpose and audience
- Establish module code (kebab-case) and name
- Choose category (Domain, Creative, Technical, Business, Personal)
- Plan component architecture
The workflow loads critical variables from the BMB configuration:
**Module Brief Integration:**
- **custom_module_location**: Where custom modules are created (default: `bmad/`)
- **user_name**: Module author information
- **date**: Automatic timestamp for versioning
- Auto-detects existing briefs
- Uses as pre-populated blueprint
- Accelerates planning phase
## Workflow Structure
### Phase 2: Architecture Planning
### Files Included
- Create directory hierarchy
- Setup configuration system
- Define installer structure
- Establish component folders
### Phase 3: Component Creation
- Optional first agent creation
- Optional first workflow creation
- Component placeholder generation
- Integration validation
### Phase 4: Installation Setup
- Create install-config.yaml
- Configure deployment questions
- Setup installer logic
- Post-install messaging
### Phase 5: Documentation
- Generate comprehensive README
- Create development roadmap
- Provide quick commands
- Document next steps
## Output Structure
### Generated Directory
```
create-module/
├── workflow.yaml # Configuration and metadata
├── instructions.md # Step-by-step execution guide
├── checklist.md # Validation criteria
├── module-structure.md # Module architecture guide
├── installer-templates/ # Installation templates
bmad/{module-code}/
├── agents/ # Agent definitions
├── workflows/ # Workflow processes
├── tasks/ # Reusable tasks
├── templates/ # Document templates
├── data/ # Module data files
├── _module-installer/ # Installation logic
│ ├── install-config.yaml
│ └── installer.js
── README.md # This file
── README.md # Module documentation
├── TODO.md # Development roadmap
└── config.yaml # Runtime configuration
```
## Workflow Process
### Configuration Files
### Phase 1: Concept Definition (Steps 1-2)
**install-config.yaml** - Installation questions
**Module Vision and Identity**
```yaml
questions:
- id: user_name
prompt: 'Your name?'
default: 'User'
- id: output_folder
prompt: 'Output location?'
default: './output'
```
- Define module concept, purpose, and target audience
- Establish module code (kebab-case) and friendly name
- Choose module category (Domain-Specific, Creative, Technical, Business, Personal)
- Plan component architecture with agent and workflow specifications
**config.yaml** - Generated from user answers during install
**Module Brief Integration**
```yaml
user_name: 'John Doe'
output_folder: './my-output'
```
- Automatically detects existing module briefs in output folder
- Can load and use briefs as pre-populated blueprints
- Accelerates planning when comprehensive brief exists
## Module Components
### Phase 2: Architecture Planning (Steps 3-4)
### Agents
**Directory Structure Creation**
- Full module agents with workflows
- Expert agents with sidecars
- Simple utility agents
- Creates complete module directory hierarchy
- Sets up agent, workflow, task, template, and data folders
- Establishes installer directory with proper configuration
### Workflows
**Module Configuration**
- Multi-step guided processes
- Configuration-driven
- Web bundle support
- Defines configuration questions in install-config.yaml (config.yaml generated during installation)
- Configures component counts and references
- Sets up output and data folder specifications
### Tasks
### Phase 3: Component Creation (Steps 5-6)
- Reusable operations
- Agent-agnostic
- Modular components
**Interactive Component Building**
### Templates
- Optional creation of first agent using create-agent workflow
- Optional creation of first workflow using create-workflow workflow
- Creates placeholders for components to be built later
**Workflow Integration**
- Seamlessly invokes sub-workflows for component creation
- Ensures proper file placement and structure
- Maintains module consistency across components
### Phase 4: Installation and Documentation (Steps 7-9)
**Installer Infrastructure**
- Creates install-config.yaml with configuration questions for deployment
- Sets up optional installer.js for complex installation logic
- Configures post-install messaging and instructions
**Comprehensive Documentation**
- Generates detailed README.md with usage examples
- Creates development roadmap for remaining components
- Provides quick commands for continued development
### Phase 5: Validation and Finalization (Step 10)
**Quality Assurance**
- Validates directory structure and configuration files
- Checks component references and path consistency
- Ensures installer configuration is deployment-ready
- Provides comprehensive module summary and next steps
## Output
### Generated Files
- **Module Directory**: Complete module structure at `{project-root}/bmad/{module_code}/`
- **Configuration Files**:
- Source: install-config.yaml (configuration questions)
- Target: config.yaml (generated from user answers during installation)
- **Documentation**: README.md, TODO.md development roadmap
- **Component Placeholders**: Structured folders for agents, workflows, and tasks
### Output Structure
The workflow creates a complete module ready for development:
1. **Module Identity** - Name, code, version, and metadata
2. **Directory Structure** - Proper BMAD module hierarchy
3. **Configuration System** - Runtime and installation configs
4. **Component Framework** - Ready-to-use agent and workflow scaffolding
5. **Installation Infrastructure** - Deployment-ready installer
6. **Documentation Suite** - README, roadmap, and development guides
## Requirements
- **Module Brief** (optional but recommended) - Use module-brief workflow first for best results
- **BMAD Core Configuration** - Properly configured BMB config.yaml
- **Build Tools Access** - create-agent and create-workflow workflows must be available
- Document structures
- Output formats
- Report templates
## Best Practices
### Before Starting
### Planning
1. **Create a Module Brief** - Run module-brief workflow for comprehensive planning
2. **Review Existing Modules** - Study similar modules in `/bmad/` for patterns and inspiration
3. **Define Clear Scope** - Have a concrete vision of what the module will accomplish
1. **Use module-brief workflow first** - Creates comprehensive blueprint
2. **Define clear scope** - Avoid feature creep
3. **Plan component interactions** - Map agent/workflow relationships
### During Execution
### Structure
1. **Use Module Briefs** - Load existing briefs when prompted for accelerated development
2. **Start Simple** - Create one core agent and workflow, then expand iteratively
3. **Leverage Sub-workflows** - Use create-agent and create-workflow for quality components
4. **Validate Early** - Review generated structure before proceeding to next phases
1. **Follow conventions** - Use established patterns
2. **Keep components focused** - Single responsibility
3. **Document thoroughly** - Clear README and inline docs
### After Completion
### Development
1. **Follow the Roadmap** - Use generated TODO.md for systematic development
2. **Test Installation** - Validate installer with `bmad install {module_code}`
3. **Iterate Components** - Use quick commands to add agents and workflows
4. **Document Progress** - Update README.md as the module evolves
1. **Start with core agent** - Build primary functionality first
2. **Create key workflows** - Essential processes before edge cases
3. **Test incrementally** - Validate as you build
## Troubleshooting
### Installation
### Common Issues
1. **Minimal config questions** - Only essential settings
2. **Smart defaults** - Sensible out-of-box experience
3. **Clear post-install** - Guide users to first steps
**Issue**: Module already exists at target location
## Integration Points
- **Solution**: Choose a different module code or remove existing module
- **Check**: Verify output folder permissions and available space
### With Other Workflows
**Issue**: Sub-workflow invocation fails
- **module-brief** - Strategic planning input
- **create-agent** - Agent component creation
- **create-workflow** - Workflow building
- **redoc** - Documentation maintenance
- **Solution**: Ensure create-agent and create-workflow workflows are available
- **Check**: Validate workflow paths in config.yaml
### With BMad Core
**Issue**: Installation configuration invalid
- Uses core framework capabilities
- Integrates with module system
- Follows BMad conventions
- **Solution**: Review install-config.yaml syntax and paths
- **Check**: Ensure all referenced paths use {project-root} variables correctly
## Examples
## Customization
### Domain-Specific Module
To customize this workflow:
```
Category: Domain-Specific
Code: legal-advisor
Components:
- Contract Review Agent
- Compliance Workflow
- Legal Templates
```
1. **Modify Instructions** - Update instructions.md to adjust scaffolding steps
2. **Extend Templates** - Add new installer templates in installer-templates/
3. **Update Validation** - Enhance checklist.md with additional quality checks
4. **Add Components** - Integrate additional sub-workflows for specialized components
### Creative Module
## Version History
```
Category: Creative
Code: story-builder
Components:
- Narrative Agent
- Plot Workflow
- Character Templates
```
- **v1.0.0** - Initial release
- Interactive module scaffolding
- Component integration with create-agent and create-workflow
- Complete installation infrastructure
- Module brief integration support
### Technical Module
## Support
```
Category: Technical
Code: api-tester
Components:
- Test Runner Agent
- API Validation Workflow
- Test Report Templates
```
For issues or questions:
## Workflow Files
- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
- Study module structure patterns at `module-structure.md`
- Validate output using `checklist.md`
- Consult existing modules in `/bmad/` for examples
```
create-module/
├── workflow.yaml # Configuration
├── instructions.md # Step guide
├── checklist.md # Validation
├── module-structure.md # Architecture
├── installer-templates/ # Install files
└── README.md # This file
```
---
## Related Documentation
_Part of the BMad Method v6 - BMB (Builder) Module_
- [Module Structure](./module-structure.md)
- [Module Brief Workflow](../module-brief/README.md)
- [Create Agent](../create-agent/README.md)
- [Create Workflow](../create-workflow/README.md)
- [BMB Module](../../README.md)

View File

@@ -1,218 +0,0 @@
# Build Module Workflow
## Overview
The Build Module workflow is an interactive scaffolding system that creates complete BMAD modules with agents, workflows, tasks, and installation infrastructure. It serves as the primary tool for building new modules in the BMAD ecosystem, guiding users through the entire module creation process from concept to deployment-ready structure.
## Key Features
- **Interactive Module Planning** - Collaborative session to define module concept, scope, and architecture
- **Intelligent Scaffolding** - Automatic creation of proper directory structures and configuration files
- **Component Integration** - Seamless integration with create-agent and create-workflow workflows
- **Installation Infrastructure** - Complete installer setup with configuration templates
- **Module Brief Integration** - Can use existing module briefs as blueprints for accelerated development
- **Validation and Documentation** - Built-in validation checks and comprehensive README generation
## Usage
### Basic Invocation
```bash
workflow create-module
```
### With Module Brief Input
```bash
# If you have a module brief from the module-brief workflow
workflow create-module --input module-brief-my-module-2024-09-26.md
```
### Configuration
The workflow loads critical variables from the BMB configuration:
- **custom_module_location**: Where custom modules are created (default: `bmad/`)
- **user_name**: Module author information
- **date**: Automatic timestamp for versioning
## Workflow Structure
### Files Included
```
create-module/
├── workflow.yaml # Configuration and metadata
├── instructions.md # Step-by-step execution guide
├── checklist.md # Validation criteria
├── module-structure.md # Module architecture guide
├── installer-templates/ # Installation templates
│ ├── install-config.yaml
│ └── installer.js
└── README.md # This file
```
## Workflow Process
### Phase 1: Concept Definition (Steps 1-2)
**Module Vision and Identity**
- Define module concept, purpose, and target audience
- Establish module code (kebab-case) and friendly name
- Choose module category (Domain-Specific, Creative, Technical, Business, Personal)
- Plan component architecture with agent and workflow specifications
**Module Brief Integration**
- Automatically detects existing module briefs in output folder
- Can load and use briefs as pre-populated blueprints
- Accelerates planning when comprehensive brief exists
### Phase 2: Architecture Planning (Steps 3-4)
**Directory Structure Creation**
- Creates complete module directory hierarchy
- Sets up agent, workflow, task, template, and data folders
- Establishes installer directory with proper configuration
**Module Configuration**
- Generates main config.yaml with module metadata
- Configures component counts and references
- Sets up output and data folder specifications
### Phase 3: Component Creation (Steps 5-6)
**Interactive Component Building**
- Optional creation of first agent using create-agent workflow
- Optional creation of first workflow using create-workflow workflow
- Creates placeholders for components to be built later
**Workflow Integration**
- Seamlessly invokes sub-workflows for component creation
- Ensures proper file placement and structure
- Maintains module consistency across components
### Phase 4: Installation and Documentation (Steps 7-9)
**Installer Infrastructure**
- Creates install-config.yaml for deployment
- Sets up optional installer.js for complex installation logic
- Configures post-install messaging and instructions
**Comprehensive Documentation**
- Generates detailed README.md with usage examples
- Creates development roadmap for remaining components
- Provides quick commands for continued development
### Phase 5: Validation and Finalization (Step 10)
**Quality Assurance**
- Validates directory structure and configuration files
- Checks component references and path consistency
- Ensures installer configuration is deployment-ready
- Provides comprehensive module summary and next steps
## Output
### Generated Files
- **Module Directory**: Complete module structure at `{project-root}/bmad/{module_code}/`
- **Configuration Files**: config.yaml, install-config.yaml
- **Documentation**: README.md, TODO.md development roadmap
- **Component Placeholders**: Structured folders for agents, workflows, and tasks
### Output Structure
The workflow creates a complete module ready for development:
1. **Module Identity** - Name, code, version, and metadata
2. **Directory Structure** - Proper BMAD module hierarchy
3. **Configuration System** - Runtime and installation configs
4. **Component Framework** - Ready-to-use agent and workflow scaffolding
5. **Installation Infrastructure** - Deployment-ready installer
6. **Documentation Suite** - README, roadmap, and development guides
## Requirements
- **Module Brief** (optional but recommended) - Use module-brief workflow first for best results
- **BMAD Core Configuration** - Properly configured BMB config.yaml
- **Build Tools Access** - create-agent and create-workflow workflows must be available
## Best Practices
### Before Starting
1. **Create a Module Brief** - Run module-brief workflow for comprehensive planning
2. **Review Existing Modules** - Study similar modules in `/bmad/` for patterns and inspiration
3. **Define Clear Scope** - Have a concrete vision of what the module will accomplish
### During Execution
1. **Use Module Briefs** - Load existing briefs when prompted for accelerated development
2. **Start Simple** - Create one core agent and workflow, then expand iteratively
3. **Leverage Sub-workflows** - Use create-agent and create-workflow for quality components
4. **Validate Early** - Review generated structure before proceeding to next phases
### After Completion
1. **Follow the Roadmap** - Use generated TODO.md for systematic development
2. **Test Installation** - Validate installer with `bmad install {module_code}`
3. **Iterate Components** - Use quick commands to add agents and workflows
4. **Document Progress** - Update README.md as the module evolves
## Troubleshooting
### Common Issues
**Issue**: Module already exists at target location
- **Solution**: Choose a different module code or remove existing module
- **Check**: Verify output folder permissions and available space
**Issue**: Sub-workflow invocation fails
- **Solution**: Ensure create-agent and create-workflow workflows are available
- **Check**: Validate workflow paths in config.yaml
**Issue**: Installation configuration invalid
- **Solution**: Review install-config.yaml syntax and paths
- **Check**: Ensure all referenced paths use {project-root} variables correctly
## Customization
To customize this workflow:
1. **Modify Instructions** - Update instructions.md to adjust scaffolding steps
2. **Extend Templates** - Add new installer templates in installer-templates/
3. **Update Validation** - Enhance checklist.md with additional quality checks
4. **Add Components** - Integrate additional sub-workflows for specialized components
## Version History
- **v1.0.0** - Initial release
- Interactive module scaffolding
- Component integration with create-agent and create-workflow
- Complete installation infrastructure
- Module brief integration support
## Support
For issues or questions:
- Review the workflow creation guide at `/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
- Study module structure patterns at `module-structure.md`
- Validate output using `checklist.md`
- Consult existing modules in `/bmad/` for examples
---
_Part of the BMad Method v6 - BMB (Builder) Module_

View File

@@ -1,245 +0,0 @@
# Build Module Validation Checklist
## Module Identity and Metadata
### Basic Information
- [ ] Module code follows kebab-case convention (e.g., "rpg-toolkit")
- [ ] Module name is descriptive and title-cased
- [ ] Module purpose is clearly defined (1-2 sentences)
- [ ] Target audience is identified
- [ ] Version number follows semantic versioning (e.g., "1.0.0")
- [ ] Author information is present
### Naming Consistency
- [ ] Module code used consistently throughout all files
- [ ] No naming conflicts with existing modules
- [ ] All paths use consistent module code references
## Directory Structure
### Source Directories (bmad/{module-code}/)
- [ ] `/agents` directory created (even if empty)
- [ ] `/workflows` directory created (even if empty)
- [ ] `/tasks` directory exists (if tasks planned)
- [ ] `/templates` directory exists (if templates used)
- [ ] `/data` directory exists (if data files needed)
- [ ] `config.yaml` present in module root
- [ ] `README.md` present with documentation
### Runtime Directories (bmad/{module-code}/)
- [ ] `/_module-installer` directory created
- [ ] `/data` directory for user data
- [ ] `/agents` directory for overrides
- [ ] `/workflows` directory for instances
- [ ] Runtime `config.yaml` present
## Component Planning
### Agents
- [ ] At least one agent defined or planned
- [ ] Agent purposes are distinct and clear
- [ ] Agent types (Simple/Expert/Module) identified
- [ ] No significant overlap between agents
- [ ] Primary agent is identified
### Workflows
- [ ] At least one workflow defined or planned
- [ ] Workflow purposes are clear
- [ ] Workflow types identified (Document/Action/Interactive)
- [ ] Primary workflow is identified
- [ ] Workflow complexity is appropriate
### Tasks (if applicable)
- [ ] Tasks have single, clear purposes
- [ ] Tasks don't duplicate workflow functionality
- [ ] Task files follow naming conventions
## Configuration Files
### Module config.yaml
- [ ] All required fields present (name, code, version, author)
- [ ] Component lists accurate (agents, workflows, tasks)
- [ ] Paths use proper variables ({project-root}, etc.)
- [ ] Output folders configured
- [ ] Custom settings documented
### Install Configuration
- [ ] `install-config.yaml` exists in `_module-installer`
- [ ] Installation steps defined
- [ ] Directory creation steps present
- [ ] File copy operations specified
- [ ] Module registration included
- [ ] Post-install message defined
## Installation Infrastructure
### Installer Files
- [ ] Install configuration validates against schema
- [ ] All source paths exist or are marked as templates
- [ ] Destination paths use correct variables
- [ ] Optional vs required steps clearly marked
### installer.js (if present)
- [ ] Main `installModule` function exists
- [ ] Error handling implemented
- [ ] Console logging for user feedback
- [ ] Exports correct function names
- [ ] Placeholder code replaced with actual logic (or logged as TODO)
### External Assets (if any)
- [ ] Asset files exist in assets directory
- [ ] Copy destinations are valid
- [ ] Permissions requirements documented
## Documentation
### README.md
- [ ] Module overview section present
- [ ] Installation instructions included
- [ ] Component listing with descriptions
- [ ] Quick start guide provided
- [ ] Configuration options documented
- [ ] At least one usage example
- [ ] Directory structure shown
- [ ] Author and date information
### Component Documentation
- [ ] Each agent has purpose documentation
- [ ] Each workflow has description
- [ ] Tasks are documented (if present)
- [ ] Examples demonstrate typical usage
### Development Roadmap
- [ ] TODO.md or roadmap section exists
- [ ] Planned components listed
- [ ] Development phases identified
- [ ] Quick commands for adding components
## Integration
### Cross-component References
- [ ] Agents reference correct workflow paths
- [ ] Workflows reference correct task paths
- [ ] All internal paths use module variables
- [ ] External dependencies declared
### Module Boundaries
- [ ] Module scope is well-defined
- [ ] No feature creep into other domains
- [ ] Clear separation from other modules
## Quality Checks
### Completeness
- [ ] At least one functional component (not all placeholders)
- [ ] Core functionality is implementable
- [ ] Module provides clear value
### Consistency
- [ ] Formatting consistent across files
- [ ] Variable naming follows conventions
- [ ] Communication style appropriate for domain
### Scalability
- [ ] Structure supports future growth
- [ ] Component organization is logical
- [ ] No hard-coded limits
## Testing and Validation
### Structural Validation
- [ ] YAML files parse without errors
- [ ] JSON files (if any) are valid
- [ ] XML files (if any) are well-formed
- [ ] No syntax errors in JavaScript files
### Path Validation
- [ ] All referenced paths exist or are clearly marked as TODO
- [ ] Variable substitutions are correct
- [ ] No absolute paths (unless intentional)
### Installation Testing
- [ ] Installation steps can be simulated
- [ ] No circular dependencies
- [ ] Uninstall process defined (if complex)
## Final Checks
### Ready for Use
- [ ] Module can be installed without errors
- [ ] At least one component is functional
- [ ] User can understand how to get started
- [ ] Next steps are clear
### Professional Quality
- [ ] No placeholder text remains (unless marked TODO)
- [ ] No obvious typos or grammar issues
- [ ] Professional tone throughout
- [ ] Contact/support information provided
## Issues Found
### Critical Issues
<!-- List any issues that MUST be fixed before module can be used -->
### Warnings
<!-- List any issues that should be addressed but won't prevent basic usage -->
### Improvements
<!-- List any optional enhancements that would improve the module -->
### Missing Components
<!-- List any planned components not yet implemented -->
## Module Complexity Assessment
### Complexity Rating
- [ ] Simple (1-2 agents, 2-3 workflows)
- [ ] Standard (3-5 agents, 5-10 workflows)
- [ ] Complex (5+ agents, 10+ workflows)
### Readiness Level
- [ ] Prototype (Basic structure, mostly placeholders)
- [ ] Alpha (Core functionality works)
- [ ] Beta (Most features complete, needs testing)
- [ ] Release (Full functionality, documented)
## Sign-off
**Module Name:** \***\*\*\*\*\***\_\_\***\*\*\*\*\***
**Module Code:** \***\*\*\*\*\***\_\_\***\*\*\*\*\***
**Version:** \***\*\*\*\*\***\_\_\***\*\*\*\*\***
**Validated By:** \***\*\*\*\*\***\_\_\***\*\*\*\*\***
**Date:** \***\*\*\*\*\***\_\_\***\*\*\*\*\***
**Status:** ⬜ Pass / ⬜ Pass with Issues / ⬜ Fail

View File

@@ -1,231 +0,0 @@
/* eslint-disable unicorn/prefer-module, unicorn/prefer-node-protocol */
/**
* {{MODULE_NAME}} Module Installer
* Custom installation logic for complex module setup
*
* This is a template - replace {{VARIABLES}} with actual values
*/
// const fs = require('fs'); // Uncomment when implementing file operations
const path = require('path');
/**
* Main installation function
* Called by BMAD installer when processing the module
*/
async function installModule(config) {
console.log('🚀 Installing {{MODULE_NAME}} module...');
console.log(` Version: ${config.version}`);
console.log(` Module Code: ${config.module_code}`);
try {
// Step 1: Validate environment
await validateEnvironment(config);
// Step 2: Setup custom configurations
await setupConfigurations(config);
// Step 3: Initialize module-specific features
await initializeFeatures(config);
// Step 4: Run post-install tasks
await runPostInstallTasks(config);
console.log('✅ {{MODULE_NAME}} module installed successfully!');
return {
success: true,
message: 'Module installed and configured',
};
} catch (error) {
console.error('❌ Installation failed:', error.message);
return {
success: false,
error: error.message,
};
}
}
/**
* Validate that the environment meets module requirements
*/
async function validateEnvironment(config) {
console.log(' Validating environment...');
// TODO: Add environment checks
// Examples:
// - Check for required tools/binaries
// - Verify permissions
// - Check network connectivity
// - Validate API keys
// Placeholder validation
if (!config.project_root) {
throw new Error('Project root not defined');
}
console.log(' ✓ Environment validated');
}
/**
* Setup module-specific configurations
*/
async function setupConfigurations(config) {
console.log(' Setting up configurations...');
// TODO: Add configuration setup
// Examples:
// - Create config files
// - Setup environment variables
// - Configure external services
// - Initialize settings
// Placeholder configuration
const configPath = path.join(config.project_root, 'bmad', config.module_code, 'config.json');
// Example of module config that would be created
// const moduleConfig = {
// installed: new Date().toISOString(),
// settings: {
// // Add default settings
// }
// };
// Note: This is a placeholder - actual implementation would write the file
console.log(` ✓ Would create config at: ${configPath}`);
console.log(' ✓ Configurations complete');
}
/**
* Initialize module-specific features
*/
async function initializeFeatures(config) {
console.log(' Initializing features...');
// TODO: Add feature initialization
// Examples:
// - Create database schemas
// - Setup cron jobs
// - Initialize caches
// - Register webhooks
// - Setup file watchers
// Module-specific initialization based on type
switch (config.module_category) {
case 'data': {
await initializeDataFeatures(config);
break;
}
case 'automation': {
await initializeAutomationFeatures(config);
break;
}
case 'integration': {
await initializeIntegrationFeatures(config);
break;
}
default: {
console.log(' - Using standard initialization');
}
}
console.log(' ✓ Features initialized');
}
/**
* Initialize data-related features
*/
async function initializeDataFeatures(/* config */) {
console.log(' - Setting up data storage...');
// TODO: Setup databases, data folders, etc.
}
/**
* Initialize automation features
*/
async function initializeAutomationFeatures(/* config */) {
console.log(' - Setting up automation hooks...');
// TODO: Setup triggers, watchers, schedulers
}
/**
* Initialize integration features
*/
async function initializeIntegrationFeatures(/* config */) {
console.log(' - Setting up integrations...');
// TODO: Configure APIs, webhooks, external services
}
/**
* Run post-installation tasks
*/
async function runPostInstallTasks(/* config */) {
console.log(' Running post-install tasks...');
// TODO: Add post-install tasks
// Examples:
// - Generate sample data
// - Run initial workflows
// - Send notifications
// - Update registries
console.log(' ✓ Post-install tasks complete');
}
/**
* Initialize database for the module (optional)
*/
async function initDatabase(/* config */) {
console.log(' Initializing database...');
// TODO: Add database initialization
// This function can be called from install-config.yaml
console.log(' ✓ Database initialized');
}
/**
* Generate sample data for the module (optional)
*/
async function generateSamples(config) {
console.log(' Generating sample data...');
// TODO: Create sample files, data, configurations
// This helps users understand how to use the module
const samplesPath = path.join(config.project_root, 'examples', config.module_code);
console.log(` - Would create samples at: ${samplesPath}`);
console.log(' ✓ Samples generated');
}
/**
* Uninstall the module (cleanup)
*/
async function uninstallModule(/* config */) {
console.log('🗑️ Uninstalling {{MODULE_NAME}} module...');
try {
// TODO: Add cleanup logic
// - Remove configurations
// - Clean up databases
// - Unregister services
// - Backup user data
console.log('✅ Module uninstalled successfully');
return { success: true };
} catch (error) {
console.error('❌ Uninstall failed:', error.message);
return {
success: false,
error: error.message,
};
}
}
// Export functions for BMAD installer
module.exports = {
installModule,
initDatabase,
generateSamples,
uninstallModule,
};

View File

@@ -1,521 +0,0 @@
# Build Module - Interactive Module Builder Instructions
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
<critical>You MUST have already loaded and processed: {project-root}/bmad/bmb/workflows/create-module/workflow.yaml</critical>
<critical>Study existing modules in: {project-root}/bmad/ for patterns</critical>
<critical>Communicate in {communication_language} throughout the module creation process</critical>
<workflow>
<step n="-1" goal="Optional brainstorming for module ideas" optional="true">
<ask>Do you want to brainstorm module ideas first? [y/n]</ask>
<check>If yes:</check>
<action>Invoke brainstorming workflow: {brainstorming_workflow}</action>
<action>Pass context data: {brainstorming_context}</action>
<action>Wait for brainstorming session completion</action>
<action>Use brainstorming output to inform module concept, agent lineup, and workflow portfolio in following steps</action>
<check>If no:</check>
<action>Proceed directly to Step 0</action>
<template-output>brainstorming_results</template-output>
</step>
<step n="0" goal="Check for module brief" optional="true">
<ask>Do you have a module brief or should we create one? [have/create/skip]</ask>
<check>If create:</check>
<action>Invoke module-brief workflow: {project-root}/bmad/bmb/workflows/module-brief/workflow.yaml</action>
<action>Wait for module brief completion</action>
<action>Load the module brief to use as blueprint</action>
<check>If have:</check>
<ask>Provide path to module brief document</ask>
<action>Load the module brief and use it to pre-populate all planning sections</action>
<check>If skip:</check>
<action>Proceed directly to Step 1</action>
<template-output>module_brief</template-output>
</step>
<step n="1" goal="Define module concept and scope">
<critical>Load and study the complete module structure guide</critical>
<action>Load module structure guide: {module_structure_guide}</action>
<action>Understand module types (Simple/Standard/Complex)</action>
<action>Review directory structures and component guidelines</action>
<action>Study the installation infrastructure patterns</action>
<action>If brainstorming or module brief was completed, reference those results to guide the conversation</action>
<action>Guide user to articulate their module's vision, exploring its purpose, what it will help with, and who will use it</action>
<action>Based on their description, intelligently propose module details:</action>
**Module Identity Development:**
1. **Module name** - Extract from their description with proper title case
2. **Module code** - Generate kebab-case from name following patterns:
- Multi-word descriptive names → shortened kebab-case
- Domain-specific terms → recognizable abbreviations
- Present suggested code and confirm it works for paths like bmad/{{code}}/agents/
3. **Module purpose** - Refine their description into 1-2 clear sentences
4. **Target audience** - Infer from context or ask if unclear
**Module Theme Reference Categories:**
- Domain-Specific (Legal, Medical, Finance, Education)
- Creative (RPG/Gaming, Story Writing, Music Production)
- Technical (DevOps, Testing, Architecture, Security)
- Business (Project Management, Marketing, Sales)
- Personal (Journaling, Learning, Productivity)
<critical>Determine output location:</critical>
- Module will be created at {installer_output_folder}
<action>Store module identity for scaffolding</action>
<template-output>module_identity</template-output>
</step>
<step n="2" goal="Plan module components">
<action>Based on the module purpose, intelligently propose an initial component architecture</action>
**Agents Planning:**
<action>Suggest agents based on module purpose, considering agent types (Simple/Expert/Module) appropriate to each role</action>
**Example Agent Patterns by Domain:**
- Data/Analytics: Analyst, Designer, Builder roles
- Gaming/Creative: Game Master, Generator, Storytelling roles
- Team/Business: Manager, Facilitator, Documentation roles
<action>Present suggested agent list with types, explaining we can start with core ones and add others later</action>
<action>Confirm which agents resonate with their vision</action>
**Workflows Planning:**
<action>Intelligently suggest workflows that complement the proposed agents</action>
**Example Workflow Patterns by Domain:**
- Data/Analytics: analyze-dataset, create-dashboard, generate-report
- Gaming/Creative: session-prep, generate-encounter, world-building
- Team/Business: planning, facilitation, documentation workflows
<action>For each workflow, note whether it should be Document, Action, or Interactive type</action>
<action>Confirm which workflows are most important to start with</action>
<action>Determine which to create now vs placeholder</action>
**Tasks Planning (optional):**
<ask>Any special tasks that don't warrant full workflows?</ask>
<check>If tasks needed:</check>
<action>For each task, capture name, purpose, and whether standalone or supporting</action>
<template-output>module_components</template-output>
</step>
<step n="2b" goal="Determine module complexity">
<action>Based on components, intelligently determine module type using criteria:</action>
**Simple Module Criteria:**
- 1-2 agents, all Simple type
- 1-3 workflows
- No complex integrations
**Standard Module Criteria:**
- 2-4 agents with mixed types
- 3-8 workflows
- Some shared resources
**Complex Module Criteria:**
- 4+ agents or multiple Module-type agents
- 8+ workflows
- Complex interdependencies
- External integrations
<action>Present determined module type with explanation of what structure will be set up</action>
<template-output>module_type</template-output>
</step>
<step n="3" goal="Create module directory structure">
<critical>Use module path determined in Step 1:</critical>
- The module base path is {{module_path}}
<action>Create base module directories at the determined path:</action>
```
{{module_code}}/
├── agents/ # Agent definitions
├── workflows/ # Workflow folders
├── tasks/ # Task files (if any)
├── templates/ # Shared templates
├── data/ # Module data files
├── config.yaml # Module configuration
└── README.md # Module documentation
```
<action>Create installer directory:</action>
```
{{module_code}}/
├── _module-installer/
│ ├── install-config.yaml
│ ├── installer.js (optional)
│ └── assets/ # Files to copy during install
├── config.yaml # Runtime configuration
├── agents/ # Agent configs (optional)
├── workflows/ # Workflow instances
└── data/ # User data directory
```
<template-output>directory_structure</template-output>
</step>
<step n="4" goal="Generate module configuration">
Create the main module config.yaml:
```yaml
# {{module_name}} Module Configuration
module_name: {{module_name}}
module_code: {{module_code}}
author: {{user_name}}
description: {{module_purpose}}
# Module paths
module_root: "{project-root}/bmad/{{module_code}}"
installer_path: "{project-root}/bmad/{{module_code}}"
# Component counts
agents:
count: {{agent_count}}
list: {{agent_list}}
workflows:
count: {{workflow_count}}
list: {{workflow_list}}
tasks:
count: {{task_count}}
list: {{task_list}}
# Module-specific settings
{{custom_settings}}
# Output configuration
output_folder: "{project-root}/docs/{{module_code}}"
data_folder: "{{determined_module_path}}/data"
```
<critical>Save location:</critical>
- Save to {{module_path}}/config.yaml
<template-output>module_config</template-output>
</step>
<step n="5" goal="Create first agent" optional="true">
<ask>Create your first agent now? [yes/no]</ask>
<check>If yes:</check>
<action>Invoke agent builder workflow: {agent_builder}</action>
<action>Pass module_components as context input</action>
<action>Guide them to create the primary agent for the module</action>
<critical>Save to module's agents folder:</critical>
- Save to {{module_path}}/agents/
<check>If no:</check>
<action>Create placeholder file in agents folder with TODO notes including agent name, purpose, and type</action>
<template-output>first_agent</template-output>
</step>
<step n="6" goal="Create first workflow" optional="true">
<ask>Create your first workflow now? [yes/no]</ask>
<check>If yes:</check>
<action>Invoke workflow builder: {workflow_builder}</action>
<action>Pass module_components as context input</action>
<action>Guide them to create the primary workflow</action>
<critical>Save to module's workflows folder:</critical>
- Save to {{module_path}}/workflows/
<check>If no:</check>
<action>Create placeholder workflow folder structure with TODO notes for workflow.yaml, instructions.md, and template.md if document workflow</action>
<template-output>first_workflow</template-output>
</step>
<step n="7" goal="Setup module installer">
<action>Load installer templates from: {installer_templates}</action>
Create install-config.yaml:
```yaml
# {{module_name}} Installation Configuration
module_name: { { module_name } }
module_code: { { module_code } }
installation_date: { { date } }
# Installation steps
install_steps:
- name: 'Create directories'
action: 'mkdir'
paths:
- '{project-root}/bmad/{{module_code}}'
- '{project-root}/bmad/{{module_code}}/data'
- '{project-root}/bmad/{{module_code}}/agents'
- name: 'Copy configuration'
action: 'copy'
source: '{installer_path}/config.yaml'
dest: '{project-root}/bmad/{{module_code}}/config.yaml'
- name: 'Register module'
action: 'register'
manifest: '{project-root}/bmad/_cfg/manifest.yaml'
# External assets (if any)
external_assets:
- description: '{{asset_description}}'
source: 'assets/{{filename}}'
dest: '{{destination_path}}'
# Post-install message
post_install_message: |
{{module_name}} has been installed successfully!
To get started:
1. Load any {{module_code}} agent
2. Use *help to see available commands
3. Check README.md for full documentation
```
Create installer.js stub (optional):
```javascript
// {{module_name}} Module Installer
// This is a placeholder for complex installation logic
function installModule(config) {
console.log('Installing {{module_name}} module...');
// TODO: Add any complex installation logic here
// Examples:
// - Database setup
// - API key configuration
// - External service registration
// - File system preparation
console.log('{{module_name}} module installed successfully!');
return true;
}
module.exports = { installModule };
```
<template-output>installer_config</template-output>
</step>
<step n="8" goal="Create module documentation">
Generate comprehensive README.md:
````markdown
# {{module_name}}
{{module_purpose}}
## Overview
This module provides:
{{component_summary}}
## Installation
```bash
bmad install {{module_code}}
```
````
## Components
### Agents ({{agent_count}})
{{agent_documentation}}
### Workflows ({{workflow_count}})
{{workflow_documentation}}
### Tasks ({{task_count}})
{{task_documentation}}
## Quick Start
1. **Load the main agent:**
```
agent {{primary_agent}}
```
2. **View available commands:**
```
*help
```
3. **Run the main workflow:**
```
workflow {{primary_workflow}}
```
## Module Structure
```
{{directory_tree}}
```
## Configuration
The module can be configured in `bmad/{{module_code}}/config.yaml`
Key settings:
{{configuration_options}}
## Examples
### Example 1: {{example_use_case}}
{{example_walkthrough}}
## Development Roadmap
- [ ] {{roadmap_item_1}}
- [ ] {{roadmap_item_2}}
- [ ] {{roadmap_item_3}}
## Contributing
To extend this module:
1. Add new agents using `create-agent` workflow
2. Add new workflows using `create-workflow` workflow
3. Submit improvements via pull request
## Author
Created by {{user_name}} on {{date}}
````
<template-output>module_readme</template-output>
</step>
<step n="9" goal="Generate component roadmap">
Create a development roadmap for remaining components:
**TODO.md file:**
```markdown
# {{module_name}} Development Roadmap
## Phase 1: Core Components
{{phase1_tasks}}
## Phase 2: Enhanced Features
{{phase2_tasks}}
## Phase 3: Polish and Integration
{{phase3_tasks}}
## Quick Commands
Create new agent:
````
workflow create-agent
```
Create new workflow:
```
workflow create-workflow
```
## Notes
{{development_notes}}
```
Ask if user wants to:
1. Continue building more components now
2. Save roadmap for later development
3. Test what's been built so far
<template-output>development_roadmap</template-output>
</step>
<step n="10" goal="Validate and finalize module">
<action>Run validation checks:</action>
**Structure validation:**
- All required directories created
- Config files properly formatted
- Installer configuration valid
**Component validation:**
- At least one agent or workflow exists (or planned)
- All references use correct paths
- Module code consistent throughout
**Documentation validation:**
- README.md complete
- Installation instructions clear
- Examples provided
<action>Present summary to {user_name}:</action>
- Module name and code
- Location path
- Agent count (created vs planned)
- Workflow count (created vs planned)
- Task count
- Installer status
<action>Provide next steps guidance:</action>
1. Complete remaining components using roadmap
2. Run the BMAD Method installer to this project location
3. Select 'Compile Agents' option after confirming folder
4. Module will be compiled and available for use
5. Test with bmad install command
6. Share or integrate with existing system
<ask>Would you like to:
- Create another component now?
- Test the module installation?
- Exit and continue later?
</ask>
<template-output>module_summary</template-output>
</step>
</workflow>

View File

@@ -1,310 +0,0 @@
# BMAD Module Structure Guide
## What is a Module?
A BMAD module is a self-contained package of agents, workflows, tasks, and resources that work together to provide specialized functionality. Think of it as an expansion pack for the BMAD Method.
## Module Architecture
### Core Structure
```
project-root/
├── bmad/{module-code}/ # Source code
│ ├── agents/ # Agent definitions
│ ├── workflows/ # Workflow folders
│ ├── tasks/ # Task files
│ ├── templates/ # Shared templates
│ ├── data/ # Static data
│ ├── config.yaml # Module config
│ └── README.md # Documentation
└── bmad/{module-code}/ # Runtime instance
├── _module-installer/ # Installation files
│ ├── install-config.yaml
│ ├── installer.js # Optional
│ └── assets/ # Install assets
├── config.yaml # User config
├── agents/ # Agent overrides
├── workflows/ # Workflow instances
└── data/ # User data
```
## Module Types by Complexity
### Simple Module (1-2 agents, 2-3 workflows)
Perfect for focused, single-purpose tools.
**Example: Code Review Module**
- 1 Reviewer Agent
- 2 Workflows: quick-review, deep-review
- Clear, narrow scope
### Standard Module (3-5 agents, 5-10 workflows)
Comprehensive solution for a domain.
**Example: Project Management Module**
- PM Agent, Scrum Master Agent, Analyst Agent
- Workflows: sprint-planning, retrospective, roadmap, user-stories
- Integrated component ecosystem
### Complex Module (5+ agents, 10+ workflows)
Full platform or framework.
**Example: RPG Toolkit Module**
- DM Agent, NPC Agent, Monster Agent, Loot Agent, Map Agent
- 15+ workflows for every aspect of game management
- Multiple interconnected systems
## Module Naming Conventions
### Module Code (kebab-case)
- `data-viz` - Data Visualization
- `team-collab` - Team Collaboration
- `rpg-toolkit` - RPG Toolkit
- `legal-assist` - Legal Assistant
### Module Name (Title Case)
- "Data Visualization Suite"
- "Team Collaboration Platform"
- "RPG Game Master Toolkit"
- "Legal Document Assistant"
## Component Guidelines
### Agents per Module
**Recommended Distribution:**
- **Primary Agent (1)**: The main interface/orchestrator
- **Specialist Agents (2-4)**: Domain-specific experts
- **Utility Agents (0-2)**: Helper/support functions
**Anti-patterns to Avoid:**
- Too many overlapping agents
- Agents that could be combined
- Agents without clear purpose
### Workflows per Module
**Categories:**
- **Core Workflows (2-3)**: Essential functionality
- **Feature Workflows (3-5)**: Specific capabilities
- **Utility Workflows (2-3)**: Supporting operations
- **Admin Workflows (0-2)**: Maintenance/config
**Workflow Complexity Guide:**
- Simple: 3-5 steps, single output
- Standard: 5-10 steps, multiple outputs
- Complex: 10+ steps, conditional logic, sub-workflows
### Tasks per Module
Tasks should be used for:
- Single-operation utilities
- Shared subroutines
- Quick actions that don't warrant workflows
## Module Dependencies
### Internal Dependencies
- Agents can reference module workflows
- Workflows can invoke module tasks
- Tasks can use module templates
### External Dependencies
- Reference other modules via full paths
- Declare dependencies in config.yaml
- Version compatibility notes
## Installation Infrastructure
### Required: install-config.yaml
```yaml
module_name: 'Module Name'
module_code: 'module-code'
install_steps:
- name: 'Create directories'
action: 'mkdir'
paths: [...]
- name: 'Copy files'
action: 'copy'
mappings: [...]
- name: 'Register module'
action: 'register'
```
### Optional: installer.js
For complex installations requiring:
- Database setup
- API configuration
- System integration
- Permission management
### Optional: External Assets
Files that get copied outside the module:
- System configurations
- User templates
- Shared resources
- Integration scripts
## Module Lifecycle
### Development Phases
1. **Planning Phase**
- Define scope and purpose
- Identify components
- Design architecture
2. **Scaffolding Phase**
- Create directory structure
- Generate configurations
- Setup installer
3. **Building Phase**
- Create agents incrementally
- Build workflows progressively
- Add tasks as needed
4. **Testing Phase**
- Test individual components
- Verify integration
- Validate installation
5. **Deployment Phase**
- Package module
- Document usage
- Distribute/share
## Best Practices
### Module Cohesion
- All components should relate to module theme
- Clear boundaries between modules
- No feature creep
### Progressive Enhancement
- Start with MVP (1 agent, 2 workflows)
- Add components based on usage
- Refactor as patterns emerge
### Documentation Standards
- Every module needs README.md
- Each agent needs purpose statement
- Workflows need clear descriptions
- Include examples and quickstart
### Naming Consistency
- Use module code prefix for uniqueness
- Consistent naming patterns within module
- Clear, descriptive names
## Example Modules
### Example 1: Personal Productivity
```
productivity/
├── agents/
│ ├── task-manager.md # GTD methodology
│ └── focus-coach.md # Pomodoro timer
├── workflows/
│ ├── daily-planning/ # Morning routine
│ ├── weekly-review/ # Week retrospective
│ └── project-setup/ # New project init
└── config.yaml
```
### Example 2: Content Creation
```
content/
├── agents/
│ ├── writer.md # Blog/article writer
│ ├── editor.md # Copy editor
│ └── seo-optimizer.md # SEO specialist
├── workflows/
│ ├── blog-post/ # Full blog creation
│ ├── social-media/ # Social content
│ ├── email-campaign/ # Email sequence
│ └── content-calendar/ # Planning
└── templates/
├── blog-template.md
└── email-template.md
```
### Example 3: DevOps Automation
```
devops/
├── agents/
│ ├── deploy-master.md # Deployment orchestrator
│ ├── monitor.md # System monitoring
│ ├── incident-responder.md # Incident management
│ └── infra-architect.md # Infrastructure design
├── workflows/
│ ├── ci-cd-setup/ # Pipeline creation
│ ├── deploy-app/ # Application deployment
│ ├── rollback/ # Emergency rollback
│ ├── health-check/ # System verification
│ └── incident-response/ # Incident handling
├── tasks/
│ ├── check-status.md # Quick status check
│ └── notify-team.md # Team notifications
└── data/
└── runbooks/ # Operational guides
```
## Module Evolution Pattern
```
Simple Module → Standard Module → Complex Module → Module Suite
(MVP) (Enhanced) (Complete) (Ecosystem)
```
## Common Pitfalls
1. **Over-engineering**: Starting too complex
2. **Under-planning**: No clear architecture
3. **Poor boundaries**: Module does too much
4. **Weak integration**: Components don't work together
5. **Missing docs**: No clear usage guide
## Success Metrics
A well-designed module has:
- ✅ Clear, focused purpose
- ✅ Cohesive components
- ✅ Smooth installation
- ✅ Comprehensive docs
- ✅ Room for growth
- ✅ Happy users!

View File

@@ -1,40 +0,0 @@
# Build Module Workflow Configuration
name: create-module
description: "Interactive workflow to build complete BMAD modules with agents, workflows, tasks, and installation infrastructure"
author: "BMad"
# Critical variables load from config_source
config_source: "{project-root}/bmad/bmb/config.yaml"
custom_module_location: "{config_source}:custom_module_location"
communication_language: "{config_source}:communication_language"
user_name: "{config_source}:user_name"
# Reference guides for module building
module_structure_guide: "{installed_path}/module-structure.md"
installer_templates: "{installed_path}/installer-templates/"
# Use existing build workflows
agent_builder: "{project-root}/bmad/bmb/workflows/create-agent/workflow.yaml"
workflow_builder: "{project-root}/bmad/bmb/workflows/create-workflow/workflow.yaml"
brainstorming_workflow: "{project-root}/bmad/core/workflows/brainstorming/workflow.yaml"
brainstorming_context: "{installed_path}/brainstorm-context.md"
# Optional docs that help understand module patterns
recommended_inputs:
- module_brief: "{output_folder}/module-brief-*.md"
- brainstorming_results: "{output_folder}/brainstorming-*.md"
- bmm_module: "{project-root}/bmad/bmm/"
- cis_module: "{project-root}/bmad/cis/"
- existing_agents: "{project-root}/bmad/*/agents/"
- existing_workflows: "{project-root}/bmad/*/workflows/"
# Module path and component files
installed_path: "{project-root}/bmad/bmb/workflows/create-module"
template: false # This is an interactive scaffolding workflow
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Output configuration - creates entire module structure
# Save to custom_module_location/{{module_code}}
installer_output_folder: "{custom_module_location}/{{module_code}}"
# Web bundle configuration

View File

@@ -108,7 +108,8 @@ Most workflows should be `standalone: true` to give users direct access.
1. **Yes (Recommended)** - Users can run it directly (standalone: true)
2. **No** - Only called by other workflows/agents (standalone: false)
Most workflows choose option 1:</ask>
Most workflows choose option 1:
</ask>
<action>Store {{standalone_setting}} as true or false based on response</action>
@@ -150,7 +151,8 @@ The architecture workflow is an excellent example of intent-based with prescript
2. **Prescriptive** - Structured, consistent, controlled interactions
3. **Mixed/Balanced** - I'll help you decide step-by-step
What feels right for your workflow's purpose?</ask>
What feels right for your workflow's purpose?
</ask>
<action>Store {{instruction_style}} preference</action>
@@ -185,11 +187,12 @@ Beyond style, consider **how interactive** this workflow should be:
<ask>What interactivity level suits this workflow?
1. **High** - Highly collaborative, user actively involved throughout
2. **Medium** - Guided with key decision points (most common)
3. **Low** - Autonomous with final review
1. **High** - Highly collaborative, user actively involved throughout (Recommended)
2. **Medium** - Guided with key decision points
3. **Low** - Mostly autonomous with final review
Select the level that matches your workflow's purpose:</ask>
Select the level that matches your workflow's purpose:
</ask>
<action>Store {{interactivity_level}} preference</action>
@@ -487,6 +490,7 @@ Generate the template.md file following guide conventions:
# Document Title
**Date:** {{date}}
**Author:** {{user_name}}
```
@@ -575,7 +579,9 @@ Review the created workflow:
4. Validate YAML syntax
5. Confirm all placeholders are replaced
**Standard Config Validation:** 6. Verify workflow.yaml contains standard config block:
**Standard Config Validation:**
6. Verify workflow.yaml contains standard config block:
- config_source defined
- output_folder, user_name, communication_language pulled from config
@@ -584,7 +590,9 @@ Review the created workflow:
7. Check instructions use config variables where appropriate
8. Verify template includes config variables in metadata (if document workflow)
**YAML/Instruction/Template Alignment:** 9. Cross-check all workflow.yaml variables against instruction usage:
**YAML/Instruction/Template Alignment:**
9. Cross-check all workflow.yaml variables against instruction usage:
- Are all yaml variables referenced in instructions.md OR template.md?
- Are there hardcoded values that should be variables?

View File

@@ -1,39 +0,0 @@
# {TITLE} Workflow Template Configuration
name: "{WORKFLOW_CODE}"
description: "{WORKFLOW_DESCRIPTION}"
author: "BMad"
# Critical variables load from config_source
# Add Additional Config Pulled Variables Here
config_source: "{project-root}/{module-code}/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
date: system-generated
# Required Data Files - HALT if missing!
# optional, can be omitted
brain_techniques: "{installed_path}/{critical-data-file.csv}" # example, can be other formats or URLs
# Optional docs that if loaded on start to kickstart this workflow or used at some point, these are meant to be suggested inputs for the user
recommended_inputs: # optional, can be omitted
- example_input: "{project-root}/{path/to/file.md}"
# Module path and component files
installed_path: "{project-root}/bmad/{module-code}/workflows/{workflow-code}"
template: "{installed_path}/template.md" # optional, can be omitted
instructions: "{installed_path}/instructions.md" # optional, can be omitted
validation: "{installed_path}/checklist.md" # optional, can be omitted
# Output configuration
default_output_file: "{output_folder}/{file.md}" # optional, can be omitted
validation_output_file: "{output_folder}/{file-validation-report.md}" # optional, can be omitted
# Tool Requirements (MCP Required Tools or other tools needed to run this workflow)
required_tools: #optional, can be omitted
- "Tool Name": #example, can be omitted if none
description: "Description of why this tool is needed"
link: "https://link-to-tool.com"
# Web Bundle Configuration (optional - for web-deployable workflows)
# IMPORTANT: Web bundles are self-contained and cannot use config_source variables
# All referenced files must be listed in web_bundle_files

View File

@@ -1,38 +0,0 @@
# Build Workflow - Workflow Builder Configuration
name: create-workflow
description: "Interactive workflow builder that guides creation of new BMAD workflows with proper structure and validation for optimal human-AI collaboration. Includes optional brainstorming phase for workflow ideas and design."
author: "BMad Builder"
# Critical variables
config_source: "{project-root}/bmad/bmb/config.yaml"
custom_workflow_location: "{config_source}:custom_workflow_location"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
# Template files for new workflows
template_workflow_yaml: "{workflow_template_path}/workflow.yaml"
template_instructions: "{workflow_template_path}/instructions.md"
template_template: "{workflow_template_path}/template.md"
template_checklist: "{workflow_template_path}/checklist.md"
# Optional input docs
recommended_inputs:
- existing_workflows: "{project-root}/bmad/*/workflows/"
- bmm_workflows: "{project-root}/bmad/bmm/workflows/"
# Module path and component files
installed_path: "{project-root}/bmad/bmb/workflows/create-workflow"
template: false # This is an action workflow - no template needed
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Required data files - CRITICAL for workflow conventions
workflow_creation_guide: "{installed_path}/workflow-creation-guide.md"
workflow_template_path: "{installed_path}/workflow-template"
# Output configuration - Creates the new workflow folder with all files
# If workflow belongs to a module: Save to module's workflows folder
# If standalone workflow: Save to custom_workflow_location/{{workflow_name}}
module_output_folder: "{project-root}/bmad/{{target_module}}/workflows/{{workflow_name}}"
standalone_output_folder: "{custom_workflow_location}/{{workflow_name}}"
# Web bundle configuration

View File

@@ -1,25 +0,0 @@
# Edit Workflow - Workflow Editor Configuration
name: "edit-workflow"
description: "Edit existing BMAD workflows while following all best practices and conventions"
author: "BMad"
# Critical variables load from config_source
config_source: "{project-root}/bmad/bmb/config.yaml"
communication_language: "{config_source}:communication_language"
user_name: "{config_source}:user_name"
# Required Data Files - Critical for understanding workflow conventions
workflow_creation_guide: "{project-root}/bmad/bmb/workflows/create-workflow/workflow-creation-guide.md"
workflow_execution_engine: "{project-root}/bmad/core/tasks/workflow.xml"
# Optional docs that can be used to understand the target workflow
recommended_inputs:
- target_workflow: "Path to the workflow.yaml file to edit"
- workflow_examples: "{project-root}/bmad/bmm/workflows/"
# Module path and component files
installed_path: "{project-root}/bmad/bmb/workflows/edit-workflow"
template: false # This is an action workflow - no template needed
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Web bundle configuration

View File

@@ -1,27 +0,0 @@
# Module Brief Workflow Configuration
name: module-brief
description: "Create a comprehensive Module Brief that serves as the blueprint for building new BMAD modules using strategic analysis and creative vision"
author: "BMad Builder"
# Critical variables
config_source: "{project-root}/bmad/bmb/config.yaml"
output_folder: "{config_source}:output_folder"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
date: system-generated
# Optional input docs that enhance module planning
recommended_inputs:
- brainstorming_results: "{output_folder}/brainstorming-*.md"
- existing_modules: "{project-root}/bmad/"
- module_examples: "{project-root}/bmad/bmb/workflows/create-module/module-structure.md"
# Module path and component files
installed_path: "{project-root}/bmad/bmb/workflows/module-brief"
template: "{installed_path}/template.md"
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Output configuration
default_output_file: "{output_folder}/module-brief-{{module_code}}-{{date}}.md"
# Web bundle configuration

View File

@@ -1,31 +0,0 @@
# ReDoc - Reverse-Tree Documentation Engine
name: "redoc"
description: "Autonomous documentation system that maintains module, workflow, and agent documentation using a reverse-tree approach (leaf folders first, then parents). Understands BMAD conventions and produces technical writer quality output."
author: "BMad"
# Critical variables
config_source: "{project-root}/bmad/bmb/config.yaml"
user_name: "{config_source}:user_name"
communication_language: "{config_source}:communication_language"
# Required knowledge base - BMAD conventions and patterns
bmad_conventions:
agent_architecture: "{project-root}/src/modules/bmb/workflows/create-agent/agent-architecture.md"
agent_command_patterns: "{project-root}/src/modules/bmb/workflows/create-agent/agent-command-patterns.md"
agent_types: "{project-root}/src/modules/bmb/workflows/create-agent/agent-types.md"
module_structure: "{project-root}/src/modules/bmb/workflows/create-module/module-structure.md"
workflow_guide: "{project-root}/src/modules/bmb/workflows/create-workflow/workflow-creation-guide.md"
# Runtime inputs
target_path: "" # User specifies: module path, workflow path, agent path, or folder path
# Module path and component files
installed_path: "{project-root}/src/modules/bmb/workflows/redoc"
template: false # Action workflow - updates files in place
instructions: "{installed_path}/instructions.md"
validation: "{installed_path}/checklist.md"
# Configuration
autonomous: true # Runs without user checkpoints unless clarification needed
# Web bundle configuration