feat: L'Ami Fiduciaire V1.0.0 — full codebase with Story 0.1 complete

Initial commit of the L'Ami Fiduciaire SaaS platform built on Laravel 12,
Vue 3, Inertia.js 2, and Tailwind CSS 4.

Story 0.1 (rename folders to declarations in database) is implemented and
code-reviewed: migration, rollback, and 6 Pest tests all passing.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-03-11 23:33:10 +00:00
commit 35545c2a8f
1517 changed files with 246774 additions and 0 deletions

View File

@@ -0,0 +1,179 @@
# Agent Architecture for Modules
**Purpose:** High-level guidance for planning agents in your module — not implementation details (that's what the agent-builder workflow is for).
---
## Single Agent vs. Multi-Agent Module
### Single Agent Module
**Use when:** One persona can handle the module's purpose.
**Characteristics:**
- Simpler, focused
- Clear single point of contact
- Good for narrow domains
**Question:** Could one expert agent with a sidecar handle this entire module?
---
### Multi-Agent Module
**Use when:** Different expertise areas justify specialized personas.
**Characteristics:**
- Each agent has a distinct role and expertise
- Agents form a cohesive team around the module's theme
- Menus coordinate to guide users to the right agent
**Why multi-agent?**
- Different workflows need different expert perspectives
- Users expect to talk to "the right expert" for each task
- The module covers a domain too broad for one persona
---
## Flagship Example: BMM Agent Team
BMM demonstrates a multi-agent module with **9 specialized agents** forming a complete software development team.
### The BMM Theme
**"Agile software delivery, AI-driven"**
Every agent serves this theme — they're a complete team working together.
### BMM Agent Overview
| Agent | Name | Role | Responsible For |
|-------|------|------|-----------------|
| PM | John | Product Manager | PRDs, requirements, user stories |
| Architect | Winston | System Architect | Technical design, architecture |
| UX | | UX Designer | User research, UX design |
| Dev | | Developer | Implementation, coding |
| TEA | | Test Engineer Architect | Test architecture, QA |
| SM | | Scrum Master | Sprint planning, workflow status |
| Tech Writer | | Technical Writer | Documentation |
| Analyst | | Business Analyst | Analysis, metrics |
| Quick Flow | | Solo Developer | Quick standalone work |
### Key Patterns
1. **Shared commands** — All agents have `[WS]` Workflow Status
2. **Specialty commands** — Each agent has unique commands (PM→PRD, Architect→Architecture)
3. **No overlap** — Each command has one clear owner
4. **Collaboration** — Agents reference each other's work (PRD → Architecture → Implementation)
---
## Planning Your Agents
### For Each Agent, Document:
1. **Role** — What is this agent responsible for?
2. **Workflows** — Which workflows will this agent trigger/own?
3. **Human Name** — What's their persona name? (e.g., "John", "Winston")
4. **Communication Style** — How do they talk? (e.g., "Direct and data-sharp", "Calm and pragmatic")
5. **Skills/Expertise** — What knowledge does this agent bring?
6. **Memory/Learning** — Does this agent need to remember things over time? (hasSidecar)
That's it! The agent-builder workflow will handle the detailed implementation.
---
## Agent Memory & Learning
### Sidecar Agents (hasSidecar: true)
**Use when:** The agent needs to remember context across sessions.
**Characteristics:**
- Has a sidecar file that persists between conversations
- Learns from user interactions
- Remembers project details, preferences, past work
**Examples:**
- An agent that tracks project decisions over time
- An agent that learns user preferences
- An agent that maintains ongoing project context
### Stateless Agents (hasSidecar: false)
**Use when:** The agent doesn't need persistent memory.
**Characteristics:**
- Each conversation starts fresh
- Relies on shared context files (like project-context.md)
- Simpler, more predictable
**Most module agents are stateless** — they reference shared project context rather than maintaining their own memory.
---
## Agent-Workflow Coordination
### Menu Triggers
Each agent has menu items that trigger workflows:
| Trigger Type | Pattern | Example |
|--------------|---------|---------|
| Shared | Same across all agents | `[WS]` Workflow Status |
| Specialty | Unique to this agent | `[PR]` Create PRD (PM only) |
| Cross-reference | Points to another agent's workflow | "See architecture" |
### Simple Planning Format
For each agent, just document:
```
Agent: PM (John)
Role: Product Manager, requirements, PRDs
Triggers:
- WS → Workflow Status (shared)
- PR → Create PRD (specialty)
- ES → Epics and Stories (specialty)
Memory: No (uses shared project-context)
```
The agent-builder workflow will convert this into the proper format.
---
## When to Use Multiple Agents
**Consider multiple agents when:**
- Different workflows require different expertise
- The domain has clear specialization areas
- Users would expect to talk to different "experts"
- The module covers a broad process (like software development)
**Use a single agent when:**
- The domain is focused and narrow
- One expertise area covers all workflows
- Simplicity is preferred
- The agent could reasonably handle everything with a sidecar
---
## Quick Agent Planning Checklist
For each agent in your module:
- [ ] Role defined (what they're responsible for)
- [ ] Workflows assigned (which workflows they trigger)
- [ ] Human name chosen (persona)
- [ ] Communication style described
- [ ] Skills/expertise identified
- [ ] Memory decision (hasSidecar: true/false)
---
## Notes
- **Don't worry about the exact YAML format** — agent-builder handles that
- **Focus on the planning** — who does what, how they work together
- **Keep it high-level** — this is about the module's agent architecture, not implementation details
- **BMM is the reference** — look at how their agents form a cohesive team

View File

@@ -0,0 +1,179 @@
# Agent Architecture for Modules
**Purpose:** High-level guidance for planning agents in your module — not implementation details (that's what the agent-builder workflow is for).
---
## Single Agent vs. Multi-Agent Module
### Single Agent Module
**Use when:** One persona can handle the module's purpose.
**Characteristics:**
- Simpler, focused
- Clear single point of contact
- Good for narrow domains
**Question:** Could one expert agent with a sidecar handle this entire module?
---
### Multi-Agent Module
**Use when:** Different expertise areas justify specialized personas.
**Characteristics:**
- Each agent has a distinct role and expertise
- Agents form a cohesive team around the module's theme
- Menus coordinate to guide users to the right agent
**Why multi-agent?**
- Different workflows need different expert perspectives
- Users expect to talk to "the right expert" for each task
- The module covers a domain too broad for one persona
---
## Flagship Example: BMM Agent Team
BMM demonstrates a multi-agent module with **9 specialized agents** forming a complete software development team.
### The BMM Theme
**"Agile software delivery, AI-driven"**
Every agent serves this theme — they're a complete team working together.
### BMM Agent Overview
| Agent | Name | Role | Responsible For |
|-------|------|------|-----------------|
| PM | John | Product Manager | PRDs, requirements, user stories |
| Architect | Winston | System Architect | Technical design, architecture |
| UX | | UX Designer | User research, UX design |
| Dev | | Developer | Implementation, coding |
| TEA | | Test Engineer Architect | Test architecture, QA |
| SM | | Scrum Master | Sprint planning, workflow status |
| Tech Writer | | Technical Writer | Documentation |
| Analyst | | Business Analyst | Analysis, metrics |
| Quick Flow | | Solo Developer | Quick standalone work |
### Key Patterns
1. **Shared commands** — All agents have `[WS]` Workflow Status
2. **Specialty commands** — Each agent has unique commands (PM→PRD, Architect→Architecture)
3. **No overlap** — Each command has one clear owner
4. **Collaboration** — Agents reference each other's work (PRD → Architecture → Implementation)
---
## Planning Your Agents
### For Each Agent, Document:
1. **Role** — What is this agent responsible for?
2. **Workflows** — Which workflows will this agent trigger/own?
3. **Human Name** — What's their persona name? (e.g., "John", "Winston")
4. **Communication Style** — How do they talk? (e.g., "Direct and data-sharp", "Calm and pragmatic")
5. **Skills/Expertise** — What knowledge does this agent bring?
6. **Memory/Learning** — Does this agent need to remember things over time? (hasSidecar)
That's it! The agent-builder workflow will handle the detailed implementation.
---
## Agent Memory & Learning
### Sidecar Agents (hasSidecar: true)
**Use when:** The agent needs to remember context across sessions.
**Characteristics:**
- Has a sidecar file that persists between conversations
- Learns from user interactions
- Remembers project details, preferences, past work
**Examples:**
- An agent that tracks project decisions over time
- An agent that learns user preferences
- An agent that maintains ongoing project context
### Stateless Agents (hasSidecar: false)
**Use when:** The agent doesn't need persistent memory.
**Characteristics:**
- Each conversation starts fresh
- Relies on shared context files (like project-context.md)
- Simpler, more predictable
**Most module agents are stateless** — they reference shared project context rather than maintaining their own memory.
---
## Agent-Workflow Coordination
### Menu Triggers
Each agent has menu items that trigger workflows:
| Trigger Type | Pattern | Example |
|--------------|---------|---------|
| Shared | Same across all agents | `[WS]` Workflow Status |
| Specialty | Unique to this agent | `[PR]` Create PRD (PM only) |
| Cross-reference | Points to another agent's workflow | "See architecture" |
### Simple Planning Format
For each agent, just document:
```
Agent: PM (John)
Role: Product Manager, requirements, PRDs
Triggers:
- WS → Workflow Status (shared)
- PR → Create PRD (specialty)
- ES → Epics and Stories (specialty)
Memory: No (uses shared project-context)
```
The agent-builder workflow will convert this into the proper format.
---
## When to Use Multiple Agents
**Consider multiple agents when:**
- Different workflows require different expertise
- The domain has clear specialization areas
- Users would expect to talk to different "experts"
- The module covers a broad process (like software development)
**Use a single agent when:**
- The domain is focused and narrow
- One expertise area covers all workflows
- Simplicity is preferred
- The agent could reasonably handle everything with a sidecar
---
## Quick Agent Planning Checklist
For each agent in your module:
- [ ] Role defined (what they're responsible for)
- [ ] Workflows assigned (which workflows they trigger)
- [ ] Human name chosen (persona)
- [ ] Communication style described
- [ ] Skills/expertise identified
- [ ] Memory decision (hasSidecar: true/false)
---
## Notes
- **Don't worry about the exact YAML format** — agent-builder handles that
- **Focus on the planning** — who does what, how they work together
- **Keep it high-level** — this is about the module's agent architecture, not implementation details
- **BMM is the reference** — look at how their agents form a cohesive team

View File

@@ -0,0 +1,79 @@
# Agent Specification: {agent_name}
**Module:** {module_code}
**Status:** Placeholder — To be created via create-agent workflow
**Created:** {date}
---
## Agent Metadata
```yaml
agent:
metadata:
id: "_bmad/{module_code}/agents/{agent_file_name}.md"
name: {agent_human_name}
title: {agent_title}
icon: {agent_icon}
module: {module_code}
hasSidecar: false
```
---
## Agent Persona
### Role
{agent_role}
### Identity
{agent_identity}
### Communication Style
{agent_communication_style}
### Principles
{agent_principles}
---
## Agent Menu
### Planned Commands
| Trigger | Command | Description | Workflow |
|---------|---------|-------------|----------|
{agent_menu_table}
---
## Agent Integration
### Shared Context
- References: `{shared_context_files}`
- Collaboration with: {collaborating_agents}
### Workflow References
{workflow_references}
---
## Implementation Notes
**Use the create-agent workflow to build this agent.**
Inputs needed:
- Agent name and human name
- Role and expertise area
- Communication style preferences
- Menu commands and workflow mappings
---
_Spec created on {date} via BMAD Module workflow_

View File

@@ -0,0 +1,79 @@
# Agent Specification: {agent_name}
**Module:** {module_code}
**Status:** Placeholder — To be created via create-agent workflow
**Created:** {date}
---
## Agent Metadata
```yaml
agent:
metadata:
id: "_bmad/{module_code}/agents/{agent_file_name}.md"
name: {agent_human_name}
title: {agent_title}
icon: {agent_icon}
module: {module_code}
hasSidecar: false
```
---
## Agent Persona
### Role
{agent_role}
### Identity
{agent_identity}
### Communication Style
{agent_communication_style}
### Principles
{agent_principles}
---
## Agent Menu
### Planned Commands
| Trigger | Command | Description | Workflow |
|---------|---------|-------------|----------|
{agent_menu_table}
---
## Agent Integration
### Shared Context
- References: `{shared_context_files}`
- Collaboration with: {collaborating_agents}
### Workflow References
{workflow_references}
---
## Implementation Notes
**Use the create-agent workflow to build this agent.**
Inputs needed:
- Agent name and human name
- Role and expertise area
- Communication style preferences
- Menu commands and workflow mappings
---
_Spec created on {date} via BMAD Module workflow_

View File

@@ -0,0 +1,263 @@
# Module Standards
**Purpose:** Defines what a BMAD module is, its structure, and the three types of modules.
---
## What is a BMAD Module?
A **BMAD module** is a self-contained package of functionality that extends the BMAD framework. Modules provide:
- **Agents** — AI personas with specialized expertise and menu-driven commands
- **Workflows** — Structured processes for accomplishing complex tasks
- **Configuration** — module.yaml for user customization
---
## Module Types
### 1. Standalone Module
A new, independent module focused on a specific domain.
**Characteristics:**
- Own module code (e.g., `healthcare-ai`, `legal-assist`)
- Independent of other modules
- Can be installed alongside any other modules
- Has its own agents, workflows, configuration
**Location:** `src/modules/{module-code}/`
**Example:** CIS (Creative Innovation Suite) — a standalone module for innovation workflows
---
### 2. Extension Module
Extends an existing BMAD module with additional functionality.
**Characteristics:**
- Builds upon an existing module's agents and workflows
- May add new agents or workflows that complement the base module
- Shares configuration context with the extended module
- Typically installed alongside the module it extends
**Location:** `src/modules/{base-module}/extensions/{extension-code}/`
**Example:** An extension to BMM that adds specialized security review workflows
---
### Extension Module: Override & Merge Pattern
When an extension module is installed, its files merge with the base module following these rules:
#### Code Matching
The extension's `module.yaml` `code:` field matches the base module's code:
```yaml
# Base module: src/modules/bmm/module.yaml
code: bmm
# Extension: src/modules/bmm/extensions/security/module.yaml
code: bmm # SAME CODE — extends BMM
```
The **folder name** is unique (e.g., `bmm-security`) but the `code:` matches the base module.
#### File Merge Rules
| File Type | Same Name | Different Name |
|-----------|-----------|----------------|
| Agent file | **OVERRIDE** — replaces the base agent | **ADD** — new agent added |
| Workflow folder | **OVERRIDE** — replaces the base workflow | **ADD** — new workflow added |
| Other files | **OVERRIDE** — replaces base file | **ADD** — new file added |
#### Examples
**Override scenario:**
```
Base module (BMM):
├── agents/
│ └── pm.agent.yaml # Original PM agent
Extension (bmm-security):
├── agents/
│ └── pm.agent.yaml # Security-focused PM — REPLACES original
Result after installation:
├── agents/
│ └── pm.agent.yaml # Now the security version
```
**Add scenario:**
```
Base module (BMM):
├── agents/
│ ├── pm.agent.yaml
│ └── architect.agent.yaml
Extension (bmm-security):
├── agents/
│ └── security-auditor.agent.yaml # NEW agent
Result after installation:
├── agents/
│ ├── pm.agent.yaml
│ ├── architect.agent.yaml
│ └── security-auditor.agent.yaml # ADDED
```
**Mixed scenario:**
```
Extension contains both overrides and new files — applies rules per file
```
---
### 3. Global Module
Affects the entire BMAD framework and all modules.
**Characteristics:**
- Core functionality that impacts all modules
- Often provides foundational services or utilities
- Installed at the framework level
- Use sparingly — only for truly global concerns
**Location:** `src/modules/{module-code}/` with `global: true` in module.yaml
**Example:** A module that provides universal logging or telemetry across BMAD
---
## Required Module Structure
```
{module-code}/
├── module.yaml # Module configuration (REQUIRED)
├── README.md # Module documentation (REQUIRED)
├── agents/ # Agent definitions (if any)
│ └── {agent-name}.agent.yaml
├── workflows/ # Workflow definitions (if any)
│ └── {workflow-name}/
│ └── workflow.md
└── {other folders} # Tasks, templates, data as needed
```
---
## Required Files
### module.yaml (REQUIRED)
Every module MUST have a `module.yaml` file with at minimum:
```yaml
code: {module-code}
name: "Module Display Name"
header: "Brief module description"
subheader: "Additional context"
default_selected: false
```
See: `module-yaml-conventions.md` for full specification.
---
### README.md (REQUIRED)
Every module MUST have a README.md with:
- Module name and purpose
- Installation instructions
- Components section (agents, workflows)
- Quick start guide
- Module structure diagram
- Configuration section
- Usage examples
- Author information
---
## Optional Components
### Agents
Agents are AI personas with:
- Metadata (id, name, title, icon, module)
- Persona (role, identity, communication_style, principles)
- Menu (trigger → workflow/exec mappings)
See: `agent-architecture.md` for design guidance.
---
### Workflows
Workflows are structured processes with:
- workflow.md (entry point)
- steps/ folder with step files
- data/ folder with shared reference
- templates/ folder if needed
---
---
## Module Type Decision Tree
```
START: Creating a module
├─ Is this a brand new independent domain?
│ └─ YES → Standalone Module
├─ Does this extend an existing module?
│ └─ YES → Extension Module
└─ Does this affect all modules globally?
└─ YES → Global Module (use sparingly)
```
---
## Naming Conventions
### Module Code
- **kebab-case** (e.g., `bmm`, `cis`, `bmgd`, `healthcare-ai`)
- Short, memorable, descriptive
- 2-20 characters
- Lowercase letters, numbers, hyphens only
### Agent Files
- Format: `{role-name}.agent.yaml`
- Example: `pm.agent.yaml`, `architect.agent.yaml`
### Workflow Folders
- Format: `{workflow-name}/`
- Example: `prd/`, `create-architecture/`
---
## Module Dependencies
Modules can depend on:
- **Core BMAD** — Always available
- **Other modules** — Specify in module.yaml as `dependencies:`
- **External tools** — Document in README
---
## Quick Reference
| Question | Answer |
|----------|--------|
| What's a module? | Self-contained package of agents, workflows, config |
| What are the types? | Standalone, Extension, Global |
| What's required? | module.yaml, README.md |
| Where do modules live? | `src/modules/{code}/` |
| How do agents work? | Menu triggers → workflow/exec |
| How does installation work? | module.yaml prompts |

View File

@@ -0,0 +1,263 @@
# Module Standards
**Purpose:** Defines what a BMAD module is, its structure, and the three types of modules.
---
## What is a BMAD Module?
A **BMAD module** is a self-contained package of functionality that extends the BMAD framework. Modules provide:
- **Agents** — AI personas with specialized expertise and menu-driven commands
- **Workflows** — Structured processes for accomplishing complex tasks
- **Configuration** — module.yaml for user customization
---
## Module Types
### 1. Standalone Module
A new, independent module focused on a specific domain.
**Characteristics:**
- Own module code (e.g., `healthcare-ai`, `legal-assist`)
- Independent of other modules
- Can be installed alongside any other modules
- Has its own agents, workflows, configuration
**Location:** `src/modules/{module-code}/`
**Example:** CIS (Creative Innovation Suite) — a standalone module for innovation workflows
---
### 2. Extension Module
Extends an existing BMAD module with additional functionality.
**Characteristics:**
- Builds upon an existing module's agents and workflows
- May add new agents or workflows that complement the base module
- Shares configuration context with the extended module
- Typically installed alongside the module it extends
**Location:** `src/modules/{base-module}/extensions/{extension-code}/`
**Example:** An extension to BMM that adds specialized security review workflows
---
### Extension Module: Override & Merge Pattern
When an extension module is installed, its files merge with the base module following these rules:
#### Code Matching
The extension's `module.yaml` `code:` field matches the base module's code:
```yaml
# Base module: src/modules/bmm/module.yaml
code: bmm
# Extension: src/modules/bmm/extensions/security/module.yaml
code: bmm # SAME CODE — extends BMM
```
The **folder name** is unique (e.g., `bmm-security`) but the `code:` matches the base module.
#### File Merge Rules
| File Type | Same Name | Different Name |
|-----------|-----------|----------------|
| Agent file | **OVERRIDE** — replaces the base agent | **ADD** — new agent added |
| Workflow folder | **OVERRIDE** — replaces the base workflow | **ADD** — new workflow added |
| Other files | **OVERRIDE** — replaces base file | **ADD** — new file added |
#### Examples
**Override scenario:**
```
Base module (BMM):
├── agents/
│ └── pm.agent.yaml # Original PM agent
Extension (bmm-security):
├── agents/
│ └── pm.agent.yaml # Security-focused PM — REPLACES original
Result after installation:
├── agents/
│ └── pm.agent.yaml # Now the security version
```
**Add scenario:**
```
Base module (BMM):
├── agents/
│ ├── pm.agent.yaml
│ └── architect.agent.yaml
Extension (bmm-security):
├── agents/
│ └── security-auditor.agent.yaml # NEW agent
Result after installation:
├── agents/
│ ├── pm.agent.yaml
│ ├── architect.agent.yaml
│ └── security-auditor.agent.yaml # ADDED
```
**Mixed scenario:**
```
Extension contains both overrides and new files — applies rules per file
```
---
### 3. Global Module
Affects the entire BMAD framework and all modules.
**Characteristics:**
- Core functionality that impacts all modules
- Often provides foundational services or utilities
- Installed at the framework level
- Use sparingly — only for truly global concerns
**Location:** `src/modules/{module-code}/` with `global: true` in module.yaml
**Example:** A module that provides universal logging or telemetry across BMAD
---
## Required Module Structure
```
{module-code}/
├── module.yaml # Module configuration (REQUIRED)
├── README.md # Module documentation (REQUIRED)
├── agents/ # Agent definitions (if any)
│ └── {agent-name}.agent.yaml
├── workflows/ # Workflow definitions (if any)
│ └── {workflow-name}/
│ └── workflow.md
└── {other folders} # Tasks, templates, data as needed
```
---
## Required Files
### module.yaml (REQUIRED)
Every module MUST have a `module.yaml` file with at minimum:
```yaml
code: {module-code}
name: "Module Display Name"
header: "Brief module description"
subheader: "Additional context"
default_selected: false
```
See: `module-yaml-conventions.md` for full specification.
---
### README.md (REQUIRED)
Every module MUST have a README.md with:
- Module name and purpose
- Installation instructions
- Components section (agents, workflows)
- Quick start guide
- Module structure diagram
- Configuration section
- Usage examples
- Author information
---
## Optional Components
### Agents
Agents are AI personas with:
- Metadata (id, name, title, icon, module)
- Persona (role, identity, communication_style, principles)
- Menu (trigger → workflow/exec mappings)
See: `agent-architecture.md` for design guidance.
---
### Workflows
Workflows are structured processes with:
- workflow.md (entry point)
- steps/ folder with step files
- data/ folder with shared reference
- templates/ folder if needed
---
---
## Module Type Decision Tree
```
START: Creating a module
├─ Is this a brand new independent domain?
│ └─ YES → Standalone Module
├─ Does this extend an existing module?
│ └─ YES → Extension Module
└─ Does this affect all modules globally?
└─ YES → Global Module (use sparingly)
```
---
## Naming Conventions
### Module Code
- **kebab-case** (e.g., `bmm`, `cis`, `bmgd`, `healthcare-ai`)
- Short, memorable, descriptive
- 2-20 characters
- Lowercase letters, numbers, hyphens only
### Agent Files
- Format: `{role-name}.agent.yaml`
- Example: `pm.agent.yaml`, `architect.agent.yaml`
### Workflow Folders
- Format: `{workflow-name}/`
- Example: `prd/`, `create-architecture/`
---
## Module Dependencies
Modules can depend on:
- **Core BMAD** — Always available
- **Other modules** — Specify in module.yaml as `dependencies:`
- **External tools** — Document in README
---
## Quick Reference
| Question | Answer |
|----------|--------|
| What's a module? | Self-contained package of agents, workflows, config |
| What are the types? | Standalone, Extension, Global |
| What's required? | module.yaml, README.md |
| Where do modules live? | `src/modules/{code}/` |
| How do agents work? | Menu triggers → workflow/exec |
| How does installation work? | module.yaml prompts |

View File

@@ -0,0 +1,392 @@
# module.yaml Conventions
**Purpose:** Defines how module.yaml works, including variables, templates, and how they provide context to agents and workflows.
---
## Overview
`module.yaml` is the configuration file for a BMAD module. It:
- Defines module metadata (code, name, description)
- Collects user input via prompts during installation
- Makes those inputs available to agents and workflows as variables
- Specifies which module should be selected by default
---
## Frontmatter Fields
### Required Fields
```yaml
code: {module-code} # kebab-case identifier
name: "Display Name" # Human-readable name
header: "Brief description" # One-line summary
subheader: "Additional context" # More detail
default_selected: false # Auto-select on install?
```
### `default_selected` Guidelines
| Module Type | default_selected | Example |
|-------------|------------------|---------|
| Core/Primary | `true` | BMM (agile software delivery) |
| Specialized | `false` | CIS (creative innovation), BMGD (game dev) |
| Experimental | `false` | New modules in development |
---
## Variables System
### Core Config Variables (Always Available)
These variables are automatically available to ALL modules:
```yaml
# Variables from Core Config inserted:
## user_name # User's name
## communication_language # Preferred language
## document_output_language # Output document language
## output_folder # Default output location
```
No need to define these — they're injected automatically.
---
### Custom Variables
Define custom variables for user input:
```yaml
variable_name:
prompt: "Question to ask the user?"
default: "{default_value}"
result: "{template_for_final_value}"
```
**Example:**
```yaml
project_name:
prompt: "What is the title of your project?"
default: "{directory_name}"
result: "{value}"
```
### Variable Templates
In `prompt` and `result`, you can use templates:
| Template | Expands To |
|----------|------------|
| `{value}` | The user's input |
| `{directory_name}` | Current directory name |
| `{output_folder}` | Output folder from core config |
| `{project-root}` | Project root path |
| `{variable_name}` | Another variable's value |
---
## Variable Types
### 1. Simple Text Input
```yaml
project_name:
prompt: "What is the title of your project?"
default: "{directory_name}"
result: "{value}"
```
---
### 2. Boolean/Flag
```yaml
enable_feature:
prompt: "Enable this feature?"
default: false
result: "{value}"
```
---
### 3. Single Select
```yaml
skill_level:
prompt: "What is your experience level?"
default: "intermediate"
result: "{value}"
single-select:
- value: "beginner"
label: "Beginner - Explains concepts clearly"
- value: "intermediate"
label: "Intermediate - Balanced approach"
- value: "expert"
label: "Expert - Direct and technical"
```
---
### 4. Multi Select
```yaml
platforms:
prompt: "Which platforms do you need?"
default: ["unity", "unreal"]
result: "{value}"
multi-select:
- value: "unity"
label: "Unity"
- value: "unreal"
label: "Unreal Engine"
- value: "godot"
label: "Godot"
```
---
### 5. Multi-Line Prompt
```yaml
complex_variable:
prompt:
- "First question?"
- "Second context?"
- "Third detail?"
default: "default_value"
result: "{value}"
```
---
### 6. Required Variable
```yaml
critical_variable:
prompt: "Required information:"
required: true
result: "{value}"
```
---
### 7. Path Variable
```yaml
artifacts_folder:
prompt: "Where should artifacts be stored?"
default: "{output_folder}/artifacts"
result: "{project-root}/{value}"
```
---
## Variable Inheritance / Aliasing
Create an alias for another variable:
```yaml
primary_artifacts:
prompt: "Where should primary artifacts be stored?"
default: "{output_folder}/artifacts"
result: "{project-root}/{value}"
# Alias for workflow compatibility
sprint_artifacts:
inherit: "primary_artifacts"
```
Now `sprint_artifacts` and `primary_artifacts` reference the same value.
---
## How Variables Become Available
### To Agents
After installation, variables are available in agent frontmatter/context:
```yaml
# In agent.agent.yaml or workflow execution
{variable_name} # Expands to the user's configured value
```
**Example:** If the user configured `project_name: "MyApp"`, agents can reference `{project_name}` and it will expand to `"MyApp"`.
### To Workflows
Workflows can reference module variables in their step files:
```yaml
---
outputFile: '{implementation_artifacts}/my-output.md'
---
```
This expands the `implementation_artifacts` variable from module.yaml.
---
## Real-World Examples
### BMM (BMad Method) — Complex Configuration
```yaml
code: bmm
name: "BMM: BMad Method Agile-AI Driven-Development"
header: "BMad Method™: Breakthrough Method of Agile-Ai Driven-Dev"
subheader: "Agent and Workflow Configuration for this module"
default_selected: true
# Variables from Core Config inserted:
## user_name
## communication_language
## document_output_language
## output_folder
project_name:
prompt: "What is the title of your project?"
default: "{directory_name}"
result: "{value}"
user_skill_level:
prompt:
- "What is your development experience level?"
- "This affects how agents explain concepts."
default: "intermediate"
result: "{value}"
single-select:
- value: "beginner"
label: "Beginner - Explain concepts clearly"
- value: "intermediate"
label: "Intermediate - Balanced approach"
- value: "expert"
label: "Expert - Direct and technical"
planning_artifacts:
prompt: "Where should planning artifacts be stored?"
default: "{output_folder}/planning-artifacts"
result: "{project-root}/{value}"
implementation_artifacts:
prompt: "Where should implementation artifacts be stored?"
default: "{output_folder}/implementation-artifacts"
result: "{project-root}/{value}"
project_knowledge:
prompt: "Where should project knowledge be stored?"
default: "docs"
result: "{project-root}/{value}"
tea_use_mcp_enhancements:
prompt: "Enable MCP enhancements in Test Architect?"
default: false
result: "{value}"
```
---
### CIS (Creative Innovation Suite) — Minimal Configuration
```yaml
code: cis
name: "CIS: Creative Innovation Suite"
header: "Creative Innovation Suite (CIS) Module"
subheader: "No custom configuration - uses Core settings only"
default_selected: false
# Variables from Core Config inserted:
## user_name
## communication_language
## document_output_language
## output_folder
```
Some modules don't need custom variables — core config is enough!
---
### BMGD (Game Development) — Multi-Select Example
```yaml
code: bmgd
name: "BMGD: BMad Game Development"
header: "BMad Game Development Module"
subheader: "Configure game development settings"
default_selected: false
project_name:
prompt: "What is the name of your game project?"
default: "{directory_name}"
result: "{value}"
primary_platform:
prompt: "Which game engine do you use?"
default: ["unity", "unreal"]
required: true
result: "{value}"
multi-select:
- value: "unity"
label: "Unity"
- value: "unreal"
label: "Unreal Engine"
- value: "godot"
label: "Godot"
- value: "other"
label: "Custom / Other"
```
---
## Best Practices
### DO:
- Keep prompts clear and concise
- Provide sensible defaults
- Use `result: "{project-root}/{value}"` for paths
- Use single/multi-select for structured choices
- Group related variables logically
### DON'T:
- Overwhelm users with too many questions
- Ask for information that could be inferred
- Use technical jargon in prompts
- Create variables that are never used
---
## Variable Naming
- **kebab-case** (e.g., `planning_artifacts`, `user_skill_level`)
- Descriptive but concise
- Avoid conflicts with core variables
---
## Testing Your module.yaml
After creating module.yaml, test it:
1. Run `bmad install` in a test project
2. Verify prompts appear correctly
3. Check that variables expand in agents/workflows
4. Test default values
5. Validate path templates resolve correctly
---
## Quick Reference
| Pattern | Use Case |
|---------|----------|
| Simple text input | Names, titles, descriptions |
| Boolean/Flag | Enable/disable features |
| Single select | Experience levels, categories |
| Multi select | Platforms, frameworks, options |
| Multi-line prompt | Complex questions needing context |
| Required | Must-have information |
| Path variable | Directory locations |
| Inherit/Alias | Compatibility, references |

View File

@@ -0,0 +1,392 @@
# module.yaml Conventions
**Purpose:** Defines how module.yaml works, including variables, templates, and how they provide context to agents and workflows.
---
## Overview
`module.yaml` is the configuration file for a BMAD module. It:
- Defines module metadata (code, name, description)
- Collects user input via prompts during installation
- Makes those inputs available to agents and workflows as variables
- Specifies which module should be selected by default
---
## Frontmatter Fields
### Required Fields
```yaml
code: {module-code} # kebab-case identifier
name: "Display Name" # Human-readable name
header: "Brief description" # One-line summary
subheader: "Additional context" # More detail
default_selected: false # Auto-select on install?
```
### `default_selected` Guidelines
| Module Type | default_selected | Example |
|-------------|------------------|---------|
| Core/Primary | `true` | BMM (agile software delivery) |
| Specialized | `false` | CIS (creative innovation), BMGD (game dev) |
| Experimental | `false` | New modules in development |
---
## Variables System
### Core Config Variables (Always Available)
These variables are automatically available to ALL modules:
```yaml
# Variables from Core Config inserted:
## user_name # User's name
## communication_language # Preferred language
## document_output_language # Output document language
## output_folder # Default output location
```
No need to define these — they're injected automatically.
---
### Custom Variables
Define custom variables for user input:
```yaml
variable_name:
prompt: "Question to ask the user?"
default: "{default_value}"
result: "{template_for_final_value}"
```
**Example:**
```yaml
project_name:
prompt: "What is the title of your project?"
default: "{directory_name}"
result: "{value}"
```
### Variable Templates
In `prompt` and `result`, you can use templates:
| Template | Expands To |
|----------|------------|
| `{value}` | The user's input |
| `{directory_name}` | Current directory name |
| `{output_folder}` | Output folder from core config |
| `{project-root}` | Project root path |
| `{variable_name}` | Another variable's value |
---
## Variable Types
### 1. Simple Text Input
```yaml
project_name:
prompt: "What is the title of your project?"
default: "{directory_name}"
result: "{value}"
```
---
### 2. Boolean/Flag
```yaml
enable_feature:
prompt: "Enable this feature?"
default: false
result: "{value}"
```
---
### 3. Single Select
```yaml
skill_level:
prompt: "What is your experience level?"
default: "intermediate"
result: "{value}"
single-select:
- value: "beginner"
label: "Beginner - Explains concepts clearly"
- value: "intermediate"
label: "Intermediate - Balanced approach"
- value: "expert"
label: "Expert - Direct and technical"
```
---
### 4. Multi Select
```yaml
platforms:
prompt: "Which platforms do you need?"
default: ["unity", "unreal"]
result: "{value}"
multi-select:
- value: "unity"
label: "Unity"
- value: "unreal"
label: "Unreal Engine"
- value: "godot"
label: "Godot"
```
---
### 5. Multi-Line Prompt
```yaml
complex_variable:
prompt:
- "First question?"
- "Second context?"
- "Third detail?"
default: "default_value"
result: "{value}"
```
---
### 6. Required Variable
```yaml
critical_variable:
prompt: "Required information:"
required: true
result: "{value}"
```
---
### 7. Path Variable
```yaml
artifacts_folder:
prompt: "Where should artifacts be stored?"
default: "{output_folder}/artifacts"
result: "{project-root}/{value}"
```
---
## Variable Inheritance / Aliasing
Create an alias for another variable:
```yaml
primary_artifacts:
prompt: "Where should primary artifacts be stored?"
default: "{output_folder}/artifacts"
result: "{project-root}/{value}"
# Alias for workflow compatibility
sprint_artifacts:
inherit: "primary_artifacts"
```
Now `sprint_artifacts` and `primary_artifacts` reference the same value.
---
## How Variables Become Available
### To Agents
After installation, variables are available in agent frontmatter/context:
```yaml
# In agent.agent.yaml or workflow execution
{variable_name} # Expands to the user's configured value
```
**Example:** If the user configured `project_name: "MyApp"`, agents can reference `{project_name}` and it will expand to `"MyApp"`.
### To Workflows
Workflows can reference module variables in their step files:
```yaml
---
outputFile: '{implementation_artifacts}/my-output.md'
---
```
This expands the `implementation_artifacts` variable from module.yaml.
---
## Real-World Examples
### BMM (BMad Method) — Complex Configuration
```yaml
code: bmm
name: "BMM: BMad Method Agile-AI Driven-Development"
header: "BMad Method™: Breakthrough Method of Agile-Ai Driven-Dev"
subheader: "Agent and Workflow Configuration for this module"
default_selected: true
# Variables from Core Config inserted:
## user_name
## communication_language
## document_output_language
## output_folder
project_name:
prompt: "What is the title of your project?"
default: "{directory_name}"
result: "{value}"
user_skill_level:
prompt:
- "What is your development experience level?"
- "This affects how agents explain concepts."
default: "intermediate"
result: "{value}"
single-select:
- value: "beginner"
label: "Beginner - Explain concepts clearly"
- value: "intermediate"
label: "Intermediate - Balanced approach"
- value: "expert"
label: "Expert - Direct and technical"
planning_artifacts:
prompt: "Where should planning artifacts be stored?"
default: "{output_folder}/planning-artifacts"
result: "{project-root}/{value}"
implementation_artifacts:
prompt: "Where should implementation artifacts be stored?"
default: "{output_folder}/implementation-artifacts"
result: "{project-root}/{value}"
project_knowledge:
prompt: "Where should project knowledge be stored?"
default: "docs"
result: "{project-root}/{value}"
tea_use_mcp_enhancements:
prompt: "Enable MCP enhancements in Test Architect?"
default: false
result: "{value}"
```
---
### CIS (Creative Innovation Suite) — Minimal Configuration
```yaml
code: cis
name: "CIS: Creative Innovation Suite"
header: "Creative Innovation Suite (CIS) Module"
subheader: "No custom configuration - uses Core settings only"
default_selected: false
# Variables from Core Config inserted:
## user_name
## communication_language
## document_output_language
## output_folder
```
Some modules don't need custom variables — core config is enough!
---
### BMGD (Game Development) — Multi-Select Example
```yaml
code: bmgd
name: "BMGD: BMad Game Development"
header: "BMad Game Development Module"
subheader: "Configure game development settings"
default_selected: false
project_name:
prompt: "What is the name of your game project?"
default: "{directory_name}"
result: "{value}"
primary_platform:
prompt: "Which game engine do you use?"
default: ["unity", "unreal"]
required: true
result: "{value}"
multi-select:
- value: "unity"
label: "Unity"
- value: "unreal"
label: "Unreal Engine"
- value: "godot"
label: "Godot"
- value: "other"
label: "Custom / Other"
```
---
## Best Practices
### DO:
- Keep prompts clear and concise
- Provide sensible defaults
- Use `result: "{project-root}/{value}"` for paths
- Use single/multi-select for structured choices
- Group related variables logically
### DON'T:
- Overwhelm users with too many questions
- Ask for information that could be inferred
- Use technical jargon in prompts
- Create variables that are never used
---
## Variable Naming
- **kebab-case** (e.g., `planning_artifacts`, `user_skill_level`)
- Descriptive but concise
- Avoid conflicts with core variables
---
## Testing Your module.yaml
After creating module.yaml, test it:
1. Run `bmad install` in a test project
2. Verify prompts appear correctly
3. Check that variables expand in agents/workflows
4. Test default values
5. Validate path templates resolve correctly
---
## Quick Reference
| Pattern | Use Case |
|---------|----------|
| Simple text input | Names, titles, descriptions |
| Boolean/Flag | Enable/disable features |
| Single select | Experience levels, categories |
| Multi select | Platforms, frameworks, options |
| Multi-line prompt | Complex questions needing context |
| Required | Must-have information |
| Path variable | Directory locations |
| Inherit/Alias | Compatibility, references |

View File

@@ -0,0 +1,254 @@
---
name: module-help-generate
description: Generate or update module-help.csv for any BMad module with proper structure
web_bundle: false
# Path variables (to be set by caller)
modulePath: '{module_path}'
moduleYamlFile: '{module_path}/module.yaml'
moduleHelpCsvFile: '{module_path}/module-help.csv'
workflowsDir: '{module_path}/workflows'
agentsDir: '{module_path}/agents'
---
# Module Help CSV Generator
**Goal:** Generate or update a `module-help.csv` file that serves as the central registry for all module functionality - workflows, agents, and commands.
**Your Role:** You are a Module Documentation Architect. You will analyze a module's structure and create a properly formatted CSV that enables discoverability and CLI integration.
---
## CRITICAL RULES (NO EXCEPTIONS)
- ALWAYS read existing `module-help.csv` first if it exists - update/validate rather than replace
- ALWAYS read `module.yaml` to get module code and type
- ALWAYS read ALL agent `.yaml` files to understand menu triggers
- ALWAYS read ALL workflow `workflow.md` files to understand purpose
- ALWAYS place `anytime` entries at the TOP with EMPTY sequence
- ALWAYS place phased entries BELOW anytime entries
- ALWAYS number phases starting at `-1` (phase-1, phase-2, phase-3...)
- ALWAYS leave sequence EMPTY for `anytime` entries (user chooses, not ordered)
- ALWAYS include sequence number for phased entries (defines order within phase)
- ALWAYS use EMPTY `workflow-file` for agent-only menu triggers
- ALWAYS include `agent` column for agent-based features
- NEVER assume workflow paths - verify from actual file structure
- ALWAYS search for and put the file at the root of the module ONLY
---
## CSV STRUCTURE (13 columns)
```
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
```
| Column | Purpose | Rules |
|--------|---------|-------|
| `module` | Module code from `module.yaml` | Required |
| `phase` | `anytime` or `phase-1`, `phase-2`, etc. | Phases start at -1 |
| `name` | Display name of the feature | User-facing |
| `code` | Short code for commands | Unique within module |
| `sequence` | Order within phase | EMPTY for anytime, number for phases |
| `workflow-file` | Path to workflow.md | EMPTY for agent-only |
| `command` | Internal command name | Format: `{module_code}_{feature_code}` |
| `required` | Whether required | Usually `false` |
| `agent` | Associated agent name | From agent YAML metadata |
| `options` | Mode or action type | e.g., "Create Mode", "Chat Mode" |
| `description` | User-facing description | Explain what and when to use |
| `output-location` | Where output goes | Folder name or EMPTY |
| `outputs` | What is produced | Output type or EMPTY |
---
## PHASE AND SEQUENCING RULES
### 1. anytime
- Use for: standalone features, agent menu triggers, unrelated utilities
- Place at TOP of file
- `sequence` column MUST BE EMPTY
- User chooses what to run - no order
### 2. Phases (phase-1, phase-2, phase-3...)
- Use for: sequential workflows, guided processes
- Place BELOW anytime entries
- Phases ALWAYS start at `-1` (not 0 or 1)
- `sequence` defines order WITHIN phase (10, 20, 30...)
- the name can be named differently than just phase but should be dash number at the end if sequence is needed
### 3. Module Integration Patterns
**Full module with phases:**
```
anytime entries (sequence empty)
phase-1 entries (sequence 10, 20, 30...)
phase-2 entries (sequence 10, 20, 30...)
```
**Add-on to existing module:**
```
May only have phase-3 entries that integrate into another module's workflow
Sequence numbers fit logically before/after existing items
```
**Standalone collections:**
```
All entries are anytime
No sequence numbers
User picks one as needed
```
**Agent-only features:**
```
Empty workflow-file column
Agent handles everything via its menu
```
---
## EXECUTION SEQUENCE
### Step 1: Identify Target Module
Ask user:
1. What is the path to the module?
2. Or should we scan for modules in the workspace?
### Step 2: Read Module Configuration
Load and read:
```
{moduleYamlFile}
```
Extract:
- `code` - Module identifier
- `type` - Module type
- `name` - Module display name
### Step 3: Check for Existing module-help.csv
Check if exists:
```
{moduleHelpCsvFile}
```
**If exists:**
- Read entire file
- Parse all existing entries
- Ask user: Update existing, validate, or regenerate?
**If not exists:**
- Note: Will create new file
- Proceed to discovery
### Step 4: Discover All Workflows
Scan the workflows directory:
```
{workflowsDir}
```
For each workflow found:
- Read the `workflow.md` file
- Extract: name, description, goal, role
- Note the relative path for CSV entry
### Step 5: Discover All Agents
Scan the agents directory:
```
{agentsDir}
```
For each agent found:
- Read the `.agent.yaml` file
- Extract: metadata (name, title), persona, menu triggers
- Identify agent-only triggers (no workflow route)
- Identify workflow-routing triggers
### Step 6: Determine Phasing Strategy
Analyze the module and decide:
**Question for each workflow:**
- Is this part of a sequential journey? → Use phases
- Is this standalone/optional? → Use anytime
- Can user do this anytime? → Use anytime
**For agent menu items:**
- Does it route to a workflow? → Map to that workflow or anytime
- Is it an inline action? → anytime, no workflow file
### Step 7: Generate CSV Content
Build the CSV following structure:
**Header:**
```
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
```
**Entry Rules:**
1. ALL `anytime` entries FIRST - `sequence` EMPTY
2. THEN phased entries - `phase-1`, `phase-2`, etc.
3. Within phases, `sequence` orders execution (10, 20, 30...)
4. Agent-only actions: empty `workflow-file`, specify `agent`
**Code Format:**
- Command: `{module_code}_{feature_name}`
- Keep codes short but memorable (2-3 letters usually)
**Description Guidance:**
- Explain WHAT the feature does
- Include WHEN to use it (especially for phased items)
- For add-on modules: "Best used after X but before Y"
### Step 8: Present to User
Before writing:
1. Show the CSV content in a readable table format
2. Explain phasing decisions
3. Highlight any agent-only entries
4. Ask for confirmation or adjustments
### Step 9: Write File
On confirmation:
```
Write to: {moduleHelpCsvFile}
```
---
## EXAMPLE OUTPUT STRUCTURE
### Full Module with Phases (like mwm):
```csv
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
mwm,anytime,Chat with Wellness,CWC,,"mwm_chat",false,wellness-companion,Chat Mode,"Have a supportive conversation anytime",,,
mwm,anytime,Quick Breathing,QB,,"mwm_breathing",false,meditation-guide,Breathing,"Quick 4-7-8 breathing exercise",,,
mwm,phase-1,Daily Check In,DCI,10,_bmad/mwm/workflows/daily-checkin/workflow.md,mwm_daily_checkin,false,wellness-companion,Check In Mode,"Start your day with wellness check-in",mwm_output,"summary",
mwm,phase-2,Wellness Journal,WJ,20,_bmad/mwm/workflows/wellness-journal/workflow.md,mwm_journal,false,wellness-companion,Journal Mode,"Reflect and track your wellness journey",mwm_output,"entry",
```
### Standalone Module (like bmad-custom):
```csv
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
bmad-custom,anytime,Quiz Master,QM,,"bmad_quiz",false,,Trivia,"Interactive trivia quiz with gameshow atmosphere",bmad_output,"results",
bmad-custom,anytime,Wassup,WS,,"bmad_wassup",false,,Status,"Check uncommitted changes and suggest commits",bmad_output,"summary",
bmad-custom,anytime,Write Commit,WC,,"bmad_write_commit",false,commit-poet,Write,"Craft a commit message from your changes",bmad_output,"message",
```
---
## INITIALIZATION
To begin this workflow:
1. Ask user for the target module path if not provided
2. Load and read `module.yaml` in the root of the target if it exists
3. Check for existing `module-help.csv`
4. Scan for all workflows and agents
5. Generate CSV following all rules above
6. Update the file and review with the user - never auto commit and push

View File

@@ -0,0 +1,254 @@
---
name: module-help-generate
description: Generate or update module-help.csv for any BMad module with proper structure
web_bundle: false
# Path variables (to be set by caller)
modulePath: '{module_path}'
moduleYamlFile: '{module_path}/module.yaml'
moduleHelpCsvFile: '{module_path}/module-help.csv'
workflowsDir: '{module_path}/workflows'
agentsDir: '{module_path}/agents'
---
# Module Help CSV Generator
**Goal:** Generate or update a `module-help.csv` file that serves as the central registry for all module functionality - workflows, agents, and commands.
**Your Role:** You are a Module Documentation Architect. You will analyze a module's structure and create a properly formatted CSV that enables discoverability and CLI integration.
---
## CRITICAL RULES (NO EXCEPTIONS)
- ALWAYS read existing `module-help.csv` first if it exists - update/validate rather than replace
- ALWAYS read `module.yaml` to get module code and type
- ALWAYS read ALL agent `.yaml` files to understand menu triggers
- ALWAYS read ALL workflow `workflow.md` files to understand purpose
- ALWAYS place `anytime` entries at the TOP with EMPTY sequence
- ALWAYS place phased entries BELOW anytime entries
- ALWAYS number phases starting at `-1` (phase-1, phase-2, phase-3...)
- ALWAYS leave sequence EMPTY for `anytime` entries (user chooses, not ordered)
- ALWAYS include sequence number for phased entries (defines order within phase)
- ALWAYS use EMPTY `workflow-file` for agent-only menu triggers
- ALWAYS include `agent` column for agent-based features
- NEVER assume workflow paths - verify from actual file structure
- ALWAYS search for and put the file at the root of the module ONLY
---
## CSV STRUCTURE (13 columns)
```
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
```
| Column | Purpose | Rules |
|--------|---------|-------|
| `module` | Module code from `module.yaml` | Required |
| `phase` | `anytime` or `phase-1`, `phase-2`, etc. | Phases start at -1 |
| `name` | Display name of the feature | User-facing |
| `code` | Short code for commands | Unique within module |
| `sequence` | Order within phase | EMPTY for anytime, number for phases |
| `workflow-file` | Path to workflow.md | EMPTY for agent-only |
| `command` | Internal command name | Format: `{module_code}_{feature_code}` |
| `required` | Whether required | Usually `false` |
| `agent` | Associated agent name | From agent YAML metadata |
| `options` | Mode or action type | e.g., "Create Mode", "Chat Mode" |
| `description` | User-facing description | Explain what and when to use |
| `output-location` | Where output goes | Folder name or EMPTY |
| `outputs` | What is produced | Output type or EMPTY |
---
## PHASE AND SEQUENCING RULES
### 1. anytime
- Use for: standalone features, agent menu triggers, unrelated utilities
- Place at TOP of file
- `sequence` column MUST BE EMPTY
- User chooses what to run - no order
### 2. Phases (phase-1, phase-2, phase-3...)
- Use for: sequential workflows, guided processes
- Place BELOW anytime entries
- Phases ALWAYS start at `-1` (not 0 or 1)
- `sequence` defines order WITHIN phase (10, 20, 30...)
- the name can be named differently than just phase but should be dash number at the end if sequence is needed
### 3. Module Integration Patterns
**Full module with phases:**
```
anytime entries (sequence empty)
phase-1 entries (sequence 10, 20, 30...)
phase-2 entries (sequence 10, 20, 30...)
```
**Add-on to existing module:**
```
May only have phase-3 entries that integrate into another module's workflow
Sequence numbers fit logically before/after existing items
```
**Standalone collections:**
```
All entries are anytime
No sequence numbers
User picks one as needed
```
**Agent-only features:**
```
Empty workflow-file column
Agent handles everything via its menu
```
---
## EXECUTION SEQUENCE
### Step 1: Identify Target Module
Ask user:
1. What is the path to the module?
2. Or should we scan for modules in the workspace?
### Step 2: Read Module Configuration
Load and read:
```
{moduleYamlFile}
```
Extract:
- `code` - Module identifier
- `type` - Module type
- `name` - Module display name
### Step 3: Check for Existing module-help.csv
Check if exists:
```
{moduleHelpCsvFile}
```
**If exists:**
- Read entire file
- Parse all existing entries
- Ask user: Update existing, validate, or regenerate?
**If not exists:**
- Note: Will create new file
- Proceed to discovery
### Step 4: Discover All Workflows
Scan the workflows directory:
```
{workflowsDir}
```
For each workflow found:
- Read the `workflow.md` file
- Extract: name, description, goal, role
- Note the relative path for CSV entry
### Step 5: Discover All Agents
Scan the agents directory:
```
{agentsDir}
```
For each agent found:
- Read the `.agent.yaml` file
- Extract: metadata (name, title), persona, menu triggers
- Identify agent-only triggers (no workflow route)
- Identify workflow-routing triggers
### Step 6: Determine Phasing Strategy
Analyze the module and decide:
**Question for each workflow:**
- Is this part of a sequential journey? → Use phases
- Is this standalone/optional? → Use anytime
- Can user do this anytime? → Use anytime
**For agent menu items:**
- Does it route to a workflow? → Map to that workflow or anytime
- Is it an inline action? → anytime, no workflow file
### Step 7: Generate CSV Content
Build the CSV following structure:
**Header:**
```
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
```
**Entry Rules:**
1. ALL `anytime` entries FIRST - `sequence` EMPTY
2. THEN phased entries - `phase-1`, `phase-2`, etc.
3. Within phases, `sequence` orders execution (10, 20, 30...)
4. Agent-only actions: empty `workflow-file`, specify `agent`
**Code Format:**
- Command: `{module_code}_{feature_name}`
- Keep codes short but memorable (2-3 letters usually)
**Description Guidance:**
- Explain WHAT the feature does
- Include WHEN to use it (especially for phased items)
- For add-on modules: "Best used after X but before Y"
### Step 8: Present to User
Before writing:
1. Show the CSV content in a readable table format
2. Explain phasing decisions
3. Highlight any agent-only entries
4. Ask for confirmation or adjustments
### Step 9: Write File
On confirmation:
```
Write to: {moduleHelpCsvFile}
```
---
## EXAMPLE OUTPUT STRUCTURE
### Full Module with Phases (like mwm):
```csv
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
mwm,anytime,Chat with Wellness,CWC,,"mwm_chat",false,wellness-companion,Chat Mode,"Have a supportive conversation anytime",,,
mwm,anytime,Quick Breathing,QB,,"mwm_breathing",false,meditation-guide,Breathing,"Quick 4-7-8 breathing exercise",,,
mwm,phase-1,Daily Check In,DCI,10,_bmad/mwm/workflows/daily-checkin/workflow.md,mwm_daily_checkin,false,wellness-companion,Check In Mode,"Start your day with wellness check-in",mwm_output,"summary",
mwm,phase-2,Wellness Journal,WJ,20,_bmad/mwm/workflows/wellness-journal/workflow.md,mwm_journal,false,wellness-companion,Journal Mode,"Reflect and track your wellness journey",mwm_output,"entry",
```
### Standalone Module (like bmad-custom):
```csv
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
bmad-custom,anytime,Quiz Master,QM,,"bmad_quiz",false,,Trivia,"Interactive trivia quiz with gameshow atmosphere",bmad_output,"results",
bmad-custom,anytime,Wassup,WS,,"bmad_wassup",false,,Status,"Check uncommitted changes and suggest commits",bmad_output,"summary",
bmad-custom,anytime,Write Commit,WC,,"bmad_write_commit",false,commit-poet,Write,"Craft a commit message from your changes",bmad_output,"message",
```
---
## INITIALIZATION
To begin this workflow:
1. Ask user for the target module path if not provided
2. Load and read `module.yaml` in the root of the target if it exists
3. Check for existing `module-help.csv`
4. Scan for all workflows and agents
5. Generate CSV following all rules above
6. Update the file and review with the user - never auto commit and push

View File

@@ -0,0 +1,147 @@
---
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.

View File

@@ -0,0 +1,147 @@
---
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.

View File

@@ -0,0 +1,140 @@
---
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.

View File

@@ -0,0 +1,140 @@
---
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.

View File

@@ -0,0 +1,148 @@
---
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.

View File

@@ -0,0 +1,148 @@
---
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.

View File

@@ -0,0 +1,82 @@
---
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

View File

@@ -0,0 +1,82 @@
---
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

View File

@@ -0,0 +1,96 @@
---
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")

View File

@@ -0,0 +1,96 @@
---
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")

View File

@@ -0,0 +1,85 @@
---
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

View File

@@ -0,0 +1,85 @@
---
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

View File

@@ -0,0 +1,75 @@
---
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

View File

@@ -0,0 +1,75 @@
---
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

View File

@@ -0,0 +1,96 @@
---
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)

View File

@@ -0,0 +1,96 @@
---
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)

View File

@@ -0,0 +1,82 @@
---
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

View File

@@ -0,0 +1,82 @@
---
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

View File

@@ -0,0 +1,90 @@
---
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")

View File

@@ -0,0 +1,90 @@
---
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")

View File

@@ -0,0 +1,83 @@
---
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

View File

@@ -0,0 +1,83 @@
---
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

View File

@@ -0,0 +1,94 @@
---
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

View File

@@ -0,0 +1,94 @@
---
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

View File

@@ -0,0 +1,104 @@
---
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

View File

@@ -0,0 +1,104 @@
---
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

View File

@@ -0,0 +1,117 @@
---
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

View File

@@ -0,0 +1,117 @@
---
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

View File

@@ -0,0 +1,178 @@
---
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: '../data/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. Agent placeholder/spec files
4. Workflow placeholder/spec files
5. README.md and TODO.md
6. module-help.csv (generated from specs)
"**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.

View File

@@ -0,0 +1,178 @@
---
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: '../data/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. Agent placeholder/spec files
4. Workflow placeholder/spec files
5. README.md and TODO.md
6. module-help.csv (generated from specs)
"**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.

View File

@@ -0,0 +1,82 @@
---
name: 'step-01b-continue'
description: 'Handle workflow continuation for Create mode'
workflowFile: '../workflow-create-module.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-agents |
| step-04-agents | step-05-workflows |
| step-05-workflows | step-06-docs |
| step-06-docs | step-07-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

View File

@@ -0,0 +1,82 @@
---
name: 'step-01b-continue'
description: 'Handle workflow continuation for Create mode'
workflowFile: '../workflow-create-module.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-agents |
| step-04-agents | step-05-workflows |
| step-05-workflows | step-06-docs |
| step-06-docs | step-07-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

View File

@@ -0,0 +1,104 @@
---
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}
```
"**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/`
### 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/
✅ Build tracking updated

View File

@@ -0,0 +1,104 @@
---
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}
```
"**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/`
### 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/
✅ Build tracking updated

View File

@@ -0,0 +1,118 @@
---
name: 'step-03-config'
description: 'Generate module.yaml with install questions'
nextStepFile: './step-04-agents.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

View File

@@ -0,0 +1,118 @@
---
name: 'step-03-config'
description: 'Generate module.yaml with install questions'
nextStepFile: './step-04-agents.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

View File

@@ -0,0 +1,167 @@
---
name: 'step-04-agents'
description: 'Create agent placeholder/spec files'
nextStepFile: './step-05-workflows.md'
agentSpecTemplate: '../data/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 4: 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-04-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

View File

@@ -0,0 +1,167 @@
---
name: 'step-04-agents'
description: 'Create agent placeholder/spec files'
nextStepFile: './step-05-workflows.md'
agentSpecTemplate: '../data/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 4: 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-04-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

View File

@@ -0,0 +1,183 @@
---
name: 'step-05-workflows'
description: 'Create workflow placeholder/spec files'
nextStepFile: './step-06-docs.md'
workflowSpecTemplate: '../templates/workflow-spec-template.md'
buildTrackingFile: '{bmad_creations_output_folder}/modules/module-build-{module_code}.md'
targetLocation: '{build_tracking_targetLocation}'
---
# Step 5: 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-05-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

View File

@@ -0,0 +1,183 @@
---
name: 'step-05-workflows'
description: 'Create workflow placeholder/spec files'
nextStepFile: './step-06-docs.md'
workflowSpecTemplate: '../templates/workflow-spec-template.md'
buildTrackingFile: '{bmad_creations_output_folder}/modules/module-build-{module_code}.md'
targetLocation: '{build_tracking_targetLocation}'
---
# Step 5: 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-05-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

View File

@@ -0,0 +1,400 @@
---
name: 'step-06-docs'
description: 'Generate README.md, TODO.md, and docs/ folder'
nextStepFile: './step-07-complete.md'
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
targetLocation: '{build_tracking_targetLocation}'
---
# Step 6: 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/
```
---
## 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
- [ ] Verify all agents and workflows are discoverable
---
## 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-06-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

View File

@@ -0,0 +1,400 @@
---
name: 'step-06-docs'
description: 'Generate README.md, TODO.md, and docs/ folder'
nextStepFile: './step-07-complete.md'
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
targetLocation: '{build_tracking_targetLocation}'
---
# Step 6: 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/
```
---
## 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
- [ ] Verify all agents and workflows are discoverable
---
## 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-06-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

View File

@@ -0,0 +1,152 @@
---
name: 'step-07-complete'
description: 'Finalize, offer to run validation'
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
targetLocation: '{build_tracking_targetLocation}'
moduleHelpGenerateWorkflow: '../module-help-generate.md'
validationWorkflow: '../steps-v/step-01-validate.md'
moduleHelpCsvFile: '{build_tracking_targetLocation}/module-help.csv'
---
# Step 7: 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. Generate module-help.csv
"**🎯 Generating module-help.csv...**"
Load and execute the module-help-generate workflow:
```
{moduleHelpGenerateWorkflow}
```
**Set these variables before loading:**
- `modulePath: {targetLocation}`
- `moduleYamlFile: {targetLocation}/module.yaml`
- `moduleHelpCsvFile: {targetLocation}/module-help.csv`
- `workflowsDir: {targetLocation}/workflows`
- `agentsDir: {targetLocation}/agents`
**What this does:**
- Scans all workflows in `{workflowsDir}/`
- Scans all agents in `{agentsDir}/`
- Generates `{moduleHelpCsvFile}` with proper structure:
- `anytime` entries at top (no sequence)
- Phased entries below (phase-1, phase-2, etc.)
- Agent-only entries have empty `workflow-file`
**Wait for workflow completion** before proceeding.
### 2. 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 |
| Help Registry | 1 | module-help.csv |
| Documentation | 2 | README.md, TODO.md |
### 3. 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-agents', 'step-05-workflows', 'step-06-docs', 'step-07-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
✅ module-help.csv generated at module root
✅ Build tracking marked COMPLETE
✅ Summary presented to user
✅ Next steps clearly explained
✅ Validation offered (optional)

View File

@@ -0,0 +1,152 @@
---
name: 'step-07-complete'
description: 'Finalize, offer to run validation'
buildTrackingFile: '{bmb_creations_output_folder}/modules/module-build-{module_code}.md'
targetLocation: '{build_tracking_targetLocation}'
moduleHelpGenerateWorkflow: '../module-help-generate.md'
validationWorkflow: '../steps-v/step-01-validate.md'
moduleHelpCsvFile: '{build_tracking_targetLocation}/module-help.csv'
---
# Step 7: 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. Generate module-help.csv
"**🎯 Generating module-help.csv...**"
Load and execute the module-help-generate workflow:
```
{moduleHelpGenerateWorkflow}
```
**Set these variables before loading:**
- `modulePath: {targetLocation}`
- `moduleYamlFile: {targetLocation}/module.yaml`
- `moduleHelpCsvFile: {targetLocation}/module-help.csv`
- `workflowsDir: {targetLocation}/workflows`
- `agentsDir: {targetLocation}/agents`
**What this does:**
- Scans all workflows in `{workflowsDir}/`
- Scans all agents in `{agentsDir}/`
- Generates `{moduleHelpCsvFile}` with proper structure:
- `anytime` entries at top (no sequence)
- Phased entries below (phase-1, phase-2, etc.)
- Agent-only entries have empty `workflow-file`
**Wait for workflow completion** before proceeding.
### 2. 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 |
| Help Registry | 1 | module-help.csv |
| Documentation | 2 | README.md, TODO.md |
### 3. 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-agents', 'step-05-workflows', 'step-06-docs', 'step-07-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
✅ module-help.csv generated at module root
✅ Build tracking marked COMPLETE
✅ Summary presented to user
✅ Next steps clearly explained
✅ Validation offered (optional)

View File

@@ -0,0 +1,81 @@
---
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

View File

@@ -0,0 +1,81 @@
---
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

View File

@@ -0,0 +1,77 @@
---
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

View File

@@ -0,0 +1,77 @@
---
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

View File

@@ -0,0 +1,77 @@
---
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

View File

@@ -0,0 +1,77 @@
---
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

View File

@@ -0,0 +1,80 @@
---
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

View File

@@ -0,0 +1,80 @@
---
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

View File

@@ -0,0 +1,75 @@
---
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

View File

@@ -0,0 +1,75 @@
---
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

View File

@@ -0,0 +1,96 @@
---
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

View File

@@ -0,0 +1,96 @@
---
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

View File

@@ -0,0 +1,93 @@
---
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)
**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

View File

@@ -0,0 +1,93 @@
---
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)
**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

View File

@@ -0,0 +1,99 @@
---
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

View File

@@ -0,0 +1,99 @@
---
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

View File

@@ -0,0 +1,152 @@
---
name: 'step-04-agent-specs'
description: 'Validate agent specifications and built agents'
nextStepFile: './step-05-workflow-specs.md'
agentSpecTemplate: '../data/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

View File

@@ -0,0 +1,152 @@
---
name: 'step-04-agent-specs'
description: 'Validate agent specifications and built agents'
nextStepFile: './step-05-workflow-specs.md'
agentSpecTemplate: '../data/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

View File

@@ -0,0 +1,152 @@
---
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

View File

@@ -0,0 +1,152 @@
---
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

View File

@@ -0,0 +1,143 @@
---
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

View File

@@ -0,0 +1,143 @@
---
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

View File

@@ -0,0 +1,102 @@
---
name: 'step-07-installation'
description: 'Installation readiness check'
nextStepFile: './step-08-report.md'
moduleHelpGenerateWorkflow: '../module-help-generate.md'
validationReportOutput: '{validation_report_output}'
targetPath: '{validation_target_path}'
moduleHelpCsvFile: '{validation_target_path}/module-help.csv'
---
# 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 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
### 2. Check module-help.csv
**CRITICAL:** Every module must have `module-help.csv` at its root.
**Check:**
- [ ] `module-help.csv` exists at `{moduleHelpCsvFile}`
- [ ] Has valid header: `module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,`
- [ ] `anytime` entries at TOP with EMPTY sequence
- [ ] Phased entries BELOW anytime (phase-1, phase-2, etc.)
- [ ] Agent-only entries have EMPTY `workflow-file`
**If missing:**
- FAIL - Module is not ready for installation without help registry
- Suggest running `{moduleHelpGenerateWorkflow}`
### 3. 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
### 4. Record Results
Append to `{validationReportOutput}`:
```markdown
## Installation Readiness
**Status:** {PASS/FAIL/WARNINGS}
**Install Variables:** {count} variables
**Install Variables:** {count} variables
**Help Registry:** {present/missing} - {status}
**Ready to Install:** {yes/no}
**Issues Found:**
{list any issues}
```
### 5. Auto-Proceed
"**✓ Installation readiness check complete.**"
Proceeding to final report...
Load `{nextStepFile}`
---
## Success Metrics
✅ Installation readiness assessed
✅ module-help.csv presence and structure validated
✅ Module type compatibility checked
✅ Results recorded

View File

@@ -0,0 +1,102 @@
---
name: 'step-07-installation'
description: 'Installation readiness check'
nextStepFile: './step-08-report.md'
moduleHelpGenerateWorkflow: '../module-help-generate.md'
validationReportOutput: '{validation_report_output}'
targetPath: '{validation_target_path}'
moduleHelpCsvFile: '{validation_target_path}/module-help.csv'
---
# 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 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
### 2. Check module-help.csv
**CRITICAL:** Every module must have `module-help.csv` at its root.
**Check:**
- [ ] `module-help.csv` exists at `{moduleHelpCsvFile}`
- [ ] Has valid header: `module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,`
- [ ] `anytime` entries at TOP with EMPTY sequence
- [ ] Phased entries BELOW anytime (phase-1, phase-2, etc.)
- [ ] Agent-only entries have EMPTY `workflow-file`
**If missing:**
- FAIL - Module is not ready for installation without help registry
- Suggest running `{moduleHelpGenerateWorkflow}`
### 3. 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
### 4. Record Results
Append to `{validationReportOutput}`:
```markdown
## Installation Readiness
**Status:** {PASS/FAIL/WARNINGS}
**Install Variables:** {count} variables
**Install Variables:** {count} variables
**Help Registry:** {present/missing} - {status}
**Ready to Install:** {yes/no}
**Issues Found:**
{list any issues}
```
### 5. Auto-Proceed
"**✓ Installation readiness check complete.**"
Proceeding to final report...
Load `{nextStepFile}`
---
## Success Metrics
✅ Installation readiness assessed
✅ module-help.csv presence and structure validated
✅ Module type compatibility checked
✅ Results recorded

View File

@@ -0,0 +1,197 @@
---
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

View File

@@ -0,0 +1,197 @@
---
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

View File

@@ -0,0 +1,154 @@
# 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_

View File

@@ -0,0 +1,154 @@
# 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_

View File

@@ -0,0 +1,96 @@
# 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_

View File

@@ -0,0 +1,96 @@
# 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_

View File

@@ -0,0 +1,71 @@
---
name: create-module-brief
description: Create product brief for BMAD module development
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/module'
briefWorkflow: './steps-b/step-01-welcome.md'
---
# Create Module Brief
**Goal:** Collaboratively explore and design your module vision through creative discovery.
**Your Role:** You are the **Module Architect** — a specialist in BMAD module design. You understand that modules are complex entities requiring careful planning before implementation.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution.
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file
- **Just-In-Time Loading**: Only the current step file is in memory
- **Sequential Enforcement**: Sequence within the step files must be completed in order
- **State Tracking**: Document progress in output file frontmatter
- **Append-Only Building**: Build documents by appending content as directed
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue, only proceed when user selects 'C'
5. **SAVE STATE**: Update frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter when writing final output for a step
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** create mental todo lists from future steps
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with config `{communication_language}`
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml` and resolve:
- `project_name`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. Route to Brief Workflow
"**Brief Mode: Creating a module brief through exploratory, creative discovery.**"
Load, read completely, then execute `{briefWorkflow}` (steps-b/step-01-welcome.md)
---
## OUTPUT
**Brief mode produces:**
- `module-brief-{code}.md` — Complete module vision document

View File

@@ -0,0 +1,71 @@
---
name: create-module-brief
description: Create product brief for BMAD module development
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/module'
briefWorkflow: './steps-b/step-01-welcome.md'
---
# Create Module Brief
**Goal:** Collaboratively explore and design your module vision through creative discovery.
**Your Role:** You are the **Module Architect** — a specialist in BMAD module design. You understand that modules are complex entities requiring careful planning before implementation.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution.
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file
- **Just-In-Time Loading**: Only the current step file is in memory
- **Sequential Enforcement**: Sequence within the step files must be completed in order
- **State Tracking**: Document progress in output file frontmatter
- **Append-Only Building**: Build documents by appending content as directed
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue, only proceed when user selects 'C'
5. **SAVE STATE**: Update frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter when writing final output for a step
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** create mental todo lists from future steps
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with config `{communication_language}`
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml` and resolve:
- `project_name`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. Route to Brief Workflow
"**Brief Mode: Creating a module brief through exploratory, creative discovery.**"
Load, read completely, then execute `{briefWorkflow}` (steps-b/step-01-welcome.md)
---
## OUTPUT
**Brief mode produces:**
- `module-brief-{code}.md` — Complete module vision document

View File

@@ -0,0 +1,86 @@
---
name: create-module
description: Create a complete BMAD module with agents, workflows, and infrastructure
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/module'
createWorkflow: './steps-c/step-01-load-brief.md'
---
# Create Module
**Goal:** Build a complete, installable BMAD module from a module brief.
**Your Role:** You are the **Module Architect** — a specialist in BMAD module design and implementation. You transform module visions into fully structured, compliant modules.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution.
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file
- **Just-In-Time Loading**: Only the current step file is in memory
- **Sequential Enforcement**: Sequence within the step files must be completed in order
- **State Tracking**: Document progress in output file frontmatter
- **Append-Only Building**: Build documents by appending content as directed
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue, only proceed when user selects 'C'
5. **SAVE STATE**: Update frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter when writing final output for a step
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** create mental todo lists from future steps
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with config `{communication_language}`
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml` and resolve:
- `project_name`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. Route to Create Workflow
"**Create Mode: Building a complete BMAD module from a module brief.**"
Ask: "Where is the module brief? Please provide the path to the module-brief-{code}.md file."
Then load, read completely, and execute `{createWorkflow}` (steps-c/step-01-load-brief.md)
---
## CONFIGURATION
This workflow references:
- `{installed_path}/data/` — Module standards and templates
- `{installed_path}/templates/` — Output templates
---
## OUTPUT
**Create mode produces:**
- Module directory structure
- `module.yaml` with install configuration
- Agent placeholder/spec files
- Workflow placeholder/spec files
- `README.md` and `TODO.md`
- `module-help.csv` (generated from specs)

View File

@@ -0,0 +1,86 @@
---
name: create-module
description: Create a complete BMAD module with agents, workflows, and infrastructure
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/module'
createWorkflow: './steps-c/step-01-load-brief.md'
---
# Create Module
**Goal:** Build a complete, installable BMAD module from a module brief.
**Your Role:** You are the **Module Architect** — a specialist in BMAD module design and implementation. You transform module visions into fully structured, compliant modules.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution.
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file
- **Just-In-Time Loading**: Only the current step file is in memory
- **Sequential Enforcement**: Sequence within the step files must be completed in order
- **State Tracking**: Document progress in output file frontmatter
- **Append-Only Building**: Build documents by appending content as directed
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue, only proceed when user selects 'C'
5. **SAVE STATE**: Update frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter when writing final output for a step
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** create mental todo lists from future steps
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with config `{communication_language}`
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml` and resolve:
- `project_name`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. Route to Create Workflow
"**Create Mode: Building a complete BMAD module from a module brief.**"
Ask: "Where is the module brief? Please provide the path to the module-brief-{code}.md file."
Then load, read completely, and execute `{createWorkflow}` (steps-c/step-01-load-brief.md)
---
## CONFIGURATION
This workflow references:
- `{installed_path}/data/` — Module standards and templates
- `{installed_path}/templates/` — Output templates
---
## OUTPUT
**Create mode produces:**
- Module directory structure
- `module.yaml` with install configuration
- Agent placeholder/spec files
- Workflow placeholder/spec files
- `README.md` and `TODO.md`
- `module-help.csv` (generated from specs)

View File

@@ -0,0 +1,66 @@
---
name: edit-module
description: Edit existing BMAD modules while maintaining coherence
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/module'
editWorkflow: './steps-e/step-01-load-target.md'
---
# Edit Module
**Goal:** Modify existing BMAD module briefs or module structures while maintaining coherence and compliance.
**Your Role:** You are the **Module Architect** — a specialist in BMAD module design and maintenance. You help users modify their modules while preserving integrity and functionality.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution.
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file
- **Just-In-Time Loading**: Only the current step file is in memory
- **Sequential Enforcement**: Sequence within the step files must be completed in order
- **State Tracking**: Document progress in output file frontmatter
- **Append-Only Building**: Build documents by appending content as directed
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue, only proceed when user selects 'C'
5. **SAVE STATE**: Update frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter when writing final output for a step
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** create mental todo lists from future steps
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with config `{communication_language}`
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml` and resolve:
- `project_name`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. Route to Edit Workflow
"**Edit Mode: Modifying an existing BMAD module brief or module structure.**"
Ask: "What would you like to edit? Please provide the path to the module brief or module directory."
Then load, read completely, and execute `{editWorkflow}` (steps-e/step-01-assess.md)

View File

@@ -0,0 +1,66 @@
---
name: edit-module
description: Edit existing BMAD modules while maintaining coherence
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/module'
editWorkflow: './steps-e/step-01-load-target.md'
---
# Edit Module
**Goal:** Modify existing BMAD module briefs or module structures while maintaining coherence and compliance.
**Your Role:** You are the **Module Architect** — a specialist in BMAD module design and maintenance. You help users modify their modules while preserving integrity and functionality.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution.
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file
- **Just-In-Time Loading**: Only the current step file is in memory
- **Sequential Enforcement**: Sequence within the step files must be completed in order
- **State Tracking**: Document progress in output file frontmatter
- **Append-Only Building**: Build documents by appending content as directed
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue, only proceed when user selects 'C'
5. **SAVE STATE**: Update frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter when writing final output for a step
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** create mental todo lists from future steps
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with config `{communication_language}`
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml` and resolve:
- `project_name`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. Route to Edit Workflow
"**Edit Mode: Modifying an existing BMAD module brief or module structure.**"
Ask: "What would you like to edit? Please provide the path to the module brief or module directory."
Then load, read completely, and execute `{editWorkflow}` (steps-e/step-01-assess.md)

View File

@@ -0,0 +1,66 @@
---
name: validate-module
description: Run compliance check on BMAD modules against best practices
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/module'
validateWorkflow: './steps-v/step-01-validate.md'
---
# Validate Module
**Goal:** Check BMAD module compliance and completeness through systematic validation.
**Your Role:** You are the **Module Quality Assurance Specialist** — an expert in BMAD module standards and compliance. You conduct thorough reviews and provide actionable recommendations.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution.
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file
- **Just-In-Time Loading**: Only the current step file is in memory
- **Sequential Enforcement**: Sequence within the step files must be completed in order
- **State Tracking**: Document progress in output file frontmatter
- **Append-Only Building**: Build documents by appending content as directed
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue, only proceed when user selects 'C'
5. **SAVE STATE**: Update frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter when writing final output for a step
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** create mental todo lists from future steps
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with config `{communication_language}`
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml` and resolve:
- `project_name`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. Route to Validate Workflow
"**Validate Mode: Running compliance check on BMAD module.**"
Ask: "What would you like to validate? Please provide the path to the module brief or module directory."
Then load, read completely, and execute `{validateWorkflow}` (steps-v/step-01-validate.md)

View File

@@ -0,0 +1,66 @@
---
name: validate-module
description: Run compliance check on BMAD modules against best practices
web_bundle: true
installed_path: '{project-root}/_bmad/bmb/workflows/module'
validateWorkflow: './steps-v/step-01-validate.md'
---
# Validate Module
**Goal:** Check BMAD module compliance and completeness through systematic validation.
**Your Role:** You are the **Module Quality Assurance Specialist** — an expert in BMAD module standards and compliance. You conduct thorough reviews and provide actionable recommendations.
---
## WORKFLOW ARCHITECTURE
This uses **step-file architecture** for disciplined execution.
### Core Principles
- **Micro-file Design**: Each step is a self contained instruction file
- **Just-In-Time Loading**: Only the current step file is in memory
- **Sequential Enforcement**: Sequence within the step files must be completed in order
- **State Tracking**: Document progress in output file frontmatter
- **Append-Only Building**: Build documents by appending content as directed
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
4. **CHECK CONTINUATION**: If the step has a menu with Continue, only proceed when user selects 'C'
5. **SAVE STATE**: Update frontmatter before loading next step
6. **LOAD NEXT**: When directed, read fully and follow the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps or optimize the sequence
- 💾 **ALWAYS** update frontmatter when writing final output for a step
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** create mental todo lists from future steps
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with config `{communication_language}`
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml` and resolve:
- `project_name`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### 2. Route to Validate Workflow
"**Validate Mode: Running compliance check on BMAD module.**"
Ask: "What would you like to validate? Please provide the path to the module brief or module directory."
Then load, read completely, and execute `{validateWorkflow}` (steps-v/step-01-validate.md)