bmad初始化

This commit is contained in:
2025-11-01 19:22:39 +08:00
parent 5b21dc0bd5
commit 426ae41f54
447 changed files with 80633 additions and 0 deletions

View File

@@ -0,0 +1,229 @@
# Create Module Workflow
Interactive scaffolding system creating complete BMad modules with agents, workflows, tasks, and installation infrastructure.
## Table of Contents
- [Quick Start](#quick-start)
- [Workflow Phases](#workflow-phases)
- [Output Structure](#output-structure)
- [Module Components](#module-components)
- [Best Practices](#best-practices)
## 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
```
## Workflow Phases
### Phase 1: Concept Definition
- Define module purpose and audience
- Establish module code (kebab-case) and name
- Choose category (Domain, Creative, Technical, Business, Personal)
- Plan component architecture
**Module Brief Integration:**
- Auto-detects existing briefs
- Uses as pre-populated blueprint
- Accelerates planning phase
### Phase 2: Architecture Planning
- 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
```
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 # Module documentation
├── TODO.md # Development roadmap
└── config.yaml # Runtime configuration
```
### Configuration Files
**install-config.yaml** - Installation questions
```yaml
questions:
- id: user_name
prompt: 'Your name?'
default: 'User'
- id: output_folder
prompt: 'Output location?'
default: './output'
```
**config.yaml** - Generated from user answers during install
```yaml
user_name: 'John Doe'
output_folder: './my-output'
```
## Module Components
### Agents
- Full module agents with workflows
- Expert agents with sidecars
- Simple utility agents
### Workflows
- Multi-step guided processes
- Configuration-driven
- Web bundle support
### Tasks
- Reusable operations
- Agent-agnostic
- Modular components
### Templates
- Document structures
- Output formats
- Report templates
## Best Practices
### Planning
1. **Use module-brief workflow first** - Creates comprehensive blueprint
2. **Define clear scope** - Avoid feature creep
3. **Plan component interactions** - Map agent/workflow relationships
### Structure
1. **Follow conventions** - Use established patterns
2. **Keep components focused** - Single responsibility
3. **Document thoroughly** - Clear README and inline docs
### Development
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
### Installation
1. **Minimal config questions** - Only essential settings
2. **Smart defaults** - Sensible out-of-box experience
3. **Clear post-install** - Guide users to first steps
## Integration Points
### With Other Workflows
- **module-brief** - Strategic planning input
- **create-agent** - Agent component creation
- **create-workflow** - Workflow building
- **redoc** - Documentation maintenance
### With BMad Core
- Uses core framework capabilities
- Integrates with module system
- Follows BMad conventions
## Examples
### Domain-Specific Module
```
Category: Domain-Specific
Code: legal-advisor
Components:
- Contract Review Agent
- Compliance Workflow
- Legal Templates
```
### Creative Module
```
Category: Creative
Code: story-builder
Components:
- Narrative Agent
- Plot Workflow
- Character Templates
```
### Technical Module
```
Category: Technical
Code: api-tester
Components:
- Test Runner Agent
- API Validation Workflow
- Test Report Templates
```
## Workflow Files
```
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
- [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

@@ -0,0 +1,137 @@
# Module Brainstorming Context
_Context provided to brainstorming workflow when creating a new BMAD module_
## Session Focus
You are brainstorming ideas for a **complete BMAD module** - a self-contained package that extends the BMAD Method with specialized domain expertise and capabilities.
## What is a BMAD Module?
A module is a cohesive package that provides:
- **Domain Expertise**: Specialized knowledge in a specific area (RPG, DevOps, Content Creation, etc.)
- **Agent Team**: Multiple AI personas with complementary skills
- **Workflows**: Guided processes for common tasks in the domain
- **Templates**: Document structures for consistent outputs
- **Integration**: Components that work together seamlessly
## Brainstorming Goals
Explore and define:
### 1. Domain and Purpose
- **What domain/problem space?** (e.g., game development, marketing, personal productivity)
- **Who is the target user?** (developers, writers, managers, hobbyists)
- **What pain points does it solve?** (tedious tasks, missing structure, need for expertise)
- **What makes this domain exciting?** (creativity, efficiency, empowerment)
### 2. Agent Team Composition
- **How many agents?** (typically 3-7 for a module)
- **What roles/personas?** (architect, researcher, reviewer, specialist)
- **How do they collaborate?** (handoffs, reviews, ensemble work)
- **What personality theme?** (Star Trek crew, superhero team, fantasy party, professional squad)
### 3. Core Workflows
- **What documents need creating?** (plans, specs, reports, creative outputs)
- **What processes need automation?** (analysis, generation, review, deployment)
- **What workflows enable the vision?** (3-10 key workflows that define the module)
### 4. Value Proposition
- **What becomes easier?** (specific tasks that get 10x faster)
- **What becomes possible?** (new capabilities previously unavailable)
- **What becomes better?** (quality improvements, consistency gains)
## Creative Constraints
A good BMAD module should be:
- **Focused**: Serves a specific domain well (not generic)
- **Complete**: Provides end-to-end capabilities for that domain
- **Cohesive**: Agents and workflows complement each other
- **Fun**: Personality and creativity make it enjoyable to use
- **Practical**: Solves real problems, delivers real value
## Module Architecture Questions
1. **Module Identity**
- Module code (kebab-case, e.g., "rpg-toolkit")
- Module name (friendly, e.g., "RPG Toolkit")
- Module purpose (one sentence)
- Target audience
2. **Agent Lineup**
- Agent names and roles
- Communication styles and personalities
- Expertise areas
- Command sets (what each agent can do)
3. **Workflow Portfolio**
- Document generation workflows
- Action/automation workflows
- Analysis/research workflows
- Creative/ideation workflows
4. **Integration Points**
- How agents invoke workflows
- How workflows use templates
- How components pass data
- Dependencies on other modules
## Example Module Patterns
### Professional Domains
- **DevOps Suite**: Deploy, Monitor, Troubleshoot agents + deployment workflows
- **Marketing Engine**: Content, SEO, Analytics agents + campaign workflows
- **Legal Assistant**: Contract, Research, Review agents + document workflows
### Creative Domains
- **RPG Toolkit**: DM, NPC, Quest agents + adventure creation workflows
- **Story Crafter**: Plot, Character, World agents + writing workflows
- **Music Producer**: Composer, Arranger, Mixer agents + production workflows
### Personal Domains
- **Life Coach**: Planner, Tracker, Mentor agents + productivity workflows
- **Learning Companion**: Tutor, Quiz, Reviewer agents + study workflows
- **Health Guide**: Nutrition, Fitness, Wellness agents + tracking workflows
## Suggested Brainstorming Techniques
Particularly effective for module ideation:
1. **Domain Immersion**: Deep dive into target domain's problems
2. **Persona Mapping**: Who needs this and what do they struggle with?
3. **Workflow Mapping**: What processes exist today? How could they improve?
4. **Team Building**: What personalities would make a great team?
5. **Integration Thinking**: How do pieces connect and amplify each other?
## Key Questions to Answer
1. What domain expertise should this module embody?
2. What would users be able to do that they can't do now?
3. Who are the 3-7 agents and what are their personalities?
4. What are the 5-10 core workflows?
5. What makes this module delightful to use?
6. How is this different from existing tools?
7. What's the "killer feature" that makes this essential?
## Output Goals
Generate:
- **Module concept**: Clear vision and purpose
- **Agent roster**: Names, roles, personalities for each agent
- **Workflow list**: Core workflows with brief descriptions
- **Unique angle**: What makes this module special
- **Use cases**: 3-5 concrete scenarios where this module shines
---
_This focused context helps create cohesive, valuable BMAD modules_

View File

@@ -0,0 +1,244 @@
# 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)
- [ ] `/_module-installer/install-config.yaml` present (defines configuration questions)
- [ ] `README.md` present with documentation
### Installed Module Structure (generated in target after installation)
- [ ] `/agents` directory for compiled agents
- [ ] `/workflows` directory for workflow instances
- [ ] `/data` directory for user data
- [ ] `config.yaml` generated from install-config.yaml during installation
## 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
### Installation Configuration (install-config.yaml)
- [ ] `install-config.yaml` exists in `_module-installer`
- [ ] Module metadata present (code, name, version)
- [ ] Configuration questions defined for user input
- [ ] Default values provided for all questions
- [ ] Prompt text is clear and helpful
- [ ] Result templates use proper variable substitution
- [ ] Paths use proper variables ({project-root}, {value}, etc.)
### Generated Config (config.yaml in target)
- [ ] Generated during installation from install-config.yaml
- [ ] Contains all user-provided configuration values
- [ ] Module metadata included
- [ ] No config.yaml should exist in source module
## 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

@@ -0,0 +1,92 @@
# {{MODULE_NAME}} Module Configuration
# This file defines installation questions and module configuration values
code: "{{MODULE_CODE}}"
name: "{{MODULE_NAME}}"
default_selected: "{{DEFAULT_SELECTED}}" # true if this should be selected by default
# Welcome message shown during installation
prompt:
- "{{WELCOME_MESSAGE_LINE_1}}"
- "{{WELCOME_MESSAGE_LINE_2}}"
# Core config values are automatically inherited:
## user_name
## communication_language
## document_output_language
## output_folder
# ============================================================================
# CONFIGURATION FIELDS
# ============================================================================
#
# Each field can be:
# 1. INTERACTIVE (has 'prompt' - asks user during installation)
# 2. STATIC (no 'prompt' - just uses 'result' value)
#
# Field structure:
# field_name:
# prompt: "Question to ask user" (optional - omit for static values)
# default: "default_value" (optional)
# result: "{value}" or "static-value"
# single-select: [...] (optional - for dropdown)
# multi-select: [...] (optional - for checkboxes)
#
# Special placeholders in result:
# {value} - replaced with user's answer
# {project-root} - replaced with project root path
# {directory_name} - replaced with project directory name
# {module_code} - replaced with this module's code
# ============================================================================
# EXAMPLE: Interactive text input
# example_project_name:
# prompt: "What is your project name?"
# default: "{directory_name}"
# result: "{value}"
# EXAMPLE: Interactive single-select dropdown
# example_skill_level:
# prompt: "What is your experience level?"
# default: "intermediate"
# result: "{value}"
# single-select:
# - value: "beginner"
# label: "Beginner - New to this domain"
# - value: "intermediate"
# label: "Intermediate - Familiar with basics"
# - value: "expert"
# label: "Expert - Deep knowledge"
# EXAMPLE: Interactive multi-select checkboxes
# example_features:
# prompt:
# - "Which features do you want to enable?"
# - "(Select all that apply)"
# result: "{value}"
# multi-select:
# - "Feature A"
# - "Feature B"
# - "Feature C"
# EXAMPLE: Interactive path input
# example_output_path:
# prompt: "Where should outputs be saved?"
# default: "output/{{MODULE_CODE}}"
# result: "{project-root}/{value}"
# EXAMPLE: Static value (no user prompt)
# example_static_setting:
# result: "hardcoded-value"
# EXAMPLE: Static path
# module_data_path:
# result: "{project-root}/bmad/{{MODULE_CODE}}/data"
# ============================================================================
# YOUR MODULE CONFIGURATION FIELDS
# ============================================================================
# Replace examples above with your module's actual configuration needs.
# Delete this comment block and the examples when implementing.
# ============================================================================
# TODO: INSERT {MODULE_CONFIG_FIELDS} HERE

View File

@@ -0,0 +1,231 @@
/* 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

@@ -0,0 +1,581 @@
# 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">
<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>
<check if="no">
<action>Proceed directly to Step 0</action>
</check>
<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">
<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>
<check if="have">
<ask>Provide path to module brief document</ask>
<action>Load the module brief and use it to pre-populate all planning sections</action>
</check>
<check if="skip">
<action>Proceed directly to Step 1</action>
</check>
<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>
<action if="tasks needed">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
├── _module-installer/ # Installation configuration
│ └── install-config.yaml # Configuration questions (config.yaml generated at install time)
└── README.md # Module documentation
```
<action>Create installer directory:</action>
**INSTALLED MODULE STRUCTURE** (generated in target project after installation):
```
{{module_code}}/
├── agents/ # Compiled agents
├── workflows/ # Workflow instances
├── config.yaml # Generated from install-config.yaml during installation
└── data/ # User data directory
```
**SOURCE MODULE** (\_module-installer is for installation only, not copied to target):
```
{{module_code}}/
├── _module-installer/
│ ├── install-config.yaml # Configuration questions
│ ├── installer.js # Optional custom installation logic
│ └── assets/ # Files to copy during install
```
<template-output>directory_structure</template-output>
</step>
<step n="4" goal="Plan module configuration fields">
<action>Based on the module purpose and components, determine what configuration settings the module needs</action>
**Configuration Field Planning:**
<ask>Does your module need any user-configurable settings during installation?</ask>
**Common configuration patterns:**
- Output/data paths (where module saves files)
- Feature toggles (enable/disable functionality)
- Integration settings (API keys, external services)
- Behavior preferences (automation level, detail level)
- User skill level or experience settings
<action>For each configuration field needed, determine:</action>
1. Field name (snake_case)
2. Whether it's INTERACTIVE (asks user) or STATIC (hardcoded)
3. Prompt text (if interactive)
4. Default value
5. Type: text input, single-select, or multi-select
6. Result template (how the value gets stored)
<action>Store planned configuration fields for installer generation in step 7</action>
<template-output>module_config_fields</template-output>
</step>
<step n="5" goal="Create first agent" optional="true">
<ask>Create your first agent now? [yes/no]</ask>
<check if="yes">
<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>
<check if="no">
<action>Create placeholder file in agents folder with TODO notes including agent name, purpose, and type</action>
</check>
<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">
<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>
<check if="no">
<action>Create placeholder workflow folder structure with TODO notes for workflow.yaml, instructions.md, and template.md if document workflow</action>
</check>
<template-output>first_workflow</template-output>
</step>
<step n="7" goal="Setup module installer">
<action>Load installer template from: {installer_templates}/install-config.yaml</action>
<critical>IMPORTANT: Create install-config.yaml NOT install-config.yaml</critical>
<critical>This is the STANDARD format that BMAD installer uses</critical>
Create \_module-installer/install-config.yaml:
```yaml
# {{module_name}} Module Configuration
# This file defines installation questions and module configuration values
code: {{module_code}}
name: "{{module_name}}"
default_selected: false # Set to true if this should be selected by default
# Welcome message shown during installation
prompt:
- "Thank you for choosing {{module_name}}!"
- "{{brief_module_description}}"
# Core config values are automatically inherited:
## user_name
## communication_language
## document_output_language
## output_folder
# ============================================================================
# CONFIGURATION FIELDS (from step 4 planning)
# ============================================================================
# Each field can be:
# 1. INTERACTIVE (has 'prompt' - asks user during installation)
# 2. STATIC (no 'prompt' - just uses 'result' value)
# ============================================================================
# EXAMPLE Interactive text input:
# output_path:
# prompt: "Where should {{module_code}} save outputs?"
# default: "output/{{module_code}}"
# result: "{project-root}/{value}"
# EXAMPLE Interactive single-select:
# detail_level:
# prompt: "How detailed should outputs be?"
# default: "standard"
# result: "{value}"
# single-select:
# - value: "minimal"
# label: "Minimal - Brief summaries only"
# - value: "standard"
# label: "Standard - Balanced detail"
# - value: "detailed"
# label: "Detailed - Comprehensive information"
# EXAMPLE Static value:
# module_version:
# result: "1.0.0"
# EXAMPLE Static path:
# data_path:
# result: "{project-root}/bmad/{{module_code}}/data"
{{generated_config_fields_from_step_4}}
```
<critical>Save location:</critical>
- Save to {{module_path}}/\_module-installer/install-config.yaml
<ask>Does your module need custom installation logic (database setup, API registration, etc.)?</ask>
<check if="yes, create installer.js">
```javascript
// {{module_name}} Module Installer
// Custom installation logic
/\*\*
- Module installation hook
- Called after files are copied but before IDE configuration
-
- @param {Object} options - Installation options
- @param {string} options.projectRoot - Project root directory
- @param {Object} options.config - Module configuration from install-config.yaml
- @param {Array} options.installedIDEs - List of IDE codes being configured
- @param {Object} options.logger - Logger instance (log, warn, error methods)
- @returns {boolean} - true if successful, false to abort installation
\*/
async function install(options) {
const { projectRoot, config, installedIDEs, logger } = options;
logger.log('Running {{module_name}} custom installer...');
// TODO: Add custom installation logic here
// Examples:
// - Create database tables
// - Download external assets
// - Configure API connections
// - Initialize data files
// - Set up webhooks or integrations
logger.log('{{module_name}} custom installation complete!');
return true;
}
module.exports = { install };
`````
<critical>Save location:</critical>
- Save to {{module_path}}/\_module-installer/installer.js
</check>
<check if="no">
<action>Skip installer.js creation - the standard installer will handle everything</action>
</check>
<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

@@ -0,0 +1,366 @@
# 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
```
# SOURCE MODULE (in BMAD-METHOD project)
src/modules/{module-code}/
├── agents/ # Agent definitions (.agent.yaml)
├── workflows/ # Workflow folders
├── tasks/ # Task files
├── tools/ # Tool files
├── templates/ # Shared templates
├── data/ # Static data
├── _module-installer/ # Installation configuration
│ ├── install-config.yaml # Installation questions & config
│ ├── installer.js # Optional custom install logic
│ └── assets/ # Files to copy during install
└── README.md # Module documentation
# INSTALLED MODULE (in target project)
{project-root}/bmad/{module-code}/
├── agents/ # Compiled agent files (.md)
├── workflows/ # Workflow instances
├── tasks/ # Task files
├── tools/ # Tool files
├── templates/ # Templates
├── data/ # Module data
├── config.yaml # Generated from install-config.yaml
└── README.md # Module documentation
```
## 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: \_module-installer/install-config.yaml
This file defines both installation questions AND static configuration values:
```yaml
# Module metadata
code: module-code
name: 'Module Name'
default_selected: false
# Welcome message during installation
prompt:
- 'Welcome to Module Name!'
- 'Brief description here'
# Core values automatically inherited from installer:
## user_name
## communication_language
## document_output_language
## output_folder
# INTERACTIVE fields (ask user during install)
output_location:
prompt: 'Where should module outputs be saved?'
default: 'output/module-code'
result: '{project-root}/{value}'
feature_level:
prompt: 'Which feature set?'
default: 'standard'
result: '{value}'
single-select:
- value: 'basic'
label: 'Basic - Core features only'
- value: 'standard'
label: 'Standard - Recommended features'
- value: 'advanced'
label: 'Advanced - All features'
# STATIC fields (no prompt, just hardcoded values)
module_version:
result: '1.0.0'
data_path:
result: '{project-root}/bmad/module-code/data'
```
**Key Points:**
- File is named `install-config.yaml` (NOT install-config.yaml)
- Supports both interactive prompts and static values
- `result` field uses placeholders: `{value}`, `{project-root}`, `{directory_name}`
- Installer generates final `config.yaml` from this template
### Optional: \_module-installer/installer.js
For complex installations requiring custom logic:
```javascript
/**
* @param {Object} options - Installation options
* @param {string} options.projectRoot - Target project directory
* @param {Object} options.config - Config from install-config.yaml
* @param {Array} options.installedIDEs - IDEs being configured
* @param {Object} options.logger - Logger (log, warn, error)
* @returns {boolean} - true if successful
*/
async function install(options) {
// Custom installation logic here
// - Database setup
// - API configuration
// - External downloads
// - Integration setup
return true;
}
module.exports = { install };
```
### Optional: \_module-installer/assets/
Files to copy during installation:
- External configurations
- Documentation
- Example files
- 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

@@ -0,0 +1,43 @@
# 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}}"
standalone: true
# Web bundle configuration