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

@@ -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!