Ignore and untrack BMad directories
This commit is contained in:
Max
@@ -1,179 +0,0 @@
|
||||
# Agent Architecture for Modules
|
||||
|
||||
**Purpose:** High-level guidance for planning agents in your module — not implementation details (that's what the agent-builder workflow is for).
|
||||
|
||||
---
|
||||
|
||||
## Single Agent vs. Multi-Agent Module
|
||||
|
||||
### Single Agent Module
|
||||
|
||||
**Use when:** One persona can handle the module's purpose.
|
||||
|
||||
**Characteristics:**
|
||||
- Simpler, focused
|
||||
- Clear single point of contact
|
||||
- Good for narrow domains
|
||||
|
||||
**Question:** Could one expert agent with a sidecar handle this entire module?
|
||||
|
||||
---
|
||||
|
||||
### Multi-Agent Module
|
||||
|
||||
**Use when:** Different expertise areas justify specialized personas.
|
||||
|
||||
**Characteristics:**
|
||||
- Each agent has a distinct role and expertise
|
||||
- Agents form a cohesive team around the module's theme
|
||||
- Menus coordinate to guide users to the right agent
|
||||
|
||||
**Why multi-agent?**
|
||||
- Different workflows need different expert perspectives
|
||||
- Users expect to talk to "the right expert" for each task
|
||||
- The module covers a domain too broad for one persona
|
||||
|
||||
---
|
||||
|
||||
## Flagship Example: BMM Agent Team
|
||||
|
||||
BMM demonstrates a multi-agent module with **9 specialized agents** forming a complete software development team.
|
||||
|
||||
### The BMM Theme
|
||||
|
||||
**"Agile software delivery, AI-driven"**
|
||||
|
||||
Every agent serves this theme — they're a complete team working together.
|
||||
|
||||
### BMM Agent Overview
|
||||
|
||||
| Agent | Name | Role | Responsible For |
|
||||
|-------|------|------|-----------------|
|
||||
| PM | John | Product Manager | PRDs, requirements, user stories |
|
||||
| Architect | Winston | System Architect | Technical design, architecture |
|
||||
| UX | | UX Designer | User research, UX design |
|
||||
| Dev | | Developer | Implementation, coding |
|
||||
| TEA | | Test Engineer Architect | Test architecture, QA |
|
||||
| SM | | Scrum Master | Sprint planning, workflow status |
|
||||
| Tech Writer | | Technical Writer | Documentation |
|
||||
| Analyst | | Business Analyst | Analysis, metrics |
|
||||
| Quick Flow | | Solo Developer | Quick standalone work |
|
||||
|
||||
### Key Patterns
|
||||
|
||||
1. **Shared commands** — All agents have `[WS]` Workflow Status
|
||||
2. **Specialty commands** — Each agent has unique commands (PM→PRD, Architect→Architecture)
|
||||
3. **No overlap** — Each command has one clear owner
|
||||
4. **Collaboration** — Agents reference each other's work (PRD → Architecture → Implementation)
|
||||
|
||||
---
|
||||
|
||||
## Planning Your Agents
|
||||
|
||||
### For Each Agent, Document:
|
||||
|
||||
1. **Role** — What is this agent responsible for?
|
||||
2. **Workflows** — Which workflows will this agent trigger/own?
|
||||
3. **Human Name** — What's their persona name? (e.g., "John", "Winston")
|
||||
4. **Communication Style** — How do they talk? (e.g., "Direct and data-sharp", "Calm and pragmatic")
|
||||
5. **Skills/Expertise** — What knowledge does this agent bring?
|
||||
6. **Memory/Learning** — Does this agent need to remember things over time? (hasSidecar)
|
||||
|
||||
That's it! The agent-builder workflow will handle the detailed implementation.
|
||||
|
||||
---
|
||||
|
||||
## Agent Memory & Learning
|
||||
|
||||
### Sidecar Agents (hasSidecar: true)
|
||||
|
||||
**Use when:** The agent needs to remember context across sessions.
|
||||
|
||||
**Characteristics:**
|
||||
- Has a sidecar file that persists between conversations
|
||||
- Learns from user interactions
|
||||
- Remembers project details, preferences, past work
|
||||
|
||||
**Examples:**
|
||||
- An agent that tracks project decisions over time
|
||||
- An agent that learns user preferences
|
||||
- An agent that maintains ongoing project context
|
||||
|
||||
### Stateless Agents (hasSidecar: false)
|
||||
|
||||
**Use when:** The agent doesn't need persistent memory.
|
||||
|
||||
**Characteristics:**
|
||||
- Each conversation starts fresh
|
||||
- Relies on shared context files (like project-context.md)
|
||||
- Simpler, more predictable
|
||||
|
||||
**Most module agents are stateless** — they reference shared project context rather than maintaining their own memory.
|
||||
|
||||
---
|
||||
|
||||
## Agent-Workflow Coordination
|
||||
|
||||
### Menu Triggers
|
||||
|
||||
Each agent has menu items that trigger workflows:
|
||||
|
||||
| Trigger Type | Pattern | Example |
|
||||
|--------------|---------|---------|
|
||||
| Shared | Same across all agents | `[WS]` Workflow Status |
|
||||
| Specialty | Unique to this agent | `[PR]` Create PRD (PM only) |
|
||||
| Cross-reference | Points to another agent's workflow | "See architecture" |
|
||||
|
||||
### Simple Planning Format
|
||||
|
||||
For each agent, just document:
|
||||
|
||||
```
|
||||
Agent: PM (John)
|
||||
Role: Product Manager, requirements, PRDs
|
||||
Triggers:
|
||||
- WS → Workflow Status (shared)
|
||||
- PR → Create PRD (specialty)
|
||||
- ES → Epics and Stories (specialty)
|
||||
Memory: No (uses shared project-context)
|
||||
```
|
||||
|
||||
The agent-builder workflow will convert this into the proper format.
|
||||
|
||||
---
|
||||
|
||||
## When to Use Multiple Agents
|
||||
|
||||
**Consider multiple agents when:**
|
||||
- Different workflows require different expertise
|
||||
- The domain has clear specialization areas
|
||||
- Users would expect to talk to different "experts"
|
||||
- The module covers a broad process (like software development)
|
||||
|
||||
**Use a single agent when:**
|
||||
- The domain is focused and narrow
|
||||
- One expertise area covers all workflows
|
||||
- Simplicity is preferred
|
||||
- The agent could reasonably handle everything with a sidecar
|
||||
|
||||
---
|
||||
|
||||
## Quick Agent Planning Checklist
|
||||
|
||||
For each agent in your module:
|
||||
|
||||
- [ ] Role defined (what they're responsible for)
|
||||
- [ ] Workflows assigned (which workflows they trigger)
|
||||
- [ ] Human name chosen (persona)
|
||||
- [ ] Communication style described
|
||||
- [ ] Skills/expertise identified
|
||||
- [ ] Memory decision (hasSidecar: true/false)
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **Don't worry about the exact YAML format** — agent-builder handles that
|
||||
- **Focus on the planning** — who does what, how they work together
|
||||
- **Keep it high-level** — this is about the module's agent architecture, not implementation details
|
||||
- **BMM is the reference** — look at how their agents form a cohesive team
|
||||
@@ -1,79 +0,0 @@
|
||||
# Agent Specification: {agent_name}
|
||||
|
||||
**Module:** {module_code}
|
||||
**Status:** Placeholder — To be created via create-agent workflow
|
||||
**Created:** {date}
|
||||
|
||||
---
|
||||
|
||||
## Agent Metadata
|
||||
|
||||
```yaml
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/{module_code}/agents/{agent_file_name}.md"
|
||||
name: {agent_human_name}
|
||||
title: {agent_title}
|
||||
icon: {agent_icon}
|
||||
module: {module_code}
|
||||
hasSidecar: false
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Persona
|
||||
|
||||
### Role
|
||||
|
||||
{agent_role}
|
||||
|
||||
### Identity
|
||||
|
||||
{agent_identity}
|
||||
|
||||
### Communication Style
|
||||
|
||||
{agent_communication_style}
|
||||
|
||||
### Principles
|
||||
|
||||
{agent_principles}
|
||||
|
||||
---
|
||||
|
||||
## Agent Menu
|
||||
|
||||
### Planned Commands
|
||||
|
||||
| Trigger | Command | Description | Workflow |
|
||||
|---------|---------|-------------|----------|
|
||||
{agent_menu_table}
|
||||
|
||||
---
|
||||
|
||||
## Agent Integration
|
||||
|
||||
### Shared Context
|
||||
|
||||
- References: `{shared_context_files}`
|
||||
- Collaboration with: {collaborating_agents}
|
||||
|
||||
### Workflow References
|
||||
|
||||
{workflow_references}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Use the create-agent workflow to build this agent.**
|
||||
|
||||
Inputs needed:
|
||||
- Agent name and human name
|
||||
- Role and expertise area
|
||||
- Communication style preferences
|
||||
- Menu commands and workflow mappings
|
||||
|
||||
---
|
||||
|
||||
_Spec created on {date} via BMAD Module workflow_
|
||||
@@ -1,348 +0,0 @@
|
||||
# Module Installer Standards
|
||||
|
||||
**Purpose:** How the `_module-installer` folder works, including installer.js patterns and platform-specific configuration.
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The `_module-installer` folder contains optional installation logic for your module. It runs AFTER the IDE installations and can:
|
||||
- Create directories specified in module.yaml
|
||||
- Copy assets or templates
|
||||
- Configure IDE-specific settings
|
||||
- Set up platform-specific integrations
|
||||
|
||||
---
|
||||
|
||||
## When Do You Need an Installer?
|
||||
|
||||
### Use an Installer When:
|
||||
|
||||
- Creating directories based on user configuration
|
||||
- Copying template files to the user's project
|
||||
- IDE-specific setup (Claude Code, Windsurf, Cursor, etc.)
|
||||
- Platform-specific integrations
|
||||
|
||||
### Skip the Installer When:
|
||||
|
||||
- Module only provides agents and workflows
|
||||
- No file operations needed
|
||||
- No IDE-specific configuration
|
||||
|
||||
---
|
||||
|
||||
## Folder Structure
|
||||
|
||||
```
|
||||
_module-installer/
|
||||
├── installer.js # Main installer (REQUIRED if folder exists)
|
||||
└── platform-specifics/ # IDE-specific handlers (optional)
|
||||
├── claude-code.js
|
||||
├── windsurf.js
|
||||
├── cursor.js
|
||||
└── ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## installer.js Pattern
|
||||
|
||||
### Function Signature
|
||||
|
||||
```javascript
|
||||
/**
|
||||
* Module Installer
|
||||
*
|
||||
* @param {Object} options - Installation options
|
||||
* @param {string} options.projectRoot - The root directory of the target project
|
||||
* @param {Object} options.config - Module configuration from module.yaml (resolved variables)
|
||||
* @param {Array<string>} options.installedIDEs - Array of IDE codes that were installed
|
||||
* @param {Object} options.logger - Logger instance for output
|
||||
* @returns {Promise<boolean>} - Success status (true = success, false = failure)
|
||||
*/
|
||||
async function install(options) {
|
||||
const { projectRoot, config, installedIDEs, logger } = options;
|
||||
|
||||
try {
|
||||
// Installation logic here
|
||||
logger.log(chalk.blue('Installing {Module Name}...'));
|
||||
|
||||
// ... your logic ...
|
||||
|
||||
logger.log(chalk.green('✓ {Module Name} installation complete'));
|
||||
return true;
|
||||
} catch (error) {
|
||||
logger.error(chalk.red(`Error installing module: ${error.message}`));
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = { install };
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### What You Receive
|
||||
|
||||
| Parameter | Type | Description |
|
||||
|-----------|------|-------------|
|
||||
| `projectRoot` | string | Absolute path to the user's project root |
|
||||
| `config` | object | Resolved module.yaml variables |
|
||||
| `installedIDEs` | array | List of IDE codes installed (e.g., `['claude-code', 'windsurf']`) |
|
||||
| `logger` | object | Logger with `.log()`, `.warn()`, `.error()` methods |
|
||||
|
||||
The `config` object contains your module.yaml variables **after** user input:
|
||||
|
||||
```javascript
|
||||
// If module.yaml defined:
|
||||
// project_name:
|
||||
// prompt: "What is your project name?"
|
||||
// result: "{value}"
|
||||
|
||||
config.project_name // = user's input
|
||||
config.planning_artifacts // = resolved path
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Installation Tasks
|
||||
|
||||
### 1. Create Directories
|
||||
|
||||
```javascript
|
||||
const fs = require('fs-extra');
|
||||
const path = require('node:path');
|
||||
|
||||
// Create directory from config
|
||||
if (config['planning_artifacts']) {
|
||||
const dirConfig = config['planning_artifacts'].replace('{project-root}/', '');
|
||||
const dirPath = path.join(projectRoot, dirConfig);
|
||||
|
||||
if (!(await fs.pathExists(dirPath))) {
|
||||
logger.log(chalk.yellow(`Creating directory: ${dirConfig}`));
|
||||
await fs.ensureDir(dirPath);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Copy Assets
|
||||
|
||||
```javascript
|
||||
const assetsSource = path.join(__dirname, 'assets');
|
||||
const assetsDest = path.join(projectRoot, 'docs');
|
||||
|
||||
if (await fs.pathExists(assetsSource)) {
|
||||
await fs.copy(assetsSource, assetsDest);
|
||||
logger.log(chalk.green('✓ Copied assets to docs/'));
|
||||
}
|
||||
```
|
||||
|
||||
### 3. IDE-Specific Configuration
|
||||
|
||||
```javascript
|
||||
// Handle IDE-specific configurations
|
||||
if (installedIDEs && installedIDEs.length > 0) {
|
||||
logger.log(chalk.cyan(`Configuring for IDEs: ${installedIDEs.join(', ')}`));
|
||||
|
||||
for (const ide of installedIDEs) {
|
||||
await configureForIDE(ide, projectRoot, config, logger);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Platform-Specific Handlers
|
||||
|
||||
### Pattern
|
||||
|
||||
Create files in `platform-specifics/{ide-code}.js`:
|
||||
|
||||
```javascript
|
||||
// platform-specifics/claude-code.js
|
||||
|
||||
/**
|
||||
* Configure module for Claude Code
|
||||
*/
|
||||
async function install(options) {
|
||||
const { projectRoot, config, logger, platformInfo } = options;
|
||||
|
||||
try {
|
||||
// Claude Code specific configuration
|
||||
logger.log(chalk.dim(' Configuring Claude Code integration...'));
|
||||
|
||||
// Your logic here
|
||||
|
||||
return true;
|
||||
} catch (error) {
|
||||
logger.warn(chalk.yellow(` Warning: ${error.message}`));
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = { install };
|
||||
```
|
||||
|
||||
### Load from Main Installer
|
||||
|
||||
```javascript
|
||||
// installer.js
|
||||
const platformCodes = require(path.join(__dirname, '../../../../tools/cli/lib/platform-codes'));
|
||||
|
||||
async function configureForIDE(ide, projectRoot, config, logger) {
|
||||
// Validate platform code
|
||||
if (!platformCodes.isValidPlatform(ide)) {
|
||||
logger.warn(chalk.yellow(` Unknown platform: '${ide}'. Skipping.`));
|
||||
return;
|
||||
}
|
||||
|
||||
const platformName = platformCodes.getDisplayName(ide);
|
||||
const platformSpecificPath = path.join(__dirname, 'platform-specifics', `${ide}.js`);
|
||||
|
||||
try {
|
||||
if (await fs.pathExists(platformSpecificPath)) {
|
||||
const platformHandler = require(platformSpecificPath);
|
||||
|
||||
if (typeof platformHandler.install === 'function') {
|
||||
await platformHandler.install({ projectRoot, config, logger });
|
||||
logger.log(chalk.green(` ✓ Configured for ${platformName}`));
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
logger.warn(chalk.yellow(` Warning: Could not configure ${platformName}: ${error.message}`));
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Complete Example: BMM Installer
|
||||
|
||||
```javascript
|
||||
const fs = require('fs-extra');
|
||||
const path = require('node:path');
|
||||
const chalk = require('chalk');
|
||||
const platformCodes = require(path.join(__dirname, '../../../../tools/cli/lib/platform-codes'));
|
||||
|
||||
/**
|
||||
* BMM Module Installer
|
||||
*/
|
||||
async function install(options) {
|
||||
const { projectRoot, config, installedIDEs, logger } = options;
|
||||
|
||||
try {
|
||||
logger.log(chalk.blue('🚀 Installing BMM Module...'));
|
||||
|
||||
// Create output directory
|
||||
if (config['output_folder']) {
|
||||
const outputConfig = config['output_folder'].replace('{project-root}/', '');
|
||||
const outputPath = path.join(projectRoot, outputConfig);
|
||||
if (!(await fs.pathExists(outputPath))) {
|
||||
logger.log(chalk.yellow(`Creating output directory: ${outputConfig}`));
|
||||
await fs.ensureDir(outputPath);
|
||||
}
|
||||
}
|
||||
|
||||
// Create implementation artifacts directory
|
||||
if (config['implementation_artifacts']) {
|
||||
const storyConfig = config['implementation_artifacts'].replace('{project-root}/', '');
|
||||
const storyPath = path.join(projectRoot, storyConfig);
|
||||
if (!(await fs.pathExists(storyPath))) {
|
||||
logger.log(chalk.yellow(`Creating story directory: ${storyConfig}`));
|
||||
await fs.ensureDir(storyPath);
|
||||
}
|
||||
}
|
||||
|
||||
// IDE-specific configuration
|
||||
if (installedIDEs && installedIDEs.length > 0) {
|
||||
logger.log(chalk.cyan(`Configuring BMM for IDEs: ${installedIDEs.join(', ')}`));
|
||||
|
||||
for (const ide of installedIDEs) {
|
||||
await configureForIDE(ide, projectRoot, config, logger);
|
||||
}
|
||||
}
|
||||
|
||||
logger.log(chalk.green('✓ BMM Module installation complete'));
|
||||
return true;
|
||||
} catch (error) {
|
||||
logger.error(chalk.red(`Error installing BMM: ${error.message}`));
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
async function configureForIDE(ide, projectRoot, config, logger) {
|
||||
if (!platformCodes.isValidPlatform(ide)) {
|
||||
logger.warn(chalk.yellow(` Warning: Unknown platform '${ide}'. Skipping.`));
|
||||
return;
|
||||
}
|
||||
|
||||
const platformSpecificPath = path.join(__dirname, 'platform-specifics', `${ide}.js`);
|
||||
|
||||
try {
|
||||
if (await fs.pathExists(platformSpecificPath)) {
|
||||
const platformHandler = require(platformSpecificPath);
|
||||
|
||||
if (typeof platformHandler.install === 'function') {
|
||||
await platformHandler.install({ projectRoot, config, logger });
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
logger.warn(chalk.yellow(` Warning: Could not load handler for ${ide}: ${error.message}`));
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = { install };
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO:
|
||||
- Return `true` for success, `false` for failure
|
||||
- Use chalk for colored output
|
||||
- Log what you're doing (create, copy, configure)
|
||||
- Handle errors gracefully with try/catch
|
||||
- Validate paths before creating directories
|
||||
|
||||
### DON'T:
|
||||
- Assume paths exist — check with `fs.pathExists()`
|
||||
- Overwrite user files without asking
|
||||
- Fail silently — log errors
|
||||
- Use absolute paths — build from `projectRoot`
|
||||
|
||||
---
|
||||
|
||||
## Available Platform Codes
|
||||
|
||||
Common IDE codes:
|
||||
- `claude-code` — Anthropic's Claude Code
|
||||
- `windsurf` — Windsurf IDE
|
||||
- `cursor` — Cursor AI IDE
|
||||
- `vscode` — Visual Studio Code
|
||||
|
||||
Use `platformCodes.isValidPlatform(ide)` to validate.
|
||||
|
||||
---
|
||||
|
||||
## Testing Your Installer
|
||||
|
||||
1. Create a test project
|
||||
2. Run `bmad install {your-module}`
|
||||
3. Verify directories are created
|
||||
4. Check that config variables are resolved correctly
|
||||
5. Test platform-specific handlers
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Task | Code Pattern |
|
||||
|------|--------------|
|
||||
| Create directory | `await fs.ensureDir(path)` |
|
||||
| Check if exists | `await fs.pathExists(path)` |
|
||||
| Copy files | `await fs.copy(src, dest)` |
|
||||
| Log info | `logger.log(chalk.blue('message'))` |
|
||||
| Log success | `logger.log(chalk.green('✓ message'))` |
|
||||
| Log warning | `logger.warn(chalk.yellow('warning'))` |
|
||||
| Log error | `logger.error(chalk.red('error'))` |
|
||||
@@ -1,280 +0,0 @@
|
||||
# Module Standards
|
||||
|
||||
**Purpose:** Defines what a BMAD module is, its structure, and the three types of modules.
|
||||
|
||||
---
|
||||
|
||||
## What is a BMAD Module?
|
||||
|
||||
A **BMAD module** is a self-contained package of functionality that extends the BMAD framework. Modules provide:
|
||||
- **Agents** — AI personas with specialized expertise and menu-driven commands
|
||||
- **Workflows** — Structured processes for accomplishing complex tasks
|
||||
- **Configuration** — module.yaml for user customization
|
||||
- **Installation** — Optional installer.js for setup logic
|
||||
|
||||
---
|
||||
|
||||
## Module Types
|
||||
|
||||
### 1. Standalone Module
|
||||
|
||||
A new, independent module focused on a specific domain.
|
||||
|
||||
**Characteristics:**
|
||||
- Own module code (e.g., `healthcare-ai`, `legal-assist`)
|
||||
- Independent of other modules
|
||||
- Can be installed alongside any other modules
|
||||
- Has its own agents, workflows, configuration
|
||||
|
||||
**Location:** `src/modules/{module-code}/`
|
||||
|
||||
**Example:** CIS (Creative Innovation Suite) — a standalone module for innovation workflows
|
||||
|
||||
---
|
||||
|
||||
### 2. Extension Module
|
||||
|
||||
Extends an existing BMAD module with additional functionality.
|
||||
|
||||
**Characteristics:**
|
||||
- Builds upon an existing module's agents and workflows
|
||||
- May add new agents or workflows that complement the base module
|
||||
- Shares configuration context with the extended module
|
||||
- Typically installed alongside the module it extends
|
||||
|
||||
**Location:** `src/modules/{base-module}/extensions/{extension-code}/`
|
||||
|
||||
**Example:** An extension to BMM that adds specialized security review workflows
|
||||
|
||||
---
|
||||
|
||||
### Extension Module: Override & Merge Pattern
|
||||
|
||||
When an extension module is installed, its files merge with the base module following these rules:
|
||||
|
||||
#### Code Matching
|
||||
|
||||
The extension's `module.yaml` `code:` field matches the base module's code:
|
||||
|
||||
```yaml
|
||||
# Base module: src/modules/bmm/module.yaml
|
||||
code: bmm
|
||||
|
||||
# Extension: src/modules/bmm/extensions/security/module.yaml
|
||||
code: bmm # SAME CODE — extends BMM
|
||||
```
|
||||
|
||||
The **folder name** is unique (e.g., `bmm-security`) but the `code:` matches the base module.
|
||||
|
||||
#### File Merge Rules
|
||||
|
||||
| File Type | Same Name | Different Name |
|
||||
|-----------|-----------|----------------|
|
||||
| Agent file | **OVERRIDE** — replaces the base agent | **ADD** — new agent added |
|
||||
| Workflow folder | **OVERRIDE** — replaces the base workflow | **ADD** — new workflow added |
|
||||
| Other files | **OVERRIDE** — replaces base file | **ADD** — new file added |
|
||||
|
||||
#### Examples
|
||||
|
||||
**Override scenario:**
|
||||
```
|
||||
Base module (BMM):
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Original PM agent
|
||||
|
||||
Extension (bmm-security):
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Security-focused PM — REPLACES original
|
||||
|
||||
Result after installation:
|
||||
├── agents/
|
||||
│ └── pm.agent.yaml # Now the security version
|
||||
```
|
||||
|
||||
**Add scenario:**
|
||||
```
|
||||
Base module (BMM):
|
||||
├── agents/
|
||||
│ ├── pm.agent.yaml
|
||||
│ └── architect.agent.yaml
|
||||
|
||||
Extension (bmm-security):
|
||||
├── agents/
|
||||
│ └── security-auditor.agent.yaml # NEW agent
|
||||
|
||||
Result after installation:
|
||||
├── agents/
|
||||
│ ├── pm.agent.yaml
|
||||
│ ├── architect.agent.yaml
|
||||
│ └── security-auditor.agent.yaml # ADDED
|
||||
```
|
||||
|
||||
**Mixed scenario:**
|
||||
```
|
||||
Extension contains both overrides and new files — applies rules per file
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Global Module
|
||||
|
||||
Affects the entire BMAD framework and all modules.
|
||||
|
||||
**Characteristics:**
|
||||
- Core functionality that impacts all modules
|
||||
- Often provides foundational services or utilities
|
||||
- Installed at the framework level
|
||||
- Use sparingly — only for truly global concerns
|
||||
|
||||
**Location:** `src/modules/{module-code}/` with `global: true` in module.yaml
|
||||
|
||||
**Example:** A module that provides universal logging or telemetry across BMAD
|
||||
|
||||
---
|
||||
|
||||
## Required Module Structure
|
||||
|
||||
```
|
||||
{module-code}/
|
||||
├── module.yaml # Module configuration (REQUIRED)
|
||||
├── README.md # Module documentation (REQUIRED)
|
||||
├── agents/ # Agent definitions (if any)
|
||||
│ └── {agent-name}.agent.yaml
|
||||
├── workflows/ # Workflow definitions (if any)
|
||||
│ └── {workflow-name}/
|
||||
│ └── workflow.md
|
||||
├── _module-installer/ # Installation logic (optional)
|
||||
│ ├── installer.js
|
||||
│ └── platform-specifics/
|
||||
│ ├── claude-code.js
|
||||
│ ├── windsurf.js
|
||||
│ └── ...
|
||||
└── {other folders} # Tasks, templates, data as needed
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Required Files
|
||||
|
||||
### module.yaml (REQUIRED)
|
||||
|
||||
Every module MUST have a `module.yaml` file with at minimum:
|
||||
|
||||
```yaml
|
||||
code: {module-code}
|
||||
name: "Module Display Name"
|
||||
header: "Brief module description"
|
||||
subheader: "Additional context"
|
||||
default_selected: false
|
||||
```
|
||||
|
||||
See: `module-yaml-conventions.md` for full specification.
|
||||
|
||||
---
|
||||
|
||||
### README.md (REQUIRED)
|
||||
|
||||
Every module MUST have a README.md with:
|
||||
- Module name and purpose
|
||||
- Installation instructions
|
||||
- Components section (agents, workflows)
|
||||
- Quick start guide
|
||||
- Module structure diagram
|
||||
- Configuration section
|
||||
- Usage examples
|
||||
- Author information
|
||||
|
||||
---
|
||||
|
||||
## Optional Components
|
||||
|
||||
### Agents
|
||||
|
||||
Agents are AI personas with:
|
||||
- Metadata (id, name, title, icon, module)
|
||||
- Persona (role, identity, communication_style, principles)
|
||||
- Menu (trigger → workflow/exec mappings)
|
||||
|
||||
See: `agent-architecture.md` for design guidance.
|
||||
|
||||
---
|
||||
|
||||
### Workflows
|
||||
|
||||
Workflows are structured processes with:
|
||||
- workflow.md (entry point)
|
||||
- steps/ folder with step files
|
||||
- data/ folder with shared reference
|
||||
- templates/ folder if needed
|
||||
|
||||
---
|
||||
|
||||
### _module-installer/
|
||||
|
||||
Optional installation logic for:
|
||||
- Creating directories
|
||||
- Copying assets
|
||||
- IDE-specific configuration
|
||||
- Platform-specific setup
|
||||
|
||||
See: `module-installer-standards.md` for patterns.
|
||||
|
||||
---
|
||||
|
||||
## Module Type Decision Tree
|
||||
|
||||
```
|
||||
START: Creating a module
|
||||
│
|
||||
├─ Is this a brand new independent domain?
|
||||
│ └─ YES → Standalone Module
|
||||
│
|
||||
├─ Does this extend an existing module?
|
||||
│ └─ YES → Extension Module
|
||||
│
|
||||
└─ Does this affect all modules globally?
|
||||
└─ YES → Global Module (use sparingly)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
### Module Code
|
||||
|
||||
- **kebab-case** (e.g., `bmm`, `cis`, `bmgd`, `healthcare-ai`)
|
||||
- Short, memorable, descriptive
|
||||
- 2-20 characters
|
||||
- Lowercase letters, numbers, hyphens only
|
||||
|
||||
### Agent Files
|
||||
|
||||
- Format: `{role-name}.agent.yaml`
|
||||
- Example: `pm.agent.yaml`, `architect.agent.yaml`
|
||||
|
||||
### Workflow Folders
|
||||
|
||||
- Format: `{workflow-name}/`
|
||||
- Example: `prd/`, `create-architecture/`
|
||||
|
||||
---
|
||||
|
||||
## Module Dependencies
|
||||
|
||||
Modules can depend on:
|
||||
- **Core BMAD** — Always available
|
||||
- **Other modules** — Specify in module.yaml as `dependencies:`
|
||||
- **External tools** — Document in README, handle in installer
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Question | Answer |
|
||||
|----------|--------|
|
||||
| What's a module? | Self-contained package of agents, workflows, config |
|
||||
| What are the types? | Standalone, Extension, Global |
|
||||
| What's required? | module.yaml, README.md |
|
||||
| Where do modules live? | `src/modules/{code}/` |
|
||||
| How do agents work? | Menu triggers → workflow/exec |
|
||||
| How does installation work? | module.yaml prompts + optional installer.js |
|
||||
@@ -1,392 +0,0 @@
|
||||
# module.yaml Conventions
|
||||
|
||||
**Purpose:** Defines how module.yaml works, including variables, templates, and how they provide context to agents and workflows.
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
`module.yaml` is the configuration file for a BMAD module. It:
|
||||
- Defines module metadata (code, name, description)
|
||||
- Collects user input via prompts during installation
|
||||
- Makes those inputs available to agents and workflows as variables
|
||||
- Specifies which module should be selected by default
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Fields
|
||||
|
||||
### Required Fields
|
||||
|
||||
```yaml
|
||||
code: {module-code} # kebab-case identifier
|
||||
name: "Display Name" # Human-readable name
|
||||
header: "Brief description" # One-line summary
|
||||
subheader: "Additional context" # More detail
|
||||
default_selected: false # Auto-select on install?
|
||||
```
|
||||
|
||||
### `default_selected` Guidelines
|
||||
|
||||
| Module Type | default_selected | Example |
|
||||
|-------------|------------------|---------|
|
||||
| Core/Primary | `true` | BMM (agile software delivery) |
|
||||
| Specialized | `false` | CIS (creative innovation), BMGD (game dev) |
|
||||
| Experimental | `false` | New modules in development |
|
||||
|
||||
---
|
||||
|
||||
## Variables System
|
||||
|
||||
### Core Config Variables (Always Available)
|
||||
|
||||
These variables are automatically available to ALL modules:
|
||||
|
||||
```yaml
|
||||
# Variables from Core Config inserted:
|
||||
## user_name # User's name
|
||||
## communication_language # Preferred language
|
||||
## document_output_language # Output document language
|
||||
## output_folder # Default output location
|
||||
```
|
||||
|
||||
No need to define these — they're injected automatically.
|
||||
|
||||
---
|
||||
|
||||
### Custom Variables
|
||||
|
||||
Define custom variables for user input:
|
||||
|
||||
```yaml
|
||||
variable_name:
|
||||
prompt: "Question to ask the user?"
|
||||
default: "{default_value}"
|
||||
result: "{template_for_final_value}"
|
||||
```
|
||||
|
||||
**Example:**
|
||||
|
||||
```yaml
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
### Variable Templates
|
||||
|
||||
In `prompt` and `result`, you can use templates:
|
||||
|
||||
| Template | Expands To |
|
||||
|----------|------------|
|
||||
| `{value}` | The user's input |
|
||||
| `{directory_name}` | Current directory name |
|
||||
| `{output_folder}` | Output folder from core config |
|
||||
| `{project-root}` | Project root path |
|
||||
| `{variable_name}` | Another variable's value |
|
||||
|
||||
---
|
||||
|
||||
## Variable Types
|
||||
|
||||
### 1. Simple Text Input
|
||||
|
||||
```yaml
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Boolean/Flag
|
||||
|
||||
```yaml
|
||||
enable_feature:
|
||||
prompt: "Enable this feature?"
|
||||
default: false
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Single Select
|
||||
|
||||
```yaml
|
||||
skill_level:
|
||||
prompt: "What is your experience level?"
|
||||
default: "intermediate"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "beginner"
|
||||
label: "Beginner - Explains concepts clearly"
|
||||
- value: "intermediate"
|
||||
label: "Intermediate - Balanced approach"
|
||||
- value: "expert"
|
||||
label: "Expert - Direct and technical"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. Multi Select
|
||||
|
||||
```yaml
|
||||
platforms:
|
||||
prompt: "Which platforms do you need?"
|
||||
default: ["unity", "unreal"]
|
||||
result: "{value}"
|
||||
multi-select:
|
||||
- value: "unity"
|
||||
label: "Unity"
|
||||
- value: "unreal"
|
||||
label: "Unreal Engine"
|
||||
- value: "godot"
|
||||
label: "Godot"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. Multi-Line Prompt
|
||||
|
||||
```yaml
|
||||
complex_variable:
|
||||
prompt:
|
||||
- "First question?"
|
||||
- "Second context?"
|
||||
- "Third detail?"
|
||||
default: "default_value"
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. Required Variable
|
||||
|
||||
```yaml
|
||||
critical_variable:
|
||||
prompt: "Required information:"
|
||||
required: true
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. Path Variable
|
||||
|
||||
```yaml
|
||||
artifacts_folder:
|
||||
prompt: "Where should artifacts be stored?"
|
||||
default: "{output_folder}/artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Variable Inheritance / Aliasing
|
||||
|
||||
Create an alias for another variable:
|
||||
|
||||
```yaml
|
||||
primary_artifacts:
|
||||
prompt: "Where should primary artifacts be stored?"
|
||||
default: "{output_folder}/artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
# Alias for workflow compatibility
|
||||
sprint_artifacts:
|
||||
inherit: "primary_artifacts"
|
||||
```
|
||||
|
||||
Now `sprint_artifacts` and `primary_artifacts` reference the same value.
|
||||
|
||||
---
|
||||
|
||||
## How Variables Become Available
|
||||
|
||||
### To Agents
|
||||
|
||||
After installation, variables are available in agent frontmatter/context:
|
||||
|
||||
```yaml
|
||||
# In agent.agent.yaml or workflow execution
|
||||
{variable_name} # Expands to the user's configured value
|
||||
```
|
||||
|
||||
**Example:** If the user configured `project_name: "MyApp"`, agents can reference `{project_name}` and it will expand to `"MyApp"`.
|
||||
|
||||
### To Workflows
|
||||
|
||||
Workflows can reference module variables in their step files:
|
||||
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{implementation_artifacts}/my-output.md'
|
||||
---
|
||||
```
|
||||
|
||||
This expands the `implementation_artifacts` variable from module.yaml.
|
||||
|
||||
---
|
||||
|
||||
## Real-World Examples
|
||||
|
||||
### BMM (BMad Method) — Complex Configuration
|
||||
|
||||
```yaml
|
||||
code: bmm
|
||||
name: "BMM: BMad Method Agile-AI Driven-Development"
|
||||
header: "BMad Method™: Breakthrough Method of Agile-Ai Driven-Dev"
|
||||
subheader: "Agent and Workflow Configuration for this module"
|
||||
default_selected: true
|
||||
|
||||
# Variables from Core Config inserted:
|
||||
## user_name
|
||||
## communication_language
|
||||
## document_output_language
|
||||
## output_folder
|
||||
|
||||
project_name:
|
||||
prompt: "What is the title of your project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
|
||||
user_skill_level:
|
||||
prompt:
|
||||
- "What is your development experience level?"
|
||||
- "This affects how agents explain concepts."
|
||||
default: "intermediate"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "beginner"
|
||||
label: "Beginner - Explain concepts clearly"
|
||||
- value: "intermediate"
|
||||
label: "Intermediate - Balanced approach"
|
||||
- value: "expert"
|
||||
label: "Expert - Direct and technical"
|
||||
|
||||
planning_artifacts:
|
||||
prompt: "Where should planning artifacts be stored?"
|
||||
default: "{output_folder}/planning-artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
implementation_artifacts:
|
||||
prompt: "Where should implementation artifacts be stored?"
|
||||
default: "{output_folder}/implementation-artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
project_knowledge:
|
||||
prompt: "Where should project knowledge be stored?"
|
||||
default: "docs"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
tea_use_mcp_enhancements:
|
||||
prompt: "Enable MCP enhancements in Test Architect?"
|
||||
default: false
|
||||
result: "{value}"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### CIS (Creative Innovation Suite) — Minimal Configuration
|
||||
|
||||
```yaml
|
||||
code: cis
|
||||
name: "CIS: Creative Innovation Suite"
|
||||
header: "Creative Innovation Suite (CIS) Module"
|
||||
subheader: "No custom configuration - uses Core settings only"
|
||||
default_selected: false
|
||||
|
||||
# Variables from Core Config inserted:
|
||||
## user_name
|
||||
## communication_language
|
||||
## document_output_language
|
||||
## output_folder
|
||||
```
|
||||
|
||||
Some modules don't need custom variables — core config is enough!
|
||||
|
||||
---
|
||||
|
||||
### BMGD (Game Development) — Multi-Select Example
|
||||
|
||||
```yaml
|
||||
code: bmgd
|
||||
name: "BMGD: BMad Game Development"
|
||||
header: "BMad Game Development Module"
|
||||
subheader: "Configure game development settings"
|
||||
default_selected: false
|
||||
|
||||
project_name:
|
||||
prompt: "What is the name of your game project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
|
||||
primary_platform:
|
||||
prompt: "Which game engine do you use?"
|
||||
default: ["unity", "unreal"]
|
||||
required: true
|
||||
result: "{value}"
|
||||
multi-select:
|
||||
- value: "unity"
|
||||
label: "Unity"
|
||||
- value: "unreal"
|
||||
label: "Unreal Engine"
|
||||
- value: "godot"
|
||||
label: "Godot"
|
||||
- value: "other"
|
||||
label: "Custom / Other"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO:
|
||||
- Keep prompts clear and concise
|
||||
- Provide sensible defaults
|
||||
- Use `result: "{project-root}/{value}"` for paths
|
||||
- Use single/multi-select for structured choices
|
||||
- Group related variables logically
|
||||
|
||||
### DON'T:
|
||||
- Overwhelm users with too many questions
|
||||
- Ask for information that could be inferred
|
||||
- Use technical jargon in prompts
|
||||
- Create variables that are never used
|
||||
|
||||
---
|
||||
|
||||
## Variable Naming
|
||||
|
||||
- **kebab-case** (e.g., `planning_artifacts`, `user_skill_level`)
|
||||
- Descriptive but concise
|
||||
- Avoid conflicts with core variables
|
||||
|
||||
---
|
||||
|
||||
## Testing Your module.yaml
|
||||
|
||||
After creating module.yaml, test it:
|
||||
|
||||
1. Run `bmad install` in a test project
|
||||
2. Verify prompts appear correctly
|
||||
3. Check that variables expand in agents/workflows
|
||||
4. Test default values
|
||||
5. Validate path templates resolve correctly
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Pattern | Use Case |
|
||||
|---------|----------|
|
||||
| Simple text input | Names, titles, descriptions |
|
||||
| Boolean/Flag | Enable/disable features |
|
||||
| Single select | Experience levels, categories |
|
||||
| Multi select | Platforms, frameworks, options |
|
||||
| Multi-line prompt | Complex questions needing context |
|
||||
| Required | Must-have information |
|
||||
| Path variable | Directory locations |
|
||||
| Inherit/Alias | Compatibility, references |
|
||||
@@ -1,147 +0,0 @@
|
||||
---
|
||||
name: 'step-01-welcome'
|
||||
description: 'Welcome user, select mode (Interactive/Express/YOLO), gather initial idea'
|
||||
|
||||
nextStepFile: './step-02-spark.md'
|
||||
briefTemplateFile: '../templates/brief-template.md'
|
||||
moduleStandardsFile: '../data/module-standards.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 1: Welcome & Mode Selection
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Welcome the user to the Module Brief workflow, select the collaboration mode (Interactive/Express/YOLO), and gather their initial module idea.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Architect** — creative, inspiring, helping users discover amazing module ideas
|
||||
- ✅ This is explorative and collaborative — not a template-filling exercise
|
||||
- ✅ Help users clarify and expand their vision
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Set the creative tone — this is about discovering possibilities
|
||||
- 🚫 FORBIDDEN to jump straight to technical details
|
||||
- 💬 Ask questions that spark imagination
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 No output file yet — gathering initial context
|
||||
- 📖 Load next step when user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available: module standards, brief template
|
||||
- Focus: Initial idea gathering and mode selection
|
||||
- No existing brief — this is a fresh start
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
||||
|
||||
### 1. Welcome with Enthusiasm
|
||||
|
||||
"**Welcome to the Module Brief workflow!** 🚀
|
||||
|
||||
I'm here to help you create an amazing BMAD module. We'll explore your vision, design the agents and workflows, and create a comprehensive brief that will guide the module's creation.
|
||||
|
||||
Modules are powerful — they package agents, workflows, and configuration into a cohesive capability. Let's make something great!"
|
||||
|
||||
### 2. Select Collaboration Mode
|
||||
|
||||
"**How would you like to work?**"
|
||||
|
||||
- **[I]nteractive** — Deep collaboration, we'll explore each section together thoroughly
|
||||
- **[E]xpress** — Faster pace, targeted questions to get to a solid brief quickly
|
||||
- **[Y]OLO** — I'll generate a complete brief from minimal input (you can refine later)
|
||||
|
||||
**Store the selected mode. This affects how we proceed through subsequent steps.**
|
||||
|
||||
### 3. Gather the Initial Idea
|
||||
|
||||
"**Tell me about your module idea.**"
|
||||
|
||||
Encourage them to share:
|
||||
- What problem does it solve?
|
||||
- Who would use it?
|
||||
- What excites you about it?
|
||||
|
||||
**If they're stuck**, offer creative prompts:
|
||||
- "What domain do you work in? What tasks feel repetitive or could be AI-powered?"
|
||||
- "Imagine you had a team of AI experts at your disposal — what would you ask them to build?"
|
||||
- "Is there a module you wish existed?"
|
||||
|
||||
**Capture their initial idea.** We'll explore and expand it in the next steps.
|
||||
|
||||
### 4. Preview the Journey Ahead
|
||||
|
||||
"**Here's where we're going together:**"
|
||||
|
||||
1. Spark — Explore and clarify your idea
|
||||
2. Module Type — Standalone, Extension, or Global?
|
||||
3. Vision — What would make this extraordinary?
|
||||
4. Identity — Name, code, personality
|
||||
5. Users — Who is this for?
|
||||
6. Value — What makes it special?
|
||||
7. Agents — Who's on your team?
|
||||
8. Workflows — What can we do?
|
||||
9. Tools — MCP tools, integrations?
|
||||
10. Scenarios — How will people use it?
|
||||
11. Creative — Easter eggs, lore, magic ✨
|
||||
12. Review — Read through together
|
||||
13. Finalize — Your complete brief
|
||||
|
||||
"**This is about discovery and creativity. We're not filling out forms — we're designing something amazing together.**"
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions — always respond and redisplay menu
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}` for deeper idea exploration, then redisplay menu
|
||||
- IF P: Execute `{partyModeWorkflow}` for creative brainstorming, then redisplay menu
|
||||
- IF C: Store the mode and initial idea, then load `{nextStepFile}`
|
||||
- IF Any other: Help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- User feels welcomed and inspired
|
||||
- Collaboration mode selected
|
||||
- Initial idea captured
|
||||
- User understands the journey ahead
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping to technical details prematurely
|
||||
- Not capturing the initial idea
|
||||
- Not setting the creative tone
|
||||
- Rushing through mode selection
|
||||
|
||||
**Master Rule:** This step sets the tone for the entire brief — make it inspiring and collaborative.
|
||||
@@ -1,140 +0,0 @@
|
||||
---
|
||||
name: 'step-02-spark'
|
||||
description: 'Ignite the idea, explore problem space, what excites them'
|
||||
|
||||
nextStepFile: './step-03-module-type.md'
|
||||
moduleStandardsFile: '../data/module-standards.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 2: Spark
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Ignite and explore the user's idea — dig into the problem space, understand what excites them, and help clarify the vision.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Architect** — curious, explorative, helping ideas grow
|
||||
- ✅ Ask open-ended questions that reveal depth
|
||||
- ✅ Listen more than you speak
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 This is about understanding the problem space, not solving it yet
|
||||
- 🚫 FORBIDDEN to jump to implementation
|
||||
- 💬 Ask "why" and "what if" questions
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 📖 Reference module standards to understand types
|
||||
- 📖 Load next step when user selects 'C'
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly.
|
||||
|
||||
### 1. Connect to Their Idea
|
||||
|
||||
"**Let's explore your idea together.**"
|
||||
|
||||
Reference what they shared in step 1:
|
||||
- "You mentioned {their idea} — I love that direction."
|
||||
- "Tell me more about the problem you're solving."
|
||||
|
||||
### 2. Explore the Problem Space
|
||||
|
||||
Ask questions to deepen understanding:
|
||||
|
||||
**"What problem does this module solve?"**
|
||||
|
||||
- Who feels this problem right now?
|
||||
- What do they currently do without this module?
|
||||
- What would change if this existed?
|
||||
|
||||
**"What excites you about this idea?"**
|
||||
|
||||
- Why THIS module? Why now?
|
||||
- What's the vision — the dream outcome?
|
||||
- If this module succeeds wildly, what does that look like?
|
||||
|
||||
### 3. Identify the Users
|
||||
|
||||
**"Who is this module for?"**
|
||||
|
||||
Help them think about:
|
||||
- Primary users — who will use this most?
|
||||
- Secondary users — who else benefits?
|
||||
- What do these users care about?
|
||||
|
||||
### 4. Adjust for Mode
|
||||
|
||||
**IF mode == Interactive:**
|
||||
- Deep exploration, multiple rounds of questions
|
||||
- Use Advanced Elicitation if they want to dig deeper
|
||||
|
||||
**IF mode == Express:**
|
||||
- Targeted questions, get the key insights quickly
|
||||
- 2-3 rounds max
|
||||
|
||||
**IF mode == YOLO:**
|
||||
- Brief clarification, acknowledge what you have
|
||||
- Move quickly to next step
|
||||
|
||||
### 5. Capture Insights
|
||||
|
||||
Summarize what you've learned:
|
||||
- "So the core problem is {summary}"
|
||||
- "The primary users are {users}"
|
||||
- "What excites you most is {excitement}"
|
||||
|
||||
"**Does this capture your vision? Anything to add or refine?**"
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}` for deeper exploration
|
||||
- IF P: Execute `{partyModeWorkflow}` for creative ideation
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Problem space clearly understood
|
||||
- User excitement identified
|
||||
- Target users clarified
|
||||
- Vision feels solid
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping to solutions too quickly
|
||||
- Not understanding the problem
|
||||
- Not capturing what excites them
|
||||
|
||||
**Master Rule:** Understand before you build. This step is about clarity, not solutions.
|
||||
@@ -1,148 +0,0 @@
|
||||
---
|
||||
name: 'step-03-module-type'
|
||||
description: 'EARLY decision: Standalone, Extension, or Global module?'
|
||||
|
||||
nextStepFile: './step-04-vision.md'
|
||||
moduleStandardsFile: '../data/module-standards.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 3: Module Type
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Make the EARLY key decision: Is this a Standalone, Extension, or Global module? This decision affects everything that follows.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Architect** — you understand module types and their implications
|
||||
- ✅ Help the user make an informed decision
|
||||
- ✅ This is a commitment — get it right
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 This decision MUST happen early
|
||||
- 🚫 FORBIDDEN to proceed without clarity on module type
|
||||
- 💬 Explain the trade-offs clearly
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load `{moduleStandardsFile}` to reference module types
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 📖 Load next step when user selects 'C'
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly.
|
||||
|
||||
### 1. Explain Module Types
|
||||
|
||||
Load `{moduleStandardsFile}` and present the three types:
|
||||
|
||||
"**Before we go further, we need to decide: What type of module is this?** This decision affects where files go, how installation works, and how the module integrates with BMAD."
|
||||
|
||||
**Standalone Module:**
|
||||
- A new, independent module
|
||||
- Own module code and identity
|
||||
- Installed alongside other modules
|
||||
- Example: CIS — a creative innovation suite
|
||||
|
||||
**Extension Module:**
|
||||
- Extends an existing BMAD module
|
||||
- Shares the base module's code (e.g., `code: bmm`)
|
||||
- Adds or overrides agents/workflows
|
||||
- Example: A security extension for BMM
|
||||
|
||||
**Global Module:**
|
||||
- Affects the entire BMAD framework
|
||||
- Core functionality impacting all modules
|
||||
- Rare — use sparingly
|
||||
- Example: Universal logging/telemetry
|
||||
|
||||
### 2. Determine Type Together
|
||||
|
||||
**"Based on your idea, what type makes sense?"**
|
||||
|
||||
Help them think through:
|
||||
- **"Is this a brand new domain?"** → Likely Standalone
|
||||
- **"Does this build on an existing module?"** → Likely Extension
|
||||
- **"Does this affect all modules?"** → Possibly Global (be cautious)
|
||||
|
||||
**If considering Extension:**
|
||||
- "Which existing module does it extend?"
|
||||
- "Are you adding new agents/workflows, or modifying existing ones?"
|
||||
- "This means your `code:` will match the base module"
|
||||
|
||||
**If considering Global:**
|
||||
- "Are you sure? Global modules are rare."
|
||||
- "Could this be a standalone module instead?"
|
||||
|
||||
### 3. Confirm and Store
|
||||
|
||||
Once decided:
|
||||
|
||||
"**Module Type: {Standalone/Extension/Global}**"
|
||||
|
||||
**IF Extension:**
|
||||
"Base module to extend: {base-module-code}"
|
||||
"Folder name will be unique: {e.g., bmm-security}"
|
||||
|
||||
**Store this decision.** It affects:
|
||||
- Where files are created
|
||||
- What `code:` goes in module.yaml
|
||||
- Installation behavior
|
||||
|
||||
### 4. Preview Implications
|
||||
|
||||
Briefly explain what this means:
|
||||
- "As a {type}, your module will {implications}"
|
||||
- "When we build, files will go to {location}"
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- User can change their mind before proceeding
|
||||
- ONLY proceed to next step when user selects 'C' and confirms the type
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}` for deeper exploration of the decision
|
||||
- IF P: Execute `{partyModeWorkflow}` for brainstorming the approach
|
||||
- IF C: Confirm the decision, then load `{nextStepFile}`
|
||||
- IF Any other: Help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Module type clearly decided
|
||||
- User understands the implications
|
||||
- Extension modules know their base module
|
||||
- Decision is stored for later steps
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding without clear module type
|
||||
- User doesn't understand the implications
|
||||
- Extension module without clear base
|
||||
|
||||
**Master Rule:** This is a gateway decision. Get clarity before moving forward.
|
||||
@@ -1,82 +0,0 @@
|
||||
---
|
||||
name: 'step-04-vision'
|
||||
description: 'Deep dive into the vision — what would make this module extraordinary?'
|
||||
|
||||
nextStepFile: './step-05-identity.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 4: Vision
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Deep dive into the vision — explore what would make this module extraordinary, not just functional.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — visioning, dreaming big
|
||||
- ✅ Push beyond "good enough" to "extraordinary"
|
||||
- 💬 Ask "what would make this amazing?"
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 This is about the vision, not the details
|
||||
- 🚫 FORBIDDEN to jump to implementation
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Set the Visioning Tone
|
||||
|
||||
"**Let's dream big. What would make this module extraordinary?**"
|
||||
|
||||
"Good modules solve problems. Great modules inspire people. Let's make yours great."
|
||||
|
||||
### 2. Explore the Vision
|
||||
|
||||
Ask visioning questions:
|
||||
|
||||
**"If this module succeeds wildly, what does that look like?"**
|
||||
- How are people using it?
|
||||
- What are they able to do that they couldn't before?
|
||||
- What's the feeling when they use it?
|
||||
|
||||
**"What would make someone say 'I love this module'?"**
|
||||
- Delightful features?
|
||||
- Surprising capabilities?
|
||||
- The way it makes them feel?
|
||||
|
||||
**"What's the 'secret sauce' — the thing that makes this special?"**
|
||||
|
||||
### 3. Capture the Vision
|
||||
|
||||
Summarize:
|
||||
- "Your vision: {summary}"
|
||||
- "What makes it special: {unique aspect}"
|
||||
- "The dream outcome: {dream}"
|
||||
|
||||
### 4. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Vision feels inspiring and clear
|
||||
✅ "Extraordinary" elements identified
|
||||
✅ User excited about the possibility
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
name: 'step-05-identity'
|
||||
description: 'Module code, name, and personality/theme'
|
||||
|
||||
nextStepFile: './step-06-users.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Identity
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define the module's identity — code, name, and personality/theme.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — naming, branding, theming
|
||||
- ✅ This is where personality comes in
|
||||
- 💬 Have fun with this!
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Module code follows conventions (kebab-case, 2-20 chars)
|
||||
- 🚫 FORBIDDEN to use reserved codes or existing module codes (for standalone)
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Module Code
|
||||
|
||||
"**Let's give your module a code.**"
|
||||
|
||||
Explain:
|
||||
- kebab-case (e.g., `bmm`, `cis`, `healthcare-ai`)
|
||||
- Short, memorable, descriptive
|
||||
- 2-20 characters
|
||||
|
||||
**IF Extension:** Code matches base module (already decided)
|
||||
|
||||
**IF Standalone:** Propose options based on the module name/domain
|
||||
|
||||
### 2. Module Name
|
||||
|
||||
"**What's the display name?**"
|
||||
|
||||
This is the human-facing name in module.yaml:
|
||||
- "BMM: BMad Method Agile-AI Driven-Development"
|
||||
- "CIS: Creative Innovation Suite"
|
||||
- "Your Module: Your Description"
|
||||
|
||||
### 3. Personality Theme
|
||||
|
||||
"**Does your module have a personality or theme?**"
|
||||
|
||||
Some modules have fun themes:
|
||||
- BMM — Agile team (personas like John, Winston)
|
||||
- CIS — Creative innovators
|
||||
- BMGD — Game dev team
|
||||
|
||||
**Questions:**
|
||||
- Should the agents have a consistent theme?
|
||||
- Any personality vibes? (Corporate team, fantasy party, reality show cast?)
|
||||
- Or keep it professional/focused?
|
||||
|
||||
### 4. Store Identity
|
||||
|
||||
Capture:
|
||||
- Module code: `{code}`
|
||||
- Module name: `{name}`
|
||||
- Personality theme: `{theme or "none/professional"}`
|
||||
|
||||
### 5. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Module code decided and validated
|
||||
✅ Module name defined
|
||||
✅ Personality theme decided (even if "none")
|
||||
@@ -1,85 +0,0 @@
|
||||
---
|
||||
name: 'step-06-users'
|
||||
description: 'Who + How — personas AND user journey combined'
|
||||
|
||||
nextStepFile: './step-07-value.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 6: Users
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define who the module is for AND how they'll use it — personas and user journey combined.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — user-centric, empathetic
|
||||
- ✅ Help the user walk in their users' shoes
|
||||
- 💬 Tell the story of how this will be used
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Define the Users
|
||||
|
||||
"**Let's get specific about who this is for.**"
|
||||
|
||||
**Primary Users:**
|
||||
- Who will use this module most often?
|
||||
- What's their role? (developer, designer, analyst, etc.)
|
||||
- What's their skill level? (beginner, intermediate, expert)
|
||||
|
||||
**Secondary Users:**
|
||||
- Who else might use it?
|
||||
- How is their experience different?
|
||||
|
||||
### 2. Build User Personas
|
||||
|
||||
Create 1-2 brief personas:
|
||||
|
||||
**Persona 1:**
|
||||
- Name/role: {e.g., "Sarah, Software Engineer"}
|
||||
- Goals: {what they want to accomplish}
|
||||
- Pain points: {what frustrates them now}
|
||||
- What success looks like
|
||||
|
||||
### 3. Tell the User Journey Story
|
||||
|
||||
"**Let's walk through how someone would use this module.**"
|
||||
|
||||
Tell a story:
|
||||
1. User has a problem → {their situation}
|
||||
2. They load the module → {what they expect}
|
||||
3. They run an agent/workflow → {what happens}
|
||||
4. They get a result → {the outcome}
|
||||
5. This helps them → {the achievement}
|
||||
|
||||
"**Can you see this flow? Does it match what you envision?**"
|
||||
|
||||
### 4. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ User personas defined
|
||||
✅ User journey story told
|
||||
✅ User can visualize how their module will be used
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
name: 'step-07-value'
|
||||
description: 'Unique Value Proposition — what makes this module special?'
|
||||
|
||||
nextStepFile: './step-08-agents.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 7: Value
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Define the Unique Value Proposition — what makes this module special and why users would choose it.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — focused on differentiation
|
||||
- ✅ Help identify what makes this unique
|
||||
- 💬 Ask "why this and not something else?"
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Explore Differentiation
|
||||
|
||||
"**What makes your module special? Why would someone choose it?**"
|
||||
|
||||
Ask:
|
||||
- **What can users do with your module that they can't do otherwise?**
|
||||
- **What's the 'aha!' moment — when they realize this is exactly what they need?**
|
||||
- **What problem does this solve better than anything else?**
|
||||
|
||||
### 2. Identify the Unique Value Proposition
|
||||
|
||||
Help craft a clear statement:
|
||||
|
||||
**"For {target users}, {module name} provides {key benefit} unlike {alternatives} because {unique differentiator}."**
|
||||
|
||||
Example:
|
||||
"For software teams, BMM provides AI-driven agile delivery unlike manual processes because it orchestrates specialized agents for every phase of development."
|
||||
|
||||
### 3. Competitive Context
|
||||
|
||||
**"What else exists in this space? How is yours different?"**
|
||||
|
||||
- Similar modules?
|
||||
- Manual approaches?
|
||||
- Why is yours better?
|
||||
|
||||
### 4. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Unique value proposition articulated
|
||||
✅ Differentiation from alternatives clear
|
||||
✅ User can explain why someone would choose this module
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
name: 'step-08-agents'
|
||||
description: 'Agent architecture — party mode simulation of interactions'
|
||||
|
||||
nextStepFile: './step-09-workflows.md'
|
||||
agentArchitectureFile: '../data/agent-architecture.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 8: Agents
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Design the agent architecture — who's on your team? Simulate how agents might interact.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — team designer
|
||||
- ✅ Focus on high-level planning (role, workflows, name, style)
|
||||
- ✅ Don't worry about YAML format — agent-builder handles that
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Load `{agentArchitectureFile}` for guidance
|
||||
- 🎯 Party mode is great here — simulate agent interactions
|
||||
- 🚫 FORBIDDEN to design full agent specs (that's agent-builder's job)
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Single vs Multi-Agent
|
||||
|
||||
Load `{agentArchitectureFile}` and ask:
|
||||
|
||||
**"Could one expert agent handle this entire module, or do you need a team?"**
|
||||
|
||||
Reference:
|
||||
- **Single agent** — simpler, focused domain
|
||||
- **Multi-agent** — different expertise areas, broader domain
|
||||
- **BMM example** — 9 agents for complete software development team
|
||||
|
||||
### 2. Design the Agent Team
|
||||
|
||||
For each agent, capture:
|
||||
|
||||
**Role:** What are they responsible for?
|
||||
**Workflows:** Which workflows will they trigger?
|
||||
**Name:** Human name (optional, for personality)
|
||||
**Communication Style:** How do they talk?
|
||||
**Memory:** Do they need to remember things over time? (hasSidecar)
|
||||
|
||||
Keep it high-level — don't design full agent specs!
|
||||
|
||||
### 3. Party Mode Simulation
|
||||
|
||||
**"Want to simulate how your agents might interact?"**
|
||||
|
||||
- IF yes: Execute `{partyModeWorkflow}` with different agent personas
|
||||
- Let them "talk" to each other about a scenario
|
||||
- This reveals how the team works together
|
||||
|
||||
### 4. Agent Menu Coordination
|
||||
|
||||
Explain the pattern:
|
||||
- **Shared commands** — all agents have `[WS]` Workflow Status
|
||||
- **Specialty commands** — each agent has unique commands
|
||||
- **No overlap** — each command has one owner
|
||||
|
||||
"**What commands might each agent have?**"
|
||||
|
||||
### 5. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}` — great for agent interaction simulation
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Single vs multi-agent decided
|
||||
✅ Agent roles defined
|
||||
✅ Agent-workflow mappings clear
|
||||
✅ Agent interactions explored (via party mode if used)
|
||||
@@ -1,82 +0,0 @@
|
||||
---
|
||||
name: 'step-09-workflows'
|
||||
description: 'Workflow ecosystem — brainstorm what workflows could exist'
|
||||
|
||||
nextStepFile: './step-10-tools.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 9: Workflows
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Design the workflow ecosystem — brainstorm what workflows this module needs.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — workflow designer
|
||||
- ✅ Focus on what workflows exist, not their details
|
||||
- 💬 Brainstorm mode — generate lots of ideas
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Categorize workflows: Core, Feature, Utility
|
||||
- 🚫 FORBIDDEN to design full workflow specs (that's create-workflow's job)
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Brainstorm Workflows
|
||||
|
||||
"**What workflows should your module have?**"
|
||||
|
||||
Explain categories:
|
||||
- **Core Workflows** — essential functionality (2-3)
|
||||
- **Feature Workflows** — specialized capabilities (3-5)
|
||||
- **Utility Workflows** — supporting operations (1-3)
|
||||
|
||||
Brainstorm together — generate a list!
|
||||
|
||||
### 2. For Each Workflow
|
||||
|
||||
Capture briefly:
|
||||
|
||||
**Workflow name:** {e.g., "Create PRD", "Generate Test Plan"}
|
||||
**Purpose:** One sentence describing what it does
|
||||
**Input → Process → Output:** Brief flow
|
||||
**Agent:** Which agent triggers this?
|
||||
|
||||
### 3. Workflow Connections
|
||||
|
||||
"**How do workflows connect?**"
|
||||
|
||||
- Does workflow A feed into workflow B?
|
||||
- Are there dependencies?
|
||||
- What's the typical sequence?
|
||||
|
||||
### 4. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}` — great for workflow brainstorming
|
||||
- IF P: Execute `{partyModeWorkflow}` — different perspectives on workflows
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Workflow list generated (core, feature, utility)
|
||||
✅ Each workflow has a clear purpose
|
||||
✅ Agent-workflow mappings defined
|
||||
✅ Workflow connections understood
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
name: 'step-10-tools'
|
||||
description: 'MCP tools, integrations, external services the module might need'
|
||||
|
||||
nextStepFile: './step-11-scenarios.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 10: Tools
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Identify MCP tools, integrations, and external services the module might need.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — integrations thinker
|
||||
- ✅ Keep it practical — only what's needed
|
||||
- 💬 Ask "what external capabilities would help?"
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. MCP Tools
|
||||
|
||||
"**Does your module need any MCP (Model Context Protocol) tools?**"
|
||||
|
||||
Explain: MCP tools connect agents to external capabilities.
|
||||
|
||||
Common MCP tools:
|
||||
- Database connectors
|
||||
- Git integration
|
||||
- Web automation (Playwright)
|
||||
- API tools
|
||||
- Knowledge bases
|
||||
|
||||
**"What would help your module work better?"**
|
||||
|
||||
### 2. External Services
|
||||
|
||||
"**Any external services or APIs?**"
|
||||
|
||||
- Web APIs?
|
||||
- Cloud services?
|
||||
- Data sources?
|
||||
- Third-party tools?
|
||||
|
||||
### 3. Module Integrations
|
||||
|
||||
"**Does this integrate with other BMAD modules?****
|
||||
|
||||
- Uses workflows from other modules?
|
||||
- Shares agents or extends them?
|
||||
- Depends on another module's capabilities?
|
||||
|
||||
### 4. Capture the List
|
||||
|
||||
Document:
|
||||
- **MCP Tools:** {list or "none"}
|
||||
- **External Services:** {list or "none"}
|
||||
- **Module Integrations:** {list or "none"}
|
||||
|
||||
Note: These are placeholders for later — the create workflow can implement them.
|
||||
|
||||
### 5. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ MCP tools identified (or "none" decided)
|
||||
✅ External services documented (or "none")
|
||||
✅ Module integrations noted (or "none")
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
name: 'step-11-scenarios'
|
||||
description: 'User journey — tell stories of how people will use this module'
|
||||
|
||||
nextStepFile: './step-12-creative.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 11: Scenarios
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Tell stories of how users will actually use this module — bring the vision to life.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — storyteller
|
||||
- ✅ Paint a picture of actual usage
|
||||
- 💬 Narrative mode — "imagine this..."
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Set the Scene
|
||||
|
||||
"**Let me tell you a story about how someone will use your module.**"
|
||||
|
||||
"Close your eyes and imagine..."
|
||||
|
||||
### 2. Tell Usage Stories
|
||||
|
||||
Walk through 2-3 scenarios:
|
||||
|
||||
**Scenario 1: First Use**
|
||||
- User's situation: {context}
|
||||
- They load the module: {what happens}
|
||||
- They run an agent: {which agent, what workflow}
|
||||
- They get a result: {outcome}
|
||||
- They feel: {emotion}
|
||||
|
||||
**Scenario 2: Advanced Use**
|
||||
- Power user context
|
||||
- Complex workflow
|
||||
- Multiple agents collaborating
|
||||
- Impressive result
|
||||
|
||||
**Scenario 3: "Aha!" Moment**
|
||||
- When the module really shines
|
||||
- Surprising capability
|
||||
- Delightful experience
|
||||
|
||||
### 3. Validate the Stories
|
||||
|
||||
"**Do these stories feel right? Can you see your module being used this way?**"
|
||||
|
||||
Adjust based on feedback.
|
||||
|
||||
### 4. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ 2-3 usage scenarios told
|
||||
✅ User can visualize their module in action
|
||||
✅ Stories feel authentic and exciting
|
||||
@@ -1,94 +0,0 @@
|
||||
---
|
||||
name: 'step-12-creative'
|
||||
description: 'Creative features — easter eggs, lore, delightful touches'
|
||||
|
||||
nextStepFile: './step-13-review.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 12: Creative Features
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Add the magic — easter eggs, lore, delightful touches that make the module memorable.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — creative magician
|
||||
- ✅ This is where personality comes alive
|
||||
- 💬 "What would make someone smile?"
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 This is optional creativity — not all modules need this
|
||||
- 🎯 Party mode is perfect here
|
||||
- ✨ Have fun with it!
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Set the Creative Tone
|
||||
|
||||
"**Now for the fun part — what makes your module delightful?** ✨
|
||||
|
||||
"Great modules work. Amazing modules have personality. What's yours?"
|
||||
|
||||
### 2. Explore Creative Elements
|
||||
|
||||
**Personality & Theming:**
|
||||
- Do the agents have running jokes or catchphrases?
|
||||
- Is there a consistent tone or vibe?
|
||||
- Any thematic elements? (space, medieval, corporate, etc.)
|
||||
|
||||
**Easter Eggs:**
|
||||
- Hidden commands or responses?
|
||||
- Fun interactions when users try certain things?
|
||||
- Surprises that delight?
|
||||
|
||||
**Module Lore:**
|
||||
- Backstory for the agents?
|
||||
- A consistent "universe" the module lives in?
|
||||
- Narrative elements?
|
||||
|
||||
### 3. Party Mode Ideation
|
||||
|
||||
"**Want to brainstorm creative ideas together?**"
|
||||
|
||||
- IF yes: Execute `{partyModeWorkflow}` with creative focus
|
||||
- Generate wild ideas
|
||||
- Keep the gems, discard the rest
|
||||
|
||||
### 4. Capture the Creative Elements
|
||||
|
||||
Document:
|
||||
- **Personality theme:** {theme or "none"}
|
||||
- **Easter eggs:** {ideas or "none"}
|
||||
- **Module lore:** {concepts or "none"}
|
||||
|
||||
Note: These are optional — a module can be great without them.
|
||||
|
||||
### 5. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}` — perfect for creative brainstorming!
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Creative elements explored (even if "none")
|
||||
✅ Personality themes considered
|
||||
✅ User excited about the possibilities
|
||||
@@ -1,104 +0,0 @@
|
||||
---
|
||||
name: 'step-13-review'
|
||||
description: 'Read through the brief together, "Does this excite you?"'
|
||||
|
||||
nextStepFile: './step-14-finalize.md'
|
||||
briefTemplateFile: '../../templates/brief-template.md'
|
||||
---
|
||||
|
||||
# Step 13: Review
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Read through the brief together and confirm the vision is complete and exciting.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — review facilitator
|
||||
- ✅ Read back what we've discovered
|
||||
- ✅ Ensure nothing important is missing
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Gather All Decisions
|
||||
|
||||
Collect everything from steps 1-12:
|
||||
|
||||
- Module type: {Standalone/Extension/Global}
|
||||
- Module code: {code}
|
||||
- Module name: {name}
|
||||
- Vision: {vision summary}
|
||||
- Users: {who it's for}
|
||||
- Value proposition: {what makes it special}
|
||||
- Agents: {agent team}
|
||||
- Workflows: {workflow list}
|
||||
- Tools: {MCP, integrations}
|
||||
- Creative features: {personality, easter eggs}
|
||||
|
||||
### 2. Read It Back
|
||||
|
||||
"**Let me read back what we've designed together.**"
|
||||
|
||||
Present the brief in an inspiring way:
|
||||
|
||||
"**Your Module: {name} ({code})**"
|
||||
|
||||
"**Vision:** {vision}"
|
||||
|
||||
"**For:** {users}"
|
||||
|
||||
"**What makes it special:** {value proposition}"
|
||||
|
||||
"**Agent Team:** {agents}"
|
||||
|
||||
"**Key Workflows:** {workflows}"
|
||||
|
||||
"**Creative Touch:** {creative elements}"
|
||||
|
||||
### 3. The Excitement Check
|
||||
|
||||
"**Does this excite you?****
|
||||
|
||||
- Is this the module you envisioned?
|
||||
- Anything missing?
|
||||
- Anything you want to change?"
|
||||
|
||||
**Make updates if needed.**
|
||||
|
||||
### 4. Final Confirmation
|
||||
|
||||
"**Are you happy with this brief? Ready to finalize?**"
|
||||
|
||||
### 5. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [B] Back to refine [C] Continue to Finalize
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C' and confirms
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF B: Go back to specific step to refine (ask which one)
|
||||
- IF C: Load `{nextStepFile}`
|
||||
- IF Any other: Ask for clarification, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Brief reviewed completely
|
||||
✅ User confirms excitement
|
||||
✅ No major gaps identified
|
||||
✅ Ready to finalize
|
||||
@@ -1,117 +0,0 @@
|
||||
---
|
||||
name: 'step-14-finalize'
|
||||
description: 'Final polish, output the brief document'
|
||||
|
||||
briefTemplateFile: '../../templates/brief-template.md'
|
||||
bmbCreationsOutputFolder: '{bmb_creations_output_folder}'
|
||||
---
|
||||
|
||||
# Step 14: Finalize
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Create the final module brief document and save it to the bmb-creations output folder.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Architect** — completing the brief
|
||||
- ✅ Assemble everything into a beautiful document
|
||||
- ✅ Celebrate the completion!
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load Template
|
||||
|
||||
Load `{briefTemplateFile}` to use as the base.
|
||||
|
||||
### 2. Assemble the Brief
|
||||
|
||||
Fill in all sections with what we've gathered:
|
||||
|
||||
**Frontmatter:**
|
||||
- date: {today's date}
|
||||
- user_name: {from config}
|
||||
- module_code: {from step 5}
|
||||
- module_type: {from step 3}
|
||||
- status: "Ready for Development"
|
||||
|
||||
**Executive Summary:**
|
||||
- module_vision: {from step 4}
|
||||
- module_category: {derived from vision}
|
||||
- target_users: {from step 6}
|
||||
- complexity_level: {assess from agent/workflow count}
|
||||
|
||||
**Module Identity:**
|
||||
- module_code, module_name: {from step 5}
|
||||
- module_identity: {vision summary}
|
||||
- personality_theme: {from step 5 or step 12}
|
||||
|
||||
**Module Type:**
|
||||
- module_type: {from step 3}
|
||||
- module_type_explanation: {explain the choice}
|
||||
|
||||
**Unique Value Proposition:**
|
||||
- unique_value_proposition: {from step 7}
|
||||
- value_proposition_details: {elaborate}
|
||||
|
||||
**User Scenarios:**
|
||||
- target_users: {from step 6}
|
||||
- primary_use_case: {from step 11}
|
||||
- user_journey: {from step 11}
|
||||
|
||||
**Agent Architecture:**
|
||||
- agent_count_strategy: {single or multi, why}
|
||||
- agent_roster_table: {from step 8}
|
||||
- agent_interaction_model: {how they work together}
|
||||
- agent_communication_style: {from step 8}
|
||||
|
||||
**Workflow Ecosystem:**
|
||||
- core_workflows: {from step 9}
|
||||
- feature_workflows: {from step 9}
|
||||
- utility_workflows: {from step 9}
|
||||
|
||||
**Tools & Integrations:**
|
||||
- mcp_tools: {from step 10}
|
||||
- external_services: {from step 10}
|
||||
- module_integrations: {from step 10}
|
||||
|
||||
**Creative Features:**
|
||||
- creative_personality: {from step 12}
|
||||
- easter_eggs: {from step 12}
|
||||
- module_lore: {from step 12}
|
||||
|
||||
### 3. Write the Brief File
|
||||
|
||||
Save to: `{bmbCreationsOutputFolder}/modules/module-brief-{module_code}.md`
|
||||
|
||||
### 4. Celebrate and Next Steps
|
||||
|
||||
"**🎉 Your module brief is complete!**"
|
||||
|
||||
"**Saved to:** {file path}"
|
||||
|
||||
"**Next steps:**"
|
||||
1. **Review the brief** — Make sure it captures your vision
|
||||
2. **Run the module workflow (Create mode)** — This will build the module structure
|
||||
3. **Create agents** — Use the agent-builder workflow for each agent
|
||||
4. **Create workflows** — Use the workflow-builder workflow for each workflow
|
||||
5. **Test and iterate** — Install and refine
|
||||
|
||||
"**You've created something amazing. Let's build it!**"
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Brief document created and saved
|
||||
✅ All sections filled with gathered information
|
||||
✅ File path provided to user
|
||||
✅ Next steps clearly explained
|
||||
@@ -1,178 +0,0 @@
|
||||
---
|
||||
name: 'step-01-load-brief'
|
||||
description: 'Load brief or user write-up, validate completeness'
|
||||
|
||||
nextStepFile: './step-02-structure.md'
|
||||
continueFile: './step-01b-continue.md'
|
||||
agentSpecTemplate: '../../templates/agent-spec-template.md'
|
||||
workflowSpecTemplate: '../../templates/workflow-spec-template.md'
|
||||
moduleStandardsFile: '../../data/module-standards.md'
|
||||
moduleYamlConventionsFile: '../../data/module-yaml-conventions.md'
|
||||
advancedElicitationTask: '../../../../core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '../../../../core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Brief (Create Mode)
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load the module brief (or get a detailed user write-up) and validate it has the information needed to build the module.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — structured, competent, ready to build
|
||||
- ✅ Validate input before proceeding
|
||||
- ✅ Ensure we have what we need to succeed
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 This is a continuable workflow — check for existing work
|
||||
- 🚫 FORBIDDEN to proceed without complete brief or write-up
|
||||
- 💾 Track progress for continuation
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 📖 Create/update output file to track progress
|
||||
- 🚫 FORBIDDEN to load next step until brief is validated
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Input: Module brief from Brief mode OR user-provided write-up
|
||||
- Output: Module structure ready for implementation
|
||||
- This mode requires complete information to proceed
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly.
|
||||
|
||||
### 1. Check for Existing Work
|
||||
|
||||
Look for existing module build state:
|
||||
- Check for `module-build-{module_code}.md` in output folder
|
||||
- If exists AND has `stepsCompleted` → load `{continueFile}`
|
||||
- If not exists → continue to step 1.2
|
||||
|
||||
### 2. Get the Brief or Write-Up
|
||||
|
||||
"**Welcome to Create mode! I'll build your module structure from your brief.**"
|
||||
|
||||
**"Where is your module brief?"**
|
||||
|
||||
Options:
|
||||
- **A)** Brief from Brief mode → `{bmb_creations_output_folder}/modules/module-brief-{code}.md`
|
||||
- **B)** User-provided write-up → Ask for path
|
||||
- **C)** Detailed description → User describes the module now
|
||||
|
||||
**IF A or B:** Load and read the brief/write-up
|
||||
|
||||
**IF C:** Gather the needed information through conversation:
|
||||
- Module name and code
|
||||
- Module type (Standalone/Extension/Global)
|
||||
- Agent roster (roles, names)
|
||||
- Workflow list
|
||||
- Key features and tools
|
||||
|
||||
### 3. Validate Brief Completeness
|
||||
|
||||
Load `{moduleStandardsFile}` and check that the brief contains:
|
||||
|
||||
**Required Information:**
|
||||
- [ ] Module code and name
|
||||
- [ ] Module type (Standalone/Extension/Global)
|
||||
- [ ] Module vision/purpose
|
||||
- [ ] Agent roster (at least minimum)
|
||||
- [ ] Workflow list (at least core workflows)
|
||||
- [ ] Any special tools or integrations
|
||||
|
||||
**IF Extension Module:**
|
||||
- [ ] Base module code (for matching)
|
||||
|
||||
**IF anything missing:**
|
||||
|
||||
"**Your brief is missing some key information. Let me help you complete it.**"
|
||||
|
||||
Use `{advancedElicitationTask}` if needed to gather missing details.
|
||||
|
||||
### 4. Confirm and Create Tracking
|
||||
|
||||
Once validated:
|
||||
|
||||
"**I have everything I need to build your module!**"
|
||||
|
||||
"**Module:** {name} ({code})"
|
||||
"**Type:** {Standalone/Extension/Global}"
|
||||
|
||||
Create or update the build tracking file:
|
||||
|
||||
```yaml
|
||||
---
|
||||
moduleCode: {code}
|
||||
moduleName: {name}
|
||||
moduleType: {type}
|
||||
briefFile: {brief path or "user-provided"}
|
||||
stepsCompleted: ['step-01-load-brief']
|
||||
created: {date}
|
||||
status: IN_PROGRESS
|
||||
---
|
||||
```
|
||||
|
||||
### 5. Preview the Build Process
|
||||
|
||||
"**Here's what I'll build for you:**"
|
||||
|
||||
1. Directory structure (based on module type)
|
||||
2. module.yaml with install configuration
|
||||
3. _module-installer/ folder (if needed)
|
||||
4. Agent placeholder/spec files
|
||||
5. Workflow placeholder/spec files
|
||||
6. README.md and TODO.md
|
||||
|
||||
"**Ready to start building?**"
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}` for any refinements
|
||||
- IF P: Execute `{partyModeWorkflow}` for creative pre-build discussion
|
||||
- IF C: Update tracking file, then load `{nextStepFile}`
|
||||
- IF Any other: Help user, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Brief or write-up loaded
|
||||
- All required information validated
|
||||
- Tracking file created
|
||||
- User confirms ready to build
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding with incomplete brief
|
||||
- Missing key information (code, type, agents, workflows)
|
||||
- Not validating extension base module
|
||||
|
||||
**Master Rule:** Garbage in, garbage out. Ensure we have complete information before building.
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
name: 'step-01b-continue'
|
||||
description: 'Handle workflow continuation for Create mode'
|
||||
|
||||
workflowFile: '../workflow.md'
|
||||
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
|
||||
---
|
||||
|
||||
# Step 1b: Continue (Create Mode)
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Resume a paused Create mode session by loading the build tracking state and routing to the correct step.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — picking up where we left off
|
||||
- ✅ Warm welcome back
|
||||
- ✅ Seamless resume
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Welcome Back
|
||||
|
||||
"**Welcome back to the Module Builder!** 👋"
|
||||
|
||||
### 2. Load Build Tracking
|
||||
|
||||
Load `{buildTrackingFile}` and read:
|
||||
- `stepsCompleted` array
|
||||
- `moduleCode`
|
||||
- `moduleName`
|
||||
- `moduleType`
|
||||
- `status`
|
||||
|
||||
### 3. Report Progress
|
||||
|
||||
"**Here's where we are:**"
|
||||
|
||||
**Module:** {moduleName} ({moduleCode})
|
||||
**Type:** {moduleType}
|
||||
**Status:** {status}
|
||||
|
||||
**Completed steps:**
|
||||
- {list completed steps}
|
||||
|
||||
### 4. Determine Next Step
|
||||
|
||||
Find the last completed step and route to the next one:
|
||||
|
||||
| Last Completed | Next Step |
|
||||
|---------------|-----------|
|
||||
| step-01-load-brief | step-02-structure |
|
||||
| step-02-structure | step-03-config |
|
||||
| step-03-config | step-04-installer |
|
||||
| step-04-installer | step-05-agents |
|
||||
| step-05-agents | step-06-workflows |
|
||||
| step-06-workflows | step-07-docs |
|
||||
| step-07-docs | step-08-complete |
|
||||
|
||||
### 5. Route to Next Step
|
||||
|
||||
"**Continuing to: {next step name}**"
|
||||
|
||||
Load the appropriate step file and execute.
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ User welcomed back
|
||||
✅ Build state loaded
|
||||
✅ Correct next step identified
|
||||
✅ Seamless resume
|
||||
@@ -1,109 +0,0 @@
|
||||
---
|
||||
name: 'step-02-structure'
|
||||
description: 'Create directory structure based on module type'
|
||||
|
||||
nextStepFile: './step-03-config.md'
|
||||
moduleStandardsFile: '../../data/module-standards.md'
|
||||
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
|
||||
---
|
||||
|
||||
# Step 2: Directory Structure
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Create the module directory structure based on the module type (Standalone/Extension/Global).
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — creating the foundation
|
||||
- ✅ Structure follows standards
|
||||
- ✅ Confirm before creating
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Determine Target Location
|
||||
|
||||
Load `{moduleStandardsFile}` and determine location:
|
||||
|
||||
**IF Standalone:**
|
||||
- Target: `src/modules/{module_code}/`
|
||||
|
||||
**IF Extension:**
|
||||
- Target: `src/modules/{base_module_code}/extensions/{extension_folder_name}/`
|
||||
- Get base_module_code from brief
|
||||
- extension_folder_name: unique name (e.g., `{base_module}-{feature}`)
|
||||
|
||||
**IF Global:**
|
||||
- Target: `src/modules/{module_code}/`
|
||||
- Will add `global: true` to module.yaml
|
||||
|
||||
### 2. Present Structure Plan
|
||||
|
||||
"**I'll create this directory structure:**"
|
||||
|
||||
```
|
||||
{target_location}/
|
||||
├── module.yaml
|
||||
├── README.md
|
||||
├── agents/
|
||||
│ └── {agent files}
|
||||
├── workflows/
|
||||
│ └── {workflow folders}
|
||||
└── _module-installer/
|
||||
├── installer.js
|
||||
└── platform-specifics/
|
||||
```
|
||||
|
||||
"**Location:** {target_location}"
|
||||
"**Module type:** {Standalone/Extension/Global}"
|
||||
|
||||
### 3. Confirm and Create
|
||||
|
||||
"**Shall I create the directory structure?**"
|
||||
|
||||
**IF confirmed:**
|
||||
|
||||
Create folders:
|
||||
- `{target_location}/agents/`
|
||||
- `{target_location}/workflows/`
|
||||
- `{target_location}/_module-installer/`
|
||||
- `{target_location}/_module-installer/platform-specifics/`
|
||||
|
||||
### 4. Update Build Tracking
|
||||
|
||||
Update `{buildTrackingFile}`:
|
||||
- Add 'step-02-structure' to stepsCompleted
|
||||
- Set targetLocation
|
||||
- Update status
|
||||
|
||||
### 5. Report Success
|
||||
|
||||
"**✓ Directory structure created at:** {target_location}"
|
||||
|
||||
### 6. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [C] Continue
|
||||
|
||||
- IF C: Update tracking, load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Directory structure created
|
||||
✅ Location based on module type
|
||||
✅ Folders: agents/, workflows/, _module-installer/
|
||||
✅ Build tracking updated
|
||||
@@ -1,118 +0,0 @@
|
||||
---
|
||||
name: 'step-03-config'
|
||||
description: 'Generate module.yaml with install questions'
|
||||
|
||||
nextStepFile: './step-04-installer.md'
|
||||
moduleYamlConventionsFile: '../../data/module-yaml-conventions.md'
|
||||
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
|
||||
targetLocation: '{build_tracking_targetLocation}'
|
||||
---
|
||||
|
||||
# Step 3: Module Configuration
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate module.yaml with install configuration and custom variables.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — configuration expert
|
||||
- ✅ Follow module.yaml conventions
|
||||
- ✅ Ask about custom variables
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load Conventions
|
||||
|
||||
Load `{moduleYamlConventionsFile}` for reference.
|
||||
|
||||
### 2. Generate Base module.yaml
|
||||
|
||||
Create `{targetLocation}/module.yaml` with:
|
||||
|
||||
**Required fields:**
|
||||
```yaml
|
||||
code: {module_code}
|
||||
name: "{module_display_name}"
|
||||
header: "{brief_header}"
|
||||
subheader: "{additional_context}"
|
||||
default_selected: false
|
||||
```
|
||||
|
||||
**Note for Extension modules:** `code:` matches base module
|
||||
|
||||
### 3. Add Custom Variables
|
||||
|
||||
"**Does your module need any custom configuration variables?**"
|
||||
|
||||
Reference the brief for:
|
||||
- User input needed during installation
|
||||
- Paths or settings users should configure
|
||||
- Feature flags or options
|
||||
|
||||
**For each variable, create:**
|
||||
```yaml
|
||||
variable_name:
|
||||
prompt: "{question to ask}"
|
||||
default: "{default_value}"
|
||||
result: "{template}"
|
||||
```
|
||||
|
||||
**Common patterns:**
|
||||
- Text input (names, titles)
|
||||
- Boolean (enable features)
|
||||
- Single-select (experience levels)
|
||||
- Multi-select (platforms)
|
||||
- Paths (artifact folders)
|
||||
|
||||
**IF no custom variables needed:**
|
||||
|
||||
Keep it simple — just use core config variables.
|
||||
|
||||
### 4. Write module.yaml
|
||||
|
||||
Write the complete module.yaml to `{targetLocation}/module.yaml`
|
||||
|
||||
### 5. Update Build Tracking
|
||||
|
||||
Update `{buildTrackingFile}`:
|
||||
- Add 'step-03-config' to stepsCompleted
|
||||
- Note: module.yaml created
|
||||
|
||||
### 6. Report and Confirm
|
||||
|
||||
"**✓ module.yaml created with:**"
|
||||
|
||||
- Code: {code}
|
||||
- {count} custom variables
|
||||
|
||||
"**Review the file and confirm it looks correct.**"
|
||||
|
||||
### 7. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [C] Continue
|
||||
|
||||
- IF C: Update tracking, load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ module.yaml created
|
||||
✅ Required fields populated
|
||||
✅ Custom variables added (if any)
|
||||
✅ Extension modules use correct code
|
||||
✅ Build tracking updated
|
||||
@@ -1,160 +0,0 @@
|
||||
---
|
||||
name: 'step-04-installer'
|
||||
description: 'Setup _module-installer folder and installer.js'
|
||||
|
||||
nextStepFile: './step-05-agents.md'
|
||||
moduleInstallerStandardsFile: '../../data/module-installer-standards.md'
|
||||
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
|
||||
targetLocation: '{build_tracking_targetLocation}'
|
||||
---
|
||||
|
||||
# Step 4: Module Installer
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Setup the _module-installer folder and create installer.js if needed.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — installer expert
|
||||
- ✅ Not all modules need installers
|
||||
- ✅ Follow installer patterns
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Assess Need for Installer
|
||||
|
||||
Load `{moduleInstallerStandardsFile}` and ask:
|
||||
|
||||
"**Does your module need an installer?**"
|
||||
|
||||
Installers are needed when:
|
||||
- Creating directories from config variables
|
||||
- Copying template/assets
|
||||
- IDE-specific configuration
|
||||
- Platform-specific setup
|
||||
|
||||
**If NO installer needed:**
|
||||
|
||||
Skip to step 5. Folder structure already exists.
|
||||
|
||||
**If YES:** Continue to step 4.2
|
||||
|
||||
### 2. Determine Installer Requirements
|
||||
|
||||
"**What should the installer do?**"
|
||||
|
||||
- Create directories? (which variables)
|
||||
- Copy assets? (from where)
|
||||
- IDE configuration? (which IDEs)
|
||||
- Platform-specific setup?
|
||||
|
||||
### 3. Create installer.js
|
||||
|
||||
Create `{targetLocation}/_module-installer/installer.js`:
|
||||
|
||||
```javascript
|
||||
const fs = require('fs-extra');
|
||||
const path = require('node:path');
|
||||
const chalk = require('chalk');
|
||||
const platformCodes = require(path.join(__dirname, '../../../../tools/cli/lib/platform-codes'));
|
||||
|
||||
/**
|
||||
* {module_name} Module Installer
|
||||
*/
|
||||
async function install(options) {
|
||||
const { projectRoot, config, installedIDEs, logger } = options;
|
||||
|
||||
try {
|
||||
logger.log(chalk.blue('Installing {module_name}...'));
|
||||
|
||||
// Create directories
|
||||
if (config['{variable_name}']) {
|
||||
const dirConfig = config['{variable_name}'].replace('{project-root}/', '');
|
||||
const dirPath = path.join(projectRoot, dirConfig);
|
||||
if (!(await fs.pathExists(dirPath))) {
|
||||
logger.log(chalk.yellow(`Creating directory: ${dirConfig}`));
|
||||
await fs.ensureDir(dirPath);
|
||||
}
|
||||
}
|
||||
|
||||
// IDE-specific configuration
|
||||
if (installedIDEs && installedIDEs.length > 0) {
|
||||
for (const ide of installedIDEs) {
|
||||
await configureForIDE(ide, projectRoot, config, logger);
|
||||
}
|
||||
}
|
||||
|
||||
logger.log(chalk.green('✓ {module_name} installation complete'));
|
||||
return true;
|
||||
} catch (error) {
|
||||
logger.error(chalk.red(`Error installing module: ${error.message}`));
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
async function configureForIDE(ide, projectRoot, config, logger) {
|
||||
if (!platformCodes.isValidPlatform(ide)) {
|
||||
logger.warn(chalk.yellow(`Unknown platform: '${ide}'. Skipping.`));
|
||||
return;
|
||||
}
|
||||
|
||||
const platformSpecificPath = path.join(__dirname, 'platform-specifics', `${ide}.js`);
|
||||
|
||||
try {
|
||||
if (await fs.pathExists(platformSpecificPath)) {
|
||||
const platformHandler = require(platformSpecificPath);
|
||||
if (typeof platformHandler.install === 'function') {
|
||||
await platformHandler.install({ projectRoot, config, logger });
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
logger.warn(chalk.yellow(`Warning: Could not configure ${ide}: ${error.message}`));
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = { install };
|
||||
```
|
||||
|
||||
Customize based on module requirements.
|
||||
|
||||
### 4. Platform-Specific Handlers (Optional)
|
||||
|
||||
If IDE-specific setup needed, ask which IDEs and create:
|
||||
- `{targetLocation}/_module-installer/platform-specifics/claude-code.js`
|
||||
- `{targetLocation}/_module-installer/platform-specifics/windsurf.js`
|
||||
- etc.
|
||||
|
||||
### 5. Update Build Tracking
|
||||
|
||||
Update `{buildTrackingFile}`:
|
||||
- Add 'step-04-installer' to stepsCompleted
|
||||
- Note: installer created or skipped
|
||||
|
||||
### 6. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [C] Continue
|
||||
|
||||
- IF C: Update tracking, load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Assessed installer need
|
||||
✅ installer.js created (if needed)
|
||||
✅ Platform handlers created (if needed)
|
||||
✅ Build tracking updated
|
||||
@@ -1,167 +0,0 @@
|
||||
---
|
||||
name: 'step-05-agents'
|
||||
description: 'Create agent placeholder/spec files'
|
||||
|
||||
nextStepFile: './step-06-workflows.md'
|
||||
agentSpecTemplate: '../../templates/agent-spec-template.md'
|
||||
agentArchitectureFile: '../../data/agent-architecture.md'
|
||||
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
|
||||
targetLocation: '{build_tracking_targetLocation}'
|
||||
---
|
||||
|
||||
# Step 5: Agent Specs
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Create agent placeholder/spec files based on the brief.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — creating agent specs
|
||||
- ✅ These are specs, not full agents (agent-builder does that)
|
||||
- ✅ Keep it high-level
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load Agent Architecture
|
||||
|
||||
Load `{agentArchitectureFile}` for guidance.
|
||||
|
||||
### 2. Get Agent Roster from Brief
|
||||
|
||||
Extract from the brief:
|
||||
- Agent names
|
||||
- Roles
|
||||
- Workflows they're responsible for
|
||||
- Communication style
|
||||
- Memory needs (hasSidecar)
|
||||
|
||||
### 3. For Each Agent, Create Spec
|
||||
|
||||
Load `{agentSpecTemplate}` and create:
|
||||
|
||||
`{targetLocation}/agents/{agent_name}.spec.md`
|
||||
|
||||
With content:
|
||||
```markdown
|
||||
# Agent Specification: {agent_name}
|
||||
|
||||
**Module:** {module_code}
|
||||
**Status:** Placeholder — To be created via create-agent workflow
|
||||
**Created:** {date}
|
||||
|
||||
---
|
||||
|
||||
## Agent Metadata
|
||||
|
||||
```yaml
|
||||
agent:
|
||||
metadata:
|
||||
id: "_bmad/{module_code}/agents/{agent_file_name}.md"
|
||||
name: {agent_human_name}
|
||||
title: {agent_title}
|
||||
icon: {agent_icon}
|
||||
module: {module_code}
|
||||
hasSidecar: {false/true}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Persona
|
||||
|
||||
### Role
|
||||
|
||||
{agent_role}
|
||||
|
||||
### Identity
|
||||
|
||||
{agent_identity}
|
||||
|
||||
### Communication Style
|
||||
|
||||
{agent_communication_style}
|
||||
|
||||
### Principles
|
||||
|
||||
{agent_principles}
|
||||
|
||||
---
|
||||
|
||||
## Agent Menu
|
||||
|
||||
### Planned Commands
|
||||
|
||||
| Trigger | Command | Description | Workflow |
|
||||
|---------|---------|-------------|----------|
|
||||
{agent_menu_table}
|
||||
|
||||
---
|
||||
|
||||
## Agent Integration
|
||||
|
||||
### Shared Context
|
||||
|
||||
- References: `{shared_context_files}`
|
||||
- Collaboration with: {collaborating_agents}
|
||||
|
||||
### Workflow References
|
||||
|
||||
{workflow_references}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Use the create-agent workflow to build this agent.**
|
||||
|
||||
---
|
||||
|
||||
_Spec created on {date} via BMAD Module workflow_
|
||||
```
|
||||
|
||||
### 4. Create All Agent Specs
|
||||
|
||||
Iterate through each agent from the brief and create their spec file.
|
||||
|
||||
### 5. Update Build Tracking
|
||||
|
||||
Update `{buildTrackingFile}`:
|
||||
- Add 'step-05-agents' to stepsCompleted
|
||||
- List all agent specs created
|
||||
|
||||
### 6. Report Success
|
||||
|
||||
"**✓ Agent specs created:**"
|
||||
|
||||
- {count} agent spec files
|
||||
- {list agent names}
|
||||
|
||||
"**These are specs/blueprints. Use the create-agent workflow to build each agent.**"
|
||||
|
||||
### 7. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [C] Continue
|
||||
|
||||
- IF C: Update tracking, load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Agent spec files created for all agents
|
||||
✅ Each spec has role, workflows, menu triggers
|
||||
✅ hasSidecar documented (memory decision)
|
||||
✅ Build tracking updated
|
||||
@@ -1,183 +0,0 @@
|
||||
---
|
||||
name: 'step-06-workflows'
|
||||
description: 'Create workflow placeholder/spec files'
|
||||
|
||||
nextStepFile: './step-07-docs.md'
|
||||
workflowSpecTemplate: '../../templates/workflow-spec-template.md'
|
||||
buildTrackingFile: '{bmad_creations_output_folder}/modules/module-build-{module_code}.md'
|
||||
targetLocation: '{build_tracking_targetLocation}'
|
||||
---
|
||||
|
||||
# Step 6: Workflow Specs
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Create workflow placeholder/spec files based on the brief.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — creating workflow specs
|
||||
- ✅ These are specs, not full workflows (workflow-builder does that)
|
||||
- ✅ Keep it high-level
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Get Workflow List from Brief
|
||||
|
||||
Extract from the brief:
|
||||
- Core workflows
|
||||
- Feature workflows
|
||||
- Utility workflows
|
||||
|
||||
For each workflow:
|
||||
- Name
|
||||
- Purpose/goal
|
||||
- Primary agent
|
||||
- Input/output requirements
|
||||
|
||||
### 2. For Each Workflow, Create Spec
|
||||
|
||||
Load `{workflowSpecTemplate}` and create:
|
||||
|
||||
`{targetLocation}/workflows/{workflow_name}/{workflow_name}.spec.md`
|
||||
|
||||
With content:
|
||||
```markdown
|
||||
# Workflow Specification: {workflow_name}
|
||||
|
||||
**Module:** {module_code}
|
||||
**Status:** Placeholder — To be created via create-workflow workflow
|
||||
**Created:** {date}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
**Goal:** {workflow_goal}
|
||||
|
||||
**Description:** {workflow_description}
|
||||
|
||||
**Workflow Type:** {workflow_type}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
### Entry Point
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: {workflow_name}
|
||||
description: {workflow_description}
|
||||
web_bundle: true
|
||||
installed_path: '{project-root}/_bmad/{module_code}/workflows/{workflow_folder_name}'
|
||||
---
|
||||
```
|
||||
|
||||
### Mode
|
||||
|
||||
- [ ] Create-only (steps-c/)
|
||||
- [ ] Tri-modal (steps-c/, steps-e/, steps-v/)
|
||||
|
||||
---
|
||||
|
||||
## Planned Steps
|
||||
|
||||
| Step | Name | Goal |
|
||||
|------|------|------|
|
||||
{workflow_steps_table}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Inputs
|
||||
|
||||
### Required Inputs
|
||||
|
||||
{required_inputs}
|
||||
|
||||
### Optional Inputs
|
||||
|
||||
{optional_inputs}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Outputs
|
||||
|
||||
### Output Format
|
||||
|
||||
- [ ] Document-producing
|
||||
- [ ] Non-document
|
||||
|
||||
### Output Files
|
||||
|
||||
{output_files}
|
||||
|
||||
---
|
||||
|
||||
## Agent Integration
|
||||
|
||||
### Primary Agent
|
||||
|
||||
{primary_agent}
|
||||
|
||||
### Other Agents
|
||||
|
||||
{other_agents}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Use the create-workflow workflow to build this workflow.**
|
||||
|
||||
---
|
||||
|
||||
_Spec created on {date} via BMAD Module workflow_
|
||||
```
|
||||
|
||||
### 3. Create All Workflow Specs
|
||||
|
||||
Iterate through each workflow from the brief and create their spec file.
|
||||
|
||||
### 4. Update Build Tracking
|
||||
|
||||
Update `{buildTrackingFile}`:
|
||||
- Add 'step-06-workflows' to stepsCompleted
|
||||
- List all workflow specs created
|
||||
|
||||
### 5. Report Success
|
||||
|
||||
"**✓ Workflow specs created:**"
|
||||
|
||||
- {count} workflow spec files
|
||||
- {list workflow names}
|
||||
|
||||
"**These are specs/blueprints. Use the create-workflow workflow to build each workflow.**"
|
||||
|
||||
### 6. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [C] Continue
|
||||
|
||||
- IF C: Update tracking, load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Workflow spec files created for all workflows
|
||||
✅ Each spec has goal, steps, inputs/outputs
|
||||
✅ Agent associations documented
|
||||
✅ Build tracking updated
|
||||
@@ -1,402 +0,0 @@
|
||||
---
|
||||
name: 'step-07-docs'
|
||||
description: 'Generate README.md, TODO.md, and docs/ folder'
|
||||
|
||||
nextStepFile: './step-08-complete.md'
|
||||
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
|
||||
targetLocation: '{build_tracking_targetLocation}'
|
||||
---
|
||||
|
||||
# Step 7: Documentation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate README.md, TODO.md, and user documentation in docs/ folder for the module.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — documentation creator
|
||||
- ✅ README is the user's first impression
|
||||
- ✅ TODO tracks remaining work
|
||||
- ✅ docs/ provides user-facing documentation
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Generate README.md
|
||||
|
||||
Create `{targetLocation}/README.md`:
|
||||
|
||||
```markdown
|
||||
# {module_display_name}
|
||||
|
||||
{brief_header}
|
||||
|
||||
{subheader}
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
{module_overview_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
bmad install {module_code}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
{quick_start_from_brief}
|
||||
|
||||
**For detailed documentation, see [docs/](docs/).**
|
||||
|
||||
---
|
||||
|
||||
## Components
|
||||
|
||||
### Agents
|
||||
|
||||
{agent_list_from_brief}
|
||||
|
||||
### Workflows
|
||||
|
||||
{workflow_list_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## Configuration
|
||||
|
||||
The module supports these configuration options (set during installation):
|
||||
|
||||
{config_variables_from_module_yaml}
|
||||
|
||||
---
|
||||
|
||||
## Module Structure
|
||||
|
||||
```
|
||||
{module_code}/
|
||||
├── module.yaml
|
||||
├── README.md
|
||||
├── TODO.md
|
||||
├── docs/
|
||||
│ ├── getting-started.md
|
||||
│ ├── agents.md
|
||||
│ ├── workflows.md
|
||||
│ └── examples.md
|
||||
├── agents/
|
||||
├── workflows/
|
||||
└── _module-installer/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Documentation
|
||||
|
||||
For detailed user guides and documentation, see the **[docs/](docs/)** folder:
|
||||
- [Getting Started](docs/getting-started.md)
|
||||
- [Agents Reference](docs/agents.md)
|
||||
- [Workflows Reference](docs/workflows.md)
|
||||
- [Examples](docs/examples.md)
|
||||
|
||||
---
|
||||
|
||||
## Development Status
|
||||
|
||||
This module is currently in development. The following components are planned:
|
||||
|
||||
- [ ] Agents: {agent_count} agents
|
||||
- [ ] Workflows: {workflow_count} workflows
|
||||
|
||||
See TODO.md for detailed status.
|
||||
|
||||
---
|
||||
|
||||
## Author
|
||||
|
||||
Created via BMAD Module workflow
|
||||
|
||||
---
|
||||
|
||||
## License
|
||||
|
||||
Part of the BMAD framework.
|
||||
```
|
||||
|
||||
### 2. Generate TODO.md
|
||||
|
||||
Create `{targetLocation}/TODO.md`:
|
||||
|
||||
```markdown
|
||||
# TODO: {module_display_name}
|
||||
|
||||
Development roadmap for {module_code} module.
|
||||
|
||||
---
|
||||
|
||||
## Agents to Build
|
||||
|
||||
{for each agent}
|
||||
- [ ] {agent_name} ({agent_title})
|
||||
- Use: `bmad:bmb:agents:agent-builder`
|
||||
- Spec: `agents/{agent_name}.spec.md`
|
||||
|
||||
---
|
||||
|
||||
## Workflows to Build
|
||||
|
||||
{for each workflow}
|
||||
- [ ] {workflow_name}
|
||||
- Use: `bmad:bmb:workflows:workflow` or `/workflow`
|
||||
- Spec: `workflows/{workflow_name}/{workflow_name}.spec.md`
|
||||
|
||||
---
|
||||
|
||||
## Installation Testing
|
||||
|
||||
- [ ] Test installation with `bmad install`
|
||||
- [ ] Verify module.yaml prompts work correctly
|
||||
- [ ] Test installer.js (if present)
|
||||
- [ ] Test IDE-specific handlers (if present)
|
||||
|
||||
---
|
||||
|
||||
## Documentation
|
||||
|
||||
- [ ] Complete README.md with usage examples
|
||||
- [ ] Enhance docs/ folder with more guides
|
||||
- [ ] Add troubleshooting section
|
||||
- [ ] Document configuration options
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. Build agents using create-agent workflow
|
||||
2. Build workflows using create-workflow workflow
|
||||
3. Test installation and functionality
|
||||
4. Iterate based on testing
|
||||
|
||||
---
|
||||
|
||||
_Last updated: {date}_
|
||||
```
|
||||
|
||||
### 3. Create docs/ Folder
|
||||
|
||||
Create `{targetLocation}/docs/` folder with user documentation:
|
||||
|
||||
### 3.1. getting-started.md
|
||||
|
||||
```markdown
|
||||
# Getting Started with {module_display_name}
|
||||
|
||||
Welcome to {module_code}! This guide will help you get up and running.
|
||||
|
||||
---
|
||||
|
||||
## What This Module Does
|
||||
|
||||
{module_purpose_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## Installation
|
||||
|
||||
If you haven't installed the module yet:
|
||||
|
||||
```bash
|
||||
bmad install {module_code}
|
||||
```
|
||||
|
||||
Follow the prompts to configure the module for your needs.
|
||||
|
||||
---
|
||||
|
||||
## First Steps
|
||||
|
||||
{first_steps_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
{common_use_cases_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## What's Next?
|
||||
|
||||
- Check out the [Agents Reference](agents.md) to meet your team
|
||||
- Browse the [Workflows Reference](workflows.md) to see what you can do
|
||||
- See [Examples](examples.md) for real-world usage
|
||||
|
||||
---
|
||||
|
||||
## Need Help?
|
||||
|
||||
If you run into issues:
|
||||
1. Check the troubleshooting section in examples.md
|
||||
2. Review your module configuration
|
||||
3. Consult the broader BMAD documentation
|
||||
```
|
||||
|
||||
### 3.2. agents.md
|
||||
|
||||
```markdown
|
||||
# Agents Reference
|
||||
|
||||
{module_code} includes {agent_count} specialized agents:
|
||||
|
||||
---
|
||||
|
||||
{for each agent}
|
||||
## {agent_title}
|
||||
|
||||
**ID:** `{agent_id}`
|
||||
**Icon:** {agent_icon}
|
||||
|
||||
**Role:**
|
||||
{agent_role_from_spec}
|
||||
|
||||
**When to Use:**
|
||||
{when_to_use_from_spec}
|
||||
|
||||
**Key Capabilities:**
|
||||
{agent_capabilities_from_spec}
|
||||
|
||||
**Menu Trigger(s):**
|
||||
{menu_triggers_from_spec}
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
### 3.3. workflows.md
|
||||
|
||||
```markdown
|
||||
# Workflows Reference
|
||||
|
||||
{module_code} includes {workflow_count} workflows:
|
||||
|
||||
---
|
||||
|
||||
{for each workflow}
|
||||
## {workflow_title}
|
||||
|
||||
**ID:** `{workflow_id}`
|
||||
**Workflow:** `{workflow_name}`
|
||||
|
||||
**Purpose:**
|
||||
{workflow_purpose_from_spec}
|
||||
|
||||
**When to Use:**
|
||||
{when_to_use_from_spec}
|
||||
|
||||
**Key Steps:**
|
||||
{workflow_steps_outline_from_spec}
|
||||
|
||||
**Agent(s):**
|
||||
{associated_agents_from_spec}
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
### 3.4. examples.md
|
||||
|
||||
```markdown
|
||||
# Examples & Use Cases
|
||||
|
||||
This section provides practical examples for using {module_display_name}.
|
||||
|
||||
---
|
||||
|
||||
## Example Workflows
|
||||
|
||||
{example_workflows_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## Common Scenarios
|
||||
|
||||
{common_scenarios_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## Tips & Tricks
|
||||
|
||||
{tips_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
{troubleshooting_from_brief}
|
||||
|
||||
---
|
||||
|
||||
## Getting More Help
|
||||
|
||||
- Review the main BMAD documentation
|
||||
- Check module configuration in module.yaml
|
||||
- Verify all agents and workflows are properly installed
|
||||
```
|
||||
|
||||
### 4. Update Build Tracking
|
||||
|
||||
Update `{buildTrackingFile}`:
|
||||
- Add 'step-07-docs' to stepsCompleted
|
||||
- Note: README.md, TODO.md, and docs/ folder created
|
||||
|
||||
### 5. Report Success
|
||||
|
||||
"**✓ Documentation created:**"
|
||||
|
||||
- README.md — module overview and navigation
|
||||
- TODO.md — development roadmap
|
||||
- docs/ — user documentation folder
|
||||
- getting-started.md — quick start guide
|
||||
- agents.md — agent reference
|
||||
- workflows.md — workflow reference
|
||||
- examples.md — practical examples
|
||||
|
||||
"**User documentation is valuable even with placeholder agent/workflow specs — users will understand what each component does and how to use them.**"
|
||||
|
||||
"**TODO.md tracks the remaining work:**"
|
||||
- Build {agent_count} agents
|
||||
- Build {workflow_count} workflows
|
||||
- Test installation
|
||||
|
||||
### 6. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [C] Continue
|
||||
|
||||
- IF C: Update tracking, load `{nextStepFile}`
|
||||
- IF Any other: Help, then redisplay menu
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ README.md created with all sections
|
||||
✅ TODO.md created with agent/workflow checklist
|
||||
✅ docs/ folder created with user documentation
|
||||
✅ Build tracking updated
|
||||
@@ -1,123 +0,0 @@
|
||||
---
|
||||
name: 'step-08-complete'
|
||||
description: 'Finalize, offer to run validation'
|
||||
|
||||
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
|
||||
targetLocation: '{build_tracking_targetLocation}'
|
||||
validationWorkflow: '../steps-v/step-01-validate.md'
|
||||
---
|
||||
|
||||
# Step 8: Complete
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Finalize the module build, update tracking, and offer to run validation.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Module Builder** — completing the build
|
||||
- ✅ Celebrate what was created
|
||||
- ✅ Guide next steps
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Final Build Summary
|
||||
|
||||
"**🎉 Module structure build complete!**"
|
||||
|
||||
**Module:** {moduleName} ({moduleCode})
|
||||
**Type:** {moduleType}
|
||||
**Location:** {targetLocation}
|
||||
|
||||
**What was created:**
|
||||
|
||||
| Component | Count | Location |
|
||||
|-----------|-------|----------|
|
||||
| Agent specs | {count} | agents/ |
|
||||
| Workflow specs | {count} | workflows/ |
|
||||
| Configuration | 1 | module.yaml |
|
||||
| Documentation | 2 | README.md, TODO.md |
|
||||
| Installer | {yes/no} | _module-installer/ |
|
||||
|
||||
### 2. Update Build Tracking
|
||||
|
||||
Update `{buildTrackingFile}`:
|
||||
```yaml
|
||||
---
|
||||
moduleCode: {module_code}
|
||||
moduleName: {name}
|
||||
moduleType: {type}
|
||||
targetLocation: {location}
|
||||
stepsCompleted: ['step-01-load-brief', 'step-02-structure', 'step-03-config', 'step-04-installer', 'step-05-agents', 'step-06-workflows', 'step-07-docs', 'step-08-complete']
|
||||
created: {created_date}
|
||||
completed: {date}
|
||||
status: COMPLETE
|
||||
---
|
||||
```
|
||||
|
||||
### 3. Next Steps
|
||||
|
||||
"**Your module structure is ready! Here's what to do next:**"
|
||||
|
||||
1. **Review the build** — Check {targetLocation}
|
||||
2. **Build agents** — Use `bmad:bmb:agents:agent-builder` for each agent spec
|
||||
3. **Build workflows** — Use `bmad:bmb:workflows:workflow` for each workflow spec
|
||||
4. **Test installation** — Run `bmad install {module_code}`
|
||||
5. **Iterate** — Refine based on testing
|
||||
|
||||
### 4. Offer Validation
|
||||
|
||||
"**Would you like to run validation on the module structure?**"
|
||||
|
||||
Validation checks:
|
||||
- File structure compliance
|
||||
- module.yaml correctness
|
||||
- Spec completeness
|
||||
- Installation readiness
|
||||
|
||||
### 5. MENU OPTIONS
|
||||
|
||||
**Select an Option:** [V] Validate Module [D] Done
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF V: Load `{validationWorkflow}` to run validation
|
||||
- IF D: Celebration message, workflow complete
|
||||
- IF Any other: Help user, then redisplay menu
|
||||
|
||||
### 6. Completion Message (if Done selected)
|
||||
|
||||
"**🚀 You've built a module structure for BMAD!**"
|
||||
|
||||
"**Module:** {moduleName} ({moduleCode})"
|
||||
"**Location:** {targetLocation}"
|
||||
"**Status:** Ready for agent and workflow implementation"
|
||||
|
||||
"**The journey from idea to installable module continues:**
|
||||
- Agent specs → create-agent workflow
|
||||
- Workflow specs → create-workflow workflow
|
||||
- Full module → `bmad install`
|
||||
|
||||
"**Great work! Let's build something amazing.** ✨"
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Build tracking marked COMPLETE
|
||||
✅ Summary presented to user
|
||||
✅ Next steps clearly explained
|
||||
✅ Validation offered (optional)
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
name: 'step-01-load-target'
|
||||
description: 'Load target for editing'
|
||||
|
||||
nextStepFile: './step-02-select-edit.md'
|
||||
moduleStandardsFile: '../../data/module-standards.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Target (Edit Mode)
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load the target (brief, module.yaml, agent specs, or workflow specs) for editing.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Editor** — helpful, ready to assist
|
||||
- ✅ Understand what we're editing
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Determine Edit Target
|
||||
|
||||
"**What would you like to edit?**"
|
||||
|
||||
Options:
|
||||
- **[B]rief** — Module brief from Brief mode
|
||||
- **[Y]aml** — module.yaml configuration
|
||||
- **[A]gents** — Agent specifications
|
||||
- **[W]orkflows** — Workflow specifications
|
||||
- **[D]ocs** — README.md or TODO.md
|
||||
|
||||
### 2. Load Target
|
||||
|
||||
Based on selection, load the target file(s).
|
||||
|
||||
**IF Brief:**
|
||||
- Path: `{bmb_creations_output_folder}/modules/module-brief-{code}.md`
|
||||
|
||||
**IF Yaml:**
|
||||
- Path: `src/modules/{code}/module.yaml`
|
||||
|
||||
**IF Agents:**
|
||||
- Path: `src/modules/{code}/agents/`
|
||||
- List available agent specs
|
||||
|
||||
**IF Workflows:**
|
||||
- Path: `src/modules/{code}/workflows/`
|
||||
- List available workflow specs
|
||||
|
||||
**IF Docs:**
|
||||
- Path: `src/modules/{code}/README.md` or `TODO.md`
|
||||
|
||||
### 3. Display Current Content
|
||||
|
||||
Show the current content of the target file.
|
||||
|
||||
"**Here's the current content:**"
|
||||
|
||||
{display relevant sections or summary}
|
||||
|
||||
### 4. Proceed to Selection
|
||||
|
||||
"**What would you like to change?**"
|
||||
|
||||
Load `{nextStepFile}` to select the edit type.
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Target loaded
|
||||
✅ Current content displayed
|
||||
✅ Ready to select edit type
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
name: 'step-02-select-edit'
|
||||
description: 'Select edit type and gather changes'
|
||||
|
||||
nextStepFile: './step-03-apply-edit.md'
|
||||
---
|
||||
|
||||
# Step 2: Select Edit Type
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Select the type of edit and gather the changes to make.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Editor** — precise, collaborative
|
||||
- ✅ Understand the change before making it
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Select Edit Type
|
||||
|
||||
"**What type of edit would you like to make?**"
|
||||
|
||||
- **[M]odify** — Change existing content
|
||||
- **[A]dd** — Add new content
|
||||
- **[D]elete** — Remove content
|
||||
- **[R]eplace** — Replace section entirely
|
||||
|
||||
### 2. Gather Edit Details
|
||||
|
||||
**IF Modify:**
|
||||
"**Which section do you want to modify?**"
|
||||
"What should it change to?"
|
||||
|
||||
**IF Add:**
|
||||
"**What do you want to add?**"
|
||||
"**Where should it go?**"
|
||||
|
||||
**IF Delete:**
|
||||
"**What do you want to remove?**"
|
||||
|
||||
**IF Replace:**
|
||||
"**What section should be replaced?**"
|
||||
"**What's the new content?**"
|
||||
|
||||
### 3. Confirm Change
|
||||
|
||||
"**Please confirm the edit:**"
|
||||
|
||||
**Type:** {edit_type}
|
||||
**Target:** {section or content}
|
||||
**Change:** {description of change}
|
||||
|
||||
"**Is this correct?**"
|
||||
|
||||
### 4. Store Edit Plan
|
||||
|
||||
Store the edit plan for the next step.
|
||||
|
||||
Load `{nextStepFile}` to apply the edit.
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Edit type selected
|
||||
✅ Change details gathered
|
||||
✅ User confirmed
|
||||
✅ Edit plan stored
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
name: 'step-03-apply-edit'
|
||||
description: 'Apply the edit and save'
|
||||
|
||||
nextStepFile: './step-04-review.md'
|
||||
---
|
||||
|
||||
# Step 3: Apply Edit
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Apply the confirmed edit to the target file and save.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Editor** — making changes
|
||||
- ✅ Apply edits precisely
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load Target File
|
||||
|
||||
Read the complete target file.
|
||||
|
||||
### 2. Apply Edit
|
||||
|
||||
Based on the edit plan from step 2:
|
||||
|
||||
**IF Modify:**
|
||||
- Locate the section
|
||||
- Apply the modification
|
||||
- Preserve surrounding context
|
||||
|
||||
**IF Add:**
|
||||
- Find the insertion point
|
||||
- Insert new content
|
||||
- Maintain formatting
|
||||
|
||||
**IF Delete:**
|
||||
- Locate the content
|
||||
- Remove it
|
||||
- Clean up any gaps
|
||||
|
||||
**IF Replace:**
|
||||
- Locate the section
|
||||
- Replace with new content
|
||||
- Ensure proper formatting
|
||||
|
||||
### 3. Save Changes
|
||||
|
||||
Write the modified content back to the target file.
|
||||
|
||||
### 4. Report Success
|
||||
|
||||
"**✓ Edit applied!**"
|
||||
|
||||
**File:** {file_path}
|
||||
**Change:** {summary_of_change}
|
||||
|
||||
### 5. Proceed to Review
|
||||
|
||||
Load `{nextStepFile}` to review the changes.
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Edit applied correctly
|
||||
✅ File saved
|
||||
✅ Change summary provided
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
name: 'step-04-review'
|
||||
description: 'Review changes and offer validation'
|
||||
|
||||
nextStepFile: './step-05-confirm.md'
|
||||
validationWorkflow: '../steps-v/step-01-load-target.md'
|
||||
---
|
||||
|
||||
# Step 4: Review Changes
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Review the applied changes and offer to run validation.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Editor** — confirming changes
|
||||
- ✅ Ensure user is satisfied
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Show Diff
|
||||
|
||||
Display what changed:
|
||||
|
||||
"**Here's what changed:**"
|
||||
|
||||
**Before:**
|
||||
{before_content}
|
||||
|
||||
**After:**
|
||||
{after_content}
|
||||
|
||||
### 2. Confirm Satisfaction
|
||||
|
||||
"**Are you happy with this change?**"
|
||||
|
||||
- **[Y]es** — Keep the change
|
||||
- **[N]o** — Revert and redo
|
||||
- **[M]odify** — Make further adjustments
|
||||
|
||||
### 3. Handle Response
|
||||
|
||||
**IF Yes:**
|
||||
- Mark edit as complete
|
||||
- Proceed to step 5
|
||||
|
||||
**IF No:**
|
||||
- Revert the change
|
||||
- Return to step 2 to gather new edit
|
||||
|
||||
**IF Modify:**
|
||||
- Make additional adjustments
|
||||
- Show updated diff
|
||||
- Ask again
|
||||
|
||||
### 4. Offer Validation
|
||||
|
||||
"**Would you like to run validation after this edit?**"
|
||||
|
||||
- Validation can check for any issues introduced
|
||||
|
||||
### 5. Proceed to Confirm
|
||||
|
||||
Load `{nextStepFile}` to confirm completion.
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Changes reviewed
|
||||
✅ User satisfaction confirmed
|
||||
✅ Validation offered
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
name: 'step-05-confirm'
|
||||
description: 'Confirm completion and offer next steps'
|
||||
|
||||
validationWorkflow: '../steps-v/step-01-load-target.md'
|
||||
---
|
||||
|
||||
# Step 5: Confirm Completion
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Confirm edit completion and offer next steps including validation.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Module Editor** — completing the job
|
||||
- ✅ Guide next steps
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Summary of Changes
|
||||
|
||||
"**✓ Edit complete!**"
|
||||
|
||||
**File edited:** {file_path}
|
||||
**Edit type:** {edit_type}
|
||||
**Summary:** {summary_of_change}
|
||||
|
||||
### 2. Offer Next Actions
|
||||
|
||||
"**What would you like to do next?**"
|
||||
|
||||
- **[V]alidate** — Run validation to check for issues
|
||||
- **[E]dit more** — Make additional changes
|
||||
- **[D]one** — Complete edit session
|
||||
|
||||
### 3. Handle Response
|
||||
|
||||
**IF Validate:**
|
||||
"**Loading validation workflow...**"
|
||||
Load `{validationWorkflow}`
|
||||
|
||||
**IF Edit more:**
|
||||
"**Loading edit selection...**"
|
||||
Return to step 1
|
||||
|
||||
**IF Done:**
|
||||
"**Edit session complete!**"
|
||||
Summary of what was accomplished.
|
||||
|
||||
### 4. Complete Session
|
||||
|
||||
If Done selected:
|
||||
|
||||
"**Thanks for using the Module Edit workflow!**"
|
||||
|
||||
"**Summary:**"
|
||||
- Files edited: {count}
|
||||
- Changes made: {summary}
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Edit confirmed complete
|
||||
✅ Next actions offered
|
||||
✅ Validation accessible
|
||||
✅ Session properly closed
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
name: 'step-01-load-target'
|
||||
description: 'Load target for validation'
|
||||
|
||||
nextStepFile: './step-02-file-structure.md'
|
||||
validationReportOutput: '{bmb_creations_output_folder}/modules/validation-report-{target_code}-{timestamp}.md'
|
||||
---
|
||||
|
||||
# Step 1: Load Target (Validate Mode)
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Load the target (brief, module, agent specs, or workflow specs) for validation.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Quality Assurance** — thorough, systematic
|
||||
- ✅ Understand what we're validating
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Determine Validation Target
|
||||
|
||||
"**What would you like to validate?**"
|
||||
|
||||
Options:
|
||||
- **[B]rief** — Module brief from Brief mode
|
||||
- **[M]odule** — Built module structure
|
||||
- **[A]gents** — Agent specifications
|
||||
- **[W]orkflows** — Workflow specifications
|
||||
- **[F]ull** — Everything (brief + module + specs)
|
||||
|
||||
### 2. Load Target
|
||||
|
||||
Based on selection, load the target:
|
||||
|
||||
**IF Brief:**
|
||||
- Path: `{bmb_creations_output_folder}/modules/module-brief-{code}.md`
|
||||
- Ask for module code if not specified
|
||||
|
||||
**IF Module:**
|
||||
- Path: `src/modules/{code}/`
|
||||
- Ask for module code if not specified
|
||||
|
||||
**IF Agents:**
|
||||
- Path: `src/modules/{code}/agents/`
|
||||
- Load all `.spec.md` or `.agent.yaml` files
|
||||
|
||||
**IF Workflows:**
|
||||
- Path: `src/modules/{code}/workflows/`
|
||||
- Load all `.spec.md` files
|
||||
|
||||
**IF Full:**
|
||||
- Load everything above for a module
|
||||
|
||||
### 3. Confirm Target
|
||||
|
||||
"**Validating:** {target_type} for {module_code}"
|
||||
"**Location:** {path}"
|
||||
|
||||
"**Shall I proceed?**"
|
||||
|
||||
### 4. Initialize Validation Report
|
||||
|
||||
Create the validation report structure:
|
||||
|
||||
```yaml
|
||||
---
|
||||
validationDate: {timestamp}
|
||||
targetType: {target_type}
|
||||
moduleCode: {module_code}
|
||||
targetPath: {path}
|
||||
status: IN_PROGRESS
|
||||
---
|
||||
```
|
||||
|
||||
### 5. Proceed to Validation
|
||||
|
||||
"**Starting validation checks...**"
|
||||
|
||||
Load `{nextStepFile}` to begin file structure validation.
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Target loaded
|
||||
✅ Validation report initialized
|
||||
✅ User confirmed
|
||||
@@ -1,94 +0,0 @@
|
||||
---
|
||||
name: 'step-02-file-structure'
|
||||
description: 'Validate file structure compliance'
|
||||
|
||||
nextStepFile: './step-03-module-yaml.md'
|
||||
moduleStandardsFile: '../../data/module-standards.md'
|
||||
validationReportOutput: '{validation_report_output}'
|
||||
---
|
||||
|
||||
# Step 2: File Structure Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate file structure against module standards.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Quality Assurance** — checking structure
|
||||
- ✅ Reference standards, ensure compliance
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load Standards
|
||||
|
||||
Load `{moduleStandardsFile}` for reference.
|
||||
|
||||
### 2. Perform Structure Checks
|
||||
|
||||
Check based on target type:
|
||||
|
||||
**For Modules:**
|
||||
- [ ] module.yaml exists
|
||||
- [ ] README.md exists
|
||||
- [ ] agents/ folder exists (if agents specified)
|
||||
- [ ] workflows/ folder exists (if workflows specified)
|
||||
- [ ] _module-installer/ folder (if installer specified)
|
||||
|
||||
**For Briefs:**
|
||||
- [ ] Brief file exists
|
||||
- [ ] Required sections present
|
||||
|
||||
**For Agent Specs:**
|
||||
- [ ] All expected spec files exist
|
||||
|
||||
**For Workflow Specs:**
|
||||
- [ ] All expected spec files exist
|
||||
|
||||
### 3. Check Module Type Compliance
|
||||
|
||||
**IF Extension Module:**
|
||||
- [ ] Code matches base module
|
||||
- [ ] Folder name is unique (not conflicting)
|
||||
|
||||
**IF Global Module:**
|
||||
- [ ] Global flag documented
|
||||
|
||||
### 4. Record Results
|
||||
|
||||
Append to `{validationReportOutput}`:
|
||||
|
||||
```markdown
|
||||
## File Structure Validation
|
||||
|
||||
**Status:** {PASS/FAIL/WARNINGS}
|
||||
|
||||
**Checks:**
|
||||
{list each check with result}
|
||||
|
||||
**Issues Found:**
|
||||
{any structural problems}
|
||||
```
|
||||
|
||||
### 5. Auto-Proceed
|
||||
|
||||
"**✓ File structure check complete.**"
|
||||
|
||||
Proceeding to next validation...
|
||||
|
||||
Load `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ All structure checks performed
|
||||
✅ Results recorded
|
||||
✅ Auto-proceeds to next validation
|
||||
@@ -1,99 +0,0 @@
|
||||
---
|
||||
name: 'step-03-module-yaml'
|
||||
description: 'Validate module.yaml against conventions'
|
||||
|
||||
nextStepFile: './step-04-agent-specs.md'
|
||||
moduleYamlConventionsFile: '../../data/module-yaml-conventions.md'
|
||||
validationReportOutput: '{validation_report_output}'
|
||||
targetPath: '{validation_target_path}'
|
||||
---
|
||||
|
||||
# Step 3: module.yaml Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate module.yaml formatting and conventions.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Quality Assurance** — checking configuration
|
||||
- ✅ Ensure proper YAML syntax
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load module.yaml
|
||||
|
||||
Read `{targetPath}/module.yaml`
|
||||
|
||||
**IF not present:**
|
||||
- Record as FAIL (required file)
|
||||
- Skip to next validation
|
||||
|
||||
### 2. Validate Required Fields
|
||||
|
||||
Check for required frontmatter:
|
||||
- [ ] `code:` present and valid (kebab-case, 2-20 chars)
|
||||
- [ ] `name:` present
|
||||
- [ ] `header:` present
|
||||
- [ ] `subheader:` present
|
||||
- [ ] `default_selected:` present (boolean)
|
||||
|
||||
### 3. Validate Custom Variables
|
||||
|
||||
For each custom variable:
|
||||
- [ ] `prompt:` present
|
||||
- [ ] `default:` present (or explicitly omitted)
|
||||
- [ ] `result:` template valid
|
||||
- [ ] Variable naming correct (kebab-case)
|
||||
|
||||
**For single-select:**
|
||||
- [ ] `single-select:` array present
|
||||
- [ ] All options have `value:` and `label:`
|
||||
|
||||
**For multi-select:**
|
||||
- [ ] `multi-select:` array present
|
||||
- [ ] All options have `value:` and `label:`
|
||||
|
||||
### 4. Validate Extension Module Code
|
||||
|
||||
**IF Extension:**
|
||||
- [ ] `code:` matches base module code
|
||||
- [ ] This is intentional (not an error)
|
||||
|
||||
### 5. Record Results
|
||||
|
||||
Append to `{validationReportOutput}`:
|
||||
|
||||
```markdown
|
||||
## module.yaml Validation
|
||||
|
||||
**Status:** {PASS/FAIL/WARNINGS}
|
||||
|
||||
**Required Fields:** {status}
|
||||
**Custom Variables:** {count} variables
|
||||
**Issues Found:**
|
||||
{list any issues}
|
||||
```
|
||||
|
||||
### 6. Auto-Proceed
|
||||
|
||||
"**✓ module.yaml check complete.**"
|
||||
|
||||
Proceeding to next validation...
|
||||
|
||||
Load `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ All module.yaml checks performed
|
||||
✅ Results recorded
|
||||
✅ Auto-proceeds to next validation
|
||||
@@ -1,152 +0,0 @@
|
||||
---
|
||||
name: 'step-04-agent-specs'
|
||||
description: 'Validate agent specifications and built agents'
|
||||
|
||||
nextStepFile: './step-05-workflow-specs.md'
|
||||
agentSpecTemplate: '../../templates/agent-spec-template.md'
|
||||
agentArchitectureFile: '../../data/agent-architecture.md'
|
||||
agentValidationWorkflow: '{project-root}/_bmad/bmb/workflows/agent/steps-v/step-01-validate.md'
|
||||
validationReportOutput: '{validation_report_output}'
|
||||
targetPath: '{validation_target_path}'
|
||||
---
|
||||
|
||||
# Step 4: Agent Specs Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate agent specifications and/or built agents, distinguishing between placeholder specs and fully implemented agents.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are the **Quality Assurance** — dual-mode checking
|
||||
- ✅ Specs are expected, built agents are great
|
||||
- ✅ Track status of each agent
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load Agent Files
|
||||
|
||||
Find all agent files in `{targetPath}/agents/`:
|
||||
- `.spec.md` files (placeholder specs)
|
||||
- `.agent.yaml` files (built agents)
|
||||
|
||||
### 2. Categorize Agents
|
||||
|
||||
For each agent found, determine status:
|
||||
|
||||
**Built Agents (.agent.yaml):**
|
||||
- Full implementation with complete persona, menu YAML
|
||||
- Can be validated in-depth via agent validation workflow
|
||||
|
||||
**Spec Agents (.spec.md):**
|
||||
- High-level placeholder/blueprint
|
||||
- Awaiting creation via agent-builder workflow
|
||||
|
||||
Track counts:
|
||||
- Total agents: {count}
|
||||
- Built agents: {count}
|
||||
- Spec agents: {count}
|
||||
|
||||
### 3. Validate Spec Agents (.spec.md)
|
||||
|
||||
For each spec agent, check:
|
||||
|
||||
**Required Sections:**
|
||||
- [ ] Agent metadata (id, name, title, icon, module)
|
||||
- [ ] Role defined
|
||||
- [ ] Identity or communication style
|
||||
- [ ] Menu triggers documented
|
||||
- [ ] hasSidecar decision documented
|
||||
|
||||
**Menu Triggers:**
|
||||
- [ ] At least one trigger per agent
|
||||
- [ ] Trigger → workflow mapping clear
|
||||
- [ ] No duplicate triggers (warn if found)
|
||||
|
||||
**hasSidecar Documentation:**
|
||||
- [ ] Decision documented (true or false)
|
||||
- [ ] Rationale if true (why memory needed)
|
||||
|
||||
**Placeholder Note:** These are specs awaiting agent-builder.
|
||||
|
||||
### 4. Validate Built Agents (.agent.yaml)
|
||||
|
||||
For each built agent, check:
|
||||
|
||||
**Frontmatter Completeness:**
|
||||
- [ ] agent.metadata exists
|
||||
- [ ] agent.persona exists
|
||||
- [ ] agent.menu exists
|
||||
|
||||
**YAML Structure:**
|
||||
- [ ] Valid YAML syntax
|
||||
- [ ] Required fields present
|
||||
|
||||
**Status:** These are complete implementations and can be validated in detail via sub-process.
|
||||
|
||||
### 5. Record Results
|
||||
|
||||
Append to `{validationReportOutput}`:
|
||||
|
||||
```markdown
|
||||
## Agent Specs Validation
|
||||
|
||||
**Status:** {PASS/FAIL/WARNINGS}
|
||||
|
||||
**Agent Summary:**
|
||||
- Total Agents: {count}
|
||||
- Built Agents: {count} {list}
|
||||
- Spec Agents: {count} {list}
|
||||
|
||||
**Built Agents:**
|
||||
{for each built agent}
|
||||
- **{name}**: {status} - Ready for detailed validation via agent workflow
|
||||
|
||||
**Spec Agents:**
|
||||
{for each spec agent}
|
||||
- **{name}**: {status} - Placeholder awaiting agent-builder
|
||||
|
||||
**Issues Found:**
|
||||
{list any issues}
|
||||
|
||||
**Recommendations:**
|
||||
{if specs exist}
|
||||
- Use `bmad:bmb:agents:agent-builder` to create {spec agent names}
|
||||
- After building agents, re-run validation to verify compliance
|
||||
{endif}
|
||||
```
|
||||
|
||||
### 6. Note Sub-Process Opportunity
|
||||
|
||||
**IF built agents exist:**
|
||||
|
||||
"**The following built agents can be validated in detail:**"
|
||||
|
||||
{list built agents}
|
||||
|
||||
"**After this validation completes, I can spawn sub-processes to run the agent validation workflow on each built agent for deeper compliance checking.**"
|
||||
|
||||
### 7. Auto-Proceed
|
||||
|
||||
"**✓ Agent specs check complete.**"
|
||||
|
||||
Proceeding to next validation...
|
||||
|
||||
Load `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ All agent files checked
|
||||
✅ Status tracked (spec vs built)
|
||||
✅ hasSidecar decisions validated
|
||||
✅ Recommendations for specs documented
|
||||
✅ Sub-process opportunity noted
|
||||
@@ -1,152 +0,0 @@
|
||||
---
|
||||
name: 'step-05-workflow-specs'
|
||||
description: 'Validate workflow specifications and built workflows'
|
||||
|
||||
nextStepFile: './step-06-documentation.md'
|
||||
workflowSpecTemplate: '../../templates/workflow-spec-template.md'
|
||||
workflowValidationWorkflow: '{project-root}/_bmad/bmb/workflows/workflow/steps-v/step-01-validate.md'
|
||||
validationReportOutput: '{validation_report_output}'
|
||||
targetPath: '{validation_target_path}'
|
||||
---
|
||||
|
||||
# Step 5: Workflow Specs Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate workflow specifications and/or built workflows, distinguishing between placeholder specs and fully implemented workflows.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Quality Assurance** — dual-mode checking
|
||||
- ✅ Specs are expected, built workflows are great
|
||||
- ✅ Track status of each workflow
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load Workflow Files
|
||||
|
||||
Find all workflow files in `{targetPath}/workflows/`:
|
||||
- `.spec.md` files (placeholder specs)
|
||||
- `workflow.md` files (built workflows)
|
||||
|
||||
### 2. Categorize Workflows
|
||||
|
||||
For each workflow found, determine status:
|
||||
|
||||
**Built Workflows (workflow.md with steps/ folder):**
|
||||
- Full implementation with step files, data, templates
|
||||
- Can be validated in-depth via workflow validation workflow
|
||||
|
||||
**Spec Workflows (.spec.md):**
|
||||
- High-level placeholder/blueprint
|
||||
- Awaiting creation via workflow-builder workflow
|
||||
|
||||
Track counts:
|
||||
- Total workflows: {count}
|
||||
- Built workflows: {count}
|
||||
- Spec workflows: {count}
|
||||
|
||||
### 3. Validate Spec Workflows (.spec.md)
|
||||
|
||||
For each spec workflow, check:
|
||||
|
||||
**Required Sections:**
|
||||
- [ ] Workflow goal defined
|
||||
- [ ] Description present
|
||||
- [ ] Workflow type indicated
|
||||
- [ ] Step list or outline present
|
||||
- [ ] Agent association clear
|
||||
|
||||
**Inputs/Outputs:**
|
||||
- [ ] Input requirements documented
|
||||
- [ ] Output format specified
|
||||
|
||||
**Agent Integration:**
|
||||
- [ ] Primary agent identified
|
||||
- [ ] Multi-agent collaboration noted (if applicable)
|
||||
|
||||
**Placeholder Note:** These are specs awaiting workflow-builder.
|
||||
|
||||
### 4. Validate Built Workflows (workflow.md)
|
||||
|
||||
For each built workflow, check:
|
||||
|
||||
**Workflow Structure:**
|
||||
- [ ] workflow.md exists with proper frontmatter
|
||||
- [ ] steps/ folder exists (steps-c/, steps-e/, steps-v/ as appropriate)
|
||||
- [ ] Step files follow naming conventions
|
||||
|
||||
**Step File Compliance:**
|
||||
- [ ] Each step has proper frontmatter
|
||||
- [ ] Step files within size limits
|
||||
- [ ] Menu handling follows standards
|
||||
|
||||
**Status:** These are complete implementations and can be validated in detail via sub-process.
|
||||
|
||||
### 5. Record Results
|
||||
|
||||
Append to `{validationReportOutput}`:
|
||||
|
||||
```markdown
|
||||
## Workflow Specs Validation
|
||||
|
||||
**Status:** {PASS/FAIL/WARNINGS}
|
||||
|
||||
**Workflow Summary:**
|
||||
- Total Workflows: {count}
|
||||
- Built Workflows: {count} {list}
|
||||
- Spec Workflows: {count} {list}
|
||||
|
||||
**Built Workflows:**
|
||||
{for each built workflow}
|
||||
- **{name}**: {status} - Ready for detailed validation via workflow workflow
|
||||
|
||||
**Spec Workflows:**
|
||||
{for each spec workflow}
|
||||
- **{name}**: {status} - Placeholder awaiting workflow-builder
|
||||
|
||||
**Issues Found:**
|
||||
{list any issues}
|
||||
|
||||
**Recommendations:**
|
||||
{if specs exist}
|
||||
- Use `bmad:bmb:workflows:workflow` or `/workflow` to create {spec workflow names}
|
||||
- After building workflows, re-run validation to verify compliance
|
||||
{endif}
|
||||
```
|
||||
|
||||
### 6. Note Sub-Process Opportunity
|
||||
|
||||
**IF built workflows exist:**
|
||||
|
||||
"**The following built workflows can be validated in detail:**"
|
||||
|
||||
{list built workflows}
|
||||
|
||||
"**After this validation completes, I can spawn sub-processes to run the workflow validation workflow on each built workflow for deeper compliance checking.**"
|
||||
|
||||
### 7. Auto-Proceed
|
||||
|
||||
"**✓ Workflow specs check complete.**"
|
||||
|
||||
Proceeding to next validation...
|
||||
|
||||
Load `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ All workflow files checked
|
||||
✅ Status tracked (spec vs built)
|
||||
✅ Agent associations validated
|
||||
✅ Recommendations for specs documented
|
||||
✅ Sub-process opportunity noted
|
||||
@@ -1,143 +0,0 @@
|
||||
---
|
||||
name: 'step-06-documentation'
|
||||
description: 'Validate documentation (README.md, TODO.md, docs/)'
|
||||
|
||||
nextStepFile: './step-07-installation.md'
|
||||
validationReportOutput: '{validation_report_output}'
|
||||
targetPath: '{validation_target_path}'
|
||||
moduleBriefPath: '{module_brief_path}'
|
||||
---
|
||||
|
||||
# Step 6: Documentation Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate module documentation completeness, including user-facing docs in docs/ folder.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Quality Assurance** — checking docs
|
||||
- ✅ Documentation matters for usability
|
||||
- ✅ User docs can be generated from placeholder plans
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Load Documentation Files
|
||||
|
||||
Check for:
|
||||
- `{targetPath}/README.md` (module overview)
|
||||
- `{targetPath}/TODO.md` (development roadmap)
|
||||
- `{targetPath}/docs/` (user documentation folder)
|
||||
|
||||
### 2. Validate README.md
|
||||
|
||||
**Required Sections:**
|
||||
- [ ] Module name and description
|
||||
- [ ] Installation instructions
|
||||
- [ ] Components section (agents, workflows)
|
||||
- [ ] Usage examples or quick start
|
||||
- [ ] Module structure
|
||||
- [ ] Link to docs/ folder
|
||||
|
||||
**Quality Checks:**
|
||||
- [ ] Clear description of what module does
|
||||
- [ ] Installation command shown
|
||||
- [ ] Agent/workflow lists complete
|
||||
- [ ] References user documentation
|
||||
|
||||
### 3. Validate TODO.md
|
||||
|
||||
**Required Content:**
|
||||
- [ ] Agent build checklist
|
||||
- [ ] Workflow build checklist
|
||||
- [ ] Testing section
|
||||
- [ ] Next steps
|
||||
|
||||
### 4. Validate docs/ Folder
|
||||
|
||||
**For Custom Modules:**
|
||||
- [ ] docs/ folder exists
|
||||
- [ ] Contains user-facing documentation
|
||||
- [ ] Documentation is clear and helpful
|
||||
|
||||
**Valid docs/ Contents (may include):**
|
||||
- `getting-started.md` — Quick start guide
|
||||
- `agents.md` — Agent documentation
|
||||
- `workflows.md` — Workflow documentation
|
||||
- `examples.md` — Usage examples
|
||||
- `configuration.md` — Setup/configuration guide
|
||||
- `troubleshooting.md` — Common issues and solutions
|
||||
|
||||
**Quality Check:**
|
||||
- [ ] Even with placeholder agent/workflow specs, user docs should provide useful information
|
||||
- [ ] Documentation references agents/workflows by name
|
||||
- [ ] Clear what functionality exists vs what is planned
|
||||
|
||||
### 5. Generate User Docs Recommendation
|
||||
|
||||
**IF docs/ missing or incomplete:**
|
||||
|
||||
"**User documentation can be generated from module brief and agent/workflow specs.**"
|
||||
|
||||
"**Even with placeholder plans, you can create helpful user documentation that describes:**
|
||||
- What each agent does and when to use it
|
||||
- What workflows are available and their purpose
|
||||
- How to get started with the module
|
||||
- Configuration options (from module.yaml)"
|
||||
|
||||
### 6. Record Results
|
||||
|
||||
Append to `{validationReportOutput}`:
|
||||
|
||||
```markdown
|
||||
## Documentation Validation
|
||||
|
||||
**Status:** {PASS/FAIL/WARNINGS}
|
||||
|
||||
**Root Documentation:**
|
||||
- **README.md:** {present/missing} - {status}
|
||||
- **TODO.md:** {present/missing} - {status}
|
||||
|
||||
**User Documentation (docs/):**
|
||||
- **docs/ folder:** {present/missing} - {status}
|
||||
- **Documentation files:** {count} files found
|
||||
|
||||
**Docs Contents:**
|
||||
{list files in docs/ folder}
|
||||
|
||||
**Issues Found:**
|
||||
{list any issues}
|
||||
|
||||
**Recommendations:**
|
||||
{if docs/ missing or incomplete}
|
||||
- Generate user documentation from module brief and specs
|
||||
- Create getting-started.md, agents.md, workflows.md
|
||||
- User docs are valuable even with placeholder plans
|
||||
{endif}
|
||||
```
|
||||
|
||||
### 7. Auto-Proceed
|
||||
|
||||
"**✓ Documentation check complete.**"
|
||||
|
||||
Proceeding to installation validation...
|
||||
|
||||
Load `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ All documentation checked
|
||||
✅ Required sections validated
|
||||
✅ docs/ folder presence verified
|
||||
✅ User documentation quality assessed
|
||||
✅ Recommendations documented
|
||||
@@ -1,113 +0,0 @@
|
||||
---
|
||||
name: 'step-07-installation'
|
||||
description: 'Installation readiness check'
|
||||
|
||||
nextStepFile: './step-08-report.md'
|
||||
moduleInstallerStandardsFile: '../../data/module-installer-standards.md'
|
||||
validationReportOutput: '{validation_report_output}'
|
||||
targetPath: '{validation_target_path}'
|
||||
---
|
||||
|
||||
# Step 7: Installation Readiness
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Check if the module is ready for installation.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Quality Assurance** — checking readiness
|
||||
- ✅ Installation should work
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Check Installer
|
||||
|
||||
**IF `_module-installer/` exists:**
|
||||
- [ ] `installer.js` present
|
||||
- [ ] Has valid `install()` function
|
||||
- [ ] Platform-specific handlers (if any IDEs supported)
|
||||
|
||||
**IF `_module-installer/` doesn't exist:**
|
||||
- Note: Module may not need installer
|
||||
- Check if this is intentional
|
||||
|
||||
### 2. Validate installer.js (if present)
|
||||
|
||||
Load `{moduleInstallerStandardsFile}` and check:
|
||||
|
||||
**Function Signature:**
|
||||
- [ ] `async function install(options)`
|
||||
- [ ] Accepts: projectRoot, config, installedIDEs, logger
|
||||
- [ ] Returns: Promise<boolean>
|
||||
|
||||
**Error Handling:**
|
||||
- [ ] Try/catch block present
|
||||
- [ ] Error logging present
|
||||
|
||||
**Platform Validation:**
|
||||
- [ ] Uses platformCodes for IDE validation
|
||||
- [ ] Graceful handling of unknown platforms
|
||||
|
||||
### 3. Check module.yaml Install Variables
|
||||
|
||||
**IF custom variables exist:**
|
||||
- [ ] All variables have prompts
|
||||
- [ ] Defaults are reasonable
|
||||
- [ ] Result templates are valid
|
||||
|
||||
**Path Variables:**
|
||||
- [ ] Paths use `{project-root}/` prefix
|
||||
- [ ] Output paths are user-configurable
|
||||
|
||||
### 4. Module Type Installation
|
||||
|
||||
**IF Extension:**
|
||||
- [ ] `code:` matches base (for proper merge)
|
||||
- [ ] Folder name is unique
|
||||
|
||||
**IF Global:**
|
||||
- [ ] `global: true` or documented
|
||||
- [ ] Global impact is minimal/intentional
|
||||
|
||||
### 5. Record Results
|
||||
|
||||
Append to `{validationReportOutput}`:
|
||||
|
||||
```markdown
|
||||
## Installation Readiness
|
||||
|
||||
**Status:** {PASS/FAIL/WARNINGS}
|
||||
|
||||
**Installer:** {present/missing} - {status}
|
||||
**Install Variables:** {count} variables
|
||||
**Ready to Install:** {yes/no}
|
||||
|
||||
**Issues Found:**
|
||||
{list any issues}
|
||||
```
|
||||
|
||||
### 6. Auto-Proceed
|
||||
|
||||
"**✓ Installation readiness check complete.**"
|
||||
|
||||
Proceeding to final report...
|
||||
|
||||
Load `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Installation readiness assessed
|
||||
✅ Installer validated (if present)
|
||||
✅ Module type compatibility checked
|
||||
✅ Results recorded
|
||||
@@ -1,197 +0,0 @@
|
||||
---
|
||||
name: 'step-08-report'
|
||||
description: 'Generate final validation report'
|
||||
|
||||
validationReportOutput: '{validation_report_output}'
|
||||
agentValidationWorkflow: '{project-root}/_bmad/bmb/workflows/agent/steps-v/step-01-validate.md'
|
||||
workflowValidationWorkflow: '{project-root}/_bmad/bmb/workflows/workflow/steps-v/step-01-validate.md'
|
||||
---
|
||||
|
||||
# Step 8: Validation Report
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Compile all validation results into a final report with actionable recommendations, including sub-process validation opportunities for built agents and workflows.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
### Universal Rules:
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ Speak in `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are the **Quality Assurance** — reporting results
|
||||
- ✅ Clear, actionable feedback
|
||||
- ✅ Sub-process validation for built components
|
||||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### 1. Compile Overall Status
|
||||
|
||||
Review all validation sections and determine overall status:
|
||||
|
||||
**PASS:** All checks passed, ready to proceed
|
||||
**WARNINGS:** Minor issues found, can proceed with fixes
|
||||
**FAIL:** Critical issues found, must fix before proceeding
|
||||
|
||||
### 2. Generate Summary
|
||||
|
||||
Add to `{validationReportOutput}`:
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## Overall Summary
|
||||
|
||||
**Status:** {PASS/WARNINGS/FAIL}
|
||||
|
||||
**Breakdown:**
|
||||
- File Structure: {status}
|
||||
- module.yaml: {status}
|
||||
- Agent Specs: {status} ({built_count} built, {spec_count} specs)
|
||||
- Workflow Specs: {status} ({built_count} built, {spec_count} specs)
|
||||
- Documentation: {status}
|
||||
- Installation Readiness: {status}
|
||||
|
||||
---
|
||||
|
||||
## Component Status
|
||||
|
||||
### Agents
|
||||
- **Built Agents:** {count} — {list}
|
||||
- **Spec Agents:** {count} — {list}
|
||||
|
||||
### Workflows
|
||||
- **Built Workflows:** {count} — {list}
|
||||
- **Spec Workflows:** {count} — {list}
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
|
||||
{priority-listed-recommendations}
|
||||
|
||||
### Priority 1 - Critical (must fix)
|
||||
|
||||
{critical_issues}
|
||||
|
||||
### Priority 2 - High (should fix)
|
||||
|
||||
{high_priority_issues}
|
||||
|
||||
### Priority 3 - Medium (nice to have)
|
||||
|
||||
{medium_priority_issues}
|
||||
|
||||
---
|
||||
|
||||
## Sub-Process Validation
|
||||
|
||||
{if built_agents_exist}
|
||||
### Built Agent Deep Validation
|
||||
|
||||
The following built agents can be validated in detail using the agent validation workflow:
|
||||
|
||||
{for each built_agent}
|
||||
- **{agent_name}** — Use `{agentValidationWorkflow}`
|
||||
|
||||
**Recommendation:** Run agent validation workflow on each built agent to verify:
|
||||
- Frontmatter completeness
|
||||
- Persona quality
|
||||
- Menu structure compliance
|
||||
- Sidecar validation
|
||||
|
||||
**After fixing any module-level issues, I can spawn sub-processes to validate each built agent in parallel.**
|
||||
{endif}
|
||||
|
||||
{if built_workflows_exist}
|
||||
### Built Workflow Deep Validation
|
||||
|
||||
The following built workflows can be validated in detail using the workflow validation workflow:
|
||||
|
||||
{for each built_workflow}
|
||||
- **{workflow_name}** — Use `{workflowValidationWorkflow}`
|
||||
|
||||
**Recommendation:** Run workflow validation workflow on each built workflow to verify:
|
||||
- Step file compliance
|
||||
- Tri-modal structure (steps-c/steps-e/steps-v/)
|
||||
- Frontmatter completeness
|
||||
- Size limits compliance
|
||||
|
||||
**After fixing any module-level issues, I can spawn sub-processes to validate each built workflow in parallel.**
|
||||
{endif}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
{based_on_status}
|
||||
|
||||
{if specs_exist}
|
||||
### Build Spec Components
|
||||
|
||||
**Spec Agents:** {spec_count}
|
||||
- Use `bmad:bmb:agents:agent-builder` to create: {spec_agent_names}
|
||||
|
||||
**Spec Workflows:** {spec_count}
|
||||
- Use `bmad:bmb:workflows:workflow` to create: {spec_workflow_names}
|
||||
|
||||
**After building specs, re-run validation to verify compliance.**
|
||||
{endif}
|
||||
|
||||
---
|
||||
|
||||
**Validation Completed:** {timestamp}
|
||||
```
|
||||
|
||||
### 3. Present Report
|
||||
|
||||
"**✓ Validation complete!**"
|
||||
|
||||
**Overall Status:** {overall_status}
|
||||
|
||||
**Report saved to:** `{validationReportOutput}`
|
||||
|
||||
{if built_components_exist}
|
||||
"**Built components found:**"
|
||||
- Built Agents: {count}
|
||||
- Built Workflows: {count}
|
||||
|
||||
"**These can be validated in depth via sub-process.**"
|
||||
{endif}
|
||||
|
||||
### 4. Offer Next Actions
|
||||
|
||||
"**What would you like to do?**"
|
||||
|
||||
- **[R]ead report** — Show the full validation report
|
||||
- **[S]ub-process validation** — Run deep validation on built agents/workflows
|
||||
- **[F]ix issues** — Edit mode to fix identified problems
|
||||
- **[D]one** — Complete validation
|
||||
|
||||
### 5. Menu Handling
|
||||
|
||||
- IF R: Display the full report
|
||||
- IF S:
|
||||
- {if built_components_exist}
|
||||
- Offer to run agent validation on built agents
|
||||
- Offer to run workflow validation on built workflows
|
||||
- Can run in parallel for efficiency
|
||||
- {else}
|
||||
- "No built components found for sub-process validation."
|
||||
- {endif}
|
||||
- IF F: Offer to load Edit mode
|
||||
- IF D: Complete validation session
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
✅ Overall status determined
|
||||
✅ Complete report generated
|
||||
✅ Actionable recommendations provided
|
||||
✅ Sub-process validation opportunities identified
|
||||
✅ Next steps offered
|
||||
@@ -1,154 +0,0 @@
|
||||
# Module Brief: {module_code}
|
||||
|
||||
**Date:** {date}
|
||||
**Author:** {user_name}
|
||||
**Module Code:** {module_code}
|
||||
**Module Type:** {module_type}
|
||||
**Status:** Ready for Development
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{module_vision}
|
||||
|
||||
**Module Category:** {module_category}
|
||||
**Target Users:** {target_users}
|
||||
**Complexity Level:** {complexity_level}
|
||||
|
||||
---
|
||||
|
||||
## Module Identity
|
||||
|
||||
### Module Code & Name
|
||||
|
||||
- **Code:** `{module_code}`
|
||||
- **Name:** `{module_name}`
|
||||
|
||||
### Core Concept
|
||||
|
||||
{module_identity}
|
||||
|
||||
### Personality Theme
|
||||
|
||||
{personality_theme}
|
||||
|
||||
---
|
||||
|
||||
## Module Type
|
||||
|
||||
**Type:** {module_type}
|
||||
|
||||
{module_type_explanation}
|
||||
|
||||
---
|
||||
|
||||
## Unique Value Proposition
|
||||
|
||||
**What makes this module special:**
|
||||
|
||||
{unique_value_proposition}
|
||||
|
||||
**Why users would choose this module:**
|
||||
|
||||
{value_proposition_details}
|
||||
|
||||
---
|
||||
|
||||
## User Scenarios
|
||||
|
||||
### Target Users
|
||||
|
||||
{target_users}
|
||||
|
||||
### Primary Use Case
|
||||
|
||||
{primary_use_case}
|
||||
|
||||
### User Journey
|
||||
|
||||
{user_journey}
|
||||
|
||||
---
|
||||
|
||||
## Agent Architecture
|
||||
|
||||
### Agent Count Strategy
|
||||
|
||||
{agent_count_strategy}
|
||||
|
||||
### Agent Roster
|
||||
|
||||
| Agent | Name | Role | Expertise |
|
||||
|-------|------|------|-----------|
|
||||
{agent_roster_table}
|
||||
|
||||
### Agent Interaction Model
|
||||
|
||||
{agent_interaction_model}
|
||||
|
||||
### Agent Communication Style
|
||||
|
||||
{agent_communication_style}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Ecosystem
|
||||
|
||||
### Core Workflows (Essential)
|
||||
|
||||
{core_workflows}
|
||||
|
||||
### Feature Workflows (Specialized)
|
||||
|
||||
{feature_workflows}
|
||||
|
||||
### Utility Workflows (Support)
|
||||
|
||||
{utility_workflows}
|
||||
|
||||
---
|
||||
|
||||
## Tools & Integrations
|
||||
|
||||
### MCP Tools
|
||||
|
||||
{mcp_tools}
|
||||
|
||||
### External Services
|
||||
|
||||
{external_services}
|
||||
|
||||
### Integrations with Other Modules
|
||||
|
||||
{module_integrations}
|
||||
|
||||
---
|
||||
|
||||
## Creative Features
|
||||
|
||||
### Personality & Theming
|
||||
|
||||
{creative_personality}
|
||||
|
||||
### Easter Eggs & Delighters
|
||||
|
||||
{easter_eggs}
|
||||
|
||||
### Module Lore
|
||||
|
||||
{module_lore}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Review this brief** — Ensure the vision is clear
|
||||
2. **Run create-module workflow** — Build the module structure
|
||||
3. **Create agents** — Use create-agent workflow for each agent
|
||||
4. **Create workflows** — Use create-workflow workflow for each workflow
|
||||
5. **Test module** — Install and verify functionality
|
||||
|
||||
---
|
||||
|
||||
_brief created on {date} by {user_name} using the BMAD Module workflow_
|
||||
@@ -1,96 +0,0 @@
|
||||
# Workflow Specification: {workflow_name}
|
||||
|
||||
**Module:** {module_code}
|
||||
**Status:** Placeholder — To be created via create-workflow workflow
|
||||
**Created:** {date}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
**Goal:** {workflow_goal}
|
||||
|
||||
**Description:** {workflow_description}
|
||||
|
||||
**Workflow Type:** {workflow_type}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
### Entry Point
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: {workflow_name}
|
||||
description: {workflow_description}
|
||||
web_bundle: true
|
||||
installed_path: '{project-root}/_bmad/{module_code}/workflows/{workflow_folder_name}'
|
||||
---
|
||||
```
|
||||
|
||||
### Mode
|
||||
|
||||
- [ ] Create-only (steps-c/)
|
||||
- [ ] Tri-modal (steps-c/, steps-e/, steps-v/)
|
||||
|
||||
---
|
||||
|
||||
## Planned Steps
|
||||
|
||||
| Step | Name | Goal |
|
||||
|------|------|------|
|
||||
{workflow_steps_table}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Inputs
|
||||
|
||||
### Required Inputs
|
||||
|
||||
{required_inputs}
|
||||
|
||||
### Optional Inputs
|
||||
|
||||
{optional_inputs}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Outputs
|
||||
|
||||
### Output Format
|
||||
|
||||
- [ ] Document-producing
|
||||
- [ ] Non-document
|
||||
|
||||
### Output Files
|
||||
|
||||
{output_files}
|
||||
|
||||
---
|
||||
|
||||
## Agent Integration
|
||||
|
||||
### Primary Agent
|
||||
|
||||
{primary_agent}
|
||||
|
||||
### Other Agents
|
||||
|
||||
{other_agents}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Use the create-workflow workflow to build this workflow.**
|
||||
|
||||
Inputs needed:
|
||||
- Workflow name and description
|
||||
- Step structure and sequence
|
||||
- Input/output specifications
|
||||
- Agent associations
|
||||
|
||||
---
|
||||
|
||||
_Spec created on {date} via BMAD Module workflow_
|
||||
@@ -1,100 +0,0 @@
|
||||
---
|
||||
name: module
|
||||
description: Quad-modal workflow for creating BMAD modules (Brief + Create + Edit + Validate)
|
||||
web_bundle: true
|
||||
installed_path: '{project-root}/_bmad/bmb/workflows/module'
|
||||
---
|
||||
|
||||
# Module Workflow
|
||||
|
||||
The module workflow guides users through creating complete, installable BMAD modules through a quad-modal process: **Brief → Create → Edit → Validate**.
|
||||
|
||||
## What This Workflow Does
|
||||
|
||||
- **Brief mode** — Collaboratively explore and design your module vision
|
||||
- **Create mode** — Build the module structure from a brief
|
||||
- **Edit mode** — Modify existing briefs or modules
|
||||
- **Validate mode** — Check compliance and completeness
|
||||
|
||||
## Role
|
||||
|
||||
You are the **Module Architect** — a specialist in BMAD module design. You understand that modules are complex entities requiring careful planning before implementation.
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Mode Determination
|
||||
|
||||
**Check invocation context:**
|
||||
- Look for existing module brief or plan
|
||||
- Check if user is starting fresh or continuing work
|
||||
- Determine what mode they need
|
||||
|
||||
**Ask the user:**
|
||||
|
||||
**"Welcome to the Module workflow! What would you like to do?"**
|
||||
|
||||
- **[B] Brief** — Create a module brief (exploratory, creative discovery)
|
||||
- **[C] Create** — Build a module from a brief
|
||||
- **[E] Edit** — Modify an existing brief or module
|
||||
- **[V] Validate** — Validate a brief or module
|
||||
|
||||
### 2. Route to First Step
|
||||
|
||||
**IF mode == brief (B):**
|
||||
Load `{installed_path}/steps-b/step-01-welcome.md`
|
||||
|
||||
**IF mode == create (C):**
|
||||
Ask: "Where is the module brief?" → Load `{installed_path}/steps-c/step-01-load-brief.md`
|
||||
|
||||
**IF mode == edit (E):**
|
||||
Ask: "What would you like to edit?" → Load `{installed_path}/steps-e/step-01-assess.md`
|
||||
|
||||
**IF mode == validate (V):**
|
||||
Ask: "What would you like to validate?" → Load `{installed_path}/steps-v/step-01-validate.md`
|
||||
|
||||
---
|
||||
|
||||
## Configuration
|
||||
|
||||
This workflow references:
|
||||
- `{installed_path}/data/` — Module standards and templates
|
||||
- `{installed_path}/templates/` — Output templates
|
||||
|
||||
---
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
```
|
||||
module/
|
||||
├── workflow.md # This file - mode routing
|
||||
├── data/ # Shared standards
|
||||
│ ├── module-standards.md
|
||||
│ ├── module-yaml-conventions.md
|
||||
│ ├── agent-architecture.md
|
||||
│ └── module-installer-standards.md
|
||||
├── templates/ # Output templates
|
||||
│ ├── brief-template.md
|
||||
│ ├── agent-spec-template.md
|
||||
│ └── workflow-spec-template.md
|
||||
├── steps-b/ # Brief mode (13 steps)
|
||||
├── steps-c/ # Create mode (8 steps)
|
||||
├── steps-e/ # Edit mode
|
||||
└── steps-v/ # Validate mode
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output
|
||||
|
||||
**Brief mode produces:**
|
||||
- `module-brief-{code}.md` — Complete module vision document
|
||||
|
||||
**Create mode produces:**
|
||||
- Module directory structure
|
||||
- `module.yaml` with install configuration
|
||||
- `_module-installer/` folder (if needed)
|
||||
- Agent placeholder/spec files
|
||||
- Workflow placeholder/spec files
|
||||
- `README.md` and `TODO.md`
|
||||
Reference in New Issue
Block a user