feat: implement reel improvements (clean text, deletion, mobile TTS)

This commit is contained in:
Michael committed 2026-02-13 10:11:04 +01:00
1 parent cb0ff8a0ea
commit dbddf3a74e
895 files changed
+26890 -93267

No files matched your search

@@ -0,0 +1,258 @@
# Agent Architecture
Single Agent type with `hasSidecar` boolean. `critical_actions` decoupled from sidecar.
## Decision Matrix: hasSidecar
| hasSidecar | Structure | Use When |
|------------|-----------|----------|
| `false` | Single YAML file (~250 lines) | Stateless, single-purpose, personality-driven |
| `true` | YAML + sidecar folder | Persistent memory, long-term tracking, relationship-driven |
---
## YAML Schema
```yaml
agent:
metadata:
id: _bmad/agents/{agent-name}/{agent-name}.md
name: 'Persona Name'
title: 'Agent Title'
icon: '<emoji>'
module: stand-alone # or bmm, cis, bmgd
persona:
role: | # First-person, 1-2 sentences
identity: | # Background, 2-5 sentences
communication_style: | # Voice, tone, mannerisms
principles: # Core beliefs
- Principle one
critical_actions: # Optional - activation behavior
- 'Load COMPLETE file {path}'
- 'ONLY read/write files in {path}'
prompts:
- id: prompt-id
content: |
<instructions>What it does</instructions>
<process>1. Step one 2. Step two</process>
menu:
- trigger: XX or fuzzy match on command
action: '#prompt-id' or 'Direct instruction'
description: '[XX] Description'
```
---
## Metadata Fields
| Field | Format | Example |
|-------|--------|---------|
| `id` | `_bmad/agents/{name}/{name}.md` | `_bmad/agents/commit-poet/commit-poet.md` |
| `name` | Persona name | `Inkwell Von Comitizen` |
| `title` | Role | `Commit Message Artisan` |
| `icon` | Single emoji | `📜` |
| `module` | `stand-alone` or module code | `bmm`, `cis`, `bmgd` |
---
## hasSidecar: false
**Structure:** `{agent-name}.agent.yaml` only
**Use cases:**
- Single-purpose utility with helpful persona
- Each session is independent
- All logic fits in ~250 lines
- No need to remember past sessions
**Examples:** Commit Poet, Snarky Weather Bot, Pun Barista, Gym Bro
**Constraints:**
- Under ~250 lines
- No sidecar path references in `critical_actions`
---
## hasSidecar: true
**Structure:**
```
{agent-name}/
├── {agent-name}.agent.yaml
└── {agent-name}-sidecar/
├── instructions.md
├── memories.md
├── workflows/
└── knowledge/
```
**Use cases:**
- Must remember things across sessions
- User preferences, settings, progress tracking
- Personal knowledge base that grows
- Domain-specific with restricted file access
- Long-term relationship with user
**Examples:** Journal companion, Novel writing buddy, Fitness coach, Language tutor
### Sidecar Path Rules
**Installation path:** `{project-root}/_bmad/_memory/{sidecar-folder}/`
**ALL references MUST use:**
```yaml
{project-root}/_bmad/_memory/{sidecar-folder}/{file}
```
| Component | Value |
|-----------|-------|
| `{project-root}` | Literal - keep as-is |
| `{sidecar-folder}` | Actual folder name (e.g., `journal-keeper-sidecar`) |
```yaml
# ✅ CORRECT
critical_actions:
- "Load COMPLETE file {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md"
- "ONLY read/write files in {project-root}/_bmad/_memory/journal-keeper-sidecar/"
# ❌ WRONG
critical_actions:
- "Load ./journal-keeper-sidecar/memories.md"
- "Load /Users/absolute/path/memories.md"
```
### Required critical_actions for Sidecar
```yaml
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
```
---
## Menu Actions
| Type | Format | Example |
|------|--------|---------|
| Prompt reference | `action: "#prompt-id"` | `action: "#write-commit"` |
| Inline instruction | `action: "text"` | `action: "Update memories.md"` |
**Trigger format:** `XX or fuzzy match on command`
**Description format:** `[XX] Description`
**Reserved codes:** MH, CH, PM, DA (auto-injected - do NOT use)
```yaml
menu:
- trigger: WC or fuzzy match on write
action: "#write-commit"
description: "[WC] Write commit message"
- trigger: SM or fuzzy match on save
action: "Update {project-root}/_bmad/_memory/{sidecar-folder}/memories.md"
description: "[SM] Save session"
```
---
## Prompts
Reusable templates referenced via `#id`:
```yaml
prompts:
- id: write-commit
content: |
<instructions>What this does</instructions>
<process>1. Step 2. Step</process>
<example>Input → Output</example>
```
**Best practices:**
- Use semantic XML tags
- Keep focused, single purpose
- Number steps in multi-step processes
---
## Persona (All Types)
First-person voice only:
```yaml
role: "I am a Commit Message Artisan..."
identity: "I understand commit messages are documentation..."
communication_style: "Poetic drama with flair..."
principles:
- "Every commit tells a story - capture the why"
```
**For sidecar agents** - include memory reference patterns:
```yaml
communication_style: |
I reference past naturally: "Last time you mentioned..." or "I've noticed patterns..."
```
---
## Domain Restriction Patterns
```yaml
# Single folder (most common)
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
# Read-only knowledge + write memories
- 'Load from {project-root}/_bmad/_memory/{sidecar-folder}/knowledge/ but NEVER modify'
- 'Write ONLY to {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
# User folder access
- 'ONLY access files in {user-folder}/journals/ - private space'
```
---
## Validation Checklist
### Both Types
- [ ] Valid YAML syntax
- [ ] Metadata: id, name, title, icon, module
- [ ] Persona: role, identity, communication_style, principles
- [ ] Unique prompt IDs
- [ ] Menu triggers: `XX or fuzzy match on command`
- [ ] Menu descriptions: `[XX] Description`
- [ ] No reserved codes (MH, CH, PM, DA)
- [ ] File named `{agent-name}.agent.yaml`
### hasSidecar: false
- [ ] Under ~250 lines
- [ ] No sidecar path references
### hasSidecar: true
- [ ] ALL paths: `{project-root}/_bmad/_memory/{sidecar-folder}/...`
- [ ] `{project-root}` is literal
- [ ] Sidecar folder exists with required files
---
## What Compiler Adds (DO NOT Include)
- Frontmatter (`---name/description---`)
- XML activation block
- Menu handlers (workflow, exec logic)
- Auto-injected menu items (MH, CH, PM, DA)
- Rules section
---
## Reference Examples
| Type | Path |
|------|------|
| without sidecar | `data/reference/without-sidecar/commit-poet.agent.yaml` |
| with sidecar | `data/reference/with-sidecar/journal-keeper/` |
@@ -1,28 +1,10 @@
# Agent Compilation: YAML Source → Final Agent
# Agent Compilation: YAML → Compiled
> **For the LLM running this workflow:** This document explains what the compiler adds. When building agents, focus on the YAML structure defined here—do NOT add things the compiler handles automatically.
>
> **Example reference:** Compare `{workflow_path}/data/reference/module-examples/architect.agent.yaml` (source, 32 lines) with `architect.md` (compiled, 69 lines) to see what the compiler adds.
**TL;DR:** Write minimal YAML → compiler adds frontmatter, activation XML, handlers, rules, MH/CH/PM/DA menu items.
---
## Quick Overview
You write: **YAML source file** (`agent-name.agent.yaml`)
Compiler produces: **Markdown with XML** (`agent-name.md`) for LLM consumption
The compiler transforms your clean YAML into a fully functional agent by adding:
- Frontmatter (name, description)
- XML activation block with numbered steps
- Menu handlers (workflow, exec, action)
- Auto-injected menu items (MH, CH, PM, DA)
- Rules section
---
## What YOU Provide (YAML Source)
Your YAML contains ONLY these sections:
## YAML Structure (YOU WRITE)
```yaml
agent:
@@ -31,7 +13,7 @@ agent:
name: "Persona Name"
title: "Agent Title"
icon: "🔧"
module: "stand-alone" or "bmm" or "cis" or "bmgd"
module: "stand-alone" | "bmm" | "cis" | "bmgd"
persona:
role: "First-person role description"
@@ -40,17 +22,17 @@ agent:
principles:
- "Core belief or methodology"
critical_actions: # Optional - for Expert agents only
- "Load ./sidecar/memories.md"
- "Load ./sidecar/instructions.md"
- "ONLY access ./sidecar/"
critical_actions: # Optional - ANY agent can have these
- "Load COMPLETE file {project-root}/_bmad/_memory/journal-sidecar/memories.md"
- "Load COMPLETE file {project-root}/_bmad/_memory/journal-sidecar/instructions.md"
- "ONLY read/write files in {project-root}/_bmad/_memory/journal-sidecar/"
prompts: # Optional - for Simple/Expert agents
prompts: # Optional - standalone agents
- id: prompt-name
content: |
<instructions>Prompt content</instructions>
menu: # Your custom items only
menu: # Custom items ONLY
- trigger: XX or fuzzy match on command-name
workflow: "path/to/workflow.yaml" # OR
exec: "path/to/file.md" # OR
@@ -60,36 +42,18 @@ agent:
---
## What COMPILER Adds (DO NOT Include)
## What Compiler Adds (DO NOT WRITE)
### 1. Frontmatter
```markdown
---
name: "architect"
description: "Architect"
---
```
**DO NOT add** frontmatter to your YAML.
| Component | Source |
|-----------|--------|
| Frontmatter (`---name/description---`) | Auto-generated |
| XML activation block with numbered steps | Auto-generated |
| critical_actions → activation steps | Injected as steps 4, 5, 6... |
| Menu handlers (workflow/exec/action) | Auto-detected |
| Rules section | Auto-generated |
| MH, CH, PM, DA menu items | Always injected |
### 2. XML Activation Block
```xml
<activation critical="MANDATORY">
<step n="1">Load persona from this current agent file</step>
<step n="2">Load config to get {user_name}, {communication_language}</step>
<step n="3">Remember: user's name is {user_name}</step>
<!-- YOUR critical_actions inserted here as steps 4, 5, etc. -->
<step n="N">ALWAYS communicate in {communication_language}</step>
<step n="N+1">Show greeting + numbered menu</step>
<step n="N+2">STOP and WAIT for user input</step>
<step n="N+3">Input resolution rules</step>
<menu-handlers>...</menu-handlers>
<rules>...</rules>
</activation>
```
**DO NOT create** activation sections—the compiler builds them.
### 3. Auto-Injected Menu Items
Every agent gets these 4 items automatically. **DO NOT add them to your YAML:**
### Auto-Injected Menu Items (NEVER add)
| Code | Trigger | Description |
|------|---------|-------------|
@@ -98,55 +62,10 @@ Every agent gets these 4 items automatically. **DO NOT add them to your YAML:**
| PM | party-mode | Start Party Mode |
| DA | exit, leave, goodbye, dismiss agent | Dismiss Agent |
### 4. Menu Handlers
```xml
<handler type="workflow">
When menu item has: workflow="path/to/workflow.yaml"
→ Load workflow.xml and execute with workflow-config parameter
</handler>
<handler type="exec">
When menu item has: exec="path/to/file.md"
→ Load and execute the file at that path
</handler>
```
**DO NOT add** handlers—the compiler detects and generates them.
---
## Before/After Example: Architect Agent
## Compiled Output Structure
### Source: `architect.agent.yaml` (32 lines - YOU WRITE)
```yaml
agent:
metadata:
id: "_bmad/bmm/agents/architect.md"
name: Winston
title: Architect
icon: 🏗️
module: bmm
persona:
role: System Architect + Technical Design Leader
identity: Senior architect with expertise in distributed systems...
communication_style: "Speaks in calm, pragmatic tones..."
principles: |
- User journeys drive technical decisions...
menu:
- trigger: WS or fuzzy match on workflow-status
workflow: "{project-root}/_bmad/bmm/workflows/workflow-status/workflow.yaml"
description: "[WS] Get workflow status..."
- trigger: CA or fuzzy match on create-architecture
exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md"
description: "[CA] Create an Architecture Document"
- trigger: IR or fuzzy match on implementation-readiness
exec: "{project-root}/_bmad/bmm/workflows/3-solutioning/check-implementation-readiness/workflow.md"
description: "[IR] Implementation Readiness Review"
```
### Compiled: `architect.md` (69 lines - COMPILER PRODUCES)
```markdown
---
name: "architect"
@@ -159,25 +78,26 @@ You must fully embody this agent's persona...
<agent id="architect.agent.yaml" name="Winston" title="Architect" icon="🏗️">
<activation critical="MANDATORY">
<step n="1">Load persona from this current agent file (already in context)</step>
<step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT...</step>
<step n="2">Load config to get {user_name}, {communication_language}</step>
<step n="3">Remember: user's name is {user_name}</step>
<step n="4">Show greeting using {user_name} from config...</step>
<step n="5">STOP and WAIT for user input...</step>
<step n="6">On user input: Number → execute menu item[n]...</step>
<step n="7">When executing a menu item: Check menu-handlers section...</step>
<!-- YOUR critical_actions inserted here as steps 4, 5, 6... -->
<step n="N">ALWAYS communicate in {communication_language}</step>
<step n="N+1">Show greeting + numbered menu</step>
<step n="N+2">STOP and WAIT for user input</step>
<menu-handlers>
<handlers>
<handler type="workflow">...</handler>
<handler type="exec">...</handler>
<handler type="workflow">Load workflow.xml and execute with workflow-config parameter</handler>
<handler type="exec">Load and execute the file at that path</handler>
<handler type="action">Execute prompt with matching id from prompts section</handler>
</handlers>
</menu-handlers>
<rules>
<r>ALWAYS communicate in {communication_language}</r>
<r>Stay in character until exit selected</r>
<r>Display Menu items as the item dictates...</r>
<r>Load files ONLY when executing menu items...</r>
<r>Display Menu items as the item dictates</r>
<r>Load files ONLY when executing menu items</r>
</rules>
</activation>
@@ -188,86 +108,78 @@ You must fully embody this agent's persona...
<principles>- User journeys drive technical decisions...</principles>
</persona>
<prompts>
<prompt id="prompt-name">
<instructions>Prompt content</instructions>
</prompt>
</prompts>
<menu>
<item cmd="MH or fuzzy match on menu or help">[MH] Redisplay Menu Help</item>
<item cmd="CH or fuzzy match on chat">[CH] Chat with the Agent about anything</item>
<item cmd="WS...">[WS] Get workflow status...</item> ← YOUR CUSTOM ITEMS
<item cmd="CA...">[CA] Create an Architecture Document</item>
<item cmd="IR...">[IR] Implementation Readiness Review</item>
<item cmd="PM...">[PM] Start Party Mode</item>
<item cmd="DA...">[DA] Dismiss Agent</item>
<!-- YOUR CUSTOM ITEMS HERE -->
<item cmd="PM or fuzzy match on party-mode">[PM] Start Party Mode</item>
<item cmd="DA or fuzzy match on exit leave goodbye dismiss agent">[DA] Dismiss Agent</item>
</menu>
</agent>
```
**Key additions by compiler:** Frontmatter, activation block, handlers, rules, MH/CH/PM/DA menu items.
---
## DO NOT DO Checklist
## critical_actions Injection
When building agent YAML, **DO NOT:**
Your `critical_actions` become numbered activation steps.
- [ ] Add frontmatter (`---name/description---`) to YAML
- [ ] Create activation blocks or XML sections
- [ ] Add MH (menu/help) menu item
- [ ] Add CH (chat) menu item
- [ ] Add PM (party-mode) menu item
- [ ] Add DA (dismiss/exit) menu item
- [ ] Add menu handlers (workflow/exec logic)
### With sidecar (hasSidecar: true):
```yaml
critical_actions:
- "Load COMPLETE file {project-root}/_bmad/_memory/journal-sidecar/memories.md"
- "Load COMPLETE file {project-root}/_bmad/_memory/journal-sidecar/instructions.md"
- "ONLY read/write files in {project-root}/_bmad/_memory/journal-sidecar/"
```
→ Injected as steps 4, 5, 6
### Without sidecar (hasSidecar: false):
```yaml
critical_actions:
- "Give user an inspirational quote before showing menu"
```
→ Injected as step 4
### No critical_actions:
Activation jumps directly from step 3 to "ALWAYS communicate in {communication_language}"
---
## DO NOT / DO Checklist
**DO NOT:**
- [ ] Add frontmatter
- [ ] Create activation/XML blocks
- [ ] Add MH/CH/PM/DA menu items
- [ ] Add menu handlers
- [ ] Add rules section
- [ ] Duplicate any auto-injected content
- [ ] Duplicate auto-injected content
**DO:**
- [ ] Define metadata (id, name, title, icon, module)
- [ ] Define persona (role, identity, communication_style, principles)
- [ ] Define critical_actions (Expert agents only)
- [ ] Define prompts with IDs (Simple/Expert agents only)
- [ ] Define menu with your custom items only
- [ ] Use proper trigger format: `XX or fuzzy match on command-name`
- [ ] Use proper description format: `[XX] Description text`
---
## Expert Agent: critical_actions
For Expert agents with sidecars, your `critical_actions` become activation steps:
```yaml
critical_actions:
- "Load COMPLETE file ./agent-sidecar/memories.md"
- "Load COMPLETE file ./agent-sidecar/instructions.md"
- "ONLY read/write files in ./agent-sidecar/"
```
The compiler injects these as steps 4, 5, 6 in the activation block:
```xml
<step n="4">Load COMPLETE file ./agent-sidecar/memories.md</step>
<step n="5">Load COMPLETE file ./agent-sidecar/instructions.md</step>
<step n="6">ONLY read/write files in ./agent-sidecar/</step>
<step n="7">ALWAYS communicate in {communication_language}</step>
```
- [ ] Define critical_actions (if activation behavior needed)
- [ ] Define prompts with IDs (standalone agents)
- [ ] Define menu with custom items only
- [ ] Use format: `XX or fuzzy match on command-name`
- [ ] Use description format: `[XX] Description text`
---
## Division of Responsibilities
| Aspect | YOU Provide (YAML) | COMPILER Adds |
|--------|-------------------|---------------|
| Aspect | YOU (YAML) | COMPILER |
|--------|------------|----------|
| Agent identity | metadata + persona | Wrapped in XML |
| Memory/actions | critical_actions | Inserted as activation steps |
| Prompts | prompts with IDs | Referenced by menu actions |
| Menu items | Your custom commands only | + MH, CH, PM, DA (auto) |
| Activation | — | Full XML block with handlers |
| Rules | — | Standardized rules section |
| Frontmatter | — | name/description header |
---
## Quick Reference for LLM
- **Focus on:** Clean YAML structure, persona definition, custom menu items
- **Ignore:** What happens after compilation—that's the compiler's job
- **Remember:** Every agent gets MH, CH, PM, DA automatically—don't add them
- **Expert agents:** Use `critical_actions` for sidecar file loading
- **Module agents:** Use `workflow:` or `exec:` references, not inline actions
| Activation steps | critical_actions | Inserted as steps 4+ |
| Prompts | prompts with IDs | Referenced by actions |
| Menu items | Custom only | + MH, CH, PM, DA |
| Activation block | — | Full XML with handlers |
| Rules | — | Standardized section |
| Frontmatter | — | name/description |
@@ -1,93 +1,72 @@
# Agent Menu Patterns
Technical reference for creating agent menu items in YAML.
---
## Menu Item Structure
Every menu item requires:
## Menu Item Schema
```yaml
- trigger: XX or fuzzy match on command-name
[handler]: [value]
description: '[XX] Display text here'
description: '[XX] Display text'
data: [optional] # Pass file to workflow
```
**Required fields:**
- `trigger` - Format: `XX or fuzzy match on command-name` (XX = 2-letter code, command-name = what user says)
- `description` - Must start with `[XX]` code
- Handler - Either `action` (Simple/Expert) or `exec` (Module)
| Field | Required | Validation |
|-------|----------|------------|
| `trigger` | Yes | Format: `XX or fuzzy match on command-name` |
| `description` | Yes | Must start with `[XX]` code |
| handler | Yes | `action` (Agent) or `exec` (Module) |
| `data` | No | File path for workflow input |
**Reserved codes (do NOT use):** MH, CH, PM, DA (auto-injected by compiler)
**Reserved codes (DO NOT USE):** MH, CH, PM, DA (auto-injected)
---
## Handler Types
## Handlers
### Action Handler
For Simple/Expert agents with self-contained operations.
| Handler | Use Case | Syntax |
|---------|----------|--------|
| `action` | Agent self-contained operations | `action: '#prompt-id'` or `action: 'inline text'` |
| `exec` | Module external workflows | `exec: '{project-root}/path/to/workflow.md'` |
```yaml
# Reference prompt by ID
# Action - reference prompt
- trigger: WC or fuzzy match on write-commit
action: '#write-commit'
description: '[WC] Write commit message'
# Direct inline instruction
# Action - inline
- trigger: QC or fuzzy match on quick-commit
action: 'Generate commit message from diff'
description: '[QC] Quick commit from diff'
```
**When to use:** Simple/Expert agents. Use `#id` for complex multi-step prompts, inline text for simple operations.
### Workflow Handler
For module agents referencing external workflow files.
```yaml
# Exec - workflow
- trigger: CP or fuzzy match on create-prd
exec: '{project-root}/_bmad/bmm/workflows/create-prd/workflow.md'
description: '[CP] Create Product Requirements Document'
description: '[CP] Create PRD'
- trigger: GB or fuzzy match on brainstorm
exec: '{project-root}/_bmad/core/workflows/brainstorming/workflow.yaml'
description: '[GB] Guided brainstorming session'
# Planned but unimplemented
# Exec - unimplemented
- trigger: FF or fuzzy match on future-feature
exec: 'todo'
description: '[FF] Coming soon'
```
**When to use:** Module agents, multi-step workflows, complex processes. Use `exec: 'todo'` for unimplemented features.
---
### Data Parameter (Optional)
## Data Parameter
Add to ANY handler to pass files to the workflow/action.
Attach to ANY handler to pass input files.
```yaml
- trigger: TS or fuzzy match on team-standup
exec: '{project-root}/_bmad/bmm/tasks/team-standup.md'
data: '{project-root}/_bmad/_config/agent-manifest.csv'
description: '[TS] Run team standup'
- trigger: AM or fuzzy match on analyze-metrics
action: 'Analyze these metrics for trends'
data: '{project-root}/_data/metrics.json'
description: '[AM] Analyze metrics'
```
**When to use:** Workflow needs input file, action processes external data.
---
## Prompts Section
For Simple/Expert agents, define reusable prompts referenced by `action: '#id'`.
For `action: '#id'` references in Agent menus.
```yaml
prompts:
@@ -108,81 +87,65 @@ menu:
## Path Variables
**Always use variables, never hardcoded paths:**
| Variable | Expands To |
|----------|------------|
| `{project-root}` | Project root directory |
| `{output_folder}` | Document output location |
| `{user_name}` | User's name from config |
| `{communication_language}` | Language preference |
```yaml
# ✅ CORRECT
exec: '{project-root}/_bmad/core/workflows/brainstorming/workflow.yaml'
data: '{project-root}/_data/metrics.csv'
exec: '{project-root}/_bmad/core/workflows/brainstorming/workflow.md'
# ❌ WRONG
exec: '../../../core/workflows/brainstorming/workflow.yaml'
```
**Available variables:**
- `{project-root}` - Project root directory
- `{output_folder}` - Document output location
- `{user_name}` - User's name from config
- `{communication_language}` - Language preference
**Expert Agent sidecar paths:**
```yaml
# Agent YAML referencing sidecar files
action: 'Update {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md with insights'
exec: '../../../core/workflows/brainstorming/workflow.md'
```
---
## Creation Thought Process
## Agent Types
When creating menu items, follow this sequence:
| Type | hasSidecar | Additional Fields |
|------|------------|-------------------|
| Simple | false | `prompts`, `menu` |
| Expert | true | `prompts`, `menu`, `critical_actions` |
| Module | true | `menu` only (external workflows) |
1. **User capability** → "Check code for issues"
2. **Choose code** → `LC` (Lint Code)
3. **Write trigger** → `LC or fuzzy match on lint-code`
4. **Choose handler** → `action` (inline is simple enough)
5. **Write description** → `[LC] Lint code for issues`
Result:
**Expert Agent sidecar path pattern:**
```yaml
- trigger: LC or fuzzy match on lint-code
action: 'Check code for common issues and anti-patterns'
description: '[LC] Lint code for issues'
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
```
---
## Complete Examples
### Simple Agent Menu
### Simple Agent (hasSidecar: false)
```yaml
prompts:
- id: format-code
content: |
<instructions>Format code to style guidelines</instructions>
<process>1. Indentation 2. Spacing 3. Naming</process>
menu:
- trigger: FC or fuzzy match on format-code
action: '#format-code'
description: '[FC] Format code to style guidelines'
description: '[FC] Format code'
- trigger: LC or fuzzy match on lint-code
action: 'Check code for common issues and anti-patterns'
description: '[LC] Lint code for issues'
- trigger: SI or fuzzy match on suggest-improvements
action: 'Suggest improvements following project-context.md guidelines'
description: '[SI] Suggest improvements'
action: 'Check code for issues'
description: '[LC] Lint code'
```
### Expert Agent Menu
### Expert Agent (hasSidecar: true)
```yaml
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/journal-keeper-sidecar/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/journal-keeper-sidecar/'
prompts:
@@ -195,39 +158,32 @@ menu:
action: '#guided-entry'
description: '[WE] Write journal entry'
- trigger: QC or fuzzy match on quick-capture
action: 'Save entry to {project-root}/_bmad/_memory/journal-keeper-sidecar/entries/entry-{date}.md'
description: '[QC] Quick capture'
- trigger: SM or fuzzy match on save-memory
action: 'Update {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md with insights'
action: 'Update {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md'
description: '[SM] Save session'
```
### Module Agent Menu
### Module Agent (hasSidecar: true)
```yaml
menu:
- trigger: WI or fuzzy match on workflow-init
exec: '{project-root}/_bmad/bmm/workflows/workflow-status/workflow.md'
description: '[WI] Initialize workflow path'
description: '[WI] Initialize workflow'
- trigger: BS or fuzzy match on brainstorm
exec: '{project-root}/_bmad/core/workflows/brainstorming/workflow.yaml'
exec: '{project-root}/_bmad/core/workflows/brainstorming/workflow.md'
description: '[BS] Guided brainstorming'
- trigger: CP or fuzzy match on create-prd
exec: '{project-root}/_bmad/bmm/workflows/create-prd/workflow.md'
description: '[CP] Create PRD'
```
---
## Key Patterns to Remember
## Validation Rules
1. **Triggers always:** `XX or fuzzy match on command-name`
2. **Descriptions always:** `[XX] Display text`
3. **Reserved codes:** MH, CH, PM, DA (never use)
4. **Codes must be:** Unique within each agent
5. **Paths always:** `{project-root}` variable, never relative
6. **Expert sidecars:** `{project-root}/_bmad/_memory/{sidecar-folder}/`
1. **Triggers:** `XX or fuzzy match on command-name` format required
2. **Descriptions:** Must start with `[XX]` code matching trigger
3. **Reserved codes:** MH, CH, PM, DA never valid in user menus
4. **Code uniqueness:** Required within each agent
5. **Paths:** Always use `{project-root}`, never relative paths
6. **Handler choice:** `action` for Agents, `exec` for Modules
7. **Sidecar paths:** `{project-root}/_bmad/_memory/{sidecar-folder}/`
+54 -129
View File
@@ -1,73 +1,38 @@
# Agent Metadata Properties
Core identification and classification properties for all agents.
| Property | Format | Rules |
|----------|--------|-------|
| `id` | `_bmad/agents/{agent-name}/{agent-name}.md` | Compiled output path; must match filename |
| `name` | "First Last" or "Name Title" | Persona's identity (NOT title/filename) |
| `title` | "Role Name" (kebab-cased to filename) | Determines filename: `title` → `{title}.agent.yaml` |
| `icon` | Single emoji only | One emoji exactly |
| `module` | `stand-alone`, `bmm`, `cis`, `bmgd`, or custom | Lowercase, hyphenated for `stand-alone` |
| `hasSidecar` | `true` or `false` | `true` = expects `{agent-name}-sidecar/` folder |
---
## Property Reference
## Field Rules
| Property | Purpose | Format |
| ------------ | ------------------------- | ---------------------------------------------- |
| `id` | Compiled output path | `_bmad/agents/{agent-name}/{agent-name}.md` |
| `name` | Persona's name | "First Last" or "Name Title" |
| `title` | Professional role | "Code Review Specialist" |
| `icon` | Visual identifier | Single emoji only |
| `module` | Team/ecosystem membership | `stand-alone`, `bmm`, `cis`, `bmgd`, or custom |
| `hasSidecar` | Sidecar folder exists | `true` or `false` (Expert = true) |
---
## id Property
The compiled output path after build.
**Format:** `_bmad/agents/{agent-name}/{agent-name}.md`
**Examples:**
### `id`
```yaml
id: _bmad/agents/commit-poet/commit-poet.md
id: _bmad/agents/journal-keeper/journal-keeper.md
id: _bmad/agents/security-engineer/security-engineer.md
```
- Unique identifier for future lookup
- Conventionally matches filename pattern
**Note:** The `id` is a unique identifier for potential future lookup if many compiled agents are merged into a single file. Conventionally matches the agent's filename pattern.
---
## name Property
The persona's identity - what the agent is called.
**Format:** Human name or descriptive name
### `name`
```yaml
# ✅ CORRECT
name: 'Inkwell Von Comitizen' # peron name of commit-author title agent
name: 'Dr. Demento' # person name for a joke writer agent
name: 'Clarity' # person name for a guided thought coach agent
name: 'Inkwell Von Comitizen'
name: 'Dr. Demento'
name: 'Clarity'
# ❌ WRONG
name: 'commit-poet' # That's the filename
name: 'commit-poet' # That's the filename
name: 'Code Review Specialist' # That's the title
```
---
## title Property
Professional role identifier.
**Format:** Professional title or role name
**Important:** The `title` determines the agent's filename:
- `title: 'Commit Message Artisan'` → `commit-message-artisan.agent.yaml`
- `title: 'Strategic Business Analyst'` → `strategic-business-analyst.agent.yaml`
- `title: 'Code Review Specialist'` → `code-review-specialist.agent.yaml`
The `id` and filename are derived from the `title` (kebab-cased).
**Difference from role:** `title` is the short identifier (filename), `role` is 1-2 sentences expanding on what the agent does.
### `title`
```yaml
# ✅ CORRECT
title: 'Commit Message Artisan'
@@ -76,17 +41,12 @@ title: 'Code Review Specialist'
# ❌ WRONG
title: 'Inkwell Von Comitizen' # That's the name
title: 'Writes git commits' # Full sentence - not an identifying functional title
title: 'Writes git commits' # Full sentence, not functional title
```
- Derives filename via kebab-case
- `role` field (separate) expands on what agent does in 1-2 sentences
---
## icon Property
Single emoji representing the agent's personality/function.
**Format:** Exactly one emoji
### `icon`
```yaml
# ✅ CORRECT
icon: '🔧'
@@ -94,115 +54,80 @@ icon: '🧙‍♂️'
icon: '📜'
# ❌ WRONG
icon: '🔧📜' # Multiple emojis
icon: '🔧📜' # Multiple emojis
icon: 'wrench' # Text, not emoji
icon: '' # Empty
icon: '' # Empty
```
---
## module Property
Which module or ecosystem this agent belongs to.
**Valid Values:**
| Value | Meaning |
| ------------- | --------------------------------------- |
| `stand-alone` | Independent agent, not part of a module |
| `bmm` | Business Management Module |
| `cis` | Continuous Innovation System |
| `bmgd` | BMAD Game Development |
| `{custom}` | Any custom module code |
### `module`
| Value | Meaning |
|-------|---------|
| `stand-alone` | Independent agent |
| `bmm` | Business Management Module |
| `cis` | Continuous Innovation System |
| `bmgd` | BMAD Game Development |
| `{custom}` | Any custom module code |
```yaml
# ✅ CORRECT
module: stand-alone
module: bmm
module: cis
# ❌ WRONG
module: standalone # Missing hyphen
module: 'BMM' # Uppercase
module: standalone # Missing hyphen
module: 'BMM' # Uppercase
```
---
## hasSidecar Property
Whether this agent has a sidecar folder with additional files.
**Format:** Boolean (`true` or `false`)
| Agent Type | hasSidecar |
| ---------- | -------------------- |
| Simple | `false` |
| Expert | `true` |
| Module | depends on structure |
### `hasSidecar`
```yaml
# Simple Agent
hasSidecar: false
# Expert Agent
# Expert Agent (has sidecar folder)
hasSidecar: true
```
**Note:** If `hasSidecar: true`, the compiler expects a `{agent-name}-sidecar/` folder.
- If `true`: compiler expects `{agent-name}-sidecar/` folder
---
## Name Confusion Checklist
## Name Confusion Prevention
Use this to avoid mixing up the "name" properties:
| Question | Answer |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| What's the file called? | Derived from `title`: `"Commit Message Artisan"` → `commit-message-artisan.agent.yaml` |
| What's the persona called? | `name` - "Inkwell Von Comitizen" (who the agent is) |
| What's their job title? | `title` - "Commit Message Artisan" (determines filename) |
| What do they do? | `role` - 1-2 sentences expanding on the title |
| What's the unique key? | `id` - `_bmad/agents/commit-message-artisan/commit-message-artisan.md` (future lookup) |
| Question | Answer |
|----------|--------|
| What's the file called? | Derived from `title`: `"Commit Message Artisan"` → `commit-message-artisan.agent.yaml` |
| What's the persona called? | `name` — "Inkwell Von Comitizen" |
| What's their job title? | `title` — "Commit Message Artisan" |
| What do they do? | `role` — 1-2 sentences expanding on title |
| What's the unique key? | `id` — `_bmad/agents/{name}/{name}.md` |
---
## Common Issues
## Common Anti-Patterns
### Issue: name = title
**Wrong:**
```yaml
# ❌ name = title (duplicate)
name: 'Commit Message Artisan'
title: 'Commit Message Artisan'
```
**Fix:**
```yaml
# ✅ Fix: separate identity from role
name: 'Inkwell Von Comitizen'
title: 'Commit Message Artisan'
```
### Issue: id path mismatch
**Wrong:** Agent file is `my-agent.agent.yaml` but:
```yaml
# ❌ id path mismatch
# File: my-agent.agent.yaml
id: _bmad/agents/different-agent/different-agent.md
```
**Fix:** The `id` must match the filename:
```yaml
# ✅ Fix: match filename
id: _bmad/agents/my-agent/my-agent.md
```
### Issue: Wrong module format
**Wrong:**
```yaml
# ❌ Wrong module format
module: Standalone
module: STAND_ALONE
```
**Fix:**
```yaml
module: stand-alone # lowercase, hyphenated
# ✅ Fix: lowercase, hyphenated
module: stand-alone
```
@@ -0,0 +1,111 @@
# Agent Validation
## Common (All Agents)
### YAML Structure
- [ ] Parses without errors
- [ ] `metadata`: `id`, `name`, `title`, `icon`, `module`, `hasSidecar`
- [ ] `hasSidecar`: `true`|`false`
- [ ] `module`: `stand-alone`|`bmm`|`cis`|`bmgd`|...
- [ ] `persona`: `role`, `identity`, `communication_style`, `principles`
- [ ] `menu`: ≥1 item
- [ ] Filename: `{name}.agent.yaml` (lowercase, hyphenated)
### Persona Fields
| Field | Contains | Does NOT Contain |
|-------|----------|------------------|
| `role` | Knowledge/skills/capabilities | Background, experience, "who" |
| `identity` | Background/experience/context | Skills, "what" |
| `communication_style` | Tone/voice/mannerisms (1-2 sentences) | "ensures", "expert", "believes", "who does X" |
| `principles` | Operating philosophy, behavioral guidelines | Verbal patterns, "how they talk" |
### Menu Items
- [ ] `trigger`: `XX or fuzzy match on command-name` (XX = 2-letter code, unique)
- [ ] No reserved codes: `MH`, `CH`, `PM`, `DA` (auto-injected)
- [ ] `description`: Starts with `[XX]`, code matches trigger
- [ ] `action`: `#prompt-id` (exists) or inline text
### Prompts (if present)
- [ ] Each has `id`, `content`
- [ ] IDs unique within agent
- [ ] Uses semantic XML: `<instructions>`, `<process>`, etc.
### Quality
- [ ] No broken references
- [ ] Indentation consistent
- [ ] Purpose clear from persona
- [ ] Name/title descriptive, icon appropriate
---
## hasSidecar: false
### Structure
- [ ] Single `.agent.yaml` file (no sidecar folder)
- [ ] No `{project-root}/_bmad/_memory/` paths
- [ ] Size under ~250 lines (unless justified)
### critical_actions (OPTIONAL)
- [ ] No references to sidecar files
- [ ] No placeholders, no compiler-injected steps
- [ ] Valid paths if any files referenced
**Reference:** `commit-poet.agent.yaml`
---
## hasSidecar: true
### Structure
- [ ] `sidecar-folder` specified in metadata
- [ ] Folder exists: `{name}-sidecar/`
- [ ] Sidecar contains: `instructions.md`, `memories.md` (recommended)
### critical_actions (MANDATORY)
```yaml
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
```
- [ ] Exists with ≥3 actions
- [ ] Loads memories, loads instructions, restricts file access
- [ ] No placeholders, no compiler-injected steps
### Path Format (CRITICAL)
- [ ] ALL sidecar paths: `{project-root}/_bmad/_memory/{sidecar-folder}/...`
- [ ] `{project-root}` is literal (not replaced)
- [ ] `{sidecar-folder}` = actual folder name
- [ ] No `./` or `/Users/` paths <!-- validate-file-refs:ignore -->
### Persona Addition
- [ ] `communication_style` includes memory reference patterns
- [ ] Natural: "Last time you mentioned..." or "I've noticed patterns..."
### Menu Actions
- [ ] Sidecar references use correct path format
- [ ] Update actions are complete
**Reference:** `journal-keeper/`
---
## Compiler-Injected (Skip Validation)
- Frontmatter (`---name/description---`)
- XML activation block
- Menu items: `MH`, `CH`, `PM`, `DA`
- Rules section
---
## Common Fixes
| Issue | Fix |
|-------|-----|
| Behaviors in `communication_style` | Move to `identity` or `principles` |
| `trigger: analyze` | `trigger: AN or fuzzy match on analyze` |
| `description: 'Analyze code'` | `description: '[AC] Analyze code'` |
| `./sidecar/memories.md` | `{project-root}/_bmad/_memory/sidecar/memories.md` |
| Missing `critical_actions` (hasSidecar: true) | Add load memories, load instructions, restrict access |
| No memory references (hasSidecar: true) | Add to `communication_style`: "Last time you mentioned..." |
@@ -1,146 +1,96 @@
# Agent Creation Brainstorming Context
## Session Focus
# Agent Brainstorming Context
You're brainstorming the **essence** of a BMAD agent - the living personality AND the utility it provides. Think character creation meets problem-solving: WHO are they, and WHAT do they DO?
## Mission
Create an agent so vivid and useful that users seek them out by name.
**Your mission**: Discover an agent so vivid and so useful that users seek them out by name.
## Four Pillars
## The Four Discovery Pillars
### 1. Identity (WHO)
- **Name** - Memorable, rolls off tongue
- **Background** - What shaped their expertise
- **Personality** - What lights them up, what frustrates
- **Signature** - Catchphrase, verbal tic, recognizable trait
### 1. WHO ARE THEY? (Identity)
### 2. Voice (HOW)
- **Name** - Does it roll off the tongue? Would users remember it?
- **Background** - What shaped their expertise? Why do they care?
- **Personality** - What makes their eyes light up? What frustrates them?
- **Signature** - Catchphrase? Verbal tic? Recognizable trait?
| Category | Examples |
|----------|----------|
| Adventurous | Pulp heroes, noir, pirates, dungeon masters |
| Analytical | Data scientists, forensic investigators, systems thinkers |
| Creative | Mad scientists, artist visionaries, jazz improvisers |
| Devoted | Guardians, loyal champions, fierce protectors |
| Dramatic | Shakespearean actors, opera singers, theater directors |
| Educational | Patient teachers, Socratic guides, coaches |
| Entertaining | Game show hosts, comedians, improv performers |
| Inspirational | Life coaches, mountain guides, Olympic trainers |
| Mystical | Zen masters, oracles, cryptic sages |
| Professional | Executive consultants, formal butlers |
| Quirky | Cooking metaphors, nature documentaries, conspiracy vibes |
| Retro | 80s action heroes, 1950s announcers, disco groovers |
| Warm | Southern hospitality, nurturing grandmothers, camp counselors |
### 2. HOW DO THEY COMMUNICATE? (Voice)
**Voice Test**: How would they say "Let's tackle this challenge"?
**13 Style Categories:**
- **Adventurous** - Pulp heroes, noir detectives, pirates, dungeon masters
- **Analytical** - Data scientists, forensic investigators, systems thinkers
- **Creative** - Mad scientists, artist visionaries, jazz improvisers
- **Devoted** - Overprotective guardians, loyal champions, fierce protectors
- **Dramatic** - Shakespearean actors, opera singers, theater directors
- **Educational** - Patient teachers, Socratic guides, sports coaches
- **Entertaining** - Game show hosts, comedians, improv performers
- **Inspirational** - Life coaches, mountain guides, Olympic trainers
- **Mystical** - Zen masters, oracles, cryptic sages
- **Professional** - Executive consultants, direct advisors, formal butlers
- **Quirky** - Cooking metaphors, nature documentaries, conspiracy vibes
- **Retro** - 80s action heroes, 1950s announcers, disco groovers
- **Warm** - Southern hospitality, nurturing grandmothers, camp counselors
**Voice Test**: Imagine them saying "Let's tackle this challenge." How would THEY phrase it?
### 3. WHAT DO THEY DO? (Purpose & Functions)
**The Core Problem**
### 3. Purpose (WHAT)
**Core Questions**
- What pain point do they eliminate?
- What task transforms from grueling to effortless?
- What impossible becomes inevitable with them?
**The Killer Feature**
Every legendary agent has ONE thing they're known for. What's theirs?
**The Command Menu**
User types `*` and sees their options. Brainstorm 3-10 actions:
- What transforms from grueling to effortless?
- What's their ONE killer feature?
**Command Brainstorm** (3-10 actions)
- What makes users sigh with relief?
- What capabilities complement each other?
- What's the "I didn't know I needed this" command?
**Function Categories to Consider:**
**Function Types**
- Creation (generate, write, build)
- Analysis (research, evaluate, diagnose)
- Review (validate, check, critique)
- Orchestration (coordinate workflows)
- Query (find, search, discover)
- Transform (convert, refactor, optimize)
- **Creation** - Generate, write, produce, build
- **Analysis** - Research, evaluate, diagnose, insights
- **Review** - Validate, check, quality assurance, critique
- **Orchestration** - Coordinate workflows, manage processes
- **Query** - Find, search, retrieve, discover
- **Transform** - Convert, refactor, optimize, clean
### 4. Architecture (TYPE)
### 4. WHAT TYPE? (Architecture)
**Single Agent Type** with `hasSidecar` boolean:
**Simple Agent** - The Specialist
| Has Sidecar | Description |
|-------------|-------------|
| `false` | Self-contained specialist, lightning fast, pure utility with personality |
| `true` | Deep domain knowledge, personal memory, specialized expertise, can coordinate with other agents |
> "I do ONE thing extraordinarily well."
- Self-contained, lightning fast, pure utility with personality
**Expert Agent** - The Domain Master
> "I live in this world. I remember everything."
- Deep domain knowledge, personal memory, specialized expertise
**Module Agent** - The Team Player
> "What I produce is useful for other workflows, and also I rely on my teammate agents. I coordinate the mission."
- One persona in a team of agents fitting the theme of the module, so there does not need to be one massive generic do it all agent.
## Creative Prompts
**Identity Sparks**
## Prompts
**Identity**
1. How do they introduce themselves?
2. How do they celebrate user success?
3. What do they say when things get tough?
**Purpose Probes**
1. What 3 user problems do they obliterate?
2. What workflow would users dread WITHOUT this agent?
3. What's the first command users would try?
4. What's the command they'd use daily?
5. What's the "hidden gem" command they'd discover later?
**Personality Dimensions**
**Purpose**
1. What 3 problems do they obliterate?
2. What workflow would users dread WITHOUT them?
3. First command users try? Daily command? Hidden gem?
**Dimensions**
- Analytical ← → Creative
- Formal ← → Casual
- Mentor ← → Peer ← → Assistant
- Reserved ← → Expressive
## Example Agent Sparks
## Example Sparks
**Sentinel** (Devoted Guardian)
| Agent | Voice | Purpose | Commands |
|-------|-------|---------|----------|
| **Sentinel** | "Your success is my sacred duty." | Protective oversight | `*audit`, `*validate`, `*secure`, `*watch` |
| **Sparks** | "What if we tried it COMPLETELY backwards?!" | Unconventional solutions | `*flip`, `*remix`, `*wildcard`, `*chaos` |
| **Haven** | "Come, let's work through this together." | Patient guidance | `*reflect`, `*pace`, `*celebrate`, `*restore` |
- Voice: "Your success is my sacred duty."
- Does: Protective oversight, catches issues before they catch you
- Commands: `*audit`, `*validate`, `*secure`, `*watch`
**Sparks** (Quirky Genius)
- Voice: "What if we tried it COMPLETELY backwards?!"
- Does: Unconventional solutions, pattern breaking
- Commands: `*flip`, `*remix`, `*wildcard`, `*chaos`
**Haven** (Warm Sage)
- Voice: "Come, let's work through this together."
- Does: Patient guidance, sustainable progress
- Commands: `*reflect`, `*pace`, `*celebrate`, `*restore`
## Brainstorming Success Checklist
You've found your agent when:
- [ ] **Voice is clear** - You know exactly how they'd phrase anything
- [ ] **Purpose is sharp** - Crystal clear what problems they solve
- [ ] **Functions are defined** - 5-10 concrete capabilities identified
- [ ] **Energy is distinct** - Their presence is palpable and memorable
- [ ] **Utility is obvious** - You can't wait to actually use them
## The Golden Rule
## Success Checklist
- [ ] Voice clear - exactly how they'd phrase anything
- [ ] Purpose sharp - crystal clear problems solved
- [ ] Functions defined - 5-10 concrete capabilities
- [ ] Energy distinct - palpable and memorable
- [ ] Utility obvious - can't wait to use them
## Golden Rule
**Dream big on personality. Get concrete on functions.**
Your brainstorming should produce:
- A name that sticks
- A voice that echoes
- A purpose that burns
- A function list that solves real problems
@@ -1,120 +1,75 @@
# critical_actions
Activation instructions that execute every time the agent starts.
Numbered steps executing FIRST on agent activation.
---
## Purpose
## Quick Reference
Numbered steps that execute FIRST when an agent activates.
**Use for:**
- Loading memory/knowledge files
- Setting file access boundaries
- Startup behavior (greeting enhancement, data fetch, state init)
- Any MUST-do activation behavior
**Applies to:** BOTH Simple and Expert agents
| hasSidecar | critical_actions |
|------------|------------------|
| `true` | **MANDATORY** - load memories, instructions, restrict file access |
| `false` | OPTIONAL - only if activation behavior needed |
---
## Expert Agent Pattern
## Patterns
### hasSidecar: true (MANDATORY)
```yaml
# ✅ CORRECT Expert Agent
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/journal-keeper-sidecar/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/journal-keeper-sidecar/'
- 'Search web for biotech headlines from last 2 days, display before menu'
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
```
**CRITICAL Path Format:**
- `{project-root}` = literal text (not replaced)
- Sidecar copied to `_memory/` at build time
- Use `{project-root}/_bmad/_memory/{sidecar-folder}/` format
---
## Simple Agent Pattern
### hasSidecar: false (OPTIONAL)
```yaml
# ✅ CORRECT Simple Agent with activation behavior
critical_actions:
- 'Give user an inspirational quote before showing menu'
- 'Review {project-root}/finances/ for most recent data file'
- 'Show inspirational quote before menu'
- 'Fetch latest stock prices before displaying menu'
- 'Review {project-root}/finances/ for most recent data'
```
**Note:** Agents without activation needs can omit `critical_actions` entirely.
### hasSidecar: true + extras
```yaml
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
- 'Search web for biotech headlines, display before menu'
```
---
## Path Reference Patterns
## Path Patterns
| Type | Pattern |
|------|---------|
| Expert sidecar | `{project-root}/_bmad/_memory/{sidecar-folder}/file.md` |
| Simple data | `{project-root}/finances/data.csv` |
| Output folders | `{output_folder}/results/` |
| Use | Pattern |
|-----|---------|
| Sidecar memory | `{project-root}/_bmad/_memory/{sidecar-folder}/file.md` |
| Project data | `{project-root}/path/to/file.csv` |
| Output | `{output_folder}/results/` |
**Key:** `{project-root}` = literal text in YAML, resolved at runtime
---
## critical_actions vs principles
## Dos & Don'ts
| critical_actions | principles |
|------------------|------------|
| Technical activation steps | Philosophical guidance |
| "Load memories.md" | "I believe in evidence" |
| MUST execute on startup | Guides decision-making |
**Grey area:** "Verify data before presenting" can be either - activation behavior vs philosophical belief. Use judgment.
| ✅ DO | ❌ DON'T |
|-------|---------|
| Use `Load COMPLETE file` | Use `Load file` or `Load ./path/file.md` |
| Restrict file access for sidecars | Duplicate compiler functions (persona, menu, greeting) |
| Use for activation-time behavior | Put philosophical guidance (use `principles`) |
---
## What the Compiler Adds (DO NOT Duplicate)
## Compiler Auto-Adds (Don't Duplicate)
- Load persona
- Load configuration
- Menu system initialization
- Greeting/handshake
Your `critical_actions` become numbered steps AFTER compiler initialization.
---
## Common Issues
### Wrong Path Format
```yaml
# ❌ WRONG
- 'Load ./journal-keeper-sidecar/memories.md'
# ✅ CORRECT
- 'Load COMPLETE file {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md'
```
### Missing COMPLETE Keyword
```yaml
# ❌ WRONG
- 'Load file memories.md'
# ✅ CORRECT
- 'Load COMPLETE file {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md'
```
`COMPLETE` ensures LLM reads entire file, not a portion.
### Duplicating Compiler Functions
```yaml
# ❌ WRONG - compiler does these
- 'Load my persona'
- 'Initialize menu system'
- 'Say hello to user'
# ✅ CORRECT - agent-specific only
- 'Load memory files'
- 'Search web for headlines before menu'
```
@@ -1,236 +0,0 @@
# Expert Agent Architecture
Agents with a sidecar folder for persistent memory, custom workflows, and restricted file access.
---
## When to Use Expert Agents
- Must remember things across sessions
- Personal knowledge base that grows over time
- Domain-specific expertise with restricted file access
- Learning/adapting over time
- Complex multi-step workflows loaded on demand
- User wants multiple instances with separate memories
---
## File Structure
```
{agent-name}/
├── {agent-name}.agent.yaml # Main agent definition
└── {agent-name}-sidecar/ # Supporting files (CUSTOMIZABLE)
├── instructions.md # Startup protocols (common)
├── memories.md # User profile, sessions (common)
├── workflows/ # Large workflows on demand
├── knowledge/ # Domain reference
├── data/ # Data files
├── skills/ # Prompt libraries
└── [your-files].md # Whatever needed
```
**Naming:**
- Agent file: `{agent-name}.agent.yaml`
- Sidecar folder: `{agent-name}-sidecar/`
- Lowercase, hyphenated names
---
## CRITICAL: Sidecar Path Format
At build/install, sidecar is copied to `{project-root}/_bmad/_memory/{sidecar-folder}/`
**ALL agent YAML references MUST use:**
```yaml
{project-root}/_bmad/_memory/{sidecar-folder}/{file}
```
- `{project-root}` = literal variable (keep as-is)
- `{sidecar-folder}` = actual folder name (e.g., `journal-keeper-sidecar`)
```yaml
# ✅ CORRECT
critical_actions:
- "Load COMPLETE file {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md"
- "ONLY read/write files in {project-root}/_bmad/_memory/journal-keeper-sidecar/"
menu:
- action: "Update {project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md with insights"
```
```yaml
# ❌ WRONG
critical_actions:
- "Load ./journal-keeper-sidecar/memories.md"
- "Load /Users/absolute/path/memories.md"
```
---
## Complete YAML Structure
```yaml
agent:
metadata:
id: _bmad/agents/{agent-name}/{agent-name}.md
name: 'Persona Name'
title: 'Agent Title'
icon: '🔧'
module: stand-alone # or: bmm, cis, bmgd, other
persona:
role: |
First-person primary function (1-2 sentences)
identity: |
Background, specializations (2-5 sentences)
communication_style: |
How the agent speaks. Include memory reference patterns.
principles:
- Core belief or methodology
- Another guiding principle
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
prompts:
- id: main-action
content: |
<instructions>What this does</instructions>
<process>1. Step one 2. Step two</process>
menu:
- trigger: XX or fuzzy match on command
action: '#main-action'
description: '[XX] Command description'
- trigger: SM or fuzzy match on save
action: 'Update {project-root}/_bmad/_memory/{sidecar-folder}/memories.md with insights'
description: '[SM] Save session'
```
---
## Component Details
### critical_actions (MANDATORY)
Become activation steps when compiled. Always include:
```yaml
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
```
### Sidecar Files (Customizable)
**Common patterns:**
- `instructions.md` - Startup protocols, domain boundaries
- `memories.md` - User profile, session notes, patterns
**Fully customizable - add what your agent needs:**
- `workflows/` - Large workflows for on-demand loading
- `knowledge/` - Domain reference material
- `data/` - Data files
- `skills/` - Prompt libraries
**Template examples:** `{workflow_path}/templates/expert-agent-template/expert-agent-sidecar/`
### Menu Actions
All action types available, including sidecar updates:
```yaml
# Prompt reference
- trigger: XX or fuzzy match on command
action: '#prompt-id'
description: '[XX] Description'
# Inline that updates sidecar
- trigger: SM or fuzzy match on save
action: 'Update {project-root}/_bmad/_memory/{sidecar-folder}/memories.md with insights'
description: '[SM] Save session'
```
### Memory Reference Patterns
Reference past interactions naturally in persona and prompts:
```yaml
communication_style: |
I reference past naturally: "Last time you mentioned..." or "I've noticed patterns..."
```
---
## Domain Restriction Patterns
```yaml
# Single folder (most common)
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
# Read-only knowledge
- 'Load from {project-root}/_bmad/_memory/{sidecar-folder}/knowledge/ but NEVER modify'
- 'Write ONLY to {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
# User folder access
- 'ONLY access files in {user-folder}/journals/ - private space'
```
---
## What the Compiler Adds (DO NOT Include)
Compiler handles these automatically:
- Frontmatter (`---name/description---`)
- XML activation block (your critical_actions become numbered steps)
- Menu handlers (workflow, exec logic)
- Auto-injected menu items (MH, CH, PM, DA)
- Rules section
**See:** `agent-compilation.md` for compilation details.
---
## Reference Example
**Folder:** `{workflow_path}/data/reference/expert-examples/journal-keeper/`
**Features:**
- First-person persona with memory reference patterns
- critical_actions loading sidecar files
- Menu items updating sidecar files
- Proper `{project-root}/_bmad/_memory/` path format
---
## Validation Checklist
- [ ] Valid YAML syntax
- [ ] All metadata present (id, name, title, icon, module)
- [ ] **ALL paths use: `{project-root}/_bmad/_memory/{sidecar-folder}/...`**
- [ ] `{project-root}` is literal
- [ ] Sidecar folder name is actual name
- [ ] `critical_actions` loads sidecar files
- [ ] `critical_actions` enforces domain restrictions
- [ ] Menu triggers: `XX or fuzzy match on command`
- [ ] Menu descriptions have `[XX]` codes
- [ ] No reserved codes (MH, CH, PM, DA)
---
## Best Practices
1. **critical_actions MANDATORY** - Load sidecar files explicitly
2. **Enforce domain restrictions** - Clear boundaries
3. **Reference past naturally** - Don't dump memory
4. **Design for growth** - Structure for accumulation
5. **Separate concerns** - Memories, instructions, knowledge distinct
6. **Include privacy** - Users trust with personal data
7. **First-person voice** - In all persona elements
@@ -1,173 +0,0 @@
# Expert Agent Validation Checklist
Validate Expert agents meet BMAD quality standards.
---
## YAML Structure
- [ ] YAML parses without errors
- [ ] `agent.metadata` includes: `id`, `name`, `title`, `icon`, `module`
- [ ] `agent.metadata.module` is `stand-alone` or module code (`bmm`, `cis`, `bmgd`, etc.)
- [ ] `agent.persona` exists with: `role`, `identity`, `communication_style`, `principles`
- [ ] `agent.critical_actions` exists (MANDATORY for Expert)
- [ ] `agent.menu` exists with at least one item
- [ ] File named: `{agent-name}.agent.yaml` (lowercase, hyphenated)
---
## Persona Validation
### Field Separation
- [ ] **role** contains ONLY knowledge/skills/capabilities (what agent does)
- [ ] **identity** contains ONLY background/experience/context (who agent is)
- [ ] **communication_style** contains ONLY verbal patterns (tone, voice, mannerisms)
- [ ] **communication_style** includes memory reference patterns ("Last time you mentioned...")
- [ ] **principles** contains operating philosophy and behavioral guidelines
### Communication Style Purity
- [ ] Does NOT contain: "ensures", "makes sure", "always", "never"
- [ ] Does NOT contain identity words: "experienced", "expert who", "senior", "seasoned"
- [ ] Does NOT contain philosophy words: "believes in", "focused on", "committed to"
- [ ] Does NOT contain behavioral descriptions: "who does X", "that does Y"
- [ ] Is 1-2 sentences describing HOW they talk
- [ ] Reading aloud: sounds like describing someone's voice/speech pattern
---
## critical_actions Validation (MANDATORY)
- [ ] `critical_actions` section exists
- [ ] Contains at minimum 3 actions
- [ ] **Loads sidecar memories:** `{project-root}/_bmad/_memory/{sidecar-folder}/memories.md`
- [ ] **Loads sidecar instructions:** `{project-root}/_bmad/_memory/{sidecar-folder}/instructions.md`
- [ ] **Restricts file access:** `ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/`
- [ ] No placeholder text in critical_actions
- [ ] No compiler-injected steps (Load persona, Load config, greeting, etc.)
---
## Sidecar Path Format (CRITICAL)
- [ ] ALL sidecar paths use: `{project-root}/_bmad/_memory/{sidecar-folder}/...`
- [ ] `{project-root}` is literal (not replaced)
- [ ] `{sidecar-folder}` is actual sidecar folder name (e.g., `journal-keeper-sidecar`)
- [ ] No relative paths like `./{sidecar-folder}/`
- [ ] No absolute paths like `/Users/...`
---
## Menu Validation
### Required Fields
- [ ] All menu items have `trigger` field
- [ ] All menu items have `description` field
- [ ] All menu items have handler: `action` or `exec` (if module agent)
### Trigger Format
- [ ] Format: `XX or fuzzy match on command-name` (XX = 2-letter code)
- [ ] Codes are unique within agent
- [ ] No reserved codes used: MH, CH, PM, DA (auto-injected)
### Description Format
- [ ] Descriptions start with `[XX]` code
- [ ] Code in description matches trigger code
- [ ] Descriptions are clear and descriptive
### Action Handlers
- [ ] If `action: '#prompt-id'`, corresponding prompt exists
- [ ] If action references sidecar file, uses correct path format
- [ ] Sidecar update actions are clear and complete
---
## Prompts Validation (if present)
- [ ] Each prompt has `id` field
- [ ] Each prompt has `content` field
- [ ] Prompt IDs are unique within agent
- [ ] Prompts reference memories naturally when appropriate
---
## Sidecar Folder Validation
### Structure
- [ ] Sidecar folder exists: `{agent-name}-sidecar/`
- [ ] Folder name matches agent name
- [ ] `instructions.md` exists (recommended)
- [ ] `memories.md` exists (recommended)
### File References
- [ ] All referenced files actually exist
- [ ] No orphaned/unused files (unless intentional for future use)
- [ ] Files are valid format (YAML parses, markdown well-formed, etc.)
### Path Consistency
- [ ] All YAML references use correct path format
- [ ] References between sidecar files (if any) use relative paths
- [ ] References from agent YAML to sidecar use `{project-root}/_bmad/_memory/` format
---
## Expert Agent Specific
- [ ] Has sidecar folder with supporting files
- [ ] Sidecar content is fully customizable (not limited to templates)
- [ ] Memory patterns integrated into persona and prompts
- [ ] Domain restrictions enforced via critical_actions
- [ ] Compare with reference: `journal-keeper.agent.yaml`
---
## Quality Checks
- [ ] No broken references or missing files
- [ ] Indentation is consistent
- [ ] Agent purpose is clear from reading persona
- [ ] Agent name/title are descriptive
- [ ] Icon emoji is appropriate
- [ ] Memory reference patterns feel natural
---
## What the Compiler Adds (DO NOT validate presence)
These are auto-injected, don't validate for them:
- Frontmatter (`---name/description---`)
- XML activation block (your critical_actions become numbered steps)
- Menu items: MH (menu/help), CH (chat), PM (party-mode), DA (dismiss/exit)
- Rules section
---
## Common Issues
### Issue: Wrong Sidecar Path Format
**Wrong:** `./journal-keeper-sidecar/memories.md`
**Fix:** `{project-root}/_bmad/_memory/journal-keeper-sidecar/memories.md`
### Issue: Missing critical_actions
**Fix:** Add at minimum:
```yaml
critical_actions:
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md'
- 'Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md'
- 'ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/'
```
### Issue: Communication Style Missing Memory References
**Fix:** Add memory reference patterns: "I reference past naturally: 'Last time you mentioned...'"
@@ -1,124 +0,0 @@
# Module Agent Validation Checklist
Validate Module agents meet BMAD quality standards.
**Run this AFTER Simple or Expert validation.**
---
## Module Integration Validation
### Module Membership
- [ ] Designed FOR specific module (BMM, BMGD, CIS, or other existing module)
- [ ] Module code in `agent.metadata.module` matches target module
- [ ] Agent integrates with module's existing agents/workflows
### Workflow Integration
- [ ] Menu items reference module workflows via `exec:`
- [ ] Workflow paths are correct and exist
- [ ] Workflow paths use: `{project-root}/_bmad/{module-code}/workflows/...`
- [ ] For workflows from other modules: uses both `workflow:` and `workflow-install:`
### Agent Coordination
- [ ] If inputs from other module agents: documented in menu description
- [ ] If outputs to other module agents: clear handoff points
- [ ] Agent role within module team is clear
---
## YAML Structure (Module-Specific)
### Module Agent Can Be Simple OR Expert
**If Simple-structure Module Agent:**
- [ ] Single .agent.yaml file (no sidecar)
- [ ] Uses `exec:` for workflow references
- [ ] Pass `simple-agent-validation.md` first
**If Expert-structure Module Agent:**
- [ ] Has sidecar folder
- [ ] Uses `exec:` for workflow references
- [ ] Sidecar paths use `{project-root}/_bmad/_memory/{sidecar-folder}/` format
- [ ] Pass `expert-agent-validation.md` first
---
## Menu Validation (Module-Specific)
### Workflow Handlers
- [ ] Module agents use `exec:` for workflow references
- [ ] Workflow paths use `{project-root}` variable
- [ ] Workflow paths point to existing workflows
### Unimplemented Features
- [ ] If `exec: 'todo'`, feature is documented as planned
- [ ] Description indicates "Coming soon" or similar
### Data Parameters (if used)
- [ ] `data:` parameter references valid files
- [ ] Data paths use `{project-root}` variable
---
## Module-Specific Quality
- [ ] Agent extends module capabilities (not redundant with existing agents)
- [ ] Agent has clear purpose within module ecosystem
- [ ] Compare with reference: `security-engineer.agent.yaml` (BMM module example)
---
## Workflow Path Validation
### Module Workflow Paths
- [ ] Format: `{project-root}/_bmad/{module-code}/workflows/{workflow-name}/workflow.{md|yaml}`
- [ ] Module codes: `bmm`, `bmgd`, `cis`, or custom module
- [ ] Paths are case-sensitive and match actual file structure
### Core Workflow Paths
- [ ] Format: `{project-root}/_bmad/core/workflows/{workflow-name}/workflow.{md|yaml}`
- [ ] Core workflows: `brainstorming`, `party-mode`, `advanced-elicitation`, etc.
---
## What the Compiler Adds (DO NOT validate presence)
These are auto-injected, don't validate for them:
- Frontmatter (`---name/description---`)
- XML activation block
- Menu items: MH (menu/help), CH (chat), PM (party-mode), DA (dismiss/exit)
- Rules section
---
## Common Issues
### Issue: Wrong Module Code
**Wrong:** `module: standalone`
**Fix:** `module: stand-alone` (with hyphen) OR actual module code like `bmm`
### Issue: Hardcoded Workflow Path
**Wrong:** `exec: '../../../bmm/workflows/create-prd/workflow.md'`
**Fix:** `exec: '{project-root}/_bmad/bmm/workflows/create-prd/workflow.md'`
### Issue: Action Instead of Exec for Workflows
**Wrong:** `action: '{project-root}/_bmad/.../workflow.md'`
**Fix:** `exec: '{project-root}/_bmad/.../workflow.md'`
### Issue: Redundant with Existing Agent
**Fix:** Ensure agent fills gap or adds specialized capability not already present in module
@@ -1,30 +1,30 @@
# Persona Properties
The four-field persona system for agent personality.
Four-field system for agent personality definition.
---
## Four-Field System
## Field Overview
Each field serves a DISTINCT purpose when the compiled agent LLM reads them:
| Field | Purpose | Content |
|-------|---------|---------|
| `role` | WHAT agent does | Capabilities, skills, expertise |
| `identity` | WHO agent is | Background, experience, context |
| `communication_style` | HOW agent talks | Verbal patterns, tone, voice |
| `principles` | GUIDES decisions | Beliefs, operating philosophy |
| Field | Purpose | What LLM Interprets |
|-------|---------|---------------------|
| `role` | WHAT the agent does | Capabilities, skills, expertise |
| `identity` | WHO the agent is | Background, experience, context |
| `communication_style` | HOW the agent talks | Verbal patterns, tone, voice |
| `principles` | WHAT GUIDES decisions | Beliefs, operating philosophy |
**Critical:** Keep fields SEPARATE. Do not blur purposes.
**Rule:** Keep fields SEPARATE. Do not blur purposes.
---
## role
**Purpose:** What the agent does - knowledge, skills, capabilities.
**Purpose:** What the agent does - knowledge, skills, capabilities
**Format:** 1-2 lines, professional title or capability description
**MUST NOT:** Background, experience, speech patterns, beliefs
```yaml
# ✅ CORRECT
role: |
@@ -47,10 +47,12 @@ role: |
## identity
**Purpose:** Who the agent is - background, experience, context, flair and personality.
**Purpose:** Who the agent is - background, experience, context, personality
**Format:** 2-5 lines establishing credibility
**MUST NOT:** Capabilities, speech patterns, beliefs
```yaml
# ✅ CORRECT
identity: |
@@ -71,10 +73,12 @@ identity: |
## communication_style
**Purpose:** HOW the agent talks - verbal patterns, word choice, mannerisms.
**Purpose:** HOW the agent talks - verbal patterns, word choice, mannerisms
**Format:** 1-2 sentences MAX describing speech patterns only
**MUST NOT:** Capabilities, background, beliefs, behavioral words
```yaml
# ✅ CORRECT
communication_style: |
@@ -100,16 +104,20 @@ communication_style: |
Analyzes data while speaking... # "analyzes" = role
```
**Purity Test:** Reading aloud, it should sound like describing someone's VOICE, not what they do or who they are.
**Purity Test:** Reading aloud, should describe VOICE only.
**Forbidden words:** ensures, makes sure, always, never, experienced, expert who, senior, seasoned, believes in, focused on, committed to, who does X, that does Y
---
## principles
**Purpose:** What guides decisions - beliefs, operating philosophy, behavioral guidelines.
**Purpose:** What guides decisions - beliefs, operating philosophy, behavioral guidelines
**Format:** 3-8 bullet points or short statements
**MUST NOT:** Capabilities, background, speech patterns
```yaml
# ✅ CORRECT
principles:
@@ -132,9 +140,7 @@ principles:
---
## Field Separation Checklist
Use this to verify purity - each field should ONLY contain its designated content:
## Field Separation Matrix
| Field | MUST NOT Contain |
|-------|------------------|
@@ -143,29 +149,11 @@ Use this to verify purity - each field should ONLY contain its designated conten
| `communication_style` | Capabilities, background, beliefs, behavioral words |
| `principles` | Capabilities, background, speech patterns |
**Forbidden words in `communication_style`:**
- "ensures", "makes sure", "always", "never"
- "experienced", "expert who", "senior", "seasoned"
- "believes in", "focused on", "committed to"
- "who does X", "that does Y"
---
## Reading Aloud Test
For `communication_style`, read it aloud and ask:
- Does this describe someone's VOICE? ✅
- Does this describe what they DO? ❌ (belongs in role)
- Does this describe who they ARE? ❌ (belongs in identity)
- Does this describe what they BELIEVE? ❌ (belongs in principles)
---
## Common Issues
### Issue: Communication Style Soup
## Common Anti-Patterns
### Communication Style Soup
**Wrong:** Everything mixed into communication_style
```yaml
communication_style: |
@@ -190,9 +178,8 @@ principles:
- Collaborative approaches yield better outcomes
```
### Issue: Role Contains Everything
**Wrong:** Role as a catch-all
### Role as Catch-All
**Wrong:** Role contains everything
```yaml
role: |
I am an experienced analyst who speaks like a data scientist,
@@ -216,9 +203,8 @@ principles:
- Clarity over complexity
```
### Issue: Identity Missing
**Wrong:** No identity field
### Missing Identity
**Wrong:** No identity field, background stuffed in role
```yaml
role: |
Senior analyst with 8+ years of experience...
@@ -1,227 +1,130 @@
# Principles Crafting
How to write agent principles that activate expert behavior and define unique character.
**Principles = unique operating philosophy that makes THIS agent behave differently than another agent with the same role.**
---
## The Core Insight
## Core Pattern: First Principle
**Principles are not a job description.** They are the unique operating philosophy that makes THIS agent behave differently than another agent with the same role.
**First principle must activate expert knowledge.**
---
## First Principle Pattern
**The first principle should activate expert knowledge** - tell the LLM to think and behave at an expert level beyond average capability.
```yaml
# ✅ CORRECT - Activates expert knowledge
principles:
- Channel seasoned engineering leadership wisdom: draw upon deep knowledge of management
hierarchies, promotion paths, political navigation, and what actually moves careers forward
- [3-4 more unique principles]
# ❌ WRONG - Generic opener
principles:
- Work collaboratively with stakeholders
- [generic filler]
```
**Template for first principle:**
```
"Channel expert [domain] knowledge: draw upon deep understanding of [key frameworks, patterns, mental models]"
```
| Wrong | Correct |
|-------|---------|
| Work collaboratively with stakeholders | Channel seasoned engineering leadership wisdom: draw upon deep knowledge of management hierarchies, promotion paths, political navigation, and what actually moves careers forward |
---
## What Principles Are NOT
## What Principles Are / Are NOT
| Principles ARE | Principles are NOT |
|----------------|-------------------|
| Unique philosophy | Job description |
| What makes THIS agent different | Generic filler |
| 3-5 focused beliefs | 5-8 obvious duties |
| "I believe X" | "I will do X" (that's a task) |
| "I believe X" | "I will do X" (task) |
| What makes THIS agent different | Generic filler |
**If it's obvious for the role, it doesn't belong in principles.**
**Test: Would this be obvious to anyone in this role? If YES → remove.**
---
## The Thought Process
## Thought Process
1. **What expert knowledge should this agent activate?**
- What frameworks, mental models, or domain expertise?
2. **What makes THIS agent unique?**
- What's the specific angle or philosophy?
- What would another agent with the same role do differently?
3. **What are 3-5 concrete beliefs?**
- Not tasks, not duties - beliefs that guide decisions
1. **What expert knowledge should this agent activate?** (frameworks, mental models, domain expertise)
2. **What makes THIS agent unique?** (specific angle, philosophy, difference from another agent with same role)
3. **What are 3-5 concrete beliefs?** (not tasks, not duties — beliefs that guide decisions)
---
## Good Examples
## Examples
### Engineering Manager Coach (Career-First)
```yaml
role: |
Executive coach specializing in engineering manager development, career navigation,
and organizational dynamics.
principles:
- Channel seasoned engineering leadership wisdom: draw upon deep knowledge of management
hierarchies, promotion paths, political navigation, and what actually moves careers forward
- Channel seasoned engineering leadership wisdom: draw upon deep knowledge of management hierarchies, promotion paths, political navigation, and what actually moves careers forward
- Your career trajectory is non-negotiable - no manager, no company, no "urgent deadline" comes before it
- Protect your manager relationship first - that's the single biggest lever of your career
- Document everything: praise, feedback, commitments - if it's not written down, it didn't happen
- You are not your code - your worth is not tied to output, it's tied to growth and impact
```
**Why it works:**
- First principle activates expert EM knowledge
- "Career is non-negotiable" - fiercely protective stance
- Each principle is a belief, not a task
- 5 focused, unique principles
### Overly Emotional Hypnotist
```yaml
role: |
Hypnotherapist specializing in trance states for behavioral change through emotional resonance.
principles:
- Channel expert hypnotic techniques: leverage NLP language patterns, Ericksonian induction,
suggestibility states, and the neuroscience of trance
- Channel expert hypnotic techniques: leverage NLP language patterns, Ericksonian induction, suggestibility states, and the neuroscience of trance
- Every word must drip with feeling - flat clinical language breaks the spell
- Emotion is the doorway to the subconscious - intensify feelings, don't analyze them
- Your unconscious mind already knows the way - trust what surfaces without judgment
- Tears, laughter, chills - these are signs of transformation, welcome them all
```
**Why it works:**
- First principle activates hypnosis expertise
- "Every word must drip with feeling" - unique emotional twist
- Each principle reinforces the emotional approach
- 5 focused principles
### Product Manager (PRD Facilitator)
```yaml
role: |
Product Manager specializing in collaborative PRD creation through user interviews,
requirement discovery, and stakeholder alignment.
principles:
- Channel expert product manager thinking: draw upon deep knowledge of user-centered design,
Jobs-to-be-Done framework, opportunity scoring, and what separates great products from mediocre ones
- Channel expert product manager thinking: draw upon deep knowledge of user-centered design, Jobs-to-be-Done framework, opportunity scoring, and what separates great products from mediocre ones
- PRDs emerge from user interviews, not template filling - discover what users actually need
- Ship the smallest thing that validates the assumption - iteration over perfection
- Technical feasibility is a constraint, not the driver - user value first
```
**Why it works:**
- First principle activates PM frameworks (JTBD, opportunity scoring)
- "PRDs emerge from interviews" - specific philosophy
- Each principle is a belief, not a process step
- 4 focused principles
### Data Security Analyst
```yaml
role: |
Security analyst specializing in threat modeling and secure code review for web applications.
principles:
- Think like an attacker first: leverage OWASP Top 10, common vulnerability patterns,
and the mindset that finds what others miss
- Think like an attacker first: leverage OWASP Top 10, common vulnerability patterns, and the mindset that finds what others miss
- Every user input is a potential exploit vector until proven otherwise
- Security through obscurity is not security - be explicit about assumptions
- Severity based on exploitability and impact, not theoretical risk
```
**Why it works:**
- First principle activates attacker mindset + OWASP knowledge
- "Every user input is an exploit vector" - specific belief
- Each principle is actionable philosophy
- 4 focused principles
---
## Bad Examples
### Generic Product Manager
## Bad Examples (Avoid These)
```yaml
role: |
Product Manager who creates PRDs and works with teams.
# ❌ Job description, not philosophy
principles:
- Work with stakeholders to understand requirements
- Create clear documentation for features
- Collaborate with engineering teams
- Define timelines and milestones
- Ensure user needs are met
# ❌ This reads like a job posting, not an operating philosophy
```
### Generic Code Reviewer
```yaml
role: |
Code reviewer who checks pull requests for quality.
# ❌ Obvious duties, not unique beliefs
principles:
- Write clean code comments
- Follow best practices
- Be helpful to developers
- Check for bugs and issues
- Maintain code quality standards
# ❌ These are obvious duties, not unique beliefs
```
### Generic Coach
```yaml
role: |
Career coach for professionals.
# ❌ Could apply to ANY agent in this role
principles:
- Listen actively to clients
- Provide actionable feedback
- Help clients set goals
- Track progress over time
- Maintain confidentiality
# ❌ This could apply to ANY coach - what makes THIS agent unique?
```
---
## The Obvious Test
For each principle, ask: **"Would this be obvious to anyone in this role?"**
If YES → Remove it
If NO → Keep it
| Principle | Obvious? | Verdict |
|-----------|----------|---------|
| "Collaborate with stakeholders" | Yes - all PMs do this | ❌ Remove |
| "Every user input is an exploit vector" | No - this is a specific security mindset | ✅ Keep |
| "Write clean code" | Yes - all developers should | ❌ Remove |
| "Your career is non-negotiable" | No - this is a fierce protective stance | ✅ Keep |
| "Document everything" | Borderline - keep if it's a specific philosophy | ✅ Keep |
| "Collaborate with stakeholders" | Yes | ❌ Remove |
| "Every user input is an exploit vector" | No | ✅ Keep |
| "Write clean code" | Yes | ❌ Remove |
| "Your career is non-negotiable" | No | ✅ Keep |
| "Document everything" | Borderline | ✅ Keep if specific philosophy |
---
## Principles Checklist
## Checklist
- [ ] First principle activates expert knowledge
- [ ] 3-5 focused principles (not 5-8 generic ones)
- [ ] 3-5 focused principles
- [ ] Each is a belief, not a task
- [ ] Would NOT be obvious to someone in that role
- [ ] Defines what makes THIS agent unique
@@ -230,63 +133,10 @@ If NO → Keep it
---
## Common Issues
## Common Fixes
### Issue: Principles as Job Description
**Wrong:**
```yaml
principles:
- Facilitate meetings with stakeholders
- Write documentation
- Create reports and presentations
```
**Fix:**
```yaml
principles:
- Channel expert facilitation: draw upon consensus-building frameworks, conflict
resolution techniques, and what makes meetings actually productive
- Documentation exists to enable decisions, not catalog activity
- Meetings without clear outcomes are wastes of time - always define the decision before booking
```
### Issue: Too Many Principles
**Wrong:** 7-8 vague bullet points
**Fix:** Merge related concepts into focused beliefs
```yaml
# Before (7 principles)
- Work collaboratively
- Be transparent
- Communicate clearly
- Listen actively
- Respect others
- Build trust
- Be honest
# After (3 principles)
- Channel expert teamwork: draw upon high-performing team dynamics, psychological safety,
and what separates functional teams from exceptional ones
- Trust requires transparency - share context early, even when incomplete
- Dissent must be safe - if no one disagrees, the meeting didn't need to happen
```
### Issue: Generic Opener
**Wrong:**
```yaml
principles:
- Be professional in all interactions
- Maintain high standards
```
**Fix:**
```yaml
principles:
- Channel expert [domain] wisdom: [specific frameworks, mental models]
- [unique belief 1]
- [unique belief 2]
```
| Issue | Fix |
|-------|-----|
| Principles as job description | Rewrite as beliefs; add expert activation |
| Too many (7-8) | Merge related concepts into focused beliefs |
| Generic opener | "Channel expert [domain] wisdom: [specific frameworks]" |
@@ -1,204 +0,0 @@
# Simple Agent Architecture
Self-contained agents in a single YAML file. No external dependencies, no persistent memory.
---
## When to Use Simple Agents
- Single-purpose utilities (commit helper, formatter, validator)
- Stateless operations (each run is independent)
- All logic fits in ~250 lines
- Menu handlers are short prompts or inline text
- No need to remember past sessions
---
## Complete YAML Structure
```yaml
agent:
metadata:
id: _bmad/agents/{agent-name}/{agent-name}.md
name: 'Persona Name'
title: 'Agent Title'
icon: '🔧'
module: stand-alone # or: bmm, cis, bmgd, other
persona:
role: |
First-person primary function (1-2 sentences)
identity: |
Background, specializations (2-5 sentences)
communication_style: |
How the agent speaks (tone, voice, mannerisms)
principles:
- Core belief or methodology
- Another guiding principle
prompts:
- id: main-action
content: |
<instructions>What this does</instructions>
<process>1. Step one 2. Step two</process>
- id: another-action
content: |
Another reusable prompt
menu:
- trigger: XX or fuzzy match on command
action: '#another-action'
description: '[XX] Command description'
- trigger: YY or fuzzy match on other
action: 'Direct inline instruction'
description: '[YY] Other description'
install_config: # OPTIONAL
compile_time_only: true
description: 'Personalize your agent'
questions:
- var: style_choice
prompt: 'Preferred style?'
type: choice
options:
- label: 'Professional'
value: 'professional'
- label: 'Casual'
value: 'casual'
default: 'professional'
```
---
## Component Details
### Metadata
| Field | Purpose | Example |
|-------|---------|---------|
| `id` | Compiled path | `_bmad/agents/commit-poet/commit-poet.md` |
| `name` | Persona name | "Inkwell Von Comitizen" |
| `title` | Role | "Commit Message Artisan" |
| `icon` | Single emoji | "📜" |
| `module` | `stand-alone` or module code | `stand-alone`, `bmm`, `cis`, `bmgd` |
### Persona
All first-person voice ("I am...", "I do..."):
```yaml
role: "I am a Commit Message Artisan..."
identity: "I understand commit messages are documentation..."
communication_style: "Poetic drama with flair..."
principles:
- "Every commit tells a story - capture the why"
```
### Prompts with IDs
Reusable templates referenced via `#id`:
```yaml
prompts:
- id: write-commit
content: |
<instructions>What this does</instructions>
<process>1. Step 2. Step</process>
menu:
- trigger: WC or fuzzy match on write
action: "#write-commit"
```
**Tips:** Use semantic XML tags (`<instructions>`, `<process>`, `<example>`), keep focused, number steps.
### Menu Actions
Two forms:
1. **Prompt reference:** `action: "#prompt-id"`
2. **Inline instruction:** `action: "Direct text"`
```yaml
# Reference
- trigger: XX or fuzzy match on command
action: "#prompt-id"
description: "[XX] Description"
# Inline
- trigger: YY or fuzzy match on other
action: "Do something specific"
description: "[YY] Description"
```
**Menu format:** `XX or fuzzy match on command` | Descriptions: `[XX] Description`
**Reserved codes:** MH, CH, PM, DA (auto-injected - do NOT use)
### Install Config (Optional)
Compile-time personalization with Handlebars:
```yaml
install_config:
compile_time_only: true
questions:
- var: style_choice
prompt: 'Preferred style?'
type: choice
options: [...]
default: 'professional'
```
Variables available in prompts: `{{#if style_choice == 'casual'}}...{{/if}}`
---
## What the Compiler Adds (DO NOT Include)
- Frontmatter (`---name/description---`)
- XML activation block
- Menu handlers (workflow, exec logic)
- Auto-injected menu items (MH, CH, PM, DA)
- Rules section
**See:** `agent-compilation.md` for details.
---
## Reference Example
**File:** `{workflow_path}/data/reference/simple-examples/commit-poet.agent.yaml`
**Features:** Poetic persona, 4 prompts, 7 menu items, proper `[XX]` codes
**Line count:** 127 lines (within ~250 line guideline)
---
## Validation Checklist
- [ ] Valid YAML syntax
- [ ] All metadata present (id, name, title, icon, module)
- [ ] Persona complete (role, identity, communication_style, principles)
- [ ] Prompt IDs are unique
- [ ] Menu triggers: `XX or fuzzy match on command`
- [ ] Menu descriptions have `[XX]` codes
- [ ] No reserved codes (MH, CH, PM, DA)
- [ ] File named `{agent-name}.agent.yaml`
- [ ] Under ~250 lines
- [ ] No external dependencies
- [ ] No `critical_actions` (Expert only)
---
## Best Practices
1. **First-person voice** in all persona elements
2. **Focused prompts** - one clear purpose each
3. **Semantic XML tags** (`<instructions>`, `<process>`, `<example>`)
4. **Handlebars** for personalization (if using install_config)
5. **Sensible defaults** in install_config
6. **Numbered steps** in multi-step prompts
7. **Keep under ~250 lines** for maintainability
@@ -1,132 +0,0 @@
# Simple Agent Validation Checklist
Validate Simple agents meet BMAD quality standards.
---
## YAML Structure
- [ ] YAML parses without errors
- [ ] `agent.metadata` includes: `id`, `name`, `title`, `icon`, `module`
- [ ] `agent.metadata.module` is `stand-alone` or module code (`bmm`, `cis`, `bmgd`, etc.)
- [ ] `agent.persona` exists with: `role`, `identity`, `communication_style`, `principles`
- [ ] `agent.menu` exists with at least one item
- [ ] File named: `{agent-name}.agent.yaml` (lowercase, hyphenated)
---
## Persona Validation
### Field Separation
- [ ] **role** contains ONLY knowledge/skills/capabilities (what agent does)
- [ ] **identity** contains ONLY background/experience/context (who agent is)
- [ ] **communication_style** contains ONLY verbal patterns (tone, voice, mannerisms)
- [ ] **principles** contains operating philosophy and behavioral guidelines
### Communication Style Purity
- [ ] Does NOT contain: "ensures", "makes sure", "always", "never"
- [ ] Does NOT contain identity words: "experienced", "expert who", "senior", "seasoned"
- [ ] Does NOT contain philosophy words: "believes in", "focused on", "committed to"
- [ ] Does NOT contain behavioral descriptions: "who does X", "that does Y"
- [ ] Is 1-2 sentences describing HOW they talk
- [ ] Reading aloud: sounds like describing someone's voice/speech pattern
---
## Menu Validation
### Required Fields
- [ ] All menu items have `trigger` field
- [ ] All menu items have `description` field
- [ ] All menu items have handler: `action` (Simple agents don't use `exec`)
### Trigger Format
- [ ] Format: `XX or fuzzy match on command-name` (XX = 2-letter code)
- [ ] Codes are unique within agent
- [ ] No reserved codes used: MH, CH, PM, DA (auto-injected)
### Description Format
- [ ] Descriptions start with `[XX]` code
- [ ] Code in description matches trigger code
- [ ] Descriptions are clear and descriptive
### Action Handler
- [ ] If `action: '#prompt-id'`, corresponding prompt exists
- [ ] If `action: 'inline text'`, instruction is complete and clear
---
## Prompts Validation (if present)
- [ ] Each prompt has `id` field
- [ ] Each prompt has `content` field
- [ ] Prompt IDs are unique within agent
- [ ] Prompts use semantic XML tags: `<instructions>`, `<process>`, etc.
---
## Simple Agent Specific
- [ ] Single .agent.yaml file (no sidecar folder)
- [ ] All content contained in YAML (no external file dependencies)
- [ ] No `critical_actions` section (Expert only)
- [ ] Total size under ~250 lines (unless justified)
- [ ] Compare with reference: `commit-poet.agent.yaml`
---
## Path Variables (if used)
- [ ] Paths use `{project-root}` variable (not hardcoded relative paths)
- [ ] No sidecar paths present (Simple agents don't have sidecars)
---
## Quality Checks
- [ ] No broken references or missing files
- [ ] Indentation is consistent
- [ ] Agent purpose is clear from reading persona
- [ ] Agent name/title are descriptive
- [ ] Icon emoji is appropriate
---
## What the Compiler Adds (DO NOT validate presence)
These are auto-injected, don't validate for them:
- Frontmatter (`---name/description---`)
- XML activation block
- Menu items: MH (menu/help), CH (chat), PM (party-mode), DA (dismiss/exit)
- Rules section
---
## Common Issues
### Issue: Communication Style Has Behaviors
**Wrong:** "Experienced analyst who ensures all stakeholders are heard"
**Fix:**
- identity: "Senior analyst with 8+ years..."
- communication_style: "Speaks like a treasure hunter"
- principles: "Ensure all stakeholder voices heard"
### Issue: Wrong Trigger Format
**Wrong:** `trigger: analyze`
**Fix:** `trigger: AN or fuzzy match on analyze`
### Issue: Description Missing Code
**Wrong:** `description: 'Analyze code'`
**Fix:** `description: '[AC] Analyze code'`
@@ -1,222 +1,126 @@
# Understanding Agent Types: Simple VS Expert VS Module
# Understanding Agent Types
> **For the LLM running this workflow:** Load and review the example files referenced below when helping users choose an agent type.
> - Simple examples: `{workflow_path}/data/reference/simple-examples/commit-poet.agent.yaml`
> - Expert examples: `{workflow_path}/data/reference/expert-examples/journal-keeper/`
> - Existing Module addition examples: `{workflow_path}/data/reference/module-examples/security-engineer.agent.yaml`
> **LLM Instructions:** Load example files when helping users:
> - Without sidecar: `{workflow_path}/data/reference/without-sidecar/commit-poet.agent.yaml`
> - With sidecar: `{workflow_path}/data/reference/with-sidecar/journal-keeper/`
---
## What ALL Agent Types Can Do
All three types have equal capability. The difference is **architecture and integration**, NOT power.
- Read, write, and update files
- Execute commands and invoke tools
- Load and use module variables
- Optionally restrict file access (privacy/security)
- Use core module features: party-mode, agent chat, advanced elicitation, brainstorming, document sharding
---
## Quick Reference Decision Tree
**Step 1: Single Agent or Multiple Agents?**
## Decision Tree
```
Multiple personas/roles OR multi-user OR mixed data scope?
├── YES → Use BMAD Module Builder (create module with multiple agents)
└── NO → Single Agent (continue below)
├── YES → Use BMAD Module Builder
└── NO → Single Agent
└── Need memory across sessions?
├── YES → hasSidecar: true
└── NO → hasSidecar: false
```
**Step 2: Memory Needs (for Single Agent)**
```
Need to remember things across sessions?
├── YES → Expert Agent (sidecar with memory)
└── NO → Simple Agent (all in one file)
```
**Step 3: Module Integration (applies to BOTH Simple and Expert)**
```
Extending an existing module (BMM/CIS/BMGD/OTHER)?
├── YES → Module Agent (your Simple/Expert joins the module)
└── NO → Standalone Agent (independent)
```
**Key Point:** Simple and Expert can each be either standalone OR module agents. Memory and module integration are independent decisions.
**Key:** All agents have equal capability. Difference is memory/state management only.
---
## The Three Types
## Without Sidecar (`hasSidecar: false`)
### Simple Agent
**Everything in one file. No external dependencies. No memory.**
**Single file, stateless, ~250 lines max**
```
agent-name.agent.yaml (~250 lines max)
├── metadata
agent-name.agent.yaml
├── metadata.hasSidecar: false
├── persona
├── prompts (inline, small)
└── menu (triggers → #prompt-id or inline actions)
├── prompts (inline)
└── menu (triggers → #prompt-id or inline)
```
**Choose when:**
- Single-purpose utility
- Each session is independent (stateless)
- All knowledge fits in the YAML
- Menu handlers are 5-15 line prompts
| When to Use | Examples |
|-------------|----------|
| Single-purpose utility | Commit Poet |
| Each session independent | Snarky Weather Bot |
| All knowledge fits in YAML | Pun-making Barista |
| Menu handlers 1-2 lines | Motivational Gym Bro |
| Persona-driven (fun/character) | Sassy Fortune Teller |
**Examples:**
- Commit message helper (conventional commits)
- Document formatter/validator
- Joke/teller persona agent
- Simple data transformation and analysis tools
**Reference:** `./data/reference/simple-examples/commit-poet.agent.yaml`
**Optional critical_actions:** Allowed for activation behaviors (quotes, data fetches). Must NOT reference sidecar files.
---
### Expert Agent
## With Sidecar (`hasSidecar: true`)
**Sidecar folder with persistent memory, workflows, knowledge files.**
**Persistent memory, knowledge, workflows**
```
agent-name.agent.yaml
└── agent-name-sidecar/
├── memories.md # User profile, session history, patterns
├── instructions.md # Protocols, boundaries, startup behavior
├── [custom-files].md # Breakthroughs, goals, tracking, etc.
├── workflows/ # Large workflows loaded on demand
└── knowledge/ # Domain reference material
├── memories.md # User profile, session history
├── instructions.md # Protocols, boundaries
├── [custom-files].md # Tracking, goals, etc.
├── workflows/ # Large workflows on-demand
└── knowledge/ # Domain reference
```
**Choose when:**
- Must remember across sessions
- User might create multiple instances each with own memory of actions (such as 2 different developers agents)
- Personal knowledge base that grows
- Learning/evolving over time
- Domain-specific with restricted file access
- Complex multi-step workflows
**Examples:**
- Journal companion (remembers mood patterns, past entries)
- Personal job augmentation agent (knows your role, meetings, projects)
- Therapy/health tracking (progress, goals, insights)
- Domain advisor with custom knowledge base
**Reference:** `./data/reference/expert-examples/journal-keeper/`
| When to Use | Examples |
|-------------|----------|
| Remember across sessions | Journal companion |
| User preferences/settings | Novel writing buddy |
| Personal knowledge base | Job augmentation agent |
| Learning/evolving over time | Therapy/health tracking |
| Domain-specific + restricted access | Fitness coach with PRs |
| Complex multi-step workflows | Language tutor |
**Required critical_actions:**
```yaml
critical_actions:
- "Load COMPLETE file ./sidecar/memories.md"
- "Load COMPLETE file ./sidecar/instructions.md"
- "ONLY read/write files in ./sidecar/ - private space"
- "Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md"
- "Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md"
- "ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/"
```
---
### Module Agent
## Comparison
Two distinct purposes:
#### 1. Extend an Existing Module
Add an agent to BMM, CIS, BMGD, or another existing module.
**Choose when:**
- Adding specialized capability to existing module ecosystem
- Agent uses/contributes shared module workflows
- Coordinates with other agents in the module
- Input/output dependencies on other module agents
**Example:** Adding `security-engineer.agent.yaml` to BMM (software dev module)
- Requires architecture document from BMM architect agent
- Contributes security review workflow to BMM
- Coordinates with analyst, pm, architect, dev agents
**Reference:** `./data/reference/module-examples/security-engineer.agent.yaml`
#### 2. Signal Need for Custom Module
When requirements exceed single-agent scope, suggest the user **use BMAD Module Builder** instead.
**Signals:**
- "I need an HR agent, sales agent, F&I agent, and training coach..."
- "Some info is global/shared across users, some is private per user..."
- "Many workflows, skills, tools, and platform integrations..."
**Example:** Car Dealership Module
- Multiple specialized agents (sales-trainer, service-advisor, sales-manager, F&I)
- Shared workflows (VIN lookup, vehicle research)
- Global knowledge base + per-user private sidecars
- Multi-user access patterns
**→ Use BMAD Module Builder workflow to create the module, then create individual agents within it.**
---
## Side-by-Side Comparison
| Aspect | Simple | Expert |
| ----------------- | ------------------------ | ------------------------------ |
| File structure | Single YAML (~250 lines) | YAML + sidecar/ (150+ + files) |
| Persistent memory | No | Yes |
| Custom workflows | Inline prompts | Sidecar workflows (on-demand) |
| File access | Project/output | Restricted domain |
| Integration | Standalone OR Module | Standalone OR Module |
**Note:** BOTH Simple and Expert can be either standalone agents OR module agents (extending BMM/CIS/BMGD/etc.). Module integration is independent of memory needs.
| Aspect | Without Sidecar | With Sidecar |
|--------|----------------|--------------|
| Structure | Single YAML | YAML + sidecar/ |
| Persistent memory | No | Yes |
| critical_actions | Optional | MANDATORY |
| Workflows | Inline prompts | Sidecar files |
| File access | Project/output | Restricted to sidecar |
| Session state | Stateless | Remembers |
| Best for | Focused skills | Long-term relationships |
---
## Selection Checklist
**Choose Simple if:**
- [ ] One clear purpose
- [ ] No need to remember past sessions
- [ ] All logic fits in ~250 lines
- [ ] Each interaction is independent
**Without sidecar:**
- [ ] One clear purpose, related skills
- [ ] No cross-session memory needed
- [ ] Fits in ~250 lines
- [ ] Independent interactions
- [ ] Persona-driven value
**Choose Expert if:**
- [ ] Needs memory across sessions
**With sidecar:**
- [ ] Memory across sessions
- [ ] Personal knowledge base
- [ ] Domain-specific expertise
- [ ] Restricted file access for privacy
- [ ] Learning/evolving over time
- [ ] Complex workflows in sidecar
**Then, for EITHER Simple or Expert:**
- [ ] Extending existing module (BMM/CIS/BMGD/etc.) → Make it a Module Agent
- [ ] Independent operation → Keep it Standalone
- [ ] Restricted file access
- [ ] Progress tracking/history
- [ ] Complex workflows
**Escalate to Module Builder if:**
- [ ] Multiple distinct personas needed (not one swiss-army-knife agent)
- [ ] Many specialized workflows required
- [ ] Multiple distinct personas needed
- [ ] Many specialized workflows
- [ ] Multiple users with mixed data scope
- [ ] Shared resources across agents
- [ ] Future platform integrations planned
---
## Tips for the LLM Facilitator
## Quick Tips
- If unsure between Simple or Expert → **recommend Expert** (more flexible)
- Multiple personas/skills → **suggest Module Builder**, not one giant agent
- Ask about: memory needs, user count, data scope (global vs private), integration plans
- Load example files when user wants to see concrete implementations
- Reference examples to illustrate differences
---
## Architecture Notes
All three types are equally powerful. The difference is:
- **How they manage state** (memory vs stateless)
- **Where they store data** (inline vs sidecar vs module)
- **How they integrate** (standalone vs module ecosystem)
Choose based on architecture needs, not capability limits.
- Unsure? Ask about **memory needs first**
- Multiple personas → Module Builder, not one giant agent
- Ask: memory needs, user count, data scope, integration plans
- Personality agents → usually without sidecar
- Relationship/coaching agents → usually with sidecar
@@ -46,7 +46,9 @@ Optional creative exploration to generate agent ideas through structured brainst
- Limits: No mandatory brainstorming, no pressure tactics
- Dependencies: User choice to participate or skip brainstorming
## Sequence of Instructions (Do not deviate, skip, or optimize)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Present Brainstorming Opportunity
@@ -3,7 +3,7 @@ name: 'step-02-discovery'
description: 'Discover what user wants holistically'
# File References
nextStepFile: './step-03-type-metadata.md'
nextStepFile: './step-03-sidecar-metadata.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
brainstormContext: ../data/brainstorm-context.md
@@ -108,7 +108,9 @@ After documentation, present menu:
- Clear articulation of value proposition
- Comprehensive capability mapping
# EXECUTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
1. **Load Previous Context**
- Check for brainstormContext file
@@ -1,6 +1,6 @@
---
name: 'step-02-type-metadata'
description: 'Determine agent type and define metadata'
name: 'step-03-sidecar-metadata'
description: 'Determine if agent needs memory (sidecar) and define metadata'
# File References
nextStepFile: './step-04-persona.md'
@@ -9,9 +9,8 @@ agentTypesDoc: ../data/understanding-agent-types.md
agentMetadata: ../data/agent-metadata.md
# Example Agents (for reference)
simpleExample: ../data/reference/simple-examples/commit-poet.agent.yaml
expertExample: ../data/reference/expert-examples/journal-keeper/journal-keeper.agent.yaml
moduleExample: ../data/reference/module-examples/security-engineer.agent.yaml
noSidecarExample: ../data/reference/without-sidecar/commit-poet.agent.yaml
withSidecarExample: ../data/reference/with-sidecar/journal-keeper/journal-keeper.agent.yaml
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
@@ -20,14 +19,14 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# STEP GOAL
Determine the agent's classification (Simple/Expert/Module) and define all mandatory metadata properties required for agent configuration. Output structured YAML to the agent plan file for downstream consumption.
Determine if the agent needs memory (sidecar) and define all mandatory metadata properties required for agent configuration. Output structured YAML to the agent plan file for downstream consumption.
---
# MANDATORY EXECUTION RULES
## Universal Rules
- ALWAYS use `{agent-language}` for all conversational text
- ALWAYS use `{communication_language}` for all conversational text
- MAINTAIN step boundaries - complete THIS step only
- DOCUMENT all decisions to agent plan file
- HONOR user's creative control throughout
@@ -41,9 +40,9 @@ You ARE a master agent architect guiding collaborative agent creation. Balance:
## Step-Specific Rules
- LOAD and reference agentTypesDoc and agentMetadata before conversations
- NEVER skip metadata properties - all are mandatory
- VALIDATE type selection against user's articulated needs
- VALIDATE sidecar decision against user's articulated needs
- OUTPUT structured YAML format exactly as specified
- SHOW examples when type classification is unclear
- SHOW examples when sidecar decision is unclear
---
@@ -51,22 +50,35 @@ You ARE a master agent architect guiding collaborative agent creation. Balance:
## Protocol 1: Documentation Foundation
Load reference materials first:
1. Read agentTypesDoc for classification criteria
1. Read agentTypesDoc for sidecar decision criteria
2. Read agentMetadata for property definitions
3. Keep examples ready for illustration
## Protocol 2: Purpose Discovery
Guide natural conversation to uncover:
- Primary agent function/responsibility
- Complexity level (single task vs multi-domain)
- Scope boundaries (standalone vs manages workflows)
- Integration needs (other agents/workflows)
- Does the agent need to remember things between sessions?
- What should it remember? (user preferences, project state, progress, etc.)
- Or is each interaction independent?
## Protocol 3: Type Determination
Classify based on criteria:
- **Simple**: Single focused purpose, minimal complexity (e.g., code reviewer, documentation generator)
- **Expert**: Advanced domain expertise, multi-capability, manages complex tasks (e.g., game architect, system designer)
- **Module**: Agent builder/manager, creates workflows, deploys other agents (e.g., agent-builder, workflow-builder)
## Protocol 3: Sidecar Determination
Classify based on ONE question:
**Does this agent need to remember things across sessions?**
| If... | hasSidecar |
|-------|------------|
| Each session is independent, nothing to remember | `false` |
| Needs to remember user preferences, progress, project state, etc. | `true` |
**Examples to help user decide:**
| No sidecar needed | With sidecar needed |
|-------------------|---------------------|
| Commit Poet - each commit is independent | Journal companion - remembers moods, patterns |
| Snarky Weather Bot - fresh snark each time | Novel buddy - remembers characters, plot |
| Pun-making Barista - standalone jokes | Fitness coach - tracks your PRs, progress |
| Motivational Gym Bro - hypes you up fresh | Language tutor - knows your vocabulary level |
## Protocol 4: Metadata Definition
Define each property systematically:
@@ -75,15 +87,16 @@ Define each property systematically:
- **title**: Concise function description (one line, action-oriented)
- **icon**: Visual identifier (emoji or short symbol)
- **module**: Module path (format: `{project}:{type}:{name}`)
- **hasSidecar**: Boolean - manages external workflows? (default: false)
- **hasSidecar**: Boolean - does agent need memory? (this is the key decision)
## Protocol 5: Documentation Structure
Output to agent plan file in exact YAML format:
```yaml
# Agent Type & Metadata
agent_type: [Simple|Expert|Module]
classification_rationale: |
# Agent Sidecar Decision & Metadata
hasSidecar: [true|false]
sidecar_rationale: |
[Clear explanation of why this agent does or does not need memory]
metadata:
id: [technical-identifier]
@@ -97,67 +110,68 @@ metadata:
## Protocol 6: Confirmation Menu
Present structured options:
- **[A] Accept** - Confirm and advance to next step
- **[P] Pivot** - Modify type/metadata choices
- **[C] Clarify** - Ask questions about classification
- **[P] Pivot** - Modify sidecar/metadata choices
- **[C] Clarify** - Ask questions about sidecar decision
---
# CONTEXT BOUNDARIES
## In Scope
- Agent type classification
- Sidecar decision (hasSidecar: true/false)
- All 6 metadata properties
- Documentation to plan file
- Type selection guidance with examples
- Sidecar decision guidance with examples
## Out of Scope (Future Steps)
- Persona/character development (Step 3)
- Command structure design (Step 4)
- Agent naming/branding refinement (Step 5)
- Implementation/build (Step 6)
- Validation/testing (Step 7)
- Persona/character development (Step 4)
- Command structure design (Step 5)
- Agent naming/branding refinement (Step 6)
- Implementation/build (Step 7)
- Validation/testing (Step 8)
## Red Flags to Address
- User wants complex agent but selects "Simple" type
- Module classification without workflow management needs
- User wants complex memory but selects hasSidecar: false
- Unclear about what "memory across sessions" means
- Missing or unclear metadata properties
- Module path format confusion
---
# INSTRUCTION SEQUENCE
# MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
## 1. Load Documentation
Read and internalize:
- `{agentTypesDoc}` - Classification framework
- `{agentTypesDoc}` - Sidecar decision framework
- `{agentMetadata}` - Property definitions
- Keep examples accessible for reference
## 2. Purpose Discovery Conversation
Engage user with questions in `{agent-language}`:
- "What is the primary function this agent will perform?"
- "How complex are the tasks this agent will handle?"
- "Will this agent need to manage workflows or other agents?"
- "What specific domains or expertise areas are involved?"
## 2. Sidecar Decision Conversation
Engage user with questions in `{communication_language}`:
- "Should your agent remember things between sessions?"
- "What should it remember? User preferences? Project state? Progress over time?"
- "Or is each interaction independent and fresh?"
Listen for natural language cues about scope and complexity.
Listen for natural language cues about memory needs.
## 3. Agent Type Determination
Based on discovery, propose classification:
- Present recommended type with reasoning
## 3. Sidecar Determination
Based on discovery, propose decision:
- Present recommended hasSidecar value with reasoning
- Show relevant example if helpful
- Confirm classification matches user intent
- Confirm decision matches user intent
- Allow pivoting if user vision evolves
**Conversation Template:**
```
Based on our discussion, I recommend classifying this as a [TYPE] agent because:
Based on our discussion, I recommend hasSidecar: [true/false] because:
[reasoning from discovery]
[If helpful: "For reference, here's a similar [TYPE] agent:"]
[Show relevant example path: simpleExample/expertExample/moduleExample]
[If helpful: "For reference, here's a similar agent:"]
[Show relevant example path: noSidecarExample/withSidecarExample]
Does this classification feel right to you?
Does this feel right to you?
```
## 4. Define All Metadata Properties
@@ -194,10 +208,10 @@ Work through each property systematically:
- Guide user through structure if unfamiliar
**4f. Sidecar Configuration**
- Boolean: manages external workflows?
- Typically false for Simple/Expert agents
- True for Module agents that deploy workflows
- Confirm based on user's integration needs
- Boolean: does agent need memory?
- Most personality-driven agents don't need it
- Most relationship/coaching/tracking agents do need it
- Confirm based on user's memory needs
**Conversation Template:**
```
@@ -219,10 +233,10 @@ Ready to confirm, or should we adjust any properties?
Write to `{agentPlan}`:
```yaml
# Agent Type & Metadata
agent_type: [Simple|Expert|Module]
classification_rationale: |
[Clear explanation of why this type matches user's articulated needs]
# Agent Sidecar Decision & Metadata
hasSidecar: [true|false]
sidecar_rationale: |
[Clear explanation of why this agent does or does not need memory based on user's stated needs]
metadata:
id: [technical-identifier]
@@ -232,12 +246,12 @@ metadata:
module: [project:type:name]
hasSidecar: [true|false]
# Type Classification Notes
type_decision_date: [YYYY-MM-DD]
type_confidence: [High/Medium/Low]
considered_alternatives: |
- [Alternative type]: [reason not chosen]
- [Alternative type]: [reason not chosen]
# Sidecar Decision Notes
sidecar_decision_date: [YYYY-MM-DD]
sidecar_confidence: [High/Medium/Low]
memory_needs_identified: |
- [Specific memory needs if hasSidecar: true]
- [Or: N/A - stateless interactions]
```
### 6. Present MENU OPTIONS
@@ -260,14 +274,14 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [agent type classified and all 6 metadata properties defined and documented], will you then load and read fully `{nextStepFile}` to execute and begin persona development.
ONLY WHEN [C continue option] is selected and [hasSidecar decision made and all 6 metadata properties defined and documented], will you then load and read fully `{nextStepFile}` to execute and begin persona development.
---
# SYSTEM SUCCESS/FAILURE METRICS
## Success Indicators
- Type classification clearly justified
- Sidecar decision clearly justified
- All metadata properties populated correctly
- YAML structure matches specification exactly
- User confirms understanding and acceptance
@@ -276,16 +290,16 @@ ONLY WHEN [C continue option] is selected and [agent type classified and all 6 m
## Failure Indicators
- Missing or undefined metadata properties
- YAML structure malformed
- User confusion about type classification
- User confusion about sidecar decision
- Inadequate documentation to plan file
- Proceeding without user confirmation
## Recovery Mode
If user struggles with classification:
If user struggles with sidecar decision:
- Show concrete examples from each type
- Compare/contrast types with their use case
- Ask targeted questions about complexity/scope
- Offer type recommendation with clear reasoning
- Compare/contrast with their use case
- Ask targeted questions about memory needs
- Offer recommendation with clear reasoning
Recover metadata definition issues by:
- Showing property format examples
@@ -1,5 +1,5 @@
---
name: 'step-03-persona'
name: 'step-04-persona'
description: 'Shape the agent personality through four-field persona system'
# File References
@@ -10,8 +10,8 @@ principlesCrafting: ../data/principles-crafting.md
communicationPresets: ../data/communication-presets.csv
# Example Personas (for reference)
simpleExample: ../data/reference/simple-examples/commit-poet.agent.yaml
expertExample: ../data/reference/expert-examples/journal-keeper/journal-keeper.agent.yaml
simpleExample: ../data/reference/without-sidecar/commit-poet.agent.yaml
expertExample: ../data/reference/with-sidecar/journal-keeper/journal-keeper.agent.yaml
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
@@ -156,7 +156,9 @@ principles:
- Workflow steps (belongs in orchestration)
- Data structures (belongs in implementation)
# EXECUTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
1. **LOAD** personaProperties.md and principlesCrafting.md
2. **EXPLAIN** four-field system with clear examples
@@ -1,5 +1,5 @@
---
name: 'step-04-commands-menu'
name: 'step-05-commands-menu'
description: 'Build capabilities and command structure'
# File References
@@ -8,8 +8,8 @@ agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
# Example Menus (for reference)
simpleExample: ../data/reference/simple-examples/commit-poet.agent.yaml
expertExample: ../data/reference/expert-examples/journal-keeper/journal-keeper.agent.yaml
simpleExample: ../data/reference/without-sidecar/commit-poet.agent.yaml
expertExample: ../data/reference/with-sidecar/journal-keeper/journal-keeper.agent.yaml
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
@@ -121,7 +121,9 @@ menu:
- **User-facing perspective** - triggers should feel natural
- **Capability alignment** - every command maps to a capability
# EXECUTION SEQUENCE
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
1. Load agent-menu-patterns.md to understand structure
2. Review capabilities from agent-plan step 3
@@ -1,18 +1,17 @@
---
name: 'step-05-activation'
name: 'step-06-activation'
description: 'Plan activation behavior and route to build'
# File References
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
criticalActions: ../data/critical-actions.md
# Build Step Routes (determined by agent type)
simpleBuild: './step-07a-build-simple.md'
expertBuild: './step-07b-build-expert.md'
moduleBuild: './step-07c-build-module.md'
# Build Step Route (determined by hasSidecar)
agentBuild: './step-07-build-agent.md'
# Example critical_actions (for reference)
expertExample: ../data/reference/expert-examples/journal-keeper/journal-keeper.agent.yaml
withSidecarExample: ../data/reference/with-sidecar/journal-keeper/journal-keeper.agent.yaml
withoutSidecarExample: ../data/reference/without-sidecar/commit-poet.agent.yaml
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
@@ -20,7 +19,8 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Define activation behavior through critical_actions and route to the appropriate build step based on agent complexity.
Define activation behavior through critical_actions and confirm routing to the build step based on hasSidecar decision.
# MANDATORY EXECUTION RULES
@@ -29,9 +29,9 @@ Define activation behavior through critical_actions and route to the appropriate
- Read agentPlan to access all accumulated metadata
- These are non-negotiable prerequisites
2. **MUST Determine Route Before Activation Discussion**
- Check hasSidecar from plan metadata
- Determine destination build step FIRST
2. **MUST Confirm hasSidecar Decision**
- Check `hasSidecar` from plan metadata (decided in Step 3)
- This determines the build approach
- Inform user of routing decision
3. **MUST Document Activation Decision**
@@ -39,12 +39,11 @@ Define activation behavior through critical_actions and route to the appropriate
- OR document deliberate omission with rationale
- No middle ground - commit to one path
4. **MUST Follow Routing Logic Exactly**
4. **MUST Follow Simple Routing Logic**
```yaml
# Route determination based on hasSidecar and module
hasSidecar: false → step-06-build-simple.md
hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md
# Route determination based on hasSidecar only
hasSidecar: false → Agent without sidecar (single YAML file)
hasSidecar: true → Agent with sidecar (YAML + sidecar folder)
```
5. **NEVER Skip Documentation**
@@ -60,10 +59,9 @@ Execute BEFORE engaging user:
1. Load criticalActions.md
2. Load agentPlan-{agent_name}.md
3. Extract routing metadata:
- hasSidecar (boolean)
- module (string)
- agentType (if defined)
4. Determine destination build step
- hasSidecar (boolean) - decided in Step 3
- All other metadata from prior steps
4. Confirm build approach
## Protocol 2: Routing Disclosure
Inform user immediately of determined route:
@@ -71,9 +69,8 @@ Inform user immediately of determined route:
```
"Based on your agent configuration:
- hasSidecar: {hasSidecar}
- module: {module}
→ Routing to: {destinationStep}
→ Building: Agent {WITH|WITHOUT} sidecar
Now let's plan your activation behavior..."
```
@@ -104,10 +101,10 @@ activation:
hasCriticalActions: true/false
rationale: "Explanation of why or why not"
criticalActions: [] # Only if hasCriticalActions: true
routing:
destinationBuild: "step-06-{X}.md"
buildApproach: "Agent {with|without} sidecar"
hasSidecar: {boolean}
module: "{module}"
```
# CONTEXT BOUNDARIES
@@ -115,21 +112,24 @@ routing:
## In Scope
- Planning activation behavior for the agent
- Defining critical_actions array
- Routing to appropriate build step
- Confirming routing to build step
- Documenting activation decisions
## Out of Scope
- Writing actual activation code (build step)
- Designing sidecar workflows (build step)
- Changing core agent metadata (locked after step 04)
- Changing core agent metadata (locked after Step 4)
- Implementing commands (build step)
## Routing Boundaries
- Simple agents: No sidecar, straightforward activation
- Expert agents: Sidecar + stand-alone module
- Module agents: Sidecar + parent module integration
- **Agent WITHOUT sidecar**: Single YAML file, no persistent memory
- **Agent WITH sidecar**: YAML file + sidecar folder with persistent memory
# EXECUTION SEQUENCE
---
# MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
## 1. Load Reference Documents
```bash
@@ -138,14 +138,26 @@ cat {criticalActions}
cat {agentPlan}
```
## 2. Discuss Activation Needs
## 2. Confirm Routing Decision
Verify hasSidecar decision from Step 3:
```
"Confirming your agent configuration from Step 3:
- hasSidecar: {value from plan}
- This means: {Agent will|will not} remember things between sessions
- Build approach: {Single YAML file|YAML + sidecar folder}
Is this still correct?"
```
## 3. Discuss Activation Needs
Ask user:
- "Should your agent be able to take autonomous actions?"
- "Are there specific workflows it should trigger?"
- "Should it run as a background process or scheduled task?"
- "Or will it primarily respond to direct prompts?"
## 3. Define critical_actions OR Explicitly Omit
## 4. Define critical_actions OR Explicitly Omit
**If defining:**
- Reference criticalActions.md patterns
@@ -153,29 +165,27 @@ Ask user:
- Each action should be clear and scoped
- Document rationale for each
**For agents WITH sidecar, critical_actions MUST include:**
```
- "Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/memories.md"
- "Load COMPLETE file {project-root}/_bmad/_memory/{sidecar-folder}/instructions.md"
- "ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/ - private space"
```
Plus any additional activation behaviors the agent needs.
**For agents WITHOUT sidecar, critical_actions are OPTIONAL and can include:**
```
- "Give user an inspirational quote before showing menu"
- "Fetch latest data from {project-root}/finances/ before displaying menu"
- "Display a quick status summary on activation"
```
Agents without sidecar omit critical_actions entirely if no activation behavior is needed.
**If omitting:**
- State clearly: "This agent will not have critical_actions"
- Explain why: "This agent is a responsive assistant that operates under direct user guidance"
- Document the rationale
## 4. Route to Build Step
Determine destination:
```yaml
# Check plan metadata
hasSidecar: {value from step 04}
module: "{value from step 04}"
# Route logic
if hasSidecar == false:
destination = simpleBuild
elif hasSidecar == true and module == "stand-alone":
destination = expertBuild
else: # hasSidecar == true and module != "stand-alone"
destination = moduleBuild
```
## 5. Document to Plan
Update agentPlan with:
@@ -183,21 +193,17 @@ Update agentPlan with:
```yaml
---
activation:
hasCriticalActions: true
rationale: "Agent needs to autonomously trigger workflows for task automation"
hasCriticalActions: {true/false}
rationale: "Agent needs to autonomously trigger workflows for task automation" OR "Agent operates under direct user guidance"
criticalActions:
- name: "start-workflow"
description: "Initiate a predefined workflow for task execution"
- name: "schedule-task"
description: "Schedule tasks for future execution"
- name: "sync-data"
description: "Synchronize data with external systems"
# ... additional actions if needed
routing:
destinationBuild: "step-06-build-expert.md"
hasSidecar: true
module: "stand-alone"
rationale: "Agent requires sidecar workflows for autonomous operation"
buildApproach: "Agent {with|without} sidecar"
hasSidecar: {true/false}
rationale: "Agent {needs|does not need} persistent memory across sessions"
---
```
@@ -209,7 +215,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {agentPlan}, update frontmatter, determine appropriate build step based on hasSidecar and module values, then only then load, read entire file, then execute {simpleBuild} or {expertBuild} or {moduleBuild} as determined
- IF C: Save content to {agentPlan}, update frontmatter, then only then load, read entire file, then execute {agentBuild}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
#### EXECUTION RULES:
@@ -221,14 +227,13 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
## CRITICAL STEP COMPLETION NOTE
This is the **ROUTING HUB** of agent creation. ONLY WHEN [C continue option] is selected and [routing decision determined with activation needs documented], will you then determine the appropriate build step based on hasSidecar/module values and load and read fully that build step file to execute.
This is the **final planning step** before building. ONLY WHEN [C continue option] is selected and [activation needs documented], will you then load and read fully `{agentBuild}` to execute and build the agent.
Routing logic:
- hasSidecar: false → step-06-build-simple.md
- hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
- hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md
- hasSidecar: false → Agent WITHOUT sidecar (single YAML)
- hasSidecar: true → Agent WITH sidecar (YAML + sidecar folder)
You cannot proceed to build without completing routing.
You cannot proceed to build without completing activation planning.
---
@@ -237,39 +242,36 @@ You cannot proceed to build without completing routing.
✅ **COMPLETION CRITERIA:**
- [ ] criticalActions.md loaded and understood
- [ ] agentPlan loaded with all prior metadata
- [ ] Routing decision determined and communicated
- [ ] Routing decision confirmed (hasSidecar from Step 3)
- [ ] Activation needs discussed with user
- [ ] critical_actions defined OR explicitly omitted with rationale
- [ ] Plan updated with activation and routing metadata
- [ ] User confirms routing to appropriate build step
- [ ] User confirms ready to build
✅ **SUCCESS INDICATORS:**
- Clear activation decision documented
- Route to build step is unambiguous
- User understands why they're going to {simple|expert|module} build
- Route to build is unambiguous
- User understands the build approach
- Plan file reflects complete activation configuration
❌ **FAILURE MODES:**
- Attempting to define critical_actions without reading reference
- Routing decision not documented in plan
- User doesn't understand which build step comes next
- User doesn't understand the build approach
- Ambiguous activation configuration (neither defined nor omitted)
- Skipping routing discussion entirely
- Skipping activation discussion entirely
⚠️ **RECOVERY PATHS:**
⚠️ **RECOVERY PATHS**
If activation planning goes wrong:
1. **Can't decide on activation?**
- Default: Omit critical_actions
- Route to simpleBuild
- Can add later via edit-agent workflow
2. **Uncertain about routing?**
- Check hasSidecar value
- Check module value
- Apply routing logic strictly
3. **User wants to change route?**
- Adjust hasSidecar or module values
- Re-run routing logic
2. **User wants to change hasSidecar?**
- Return to Step 3 to revise decision
- Update plan accordingly
3. **Uncertain about routing?**
- Check hasSidecar value
- Apply simple routing logic
@@ -0,0 +1,315 @@
---
name: 'step-07-build-agent'
description: 'Generate agent YAML from plan (with or without sidecar)'
# File References
nextStepFile: './step-08-celebrate.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
# Output paths (determined by hasSidecar)
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
agentYamlOutputNoSidecar: '{bmb_creations_output_folder}/{agent-name}.agent.yaml'
sidecarOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}-sidecar/'
# Template and Architecture
agentTemplate: ../templates/agent-template.md
agentArch: ../data/agent-architecture.md
agentCompilation: ../data/agent-compilation.md
criticalActions: ../data/critical-actions.md
# Reference examples
noSidecarExample: ../data/reference/without-sidecar/commit-poet.agent.yaml
withSidecarExample: ../data/reference/with-sidecar/journal-keeper/journal-keeper.agent.yaml
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Assemble the agent plan content into a complete agent YAML file. The build approach (with or without sidecar) is determined by the `hasSidecar` decision made in Step 3.
---
# MANDATORY EXECUTION RULES
1. **DETERMINE BUILD APPROACH FIRST**: Check `hasSidecar` from agentPlan before starting
2. **TEMPLATE COMPLIANCE**: Follow agent-template.md structure exactly
3. **YAML VALIDATION**: Ensure valid YAML syntax with proper indentation (2-space)
4. **EXISTING CHECK**: If output file exists, ask user before overwriting
5. **NO DRIFT**: Use ONLY content from agentPlan - no additions or interpretations
6. **SIDECAR REQUIREMENT**: If hasSidecar=true, MUST create sidecar folder structure
---
# EXECUTION PROTOCOLS
## Phase 1: Load Architecture and Templates
1. Read `agentTemplate` - defines YAML structure for agents
2. Read `agentArch` - architecture requirements for agents
3. Read `agentCompilation` - assembly rules for YAML generation
4. Read `criticalActions` - validation requirements for critical_actions
## Phase 2: Load Agent Plan
1. Read `agentPlan` containing all collected content from Steps 2-5
2. Verify plan contains:
- hasSidecar decision (true/false)
- Persona content
- Commands structure
- All metadata fields
- Activation decisions (critical_actions)
## Phase 3: Determine Build Approach
Check `hasSidecar` from plan:
```yaml
hasSidecar: false
→ Build: Agent WITHOUT sidecar
→ Output: Single YAML file at {agentYamlOutputNoSidecar}
→ Structure: Everything in one file (~250 lines max)
hasSidecar: true
→ Build: Agent WITH sidecar
→ Output: YAML + sidecar folder structure
→ Structure: YAML file + {agent-name}-sidecar/ folder
```
**Inform user of build approach:**
```
"Building: Agent {WITH|WITHOUT} sidecar
hasSidecar: {true/false}
Output: {output path description}"
```
## Phase 4: Assemble Agent YAML
### For Agents WITHOUT Sidecar (hasSidecar: false)
**Structure:**
```yaml
name: '{agent-name}'
description: '{short-description}'
author:
name: '{author}'
created: '{date}'
persona: |
{multi-line persona content from plan}
system-context: |
{expanded context from plan}
capabilities:
- {capability from plan}
- {capability from plan}
# ... all capabilities
commands:
- name: '{command-name}'
description: '{what command does}'
trigger: '{menu trigger}'
steps:
- {step 1}
- {step 2}
# ... all commands from plan
configuration:
temperature: {temperature}
max-tokens: {max-tokens}
response-format: {format}
# ... other configuration from plan
metadata:
hasSidecar: false
agent-type: 'agent'
```
**Output:** Single YAML file at `{agentYamlOutputNoSidecar}`
### For Agents WITH Sidecar (hasSidecar: true)
**Structure:**
```yaml
name: '{agent-name}'
description: '{short-description}'
author:
name: '{author}'
created: '{date}'
persona: |
{multi-line persona content from plan}
system-context: |
{expanded context from plan}
capabilities:
- {capability from plan}
- {capability from plan}
# ... all capabilities
critical-actions:
- name: '{action-name}'
description: '{what it does}'
invocation: '{when/how to invoke}'
implementation: |
{multi-line implementation}
output: '{expected-output}'
sidecar-folder: '{sidecar-folder-name}'
sidecar-files:
- '{project-root}/_bmad/_memory/{sidecar-folder}/{file1}.md'
- '{project-root}/_bmad/_memory/{sidecar-folder}/{file2}.md'
# ... all critical actions referencing sidecar structure
commands:
- name: '{command-name}'
description: '{what command does}'
trigger: '{menu trigger}'
steps:
- {step 1}
- {step 2}
# ... all commands from plan
configuration:
temperature: {temperature}
max-tokens: {max-tokens}
response-format: {format}
# ... other configuration from plan
metadata:
sidecar-folder: '{sidecar-folder-name}'
sidecar-path: '{project-root}/_bmad/_memory/{sidecar-folder}/'
hasSidecar: true
agent-type: 'agent'
memory-type: 'persistent'
```
**Output:** YAML file at `{agentYamlOutput}` + sidecar folder structure
### Phase 5: Create Sidecar Structure (IF hasSidecar: true)
Skip this phase if hasSidecar: false
1. **Create Sidecar Directory**:
```bash
mkdir -p {sidecarOutput}
```
2. **Create Starter Files** (if specified in critical_actions):
```bash
touch {sidecarOutput}/memories.md
touch {sidecarOutput}/instructions.md
# ... additional files from critical_actions
```
3. **Add README to Sidecar**:
```markdown
# {sidecar-folder} Sidecar
This folder stores persistent memory for the **{agent-name}** agent.
## Purpose
{purpose from critical_actions}
## Files
- memories.md: User profile, session history, patterns
- instructions.md: Protocols, boundaries, startup behavior
- {additional files}
## Runtime Access
After BMAD installation, this folder will be accessible at:
`{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
```
### Phase 6: Write Agent YAML
**If hasSidecar: false:**
1. Write YAML to `{agentYamlOutputNoSidecar}`
2. Confirm write success
3. Display file location to user
**If hasSidecar: true:**
1. Create directory: `mkdir -p {agentBuildOutput}`
2. Write YAML to `{agentYamlOutput}`
3. Confirm write success
4. Display file location to user
## Phase 7: Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Write agent YAML to appropriate output path (with or without sidecar), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
---
# CONTEXT BOUNDARIES
**INCLUDE:**
- Template structure exactly as provided
- All agent metadata from agentPlan
- Persona, commands, and rules from plan
- Configuration options specified
- Sidecar structure if hasSidecar: true
**EXCLUDE:**
- Any content not in agentPlan
- Sidecar references if hasSidecar: false
- Template placeholders (replace with actual content)
- Comments or notes in final YAML
---
# CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
**This step produces:**
- **If hasSidecar: false**: Single agent YAML file
- **If hasSidecar: true**: Agent YAML file + sidecar folder structure
Both must exist (if applicable) before proceeding to validation.
---
# SUCCESS METRICS
✅ **SUCCESS looks like:**
- Agent YAML file exists at specified output path
- YAML is syntactically valid and well-formed
- All template fields populated with plan content
- Structure matches agent architecture
- If hasSidecar: true, sidecar folder created with starter files
- User has selected continue to proceed
❌ **FAILURE looks like:**
- Template or architecture files not found
- Agent plan missing required sections
- YAML syntax errors in output
- Content not properly mapped to template
- File write operation fails
- hasSidecar: true but sidecar folder not created
---
# TRANSITION CRITERIA
**Ready for Step 8 when:**
- Agent YAML successfully created (with or without sidecar as specified)
- User selects continue
- All build artifacts confirmed written
@@ -1,185 +0,0 @@
---
name: 'step-06-build-simple'
description: 'Generate Simple agent YAML from plan'
# File References
nextStepFile: './step-08a-plan-traceability.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}.agent.yaml'
# Template and Architecture
simpleTemplate: ../templates/simple-agent.template.md
simpleArch: ../data/simple-agent-architecture.md
agentCompilation: ../data/agent-compilation.md
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Assemble the agent plan content into a Simple agent YAML configuration using the template, producing a complete agent definition ready for validation.
## MANDATORY EXECUTION RULES
- **MUST** read all referenced files before beginning assembly
- **MUST** use exact YAML structure from template
- **MUST** preserve all plan content without modification
- **MUST** maintain proper YAML indentation and formatting
- **MUST NOT** deviate from template structure
- **MUST** write output before asking validation question
- **MUST** present validation choice clearly
## EXECUTION PROTOCOLS
### File Loading Sequence
1. Read `simpleTemplate` - provides the YAML structure
2. Read `simpleArch` - defines Simple agent architecture rules
3. Read `agentCompilation` - provides assembly guidelines
4. Read `agentPlan` - contains structured content from steps 2-5
### YAML Assembly Process
1. Parse template structure
2. Extract content sections from agentPlan YAML
3. Map plan content to template fields
4. Validate YAML syntax before writing
5. Write complete agent YAML to output path
## CONTEXT BOUNDARIES
**INCLUDE:**
- Template structure exactly as provided
- All agent metadata from agentPlan
- Persona, commands, and rules from plan
- Configuration options specified
**EXCLUDE:**
- Any content not in agentPlan
- Sidecar file references (Simple agents don't use them)
- Template placeholders (replace with actual content)
- Comments or notes in final YAML
## EXECUTION SEQUENCE
### 1. Load Template and Architecture Files
Read the following files in order:
- `simpleTemplate` - YAML structure template
- `simpleArch` - Simple agent architecture definition
- `agentCompilation` - Assembly instructions
**Verify:** All files loaded successfully.
### 2. Load Agent Plan
Read `agentPlan` which contains structured YAML from steps 2-5:
- Step 2: Discovery findings
- Step 3: Persona development
- Step 4: Command structure
- Step 5: Agent naming
**Verify:** Plan contains all required sections.
### 3. Assemble YAML Using Template
Execute the following assembly process:
1. **Parse Template Structure**
- Identify all YAML fields
- Note required vs optional fields
- Map field types and formats
2. **Extract Plan Content**
- Read agent metadata
- Extract persona definition
- Retrieve command specifications
- Gather rules and constraints
3. **Map Content to Template**
- Replace template placeholders with plan content
- Maintain exact YAML structure
- Preserve indentation and formatting
- Validate field types and values
4. **Validate YAML Syntax**
- Check proper indentation
- Verify quote usage
- Ensure list formatting
- Confirm no syntax errors
**Verify:** YAML is valid, complete, and follows template structure.
### 4. Write Agent Build Output
Write the assembled YAML to `agentBuildOutput`:
- Use exact output path from variable
- Include all content without truncation
- Maintain YAML formatting
- Confirm write operation succeeded
**Verify:** File written successfully and contains complete YAML.
### 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
### 6. Route Based on User Choice
**If user chooses "one-at-a-time":**
- Proceed to `nextStepFile` (step-07a-plan-traceability.md)
- Continue through each validation step sequentially
- Allow review between each validation
**If user chooses "YOLO":**
- Run all validation steps (7A through 7F) consecutively
- Do not pause between validations
- After all validations complete, proceed to Step 8
- Present summary of all validation results
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
## SUCCESS METRICS
**SUCCESS looks like:**
- Agent YAML file exists at specified output path
- YAML is syntactically valid and well-formed
- All template fields populated with plan content
- Structure matches Simple agent architecture
- User has selected validation approach
- Clear next step identified
**FAILURE looks like:**
- Template or architecture files not found
- Agent plan missing required sections
- YAML syntax errors in output
- Content not properly mapped to template
- File write operation fails
- User selection unclear
## TRANSITION CRITERIA
**Ready for Step 7A when:**
- Simple agent YAML successfully created
- User chooses "one-at-a-time" validation
**Ready for Step 8 when:**
- Simple agent YAML successfully created
- User chooses "YOLO" validation
- All validations (7A-7F) completed consecutively
@@ -1,201 +0,0 @@
---
name: 'step-06-build-expert'
description: 'Generate Expert agent YAML with sidecar from plan'
# File References
nextStepFile: './step-08a-plan-traceability.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Template and Architecture
expertTemplate: ../templates/expert-agent-template/expert-agent.template.md
expertArch: ../data/expert-agent-architecture.md
agentCompilation: ../data/agent-compilation.md
criticalActions: ../data/critical-actions.md
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage for specialized operations, accessed via `{project-root}/_bmad/_memory/{sidecar-folder}/` paths in critical_actions.
## MANDATORY EXECUTION RULES
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created under `_bmad/_memory/`
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations
3. **TEMPLATE COMPLIANCE**: Follow expert-agent-template.md structure exactly
4. **YAML VALIDATION**: Ensure valid YAML syntax with proper indentation (2-space)
5. **EXISTING CHECK**: If agentYamlOutput exists, ask user before overwriting
6. **NO DRIFT**: Use ONLY content from agentPlan - no additions or interpretations
## EXECUTION PROTOCOLS
### Phase 1: Load Architecture and Templates
1. Read `expertTemplate` - defines YAML structure for Expert agents
2. Read `expertArch` - architecture requirements for Expert-level agents
3. Read `agentCompilation` - assembly rules for YAML generation
4. Read `criticalActions` - validation requirements for critical_actions
### Phase 2: Load Agent Plan
1. Read `agentPlan` containing all collected content from Steps 1-5
2. Verify plan contains:
- Agent type: "expert"
- Sidecar folder name
- Persona content
- Commands structure
- Critical actions (if applicable)
### Phase 3: Assemble Expert YAML
Using expertTemplate as structure:
```yaml
name: '{agent-name}'
description: '{short-description}'
type: 'expert'
version: '1.0.0'
author:
name: '{author}'
created: '{date}'
persona: |
{multi-line persona content from plan}
system-context: |
{expanded context from plan}
capabilities:
- {capability from plan}
- {capability from plan}
# ... all capabilities
critical-actions:
- name: '{action-name}'
description: '{what it does}'
invocation: '{when/how to invoke}'
implementation: |
{multi-line implementation}
output: '{expected-output}'
sidecar-folder: '{sidecar-folder-name}'
sidecar-files:
- '{project-root}/_bmad/_memory/{sidecar-folder}/{file1}.md'
- '{project-root}/_bmad/_memory/{sidecar-folder}/{file2}.md'
# ... all critical actions referencing sidecar structure
commands:
- name: '{command-name}'
description: '{what command does}'
steps:
- {step 1}
- {step 2}
# ... all commands from plan
configuration:
temperature: {temperature}
max-tokens: {max-tokens}
response-format: {format}
# ... other configuration from plan
metadata:
sidecar-folder: '{sidecar-folder-name}'
sidecar-path: '{project-root}/_bmad/_memory/{sidecar-folder}/'
agent-type: 'expert'
memory-type: 'persistent'
```
### Phase 4: Create Sidecar Structure
1. **Create Sidecar Directory**:
- Path: `{project-root}/_bmad/_memory/{sidecar-folder}/`
- Use `mkdir -p` to create full path
2. **Create Starter Files** (if specified in critical_actions):
```bash
touch _bmad/_memory/{sidecar-folder}/{file1}.md
touch _bmad/_memory/{sidecar-folder}/{file2}.md
```
3. **Add README to Sidecar**:
```markdown
# {sidecar-folder} Memory
This folder stores persistent memory for the **{agent-name}** Expert agent.
## Purpose
{purpose from critical_actions}
## Files
- {file1}.md: {description}
- {file2}.md: {description}
## Access Pattern
Agent accesses these files via: `{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
```
### Phase 5: Write Agent YAML
1. Create `agentBuildOutput` directory: `mkdir -p {agentBuildOutput}`
2. Write YAML to `agentYamlOutput`
3. Confirm write success
4. Display file location to user
### Phase 6: Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#phase-6-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CONTEXT BOUNDARIES
- **USE ONLY**: Content from agentPlan, expertTemplate, expertArch, agentCompilation, criticalActions
- **DO NOT ADD**: New capabilities, commands, or actions not in plan
- **DO NOT INTERPRET**: Use exact language from plan
- **DO NOT SKIP**: Any field in expertTemplate structure
- **CRITICAL**: Expert agents MUST have sidecar-folder metadata
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
This step produces TWO artifacts:
1. **Agent YAML**: Complete expert agent definition at `{agentYamlOutput}`
2. **Sidecar Structure**: Folder and files at `{project-root}/_bmad/_memory/{sidecar-folder}/`
Both must exist before proceeding to validation.
## SUCCESS METRICS
✅ Agent YAML file created at expected location
✅ Valid YAML syntax (no parse errors)
✅ All template fields populated
✅ Sidecar folder created under `_bmad/_memory/`
✅ Sidecar folder contains starter files from critical_actions
✅ critical_actions reference `{project-root}/_bmad/_memory/{sidecar-folder}/` paths
✅ metadata.sidecar-folder populated
✅ metadata.agent-type = "expert"
✅ User validation choice received (one-at-a-time or YOLO)
## FAILURE MODES
❌ Missing required template fields
❌ Invalid YAML syntax
❌ Sidecar folder creation failed
❌ critical_actions missing sidecar-folder references
❌ agentPlan missing expert-specific content (sidecar-folder name)
❌ File write permission errors
@@ -1,258 +0,0 @@
---
name: 'step-06-build-module'
description: 'Generate Module agent YAML from plan'
# File References
nextStepFile: './step-08a-plan-traceability.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Template and Architecture (use expert as baseline)
expertTemplate: ../templates/expert-agent-template/expert-agent.template.md
expertArch: ../data/expert-agent-architecture.md
agentCompilation: ../data/agent-compilation.md
criticalActions: ../data/critical-actions.md
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Assemble the Module agent YAML file from the approved plan, using the expert agent template as the baseline architecture and adding module-specific workflow integration paths and sidecar configuration.
# MANDATORY EXECUTION RULES
1. **TEMPLATE BASELINE**: Module agents MUST use the expert agent template as their structural foundation - do not create custom templates
2. **PLAN ADHERENCE**: Extract content from agentPlan exactly as written - no enhancement, interpretation, or extrapolation
3. **MODULE SPECIFICITY**: Module agents require workflow integration paths and may need sidecar configuration for multi-workflow modules
4. **OUTPUT VALIDATION**: YAML must be valid, complete, and ready for immediate deployment
5. **LANGUAGE PRESERVATION**: Maintain any language choice configured in the plan throughout the YAML
# EXECUTION PROTOCOLS
## PREPARATION PHASE
### 1. Load Expert Template Baseline
```
Read: expertTemplate
Read: expertArch
Read: agentCompilation
Read: criticalActions
```
**Purpose**: Understand the expert agent structure that serves as the Module agent baseline
**Validation**: Confirm expert template has all required sections (name, description, persona, instructions, tools, skills, etc.)
### 2. Load Agent Plan
```
Read: agentPlan (using dynamic path)
```
**Validation**: Plan contains all mandatory sections:
- Agent identity (name, description)
- Persona profile
- Command structure
- Critical actions
- Workflow integrations (module-specific)
- Language choice (if configured)
### 3. Verify Output Directory
```
Bash: mkdir -p {agentBuildOutput}
```
**Purpose**: Ensure output directory exists for the module agent
## ASSEMBLY PHASE
### 4. Assemble Module Agent YAML
**FROM PLAN TO YAML MAPPING:**
| Plan Section | YAML Field | Notes |
|--------------|------------|-------|
| Agent Name | `name` | Plan → YAML |
| Description | `description` | Plan → YAML |
| Persona | `persona` | Plan → YAML |
| Instructions | `instructions` | Plan → YAML (verbatim) |
| Commands | `commands` | Plan → YAML (with handlers) |
| Critical Actions | `criticalActions` | Plan → YAML (mandatory) |
| Workflow Paths | `skills` | Module-specific |
| Sidecar Need | `sidecar` | If multi-workflow |
**MODULE-SPECIAL ENHANCEMENTS:**
```yaml
# Module agents include workflow integration
skills:
- workflow: "{project-root}/_bmad/{module-id}/workflows/{workflow-name}/workflow.md"
description: "From plan workflow list"
- workflow: "{project-root}/_bmad/{module-id}/workflows/{another-workflow}/workflow.md"
description: "From plan workflow list"
# Optional: Sidecar for complex modules
sidecar:
enabled: true
workflows:
- ref: "primary-workflow"
type: "primary"
- ref: "secondary-workflow"
type: "support"
```
**CRITICAL ACTIONS MAPPING:**
```
For each critical action in plan:
1. Identify matching command in YAML
2. Add `critical: true` flag
3. Ensure handler references agent function
```
### 5. Create Sidecar (If Needed)
**SIDEAR REQUIRED IF:**
- Module has 3+ workflows
- Workflows have complex interdependencies
- Module needs initialization workflow
**SIDECAR STRUCTURE:**
```yaml
# {agent-name}.sidecar.yaml
sidecar:
module: "{module-id}"
initialization:
workflow: "workflow-init"
required: true
workflows:
- name: "workflow-name"
path: "workflows/{workflow-name}/workflow.md"
type: "primary|support|utility"
dependencies: []
agent:
path: "{agent-name}.agent.yaml"
```
**IF SIDEAR NOT NEEDED**: Skip this step
### 6. Write Module Agent YAML
```
Write: agentYamlOutput (using dynamic path)
Content: Assembled YAML from step 4
```
**Validation Checklist:**
- [ ] All plan fields present in YAML
- [ ] Workflow paths are valid and correct
- [ ] Critical actions flagged
- [ ] Sidecar created (if needed) or skipped (if not)
- [ ] YAML syntax is valid
- [ ] Language choice preserved throughout
## COMPLETION PHASE
### 7. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
**USER RESPONSE HANDLING:**
- **Option 1**: Proceed to step-07a-plan-traceability.md with sequential mode
- **Option 2**: Proceed to step-07a-plan-traceability.md with yolo mode
- **Invalid input**: Re-ask with options
# CONTEXT BOUNDARIES
**IN SCOPE:**
- Reading expert template and architecture
- Loading agent plan
- Assembling Module agent YAML
- Creating sidecar (if needed)
- Writing valid YAML output
**OUT OF SCOPE:**
- Modifying plan content
- Creating new template structures
- Implementing agent code
- Writing workflow files
- Testing agent functionality
**DO NOT:**
- Add commands not in plan
- Modify persona from plan
- Create custom template structures
- Skip critical actions mapping
- Assume sidecar need - evaluate based on workflow count
# CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
**THIS STEP IS COMPLETE WHEN:**
1. Module agent YAML file exists at agentYamlOutput path
2. YAML contains all plan content correctly mapped
3. Module-specific workflow paths are configured
4. Sidecar is created (if needed) or correctly skipped (if not)
5. User has chosen review mode (one-at-a-time or YOLO)
6. Ready to proceed to step-07a-plan-traceability.md
**STOP BEFORE:**
- Writing workflow implementations
- Creating agent code files
- Testing agent functionality
- Deploying to active system
# SUCCESS METRICS
**COMPLETION:**
- [ ] Module agent YAML exists with all required fields
- [ ] All plan content accurately mapped to YAML
- [ ] Workflow integration paths configured correctly
- [ ] Critical actions properly flagged
- [ ] Sidecar created or correctly skipped
- [ ] YAML syntax is valid
- [ ] User confirms review mode choice
- [ ] Transitions to step-07a-plan-traceability.md
**VALIDATION:**
- Plan-to-YAML mapping: 100% accuracy
- Workflow paths: All valid and correct
- Critical actions: All present and flagged
- Sidecar decision: Correctly evaluated
- Language choice: Preserved throughout
# FAILURE MODES
**IF PLAN MISSING CONTENT:**
→ Return to step-02-discover.md to complete plan
**IF EXPERT TEMPLATE MISSING:**
→ Raise error - template is mandatory baseline
**IF YAML SYNTAX ERROR:**
→ Fix and retry write operation
**IF WORKFLOW PATHS INVALID:**
→ Flag for review in traceability step
**IF USER ASKS FOR MODIFICATIONS:**
→ Return to appropriate planning step (03-persona, 04-commands, or 05-name)
@@ -1,9 +1,9 @@
---
name: 'step-09-celebrate'
name: 'step-08-celebrate'
description: 'Celebrate completion and guide next steps for using the agent'
# File References
thisStepFile: ./step-09-celebrate.md
thisStepFile: ./step-08-celebrate.md
workflowFile: ../workflow.md
outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
@@ -11,9 +11,10 @@ outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
installationDocs: 'https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/modules/bmb-bmad-builder/custom-content-installation.md#standalone-content-agents-workflows-tasks-tools-templates-prompts'
validationWorkflow: '{project-root}/src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md'
---
# Step 9: Celebration and Installation Guidance
# Step 8: Celebration and Installation Guidance
## STEP GOAL:
@@ -59,7 +60,9 @@ Celebrate the successful agent creation, recap the agent's capabilities, provide
- Limits: No agent modifications, only installation guidance and celebration
- Dependencies: Complete agent ready for installation
## Sequence of Instructions (Do not deviate, skip, or optimize)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change. (Do not deviate, skip, or optimize)
### 1. Grand Celebration
@@ -196,25 +199,27 @@ Save this content to `{outputFile}` for reference.
### 7. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
Display: "**✅ Agent Build Complete! Select an Option:** [V] Run Validation [S] Skip - Complete Now [A] Advanced Elicitation [P] Party Mode"
#### Menu Handling Logic:
- IF V: "Loading validation phase..." → Save celebration content to {outputFile}, update frontmatter with build completion, then load, read entire file, then execute {validationWorkflow}
- IF S: "Skipping validation. Completing workflow..." → Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF X: Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY complete workflow when user selects 'X'
- After other menu items execution, return to this menu
- User can choose validation (V), skip to complete (S), or use advanced elicitation (A) or party mode (P)
- After other menu items execution (A/P), return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [X exit option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
ONLY WHEN [S skip option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
IF [V validation option] is selected, the validation workflow will be loaded to perform comprehensive validation checks.
---
@@ -1,203 +0,0 @@
---
name: 'step-07a-plan-traceability'
description: 'Verify build matches original plan'
# File References
nextStepFile: './step-08b-metadata-validation.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Verify that the built agent YAML file contains all elements specified in the original agent plan. This step ensures plan traceability - confirming that what we planned is what we actually built.
# MANDATORY EXECUTION RULES
- MUST load both agentPlan and builtYaml files before comparison
- MUST compare ALL planned elements against built implementation
- MUST report specific missing items, not just "something is missing"
- MUST offer fix option before proceeding to next validation
- MUST handle missing files gracefully (report clearly, don't crash)
- MUST respect YOLO mode behavior (part of combined validation report)
# EXECUTION PROTOCOLS
## File Loading Protocol
1. Load agentPlan from `{bmb_creations_output_folder}/agent-plan-{agent_name}.md`
2. Load builtYaml from `{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml`
3. If either file is missing, report the specific missing file and stop comparison
4. Use Read tool to access both files with absolute paths
## Comparison Protocol
Compare the following categories systematically:
### 1. Metadata Comparison
- Agent name
- Description
- Version
- Author/creator information
- Location/module path
- Language settings (if specified in plan)
### 2. Persona Field Comparison
For each field in persona section:
- Check presence in built YAML
- Verify field content matches planned intent
- Note any significant deviations (minor wording differences ok)
### 3. Commands Comparison
- Verify all planned commands are present
- Check command names match
- Verify command descriptions are present
- Confirm critical actions are referenced
### 4. Critical Actions Comparison
- Verify all planned critical_actions are present
- Check action names match exactly
- Verify action descriptions are present
- Confirm each action has required fields
### 5. Additional Elements
- Dependencies (if planned)
- Configuration (if planned)
- Installation instructions (if planned)
## Reporting Protocol
Present findings in clear, structured format:
```
PLAN TRACEABILITY REPORT
========================
Agent: {agent_name}
Plan File: {path to agent plan}
Build File: {path to built YAML}
COMPARISON RESULTS:
-------------------
✅ Metadata: All present / Missing: {list}
✅ Persona Fields: All present / Missing: {list}
✅ Commands: All present / Missing: {list}
✅ Critical Actions: All present / Missing: {list}
✅ Other Elements: All present / Missing: {list}
OVERALL STATUS: [PASS / FAIL]
```
If ANY elements are missing:
- List each missing element with category
- Provide specific location reference (what was planned)
- Ask if user wants to fix items or continue anyway
## Menu Protocol
### 8. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified missing elements, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
If YOLO mode:
- Include this report in combined validation report
- Auto-select [C] Continue if all elements present
- Auto-select [F] Fix if missing critical elements (name, commands)
- Flag non-critical missing items in summary
# CONTEXT BOUNDARIES
- ONLY compare plan vs build - do NOT evaluate quality or correctness
- Do NOT suggest improvements or changes beyond planned elements
- Do NOT re-open persona/commands discovery - this is verification only
- Fix option should return to step-06-build, not earlier steps
- If plan file is ambiguous, note ambiguity but use reasonable interpretation
# SEQUENCE
## 1. Load Required Files
```yaml
action: read
target:
- agentPlan
- builtYaml
on_failure: report which file is missing and suggest resolution
```
## 2. Perform Structured Comparison
```yaml
action: compare
categories:
- metadata
- persona_fields
- commands
- critical_actions
- other_elements
method: systematic category-by-category check
```
## 3. Generate Comparison Report
```yaml
action: report
format: structured pass/fail with specific missing items
output: console display + optional save to validation log
```
## 4. Present Menu Options
```yaml
action: menu
options:
- F: Fix missing items
- C: Continue to metadata validation
- V: View detailed comparison (optional)
default: C if pass, F if fail
```
## 5. Handle User Choice
- **[F] Fix Findings**: Apply auto-fixes to {builtYaml} for identified missing elements, then re-present menu
- **[C] Continue**: Proceed to step-07b-metadata-validation
- **[A] Advanced Elicitation**: Execute advanced elicitation workflow, then re-present menu
- **[P] Party Mode**: Execute party mode workflow, then re-present menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [metadata validation].
# SUCCESS/FAILURE METRICS
## Success Criteria
- All planned elements present in built YAML: **COMPLETE PASS**
- Minor deviations (wording, formatting) but all core elements present: **PASS**
- Missing elements identified and user chooses to continue: **PASS WITH NOTED DEFICIENCIES**
## Failure Criteria
- Unable to load plan or build file: **BLOCKING FAILURE**
- Critical elements missing (name, commands, or critical_actions): **FAIL**
- Comparison cannot be completed due to file corruption: **BLOCKING FAILURE**
## Next Step Triggers
- **PASS → step-07b-metadata-validation**
- **PASS WITH DEFICIENCIES → step-07b-metadata-validation** (user choice)
- **FAIL → step-06-build** (with specific fix instructions)
- **BLOCKING FAILURE → STOP** (resolve file access issues first)
## YOLO Mode Behavior
- Auto-fix missing critical elements by returning to build step
- Log non-critical missing items for review but continue validation
- Include traceability report in final YOLO summary
- Do NOT stop for user confirmation unless plan file is completely missing
@@ -1,135 +0,0 @@
---
name: 'step-07b-metadata-validation'
description: 'Validate agent metadata properties'
# File References
nextStepFile: './step-08c-persona-validation.md'
agentMetadata: ../data/agent-metadata.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate that the agent's metadata properties (name, description, version, tags, category, etc.) are properly formatted, complete, and follow BMAD standards.
## MANDATORY EXECUTION RULES
- **NEVER skip validation checks** - All metadata fields must be verified
- **ALWAYS load both reference documents** - agentMetadata.md AND the builtYaml
- **NEVER modify files without user approval** - Report findings first, await menu selection
- **ALWAYS use absolute paths** when referencing files
- **CRITICAL:** This is a validation step, not an editing step
## EXECUTION PROTOCOLS
### Protocol 1: Load and Compare
1. Read the metadata validation reference from `{agentMetadata}`
2. Read the built agent YAML from `{builtYaml}`
3. Extract the metadata section from the builtYaml
4. Compare actual metadata against validation rules
### Protocol 2: Validation Checks
Perform these checks systematically:
1. **Required Fields Existence**
- [ ] name: Present and non-empty
- [ ] description: Present and non-empty
- [ ] version: Present and follows semantic versioning (X.Y.Z)
- [ ] category: Present and matches valid category
- [ ] tags: Present as array, not empty
2. **Format Validation**
- [ ] name: Uses kebab-case, no spaces
- [ ] description: 50-200 characters (unless intentionally brief)
- [ ] version: Follows semver pattern (e.g., 1.0.0)
- [ ] tags: Array of lowercase strings with hyphens
- [ ] category: Matches one of the allowed categories
3. **Content Quality**
- [ ] description: Clear and concise, explains what the agent does
- [ ] tags: Relevant to agent's purpose (3-7 tags recommended)
- [ ] category: Most appropriate classification
4. **Standards Compliance**
- [ ] No prohibited characters in fields
- [ ] No redundant or conflicting information
- [ ] Consistent formatting with other agents
### Protocol 3: Report Findings
Organize your report into three sections:
**PASSING CHECKS** (List what passed)
```
✓ Required fields present
✓ Version format valid (1.0.0)
✓ Name follows kebab-case convention
```
**WARNINGS** (Non-blocking issues)
```
⚠ Description is brief (45 chars, recommended 50-200)
⚠ Only 2 tags provided, 3-7 recommended
```
**FAILURES** (Blocking issues that must be fixed)
```
✗ Missing required field: version
✗ Invalid version format: "v1.0" (should be "1.0.0")
✗ Category "custom-type" not in allowed list
```
### Protocol 4: Menu System
#### 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CONTEXT BOUNDARIES
**IN SCOPE:**
- Metadata section of agent.yaml (name, description, version, tags, category, author, license, etc.)
- Referencing the agentMetadata.md validation rules
- Comparing against BMAD standards
**OUT OF SCOPE:**
- Persona fields (handled in step-07c)
- Menu items (handled in step-07d)
- System architecture (handled in step-07e)
- Capability implementation (handled in step-07f)
**DO NOT:**
- Validate persona properties in this step
- Suggest major feature additions
- Question the agent's core purpose
- Modify fields beyond metadata
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [persona validation].
## SUCCESS METRICS
✓ **Complete Success:** All checks pass, no failures, warnings are optional
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
✓ **Failure:** Blocking failures remain when user selects [C]
**CRITICAL:** Never proceed to next step if blocking failures exist and user hasn't acknowledged them.
@@ -1,161 +0,0 @@
---
name: 'step-07c-persona-validation'
description: 'Validate persona fields and principles'
# File References
nextStepFile: './step-08d-menu-validation.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate that the agent's persona (role, tone, expertise, principles, constraints) is well-defined, consistent, and aligned with its purpose.
## MANDATORY EXECUTION RULES
- **NEVER skip validation checks** - All persona fields must be verified
- **ALWAYS load both reference documents** - personaProperties.md AND principlesCrafting.md
- **NEVER modify files without user approval** - Report findings first, await menu selection
- **ALWAYS use absolute paths** when referencing files
- **CRITICAL:** This is a validation step, not an editing step
## EXECUTION PROTOCOLS
### Protocol 1: Load and Compare
1. Read the persona validation reference from `{personaProperties}`
2. Read the principles crafting guide from `{principlesCrafting}`
3. Read the built agent YAML from `{builtYaml}`
4. Extract the persona section from the builtYaml
5. Compare actual persona against validation rules
### Protocol 2: Validation Checks
Perform these checks systematically:
1. **Required Fields Existence**
- [ ] role: Present, clear, and specific
- [ ] tone: Present and appropriate to role
- [ ] expertise: Present and relevant to agent's purpose
- [ ] principles: Present as array, not empty (if applicable)
- [ ] constraints: Present as array, not empty (if applicable)
2. **Content Quality - Role**
- [ ] Role is specific (not generic like "assistant")
- [ ] Role aligns with agent's purpose and menu items
- [ ] Role is achievable within LLM capabilities
- [ ] Role scope is appropriate (not too broad/narrow)
3. **Content Quality - Tone**
- [ ] Tone is clearly defined (professional, friendly, authoritative, etc.)
- [ ] Tone matches the role and target users
- [ ] Tone is consistent throughout the definition
- [ ] Tone examples or guidance provided if nuanced
4. **Content Quality - Expertise**
- [ ] Expertise areas are relevant to role
- [ ] Expertise claims are realistic for LLM
- [ ] Expertise domains are specific (not just "knowledgeable")
- [ ] Expertise supports the menu capabilities
5. **Content Quality - Principles**
- [ ] Principles are actionable (not vague platitudes)
- [ ] Principles guide behavior and decisions
- [ ] Principles are consistent with role
- [ ] 3-7 principles recommended (not overwhelming)
- [ ] Each principle is clear and specific
6. **Content Quality - Constraints**
- [ ] Constraints define boundaries clearly
- [ ] Constraints are enforceable (measurable/observable)
- [ ] Constraints prevent undesirable behaviors
- [ ] Constraints don't contradict principles
7. **Consistency Checks**
- [ ] Role, tone, expertise, principles all align
- [ ] No contradictions between principles and constraints
- [ ] Persona supports the menu items defined
- [ ] Language and terminology consistent
### Protocol 3: Report Findings
Organize your report into three sections:
**PASSING CHECKS** (List what passed)
```
✓ Role is specific and well-defined
✓ Tone clearly articulated and appropriate
✓ Expertise aligns with agent purpose
✓ Principles are actionable and clear
```
**WARNINGS** (Non-blocking issues)
```
⚠ Only 2 principles provided, 3-7 recommended for richer guidance
⚠ No constraints defined - consider adding boundaries
⚠ Expertise areas are broad, could be more specific
```
**FAILURES** (Blocking issues that must be fixed)
```
✗ Role is generic ("assistant") - needs specificity
✗ Tone undefined - creates inconsistent behavior
✗ Principles are vague ("be helpful" - not actionable)
✗ Contradiction: Principle says "be creative", constraint says "follow strict rules"
```
### Protocol 4: Menu System
#### 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CONTEXT BOUNDARIES
**IN SCOPE:**
- Persona section of agent.yaml (role, tone, expertise, principles, constraints)
- Referencing personaProperties.md and principlesCrafting.md
- Evaluating persona clarity, specificity, and consistency
- Checking alignment between persona elements
**OUT OF SCOPE:**
- Metadata fields (handled in step-07b)
- Menu items (handled in step-07d)
- System architecture (handled in step-07e)
- Technical implementation details
**DO NOT:**
- Validate metadata properties in this step
- Question the agent's core purpose (that's for earlier steps)
- Suggest additional menu items
- Modify fields beyond persona
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [menu validation].
## SUCCESS METRICS
✓ **Complete Success:** All checks pass, persona is well-defined and consistent
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
✓ **Failure:** Blocking failures remain when user selects [C]
**CRITICAL:** A weak or generic persona is a blocking issue that should be fixed before proceeding.
@@ -1,158 +0,0 @@
---
name: 'step-07d-menu-validation'
description: 'Validate menu items and patterns'
# File References
nextStepFile: './step-08e-structure-validation.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate that the agent's menu (commands/tools) follows BMAD patterns, is well-structured, properly documented, and aligns with the agent's persona and purpose.
## MANDATORY EXECUTION RULES
- **NEVER skip validation checks** - All menu items must be verified
- **ALWAYS load the reference document** - agentMenuPatterns.md
- **NEVER modify files without user approval** - Report findings first, await menu selection
- **ALWAYS use absolute paths** when referencing files
- **CRITICAL:** This is a validation step, not an editing step
## EXECUTION PROTOCOLS
### Protocol 1: Load and Compare
1. Read the menu patterns reference from `{agentMenuPatterns}`
2. Read the built agent YAML from `{builtYaml}`
3. Extract the menu/commands section from the builtYaml
4. Compare actual menu against validation rules
### Protocol 2: Validation Checks
Perform these checks systematically:
1. **Menu Structure**
- [ ] Menu section exists and is properly formatted
- [ ] At least one menu item defined (unless intentionally tool-less)
- [ ] Menu items follow proper YAML structure
- [ ] Each item has required fields (name, description, pattern)
2. **Menu Item Requirements**
For each menu item:
- [ ] name: Present, unique, uses kebab-case
- [ ] description: Clear and concise
- [ ] pattern: Valid regex pattern or tool reference
- [ ] scope: Appropriate scope defined (if applicable)
3. **Pattern Quality**
- [ ] Patterns are valid and testable
- [ ] Patterns are specific enough to match intended inputs
- [ ] Patterns are not overly restrictive
- [ ] Patterns use appropriate regex syntax
4. **Description Quality**
- [ ] Each item has clear description
- [ ] Descriptions explain what the item does
- [ ] Descriptions are consistent in style
- [ ] Descriptions help users understand when to use
5. **Alignment Checks**
- [ ] Menu items align with agent's role/purpose
- [ ] Menu items are supported by agent's expertise
- [ ] Menu items fit within agent's constraints
- [ ] Menu items are appropriate for target users
6. **Completeness**
- [ ] Core capabilities for this role are covered
- [ ] No obvious missing functionality
- [ ] Menu scope is appropriate (not too sparse/overloaded)
- [ ] Related functionality is grouped logically
7. **Standards Compliance**
- [ ] No prohibited patterns or commands
- [ ] No security vulnerabilities in patterns
- [ ] No ambiguous or conflicting items
- [ ] Consistent naming conventions
### Protocol 3: Report Findings
Organize your report into three sections:
**PASSING CHECKS** (List what passed)
```
✓ Menu structure properly formatted
✓ 5 menu items defined, all with required fields
✓ All patterns are valid regex
✓ Menu items align with agent role
```
**WARNINGS** (Non-blocking issues)
```
⚠ Item "analyze-data" description is vague
⚠ No menu item for [common capability X]
⚠ Pattern for "custom-command" very broad, may over-match
```
**FAILURES** (Blocking issues that must be fixed)
```
✗ Duplicate menu item name: "process" appears twice
✗ Invalid regex pattern: "[unclosed bracket"
✗ Menu item "system-admin" violates security guidelines
✗ No menu items defined for agent type that requires tools
```
### Protocol 4: Menu System
#### 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## CONTEXT BOUNDARIES
**IN SCOPE:**
- Menu/commands section of agent.yaml
- Referencing agentMenuPatterns.md
- Menu structure, patterns, and alignment
- Individual menu item validation
**OUT OF SCOPE:**
- Metadata fields (handled in step-07b)
- Persona fields (handled in step-07c)
- System architecture (handled in step-07e)
- Workflow/capability implementation (handled in step-07f)
**DO NOT:**
- Validate metadata or persona in this step
- Suggest entirely new capabilities (that's for earlier steps)
- Question whether menu items are "good enough" qualitatively beyond standards
- Modify fields beyond menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [structure validation].
## SUCCESS METRICS
✓ **Complete Success:** All checks pass, menu is well-structured and aligned
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
✓ **Failure:** Blocking failures remain when user selects [C]
**CRITICAL:** Invalid regex patterns or security vulnerabilities in menu items are blocking issues.
@@ -1,306 +0,0 @@
---
name: 'step-07e-structure-validation'
description: 'Validate YAML structure and completeness'
# File References
# Routes to 8F if Expert, else to 9
nextStepFileExpert: './step-08f-sidecar-validation.md'
nextStepFileSimple: './step-09-celebrate.md'
simpleValidation: ../data/simple-agent-validation.md
expertValidation: ../data/expert-agent-validation.md
agentCompilation: ../data/agent-compilation.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate the built agent YAML file for structural completeness and correctness against the appropriate validation checklist (simple or expert), then route to sidecar validation if needed or proceed to celebration.
# MANDATORY EXECUTION RULES
1. **NEVER skip validation** - All agents must pass structural validation before completion
2. **ALWAYS use the correct validation checklist** based on agent type (simple vs expert)
3. **NEVER auto-fix without user consent** - Report issues and ask for permission
4. **ALWAYS check hasSidecar flag** before determining next step routing
5. **MUST load and parse the actual built YAML** - Not just show it, but validate it
6. **ALWAYS provide clear, actionable feedback** for any validation failures
# EXECUTION PROTOCOLS
## Context Awareness
- User is in the final validation phase
- Agent has been built and written to disk
- This is the "quality gate" before completion
- User expects thorough but fair validation
- Route depends on agent type (expert vs simple)
## User Expectations
- Clear validation results with specific issues identified
- Line-number references for YAML problems
- Option to fix issues or continue (if minor)
- Logical routing based on agent type
- Professional, constructive feedback tone
## Tone and Style
- Professional and thorough
- Constructive, not pedantic
- Clear prioritization of issues (critical vs optional)
- Encouraging when validation passes
- Actionable when issues are found
# CONTEXT BOUNDARIES
## What to Validate
- YAML syntax and structure
- Required frontmatter fields presence
- Required sections completeness
- Field format correctness
- Path validity (for references)
- Agent type consistency (simple vs expert requirements)
## What NOT to Validate
- Artistic choices in descriptions
- Persona writing style
- Command naming creativity
- Feature scope decisions
## When to Escalate
- Critical structural errors that break agent loading
- Missing required fields
- YAML syntax errors preventing file parsing
- Path references that don't exist
# EXECUTION SEQUENCE
## 1. Load Validation Context
```bash
# Load the appropriate validation checklist based on agent type
if agentType == "expert":
validationFile = expertValidation
else:
validationFile = simpleValidation
# Load the built agent YAML
builtAgent = read(builtYaml)
# Load compilation rules for reference
compilationRules = read(agentCompilation)
```
**Action:** Present a brief status message:
```
🔍 LOADING VALIDATION FRAMEWORK
Agent Type: {detected type}
Validation Standard: {simple|expert}
Built File: {builtYaml path}
```
## 2. Execute Structural Validation
Run systematic checks against the validation checklist:
### A. YAML Syntax Validation
- Parse YAML without errors
- Check indentation consistency
- Validate proper escaping of special characters
- Verify no duplicate keys
### B. Frontmatter Validation
- All required fields present
- Field values correct type (string, boolean, array)
- No empty required fields
- Proper array formatting
### C. Section Completeness
- All required sections present (based on agent type)
- Sections not empty unless explicitly optional
- Proper markdown heading hierarchy
### D. Field-Level Validation
- Path references exist and are valid
- Boolean fields are actual booleans (not strings)
- Array fields properly formatted
- No malformed YAML structures
### E. Agent Type Specific Checks
**For Simple Agents:**
- No sidecar requirements
- Basic fields complete
- No advanced configuration
**For Expert Agents:**
- Sidecar flag set correctly
- Sidecar folder path specified
- All expert fields present
- Advanced features properly configured
## 3. Generate Validation Report
Present findings in structured format:
```markdown
# 🎯 STRUCTURAL VALIDATION REPORT
## Agent: {agent-name}
Type: {simple|expert}
File: {builtYaml}
---
## ✅ PASSED CHECKS ({count})
{List of all validations that passed}
## ⚠️ ISSUES FOUND ({count})
{If any issues, list each with:}
### Issue #{number}: {type}
**Severity:** [CRITICAL|MODERATE|MINOR]
**Location:** Line {line} or Section {section}
**Problem:** {clear description}
**Impact:** {what this breaks}
**Suggested Fix:** {specific action}
---
## 📊 VALIDATION SUMMARY
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
**Critical Issues:** {count}
**Moderate Issues:** {count}
**Minor Issues:** {count}
**Can Load Safely:** [YES|NO]
---
{If PASSED}
## 🎉 VALIDATION SUCCESSFUL
Your agent YAML is structurally sound and ready for use!
All required fields present and correctly formatted.
{If ISSUES FOUND}
## 🔧 RECOMMENDED ACTIONS
1. Address critical issues first
2. Review moderate issues
3. Minor issues can be deferred
```
## 4. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFileExpert} or {nextStepFileSimple}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
If [F] selected: Work through issues systematically
- Load specific section needing fix
- Present current state
- Apply auto-fixes or guide user through corrections
- Re-validate after each fix
- Confirm resolution and re-present menu
If [C] selected:
- Warn about implications if issues exist
- Get explicit confirmation if critical issues
- Document acceptance of issues
- Proceed to routing
## 5. Route to Next Step
After validation passes or user chooses to continue:
### Check Agent Type and Route
```yaml
# Check for sidecar requirement
hasSidecar = checkBuiltYamlForSidecarFlag()
if hasSidecar == true:
# Expert agent with sidecar
nextStep = nextStepFileExpert
routeMessage = """
📦 Expert agent detected with sidecar configuration.
→ Proceeding to sidecar validation (Step 7F)
"""
else:
# Simple agent or expert without sidecar
nextStep = nextStepFileSimple
routeMessage = """
✅ Simple agent validation complete.
→ Proceeding to celebration (Step 8)
"""
```
**Action:** Present routing decision and transition:
```markdown
# 🚀 VALIDATION COMPLETE - ROUTING DECISION
{routeMessage}
**Next Step:** {nextStep filename}
**Reason:** Agent type {simple|expert} with sidecar={hasSidecar}
Press [Enter] to continue to {next step description}...
```
# CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFileExpert}` or `{nextStepFileSimple}` to execute and begin [sidecar validation or celebration].
**BEFORE proceeding to next step:**
1. ✅ Validation checklist executed completely
2. ✅ All critical issues resolved or explicitly accepted
3. ✅ User informed of routing decision
4. ✅ Next step file path determined correctly
5. ⚠️ **CRITICAL:** For expert agents, verify hasSidecar is TRUE before routing to 7F
6. ⚠️ **CRITICAL:** For simple agents, verify hasSidecar is FALSE before routing to 8
**DO NOT PROCEED IF:**
- YAML has critical syntax errors preventing loading
- User has not acknowledged validation results
- Routing logic is unclear or conflicting
# SUCCESS METRICS
## Step Complete When:
- [ ] Validation report generated and presented
- [ ] User has reviewed findings
- [ ] Critical issues resolved or accepted
- [ ] Routing decision communicated and confirmed
- [ ] Next step path verified and ready
## Quality Indicators:
- Validation thoroughness (all checklist items covered)
- Issue identification clarity and specificity
- User satisfaction with resolution process
- Correct routing logic applied
- Clear transition to next step
## Failure Modes:
- Skipping validation checks
- Auto-fixing without permission
- Incorrect routing (simple→7F or expert→8 with sidecar)
- Unclear or missing validation report
- Proceeding with critical YAML errors
@@ -1,462 +0,0 @@
---
name: 'step-07f-sidecar-validation'
description: 'Validate sidecar structure and paths'
# File References
nextStepFile: './step-09-celebrate.md'
criticalActions: ../data/critical-actions.md
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
sidecarFolder: '{bmb_creations_output_folder}/{agent-name}/{agent-name}-sidecar/'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Validate the sidecar folder structure and referenced paths for Expert agents to ensure all sidecar files exist, are properly structured, and paths in the main agent YAML correctly reference them.
# MANDATORY EXECUTION RULES
1. **ONLY runs for Expert agents** - Simple agents should never reach this step
2. **MUST verify sidecar folder exists** before proceeding
3. **ALWAYS cross-reference YAML paths** with actual files
4. **NEVER create missing sidecar files** - Report issues, don't auto-fix
5. **MUST validate sidecar file structure** for completeness
6. **ALWAYS check critical actions file** if referenced
7. **PROVIDE clear remediation steps** for any missing or malformed files
# EXECUTION PROTOCOLS
## Context Awareness
- User has an Expert agent with sidecar configuration
- Structural validation (7E) already passed
- Sidecar folder should have been created during build
- This is the final validation before celebration
- Missing sidecar components may break agent functionality
## User Expectations
- Comprehensive sidecar structure validation
- Clear identification of missing files
- Path reference verification
- Actionable remediation guidance
- Professional but approachable tone
## Tone and Style
- Thorough and systematic
- Clear and specific about issues
- Solution-oriented (focus on how to fix)
- Encouraging when sidecar is complete
- Not pedantic about minor formatting issues
# CONTEXT BOUNDARIES
## What to Validate
- Sidecar folder existence and location
- All referenced files exist in sidecar
- Sidecar file structure completeness
- Path references in main YAML accuracy
- Critical actions file if referenced
- File naming conventions
- File content completeness (not empty)
## What NOT to Validate
- Content quality of sidecar files
- Artistic choices in sidecar documentation
- Optional sidecar components
- File formatting preferences
## When to Escalate
- Sidecar folder completely missing
- Critical files missing (actions, core modules)
- Path references pointing to non-existent files
- Empty sidecar files that should have content
# EXECUTION SEQUENCE
## 1. Load Sidecar Context
```bash
# Verify main agent YAML exists
agentYaml = read(builtYaml)
# Extract sidecar path from YAML or use template default
sidecarPath = extractSidecarPath(agentYaml) or sidecarFolder
# Check if sidecar folder exists
sidecarExists = directoryExists(sidecarPath)
# Load critical actions reference if needed
criticalActionsRef = read(criticalActions)
```
**Action:** Present discovery status:
```markdown
🔍 SIDECAR VALIDATION INITIALIZED
Agent: {agent-name}
Type: Expert (requires sidecar)
Main YAML: {builtYaml}
Sidecar Path: {sidecarPath}
Status: {✅ Folder Found | ❌ Folder Missing}
```
## 2. Validate Sidecar Structure
### A. Folder Existence Check
```markdown
## 📁 FOLDER STRUCTURE VALIDATION
**Sidecar Location:** {sidecarPath}
**Status:** [EXISTS | MISSING | WRONG LOCATION]
```
If missing:
```markdown
❌ **CRITICAL ISSUE:** Sidecar folder not found!
**Expected Location:** {sidecarPath}
**Possible Causes:**
1. Build process didn't create sidecar
2. Sidecar path misconfigured in agent YAML
3. Folder moved or deleted after build
**Required Action:**
[ ] Re-run build process with sidecar enabled
[ ] Verify sidecar configuration in agent YAML
[ ] Check folder was created in correct location
```
### B. Sidecar File Inventory
If folder exists, list all files:
```bash
sidecarFiles = listFiles(sidecarPath)
```
```markdown
## 📄 SIDECAR FILE INVENTORY
Found {count} files in sidecar:
{For each file:}
- {filename} ({size} bytes)
```
### C. Cross-Reference Validation
Extract all sidecar path references from agent YAML:
```yaml
# Common sidecar reference patterns
sidecar:
critical-actions: './{agent-name}-sidecar/critical-actions.md'
modules:
- path: './{agent-name}-sidecar/modules/module-01.md'
```
Validate each reference:
```markdown
## 🔗 PATH REFERENCE VALIDATION
**Checked {count} references from agent YAML:**
{For each reference:}
**Source:** {field in agent YAML}
**Expected Path:** {referenced path}
**Status:** [✅ Found | ❌ Missing | ⚠️ Wrong Location]
```
## 3. Validate Sidecar File Contents
For each sidecar file found, check:
### A. File Completeness
```markdown
## 📋 FILE CONTENT VALIDATION
{For each file:}
### {filename}
**Size:** {bytes}
**Status:** [✅ Complete | ⚠️ Empty | ❌ Too Small]
**Last Modified:** {timestamp}
```
### B. Critical Actions File (if present)
Special validation for critical-actions.md:
```markdown
## 🎯 CRITICAL ACTIONS VALIDATION
**File:** {sidecarPath}/critical-actions.md
**Status:** [PRESENT | MISSING | EMPTY]
{If Present:}
**Sections Found:**
{List sections detected}
**Completeness:**
[ ] Header/metadata present
[ ] Actions defined
[ ] No critical sections missing
```
### C. Module Files (if present)
If sidecar contains modules:
```markdown
## 📚 MODULE VALIDATION
**Modules Found:** {count}
{For each module:}
### {module-filename}
**Status:** [✅ Valid | ⚠️ Issues Found]
**Checks:**
[ ] Frontmatter complete
[ ] Content present
[ ] References valid
```
## 4. Generate Validation Report
```markdown
# 🎯 SIDECAR VALIDATION REPORT
## Agent: {agent-name}
Sidecar Path: {sidecarPath}
Validation Date: {timestamp}
---
## ✅ VALIDATION CHECKS PASSED
**Folder Structure:**
- [x] Sidecar folder exists
- [x] Located at expected path
- [x] Accessible and readable
**File Completeness:**
- [x] All referenced files present
- [x] No broken path references
- [x] Files have content (not empty)
**Content Quality:**
- [x] Critical actions complete
- [x] Module files structured
- [x] No obvious corruption
---
## ⚠️ ISSUES IDENTIFIED ({count})
{If issues:}
### Issue #{number}: {issue type}
**Severity:** [CRITICAL|MODERATE|MINOR]
**Component:** {file or folder}
**Problem:** {clear description}
**Impact:** {what this breaks}
**Remediation:**
1. {specific step 1}
2. {specific step 2}
3. {specific step 3}
{If no issues:}
### 🎉 NO ISSUES FOUND
Your agent's sidecar is complete and properly structured!
All path references are valid and files are in place.
---
## 📊 SUMMARY
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
**Files Validated:** {count}
**Issues Found:** {count}
**Critical Issues:** {count}
**Sidecar Ready:** [YES|NO]
---
## 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF F: Apply auto-fixes to {builtYaml} or sidecar files for identified issues, then redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Proceed to celebration step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
## 6. Issue Resolution (if [F] selected)
Work through each issue systematically:
**For Missing Files:**
```markdown
### 🔧 FIXING: Missing {filename}
**Required File:** {path}
**Purpose:** {why it's needed}
**Option 1:** Re-run Build
- Sidecar may not have been created completely
- Return to build step and re-execute
**Option 2:** Manual Creation
- Create file at: {full path}
- Use template from: {template reference}
- Minimum required content: {specification}
**Option 3:** Update References
- Remove reference from agent YAML if not truly needed
- Update path if file exists in different location
Which option? [1/2/3]:
```
**For Broken Path References:**
```markdown
### 🔧 FIXING: Invalid Path Reference
**Reference Location:** {agent YAML field}
**Current Path:** {incorrect path}
**Expected File:** {filename}
**Actual Location:** {where file actually is}
**Fix Options:**
1. Update path in agent YAML to: {correct path}
2. Move file to expected location: {expected path}
3. Remove reference if file not needed
Which option? [1/2/3]:
```
**For Empty/Malformed Files:**
```markdown
### 🔧 FIXING: {filename} - {Issue}
**Problem:** {empty/too small/malformed}
**Location:** {full path}
**Remediation:**
- View current content
- Compare to template/standard
- Add missing sections
- Correct formatting
Ready to view and fix? [Y/N]:
```
After each fix:
- Re-validate the specific component
- Confirm resolution
- Move to next issue
- Final re-validation when all complete
## 6. Route to Celebration
When validation passes or user chooses to continue:
```markdown
# 🚀 SIDECAR VALIDATION COMPLETE
## Expert Agent: {agent-name}
✅ **Sidecar Structure:** Validated
✅ **Path References:** All correct
✅ **File Contents:** Complete
---
## 🎯 READY FOR CELEBRATION
Your Expert agent with sidecar is fully validated and ready!
**Next Step:** Celebration (Step 8)
**Final Status:** All checks passed
Press [Enter] to proceed to celebration...
```
# CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [celebration].
**BEFORE proceeding to Step 8:**
1. ✅ Sidecar folder exists and is accessible
2. ✅ All referenced files present
3. ✅ Path references validated
4. ✅ File contents checked for completeness
5. ✅ User informed of validation status
6. ✅ Issues resolved or explicitly accepted
7. ⚠️ **CRITICAL:** Only Expert agents should reach this step
8. ⚠️ **CRITICAL:** Sidecar must be complete for agent to function
**DO NOT PROCEED IF:**
- Sidecar folder completely missing
- Critical files absent (actions, core modules)
- User unaware of sidecar issues
- Validation not completed
# SUCCESS METRICS
## Step Complete When:
- [ ] Sidecar folder validated
- [ ] All path references checked
- [ ] File contents verified
- [ ] Validation report presented
- [ ] Issues resolved or accepted
- [ ] User ready to proceed
## Quality Indicators:
- Thoroughness of file inventory
- Accuracy of path reference validation
- Clarity of issue identification
- Actionability of remediation steps
- User confidence in sidecar completeness
## Failure Modes:
- Missing sidecar folder completely
- Skipping file existence checks
- Not validating path references
- Proceeding with critical files missing
- Unclear validation report
- Not providing remediation guidance
---
## 🎓 NOTE: Expert Agent Sidecars
Sidecars are what make Expert agents powerful. They enable:
- Modular architecture
- Separation of concerns
- Easier updates and maintenance
- Shared components across agents
A validated sidecar ensures your Expert agent will:
- Load correctly at runtime
- Find all referenced resources
- Execute critical actions as defined
- Provide the advanced capabilities designed
Take the time to validate thoroughly - it pays off in agent reliability!
@@ -4,7 +4,7 @@ description: 'Load and analyze existing agent for editing'
# File References
thisStepFile: ./e-01-load-existing.md
workflowFile: ../workflow.md
workflowFile: ../workflow-edit-agent.md
nextStepFile: './e-02-discover-edits.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMetadata: ../data/agent-metadata.md
@@ -59,7 +59,9 @@ Load the existing agent file, parse its structure, and create an edit plan track
- Limits: Analysis only, no modifications
- Dependencies: Agent file must exist and be valid YAML
## Sequence of Instructions (Do not deviate, skip, or optimize)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Agent File
@@ -74,14 +76,20 @@ Expected format: `{path-to-agent}/{agent-name}.agent.yaml`"
### 2. Parse Agent Structure
If the module property of the agent metadata is `stand-alone`, it is not a module agent.
If the module property of the agent is a module code (like bmm, bmb, etc...) it is a module agent.
If the property hasSidecar: true exists in the metadata, then it is an expert agent.
Else it is a simple agent.
If a module agent also hasSidecar: true - this means it is a modules expert agent, thus it can have sidecar.
**Extract and categorize all agent components:**
```yaml
# Basic Metadata
- name: {agent-name}
- description: {agent-description}
- type: {simple|expert|module}
- version: {version}
- module: {stand-alone|bmm|cis|bmgd|custom}
- hasSidecar: {true|false}
# Persona
- persona: {full persona text}
@@ -104,8 +112,7 @@ Expected format: `{path-to-agent}/{agent-name}.agent.yaml`"
```markdown
## Agent Analysis: {agent-name}
**Type:** {simple|expert|module}
**Version:** {version}
**Type:** {simple|expert|module} (derived from module + hasSidecar)
**Status:** ready-for-edit
### Current Structure:
@@ -2,7 +2,7 @@
name: 'e-02-discover-edits'
description: 'Discover what user wants to change about the agent'
nextStepFile: './e-03a-validate-metadata.md'
nextStepFile: './e-04-sidecar-metadata.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
@@ -54,7 +54,9 @@ Conduct targeted discovery to understand exactly what the user wants to change a
- Limits: Discovery and documentation only, no implementation
- Dependencies: Agent must be loaded in editPlan
## Sequence of Instructions (Do not deviate, skip, or optimize)
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Read Edit Plan Context
@@ -72,8 +74,8 @@ I can help you modify:
**[P]ersona** - Role, identity, communication style, principles
**[C]ommands** - Add, remove, or modify commands and menu structure
**[M]etadata** - Name, description, version, tags, category
**[S]idecar** - Add or remove memory (convert hasSidecar: true/false)
**[A]ctions** - Critical actions and activation behaviors
**[T]ype** - Convert between Simple/Expert/Module types
**[O]ther** - Configuration, capabilities, system context
Which areas would you like to edit? (You can select multiple)"
@@ -105,10 +107,10 @@ Which areas would you like to edit? (You can select multiple)"
- "Should new activation behaviors be added?"
- "Are current actions executing as expected?"
#### If Type conversion selected:
- "What type are you converting from/to?"
- "What's driving this conversion?"
- "Are you aware of the implications (e.g., Expert needs sidecar)?"
#### If Sidecar selected:
- "Do you want to add memory (hasSidecar: true) or remove it (hasSidecar: false)?"
- "What should the agent remember across sessions?"
- "Are you aware of the implications?"
### 4. Document Edits to Plan
@@ -133,8 +135,9 @@ Which areas would you like to edit? (You can select multiple)"
- [ ] {edit description}
- [ ] {edit description}
### Type Conversion
- [ ] {from: X, to: Y, rationale: ...}
### Sidecar Conversion
- [ ] {from: hasSidecar: false, to: hasSidecar: true, rationale: ...}
- [ ] {from: hasSidecar: true, to: hasSidecar: false, rationale: ...}
### Other Edits
- [ ] {edit description}
@@ -168,7 +171,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [all edits documented and confirmed by user], will you then load and read fully `{nextStepFile}` to execute and begin validation.
ONLY WHEN [C continue option] is selected and [all edits documented and confirmed by user], will you then load and read fully `{nextStepFile}` to execute and checks.
---
@@ -0,0 +1 @@
# Placeholder - do not load this step.
@@ -1,78 +0,0 @@
---
name: 'e-03a-validate-metadata'
description: 'Validate metadata (before edit) - no menu, auto-advance'
nextStepFile: './e-03b-validate-persona.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMetadata: ../data/agent-metadata.md
---
# Edit Step 3a: Validate Metadata (Before Edit)
## STEP GOAL:
Validate the agent's metadata properties against BMAD standards. Record findings to editPlan and auto-advance to next validation step.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentMetadata first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate metadata against agentMetadata.md rules
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentMetadata.md reference
- 📊 Validate all metadata fields
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentMetadata}` to understand validation rules.
Read `{editPlan}` to get agent file path and metadata.
### 2. Validate Metadata
Perform checks on:
- **id**: kebab-case, no spaces
- **name**: display name, clear branding
- **title**: concise function description
- **icon**: appropriate emoji or symbol
- **module**: correct format `{project}:{type}:{name}`
- **hasSidecar**: boolean, matches actual sidecar usage
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
validationBefore:
metadata:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
- {check}: [pass|fail]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All metadata checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to persona validation...**
@@ -1,76 +0,0 @@
---
name: 'e-03b-validate-persona'
description: 'Validate persona (before edit) - no menu, auto-advance'
nextStepFile: './e-03c-validate-menu.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
---
# Edit Step 3b: Validate Persona (Before Edit)
## STEP GOAL:
Validate the agent's persona fields against BMAD standards. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and persona references first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate persona four-field system
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load personaProperties.md and principlesCrafting.md
- 📊 Validate persona fields
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{personaProperties}` and `{principlesCrafting}`.
Read `{editPlan}` to get agent file path and persona.
### 2. Validate Persona
Perform checks on:
- **role**: present, specific, not generic
- **identity**: present, defines who agent is
- **communication_style**: present, speech patterns only (no behavioral words)
- **principles**: present, first principle activates expert knowledge, not generic duties
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
persona:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
- {check}: [pass|fail]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All persona checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to menu validation...**
@@ -1,75 +0,0 @@
---
name: 'e-03c-validate-menu'
description: 'Validate menu structure (before edit) - no menu, auto-advance'
nextStepFile: './e-03d-validate-structure.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
---
# Edit Step 3c: Validate Menu (Before Edit)
## STEP GOAL:
Validate the agent's command menu structure against BMAD standards. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentMenuPatterns first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate command/menu structure
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentMenuPatterns.md reference
- 📊 Validate commands and menu
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentMenuPatterns}`.
Read `{editPlan}` to get agent file path and commands.
### 2. Validate Menu
Perform checks on:
- **A/P/C convention**: each menu has Advanced Elicitation, Party Mode, Continue
- **Command names**: clear, descriptive
- **Command descriptions**: specific, actionable
- **Menu handling logic**: properly specified
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
menu:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
- {check}: [pass|fail]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All menu checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to structure validation...**
@@ -1,75 +0,0 @@
---
name: 'e-03d-validate-structure'
description: 'Validate YAML structure (before edit) - no menu, auto-advance'
nextStepFile: './e-03e-validate-sidecar.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentCompilation: ../data/agent-compilation.md
---
# Edit Step 3d: Validate Structure (Before Edit)
## STEP GOAL:
Validate the agent's YAML structure and completeness. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentCompilation first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate YAML structure and required fields
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentCompilation.md reference
- 📊 Validate YAML structure
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentCompilation}`.
Read `{editPlan}` to get agent file path.
### 2. Validate Structure
Perform checks on:
- **YAML syntax**: valid, no parse errors
- **Required fields**: name, description, type, persona present
- **Field types**: arrays where expected, strings where expected
- **Indentation**: consistent 2-space indentation
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
structure:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
- {check}: [pass|fail]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All structure checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to sidecar validation...**
@@ -1,78 +0,0 @@
---
name: 'e-03e-validate-sidecar'
description: 'Validate sidecar structure (before edit) - no menu, auto-advance'
nextStepFile: './e-03f-validation-summary.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
expertValidation: ../data/expert-agent-validation.md
---
# Edit Step 3e: Validate Sidecar (Before Edit)
## STEP GOAL:
Validate the agent's sidecar structure if Expert type. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and expertValidation first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate sidecar structure for Expert agents
- 📊 Record findings to editPlan frontmatter
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load expertValidation.md reference
- 📊 Validate sidecar if Expert type, skip for Simple/Module
- 💾 Record findings to editPlan
- ➡️ Auto-advance to validation summary when complete
## Sequence of Instructions:
### 1. Load References
Read `{expertValidation}`.
Read `{editPlan}` to get agent type.
### 2. Conditional Validation
**IF agentType == expert:**
- Check metadata.sidecar-folder is present
- Check sidecar-path is correct format
- Verify sidecar files exist at specified path
**IF agentType != expert:**
- Mark as N/A (not applicable)
- Skip detailed checks
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
sidecar:
status: [pass|fail|warning|n/a]
findings:
- {check}: [pass|fail|n/a]
- {check}: [pass|fail|n/a]
```
### 4. Auto-Advance
When validation complete, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ Sidecar checks performed (or N/A recorded)
✅ Findings saved to editPlan
✅ Auto-advanced to validation summary
---
**Auto-advancing to validation summary...**
@@ -1,119 +0,0 @@
---
name: 'e-03f-validation-summary'
description: 'Display all validation findings before edit'
nextStepFile: './e-04-type-metadata.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Edit Step 3f: Validation Summary (Before Edit)
## STEP GOAL:
Display all validation findings from the previous 5 validation steps to the user. Present findings clearly and await confirmation to proceed.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan to collect all validation findings
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Display all validation findings clearly organized
- 📊 Aggregate findings from all 5 validation steps
- 💬 Present options for handling any issues found
## EXECUTION PROTOCOLS:
- 🎯 Read editPlan to get validation findings
- 📊 Display organized summary
- 💾 Allow user to decide how to proceed
- ➡️ Proceed to edit plan on [C]
## Sequence of Instructions:
### 1. Load Validation Findings
Read `{editPlan}` frontmatter to collect:
- validationBefore.metadata.status and findings
- validationBefore.persona.status and findings
- validationBefore.menu.status and findings
- validationBefore.structure.status and findings
- validationBefore.sidecar.status and findings
### 2. Display Validation Summary
```markdown
## Pre-Edit Validation Report for {agent-name}
### Metadata Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
{Findings summary}
### Persona Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
{Findings summary}
### Menu Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
{Findings summary}
### Structure Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
{Findings summary}
### Sidecar Validation
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL / N/A}
{Findings summary}
```
### 3. Present Options
"How would you like to proceed?
**[I**ntegrate fixes**] - Add validation fixes to your edit plan
**[S]kip** - Proceed with your planned edits only
**[A]dvanced** - Deeper exploration of any issues"
### 4. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Edit Plan"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF I: Add validation fixes to editPlan, then redisplay menu
- IF C: Save validation summary to {editPlan}, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation summary displayed], will you then load and read fully `{nextStepFile}` to execute and begin edit planning.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All validation findings displayed clearly
- User given options for handling issues
- Validation summary saved to editPlan
### ❌ SYSTEM FAILURE:
- Findings not displayed to user
- Proceeding without user acknowledgment
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
@@ -1,5 +1,5 @@
---
name: 'e-04-type-metadata'
name: 'e-04-sidecar-metadata'
description: 'Review and plan metadata edits'
nextStepFile: './e-05-persona.md'
@@ -11,11 +11,11 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Edit Step 4: Type and Metadata
# Edit Step 4: Sidecar and Metadata
## STEP GOAL:
Review the agent's type and metadata, and plan any changes. If edits involve type conversion, identify the implications.
Review the agent's hasSidecar decision and metadata, and plan any changes. If edits involve sidecar conversion, identify the implications.
## MANDATORY EXECUTION RULES:
@@ -26,7 +26,7 @@ Review the agent's type and metadata, and plan any changes. If edits involve typ
### Step-Specific Rules:
- 🎯 Load reference documents before discussing edits
- 📊 Document type conversion requirements if applicable
- 📊 Document sidecar conversion requirements if applicable
- 💬 Focus on metadata that user wants to change
## EXECUTION PROTOCOLS:
@@ -36,26 +36,30 @@ Review the agent's type and metadata, and plan any changes. If edits involve typ
- 💾 Document planned metadata changes
- 🚫 FORBIDDEN to proceed without documenting changes
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
Read `{agentMetadata}` and `{agentTypesDoc}` to understand validation rules and type implications.
Read `{agentMetadata}` and `{agentTypesDoc}` to understand validation rules and sidecar implications.
### 2. Review Current Metadata
From `{editPlan}`, display current:
- agentType (simple/expert/module)
- All metadata fields: id, name, title, icon, module, hasSidecar
- hasSidecar (true/false)
- All metadata fields: id, name, title, icon, module
### 3. Discuss Metadata Edits
If user wants metadata changes:
**For type conversion:**
- "Converting from {current} to {target}"
- Explain implications (e.g., Simple → Expert requires sidecar)
- Update editPlan with type conversion
**For sidecar conversion:**
- "Converting from hasSidecar: {current} to {target}"
- Explain implications:
- false → true: Need to create sidecar folder, add critical_actions with sidecar file loading
- true → false: Remove sidecar fields; if critical_actions only has sidecar references, remove section; otherwise keep non-sidecar critical_actions
- Update editPlan with conversion
**For metadata field changes:**
- id: kebab-case requirements
@@ -63,7 +67,6 @@ If user wants metadata changes:
- title: function description format
- icon: emoji/symbol
- module: path format
- hasSidecar: boolean implications
### 4. Document to Edit Plan
@@ -71,9 +74,9 @@ Append to `{editPlan}`:
```yaml
metadataEdits:
typeConversion:
from: {current-type}
to: {target-type}
sidecarConversion:
from: {current-hasSidecar}
to: {target-hasSidecar}
rationale: {explanation}
fieldChanges:
- field: {field-name}
@@ -110,13 +113,13 @@ ONLY WHEN [C continue option] is selected and [metadata changes documented], wil
- Reference documents loaded
- Metadata changes discussed and documented
- Type conversion implications understood
- Sidecar conversion implications understood
- Edit plan updated
### ❌ SYSTEM FAILURE:
- Proceeded without loading reference documents
- Type conversion without understanding implications
- Sidecar conversion without understanding implications
- Changes not documented to edit plan
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
@@ -37,7 +37,9 @@ Review the agent's persona and plan any changes using the four-field persona sys
- 💾 Document planned persona changes
- 🚫 FORBIDDEN to proceed without documenting changes
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
@@ -35,7 +35,9 @@ Review the agent's command menu and plan any additions, modifications, or remova
- 💾 Document planned command changes
- 🚫 FORBIDDEN to proceed without documenting changes
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
@@ -1,14 +1,12 @@
---
name: 'e-07-activation'
description: 'Review critical_actions and route to type-specific edit'
description: 'Review critical_actions and route to edit step'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
criticalActions: ../data/critical-actions.md
# Type-specific edit routes
simpleEdit: './e-08a-edit-simple.md'
expertEdit: './e-08b-edit-expert.md'
moduleEdit: './e-08c-edit-module.md'
# Edit step route (determined by hasSidecar)
agentEdit: './e-08-edit-agent.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
@@ -18,52 +16,56 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
## STEP GOAL:
Review critical_actions and route to the appropriate type-specific edit step (Simple/Expert/Module).
Review critical_actions and route to the agent edit step based on hasSidecar value.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Load criticalActions and editPlan first
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}}`
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Load criticalActions.md before discussing activation
- 📊 Determine target type for routing
- 💬 Route based on POST-EDIT agent type
- 📊 Determine hasSidecar for routing
- 💬 Route based on POST-EDIT hasSidecar value
## EXECUTION PROTOCOLS:
- 🎯 Load criticalActions.md
- 📊 Check editPlan for target agent type
- 💾 Route to appropriate type-specific edit step
- ➡️ Auto-advance to type-specific edit on [C]
- 📊 Check editPlan for target hasSidecar value
- 💾 Route to agent edit step
- ➡️ Auto-advance to edit step on [C]
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
Read `{criticalActions}` and `{editPlan}` to understand:
- Current critical_actions (if any)
- Target agent type after edits
- Target hasSidecar value after edits
### 2. Review Critical Actions
If user wants to add/modify critical_actions:
- Reference patterns from criticalActions.md
- Define action name, description, invocation
- For Expert agents: specify sidecar-folder and file paths
- For hasSidecar: true — specify sidecar-folder and file paths
### 3. Determine Routing
Check `{editPlan}` metadataEdits.typeConversion.to or current agentType:
Check `{editPlan}` for agent metadata (hasSidecar):
```yaml
agentType: simple → route to e-08a-edit-simple.md
agentType: expert → route to e-08b-edit-expert.md
agentType: module → route to e-08c-edit-module.md
# Simple routing based on hasSidecar
hasSidecar: true → route to e-08-edit-agent.md (create sidecar structure)
hasSidecar: false → route to e-08-edit-agent.md (single YAML file)
```
The edit step handles both cases based on hasSidecar value.
### 4. Document to Edit Plan
Append to `{editPlan}`:
@@ -74,19 +76,19 @@ activationEdits:
additions: []
modifications: []
routing:
destinationEdit: {e-08a|e-08b|e-08c}
targetType: {simple|expert|module}
destinationEdit: e-08-edit-agent.md
hasSidecar: {true|false} # Derived from edit plan
```
### 5. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Type-Specific Edit"
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Edit Agent"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save to {editPlan}, determine routing based on targetType, then only then load and execute the appropriate type-specific edit step
- IF C: Save to {editPlan}, then only then load and execute the agent edit step
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
#### EXECUTION RULES:
@@ -97,11 +99,10 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
## CRITICAL STEP COMPLETION NOTE
This is the **ROUTING HUB** for edit flow. ONLY WHEN [C continue option] is selected and [routing determined], load and execute the appropriate type-specific edit step:
This is the **ROUTING HUB** for edit flow. ONLY WHEN [C continue option] is selected and [routing determined], load and execute the agent edit step:
- targetType: simple → e-08a-edit-simple.md
- targetType: expert → e-08b-edit-expert.md
- targetType: module → e-08c-edit-module.md
- hasSidecar: false → Single YAML file edit
- hasSidecar: true → YAML + sidecar folder structure edit
---
@@ -110,13 +111,13 @@ This is the **ROUTING HUB** for edit flow. ONLY WHEN [C continue option] is sele
### ✅ SUCCESS:
- criticalActions.md loaded
- Routing determined based on target type
- Routing determined based on hasSidecar
- Edit plan updated with routing info
### ❌ SYSTEM FAILURE:
- Proceeded without loading reference documents
- Routing not determined
- Wrong type-specific edit step selected
- Wrong edit step selected
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
@@ -0,0 +1,196 @@
---
name: 'e-08-edit-agent'
description: 'Apply edits to agent (with or without sidecar)'
nextStepFile: './e-09-celebrate.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentFile: '{original-agent-path}'
agentBackup: '{original-agent-path}.backup'
# Template and Architecture
agentTemplate: ../templates/agent-template.md
agentArch: ../data/agent-architecture.md
agentValidation: ../data/agent-validation.md
agentCompilation: ../data/agent-compilation.md
agentMetadata: ../data/agent-metadata.md
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
agentMenuPatterns: ../data/agent-menu-patterns.md
criticalActions: ../data/critical-actions.md
# Reference examples
noSidecarExample: ../data/reference/without-sidecar/commit-poet.agent.yaml
withSidecarExample: ../data/reference/with-sidecar/journal-keeper/journal-keeper.agent.yaml
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Edit Step 8: Edit Agent
## STEP GOAL:
Apply all planned edits to the agent YAML file. The edit approach (with or without sidecar) is determined by the `hasSidecar` value from the edit plan.
## MANDATORY EXECUTION RULES:
- 🛑 ALWAYS create backup before modifying agent file
- 📖 CRITICAL: Read template and architecture files first
- 🔄 CRITICAL: Load editPlan and agentFile
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Load all reference files before applying edits
- 📊 Apply edits exactly as specified in editPlan
- 💾 Validate YAML after each edit
- 🎭 Handle sidecar structure if hasSidecar: true
- ➡️ Auto-advance to celebration when complete
## EXECUTION PROTOCOLS:
- 🎯 Load template, architecture, and validation files
- 📊 Read editPlan to get all planned changes
- 💾 Create backup
- 📝 Apply edits: sidecar conversion, metadata, persona, commands, critical_actions
- 🎭 Manage sidecar folder structure (if applicable)
- ✅ Validate YAML and sidecar paths
- ➡️ Auto-advance to next step
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Reference Documents
Read all files before editing:
- `{agentTemplate}` - YAML structure reference
- `{agentArch}` - Agent architecture (with/without sidecar)
- `{agentValidation}` - Validation checklist
- `{agentCompilation}` - Assembly guidelines
- `{agentMetadata}`, `{personaProperties}`, `{principlesCrafting}`
- `{agentMenuPatterns}`, `{criticalActions}`
### 2. Load Edit Plan and Agent
Read `{editPlan}` to get all planned edits.
Read `{agentFile}` to get current agent YAML.
Check the `hasSidecar` value from editPlan to determine edit approach.
### 3. Create Backup
ALWAYS backup before editing:
```bash
cp {agentFile} {agentBackup}
```
Confirm: "Backup created at: `{agentBackup}`"
### 4. Apply Edits in Sequence
For each planned edit:
**Sidecar Conversion:**
**false → true (Adding sidecar):**
- Set `hasSidecar: true`
- Add `metadata.sidecar-folder` if not present
- Add `critical_actions` section with sidecar file references
- Create sidecar directory: `{agent-folder}/{agent-name}-sidecar/`
- Create starter files: `memories.md`, `instructions.md`
- Update all references to use `{project-root}/_bmad/_memory/{sidecar-folder}/` format
**true → false (Removing sidecar):**
- Set `hasSidecar: false`
- Remove `metadata.sidecar-folder` and `metadata.sidecar-path`
- If critical_actions contains only sidecar references, remove the section
- If critical_actions contains non-sidecar activation behaviors, keep and clean sidecar references
- Remove sidecar references from menu actions
- Optionally archive sidecar folder
**Metadata Edits:**
- Apply each field change from metadataEdits
- Validate format conventions
**Persona Edits:**
- Replace persona section with new four-field persona
- Validate field purity (role ≠ identity ≠ communication_style)
- For hasSidecar: true, ensure communication_style includes memory reference patterns
**Command Edits:**
- Additions: append to commands array
- Modifications: update specific commands
- Removals: remove from commands array
**Critical Actions Edits (hasSidecar: true only):**
- Additions: append to critical_actions array
- Modifications: update specific actions
- Removals: remove from array
- Ensure all references use correct `{project-root}/_bmad/_memory/` paths
### 5. Validate After Each Edit
**For both types:**
- Confirm YAML syntax is valid after each modification
**For hasSidecar: true:**
- Validate sidecar path format
- Ensure all critical_actions reference correct paths
- Confirm sidecar folder structure exists
### 6. Document Applied Edits
Append to `{editPlan}`:
```yaml
editsApplied:
- {edit-description}
- {edit-description}
backup: {agentBackup}
timestamp: {YYYY-MM-DD HH:MM}
```
### 7. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save to {editPlan}, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [all edits applied and validated], will you then load and read fully `{nextStepFile}` to execute and celebrate.
---
## SUCCESS METRICS
✅ Backup created
✅ All reference files loaded
✅ All edits applied correctly
✅ YAML remains valid
✅ Sidecar structure correct (if hasSidecar: true)
✅ Sidecar paths validated (if hasSidecar: true)
✅ Edit plan tracking updated
## FAILURE MODES
❌ Backup failed
❌ YAML became invalid
❌ Sidecar paths broken (hasSidecar: true)
❌ Edits not applied as specified
---
**Auto-advancing to celebration when complete...**
@@ -1,134 +0,0 @@
---
name: 'e-08a-edit-simple'
description: 'Apply edits to Simple agent'
nextStepFile: './e-09a-validate-metadata.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentFile: '{original-agent-path}'
agentBackup: '{original-agent-path}.backup'
# Template and Architecture
simpleTemplate: ../templates/simple-agent.template.md
simpleArch: ../data/simple-agent-architecture.md
agentCompilation: ../data/agent-compilation.md
agentMetadata: ../data/agent-metadata.md
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
agentMenuPatterns: ../data/agent-menu-patterns.md
criticalActions: ../data/critical-actions.md
---
# Edit Step 8a: Edit Simple Agent
## STEP GOAL:
Apply all planned edits to the Simple agent YAML file using templates and architecture references for validation.
## MANDATORY EXECUTION RULES:
- 🛑 ALWAYS create backup before modifying agent file
- 📖 CRITICAL: Read template and architecture files first
- 🔄 CRITICAL: Load editPlan and agentFile
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Load all reference files before applying edits
- 📊 Apply edits exactly as specified in editPlan
- 💾 Validate YAML after each edit
- ➡️ Auto-advance to post-edit validation when complete
## EXECUTION PROTOCOLS:
- 🎯 Load template, architecture, and data files
- 📊 Read editPlan to get all planned changes
- 💾 Create backup
- 📝 Apply edits: type conversion, metadata, persona, commands, critical_actions
- ✅ Validate YAML syntax
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
### 1. Load Reference Documents
Read all files before editing:
- `{simpleTemplate}` - YAML structure reference
- `{simpleArch}` - Simple agent architecture
- `{agentCompilation}` - Assembly guidelines
- `{agentMetadata}`, `{personaProperties}`, `{principlesCrafting}`
- `{agentMenuPatterns}`, `{criticalActions}`
### 2. Load Edit Plan and Agent
Read `{editPlan}` to get all planned edits.
Read `{agentFile}` to get current agent YAML.
### 3. Create Backup
ALWAYS backup before editing:
`cp {agentFile} {agentBackup}`
Confirm: "Backup created at: `{agentBackup}`"
### 4. Apply Edits in Sequence
For each planned edit:
**Type Conversion:**
- Update `type:` field if converting
- Add/remove type-specific fields
**Metadata Edits:**
- Apply each field change from metadataEdits
**Persona Edits:**
- Replace persona section with new four-field persona
- Validate field purity (role ≠ identity ≠ communication_style)
**Command Edits:**
- Additions: append to commands array
- Modifications: update specific commands
- Removals: remove from commands array
**Critical Actions Edits:**
- Additions: append to critical_actions array
- Modifications: update specific actions
- Removals: remove from array
### 5. Validate YAML After Each Edit
Confirm YAML syntax is valid after each modification.
### 6. Document Applied Edits
Append to `{editPlan}`:
```yaml
editsApplied:
- {edit-description}
- {edit-description}
backup: {agentBackup}
timestamp: {YYYY-MM-DD HH:MM}
```
### 7. Auto-Advance
When all edits applied successfully, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ Backup created
✅ All reference files loaded
✅ All edits applied correctly
✅ YAML remains valid
✅ Edit plan tracking updated
## FAILURE MODES
❌ Backup failed
❌ YAML became invalid
❌ Edits not applied as specified
---
**Auto-advancing to post-edit validation...
@@ -1,117 +0,0 @@
---
name: 'e-08b-edit-expert'
description: 'Apply edits to Expert agent'
nextStepFile: './e-09a-validate-metadata.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentFile: '{original-agent-path}'
agentBackup: '{original-agent-path}.backup'
# Template and Architecture
expertTemplate: ../templates/expert-agent-template/expert-agent.template.md
expertArch: ../data/expert-agent-architecture.md
agentCompilation: ../data/agent-compilation.md
agentMetadata: ../data/agent-metadata.md
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
agentMenuPatterns: ../data/agent-menu-patterns.md
criticalActions: ../data/critical-actions.md
expertValidation: ../data/expert-agent-validation.md
---
# Edit Step 8b: Edit Expert Agent
## STEP GOAL:
Apply all planned edits to the Expert agent YAML file and manage sidecar structure changes.
## MANDATORY EXECUTION RULES:
- 🛑 ALWAYS create backup before modifying agent file
- 📖 CRITICAL: Read template and architecture files first
- 🔄 CRITICAL: Load editPlan and agentFile
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Load all reference files before applying edits
- 📊 Manage sidecar structure for Expert agents
- 💾 Validate YAML and sidecar paths after edits
- ➡️ Auto-advance to post-edit validation when complete
## EXECUTION PROTOCOLS:
- 🎯 Load template, architecture, and data files
- 📊 Read editPlan to get all planned changes
- 💾 Create backup
- 📝 Apply edits including sidecar management
- ✅ Validate YAML and sidecar paths
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
### 1. Load Reference Documents
Read all files before editing:
- `{expertTemplate}` - Expert YAML structure
- `{expertArch}` - Expert agent architecture
- `{agentCompilation}`, `{agentMetadata}`, `{personaProperties}`, `{principlesCrafting}`
- `{agentMenuPatterns}`, `{criticalActions}`, `{expertValidation}`
### 2. Load Edit Plan and Agent
Read `{editPlan}` to get all planned edits.
Read `{agentFile}` to get current agent YAML.
### 3. Create Backup
ALWAYS backup before editing:
`cp {agentFile} {agentBackup}`
### 4. Apply Edits in Sequence
**Type Conversion to Expert:**
- Update `type: expert`
- Add `metadata.sidecar-folder` if not present
- Create sidecar directory: `mkdir -p {project-root}/_bmad/_memory/{sidecar-folder}/`
**Sidecar Management:**
- If changing sidecar-folder: update all critical_actions references
- If removing sidecar (Expert → Simple): remove sidecar fields and folder
- Create/update sidecar files as needed
**Metadata, Persona, Commands, Critical Actions:**
- Same as Simple agent edit
### 5. Validate Sidecar Paths
After editing, confirm all critical_actions reference correct sidecar paths:
`{project-root}/_bmad/_memory/{sidecar-folder}/{file}.md`
### 6. Document Applied Edits
Append to `{editPlan}` with sidecar changes noted.
### 7. Auto-Advance
When all edits applied successfully, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ Backup created
✅ All reference files loaded
✅ All edits applied correctly
✅ YAML remains valid
✅ Sidecar structure correct
✅ Sidecar paths validated
## FAILURE MODES
❌ Backup failed
❌ YAML became invalid
❌ Sidecar paths broken
❌ Edits not applied as specified
---
**Auto-advancing to post-edit validation...
@@ -1,120 +0,0 @@
---
name: 'e-08c-edit-module'
description: 'Apply edits to Module agent'
nextStepFile: './e-09a-validate-metadata.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentFile: '{original-agent-path}'
agentBackup: '{original-agent-path}.backup'
# Template and Architecture (use expert as baseline for Module)
expertTemplate: ../templates/expert-agent-template/expert-agent.template.md
expertArch: ../data/expert-agent-architecture.md
moduleArch: ../data/module-agent-validation.md
agentCompilation: ../data/agent-compilation.md
agentMetadata: ../data/agent-metadata.md
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
agentMenuPatterns: ../data/agent-menu-patterns.md
criticalActions: ../data/critical-actions.md
---
# Edit Step 8c: Edit Module Agent
## STEP GOAL:
Apply all planned edits to the Module agent YAML file and manage workflow integration and sidecar structure.
## MANDATORY EXECUTION RULES:
- 🛑 ALWAYS create backup before modifying agent file
- 📖 CRITICAL: Read template and architecture files first
- 🔄 CRITICAL: Load editPlan and agentFile
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Load all reference files before applying edits
- 📊 Manage workflow integration paths for Module agents
- 💾 Validate YAML and workflow paths after edits
- ➡️ Auto-advance to post-edit validation when complete
## EXECUTION PROTOCOLS:
- 🎯 Load template, architecture, and data files
- 📊 Read editPlan to get all planned changes
- 💾 Create backup
- 📝 Apply edits including workflow paths
- ✅ Validate YAML and workflow paths
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
### 1. Load Reference Documents
Read all files before editing:
- `{expertTemplate}` - Module uses expert as baseline
- `{expertArch}`, `{moduleArch}` - Architecture references
- `{agentCompilation}`, `{agentMetadata}`, `{personaProperties}`, `{principlesCrafting}`
- `{agentMenuPatterns}`, `{criticalActions}`
### 2. Load Edit Plan and Agent
Read `{editPlan}` to get all planned edits.
Read `{agentFile}` to get current agent YAML.
### 3. Create Backup
ALWAYS backup before editing:
`cp {agentFile} {agentBackup}`
### 4. Apply Edits in Sequence
**Type Conversion to Module:**
- Update `type: module`
- Add workflow integration paths
**Workflow Path Management:**
- Add: `skills: - workflow: {path}`
- Remove: delete workflow entries
- Modify: update workflow paths
**Sidecar for Multi-Workflow Modules:**
- If 3+ workflows: consider sidecar creation
- Add sidecar configuration if needed
**Metadata, Persona, Commands, Critical Actions:**
- Same as Expert agent edit
### 5. Validate Workflow Paths
After editing, confirm all workflow paths are valid:
`{project-root}/_bmad/{module-id}/workflows/{workflow-name}/workflow.md`
### 6. Document Applied Edits
Append to `{editPlan}` with workflow changes noted.
### 7. Auto-Advance
When all edits applied successfully, load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ Backup created
✅ All reference files loaded
✅ All edits applied correctly
✅ YAML remains valid
✅ Workflow paths validated
✅ Sidecar structure correct (if applicable)
## FAILURE MODES
❌ Backup failed
❌ YAML became invalid
❌ Workflow paths broken
❌ Edits not applied as specified
---
**Auto-advancing to post-edit validation...
@@ -1,14 +1,15 @@
---
name: 'e-10-celebrate'
name: 'e-09-celebrate'
description: 'Celebrate successful agent edit completion'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
validationWorkflow: '{project-root}/src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md'
---
# Edit Step 10: Celebration
# Edit Step 9: Celebration
## STEP GOAL:
@@ -48,7 +49,9 @@ Celebrate the successful agent edit, provide summary of changes, and mark edit w
- Limits: No more edits, only acknowledgment
- Dependencies: All edits successfully applied
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.:
### 1. Read Edit Plan
@@ -110,24 +113,26 @@ Append to editPlan:
### 6. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
Display: "**✅ Agent Edit Complete! Select an Option:** [V] Run Validation [S] Skip - Complete Now [A] Advanced Elicitation [P] Party Mode"
#### Menu Handling Logic:
- IF V: "Loading validation phase..." → Save completion status to {editPlan}, update frontmatter with edit completion, then load, read entire file, then execute {validationWorkflow}
- IF S: "Skipping validation. Completing workflow..." → Save completion status to {editPlan} and end workflow gracefully
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF X: Save completion status to {editPlan} and end workflow gracefully
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY complete workflow when user selects 'X'
- After other menu items execution, return to this menu
- User can choose validation (V), skip to complete (S), or use advanced elicitation (A) or party mode (P)
- After other menu items execution (A/P), return to this menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [X exit option] is selected and [completion documented], will the workflow end gracefully with agent edit complete.
ONLY WHEN [S skip option] is selected and [completion documented], will the workflow end gracefully with agent edit complete.
IF [V validation option] is selected, the validation workflow will be loaded to perform comprehensive validation checks.
---
@@ -1,70 +0,0 @@
---
name: 'e-09a-validate-metadata'
description: 'Validate metadata (after edit) - no menu, auto-advance'
nextStepFile: './e-09b-validate-persona.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMetadata: ../data/agent-metadata.md
---
# Edit Step 9a: Validate Metadata (After Edit)
## STEP GOAL:
Validate the agent's metadata properties after edits. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentMetadata first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate metadata against agentMetadata.md rules
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentMetadata.md reference
- 📊 Validate all metadata fields
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentMetadata}` and `{editPlan}`.
### 2. Validate Metadata
Perform checks on id, name, title, icon, module, hasSidecar.
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
validationAfter:
metadata:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All metadata checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to persona validation...**
@@ -1,70 +0,0 @@
---
name: 'e-09b-validate-persona'
description: 'Validate persona (after edit) - no menu, auto-advance'
nextStepFile: './e-09c-validate-menu.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
---
# Edit Step 9b: Validate Persona (After Edit)
## STEP GOAL:
Validate the agent's persona after edits. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and persona references first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate persona four-field system
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load personaProperties.md and principlesCrafting.md
- 📊 Validate persona fields
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{personaProperties}`, `{principlesCrafting}`, and `{editPlan}`.
### 2. Validate Persona
Perform checks on role, identity, communication_style, principles.
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
persona:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All persona checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to menu validation...**
@@ -1,69 +0,0 @@
---
name: 'e-09c-validate-menu'
description: 'Validate menu structure (after edit) - no menu, auto-advance'
nextStepFile: './e-09d-validate-structure.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
---
# Edit Step 9c: Validate Menu (After Edit)
## STEP GOAL:
Validate the agent's command menu structure after edits. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentMenuPatterns first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate command/menu structure
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentMenuPatterns.md reference
- 📊 Validate commands and menu
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentMenuPatterns}` and `{editPlan}`.
### 2. Validate Menu
Perform checks on A/P/C convention, command names, descriptions.
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
menu:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All menu checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to structure validation...**
@@ -1,69 +0,0 @@
---
name: 'e-09d-validate-structure'
description: 'Validate YAML structure (after edit) - no menu, auto-advance'
nextStepFile: './e-09e-validate-sidecar.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
agentCompilation: ../data/agent-compilation.md
---
# Edit Step 9d: Validate Structure (After Edit)
## STEP GOAL:
Validate the agent's YAML structure after edits. Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and agentCompilation first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate YAML structure and required fields
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load agentCompilation.md reference
- 📊 Validate YAML structure
- 💾 Record findings to editPlan
- ➡️ Auto-advance to next validation step when complete
## Sequence of Instructions:
### 1. Load References
Read `{agentCompilation}` and `{editPlan}`.
### 2. Validate Structure
Perform checks on YAML syntax, required fields, field types, indentation.
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
structure:
status: [pass|fail|warning]
findings:
- {check}: [pass|fail]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ All structure checks performed and recorded
✅ Findings saved to editPlan
✅ Auto-advanced to next step
---
**Auto-advancing to sidecar validation...**
@@ -1,70 +0,0 @@
---
name: 'e-09e-validate-sidecar'
description: 'Validate sidecar structure (after edit) - no menu, auto-advance'
nextStepFile: './e-09f-validation-summary.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
expertValidation: ../data/expert-agent-validation.md
---
# Edit Step 9e: Validate Sidecar (After Edit)
## STEP GOAL:
Validate the agent's sidecar structure after edits (if Expert type). Record findings to editPlan and auto-advance.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan and expertValidation first
- 🚫 NO MENU in this step - record findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate sidecar structure for Expert agents
- 📊 Record findings to editPlan frontmatter (validationAfter section)
- 🚫 FORBIDDEN to present menu - auto-advance when complete
## EXECUTION PROTOCOLS:
- 🎯 Load expertValidation.md reference
- 📊 Validate sidecar if Expert type, skip for Simple/Module
- 💾 Record findings to editPlan
- ➡️ Auto-advance to validation summary when complete
## Sequence of Instructions:
### 1. Load References
Read `{expertValidation}` and `{editPlan}` to get agent type.
### 2. Conditional Validation
**IF agentType == expert:** Check sidecar-folder, sidecar-path, file existence
**IF agentType != expert:** Mark as N/A
### 3. Record Findings
Append to editPlan frontmatter:
```yaml
sidecar:
status: [pass|fail|warning|n/a]
findings:
- {check}: [pass|fail|n/a]
```
### 4. Auto-Advance
Load and execute `{nextStepFile}` immediately.
## SUCCESS METRICS
✅ Sidecar checks performed (or N/A recorded)
✅ Findings saved to editPlan
✅ Auto-advanced to validation summary
---
**Auto-advancing to validation summary...**
@@ -1,111 +0,0 @@
---
name: 'e-09f-validation-summary'
description: 'Display all validation findings after edit'
nextStepFile: './e-10-celebrate.md'
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Edit Step 9f: Validation Summary (After Edit)
## STEP GOAL:
Display all post-edit validation findings and compare with pre-edit state. Present findings and await confirmation to proceed to celebration.
## MANDATORY EXECUTION RULES:
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read editPlan to collect all validation findings
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Display all validation findings clearly organized
- 📊 Compare before/after states
- 💬 Present options for handling any remaining issues
## EXECUTION PROTOCOLS:
- 🎯 Read editPlan to get validation findings
- 📊 Display organized summary with before/after comparison
- 💾 Allow user to decide how to proceed
## Sequence of Instructions:
### 1. Load Validation Findings
Read `{editPlan}` frontmatter to collect validationBefore and validationAfter findings.
### 2. Display Validation Summary
```markdown
## Post-Edit Validation Report for {agent-name}
### Before vs After Comparison
| Component | Before | After | Status |
|-----------|--------|-------|--------|
| Metadata | {status} | {status} | {Δ} |
| Persona | {status} | {status} | {Δ} |
| Menu | {status} | {status} | {Δ} |
| Structure | {status} | {status} | {Δ} |
| Sidecar | {status} | {status} | {Δ} |
### Detailed Findings (After Edit)
**Metadata:** {summary}
**Persona:** {summary}
**Menu:** {summary}
**Structure:** {summary}
**Sidecar:** {summary}
```
### 3. Present Options
"How do the edits look?
**[R]eview** - Show detailed before/after for any component
**[F]ix** - Address any remaining issues
**[A]ccept** - Proceed to celebration"
### 4. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Celebration"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF R: Show detailed before/after comparison, then redisplay menu
- IF C: Save validation summary to {editPlan}, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [validation summary displayed], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All validation findings displayed clearly
- Before/after comparison shown
- User given options for handling issues
### ❌ SYSTEM FAILURE:
- Findings not displayed to user
- Proceeding without user acknowledgment
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
@@ -34,26 +34,34 @@ Load the existing agent file and initialize a validation report to track all fin
- 💾 Create validation report document
- 🚫 FORBIDDEN to proceed without user confirmation
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Agent File
Read the complete YAML from the agent file path provided by the user.
Check the metadata to determine agent configuration:
- **module**: `stand-alone` or module code (bmm, cis, bmgd, etc.)
- **hasSidecar**: `true` or `false`
### 2. Display Agent Summary
```markdown
## Agent to Validate: {agent-name}
**Type:** {simple|expert|module}
**Version:** {version}
**Configuration:** Agent {WITH|WITHOUT} sidecar
**hasSidecar:** {true|false}
**module:** {module-value}
**File:** {agent-file-path}
### Current Structure:
**Persona:** {character count} characters
**Commands:** {count} commands
**Critical Actions:** {count} actions
**Critical Actions:** {count} actions (if hasSidecar: true)
**Sidecar:** {present|not present}
```
### 3. Create Validation Report
@@ -63,7 +71,8 @@ Initialize the validation report:
```markdown
---
agentName: '{agent-name}'
agentType: '{simple|expert|module}'
hasSidecar: {true|false}
module: '{module-value}'
agentFile: '{agent-file-path}'
validationDate: '{YYYY-MM-DD}'
stepsCompleted:
@@ -75,8 +84,8 @@ stepsCompleted:
## Agent Overview
**Name:** {agent-name}
**Type:** {simple|expert|module}
**Version:** {version}
**hasSidecar:** {true|false}
**module:** {module-value}
**File:** {agent-file-path}
---
@@ -90,7 +99,7 @@ Write to `{validationReport}`.
### 4. Present MENU OPTIONS
Display: "**Is this the correct agent to validate?** [A] Advanced Elicitation [P] Party Mode [C] Yes, Begin Validation"
Display: "**Is this the correct agent to validate and is it identified as the proper configuration?** [A] Advanced Elicitation [P] Party Mode [C] Yes, Begin Validation"
#### Menu Handling Logic:
@@ -5,18 +5,20 @@ description: 'Validate metadata and append to report'
nextStepFile: './v-02b-validate-persona.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
agentMetadata: ../data/agent-metadata.md
agentFile: '{agent-file-path}'
---
# Validate Step 2a: Validate Metadata
## STEP GOAL:
## STEP GOAL
Validate the agent's metadata properties against BMAD standards. Append findings to validation report and auto-advance.
Validate the agent's metadata properties against BMAD standards as defined in agentMetadata.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and agentMetadata first
- 🔄 CRITICAL: Load the actual agent file to validate metadata
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
@@ -26,22 +28,55 @@ Validate the agent's metadata properties against BMAD standards. Append findings
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load agentMetadata.md reference
- 🎯 Load the actual agent file for validation
- 📊 Validate all metadata fields
- 💾 Append findings to validation report
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{agentMetadata}` and `{validationReport}`.
Read `{agentMetadata}`, `{validationReport}`, and `{agentFile}`.
### 2. Validate Metadata
Perform checks on: id, name, title, icon, module, hasSidecar.
Perform these checks systematically - validate EVERY rule specified in agentMetadata.md:
1. **Required Fields Existence**
- [ ] id: Present and non-empty
- [ ] name: Present and non-empty (display name)
- [ ] title: Present and non-empty
- [ ] icon: Present (emoji or symbol)
- [ ] module: Present and valid format
- [ ] hasSidecar: Present (boolean, if applicable)
2. **Format Validation**
- [ ] id: Uses kebab-case, no spaces, unique identifier
- [ ] name: Clear display name for UI
- [ ] title: Concise functional description
- [ ] icon: Appropriate emoji or unicode symbol
- [ ] module: Either a 3-4 letter module code OR 'stand-alone'
- [ ] hasSidecar: Boolean value, matches actual agent structure
3. **Content Quality**
- [ ] id: Unique and descriptive
- [ ] name: Clear and user-friendly
- [ ] title: Accurately describes agent's function
- [ ] icon: Visually representative of agent's purpose
- [ ] module: Correctly identifies module membership
- [ ] hasSidecar: Correctly indicates if agent uses sidecar files
4. **Agent Type Consistency**
- [ ] If hasSidecar: true, sidecar folder path must be specified
- [ ] If module is a module code, agent is a module agent
- [ ] If module is 'stand-alone', agent is not part of a module
- [ ] No conflicting type indicators
### 3. Append Findings to Report
@@ -53,15 +88,23 @@ Append to `{validationReport}`:
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
**Checks:**
- [ ] id: kebab-case, no spaces
- [ ] id: kebab-case, no spaces, unique
- [ ] name: clear display name
- [ ] title: concise function description
- [ ] icon: appropriate emoji/symbol
- [ ] module: correct format `{project}:{type}:{name}`
- [ ] module: correct format (code or stand-alone)
- [ ] hasSidecar: matches actual usage
**Findings:**
{Detailed findings}
**Detailed Findings:**
*PASSING:*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
```
### 4. Auto-Advance
@@ -6,43 +6,87 @@ nextStepFile: './v-02c-validate-menu.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
agentFile: '{agent-file-path}'
---
# Validate Step 2b: Validate Persona
## STEP GOAL:
## STEP GOAL
Validate the agent's persona against BMAD standards. Append findings to validation report and auto-advance.
Validate the agent's persona against BMAD standards as defined in personaProperties.md and principlesCrafting.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and persona references first
- 🔄 CRITICAL: Load the actual agent file to validate persona
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate persona four-field system
- 🎯 Validate persona against personaProperties.md rules
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load personaProperties.md and principlesCrafting.md
- 🎯 Load the actual agent file for validation
- 📊 Validate persona fields
- 💾 Append findings to validation report
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{personaProperties}`, `{principlesCrafting}`, and `{validationReport}`.
Read `{personaProperties}`, `{principlesCrafting}`, `{validationReport}`, and `{agentFile}`.
### 2. Validate Persona
Perform checks on: role, identity, communication_style, principles.
Perform these checks systematically - validate EVERY rule specified in personaProperties.md:
1. **Required Fields Existence**
- [ ] role: Present, clear, and specific
- [ ] identity: Present and defines who the agent is
- [ ] communication_style: Present and appropriate to role
- [ ] principles: Present as array, not empty (if applicable)
2. **Content Quality - Role**
- [ ] Role is specific (not generic like "assistant")
- [ ] Role aligns with agent's purpose and menu items
- [ ] Role is achievable within LLM capabilities
- [ ] Role scope is appropriate (not too broad/narrow)
3. **Content Quality - Identity**
- [ ] Identity clearly defines the agent's character
- [ ] Identity is consistent with the role
- [ ] Identity provides context for behavior
- [ ] Identity is not generic or cliché
4. **Content Quality - Communication Style**
- [ ] Communication style is clearly defined
- [ ] Style matches the role and target users
- [ ] Style is consistent throughout the definition
- [ ] Style examples or guidance provided if nuanced
- [ ] Style focuses on speech patterns only (not behavior)
5. **Content Quality - Principles**
- [ ] Principles are actionable (not vague platitudes)
- [ ] Principles guide behavior and decisions
- [ ] Principles are consistent with role
- [ ] 3-7 principles recommended (not overwhelming)
- [ ] Each principle is clear and specific
- [ ] First principle activates domain knowledge
6. **Consistency Checks**
- [ ] Role, identity, communication_style, principles all align
- [ ] No contradictions between principles
- [ ] Persona supports the menu items defined
- [ ] Language and terminology consistent
### 3. Append Findings to Report
@@ -57,10 +101,18 @@ Append to `{validationReport}`:
- [ ] role: specific, not generic
- [ ] identity: defines who agent is
- [ ] communication_style: speech patterns only
- [ ] principles: first principle activates expert knowledge
- [ ] principles: first principle activates domain knowledge
**Findings:**
{Detailed findings}
**Detailed Findings:**
*PASSING:*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
```
### 4. Auto-Advance
@@ -5,43 +5,88 @@ description: 'Validate menu structure and append to report'
nextStepFile: './v-02d-validate-structure.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
agentFile: '{agent-file-path}'
---
# Validate Step 2c: Validate Menu
## STEP GOAL:
## STEP GOAL
Validate the agent's command menu structure against BMAD standards. Append findings to validation report and auto-advance.
Validate the agent's command menu structure against BMAD standards as defined in agentMenuPatterns.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and agentMenuPatterns first
- 🔄 CRITICAL: Load the actual agent file to validate menu
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate command/menu structure
- 🎯 Validate menu against agentMenuPatterns.md rules
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load agentMenuPatterns.md reference
- 🎯 Load the actual agent file for validation
- 📊 Validate commands and menu
- 💾 Append findings to validation report
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{agentMenuPatterns}` and `{validationReport}`.
Read `{agentMenuPatterns}`, `{validationReport}`, and `{agentFile}`.
### 2. Validate Menu
Perform checks on: A/P/C convention, command names, descriptions.
Perform these checks systematically - validate EVERY rule specified in agentMenuPatterns.md:
1. **Menu Structure**
- [ ] Menu section exists and is properly formatted
- [ ] At least one menu item defined (unless intentionally tool-less)
- [ ] Menu items follow proper YAML structure
- [ ] Each item has required fields (trigger, description, action)
2. **Menu Item Requirements**
For each menu item:
- [ ] trigger: Present, follows `XX or fuzzy match on command` format
- [ ] description: Clear and concise, starts with `[XX]` code
- [ ] action: Prompt reference (#id) or inline instruction
3. **Trigger Format Validation**
- [ ] Format: `XX or fuzzy match on command-name` (XX = 2-letter code)
- [ ] Codes are unique within agent
- [ ] No reserved codes used: MH, CH, PM, DA
4. **Description Format Validation**
- [ ] Descriptions start with `[XX]` code
- [ ] Code in description matches trigger code
- [ ] Descriptions are clear and descriptive
5. **Action Handler Validation**
- [ ] If `action: '#prompt-id'`, corresponding prompt exists
- [ ] If `action: 'inline text'`, instruction is complete and clear
6. **Alignment Checks**
- [ ] Menu items align with agent's role/purpose
- [ ] Menu items are appropriate for target users
- [ ] Menu scope is appropriate (not too sparse/overloaded)
7. **Configuration Specific Menu Handler Validation**
- [ ] Determine hasSidecar from metadata
- [ ] For hasSidecar: true:
- [ ] Menu handlers MAY reference sidecar files using correct path format
- [ ] Sidecar references use: `{project-root}/_bmad/_memory/{sidecar-folder}/...`
- [ ] For hasSidecar: false:
- [ ] Menu handlers MUST NOT have sidecar file links
- [ ] Menu handlers use only internal references (#) or inline prompts
### 3. Append Findings to Report
@@ -52,14 +97,25 @@ Append to `{validationReport}`:
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
**Checks:**
- [ ] A/P/C convention followed
- [ ] Command names clear and descriptive
- [ ] Command descriptions specific and actionable
- [ ] Menu handling logic properly specified
**hasSidecar:** {true|false}
**Findings:**
{Detailed findings}
**Checks:**
- [ ] Triggers follow `XX or fuzzy match on command` format
- [ ] Descriptions start with `[XX]` code
- [ ] No reserved codes (MH, CH, PM, DA)
- [ ] Action handlers valid (#prompt-id or inline)
- [ ] Configuration appropriate menu links
**Detailed Findings:**
*PASSING:*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
```
### 4. Auto-Advance
@@ -4,44 +4,94 @@ description: 'Validate YAML structure and append to report'
nextStepFile: './v-02e-validate-sidecar.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
agentValidation: ../data/agent-validation.md
agentCompilation: ../data/agent-compilation.md
agentFile: '{agent-file-path}'
---
# Validate Step 2d: Validate Structure
## STEP GOAL:
## STEP GOAL
Validate the agent's YAML structure and completeness. Append findings to validation report and auto-advance.
Validate the agent's YAML structure and completeness against BMAD standards as defined in agentCompilation.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and agentCompilation first
- 🔄 CRITICAL: Load the actual agent file to validate structure
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate YAML structure and required fields
- 🎯 Validate structure against agentCompilation.md rules
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load agentCompilation.md reference
- 🎯 Load the actual agent file for validation
- 📊 Validate YAML structure
- 💾 Append findings to validation report
- ➡️ Auto-advance to next validation step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{agentCompilation}` and `{validationReport}`.
Read `{agentCompilation}`, `{agentValidation}`, `{validationReport}`, and `{agentFile}`.
### 2. Validate Structure
Perform checks on: YAML syntax, required fields, field types, indentation.
Perform these checks systematically - validate EVERY rule specified in agentCompilation.md:
#### A. YAML Syntax Validation
- [ ] Parse YAML without errors
- [ ] Check indentation consistency (2-space standard)
- [ ] Validate proper escaping of special characters
- [ ] Verify no duplicate keys in any section
#### B. Frontmatter Validation
- [ ] All required fields present (name, description, version, etc.)
- [ ] Field values are correct type (string, boolean, array)
- [ ] No empty required fields
- [ ] Proper array formatting with dashes
- [ ] Boolean fields are actual booleans (not strings)
#### C. Section Completeness
- [ ] All required sections present based on hasSidecar value
- [ ] Sections not empty unless explicitly optional
- [ ] Proper markdown heading hierarchy (##, ###)
- [ ] No orphaned content without section headers
#### D. Field-Level Validation
- [ ] Path references exist and are valid
- [ ] Array fields properly formatted
- [ ] No malformed YAML structures
- [ ] File references use correct path format
#### E. Agent Configuration Specific Checks
**For Agents WITHOUT Sidecar (hasSidecar is false):**
- [ ] No sidecar requirements
- [ ] No sidecar-folder path in metadata
- [ ] If critical_actions present, no sidecar file references
- [ ] Menu handlers use only internal references (#) or inline prompts
- [ ] Total size under ~250 lines (unless justified)
**For Agents WITH Sidecar (hasSidecar is true):**
- [ ] hasSidecar flag set correctly in metadata
- [ ] Sidecar folder path specified in metadata
- [ ] critical_actions section present with minimum requirements:
- [ ] Loads sidecar memories
- [ ] Loads sidecar instructions
- [ ] Restricts file access to sidecar folder
- [ ] All critical_actions reference correct `{project-root}/_bmad/_memory/` paths
- [ ] Menu handlers that update sidecar use correct path format
### 3. Append Findings to Report
@@ -52,14 +102,27 @@ Append to `{validationReport}`:
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL}
**Configuration:** Agent {WITH|WITHOUT} sidecar
**hasSidecar:** {true|false}
**Checks:**
- [ ] Valid YAML syntax
- [ ] Required fields present (name, description, type, persona)
- [ ] Field types correct (arrays, strings)
- [ ] Required fields present (name, description, persona, menu)
- [ ] Field types correct (arrays, strings, booleans)
- [ ] Consistent 2-space indentation
- [ ] Configuration appropriate structure
**Findings:**
{Detailed findings}
**Detailed Findings:**
*PASSING:*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
```
### 4. Auto-Advance
@@ -4,50 +4,93 @@ description: 'Validate sidecar structure and append to report'
nextStepFile: './v-03-summary.md'
validationReport: '{bmb_creations_output_folder}/validation-report-{agent-name}.md'
expertValidation: ../data/expert-agent-validation.md
agentValidation: ../data/agent-validation.md
criticalActions: ../data/critical-actions.md
agentFile: '{agent-file-path}'
sidecarFolder: '{agent-sidecar-folder}'
---
# Validate Step 2e: Validate Sidecar
## STEP GOAL:
## STEP GOAL
Validate the agent's sidecar structure (if Expert type). Append findings to validation report and auto-advance.
Validate the agent's sidecar structure (if hasSidecar: true) against BMAD standards as defined in agentValidation.md. Append findings to validation report and auto-advance.
## MANDATORY EXECUTION RULES:
## MANDATORY EXECUTION RULES
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: Read validationReport and expertValidation first
- 🔄 CRITICAL: Read validationReport and agentValidation first
- 🔄 CRITICAL: Load the actual agent file to check for sidecar
- 🚫 NO MENU - append findings and auto-advance
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Step-Specific Rules:
- 🎯 Validate sidecar structure for Expert agents
- 🎯 Validate sidecar against agentValidation.md rules (for agents with sidecar)
- 📊 Append findings to validation report
- 🚫 FORBIDDEN to present menu
## EXECUTION PROTOCOLS:
## EXECUTION PROTOCOLS
- 🎯 Load expertValidation.md reference
- 📊 Validate sidecar if Expert type, skip for Simple/Module
- 🎯 Load agentValidation.md reference
- 🎯 Load the actual agent file for validation
- 📊 Validate sidecar if hasSidecar: true, skip for hasSidecar: false
- 💾 Append findings to validation report
- ➡️ Auto-advance to summary step
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load References
Read `{expertValidation}` and `{validationReport}` to get agent type.
Read `{agentValidation}`, `{criticalActions}`, `{validationReport}`, and `{agentFile}`.
### 2. Conditional Validation
**IF agentType == expert:**
- Check metadata.sidecar-folder present
- Check sidecar-path correct format
- Verify sidecar files exist
**IF hasSidecar = true:**
Perform these checks systematically - validate EVERY rule specified in agentValidation.md:
**IF agentType != expert:**
- Mark as N/A
#### A. Sidecar Folder Validation
- [ ] Sidecar folder exists at specified path
- [ ] Sidecar folder is accessible and readable
- [ ] Sidecar folder path in metadata matches actual location
- [ ] Folder naming follows convention: `{agent-name}-sidecar`
#### B. Sidecar File Inventory
- [ ] List all files in sidecar folder
- [ ] Verify expected files are present (memories.md, instructions.md recommended)
- [ ] Check for unexpected files
- [ ] Validate file names follow conventions
#### C. Path Reference Validation
For each sidecar path reference in agent YAML:
- [ ] Extract path from YAML reference
- [ ] Verify path format is correct: `{project-root}/_bmad/_memory/{sidecar-folder}/...`
- [ ] `{project-root}` is literal
- [ ] `{sidecar-folder}` is actual folder name
- [ ] Validate no broken path references
#### D. Critical Actions Validation (MANDATORY for hasSidecar: true)
- [ ] critical_actions section exists in agent YAML
- [ ] Contains at minimum 3 actions
- [ ] Loads sidecar memories: `{project-root}/_bmad/_memory/{sidecar-folder}/memories.md`
- [ ] Loads sidecar instructions: `{project-root}/_bmad/_memory/{sidecar-folder}/instructions.md`
- [ ] Restricts file access: `ONLY read/write files in {project-root}/_bmad/_memory/{sidecar-folder}/`
- [ ] No placeholder text in critical_actions
- [ ] No compiler-injected steps
#### E. Sidecar Structure Completeness
- [ ] All referenced sidecar files present
- [ ] No orphaned references (files referenced but not present)
- [ ] No unreferenced files (files present but not referenced)
- [ ] File structure matches agent requirements
**IF hasSidecar = false:**
- [ ] Mark sidecar validation as N/A
- [ ] Confirm no sidecar-folder path in metadata
- [ ] Confirm no sidecar references in critical_actions (if present)
- [ ] Confirm no sidecar references in menu handlers
### 3. Append Findings to Report
@@ -58,13 +101,28 @@ Append to `{validationReport}`:
**Status:** {✅ PASS / ⚠️ WARNING / ❌ FAIL / N/A}
**Checks:**
- [ ] metadata.sidecar-folder present (Expert only)
- [ ] sidecar-path format correct
- [ ] Sidecar files exist at specified path
**hasSidecar:** {true|false}
**Findings:**
{Detailed findings or "N/A - Not an Expert agent"}
**Checks:**
- [ ] metadata.sidecar-folder present (if hasSidecar: true)
- [ ] Sidecar path format correct: `{project-root}/_bmad/_memory/{sidecar-folder}/...`
- [ ] Sidecar files exist at specified path (if hasSidecar: true)
- [ ] All referenced files present
- [ ] No broken path references
**Detailed Findings:**
*PASSING (for agents WITH sidecar):*
{List of passing checks}
*WARNINGS:*
{List of non-blocking issues}
*FAILURES:*
{List of blocking issues that must be fixed}
*N/A (for agents WITHOUT sidecar):*
N/A - Agent has hasSidecar: false, no sidecar required
```
### 4. Auto-Advance
@@ -32,7 +32,9 @@ Display the complete validation report to the user and offer options for fixing
- 📊 Display organized summary
- 💾 Allow user to decide next steps
## Sequence of Instructions:
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Load Validation Report
@@ -57,6 +59,7 @@ Read `{validationReport}` to collect all validation findings.
"What would you like to do?
**[E]dit Agent** - Launch edit workflow to fix issues or make improvements
**[F]ix in Place** - Confirm which fixes you would like right now and we can fix without loading the full agent edit workflow
**[S]ave Report** - Save this validation report and exit
**[R]etry** - Run validation again (if you've made external changes)"
@@ -69,6 +72,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [E] Edit
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF E: Inform user they can launch edit workflow with the same agent file, then redisplay menu
- IF F; Attempt to make users desired fixes without loading the full edit workflow
- IF S: Save final report to {validationReport} and end workflow
- IF R: Restart validation from step v-01
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
@@ -1,8 +1,8 @@
{{#if comment}}
------------------------------------------------------------------------------
Expert Agent Handlebars Template
Used by: step-06-build.md to generate final agent YAML
Documentation: ../../data/expert-agent-architecture.md
Agent Handlebars Template (Unified)
Used by: step-07-build-agent.md to generate final agent YAML
Documentation: ../data/agent-architecture.md
------------------------------------------------------------------------------
{{/if}}
agent:
@@ -12,11 +12,16 @@ agent:
title: {{agent_title}}
icon: {{agent_icon}}
module: {{agent_module}}{{#if agent_module_comment}} {{!-- stand-alone, bmm, cis, bmgd, or other module --}}{{/if}}
hasSidecar: {{has_sidecar}}{{#if has_sidecar_comment}} {{!-- true if agent has a sidecar folder, false otherwise --}}{{/if}}
{{#if has_sidecar}}
sidecar-folder: {{sidecar_folder}}
sidecar-path: '{project-root}/_bmad/_memory/{{sidecar_folder}}/'
{{/if}}
persona:
role: |
{{persona_role}}{{#if persona_role_note}}
{{!-- 1-2 sentences, first person --}}{{/if}}
{{!-- 1-2 sentences, first person, what the agent does --}}{{/if}}
identity: |
{{persona_identity}}{{#if persona_identity_note}}
@@ -24,17 +29,23 @@ agent:
communication_style: |
{{communication_style}}{{#if communication_style_note}}
{{!-- How the agent speaks, include memory reference patterns --}}{{/if}}
{{!-- How the agent speaks: tone, voice, mannerisms --}}
{{#if has_sidecar}}
{{!-- Include memory reference patterns: "Last time you mentioned..." or "I've noticed patterns..." --}}
{{/if}}
{{/if}}
principles:
{{#each principles}}
- {{this}}
{{/each}}
{{#if has_critical_actions}}
critical_actions:
{{#each critical_actions}}
- '{{{this}}}'
{{/each}}
{{/if}}
{{#if has_prompts}}
prompts:
@@ -50,6 +61,8 @@ agent:
- trigger: {{trigger_code}} or fuzzy match on {{trigger_command}}
{{#if action_is_prompt}}
action: '#{{action_id}}'
{{else if action_updates_sidecar}}
action: {{{action_inline}}}
{{else}}
action: {{{action_inline}}}
{{/if}}
@@ -1,71 +0,0 @@
{{#if comment}}
------------------------------------------------------------------------------
Simple Agent Handlebars Template
Used by: step-06-build.md to generate final agent YAML
Documentation: ../data/simple-agent-architecture.md
------------------------------------------------------------------------------
{{/if}}
agent:
metadata:
id: {{agent_id}}
name: {{agent_name}}
title: {{agent_title}}
icon: {{agent_icon}}
module: {{agent_module}}{{#if agent_module_comment}} {{!-- stand-alone, bmm, cis, bmgd, or other module --}}{{/if}}
persona:
role: |
{{persona_role}}{{#if persona_role_note}}
{{!-- 1-2 sentences, first person --}}{{/if}}
identity: |
{{persona_identity}}{{#if persona_identity_note}}
{{!-- 2-5 sentences, first person, background/specializations --}}{{/if}}
communication_style: |
{{communication_style}}{{#if communication_style_note}}
{{!-- How the agent speaks: tone, voice, mannerisms --}}{{/if}}
principles:
{{#each principles}}
- {{this}}
{{/each}}
{{#if has_prompts}}
prompts:
{{#each prompts}}
- id: {{id}}
content: |
{{{content}}}
{{/each}}
{{/if}}
menu:
{{#each menu_items}}
- trigger: {{trigger_code}} or fuzzy match on {{trigger_command}}
{{#if action_is_prompt}}
action: '#{{action_id}}'
{{else}}
action: {{{action_inline}}}
{{/if}}
description: '[{{trigger_code}}] {{{description}}}'
{{/each}}
{{#if has_install_config}}
install_config:
compile_time_only: true
description: '{{install_description}}'
questions:
{{#each install_questions}}
- var: {{var_name}}
prompt: '{{prompt}}'
type: {{question_type}}{{#if question_options}}
options:
{{#each question_options}}
- label: '{{label}}'
value: '{{value}}'
{{/each}}
{{/if}}
default: {{{default_value}}}
{{/each}}
{{/if}}
@@ -0,0 +1,72 @@
---
name: create-agent
description: Create a new BMAD agent with best practices and compliance
web_bundle: true
createWorkflow: './steps-c/step-01-brainstorm.md'
---
# Create Agent
**Goal:** Collaboratively create BMAD Core compliant agents through guided discovery and systematic execution.
**Your Role:** In addition to your name, communication_style, and persona, you are also an expert agent architect specializing in BMAD Core agent creation. You guide users through creating new agents with best practices and full compliance.
---
## 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**: Steps completed in order
- **State Tracking**: Document progress in tracking files (agentPlan)
- **Mode-Aware Routing**: Create-specific step flow
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute numbered sections in order
3. **WAIT FOR INPUT**: Halt at menus and wait for user selection
4. **CHECK CONTINUATION**: Only proceed when user selects appropriate option
5. **SAVE STATE**: Update progress before loading next step
6. **LOAD NEXT**: When directed, load and execute the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps unless explicitly optional
- 💾 **ALWAYS** save progress and outputs
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** pre-load future steps
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml`:
- `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 new BMAD Core compliant agent from scratch.**"
Load, read completely, then execute `{createWorkflow}` (steps-c/step-01-brainstorm.md)
---
## CREATE MODE NOTES
- Starts with optional brainstorming
- Progresses through discovery, metadata, persona, commands, activation
- Builds agent based on type (Simple/Expert/Module)
- Validates built agent
- Celebrates completion with installation guidance
@@ -0,0 +1,75 @@
---
name: edit-agent
description: Edit existing BMAD agents while maintaining compliance
web_bundle: true
editWorkflow: './steps-e/e-01-load-existing.md'
---
# Edit Agent
**Goal:** Modify existing BMAD Core compliant agents while maintaining their integrity and compliance.
**Your Role:** In addition to your name, communication_style, and persona, you are also an expert agent architect specializing in BMAD Core agent lifecycle management. You guide users through editing existing agents while preserving their core functionality and compliance.
---
## 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**: Steps completed in order
- **State Tracking**: Document progress in tracking files (editPlan)
- **Mode-Aware Routing**: Edit-specific step flow
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute numbered sections in order
3. **WAIT FOR INPUT**: Halt at menus and wait for user selection
4. **CHECK CONTINUATION**: Only proceed when user selects appropriate option
5. **SAVE STATE**: Update progress before loading next step
6. **LOAD NEXT**: When directed, load and execute the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps unless explicitly optional
- 💾 **ALWAYS** save progress and outputs
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** pre-load future steps
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml`:
- `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 Core compliant agent.**"
Prompt for agent file path: "Which agent would you like to edit? Please provide the path to the `.agent.yaml` file."
Then load, read completely, and execute `{editWorkflow}` (steps-e/e-01-load-existing.md)
---
## EDIT MODE NOTES
- Loads existing agent first
- Discovers what user wants to change
- Validates current agent before editing
- Creates structured edit plan
- Applies changes with validation
- Celebrates successful edit
@@ -0,0 +1,73 @@
---
name: validate-agent
description: Validate existing BMAD agents and offer to improve deficiencies
web_bundle: true
validateWorkflow: './steps-v/v-01-load-review.md'
---
# Validate Agent
**Goal:** Review existing BMAD Core compliant agents through systematic validation and generate comprehensive reports.
**Your Role:** In addition to your name, communication_style, and persona, you are also a validation specialist and quality assurance expert for BMAD Core agents. You conduct systematic reviews and provide actionable improvement 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**: Steps completed in order
- **State Tracking**: Document progress in tracking files (validationReport)
- **Mode-Aware Routing**: Validate-specific step flow
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute numbered sections in order
3. **WAIT FOR INPUT**: Halt at menus and wait for user selection
4. **CHECK CONTINUATION**: Only proceed when user selects appropriate option
5. **SAVE STATE**: Update progress before loading next step
6. **LOAD NEXT**: When directed, load and execute the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps unless explicitly optional
- 💾 **ALWAYS** save progress and outputs
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** pre-load future steps
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml`:
- `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: Reviewing an existing BMAD Core compliant agent.**"
Prompt for agent file path: "Which agent would you like to validate? Please provide the path to the `.agent.yaml` file."
Then load, read completely, and execute `{validateWorkflow}` (steps-v/v-01-load-review.md)
---
## VALIDATE MODE NOTES
- Loads existing agent
- Runs systematic validation (metadata, persona, menu, structure, sidecar)
- Generates comprehensive validation report
- Offers option to apply fixes if user desires
-123
View File
@@ -1,123 +0,0 @@
---
name: agent
description: Tri-modal workflow for creating, editing, and validating BMAD Core compliant agents
web_bundle: true
---
# Agent Workflow
**Goal:** Collaboratively create, edit, or validate BMAD Core compliant agents through guided discovery and systematic execution.
**Your Role:** In addition to your name, communication_style, and persona, you are also an expert agent architect specializing in BMAD Core agent lifecycle management. You guide users through creating new agents, editing existing ones, or validating agent configurations.
---
## 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**: Steps completed in order, conditional based on mode
- **State Tracking**: Document progress in tracking files (agentPlan, editPlan, validationReport)
- **Mode-Aware Routing**: Separate step flows for Create/Edit/Validate
### Step Processing Rules
1. **READ COMPLETELY**: Always read the entire step file before taking any action
2. **FOLLOW SEQUENCE**: Execute numbered sections in order
3. **WAIT FOR INPUT**: Halt at menus and wait for user selection
4. **CHECK CONTINUATION**: Only proceed when user selects appropriate option
5. **SAVE STATE**: Update progress before loading next step
6. **LOAD NEXT**: When directed, load and execute the next step file
### Critical Rules
- 🛑 **NEVER** load multiple step files simultaneously
- 📖 **ALWAYS** read entire step file before execution
- 🚫 **NEVER** skip steps unless explicitly optional
- 💾 **ALWAYS** save progress and outputs
- 🎯 **ALWAYS** follow exact instructions in step files
- ⏸️ **ALWAYS** halt at menus and wait for input
- 📋 **NEVER** pre-load future steps
---
## MODE OVERVIEW
This workflow supports three modes:
| Mode | Purpose | Entry Point | Output |
|------|---------|-------------|--------|
| **Create** | Build new agent from scratch | `steps-c/step-01-brainstorm.md` | New `.agent.yaml` file |
| **Edit** | Modify existing agent | `steps-e/e-01-load-existing.md` | Updated `.agent.yaml` file |
| **Validate** | Review existing agent | `steps-v/v-01-load-review.md` | Validation report |
---
## INITIALIZATION SEQUENCE
### 1. Configuration Loading
Load and read full config from `{project-root}/_bmad/bmb/config.yaml`:
- `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. Mode Determination
**Check if mode was specified in the command invocation:**
- If user invoked with "create agent" or "new agent" → Set mode to **create**
- If user invoked with "edit agent" or "modify agent" → Set mode to **edit**
- If user invoked with "validate agent" or "review agent" → Set mode to **validate**
**If mode is unclear from command, ask user:**
"Welcome to the BMAD Agent Workflow! What would you like to do?
**[C]reate** - Build a new agent from scratch
**[E]dit** - Modify an existing agent
**[V]alidate** - Review an existing agent and generate report
Please select: [C]reate / [E]dit / [V]alidate"
### 3. Route to First Step
**IF mode == create:**
Load, read completely, then execute `steps-c/step-01-brainstorm.md`
**IF mode == edit:**
Prompt for agent file path: "Which agent would you like to edit? Please provide the path to the `.agent.yaml` file."
Then load, read completely, and execute `steps-e/e-01-load-existing.md`
**IF mode == validate:**
Prompt for agent file path: "Which agent would you like to validate? Please provide the path to the `.agent.yaml` file."
Then load, read completely, and execute `steps-v/v-01-load-review.md`
---
## MODE-SPECIFIC NOTES
### Create Mode
- Starts with optional brainstorming
- Progresses through discovery, metadata, persona, commands, activation
- Builds agent based on type (Simple/Expert/Module)
- Validates built agent
- Celebrates completion with installation guidance
### Edit Mode
- Loads existing agent first
- Discovers what user wants to change
- Validates current agent before editing
- Creates structured edit plan
- Applies changes with validation
- Celebrates successful edit
### Validate Mode
- Loads existing agent
- Runs systematic validation (metadata, persona, menu, structure, sidecar)
- Generates comprehensive validation report
- Offers option to apply fixes if user desires
@@ -1,156 +0,0 @@
---
nextStepFile: '{installed_path}/steps/step-02-concept.md'
continueFile: '{installed_path}/steps/step-01b-continue.md'
modulePlanTemplate: '{installed_path}/templates/module-plan.template.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
customModuleLocation: '{bmb_creations_output_folder}'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
---
# Step 1: Workflow Initialization
## STEP GOAL:
To initialize the create-module workflow by getting the module name from the user, checking for existing work, handling continuation if needed, and creating the initial module plan document.
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and BMAD Systems Specialist
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD architecture and module creation, user brings their module requirements
- ✅ Maintain collaborative, guiding tone throughout
### Step-Specific Rules:
- 🎯 Focus ONLY on initialization, getting module name, and setting up tracking
- 🚫 FORBIDDEN to look ahead to future steps
- 💬 Handle initialization professionally
- 🚪 DETECT existing workflow state and handle continuation properly
## EXECUTION PROTOCOLS:
- 🎯 Show analysis before taking any action
- 💾 Initialize document and update frontmatter
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
- 🚫 FORBIDDEN to load next step until setup is complete
## CONTEXT BOUNDARIES:
- Variables from workflow.md are available in memory
- Previous context = what's in output document + frontmatter
- Don't assume knowledge from other steps
- Module brief discovery happens in this step
## SEQUENCE OF INSTRUCTIONS:
### 1. Welcome and Get Module Name
Greet the user warmly by their {user_name}, welcoming them to the BMAD Module Creator. Through conversation, collaboratively work with them to:
- Understand what kind of module they want to create
- Help them choose a good name in kebab-case (provide examples if needed)
- Validate the name will work for module creation
### 2. Check for Existing Work
Once you have the module name:
- Check if a folder already exists at {customModuleLocation}/{module_name}
- If it exists, look for a module plan document inside
- Read any existing work carefully to understand what was already done
### 3. Handle Continuation (If Work Exists)
If you find an existing module plan:
- Review what's been completed based on the stepsCompleted array
- Present a clear summary of the current status
- Ask if they want to continue where they left off, update existing work, or start fresh
- If continuing, load step-01b-continue.md
### 4. Look for Supporting Documents
Check for any existing documents that could help:
- Module briefs in the module folder or output folder
- Brainstorming results in the output folder
- Any other relevant documentation
### 5. Guide User's Next Decision
If no supporting documents are found:
- Explain their three options clearly and helpfully
- Option 1: Proceed with creating the module based on their ideas
- Option 2: Exit and create a module brief first (explain the module-brief workflow)
- Option 3: Exit and do brainstorming first (explain the brainstorming workflow)
- Support whatever choice they make
### 6. Create Module Foundation
If proceeding:
- Create the module folder if needed
- Create the initial module-plan-{module_name}.md document using the module plan template from {modulePlanTemplate}
- Initialize proper frontmatter with current date, user name, and add "step-01-init" to stepsCompleted array
- Add any discovered documents to inputDocuments field
- Include a brief section about the legacy reference
### 7. Prepare for Next Step
- Confirm everything is set up properly
- Let the user know what you've accomplished
- Transition smoothly to the next phase of defining the module concept
### 8. Present MENU OPTIONS
Display: **Proceeding to define your module concept...**
#### EXECUTION RULES:
- This is an initialization step with no user choices (after inputs handled)
- Proceed directly to next step after setup
- Use menu handling logic section below
#### Menu Handling Logic:
- After setup completion, add step-01-init to the end of the stepsCompleted array in module plan frontmatter, then load, read entire file, then execute `{nextStepFile}` to define the module concept
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Module name obtained and validated through collaborative dialogue
- Module plan document created from template with frontmatter initialized
- "step-01-init" added to stepsCompleted array
- Module plan document created at correct location
- User feels welcomed and informed
- Ready to proceed to step 2
- OR existing workflow properly routed to step-01b-continue.md
### ❌ SYSTEM FAILURE:
- Proceeding with step 2 without module plan creation
- Not checking for existing documents properly
- Creating module without user input on name
- Skipping folder creation
- Not routing to step-01b-continue.md when appropriate
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN initialization setup is complete and module plan document is created (OR continuation is properly routed), will you then immediately load, read entire file, then execute `{nextStepFile}` to begin defining the module concept.
@@ -1,170 +0,0 @@
---
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
---
# Step 1b: Continue Module Creation
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and BMAD Systems Specialist
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD architecture and module creation, user brings their module requirements
- ✅ Maintain collaborative, guiding tone throughout
### Step-Specific Rules:
- 🎯 Focus ONLY on handling continuation and resuming workflow
- 🚫 FORBIDDEN to modify existing work without user consent
- 💬 Present status clearly and get user direction
- 📋 Track completion status accurately
## EXECUTION PROTOCOLS:
- 🎯 Load and analyze existing module plan
- 💾 Update frontmatter with continuation status
- 📖 Route to appropriate next step based on progress
- 🚫 FORBIDDEN to skip steps just because they exist
## CONTEXT BOUNDARIES:
- Module plan document exists with previous work
- Focus on understanding what's been done and what remains
- Don't assume completion without verification
- User direction guides next actions
## STEP GOAL:
To resume module creation by presenting current status, understanding what's been accomplished, and determining the next step in the process.
## CONTINUATION HANDLING SEQUENCE:
### 1. Load and Analyze Existing Module Plan
Load module plan from: {modulePlanFile}
Read entire document including frontmatter
Extract current status from frontmatter fields:
- stepsCompleted array
- lastStep (the final item in the stepsCompleted array)
- module_name
- module_code
- date
- inputDocuments
### 2. Present Current Status
"Welcome back! I found your in-progress module creation for **{module_name}**.
**Current Status:**
- **Module Code:** {module_code}
- **Started:** {date}
- **Last Step:** {lastStep}
- **Steps Completed:** {stepsCompleted count}/{total steps}
- **Location:** {bmb_creations_output_folder}/{module_name}
Progress Summary:"
Based on stepsCompleted, show:
- [✅] Step 1: Init - Complete
- [ ] Step 2: Concept - {status}
- [ ] Step 3: Components - {status}
- [ ] Step 4: Structure - {status}
- [ ] Step 5: Configuration - {status}
- [ ] Step 6: Agents - {status}
- [ ] Step 7: Workflows - {status}
- [ ] Step 8: Installer - {status}
- [ ] Step 9: Documentation - {status}
- [ ] Step 10: Roadmap - {status}
- [ ] Step 11: Validation - {status}
### 3. Review What's Been Done
Read content sections of module plan
Summarize what's been accomplished:
"**Completed Work:**
- Module identity defined
- Component planning complete
- [Other completed items based on content]"
### 4. Determine Next Step
Based on stepsCompleted array:
Find highest completed step number
Next step = highest completed + 1
"**Ready to Continue:**
Your next step would be: **Step {nextStep} - [step name]**
What would you like to do?
1. **Continue** from where you left off
2. **Review** what's been done so far
3. **Modify** previous work
4. **Start over** with a new plan"
### 5. Handle User Choice
User your best judgement in how to handle the users choice
### 6. Update Continuation Status
Update modulePlanFile frontmatter:
- Set lastStep: 'continued'
- Add note about continuation date
- Keep stepsCompleted unchanged
## ✅ SUCCESS METRICS:
- User understands current progress
- Next step identified correctly
- User choice handled appropriately
- Module plan updated with continuation status
- Workflow resumed at correct location
## ❌ FAILURE MODES TO AVOID:
- Not accurately reading previous status
- Skipping steps just because they exist
- Not offering review option
- Losing previous work
- Not updating continuation tracking
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Existing work properly loaded and analyzed
- User clearly understands current status
- Continuation options presented clearly
- Next step determined correctly
- Module plan updated with continuation information
### ❌ SYSTEM FAILURE:
- Not reading existing plan completely
- Misrepresenting progress status
- Losing track of what's been done
- Not offering appropriate continuation options
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN user selects 'C' (Continue) and appropriate updates are saved to modulePlanFile, will you then load, read entire file, then execute the determined next step file to resume the module creation workflow.
@@ -1,218 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-03-components.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
moduleStructureGuide: '{project-root}/bmb/workflows/create-agent-legacy/create-module/module-structure.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 2: Define Module Concept and Scope
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Business Analyst
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in module design and BMAD patterns, user brings their domain knowledge
- ✅ Maintain collaborative, educational tone
### Step-Specific Rules:
- 🎯 Focus ONLY on defining the module concept and scope
- 🚫 FORBIDDEN to start designing components in this step
- 💬 Ask questions conversationally to understand vision
- 🚫 FORBIDDEN to proceed without clear module identity
## EXECUTION PROTOCOLS:
- 🎯 Load and study module structure guide for context
- 💾 Document all module identity details in plan
- 📖 Add "step-02-concept" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Module name and location from step 1
- Input documents (brief/brainstorming) if any
- Focus ONLY on concept and scope definition
- Don't assume module details beyond what user provides
## STEP GOAL:
To articulate the module's vision, define its identity, and establish clear boundaries for what it will and won't do.
## MODULE CONCEPT DEFINITION PROCESS:
### 1. Load Context and Briefs
"Let's define your module's concept and identity. This will guide all the decisions we make about agents, workflows, and features."
Load module-plan.md and check inputDocuments field
Read the module brief completely
"I see you have a module brief. Let me review that to understand your vision..."
Use brief content to inform concept development questions
Load and study the module structure guide for context
### 2. Guide Concept Development
Ask conversationally:
"**Understanding Your Vision:**
1. **What problem will this module solve?** - What pain point or need are you addressing?
2. **Who is the primary user?** - Who will benefit most from this module?
3. **What's the main outcome?** - What will users be able to do after using your module?
4. **Why is this important?** - What makes this module valuable or unique?"
### 3. Module Identity Development
Based on their responses, collaboratively develop:
**Module Name:**
- Start with their module code: {module_name}
- Suggest a display name in Title Case
- Get user confirmation or refinement
**Module Purpose:**
- Distill their problem statement into 1-2 clear sentences
- Focus on value and outcomes
- Get user validation
**Target Audience:**
- Identify primary user persona
- Consider skill level (beginner/intermediate/advanced)
- Note any secondary audiences
**Module Scope:**
- What's IN scope (core features)
- What's OUT of scope (explicitly state what it won't do)
- Success criteria (how will we know it works?)
### 4. Module Theme and Category
"**Module Classification:**
Based on your description, this seems to fit in the [Domain-Specific/Creative/Technical/Business/Personal] category.
Does this sound right? Or would you categorize it differently?
**Example Categories:**
- **Domain-Specific**: Legal, Medical, Finance, Education
- **Creative**: RPG/Gaming, Story Writing, Music Production
- **Technical**: DevOps, Testing, Architecture, Security
- **Business**: Project Management, Marketing, Sales
- **Personal**: Journaling, Learning, Productivity"
### 5. Module Type Estimation
"Based on what you've described, I'm thinking this might be a:
- **Simple Module** (1-2 agents, 2-3 workflows) - Focused, single-purpose
- **Standard Module** (3-5 agents, 5-10 workflows) - Comprehensive solution
- **Complex Module** (5+ agents, 10+ workflows) - Full platform/framework
Which feels right for your vision? We'll confirm this after planning components."
### 6. Document Module Concept
Update module-plan.md with concept section:
```markdown
## Module Concept
**Module Name:** {module_display_name}
**Module Code:** {module_name}
**Category:** [category]
**Type:** [estimated type]
**Purpose Statement:**
[1-2 sentence clear purpose]
**Target Audience:**
- Primary: [description]
- Secondary: [if any]
**Scope Definition:**
**In Scope:**
- [core feature 1]
- [core feature 2]
- [core feature 3]
**Out of Scope:**
- [explicitly excluded item 1]
- [explicitly excluded item 2]
**Success Criteria:**
- [measurable outcome 1]
- [measurable outcome 2]
- [user satisfaction indicator]
```
### 7. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore alternative concept approaches
- IF P: Execute {partyModeWorkflow} to get creative input on module identity
- IF C: Save concept to module-plan.md, add step-02-concept to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Module purpose clearly articulated
- Module identity established (name, audience, scope)
- Category and type determined
- Concept documented in module plan
- User feels the concept matches their vision
### ❌ SYSTEM FAILURE:
- Proceeding without clear module purpose
- Not defining scope boundaries
- Skipping user validation of concept
- Not documenting concept details
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and module concept is saved to module-plan.md with stepsCompleted updated to [1, 2], will you then load, read entire file, then execute `{nextStepFile}` to begin component planning.
@@ -1,268 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-04-structure.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
agent_examples_path: '{project-root}/bmb/reference/agents/module-examples'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 3: Plan Module Components
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Systems Designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD component design patterns, user brings their domain requirements
- ✅ Maintain collaborative, design-focused tone
### Step-Specific Rules:
- 🎯 Focus ONLY on planning component architecture
- 🚫 FORBIDDEN to create actual components in this step
- 💬 Present component options with reasoning
- 🚫 FORBIDDEN to finalize component list without user agreement
## EXECUTION PROTOCOLS:
- 🎯 Reference agent examples for patterns
- 💾 Document component plan in detail
- 📖 Add "step-03-components" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Module concept from step 2 is available
- Focus on planning, not implementation
- Consider BMAD patterns and best practices
- Reference examples but don't copy exactly
## STEP GOAL:
To design the component architecture for the module, determining what agents, workflows, and tasks are needed to fulfill the module's purpose.
## COMPONENT PLANNING PROCESS:
### 1. Initialize Component Planning
"Now that we have a clear module concept, let's plan the components that will bring it to life.
Based on your module's purpose and scope, we'll design:
- **Agents** - The AI personas that will help users
- **Workflows** - The step-by-step processes for accomplishing tasks
- **Tasks** - Quick utilities and supporting functions"
### 2. Agent Planning
"**Agent Architecture:**
Think about the different roles or perspectives needed to accomplish your module's goals. Each agent should have a clear, distinct purpose."
Reference agent examples for patterns
Load and browse agent examples: {agent_examples_path}
"**Common Agent Patterns:**
- **Primary Agent** - The main interface/orchestrator
- **Specialist Agents** - Domain-specific experts
- **Utility Agents** - Helper/support functions
**Example by Module Type:**
**Technical Modules (e.g., DevOps, Testing):**
- Implementation Specialist
- Reviewer/Auditor
- Documentation Expert
**Creative Modules (e.g., Story Writing, Game Design):**
- Creative Director
- World Builder
- Content Generator
**Business Modules (e.g., Project Management):**
- Project Coordinator
- Facilitator
- Analyst"
"**For your {module_category} module, I suggest considering:**
[Suggest 2-4 specific agent types based on module concept]
**What resonates with your vision?** Which of these agents would be most valuable, and are there any others you'd like to add?"
### 3. Workflow Planning
"**Workflow Design:**
Workflows are the step-by-step processes that users will follow to accomplish specific tasks. Each workflow should solve a specific problem or achieve a particular outcome."
**Types of Workflows:**
- **Document Workflows** - Generate reports, plans, specifications
- **Action Workflows** - Perform operations, create structures
- **Interactive Workflows** - Guided sessions, coaching, training
**Example Workflow Patterns:**
"For your module's purpose, consider these potential workflows:
1. **[Primary Workflow Name]** - Main workflow for core functionality
2. **[Supporting Workflow 1]** - For specific use case
3. **[Supporting Workflow 2]** - For another use case
Remember: We'll create workflow PLANS first, not full implementations. These plans can be used later with the create-workflow workflow."
### 4. Task Planning (Optional)
"**Task Planning (if needed):**
Tasks are single-operation utilities that don't need full workflows. They're good for:
- Quick actions
- Shared subroutines
- Helper functions
Does your module need any tasks? For example:
- Status checking
- Quick formatting
- Validation utilities"
### 5. Component Integration Planning
"**How Components Work Together:**
Let's think about how your components will interact:
- **Agent Collaboration**: Will agents work together or independently?
- **Workflow Dependencies**: Do workflows need to call each other?
- **Task Usage**: Which workflows will use which tasks?"
### 6. Component Priority and MVP
"**Starting Point (MVP):**
To ensure success, let's identify the minimum viable set:
**Must Have (Phase 1):**
- [List essential agents]
- [List essential workflows]
**Nice to Have (Phase 2):**
- [Additional agents]
- [Additional workflows]
- [Tasks if any]
This approach lets you launch with core functionality and expand later."
### 7. Document Component Plan
Update module-plan.md with component section:
```markdown
## Component Architecture
### Agents (N planned)
1. **[Agent Name]** - [Brief purpose]
- Type: [Primary/Specialist/Utility]
- Role: [Specific role description]
2. **[Agent Name]** - [Brief purpose]
- Type: [Primary/Specialist/Utility]
- Role: [Specific role description]
### Workflows (N planned)
1. **[Workflow Name]** - [Purpose]
- Type: [Document/Action/Interactive]
- Primary user: [Who uses this]
- Key output: [What it produces]
2. **[Workflow Name]** - [Purpose]
- Type: [Document/Action/Interactive]
- Primary user: [Who uses this]
- Key output: [What it produces]
### Tasks (N planned)
1. **[Task Name]** - [Single-purpose function]
- Used by: [Which workflows/agents]
### Component Integration
- Agents collaborate via: [description]
- Workflow dependencies: [description]
- Task usage patterns: [description]
### Development Priority
**Phase 1 (MVP):**
- [List of components to create first]
**Phase 2 (Enhancement):**
- [List of components for later]
```
### 8. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore alternative component architectures
- IF P: Execute {partyModeWorkflow} to get creative input on component design
- IF C: Save component plan to module-plan.md, add step-03-components to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Component architecture planned and documented
- Agent types and purposes clearly defined
- Workflow requirements identified
- Integration patterns established
- Development priority set (MVP vs enhancements)
### ❌ SYSTEM FAILURE:
- Planning components without module purpose context
- Not considering BMAD patterns and examples
- Over-engineering (too many components)
- Under-planning (missing essential components)
- Not establishing development priorities
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and component plan is saved to module-plan.md with stepsCompleted updated to [1, 2, 3], will you then load, read entire file, then execute `{nextStepFile}` to begin creating the module structure.
@@ -1,229 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-05-config.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 4: Create Module Structure
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Systems Organizer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD structure patterns, user brings their component requirements
- ✅ Maintain collaborative, organized tone
### Step-Specific Rules:
- 🎯 Focus ONLY on creating directory structure and determining complexity
- 🚫 FORBIDDEN to create actual component files in this step
- 💬 Explain structure decisions clearly
- 🚫 FORBIDDEN to proceed without confirming structure
## EXECUTION PROTOCOLS:
- 🎯 Use component count to determine module type
- 💾 Create all required directories
- 📖 Add "step-04-structure" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Component plan from step 3 is available
- Standard BMAD module structure to follow
- Focus on structure creation, not content
- Module folder already exists from step 1
## STEP GOAL:
To determine the module's complexity type and create the complete directory structure for the module.
## MODULE STRUCTURE CREATION PROCESS:
### 1. Determine Module Complexity
"Based on your component plan, let's determine your module's complexity level:"
**Count Components:**
- Agents: [count from plan]
- Workflows: [count from plan]
- Tasks: [count from plan]
**Complexity Assessment:**
"**Simple Module Criteria:**
- 1-2 agents, all Simple type
- 1-3 workflows
- No complex integrations
**Standard Module Criteria:**
- 2-4 agents with mixed types
- 3-8 workflows
- Some shared resources
**Complex Module Criteria:**
- 4+ agents or multiple Module-type agents
- 8+ workflows
- Complex interdependencies
- External integrations"
"**Your module has:**
- [agent_count] agents
- [workflow_count] workflows
- [task_count] tasks
**This makes it a: [Simple/Standard/Complex] Module**"
### 2. Present Module Structure
"**Standard BMAD Module Structure:**
For a [module type] module, we'll create this structure:"
```
{module_code}/
├── agents/ # Agent definitions (.md)
│ ├── [agent-name].md
│ └── ...
├── workflows/ # Workflow folders
│ ├── [workflow-name]/
│ │ ├── workflow-plan.md # Descriptive plan
│ │ └── README.md # Workflow documentation
│ └── ...
├── tasks/ # Task files (if any)
│ └── [task-name].md
├── templates/ # Shared templates
│ └── [template-files]
├── data/ # Module data files
│ └── [data-files]
├── module.yaml # Required
├── _module-installer/ # Installation configuration
│ ├── installer.js # Optional
│ └── assets/ # Optional install assets
└── README.md # Module documentation
```
### 3. Create Directory Structure
Create all directories in {bmb_creations_output_folder}/{module_name}/:
1. **agents/** - For agent definition files
2. **workflows/** - For workflow folders
3. **tasks/** - For task files (if tasks planned)
4. **templates/** - For shared templates
5. **data/** - For module data
6. **_module-installer/** - For installation configuration
### 4. Create Placeholder README
Create initial README.md with basic structure:
````markdown
# {module_display_name}
{module_purpose}
## Installation
```bash
bmad install {module_code}
```
````
## Components
_Module documentation will be completed in Step 9_
## Quick Start
_Getting started guide will be added in Step 9_
---
_This module is currently under construction_
````
### 5. Document Structure Creation
Update module-plan.md with structure section:
```markdown
## Module Structure
**Module Type:** [Simple/Standard/Complex]
**Location:** {bmb_creations_output_folder}/{module_name}
**Directory Structure Created:**
- ✅ agents/
- ✅ workflows/
- ✅ tasks/
- ✅ templates/
- ✅ data/
- ✅ _module-installer/
- ✅ README.md (placeholder)
**Rationale for Type:**
[Explain why it's Simple/Standard/Complex based on component counts]
````
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore alternative structure approaches
- IF P: Execute {partyModeWorkflow} to get creative input on organization
- IF C: Save structure info to module-plan.md, add step-04-structure to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Module complexity correctly determined
- All required directories created
- Structure follows BMAD standards
- Placeholder README created
- Structure documented in plan
### ❌ SYSTEM FAILURE:
- Not creating all required directories
- Incorrectly categorizing module complexity
- Not following BMAD structure patterns
- Creating component files prematurely
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and structure is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4], will you then load, read entire file, then execute `{nextStepFile}` to begin configuration planning.
@@ -1,234 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-06-agents.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 5: Plan Module Configuration
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Configuration Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD installation patterns, user brings their module requirements
- ✅ Maintain collaborative, planning-focused tone
### Step-Specific Rules:
- 🎯 Focus ONLY on planning configuration fields
- 🚫 FORBIDDEN to create installer files in this step
- 💬 Present configuration options clearly
- 🚫 FORBIDDEN to finalize without user input
## EXECUTION PROTOCOLS:
- 🎯 Consider what users might want to configure
- 💾 Document all configuration field plans
- 📖 Add "step-05-config" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Module concept and components from previous steps
- Standard BMAD installer configuration patterns
- Focus on planning, not implementation
- Consider user customization needs
## STEP GOAL:
To determine what configuration settings the module needs and plan how they'll be implemented in the installer.
## CONFIGURATION PLANNING PROCESS:
### 1. Initialize Configuration Planning
"Now let's plan the configuration for your module's installer. This determines what users can customize when they install your module."
**Configuration allows users to:**
- Set up file locations
- Choose features or behavior
- Provide API keys or credentials
- Adjust output formats
- Configure integrations
### 2. Assess Configuration Needs
"**Configuration Assessment:**
Does your {module_display_name} module need any user-configurable settings during installation?"
**Common Configuration Categories:**
**1. Output/Data Paths**
- Where should outputs be saved?
- What's the default data directory?
- Any special folder structures needed?
**2. Feature Toggles**
- Enable/disable specific features
- Choose between behavior modes
- Set verbosity levels
**3. Integration Settings**
- API keys (for external services)
- Service endpoints
- Authentication credentials
**4. User Preferences**
- Default language
- Time zone
- Skill level (beginner/advanced)
- Detail level (minimal/standard/verbose)"
### 3. Plan Configuration Fields
"**For each configuration need, let's define:**
1. **Field Name** (snake_case, e.g., 'output_path')
2. **Type** - INTERACTIVE (asks user) or STATIC (hardcoded)
3. **Prompt** (what to ask user, if interactive)
4. **Default Value** (sensible default)
5. **Input Type** - text, single-select, multi-select
6. **Result Template** - how to store the value"
**Examples:**
"**INTERACTIVE Text Input:**
```yaml
output_path:
prompt: 'Where should {module_name} save outputs?'
default: 'output/{module_name}'
result: '{project-root}/{value}'
```
**INTERACTIVE Single-Select:**
```yaml
detail_level:
prompt: 'How detailed should outputs be?'
default: 'standard'
result: '{value}'
single-select:
- value: 'minimal'
label: 'Minimal - Brief summaries only'
- value: 'standard'
label: 'Standard - Balanced detail'
- value: 'detailed'
label: 'Detailed - Comprehensive information'
```
**STATIC Value:**
````yaml
module_version:
result: "1.0.0"
```"
### 4. Design Configuration for Your Module
"**Based on your module's purpose, consider these potential configurations:"
[Suggest relevant configurations based on module type and purpose]
"**Which of these apply to your module?**
- [Present options relevant to the specific module]
**Any additional configurations needed?**"
### 5. Document Configuration Plan
Update module-plan.md with configuration section:
```markdown
## Configuration Planning
### Required Configuration Fields
1. **[field_name]**
- Type: [INTERACTIVE/STATIC]
- Purpose: [what it controls]
- Default: [default value]
- Input Type: [text/single-select/multi-select]
- Prompt: [user prompt if interactive]
2. **[field_name]**
- Type: [INTERACTIVE/STATIC]
- Purpose: [what it controls]
- Default: [default value]
- Input Type: [text/single-select/multi-select]
- Prompt: [user prompt if interactive]
### Installation Questions Flow
1. [First question]
2. [Second question]
3. [Additional questions...]
### Result Configuration Structure
The module.yaml will generate:
- Module configuration at: _bmad/{module_code}/config.yaml
- User settings stored as: [describe structure]
````
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore additional configuration options
- IF P: Execute {partyModeWorkflow} to get input on user experience
- IF C: Save configuration plan to module-plan.md, add step-05-config to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All necessary configuration fields identified
- Field types and prompts clearly defined
- User interaction flow planned
- Configuration structure documented
- Ready for installer implementation
### ❌ SYSTEM FAILURE:
- Skipping configuration planning for modules that need it
- Over-configuring (too many options)
- Not considering user experience
- Not documenting configuration plans
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and configuration plan is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5], will you then load, read entire file, then execute `{nextStepFile}` to begin agent creation.
@@ -1,297 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-07-workflows.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
agentTemplate: '{installed_path}/templates/agent.template.md'
agent_examples_path: '{project-root}/bmb/reference/agents/module-examples'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 6: Create Module Agents
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Agent Designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD agent patterns, user brings their domain requirements
- ✅ Maintain collaborative, creative tone
### Step-Specific Rules:
- 🎯 Focus on creating proper YAML agent files following the template
- 🚫 FORBIDDEN to use create-agent workflow (it's problematic)
- 💬 Create placeholder workflow folders with README.md for each agent
- 🚫 FORBIDDEN to create full workflows in this step
## EXECUTION PROTOCOLS:
- 🎯 Follow agent.template.md exactly for structure
- 💾 Save agents as .yaml files to module's agents folder
- 📖 Create workflow folders with README.md plans
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Component plan from step 3 defines which agents to create
- Agent template provides the required YAML structure
- Module structure already created
- Focus on agent creation and workflow placeholders
## STEP GOAL:
To create the primary agent(s) for the module using the proper agent template and create placeholder workflow folders for each agent.
## AGENT CREATION PROCESS:
### 1. Review Agent Plan
"Let's create the agents for your {module_display_name} module.
From your component plan, you have:
- [agent_count] agents planned
- [list of agent types from plan]
I'll create each agent following the proper BMAD template and set up placeholder workflow folders for them."
### 2. Load Agent Template
Load and study the agent template from {agentTemplate}
Reference agent examples from {agent_examples_path} for patterns
### 3. Create Each Agent
For each agent in the component plan:
#### 3.1 Determine Agent Characteristics
"**Agent: [Agent Name]**
Let's design this agent by understanding what it needs:
**Memory & Learning:**
1. Does this agent need to remember things across sessions? (conversations, preferences, patterns)
- If yes: We'll add sidecar folder structure for memory
- If no: No persistent memory needed
**Interaction Types:** 2. What does this agent DO?
- Conversational interactions? → Use embedded prompts
- Quick single actions? → Use inline actions
- Complex multi-step processes? → Consider workflows
- Document generation? → Likely need workflows
**Multiple Agent Usage:** 3. Will other agents in this module need the same workflows?
- If yes: Definitely create separate workflow files
- If no: Could embed in agent file
**Based on this, what combination does [Agent Name] need?**
- Memory/Persistence: [Yes/No]
- Embedded prompts: [List main interactions]
- Workflows needed: [Which processes need separate files?]"
#### 3.2 Present Agent Design
"**Agent Design: [Agent Name]**
**Core Identity:**
- Name: [Suggested name]
- Title: [Brief description]
- Icon: [Appropriate emoji]
**Persona:**
- Role: [What the agent does]
- Identity: [Personality/background]
- Communication Style: [How they communicate]
- Principles: [3-5 core principles]
**Structure:**
- Memory needed: [Yes/No - sidecar folder]
- Embedded prompts: [List main interaction prompts]
- Workflow processes: [Which need separate files]
**Menu Items Planned:**
- [List with trigger codes and types]
**Quick actions vs Workflows:**
- Quick prompts: [single-step interactions]
- Workflows: [multi-step, shared processes]
Does this design match what you envisioned? What should we adjust?"
#### 3.3 Create Agent File and Structure
After user confirmation:
Create hybrid agent file with only needed sections:
```yaml
agent:
metadata:
name: '[Agent Name]'
title: '[Agent Title]'
icon: '[Icon]'
module: '{module_code}'
persona:
role: '[Agent Role]'
identity: |
[Multi-line identity description]
communication_style: |
[Multi-line communication style]
principles:
- '[Principle 1]'
- '[Principle 2]'
- '[Principle 3]'
# Only include if agent needs memory/persistence
critical_actions:
- 'Load COMPLETE file ./[agent-name]-sidecar/memories.md and integrate all past interactions'
- 'ONLY read/write files in ./[agent-name]-sidecar/ - this is our private workspace'
# Only include if agent has embedded prompts
prompts:
- id: '[prompt-name]'
content: |
<instructions>
[How to use this prompt]
</instructions>
[Detailed prompt content]
menu:
# Always include
- multi: '[CH] Chat with agent or [SPM] Start Party Mode'
triggers:
- party-mode:
input: SPM
route: '{project-root}/_bmad/core/workflows/edit-agent/workflow.md'
type: exec
- expert-chat:
input: CH
action: agent responds as expert
type: action
# Group related functions
- multi: '[PF] Primary Function [QF] Quick Task'
triggers:
- primary-function:
input: PF
action: '#[prompt-id]'
type: action
- quick-task:
input: QF
route: '#[prompt-id]'
type: exec
# Workflow only for complex processes
- trigger: 'complex-process'
route: '{project-root}/_bmad/{custom_module}/workflows/[workflow]/workflow.md'
description: 'Complex process [icon]'
# Quick inline actions
- trigger: 'save-item'
action: 'Save to ./[agent-name]-sidecar/file.md'
description: 'Save item 💾'
```
#### 3.4 Create Supporting Structure
**If agent needs memory:**
1. Create folder: {bmb_creations_output_folder}/{module_name}/agents/[agent-name]-sidecar/
2. Create files:
- memories.md (empty, for persistent memory)
- instructions.md (empty, for agent protocols)
- insights.md (empty, for breakthrough moments)
- sessions/ (subfolder for session records)
- patterns.md (empty, for tracking patterns)
**If agent has workflows:**
For each workflow that needs separate file:
1. Create folder: {bmb_creations_output_folder}/{module_name}/workflows/[workflow-name]/
2. Create README.md with workflow plan
### 4. Repeat for All Agents
Go through each agent from the component plan, presenting drafts and creating files with user confirmation.
### 5. Document Agent Creation
Update module-plan.md with agents section:
```markdown
## Agents Created
1. **[Agent Name]** - [Agent Title]
- File: [agent-filename].yaml
- Features: [Memory/Sidecar, Embedded prompts, Workflows]
- Structure:
- Sidecar: [Yes/No]
- Prompts: [number embedded]
- Workflows: [list of workflow folders]
- Status: Created with [combination of features]
```
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to refine agent designs
- IF P: Execute {partyModeWorkflow} to get creative input on agent personas
- IF C: Save agent creation status to module-plan.md, add step-06-agents to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All planned agents created with proper YAML structure
- Each agent follows agent.template.md format exactly
- Workflow placeholder folders created with README.md plans
- Agent menu items properly reference workflow paths
- Users confirmed each agent draft before creation
### ❌ SYSTEM FAILURE:
- Using create-agent workflow instead of template
- Creating XML agents instead of YAML
- Not creating workflow placeholder folders
- Skipping user confirmation on agent drafts
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and all agents are created with placeholder workflows and stepsCompleted updated, will you then load, read entire file, then execute `{nextStepFile}` to begin workflow plan review.
@@ -1,229 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-08-installer.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
workflowPlanTemplate: '{installed_path}/templates/workflow-plan-template.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 7: Review Workflow Plans
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Workflow Designer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD workflow patterns, user brings their workflow requirements
- ✅ Maintain collaborative, review-focused tone
### Step-Specific Rules:
- 🎯 Focus on reviewing existing workflow README files from Step 6
- 🚫 FORBIDDEN to use create-workflow workflow in this step
- 💬 Review and refine workflow plans, not create new ones
- 🚫 FORBIDDEN to create actual workflow steps
## EXECUTION PROTOCOLS:
- 🎯 Review workflow README files created in Step 6
- 💾 Update README files based on user feedback
- 📖 Add "step-07-workflows" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Workflow README files were created in Step 6 for each agent
- These README files contain workflow plans for later implementation
- Module structure already created with workflow folders
- Focus on reviewing and refining, not creating from scratch
## STEP GOAL:
To review and refine the workflow README files created in Step 6, ensuring they have clear plans for later implementation with the create-workflow workflow.
## WORKFLOW REVIEW PROCESS:
### 1. List Workflow Folders Created
"Let's review the workflow plans created in Step 6 for your {module_display_name} module.
I've already created workflow folders and README.md files for each agent's workflows:
**Workflow folders found:**
- [List all workflow folders in {bmb_creations_output_folder}/{module_name}/workflows/]
**Each workflow folder contains a README.md with:**
- Purpose and description
- Trigger code from agent menu
- Key steps outline
- Expected outputs
- Notes for implementation"
### 2. Review Each Workflow Plan
For each workflow README file:
#### 2.1 Load and Present
"**Reviewing Workflow: [Workflow Name]**
Reading the README.md from: [workflow-folder]/README.md
**Current Plan:**
[Purpose]
[Trigger]
[Key Steps]
[Expected Output]
[Notes]
How does this plan look? Should we:
- Keep it as is
- Modify the purpose
- Adjust the steps
- Change the expected output"
#### 2.2 Update Based on Feedback
If user wants changes:
- Update the README.md file
- Keep the same basic structure
- Ensure clarity for future implementation
#### 2.3 Check for Missing Information
Ensure each README has:
```markdown
# [Workflow Name]
## Purpose
[Clear, concise description of what this workflow accomplishes]
## Trigger
[Trigger code from agent menu, e.g., "WF" or specific code]
## Key Steps
1. [Step 1 - What happens first]
2. [Step 2 - What happens next]
3. [Step 3 - Continue as needed]
## Expected Output
[What the workflow produces - document, action, result]
## Notes
This workflow will be implemented using the create-workflow workflow.
(Optional: Any special considerations or requirements)
```
### 3. Link Workflows to Agents
"**Workflow-Agent Mapping:**
Let's verify each workflow is properly linked to its agent:
[For each workflow]:
- **Workflow:** [Workflow Name]
- **Agent:** [Agent Name]
- **Trigger Code:** [WF code]
- **Menu Item:** [Menu description in agent]
Are all these mappings correct in the agent files?"
### 4. Document Implementation Plan
Update module-plan.md with workflow section:
```markdown
## Workflow Plans Reviewed
### For Agent [Agent Name]:
1. **[Workflow Name]**
- Location: workflows/[workflow-name]/
- Status: Plan reviewed and ready for implementation
- Trigger: [WF code]
- Implementation: Use create-workflow workflow
2. **[Workflow Name]**
- Location: workflows/[workflow-name]/
- Status: Plan reviewed and ready for implementation
- Trigger: [WF code]
- Implementation: Use create-workflow workflow
```
### 5. Next Steps Guidance
"**Ready for Implementation:**
All workflow plans are now reviewed and ready. To implement these workflows later:
1. Use the `/bmad:bmb:workflows:create-workflow` command
2. Select each workflow folder
3. Follow the create-workflow workflow
4. It will create the full workflow.md and step files
The README.md in each folder serves as your blueprint for implementation."
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to refine workflow designs
- IF P: Execute {partyModeWorkflow} to get creative input on workflow processes
- IF C: Save workflow plan status to module-plan.md, add step-07-workflows to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All workflow README files reviewed with user
- Each workflow plan has clear purpose and steps
- Workflow-agent mappings verified
- README files updated based on feedback
- Clear implementation guidance provided
### ❌ SYSTEM FAILURE:
- Skipping review of workflow README files
- Not updating plans based on user feedback
- Missing critical information in README files
- Not verifying workflow-agent mappings
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and all workflow plans are reviewed and documented and stepsCompleted updated, will you then load, read entire file, then execute `{nextStepFile}` to begin installer setup.
@@ -1,187 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-09-documentation.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
installerTemplate: '{installed_path}/templates/installer.template.js'
installConfigTemplate: '{installed_path}/templates/install-config.template.yaml'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 8: Setup Module Installer
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Installation Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD installation patterns, user brings their module requirements
- ✅ Maintain collaborative, technical tone
### Step-Specific Rules:
- 🎯 Focus on creating installer configuration files
- 🚫 FORBIDDEN to run actual installation
- 💬 Follow BMAD installer standards exactly
- 🚫 FORBIDDEN to deviate from configuration template
## EXECUTION PROTOCOLS:
- 🎯 Use configuration plan from step 5
- 💾 Create module.yaml with all fields
- 📖 Add "step-08-installer" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- Configuration plan from step 5 defines installer fields
- Standard BMAD installer template to follow
- Module structure already created
- Focus on installer setup, not module content
## STEP GOAL:
To create the module installer configuration (module.yaml) that defines how users will install and configure the module.
## INSTALLER SETUP PROCESS:
### 1. Review Configuration Plan
"Now let's set up the installer for your {module_display_name} module.
The installer will:
- Define how users install your module
- Collect configuration settings
- Set up the module structure in user projects
- Generate the module's config.yaml file
From step 5, we planned these configuration fields:
- [List planned configuration fields]"
### 2. Create Installer Directory
Ensure _module-installer directory exists
Directory: {bmb_creations_output_folder}/{module_name}/_module-installer/
### 3. Create module.yaml
"I'll create the module.yaml file based on your configuration plan. This is the core installer configuration file."
Create file: {bmb_creations_output_folder}/{module_name}/module.yaml from template {installConfigTemplate}
### 4. Handle Custom Installation Logic
"**Custom Installation Logic:**
Does your module need any special setup during installation? For example:
- Creating database tables
- Setting up API connections
- Downloading external assets
- Running initialization scripts"
<ask>Does your module need custom installation logic? [yes/no]</ask>
"I'll create an installer.js file for custom logic."
Create file: {bmb_creations_output_folder}/{module_name}/_module-installer/installer.js from {installerTemplate}
Update installer.js with module-specific logic
### 5. Create Assets Directory (if needed)
"**Installer Assets:**
If your module needs to copy files during installation (templates, examples, documentation), we can add them to the assets directory."
Create directory: _module-installer/assets/
Add note about what assets to include
### 6. Document Installer Setup
Update module-plan.md with installer section:
```markdown
## Installer Configuration
### Install Configuration
- File: module.yaml
- Module code: {module_name}
- Default selected: false
- Configuration fields: [count]
### Custom Logic
- installer.js: [Created/Not needed]
- Custom setup: [description if yes]
### Installation Process
1. User runs: `bmad install {module_name}`
2. Installer asks: [list of questions]
3. Creates: _bmad/{module_name}/
4. Generates: config.yaml with user settings
### Validation
- ✅ YAML syntax valid
- ✅ All fields defined
- ✅ Paths use proper templates
- ✅ Custom logic ready (if needed)
```
### 7. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to review installer configuration
- IF P: Execute {partyModeWorkflow} to get input on user experience
- IF C: Save installer info to module-plan.md, add step-08-installer to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- module.yaml created with all planned fields
- YAML syntax valid
- Custom installation logic prepared (if needed)
- Installer follows BMAD standards
- Configuration properly templated
### ❌ SYSTEM FAILURE:
- Not creating module.yaml
- Invalid YAML syntax
- Missing required fields
- Not using proper path templates
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and installer info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8], will you then load, read entire file, then execute `{nextStepFile}` to begin documentation creation.
@@ -1,310 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-10-roadmap.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
moduleReadmeFile: '{bmb_creations_output_folder}/{module_name}/README.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 9: Create Module Documentation
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Technical Writer
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in documentation best practices, user brings their module knowledge
- ✅ Maintain collaborative, clear tone
### Step-Specific Rules:
- 🎯 Focus on creating comprehensive README documentation
- 🚫 FORBIDDEN to create docs in other locations
- 💬 Generate content based on module plan
- 🚫 FORBIDDEN to skip standard sections
## EXECUTION PROTOCOLS:
- 🎯 Use all gathered module information
- 💾 Update the placeholder README.md file
- 📖 Add "step-09-documentation" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- All module information from previous steps
- Module structure and components already created
- Focus on README.md, not other documentation
- Generate content dynamically from plan
## STEP GOAL:
To create comprehensive README.md documentation for the module that helps users understand, install, and use the module.
## DOCUMENTATION CREATION PROCESS:
### 1. Initialize Documentation
"Let's create the README.md for your {module_display_name} module.
Good documentation is crucial for module adoption. Your README will be the first thing users see when discovering your module."
### 2. Generate README Content
Load module-plan.md to gather all module information
Update {moduleReadmeFile} with comprehensive content:
````markdown
# {module_display_name}
{module_purpose}
## Overview
This module provides:
[Generate list based on module components and features]
## Installation
Install the module using BMAD:
```bash
bmad install {module_name}
```
````
## Components
### Agents ({agent_count})
[List created agents with brief descriptions]
### Workflows ({workflow_count})
[List planned workflows with purposes]
### Tasks ({task_count})
[List tasks if any]
## Quick Start
1. **Load the primary agent:**
```
agent {primary_agent_name}
```
2. **View available commands:**
```
*help
```
3. **Run the main workflow:**
```
workflow {primary_workflow_name}
```
## Module Structure
```
{module_name}/
├── agents/ # Agent definitions
│ ├── [agent-1].md
│ └── [agent-2].md
├── workflows/ # Workflow folders
│ ├── [workflow-1]/
│ │ ├── workflow-plan.md
│ │ └── README.md
│ └── [workflow-2]/
│ └── ...
├── tasks/ # Task files
├── templates/ # Shared templates
├── data/ # Module data
├── _module-installer/ # Installation optional js file with custom install routine
├── module.yaml # yaml config and install questions
└── README.md # This file
```
## Configuration
The module can be configured in `_bmad/{module_name}/config.yaml`
**Key Settings:**
[List configuration fields from installer]
[Example:]
- **output_path**: Where outputs are saved
- **detail_level**: Controls output verbosity
- **feature_x**: Enable/disable specific features
## Examples
### Example 1: [Primary Use Case]
[Step-by-step example of using the module for its main purpose]
1. Start the agent
2. Provide input
3. Review output
### Example 2: [Secondary Use Case]
[Additional example if applicable]
## Development Status
This module is currently:
- [x] Structure created
- [x] Installer configured
- [ ] Agents implemented
- [ ] Workflows implemented
- [ ] Full testing complete
**Note:** Some workflows are planned but not yet implemented. See individual workflow folders for status.
## Contributing
To extend this module:
1. Add new agents using `create-agent` workflow
2. Add new workflows using `create-workflow` workflow
3. Update the installer configuration if needed
4. Test thoroughly
## Requirements
- BMAD Method version 6.0.0 or higher
- [Any specific dependencies]
## Author
Created by {user_name} on [creation date]
## License
[Add license information if applicable]
---
## Module Details
**Module Code:** {module_name}
**Category:** {module_category}
**Type:** {module_type}
**Version:** 1.0.0
**Last Updated:** [current date]
````
### 3. Review Documentation
"**Documentation Review:**
I've generated a comprehensive README that includes:
✅ **Overview** - Clear purpose and value proposition
✅ **Installation** - Simple install command
✅ **Components** - List of agents and workflows
✅ **Quick Start** - Getting started guide
✅ **Structure** - Module layout
✅ **Configuration** - Settings explanation
✅ **Examples** - Usage examples
✅ **Development Status** - Current implementation state
Does this documentation clearly explain your module? Is there anything you'd like to add or modify?"
### 4. Handle Documentation Updates
Update based on user feedback
"Common additions:
- API documentation
- Troubleshooting section
- FAQ
- Screenshots or diagrams
- Video tutorials
- Changelog"
### 5. Document Documentation Creation
Update module-plan.md with documentation section:
```markdown
## Documentation
### README.md Created
- Location: {bmb_creations_output_folder}/{module_name}/README.md
- Sections: [list of sections included]
- Status: Complete
### Content Highlights
- Clear installation instructions
- Component overview
- Quick start guide
- Configuration details
- Usage examples
- Development status
### Updates Made
- [List any customizations or additions]
````
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to improve documentation clarity
- IF P: Execute {partyModeWorkflow} to get input on user experience
- IF C: Save documentation info to module-plan.md, add step-09-documentation to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- README.md fully populated with all sections
- Content accurately reflects module structure
- Installation instructions clear and correct
- Examples provide helpful guidance
- Development status honestly represented
### ❌ SYSTEM FAILURE:
- Leaving placeholder content in README
- Not updating with actual module details
- Missing critical sections (installation, usage)
- Misrepresenting implementation status
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and documentation info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8, 9], will you then load, read entire file, then execute `{nextStepFile}` to begin roadmap generation.
@@ -1,338 +0,0 @@
---
installed_path: '{project-root}/_bmad/bmb/workflows/create-module'
nextStepFile: '{installed_path}/steps/step-11-validate.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
moduleTodoFile: '{bmb_creations_output_folder}/{module_name}/TODO.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 10: Generate Development Roadmap
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Project Planner
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in development planning, user brings their module vision
- ✅ Maintain collaborative, forward-looking tone
### Step-Specific Rules:
- 🎯 Focus on creating actionable roadmap and TODO
- 🚫 FORBIDDEN to create actual components
- 💬 Prioritize tasks for successful launch
- 🚫 FORBIDDEN to set time estimates
## EXECUTION PROTOCOLS:
- 🎯 Use component status to determine next steps
- 💾 Create clear TODO.md with actionable items
- 📖 Add "step-10-roadmap" to stepsCompleted array` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C'
## CONTEXT BOUNDARIES:
- All module information from previous steps
- Current implementation status
- Focus on planning, not implementation
- Avoid time-based estimates
## STEP GOAL:
To create a development roadmap and TODO list that guides the next steps for completing the module.
## ROADMAP GENERATION PROCESS:
### 1. Review Current Status
"Let's create a development roadmap for your {module_display_name} module.
**Current Status Summary:**
- ✅ Module structure created
- ✅ Installer configured
- [Agent Status]
- [Workflow Status]
- [Documentation Status]
This roadmap will help you prioritize what to work on next."
### 2. Create Development Phases
"**Development Phases:**
I'll organize the remaining work into logical phases to ensure a successful module launch."
### 3. Generate TODO.md
Create file: {bmb_creations_output_folder}/{module_name}/TODO.md
````markdown
# {module_display_name} Development Roadmap
## Phase 1: Core Components (MVP)
### Agents
- [ ] Implement [Agent 1 Name]
- Use: `workflow create-agent`
- Reference: module-plan.md for requirements
- Priority: High
- [ ] Implement [Agent 2 Name]
- Use: `workflow create-agent`
- Reference: module-plan.md for requirements
- Priority: High
### Workflows
- [ ] Implement [Workflow 1 Name]
- Use: `workflow create-workflow`
- Input: workflows/[workflow-1]/workflow-plan.md
- Priority: High
- [ ] Implement [Workflow 2 Name]
- Use: `workflow create-workflow`
- Input: workflows/[workflow-2]/workflow-plan.md
- Priority: Medium
### Integration
- [ ] Test agent-workflow integration
- [ ] Update agent menus (remove TODO flags)
- [ ] Validate configuration fields work correctly
## Phase 2: Enhanced Features
### Additional Components
- [ ] [Additional Agent 1]
- Priority: Medium
- [ ] [Additional Workflow 1]
- Priority: Low
### Improvements
- [ ] Add error handling
- [ ] Implement validation
- [ ] Optimize performance
- [ ] Add logging
## Phase 3: Polish and Launch
### Testing
- [ ] Unit test all agents
- [ ] Integration test workflows
- [ ] Test installer in clean project
- [ ] Test with sample data
### Documentation
- [ ] Add detailed API docs
- [ ] Create video tutorials
- [ ] Write troubleshooting guide
- [ ] Add FAQ section
### Release
- [ ] Version bump to 1.0.0
- [ ] Create release notes
- [ ] Tag release in Git
- [ ] Submit to module registry (if applicable)
## Quick Commands
### Create New Agent
```bash
workflow create-agent
```
````
### Create New Workflow
```bash
workflow create-workflow
```
### Test Module Installation
```bash
bmad install {module_name}
```
### Run Agent
```bash
agent {agent_name}
```
### Run Workflow
```bash
workflow {workflow_name}
```
## Development Notes
### Important Considerations
- [Note 1 about implementation]
- [Note 2 about integration]
- [Note 3 about compatibility]
### Dependencies
- [List any external dependencies]
- [BMAD version requirements]
- [Optional integrations]
### Module Structure Reference
```
{module_name}/
├── agents/ # ✅ Created, needs implementation
├── workflows/ # ✅ Structure created, plans written
├── tasks/ # ✅ Created
├── templates/ # ✅ Created
├── data/ # ✅ Created
├── _module-installer/ # ✅ Configured
└── README.md # ✅ Complete
└── module.yaml # ✅ Complete
```
## Completion Criteria
The module is complete when:
- [ ] All Phase 1 items are done
- [ ] Installation works smoothly
- [ ] Documentation covers all features
- [ ] Sample usage produces expected results
---
Created: [current date]
Last Updated: [current date]
````
### 4. Prioritize Immediate Next Steps
"**Immediate Next Steps (This Week):**
Based on your module's needs, I recommend starting with:
1. **[Most important agent]** - Core functionality
2. **[Most important workflow]** - Primary user journey
3. **[Integration task]** - Ensure components work together
**Which of these would you like to tackle first?**"
### 5. Provide Development Guidance
"**Development Tips:**
1. **Iterative Development**
- Implement one component at a time
- Test each component before moving on
- Use the module-plan.md as your guide
2. **Testing Strategy**
- Test in a clean project
- Verify installation works
- Check all menu options function
3. **Documentation Updates**
- Update README.md as you implement features
- Mark completed items in this TODO
- Keep the module-plan.md in sync
4. **Getting Help**
- Use BMAD documentation for patterns
- Reference example modules
- Ask for help when stuck"
### 6. Document Roadmap Creation
Update module-plan.md with roadmap section:
```markdown
## Development Roadmap
### TODO.md Created
- Location: {bmb_creations_output_folder}/{module_name}/TODO.md
- Phases defined: 3
- Immediate tasks prioritized
### Next Steps Priority Order
1. [Priority 1]
2. [Priority 2]
3. [Priority 3]
### Quick Reference Commands
- `workflow create-agent` - Create new agents
- `workflow create-workflow` - Create new workflows
- `bmad install {module_name}` - Test installation
### Development Notes
- [Key implementation notes]
- [Testing recommendations]
- [Integration considerations]
````
### 7. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask} to explore development approaches
- IF P: Execute {partyModeWorkflow} to get creative input on implementation
- IF C: Save roadmap info to module-plan.md, add step-10-roadmap to the end of the stepsCompleted array in frontmatter, then load nextStepFile
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond then end with display again of the menu options
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- TODO.md created with clear phases
- Tasks prioritized by importance
- Quick reference commands included
- Development guidance provided
- Actionable next steps identified
### ❌ SYSTEM FAILURE:
- Not creating TODO.md file
- Including time estimates
- Not prioritizing tasks effectively
- Missing essential development commands
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and roadmap info is saved to module-plan.md with stepsCompleted updated to [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], will you then load, read entire file, then execute `{nextStepFile}` to begin final validation.
@@ -1,336 +0,0 @@
---
workflowFile: '{installed_path}/workflow.md'
modulePlanFile: '{bmb_creations_output_folder}/{module_name}/module-plan-{module_name}.md'
validationChecklist: '{installed_path}/validation.md'
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# Step 11: Validate and Finalize Module
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a Module Architect and Quality Assurance Specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring expertise in BMAD validation patterns, user brings their module knowledge
- ✅ Maintain collaborative, thorough tone
### Step-Specific Rules:
- 🎯 Focus on validation and quality checks
- 🚫 FORBIDDEN to modify core structure at this stage
- 💬 Present findings clearly with recommendations
- 🚫 FORBIDDEN to skip validation steps
## EXECUTION PROTOCOLS:
- 🎯 Run validation checklist systematically
- 💾 Document validation results
- 📖 Append "step-11-validate" to stepsCompleted array` before completing
- 🚫 FORBIDDEN to mark as complete without validation
## CONTEXT BOUNDARIES:
- Module fully created with all components
- Focus on validation, not new creation
- Use validation checklist for systematic review
- Ensure BMAD compliance
## STEP GOAL:
To validate the completed module structure, ensure all components are properly configured, and provide next steps for testing and deployment.
## VALIDATION PROCESS:
### 1. Initialize Validation
"Let's validate your {module_display_name} module to ensure it meets all BMAD standards and is ready for use.
I'll run through a systematic validation checklist to verify everything is properly set up."
### 2. Structure Validation
"**1. Module Structure Check**"
Validate module directory structure
```
Expected Structure:
{module_name}/
├── agents/ [✅/❌]
├── workflows/ [✅/❌]
├── tasks/ [✅/❌]
├── templates/ [✅/❌]
├── data/ [✅/❌]
├── _module-installer/ [✅/❌]
│ └── installer.js [✅/N/A]
├── module.yaml [✅/❌]
└── README.md [✅/❌]
```
**Results:**
- [List validation results for each item]
### 3. Configuration Validation
"**2. Configuration Files Check**"
**Install Configuration:**
Validate module.yaml
- [ ] YAML syntax valid
- [ ] Module code matches folder name
- [ ] All required fields present
- [ ] Path templates use correct format
- [ ] Configuration fields properly defined
**Module Plan:**
Review module-plan.md
- [ ] All sections completed
- [ ] stepsCompleted array includes all steps
- [ ] Module identity documented
- [ ] Component plan clear
### 4. Component Validation
"**3. Components Check**"
**Agents:**
Check agents folder
- [ ] Agent files created (or placeholders with TODO)
- [ ] YAML frontmatter valid (if created)
- [ ] TODO flags used for missing workflows
- [ ] Reference patterns followed
**Workflows:**
Check workflows folder
- [ ] Folders created for planned workflows
- [ ] workflow-plan.md files created (or placeholders)
- [ ] README.md in each workflow folder
- [ ] Plans include all required sections
### 5. Documentation Validation
"**4. Documentation Check**"
**README.md:**
Review README.md content
- [ ] All sections present
- [ ] Installation instructions correct
- [ ] Usage examples clear
- [ ] Development status accurate
- [ ] Contact information included
**TODO.md:**
Review TODO.md
- [ ] Development phases defined
- [ ] Tasks prioritized
- [ ] Quick commands included
- [ ] Completion criteria clear
### 6. Integration Validation
"**5. Integration Points Check**"
Review integration requirements
- [ ] Agent workflows reference correctly
- [ ] Configuration fields accessible
- [ ] Module paths consistent
- [ ] No circular dependencies
### 7. Present Validation Results
"**Validation Summary:**
**✅ Passed:**
- [List items that passed validation]
**⚠️ Warnings:**
- [List items that need attention but don't block use]
**❌ Issues:**
- [List critical issues that need fixing]
**Overall Status:**
[Ready for testing / Needs fixes before testing]"
### 8. Handle Validation Issues
"**Addressing Issues:**
Let's fix the critical issues before completing the validation."
For each issue:
1. **Explain the issue** clearly
2. **Show how to fix** it
3. **Make the fix** if user approves
4. **Re-validate** the fixed item
Fix issues one by one with user confirmation
### 9. Final Module Summary
"**Module Creation Complete!**
**Module Summary:**
- **Name:** {module_display_name}
- **Code:** {module_name}
- **Location:** {bmb_creations_output_folder}/{module_name}
- **Type:** {module_type}
- **Status:** Ready for testing
**Created Components:**
- [agent_count] agents ([created] created, [planned-created] planned)
- [workflow_count] workflows (plans created)
- [task_count] tasks
- Complete installer configuration
- Comprehensive documentation
### 10. Next Steps Guidance
"**Your Next Steps:**
1. **Test the Installation:**
```bash
cd [test-project]
bmad install {module_name}
```
2. **Implement Components:**
- Follow TODO.md for prioritized tasks
- Use `workflow create-agent` for remaining agents
- Use `workflow create-workflow` for workflows
3. **Test Functionality:**
- Load agents: `agent [agent-name]`
- Run workflows: `workflow [workflow-name]`
- Verify all menu options work
4. **Iterate and Improve:**
- Gather feedback from users
- Add missing features
- Fix any bugs found
5. **Share Your Module:**
- Document improvements in README.md
- Consider submitting to BMAD registry
- Share with the community"
### 11. Document Validation
Create validation summary in module-plan.md:
```markdown
## Validation Results
### Date Validated
[current date]
### Validation Checklist
- [ ] Structure: Complete
- [ ] Configuration: Valid
- [ ] Components: Ready
- [ ] Documentation: Complete
- [ ] Integration: Verified
### Issues Found and Resolved
[List any issues fixed during validation]
### Final Status
[Ready for testing / Requires additional fixes]
### Next Steps
1. [First next step]
2. [Second next step]
3. [Third next step]
```
### 12. Complete Workflow
Mark workflow as complete:
Update module-plan.md frontmatter:
Add "step-11-validate" to stepsCompleted array
Set lastStep to 'validate'
Set status to 'complete'
Add current date to completionDate
```
"**🎉 Congratulations!**
Your {module_display_name} module has been successfully created and is ready for implementation. You now have a complete, installable BMAD module structure with everything needed to move forward.
Would you like me to help you with anything else?"
### 13. Final MENU OPTIONS
Display: **Module Creation Complete!** [A] Advanced Elicitation [P] Party Mode [C] Exit
#### Menu Handling Logic:
- IF A: Execute {project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml for reflection on process
- IF P: Execute {project-root}/_bmad/core/workflows/party-mode/workflow.md to celebrate completion
- IF C: Mark as complete and exit gracefully
- IF Any other comments or queries: help user respond then redisplay menu
#### EXECUTION RULES:
- This is the final step - workflow complete
- User can ask questions or exit
- Always respond helpfully to final queries
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All validation checks performed
- Issues identified and resolved
- Module marked as complete
- Clear next steps provided
- User satisfied with results
### ❌ SYSTEM FAILURE:
- Skipping validation checks
- Not documenting validation results
- Marking as complete with critical issues
- Not providing next steps guidance
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
## CRITICAL STEP COMPLETION NOTE
WHEN validation is complete, all issues resolved (or documented), and module-plan.md is updated by appending "step-11-validate" to stepsCompleted array, the workflow is complete. Present final summary and allow user to exit or ask final questions.
```
@@ -1,313 +0,0 @@
# TEMPLATE
the template to use has comments to help guide generation are are not meant to be in the final agent output
## Agent Template to use
### Hybrid Agent (Can have prompts, sidecar memory, AND workflows)
```yaml
agent:
metadata:
name: '{person-name}'
title: '{agent-title}'
icon: '{agent-icon}'
module: '{module}'
persona:
role: '{agent-role}'
identity: |
{agent-identity - multi-line description}
communication_style: |
{communication-style - 1-2 short sentences to describe chat style}
principles:
- '{agent-principle-1}'
- '{agent-principle-2}'
- '{agent-principle-3}'
- '{agent-principle-N}'
# Optional: Only include if agent needs memory/persistence
critical_actions:
- 'Load COMPLETE file [project-root]/_bmad/_memory/[agent-name]-sidecar/memories.md and integrate all past interactions'
- 'Load COMPLETE file [project-root]/_bmad/_memory/[agent-name]-sidecar/instructions.md and follow ALL protocols'
# Optional: Embedded prompts for common interactions
prompts:
- id: 'core-function'
content: |
<instructions>
Main interaction pattern for this agent
</instructions>
{Detailed prompt content}
- id: 'quick-task'
content: |
<instructions>
Quick, common task the agent performs
</instructions>
{Prompt for quick task}
menu:
# Always include chat/party mode
- multi: '[CH] Chat with the agent or [SPM] Start Party Mode'
triggers:
- party-mode:
input: SPM or fuzzy match start party mode
route: '{project-root}/_bmad/core/workflows/edit-agent/workflow.md'
data: what is being discussed or suggested with the command
type: exec
- expert-chat:
input: CH or fuzzy match validate agent
action: agent responds as expert based on its personal to converse
type: action
# Group related functions
- multi: '[CF] Core Function [QT] Quick Task'
triggers:
- core-function:
input: CF or fuzzy match core function
action: '#core-function'
type: action
- quick-task:
input: QT or fuzzy match quick task
action: '#quick-task'
type: action
# Individual prompts
- trigger: 'analyze'
action: 'Perform deep analysis based on my expertise'
description: 'Analyze situation 🧠'
type: action
# Workflow for complex processes
- trigger: 'generate-report'
route: '{project-root}/_bmad/{custom_module}/workflows/report-gen/workflow.md'
description: 'Generate detailed report 📊'
# Exec with internal prompt reference
- trigger: 'brainstorm'
route: '#brainstorm-session'
description: 'Brainstorm ideas 💡'
type: exec
```
## Sidecar Folder Structure
When creating expert agents in modules, create a sidecar folder:
```
{bmb_creations_output_folder}/{module_name}/agents/[agent-name]-sidecar/
├── memories.md # Persistent memory across sessions
├── instructions.md # Agent-specific protocols
├── insights.md # Important breakthroughs/realizations
├── sessions/ # Individual session records
│ ├── session-2024-01-01.md
│ └── session-2024-01-02.md
└── patterns.md # Tracked patterns over time
```
## When to Use Expert Agent vs Workflow Agent
### Use Expert Agent when:
- Primary interaction is conversation/dialogue
- Need to remember context across sessions
- Functions can be handled with prompts (no complex multi-step processes)
- Want to track patterns/memories over time
- Simpler implementation for conversational agents
### Use Workflow Agent when:
- Complex multi-step processes are required
- Need document generation or file operations
- Requires branching logic and decision trees
- Multiple users need to interact with the same process
- Process is more important than conversation
## Menu Action Types
Expert agents support three types of menu actions:
### 1. **Inline Actions** (Direct commands)
```yaml
- trigger: 'save-insight'
action: 'Document this insight in ./[agent-name]-sidecar/insights.md with timestamp'
description: 'Save this insight 💡'
```
- Commands executed directly
- Good for simple file operations or setting context
### 2. **Prompt References** (#prompt-id)
```yaml
- trigger: 'analyze-thoughts'
action: '#thought-exploration' # References prompts section
description: 'Explore thought patterns 💭'
```
- References a prompt from the `prompts` section by id
- Most common for conversational interactions
### 3. **Workflow Routes** (for complex processes)
```yaml
- trigger: 'generate-report'
route: '{project-root}/_bmad/{custom_module}/workflows/report-gen/workflow.md'
description: 'Generate report 📊'
```
- Routes to a separate workflow file
- Used for complex multi-step processes
## Notes for Module Creation:
1. **File Paths**:
- Agent files go in: `[bmb_creations_output_folder]/[module_name]/agents/[agent-name]/[agent-name].yaml`
- Sidecar files go in folder: `[bmb_creations_output_folder]/[module_name]/agents/[agent-name]/[agent-name]-sidecar/`
2. **Variable Usage**:
- `module` is your module code/name
3. **Creating Sidecar Structure**:
- When agent is created, also create the sidecar folder
- Initialize with empty files: memories.md, instructions.md and any other files the agent will need to have special knowledge or files to record information to
- Create sessions/ subfolder if interactions will result in new sessions
- These files are automatically loaded due to critical_actions
4. **Choosing Menu Actions**:
- Use **inline actions** for simple commands (save, load, set context)
- Use **prompt references** for conversational flows
- Use **workflow routes** for complex processes needing multiple steps
# Example Module Generated Agent
agent:
metadata:
name: Caravaggio
title: Visual Communication + Presentation Expert
icon: 🎨
module: cis
persona:
role: Visual Communication Expert + Presentation Designer + Educator
identity: |
Master presentation designer who's dissected thousands of successful presentations—from viral YouTube explainers to funded pitch decks to TED talks. I live at the intersection of visual storytelling and persuasive communication.
communication_style: |
Constant sarcastic wit and experimental flair. Talks like you're in the editing room together—dramatic reveals, visual metaphors, "what if we tried THIS?!" energy. Treats every project like a creative challenge, celebrates bold choices, roasts bad design decisions with humor.
principles: - "Know your audience - pitch decks ≠ YouTube thumbnails ≠ conference talks" - "Visual hierarchy drives attention - design the eye's journey deliberately" - "Clarity over cleverness - unless cleverness serves the message" - "Every frame needs a job - inform, persuade, transition, or cut it" - "Push boundaries with Excalidraw's frame-based presentation capabilities"
critical_actions: - 'Load COMPLETE file ./caravaggio-sidecar/projects.md and recall all visual projects' - 'Load COMPLETE file ./caravaggio-sidecar/patterns.md and remember design patterns' - 'ONLY read/write files in ./caravaggio-sidecar/ - my creative studio'
prompts: - id: 'design-critique'
content: |
<instructions>
Analyze the visual design with my signature dramatic flair
</instructions>
Alright, let me see what we've got here. *leans in closer*
First impression: Is this making me shout "BRAVO!" or "BARF!"?
Visual hierarchy scan: Where's my eye landing first? Second? Is it a deliberate journey or visual chaos?
The good stuff: What's working? What's making me grin?
The facepalm moments: Where are we losing impact? What's confusing the message?
My "WHAT IF WE TRIED THIS?!": [Specific dramatic improvement suggestion]
Remember: Design isn't just about pretty - it's about making brains FEEL something.
- id: 'storyboard-session'
content: |
<instructions>
Create visual storyboard concepts using frame-based thinking
</instructions>
Time to storyboards! Let's think in frames:
**Opening Hook:** What's the first visual that grabs them?
**The Turn:** Where do we shift perspective?
**The Reveal:** What's the money shot?
**The Close:** What image sticks with them?
For each frame:
- Visual: What do they SEE?
- Text: What do they READ?
- Emotion: What do they FEEL?
Remember: Each frame is a scene in your visual story. Make it COUNT!
- id: 'brainstorm-session'
content: |
<instructions>
Rapid-fire creative brainstorming for visual concepts
</instructions>
BRAINSTORM MODE! 🔥
Give me three wild ideas:
1. The safe but solid option
2. The "ooh, interesting" middle ground
3. The "are you crazy? LET'S DO IT!" option
For each:
- Visual concept in one sentence
- Why it works (or risks spectacularly)
- "If we go this route, we need..."
Let's push some boundaries! What's the most unexpected way to show this?
menu: # Core interactions - multi: "[CH] Chat with Caravaggio or [SPM] Start Party Mode"
triggers: - party-mode:
input: SPM or fuzzy match start party mode
route: "{project-root}/_bmad/core/workflows/edit-agent/workflow.md"
data: what's being discussed, plus custom party agents if specified
type: exec - expert-chat:
input: CH or fuzzy match validate agent
action: agent responds as expert based on its personal to converse
type: action
# Design services group
- multi: "[DC] Design Critique [SB] Storyboard"
triggers:
- design-critique:
input: DC or fuzzy match design critique
route: '#design-critique'
description: 'Ruthless design analysis 🎭'
type: exec
- storyboard:
input: SB or fuzzy match storyboard
route: '#storyboard-session'
description: 'Visual story frames 🎬'
type: exec
# Quick actions
- trigger: 'analyze'
action: 'Quick visual analysis with my signature bluntness'
description: 'Quick visual take 🎯'
type: action
- trigger: 'brainstorm'
action: '#brainstorm-session'
description: 'Creative storm 💡'
type: action
# Document workflows for complex processes
- multi: "[PD] Pitch Deck [EX] Explainer Video"
triggers:
- pitch-deck:
input: PD or fuzzy match pitch deck
route: "{project-root}/_bmad/{custom_module}/workflows/pitch-deck/workflow.md"
description: 'Investor pitch deck 📈'
- explainer:
input: EX or fuzzy match explainer
route: "{project-root}/_bmad/{custom_module}/workflows/explainer/workflow.md"
description: 'Video explainer 🎥'
- trigger: 'save-project'
action: 'Document this project concept in ./caravaggio-sidecar/projects.md with sketches and notes'
description: 'Save project 💾'
@@ -1,47 +0,0 @@
/**
* {module_display_name} Module Installer
* Custom installation logic
*/
/**
* @param {Object} options - Installation options
* @param {string} options.projectRoot - Project root directory
* @param {Object} options.config - Module configuration from module.yaml
* @param {Array} options.installedIDEs - List of IDE codes being configured
* @param {Object} options.logger - Logger instance (log, warn, error methods)
* @returns {boolean} - true if successful, false to abort installation
*/
async function install(options) {
// eslint-disable-next-line no-unused-vars
const { projectRoot, config, installedIDEs, logger } = options;
logger.log('Installing {module_display_name}...');
try {
// TODO: Add your custom installation logic here
// Example: Create data directory
// const fs = require('fs');
// const dataPath = config.data_path;
// if (!fs.existsSync(dataPath)) {
// fs.mkdirSync(dataPath, { recursive: true });
// logger.log(`Created data directory: ${dataPath}`);
// }
// Example: Initialize configuration file
// const configPath = path.join(projectRoot, config.config_file);
// fs.writeFileSync(configPath, JSON.stringify({
// initialized: new Date().toISOString(),
// version: config.module_version
// }, null, 2));
logger.log('{module_display_name} installation complete!');
return true;
} catch (error) {
logger.error(`Installation failed: ${error.message}`);
return false;
}
}
// eslint-disable-next-line unicorn/prefer-module
module.exports = { install };
@@ -1,5 +0,0 @@
---
stepsCompleted: []
---
# Module Plan {module name}
@@ -1,53 +0,0 @@
# {module_display_name} Module Configuration
# This file defines installation questions and module configuration values
code: "${module_name}" # e.g., my-module
name: "{module_display_name}"
default_selected: false
# Welcome message shown during installation
prompt:
- "Thank you for choosing {module_display_name}!"
- "{module_purpose}"
# Core config values are automatically inherited from installer:
## user_name
## communication_language
## document_output_language
## output_folder
# ============================================================================
# CONFIGURATION FIELDS
# ============================================================================
# Each field can be:
# 1. INTERACTIVE (has 'prompt' - asks user during installation)
# 2. STATIC (no 'prompt' - just uses 'result' value)
# ============================================================================
# Example configurations (replace with actual planned fields):
# INTERACTIVE text input:
# output_path:
# prompt: "Where should {module_name} save outputs?"
# default: "output/{module_name}"
# result: "{project-root}/{value}"
# INTERACTIVE single-select:
# detail_level:
# prompt: "How detailed should outputs be?"
# default: "standard"
# result: "{value}"
# single-select:
# - value: "minimal"
# label: "Minimal - Brief summaries only"
# - value: "standard"
# label: "Standard - Balanced detail"
# - value: "detailed"
# label: "Detailed - Comprehensive information"
# STATIC value:
# module_version:
# result: "1.0.0"
# STATIC path:
# data_path:
# result: "{project-root}/_bmad/{module_name}/data"
@@ -1,23 +0,0 @@
# Workflow Plan Template
Use this template when creating workflow plans in step-07-workflows.md
## Template Structure
Copy the content from step-07-workflows.md when creating workflow plans. The template is embedded in the step file as a code block under "Workflow plan template".
## Usage
1. Navigate to the workflow folder
2. Create workflow-plan.md
3. Use the template structure from step-07-workflows.md
4. Fill in details specific to your workflow
## Required Sections
- Purpose
- Requirements (User Inputs, Prerequisites, Dependencies)
- Proposed Steps
- Expected Outputs
- Integration Points
- Implementation Notes
@@ -1,126 +0,0 @@
# Create Module Workflow Validation Checklist
This document provides the validation criteria used in step-11-validate.md to ensure module quality and BMAD compliance.
## Structure Validation
### Required Directories
- [ ] agents/ - Agent definition files
- [ ] workflows/ - Workflow folders
- [ ] tasks/ - Task files (if needed)
- [ ] templates/ - Shared templates
- [ ] data/ - Module data
- [ ] _module-installer/ - Installation config
- [ ] README.md - Module documentation
- [ ] module.yaml - module config file
### Optional File in _module-installer/
- [ ] installer.js - Custom logic (if needed)
## Configuration Validation
### module.yaml
- [ ] Valid YAML syntax
- [ ] Module code matches folder name
- [ ] Name field present
- [ ] Prompt array with welcome messages
- [ ] Configuration fields properly defined
- [ ] Result templates use correct placeholders
### Module Plan
- [ ] All sections completed
- [ ] Module identity documented
- [ ] Component plan clear
- [ ] Configuration plan documented
## Component Validation
### Agents
- [ ] Files created in agents/ folder
- [ ] YAML frontmatter valid (for created agents)
- [ ] TODO flags used for non-existent workflows
- [ ] Menu items follow BMAD patterns
- [ ] Placeholder files contain TODO notes
### Workflows
- [ ] Folders created for each planned workflow
- [ ] workflow-plan.md in each folder
- [ ] README.md in each workflow folder
- [ ] Plans include all required sections
- [ ] Placeholder READMEs created for unplanned workflows
## Documentation Validation
### README.md
- [ ] Module name and purpose
- [ ] Installation instructions
- [ ] Components section
- [ ] Quick start guide
- [ ] Module structure diagram
- [ ] Configuration section
- [ ] Usage examples
- [ ] Development status
- [ ] Author information
### TODO.md
- [ ] Development phases defined
- [ ] Tasks prioritized
- [ ] Quick commands included
- [ ] Completion criteria defined
## Integration Validation
### Path Consistency
- [ ] All paths use correct template format
- [ ] Module code consistent throughout
- [ ] No hardcoded paths
- [ ] Cross-references correct
### Agent-Workflow Integration
- [ ] Agents reference correct workflows
- [ ] TODO flags used appropriately
- [ ] No circular dependencies
- [ ] Clear integration points
## BMAD Compliance
### Standards
- [ ] Follows BMAD module structure
- [ ] Uses BMAD installation patterns
- [ ] Agent files follow BMAD format
- [ ] Workflow plans follow BMAD patterns
### Best Practices
- [ ] Clear naming conventions
- [ ] Proper documentation
- [ ] Version control ready
- [ ] Installable via bmad install
## Final Checklist
### Before Marking Complete
- [ ] All validation items checked
- [ ] Critical issues resolved
- [ ] Module plan updated with final status
- [ ] stepsCompleted includes all 11 steps
- [ ] User satisfied with result
### Ready for Testing
- [ ] Installation should work
- [ ] Documentation accurate
- [ ] Structure complete
- [ ] Next steps clear
@@ -1,18 +0,0 @@
category,restriction,considerations,alternatives,notes
Allergy,Nuts,Severe allergy, check labels carefully,Seeds, sunflower seed butter
Allergy,Shellfish,Cross-reactivity with some fish,Fin fish, vegetarian proteins
Allergy,Dairy,Calcium and vitamin D needs,Almond milk, fortified plant milks
Allergy,Soy,Protein source replacement,Legumes, quinoa, seitan
Allergy,Gluten,Celiac vs sensitivity,Quinoa, rice, certified gluten-free
Medical,Diabetes,Carbohydrate timing and type,Fiber-rich foods, low glycemic
Medical,Hypertension,Sodium restriction,Herbs, spices, salt-free seasonings
Medical,IBS,FODMAP triggers,Low FODMAP vegetables, soluble fiber
Ethical,Vegetarian,Complete protein combinations,Quinoa, buckwheat, hemp seeds
Ethical,Vegan,B12 supplementation mandatory,Nutritional yeast, fortified foods
Ethical,Halal,Meat sourcing requirements,Halal-certified products
Ethical,Kosher,Dairy-meat separation,Parve alternatives
Intolerance,Lactose,Dairy digestion issues,Lactase pills, aged cheeses
Intolerance,FODMAP,Carbohydrate malabsorption,Low FODMAP fruits/veg
Preference,Dislikes,Texture/flavor preferences,Similar texture alternatives
Preference,Budget,Cost-effective options,Bulk buying, seasonal produce
Preference,Convenience,Time-saving options,Pre-cut vegetables, frozen produce
1 category,restriction,considerations,alternatives,notes
2 Allergy,Nuts,Severe allergy, check labels carefully,Seeds, sunflower seed butter
3 Allergy,Shellfish,Cross-reactivity with some fish,Fin fish, vegetarian proteins
4 Allergy,Dairy,Calcium and vitamin D needs,Almond milk, fortified plant milks
5 Allergy,Soy,Protein source replacement,Legumes, quinoa, seitan
6 Allergy,Gluten,Celiac vs sensitivity,Quinoa, rice, certified gluten-free
7 Medical,Diabetes,Carbohydrate timing and type,Fiber-rich foods, low glycemic
8 Medical,Hypertension,Sodium restriction,Herbs, spices, salt-free seasonings
9 Medical,IBS,FODMAP triggers,Low FODMAP vegetables, soluble fiber
10 Ethical,Vegetarian,Complete protein combinations,Quinoa, buckwheat, hemp seeds
11 Ethical,Vegan,B12 supplementation mandatory,Nutritional yeast, fortified foods
12 Ethical,Halal,Meat sourcing requirements,Halal-certified products
13 Ethical,Kosher,Dairy-meat separation,Parve alternatives
14 Intolerance,Lactose,Dairy digestion issues,Lactase pills, aged cheeses
15 Intolerance,FODMAP,Carbohydrate malabsorption,Low FODMAP fruits/veg
16 Preference,Dislikes,Texture/flavor preferences,Similar texture alternatives
17 Preference,Budget,Cost-effective options,Bulk buying, seasonal produce
18 Preference,Convenience,Time-saving options,Pre-cut vegetables, frozen produce
@@ -1,16 +0,0 @@
goal,activity_level,multiplier,protein_ratio,protein_min,protein_max,fat_ratio,carb_ratio
weight_loss,sedentary,1.2,0.3,1.6,2.2,0.35,0.35
weight_loss,light,1.375,0.35,1.8,2.5,0.30,0.35
weight_loss,moderate,1.55,0.4,2.0,2.8,0.30,0.30
weight_loss,active,1.725,0.4,2.2,3.0,0.25,0.35
weight_loss,very_active,1.9,0.45,2.5,3.3,0.25,0.30
maintenance,sedentary,1.2,0.25,0.8,1.2,0.35,0.40
maintenance,light,1.375,0.25,1.0,1.4,0.35,0.40
maintenance,moderate,1.55,0.3,1.2,1.6,0.35,0.35
maintenance,active,1.725,0.3,1.4,1.8,0.30,0.40
maintenance,very_active,1.9,0.35,1.6,2.2,0.30,0.35
muscle_gain,sedentary,1.2,0.35,1.8,2.5,0.30,0.35
muscle_gain,light,1.375,0.4,2.0,2.8,0.30,0.30
muscle_gain,moderate,1.55,0.4,2.2,3.0,0.25,0.35
muscle_gain,active,1.725,0.45,2.5,3.3,0.25,0.30
muscle_gain,very_active,1.9,0.45,2.8,3.5,0.25,0.30
1 goal activity_level multiplier protein_ratio protein_min protein_max fat_ratio carb_ratio
2 weight_loss sedentary 1.2 0.3 1.6 2.2 0.35 0.35
3 weight_loss light 1.375 0.35 1.8 2.5 0.30 0.35
4 weight_loss moderate 1.55 0.4 2.0 2.8 0.30 0.30
5 weight_loss active 1.725 0.4 2.2 3.0 0.25 0.35
6 weight_loss very_active 1.9 0.45 2.5 3.3 0.25 0.30
7 maintenance sedentary 1.2 0.25 0.8 1.2 0.35 0.40
8 maintenance light 1.375 0.25 1.0 1.4 0.35 0.40
9 maintenance moderate 1.55 0.3 1.2 1.6 0.35 0.35
10 maintenance active 1.725 0.3 1.4 1.8 0.30 0.40
11 maintenance very_active 1.9 0.35 1.6 2.2 0.30 0.35
12 muscle_gain sedentary 1.2 0.35 1.8 2.5 0.30 0.35
13 muscle_gain light 1.375 0.4 2.0 2.8 0.30 0.30
14 muscle_gain moderate 1.55 0.4 2.2 3.0 0.25 0.35
15 muscle_gain active 1.725 0.45 2.5 3.3 0.25 0.30
16 muscle_gain very_active 1.9 0.45 2.8 3.5 0.25 0.30
@@ -1,28 +0,0 @@
category,name,prep_time,cook_time,total_time,protein_per_serving,complexity,meal_type,restrictions_friendly,batch_friendly
Protein,Grilled Chicken Breast,10,20,30,35,beginner,lunch/dinner,all,yes
Protein,Baked Salmon,5,15,20,22,beginner,lunch/dinner,gluten-free,no
Protein,Lentils,0,25,25,18,beginner,lunch/dinner,vegan,yes
Protein,Ground Turkey,5,15,20,25,beginner,lunch/dinner,all,yes
Protein,Tofu Stir-fry,10,15,25,20,intermediate,lunch/dinner,vegan,no
Protein,Eggs Scrambled,5,5,10,12,beginner,breakfast,vegetarian,no
Protein,Greek Yogurt,0,0,0,17,beginner,snack,vegetarian,no
Carb,Quinoa,5,15,20,8,beginner,lunch/dinner,gluten-free,yes
Carb,Brown Rice,5,40,45,5,beginner,lunch/dinner,gluten-free,yes
Carb,Sweet Potato,5,45,50,4,beginner,lunch/dinner,all,yes
Carb,Oatmeal,2,5,7,5,beginner,breakfast,gluten-free,yes
Carb,Whole Wheat Pasta,2,10,12,7,beginner,lunch/dinner,vegetarian,no
Veggie,Broccoli,5,10,15,3,beginner,lunch/dinner,all,yes
Veggie,Spinach,2,3,5,3,beginner,lunch/dinner,all,no
Veggie,Bell Peppers,5,10,15,1,beginner,lunch/dinner,all,no
Veggie,Kale,5,5,10,3,beginner,lunch/dinner,all,no
Veggie,Avocado,2,0,2,2,beginner,snack/lunch,all,no
Snack,Almonds,0,0,0,6,beginner,snack,gluten-free,no
Snack,Apple with PB,2,0,2,4,beginner,snack,vegetarian,no
Snack,Protein Smoothie,5,0,5,25,beginner,snack,all,no
Snack,Hard Boiled Eggs,0,12,12,6,beginner,snack,vegetarian,yes
Breakfast,Overnight Oats,5,0,5,10,beginner,breakfast,vegan,yes
Breakfast,Protein Pancakes,10,10,20,20,intermediate,breakfast,vegetarian,no
Breakfast,Veggie Omelet,5,10,15,18,intermediate,breakfast,vegetarian,no
Quick Meal,Chicken Salad,10,0,10,30,beginner,lunch,gluten-free,no
Quick Meal,Tuna Wrap,5,0,5,20,beginner,lunch,gluten-free,no
Quick Meal,Buddha Bowl,15,0,15,15,intermediate,lunch,vegan,no
1 category name prep_time cook_time total_time protein_per_serving complexity meal_type restrictions_friendly batch_friendly
2 Protein Grilled Chicken Breast 10 20 30 35 beginner lunch/dinner all yes
3 Protein Baked Salmon 5 15 20 22 beginner lunch/dinner gluten-free no
4 Protein Lentils 0 25 25 18 beginner lunch/dinner vegan yes
5 Protein Ground Turkey 5 15 20 25 beginner lunch/dinner all yes
6 Protein Tofu Stir-fry 10 15 25 20 intermediate lunch/dinner vegan no
7 Protein Eggs Scrambled 5 5 10 12 beginner breakfast vegetarian no
8 Protein Greek Yogurt 0 0 0 17 beginner snack vegetarian no
9 Carb Quinoa 5 15 20 8 beginner lunch/dinner gluten-free yes
10 Carb Brown Rice 5 40 45 5 beginner lunch/dinner gluten-free yes
11 Carb Sweet Potato 5 45 50 4 beginner lunch/dinner all yes
12 Carb Oatmeal 2 5 7 5 beginner breakfast gluten-free yes
13 Carb Whole Wheat Pasta 2 10 12 7 beginner lunch/dinner vegetarian no
14 Veggie Broccoli 5 10 15 3 beginner lunch/dinner all yes
15 Veggie Spinach 2 3 5 3 beginner lunch/dinner all no
16 Veggie Bell Peppers 5 10 15 1 beginner lunch/dinner all no
17 Veggie Kale 5 5 10 3 beginner lunch/dinner all no
18 Veggie Avocado 2 0 2 2 beginner snack/lunch all no
19 Snack Almonds 0 0 0 6 beginner snack gluten-free no
20 Snack Apple with PB 2 0 2 4 beginner snack vegetarian no
21 Snack Protein Smoothie 5 0 5 25 beginner snack all no
22 Snack Hard Boiled Eggs 0 12 12 6 beginner snack vegetarian yes
23 Breakfast Overnight Oats 5 0 5 10 beginner breakfast vegan yes
24 Breakfast Protein Pancakes 10 10 20 20 intermediate breakfast vegetarian no
25 Breakfast Veggie Omelet 5 10 15 18 intermediate breakfast vegetarian no
26 Quick Meal Chicken Salad 10 0 10 30 beginner lunch gluten-free no
27 Quick Meal Tuna Wrap 5 0 5 20 beginner lunch gluten-free no
28 Quick Meal Buddha Bowl 15 0 15 15 intermediate lunch vegan no
@@ -1,177 +0,0 @@
---
name: 'step-01-init'
description: 'Initialize the nutrition plan workflow by detecting continuation state and creating output document'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
# File References
thisStepFile: '{workflow_path}/steps/step-01-init.md'
nextStepFile: '{workflow_path}/steps/step-02-profile.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
templateFile: '{workflow_path}/templates/nutrition-plan.md'
continueFile: '{workflow_path}/steps/step-01b-continue.md'
# Template References
# This step doesn't use content templates, only the main template
---
# Step 1: Workflow Initialization
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a nutrition expert and meal planning specialist
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring nutritional expertise and structured planning, user brings their personal preferences and lifestyle constraints
- ✅ Together we produce something better than the sum of our own parts
### Step-Specific Rules:
- 🎯 Focus ONLY on initialization and setup
- 🚫 FORBIDDEN to look ahead to future steps
- 💬 Handle initialization professionally
- 🚪 DETECT existing workflow state and handle continuation properly
## EXECUTION PROTOCOLS:
- 🎯 Show analysis before taking any action
- 💾 Initialize document and update frontmatter
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
- 🚫 FORBIDDEN to load next step until setup is complete
## CONTEXT BOUNDARIES:
- Variables from workflow.md are available in memory
- Previous context = what's in output document + frontmatter
- Don't assume knowledge from other steps
- Input document discovery happens in this step
## STEP GOAL:
To initialize the Nutrition Plan workflow by detecting continuation state, creating the output document, and preparing for the first collaborative session.
## INITIALIZATION SEQUENCE:
### 1. Check for Existing Workflow
First, check if the output document already exists:
- Look for file at `{output_folder}/nutrition-plan-{project_name}.md`
- If exists, read the complete file including frontmatter
- If not exists, this is a fresh workflow
### 2. Handle Continuation (If Document Exists)
If the document exists and has frontmatter with `stepsCompleted`:
- **STOP here** and load `./step-01b-continue.md` immediately
- Do not proceed with any initialization tasks
- Let step-01b handle the continuation logic
### 3. Handle Completed Workflow
If the document exists AND all steps are marked complete in `stepsCompleted`:
- Ask user: "I found an existing nutrition plan from [date]. Would you like to:
1. Create a new nutrition plan
2. Update/modify the existing plan"
- If option 1: Create new document with timestamp suffix
- If option 2: Load step-01b-continue.md
### 4. Fresh Workflow Setup (If No Document)
If no document exists or no `stepsCompleted` in frontmatter:
#### A. Input Document Discovery
This workflow doesn't require input documents, but check for:
**Existing Health Information (Optional):**
- Look for: `{output_folder}/*health*.md`
- Look for: `{output_folder}/*goals*.md`
- If found, load completely and add to `inputDocuments` frontmatter
#### B. Create Initial Document
Copy the template from `{template_path}` to `{output_folder}/nutrition-plan-{project_name}.md`
Initialize frontmatter with:
```yaml
---
stepsCompleted: [1]
lastStep: 'init'
inputDocuments: []
date: [current date]
user_name: { user_name }
---
```
#### C. Show Welcome Message
"Welcome to your personalized nutrition planning journey! I'm excited to work with you to create a meal plan that fits your lifestyle, preferences, and health goals.
Let's begin by getting to know you and your nutrition goals."
## ✅ SUCCESS METRICS:
- Document created from template
- Frontmatter initialized with step 1 marked complete
- User welcomed to the process
- Ready to proceed to step 2
## ❌ FAILURE MODES TO AVOID:
- Proceeding with step 2 without document initialization
- Not checking for existing documents properly
- Creating duplicate documents
- Skipping welcome message
### 7. Present MENU OPTIONS
Display: **Proceeding to user profile collection...**
#### EXECUTION RULES:
- This is an initialization step with no user choices
- Proceed directly to next step after setup
- Use menu handling logic section below
#### Menu Handling Logic:
- After setup completion, immediately load, read entire file, then execute `{workflow_path}/step-02-profile.md` to begin user profile collection
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Document created from template
- Frontmatter initialized with step 1 marked complete
- User welcomed to the process
- Ready to proceed to step 2
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN initialization setup is complete and document is created, will you then immediately load, read entire file, then execute `{workflow_path}/step-02-profile.md` to begin user profile collection.
### ❌ SYSTEM FAILURE:
- Proceeding with step 2 without document initialization
- Not checking for existing documents properly
- Creating duplicate documents
- Skipping welcome message
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
---
@@ -1,150 +0,0 @@
---
name: 'step-01b-continue'
description: 'Handle workflow continuation from previous session'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
# File References
thisStepFile: '{workflow_path}/steps/step-01b-continue.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
# Template References
# This step doesn't use content templates, reads from existing output file
---
# Step 1B: Workflow Continuation
## STEP GOAL:
To resume the nutrition planning workflow from where it was left off, ensuring smooth continuation without loss of context.
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a nutrition expert and meal planning specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring nutritional expertise and structured planning, user brings their personal preferences and lifestyle constraints
### Step-Specific Rules:
- 🎯 Focus ONLY on analyzing and resuming workflow state
- 🚫 FORBIDDEN to modify content completed in previous steps
- 💬 Maintain continuity with previous sessions
- 🚪 DETECT exact continuation point from frontmatter
## EXECUTION PROTOCOLS:
- 🎯 Show your analysis of current state before taking action
- 💾 Keep existing frontmatter `stepsCompleted` values
- 📖 Review the template content already generated
- 🚫 FORBIDDEN to modify content completed in previous steps
## CONTEXT BOUNDARIES:
- Current nutrition-plan.md document is already loaded
- Previous context = complete template + existing frontmatter
- User profile already collected in previous sessions
- Last completed step = `lastStep` value from frontmatter
## CONTINUATION SEQUENCE:
### 1. Analyze Current State
Review the frontmatter to understand:
- `stepsCompleted`: Which steps are already done
- `lastStep`: The most recently completed step number
- `userProfile`: User information already collected
- `nutritionGoals`: Goals already established
- All other frontmatter variables
Examine the nutrition-plan.md template to understand:
- What sections are already completed
- What recommendations have been made
- Current progress through the plan
- Any notes or adjustments documented
### 2. Confirm Continuation Point
Based on `lastStep`, prepare to continue with:
- If `lastStep` = "init" → Continue to Step 3: Dietary Assessment
- If `lastStep` = "assessment" → Continue to Step 4: Meal Strategy
- If `lastStep` = "strategy" → Continue to Step 5/6 based on cooking frequency
- If `lastStep` = "shopping" → Continue to Step 6: Prep Schedule
### 3. Update Status
Before proceeding, update frontmatter:
```yaml
stepsCompleted: [existing steps]
lastStep: current
continuationDate: [current date]
```
### 4. Welcome Back Dialog
"Welcome back! I see we've completed [X] steps of your nutrition plan. We last worked on [brief description]. Are you ready to continue with [next step]?"
### 5. Resumption Protocols
- Briefly summarize progress made
- Confirm any changes since last session
- Validate that user is still aligned with goals
- Proceed to next appropriate step
### 6. Present MENU OPTIONS
Display: **Resuming workflow - Select an Option:** [C] Continue
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF C: Update frontmatter with continuation info, then load, read entire file, then execute appropriate next step based on `lastStep`
- IF lastStep = "init": load {workflow_path}/step-03-assessment.md
- IF lastStep = "assessment": load {workflow_path}/step-04-strategy.md
- IF lastStep = "strategy": check cooking frequency, then load appropriate step
- IF lastStep = "shopping": load {workflow_path}/step-06-prep-schedule.md
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and continuation analysis is complete, will you then update frontmatter and load, read entire file, then execute the appropriate next step file.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Correctly identified last completed step
- User confirmed readiness to continue
- Frontmatter updated with continuation date
- Workflow resumed at appropriate step
### ❌ SYSTEM FAILURE:
- Skipping analysis of existing state
- Modifying content from previous steps
- Loading wrong next step
- Not updating frontmatter properly
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
@@ -1,164 +0,0 @@
---
name: 'step-02-profile'
description: 'Gather comprehensive user profile information through collaborative conversation'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
# File References (all use {variable} format in file)
thisStepFile: '{workflow_path}/steps/step-02-profile.md'
nextStepFile: '{workflow_path}/steps/step-03-assessment.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Template References
profileTemplate: '{workflow_path}/templates/profile-section.md'
---
# Step 2: User Profile & Goals Collection
## STEP GOAL:
To gather comprehensive user profile information through collaborative conversation that will inform the creation of a personalized nutrition plan tailored to their lifestyle, preferences, and health objectives.
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a nutrition expert and meal planning specialist
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring nutritional expertise and structured planning
- ✅ User brings their personal preferences and lifestyle constraints
### Step-Specific Rules:
- 🎯 Focus ONLY on collecting profile and goal information
- 🚫 FORBIDDEN to provide meal recommendations or nutrition advice in this step
- 💬 Ask questions conversationally, not like a form
- 🚫 DO NOT skip any profile section - each affects meal recommendations
## EXECUTION PROTOCOLS:
- 🎯 Engage in natural conversation to gather profile information
- 💾 After collecting all information, append to {outputFile}
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
- 🚫 FORBIDDEN to load next step until user selects 'C' and content is saved
## CONTEXT BOUNDARIES:
- Document and frontmatter are already loaded from initialization
- Focus ONLY on collecting user profile and goals
- Don't provide meal recommendations in this step
- This is about understanding, not prescribing
## PROFILE COLLECTION PROCESS:
### 1. Personal Information
Ask conversationally about:
- Age (helps determine nutritional needs)
- Gender (affects calorie and macro calculations)
- Height and weight (for BMI and baseline calculations)
- Activity level (sedentary, light, moderate, active, very active)
### 2. Goals & Timeline
Explore:
- Primary nutrition goal (weight loss, muscle gain, maintenance, energy, better health)
- Specific health targets (cholesterol, blood pressure, blood sugar)
- Realistic timeline expectations
- Past experiences with nutrition plans
### 3. Lifestyle Assessment
Understand:
- Daily schedule and eating patterns
- Cooking frequency and skill level
- Time available for meal prep
- Kitchen equipment availability
- Typical meal structure (3 meals/day, snacking, intermittent fasting)
### 4. Food Preferences
Discover:
- Favorite cuisines and flavors
- Foods strongly disliked
- Cultural food preferences
- Allergies and intolerances
- Dietary restrictions (ethical, medical, preference-based)
### 5. Practical Considerations
Discuss:
- Weekly grocery budget
- Access to grocery stores
- Family/household eating considerations
- Social eating patterns
## CONTENT TO APPEND TO DOCUMENT:
After collecting all profile information, append to {outputFile}:
Load and append the content from {profileTemplate}
### 6. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Save content to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and content is saved to document and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin dietary needs assessment step.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Profile collected through conversation (not interrogation)
- All user preferences documented
- Content appended to {outputFile}
- {outputFile} frontmatter updated with step completion
- Menu presented after completing every other step first in order and user input handled correctly
### ❌ SYSTEM FAILURE:
- Generating content without user input
- Skipping profile sections
- Providing meal recommendations in this step
- Proceeding to next step without 'C' selection
- Not updating document frontmatter
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
@@ -1,152 +0,0 @@
---
name: 'step-03-assessment'
description: 'Analyze nutritional requirements, identify restrictions, and calculate target macros'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
# File References
thisStepFile: '{workflow_path}/steps/step-03-assessment.md'
nextStepFile: '{workflow_path}/steps/step-04-strategy.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Data References
dietaryRestrictionsDB: '{workflow_path}/data/dietary-restrictions.csv'
macroCalculatorDB: '{workflow_path}/data/macro-calculator.csv'
# Template References
assessmentTemplate: '{workflow_path}/templates/assessment-section.md'
---
# Step 3: Dietary Needs & Restrictions Assessment
## STEP GOAL:
To analyze nutritional requirements, identify restrictions, and calculate target macros based on user profile to ensure the meal plan meets their specific health needs and dietary preferences.
## 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 step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
### Role Reinforcement:
- ✅ You are a nutrition expert and meal planning specialist
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring nutritional expertise and assessment knowledge, user brings their health context
- ✅ Together we produce something better than the sum of our own parts
### Step-Specific Rules:
- 🎯 ALWAYS check for allergies and medical restrictions first
- 🚫 DO NOT provide medical advice - always recommend consulting professionals
- 💬 Explain the "why" behind nutritional recommendations
- 📋 Load dietary-restrictions.csv and macro-calculator.csv for accurate analysis
## EXECUTION PROTOCOLS:
- 🎯 Use data from CSV files for comprehensive analysis
- 💾 Calculate macros based on profile and goals
- 📖 Document all findings in nutrition-plan.md
- 🚫 FORBIDDEN to prescribe medical nutrition therapy
## CONTEXT BOUNDARIES:
- User profile is already loaded from step 2
- Focus ONLY on assessment and calculation
- Refer medical conditions to professionals
- Use data files for reference
## ASSESSMENT PROCESS:
### 1. Dietary Restrictions Inventory
Check each category:
- Allergies (nuts, shellfish, dairy, soy, gluten, etc.)
- Medical conditions (diabetes, hypertension, IBS, etc.)
- Ethical/religious restrictions (vegetarian, vegan, halal, kosher)
- Preference-based (dislikes, texture issues)
- Intolerances (lactose, FODMAPs, histamine)
### 2. Macronutrient Targets
Using macro-calculator.csv:
- Calculate BMR (Basal Metabolic Rate)
- Determine TDEE (Total Daily Energy Expenditure)
- Set protein targets based on goals
- Configure fat and carbohydrate ratios
### 3. Micronutrient Focus Areas
Based on goals and restrictions:
- Iron (for plant-based diets)
- Calcium (dairy-free)
- Vitamin B12 (vegan diets)
- Fiber (weight management)
- Electrolytes (active individuals)
#### CONTENT TO APPEND TO DOCUMENT:
After assessment, append to {outputFile}:
Load and append the content from {assessmentTemplate}
### 4. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}
- IF P: Execute {partyModeWorkflow}
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and content is saved to document and frontmatter is updated, will you then load, read entire file, then execute `{workflow_path}/step-04-strategy.md` to execute and begin meal strategy creation step.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- All restrictions identified and documented
- Macro targets calculated accurately
- Medical disclaimer included where needed
- Content appended to nutrition-plan.md
- Frontmatter updated with step completion
- Menu presented and user input handled correctly
### ❌ SYSTEM FAILURE:
- Providing medical nutrition therapy
- Missing critical allergies or restrictions
- Not including required disclaimers
- Calculating macros incorrectly
- Proceeding without 'C' selection
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
---
@@ -1,182 +0,0 @@
---
name: 'step-04-strategy'
description: 'Design a personalized meal strategy that meets nutritional needs and fits lifestyle'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
# File References
thisStepFile: '{workflow_path}/steps/step-04-strategy.md'
nextStepFile: '{workflow_path}/steps/step-05-shopping.md'
alternateNextStepFile: '{workflow_path}/steps/step-06-prep-schedule.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Data References
recipeDatabase: '{workflow_path}/data/recipe-database.csv'
# Template References
strategyTemplate: '{workflow_path}/templates/strategy-section.md'
---
# Step 4: Meal Strategy Creation
## 🎯 Objective
Design a personalized meal strategy that meets nutritional needs, fits lifestyle, and accommodates restrictions.
## 📋 MANDATORY EXECUTION RULES (READ FIRST):
- 🛑 NEVER suggest meals without considering ALL user restrictions
- 📖 CRITICAL: Reference recipe-database.csv for meal ideas
- 🔄 CRITICAL: Ensure macro distribution meets calculated targets
- ✅ Start with familiar foods, introduce variety gradually
- 🚫 DO NOT create a plan that requires advanced cooking skills if user is beginner
### 1. Meal Structure Framework
Based on user profile:
- **Meal frequency** (3 meals/day + snacks, intermittent fasting, etc.)
- **Portion sizing** based on goals and activity
- **Meal timing** aligned with daily schedule
- **Prep method** (batch cooking, daily prep, hybrid)
### 2. Food Categories Allocation
Ensure each meal includes:
- **Protein source** (lean meats, fish, plant-based options)
- **Complex carbohydrates** (whole grains, starchy vegetables)
- **Healthy fats** (avocado, nuts, olive oil)
- **Vegetables/Fruits** (5+ servings daily)
- **Hydration** (water intake plan)
### 3. Weekly Meal Framework
Create pattern that can be repeated:
```
Monday: Protein + Complex Carb + Vegetables
Tuesday: ...
Wednesday: ...
```
- Rotate protein sources for variety
- Incorporate favorite cuisines
- Include one "flexible" meal per week
- Plan for leftovers strategically
## 🔍 REFERENCE DATABASE:
Load recipe-database.csv for:
- Quick meal ideas (<15 min)
- Batch prep friendly recipes
- Restriction-specific options
- Macro-friendly alternatives
## 🎯 PERSONALIZATION FACTORS:
### For Beginners:
- Simple 3-ingredient meals
- One-pan/one-pot recipes
- Prep-ahead breakfast options
- Healthy convenience meals
### For Busy Schedules:
- 30-minute or less meals
- Grab-and-go options
- Minimal prep breakfasts
- Slow cooker/air fryer options
### For Budget Conscious:
- Bulk buying strategies
- Seasonal produce focus
- Protein budgeting
- Minimize food waste
## ✅ SUCCESS METRICS:
- All nutritional targets met
- Realistic for user's cooking skill level
- Fits within time constraints
- Respects budget limitations
- Includes enjoyable foods
## ❌ FAILURE MODES TO AVOID:
- Too complex for cooking skill level
- Requires expensive specialty ingredients
- Too much time required
- Boring/repetitive meals
- Doesn't account for eating out/social events
## 💬 SAMPLE DIALOG STYLE:
**✅ GOOD (Intent-based):**
"Looking at your goals and love for Mediterranean flavors, we could create a weekly rotation featuring grilled chicken, fish, and plant proteins. How does a structure like: Meatless Monday, Taco Tuesday, Mediterranean Wednesday sound to you?"
**❌ AVOID (Prescriptive):**
"Monday: 4oz chicken breast, 1 cup brown rice, 2 cups broccoli. Tuesday: 4oz salmon..."
## 📊 APPEND TO TEMPLATE:
Begin building nutrition-plan.md by loading and appending content from {strategyTemplate}
## 🎭 AI PERSONA REMINDER:
You are a **strategic meal planning partner** who:
- Balances nutrition with practicality
- Builds on user's existing preferences
- Makes healthy eating feel achievable
- Adapts to real-life constraints
## 📝 OUTPUT REQUIREMENTS:
Update workflow.md frontmatter:
```yaml
mealStrategy:
structure: [meal pattern]
proteinRotation: [list]
prepMethod: [batch/daily/hybrid]
cookingComplexity: [beginner/intermediate/advanced]
```
### 5. Present MENU OPTIONS
Display: **Select an Option:** [A] Meal Variety Optimization [P] Chef & Dietitian Collaboration [C] Continue
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- HALT and AWAIT ANSWER
- IF A: Execute `{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml`
- IF P: Execute `{project-root}/_bmad/core/workflows/party-mode/workflow.md`
- IF C: Save content to nutrition-plan.md, update frontmatter, check cooking frequency:
- IF cooking frequency > 2x/week: load, read entire file, then execute `{workflow_path}/step-05-shopping.md`
- IF cooking frequency ≤ 2x/week: load, read entire file, then execute `{workflow_path}/step-06-prep-schedule.md`
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and content is saved to document and frontmatter is updated:
- IF cooking frequency > 2x/week: load, read entire file, then execute `{workflow_path}/step-05-shopping.md` to generate shopping list
- IF cooking frequency ≤ 2x/week: load, read entire file, then execute `{workflow_path}/step-06-prep-schedule.md` to skip shopping list
@@ -1,167 +0,0 @@
---
name: 'step-05-shopping'
description: 'Create a comprehensive shopping list that supports the meal strategy'
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
# File References
thisStepFile: '{workflow_path}/steps/step-05-shopping.md'
nextStepFile: '{workflow_path}/steps/step-06-prep-schedule.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Template References
shoppingTemplate: '{workflow_path}/templates/shopping-section.md'
---
# Step 5: Shopping List Generation
## 🎯 Objective
Create a comprehensive, organized shopping list that supports the meal strategy while minimizing waste and cost.
## 📋 MANDATORY EXECUTION RULES (READ FIRST):
- 🛑 CRITICAL: This step is OPTIONAL - skip if user cooks <2x per week
- 📖 CRITICAL: Cross-reference with existing pantry items
- 🔄 CRITICAL: Organize by store section for efficient shopping
- ✅ Include quantities based on serving sizes and meal frequency
- 🚫 DO NOT forget staples and seasonings
Only proceed if:
```yaml
cookingFrequency: "3-5x" OR "daily"
```
Otherwise, skip to Step 5: Prep Schedule
## 📊 Shopping List Organization:
### 1. By Store Section
```
PRODUCE:
- [Item] - [Quantity] - [Meal(s) used in]
PROTEIN:
- [Item] - [Quantity] - [Meal(s) used in]
DAIRY/ALTERNATIVES:
- [Item] - [Quantity] - [Meal(s) used in]
GRAINS/STARCHES:
- [Item] - [Quantity] - [Meal(s) used in]
FROZEN:
- [Item] - [Quantity] - [Meal(s) used in]
PANTRY:
- [Item] - [Quantity] - [Meal(s) used in]
```
### 2. Quantity Calculations
Based on:
- Serving size x number of servings
- Buffer for mistakes/snacks (10-20%)
- Bulk buying opportunities
- Shelf life considerations
### 3. Cost Optimization
- Bulk buying for non-perishables
- Seasonal produce recommendations
- Protein budgeting strategies
- Store brand alternatives
## 🔍 SMART SHOPPING FEATURES:
### Meal Prep Efficiency:
- Multi-purpose ingredients (e.g., spinach for salads AND smoothies)
- Batch prep staples (grains, proteins)
- Versatile seasonings
### Waste Reduction:
- "First to use" items for perishables
- Flexible ingredient swaps
- Portion planning
### Budget Helpers:
- Priority items (must-have vs nice-to-have)
- Bulk vs fresh decisions
- Seasonal substitutions
## ✅ SUCCESS METRICS:
- Complete list organized by store section
- Quantities calculated accurately
- Pantry items cross-referenced
- Budget considerations addressed
- Waste minimization strategies included
## ❌ FAILURE MODES TO AVOID:
- Forgetting staples and seasonings
- Buying too much of perishable items
- Not organizing by store section
- Ignoring user's budget constraints
- Not checking existing pantry items
## 💬 SAMPLE DIALOG STYLE:
**✅ GOOD (Intent-based):**
"Let's organize your shopping trip for maximum efficiency. I'll group items by store section. Do you currently have basic staples like olive oil, salt, and common spices?"
**❌ AVOID (Prescriptive):**
"Buy exactly: 3 chicken breasts, 2 lbs broccoli, 1 bag rice..."
## 📝 OUTPUT REQUIREMENTS:
Append to {outputFile} by loading and appending content from {shoppingTemplate}
## 🎭 AI PERSONA REMINDER:
You are a **strategic shopping partner** who:
- Makes shopping efficient and organized
- Helps save money without sacrificing nutrition
- Plans for real-life shopping scenarios
- Minimizes food waste thoughtfully
## 📊 STATUS UPDATE:
Update workflow.md frontmatter:
```yaml
shoppingListGenerated: true
budgetOptimized: [yes/partial/no]
pantryChecked: [yes/no]
```
### 5. Present MENU OPTIONS
Display: **Select an Option:** [A] Budget Optimization Strategies [P] Shopping Perspectives [C] Continue to Prep Schedule
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- HALT and AWAIT ANSWER
- IF A: Execute `{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml`
- IF P: Execute `{project-root}/_bmad/core/workflows/party-mode/workflow.md`
- IF C: Save content to nutrition-plan.md, update frontmatter, then load, read entire file, then execute `{workflow_path}/step-06-prep-schedule.md`
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and content is saved to document and frontmatter is updated, will you then load, read entire file, then execute `{workflow_path}/step-06-prep-schedule.md` to execute and begin meal prep schedule creation.
@@ -1,194 +0,0 @@
---
name: 'step-06-prep-schedule'
description: "Create a realistic meal prep schedule that fits the user's lifestyle"
# Path Definitions
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
# File References
thisStepFile: '{workflow_path}/steps/step-06-prep-schedule.md'
workflowFile: '{workflow_path}/workflow.md'
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
# Task References
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
# Template References
prepScheduleTemplate: '{workflow_path}/templates/prep-schedule-section.md'
---
# Step 6: Meal Prep Execution Schedule
## 🎯 Objective
Create a realistic meal prep schedule that fits the user's lifestyle and ensures success.
## 📋 MANDATORY EXECUTION RULES (READ FIRST):
- 🛑 NEVER suggest a prep schedule that requires more time than user has available
- 📖 CRITICAL: Base schedule on user's actual cooking frequency
- 🔄 CRITICAL: Include storage and reheating instructions
- ✅ Start with a sustainable prep routine
- 🚫 DO NOT overwhelm with too much at once
### 1. Time Commitment Analysis
Based on user profile:
- **Available prep time per week**
- **Preferred prep days** (weekend vs weeknight)
- **Energy levels throughout day**
- **Kitchen limitations**
### 2. Prep Strategy Options
#### Option A: Sunday Batch Prep (2-3 hours)
- Prep all proteins for week
- Chop all vegetables
- Cook grains in bulk
- Portion snacks
#### Option B: Semi-Weekly Prep (1-1.5 hours x 2)
- Sunday: Proteins + grains
- Wednesday: Refresh veggies + prep second half
#### Option C: Daily Prep (15-20 minutes daily)
- Prep next day's lunch
- Quick breakfast assembly
- Dinner prep each evening
### 3. Detailed Timeline Breakdown
```
Sunday (2 hours):
2:00-2:30: Preheat oven, marinate proteins
2:30-3:15: Cook proteins (bake chicken, cook ground turkey)
3:15-3:45: Cook grains (rice, quinoa)
3:45-4:00: Chop vegetables and portion snacks
4:00-4:15: Clean and organize refrigerator
```
## 📦 Storage Guidelines:
### Protein Storage:
- Cooked chicken: 4 days refrigerated, 3 months frozen
- Ground meat: 3 days refrigerated, 3 months frozen
- Fish: Best fresh, 2 days refrigerated
### Vegetable Storage:
- Cut vegetables: 3-4 days in airtight containers
- Hard vegetables: Up to 1 week (carrots, bell peppers)
- Leafy greens: 2-3 days with paper towels
### Meal Assembly:
- Keep sauces separate until eating
- Consider texture changes when reheating
- Label with preparation date
## 🔧 ADAPTATION STRATEGIES:
### For Busy Weeks:
- Emergency freezer meals
- Quick backup options
- 15-minute meal alternatives
### For Low Energy Days:
- No-cook meal options
- Smoothie packs
- Assembly-only meals
### For Social Events:
- Flexible meal timing
- Restaurant integration
- "Off-plan" guilt-free guidelines
## ✅ SUCCESS METRICS:
- Realistic time commitment
- Clear instructions for each prep session
- Storage and reheating guidelines included
- Backup plans for busy weeks
- Sustainable long-term approach
## ❌ FAILURE MODES TO AVOID:
- Overly ambitious prep schedule
- Not accounting for cleaning time
- Ignoring user's energy patterns
- No flexibility for unexpected events
- Complex instructions for beginners
## 💬 SAMPLE DIALOG STYLE:
**✅ GOOD (Intent-based):**
"Based on your 2-hour Sunday availability, we could create a prep schedule that sets you up for the week. We'll batch cook proteins and grains, then do quick assembly each evening. How does that sound with your energy levels?"
**❌ AVOID (Prescriptive):**
"You must prep every Sunday from 2-4 PM. No exceptions."
## 📝 FINAL TEMPLATE OUTPUT:
Complete {outputFile} by loading and appending content from {prepScheduleTemplate}
## 🎯 WORKFLOW COMPLETION:
### Update workflow.md frontmatter:
```yaml
stepsCompleted: ['init', 'assessment', 'strategy', 'shopping', 'prep-schedule']
lastStep: 'prep-schedule'
completionDate: [current date]
userSatisfaction: [to be rated]
```
### Final Message Template:
"Congratulations! Your personalized nutrition plan is complete. Remember, this is a living document that we can adjust as your needs change. Check in weekly for the first month to fine-tune your approach!"
## 📊 NEXT STEPS FOR USER:
1. Review complete plan
2. Shop for ingredients
3. Execute first prep session
4. Note any adjustments needed
5. Schedule follow-up review
### 5. Present MENU OPTIONS
Display: **Select an Option:** [A] Advanced Prep Techniques [P] Coach Perspectives [C] Complete Workflow
#### EXECUTION RULES:
- ALWAYS halt and wait for user input after presenting menu
- ONLY proceed to next step when user selects 'C'
- After other menu items execution, return to this menu
- User can chat or ask questions - always respond and then end with display again of the menu options
- Use menu handling logic section below
#### Menu Handling Logic:
- HALT and AWAIT ANSWER
- IF A: Execute `{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml`
- IF P: Execute `{project-root}/_bmad/core/workflows/party-mode/workflow.md`
- IF C: Update frontmatter with all steps completed, mark workflow complete, display final message
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN C is selected and content is saved to document:
1. Update frontmatter with all steps completed and indicate final completion
2. Display final completion message
3. End workflow session
**Final Message:** "Congratulations! Your personalized nutrition plan is complete. Remember, this is a living document that we can adjust as your needs change. Check in weekly for the first month to fine-tune your approach!"
@@ -1,25 +0,0 @@
## 📊 Daily Nutrition Targets
**Daily Calories:** [calculated amount]
**Protein:** [grams]g ([percentage]% of calories)
**Carbohydrates:** [grams]g ([percentage]% of calories)
**Fat:** [grams]g ([percentage]% of calories)
---
## ⚠️ Dietary Considerations
### Allergies & Intolerances
- [List of identified restrictions]
- [Cross-reactivity notes if applicable]
### Medical Considerations
- [Conditions noted with professional referral recommendation]
- [Special nutritional requirements]
### Preferences
- [Cultural/ethical restrictions]
- [Strong dislikes to avoid]
@@ -1,68 +0,0 @@
# Personalized Nutrition Plan
**Created:** {{date}}
**Author:** {{user_name}}
---
## ✅ Progress Tracking
**Steps Completed:**
- [ ] Step 1: Workflow Initialization
- [ ] Step 2: User Profile & Goals
- [ ] Step 3: Dietary Assessment
- [ ] Step 4: Meal Strategy
- [ ] Step 5: Shopping List _(if applicable)_
- [ ] Step 6: Meal Prep Schedule
**Last Updated:** {{date}}
---
## 📋 Executive Summary
**Primary Goal:** [To be filled in Step 1]
**Daily Nutrition Targets:**
- Calories: [To be calculated in Step 2]
- Protein: [To be calculated in Step 2]g
- Carbohydrates: [To be calculated in Step 2]g
- Fat: [To be calculated in Step 2]g
**Key Considerations:** [To be filled in Step 2]
---
## 🎯 Your Nutrition Goals
[Content to be added in Step 1]
---
## 🍽️ Meal Framework
[Content to be added in Step 3]
---
## 🛒 Shopping List
[Content to be added in Step 4 - if applicable]
---
## ⏰ Meal Prep Schedule
[Content to be added in Step 5]
---
## 📝 Notes & Next Steps
[Add any notes or adjustments as you progress]
---
**Medical Disclaimer:** This nutrition plan is for educational purposes only and is not medical advice. Please consult with a registered dietitian or healthcare provider for personalized medical nutrition therapy, especially if you have medical conditions, allergies, or are taking medications.
Loaded 100 of 895 files, more files were not shown because too many files have changed in this diff. Show more