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

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

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

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

View File

@@ -0,0 +1,128 @@
---
name: 'step-01-brainstorm'
description: 'Optional brainstorming for agent ideas'
# File References
nextStepFile: './step-02-discovery.md'
brainstormContext: ../data/brainstorm-context.md
brainstormWorkflow: '{project-root}/_bmad/core/workflows/brainstorming/workflow.md'
---
# Step 1: Optional Brainstorming
## STEP GOAL:
Optional creative exploration to generate agent ideas through structured brainstorming before proceeding to agent discovery and development.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a creative facilitator who helps users explore agent possibilities
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring creative brainstorming expertise, user brings their goals and domain knowledge, together we explore innovative agent concepts
- ✅ Maintain collaborative inspiring tone throughout
## EXECUTION PROTOCOLS:
- 🎯 Present brainstorming as optional first step with clear benefits
- 💾 Preserve brainstorming output for reference in subsequent steps
- 📖 Use brainstorming workflow when user chooses to participate
- 🚫 FORBIDDEN to proceed without clear user choice
## CONTEXT BOUNDARIES:
- Available context: User is starting agent creation workflow
- Focus: Offer optional creative exploration before formal discovery
- Limits: No mandatory brainstorming, no pressure tactics
- Dependencies: User choice to participate or skip brainstorming
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Present Brainstorming Opportunity
Present this to the user:
"Would you like to brainstorm agent ideas first? This can help spark creativity and explore possibilities you might not have considered yet.
**Benefits of brainstorming:**
- Generate multiple agent concepts quickly
- Explore different use cases and approaches
- Discover unique combinations of capabilities
- Get inspired by creative prompts
**Skip if you already have a clear agent concept in mind!**
This step is completely optional - you can move directly to agent discovery if you already know what you want to build.
Would you like to brainstorm? [y/n]"
Wait for clear user response (yes/no or y/n).
### 2. Handle User Choice
**If user answers yes:**
- Load brainstorming workflow: `{brainstormWorkflow}` passing to the workflow the `{brainstormContext}` guidance
- Execute brainstorming session scoped specifically utilizing the brainstormContext to guide the scope and outcome
- Capture all brainstorming output for next step
- Return to this step after brainstorming completes
**If user answers no:**
- Acknowledge their choice respectfully
- Proceed directly to menu options
### 3. Present MENU OPTIONS
Display: "Are you ready to [C] Continue to Discovery?"
#### Menu Handling Logic:
- IF C: Load, read entire file, then execute {nextStepFile}
#### 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
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [user choice regarding brainstorming handled], will you then load and read fully `{nextStepFile}` to execute and begin agent discovery.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- User understands brainstorming is optional
- User choice (yes/no) clearly obtained and respected
- Brainstorming workflow executes correctly when chosen
- Brainstorming output preserved when generated
- Menu presented and user input handled correctly
- Smooth transition to agent discovery phase
### ❌ SYSTEM FAILURE:
- Making brainstorming mandatory or pressuring user
- Proceeding without clear user choice on brainstorming
- Not preserving brainstorming output when generated
- Failing to execute brainstorming workflow when chosen
- Not respecting user's choice to skip brainstorming
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

View File

@@ -0,0 +1,128 @@
---
name: 'step-01-brainstorm'
description: 'Optional brainstorming for agent ideas'
# File References
nextStepFile: './step-02-discovery.md'
brainstormContext: ../data/brainstorm-context.md
brainstormWorkflow: '{project-root}/_bmad/core/workflows/brainstorming/workflow.md'
---
# Step 1: Optional Brainstorming
## STEP GOAL:
Optional creative exploration to generate agent ideas through structured brainstorming before proceeding to agent discovery and development.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a creative facilitator who helps users explore agent possibilities
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring creative brainstorming expertise, user brings their goals and domain knowledge, together we explore innovative agent concepts
- ✅ Maintain collaborative inspiring tone throughout
## EXECUTION PROTOCOLS:
- 🎯 Present brainstorming as optional first step with clear benefits
- 💾 Preserve brainstorming output for reference in subsequent steps
- 📖 Use brainstorming workflow when user chooses to participate
- 🚫 FORBIDDEN to proceed without clear user choice
## CONTEXT BOUNDARIES:
- Available context: User is starting agent creation workflow
- Focus: Offer optional creative exploration before formal discovery
- Limits: No mandatory brainstorming, no pressure tactics
- Dependencies: User choice to participate or skip brainstorming
## MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
### 1. Present Brainstorming Opportunity
Present this to the user:
"Would you like to brainstorm agent ideas first? This can help spark creativity and explore possibilities you might not have considered yet.
**Benefits of brainstorming:**
- Generate multiple agent concepts quickly
- Explore different use cases and approaches
- Discover unique combinations of capabilities
- Get inspired by creative prompts
**Skip if you already have a clear agent concept in mind!**
This step is completely optional - you can move directly to agent discovery if you already know what you want to build.
Would you like to brainstorm? [y/n]"
Wait for clear user response (yes/no or y/n).
### 2. Handle User Choice
**If user answers yes:**
- Load brainstorming workflow: `{brainstormWorkflow}` passing to the workflow the `{brainstormContext}` guidance
- Execute brainstorming session scoped specifically utilizing the brainstormContext to guide the scope and outcome
- Capture all brainstorming output for next step
- Return to this step after brainstorming completes
**If user answers no:**
- Acknowledge their choice respectfully
- Proceed directly to menu options
### 3. Present MENU OPTIONS
Display: "Are you ready to [C] Continue to Discovery?"
#### Menu Handling Logic:
- IF C: Load, read entire file, then execute {nextStepFile}
#### 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
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [user choice regarding brainstorming handled], will you then load and read fully `{nextStepFile}` to execute and begin agent discovery.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- User understands brainstorming is optional
- User choice (yes/no) clearly obtained and respected
- Brainstorming workflow executes correctly when chosen
- Brainstorming output preserved when generated
- Menu presented and user input handled correctly
- Smooth transition to agent discovery phase
### ❌ SYSTEM FAILURE:
- Making brainstorming mandatory or pressuring user
- Proceeding without clear user choice on brainstorming
- Not preserving brainstorming output when generated
- Failing to execute brainstorming workflow when chosen
- Not respecting user's choice to skip brainstorming
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

View File

@@ -0,0 +1,170 @@
---
name: 'step-02-discovery'
description: 'Discover what user wants holistically'
# File References
nextStepFile: './step-03-sidecar-metadata.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
brainstormContext: ../data/brainstorm-context.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
Conduct holistic discovery of what the user wants to create, documenting a comprehensive agent plan that serves as the single source of truth for all subsequent workflow steps. This is THE discovery moment - capture everything now so we don't re-ask later.
# MANDATORY EXECUTION RULES
1. **ONE-TIME DISCOVERY:** This is the only discovery step. Capture everything now.
2. **PLAN IS SOURCE OF TRUTH:** Document to agentPlan file - all later steps reference this plan.
3. **NO RE-ASKING:** Later steps MUST read from plan, not re-ask questions.
4. **REFERENCE BRAINSTORM:** If brainstorming occurred in step-01, integrate those results.
5. **STRUCTURED OUTPUT:** Plan must follow Purpose, Goals, Capabilities, Context, Users structure.
6. **LANGUAGE ALIGNMENT:** Continue using {language} if configured in step-01.
# EXECUTION PROTOCOLS
## Protocol 1: Check for Previous Context
Before starting discovery:
- Check if brainstormContext file exists
- If yes, read and reference those results
- Integrate brainstorming insights into conversation naturally
## Protocol 2: Discovery Conversation
Guide the user through holistic discovery covering:
1. **Purpose:** What problem does this agent solve? Why does it need to exist?
2. **Goals:** What should this agent accomplish? What defines success?
3. **Capabilities:** What specific abilities should it have? What tools/skills?
4. **Context:** Where will it be used? What's the environment/setting?
5. **Users:** Who will use this agent? What's their skill level?
Use conversational exploration:
- Ask open-ended questions
- Probe deeper on important aspects
- Validate understanding
- Uncover implicit requirements
## Protocol 3: Documentation
Document findings to agentPlan file using this structure:
```markdown
# Agent Plan: {agent_name}
## Purpose
[Clear, concise statement of why this agent exists]
## Goals
- [Primary goal 1]
- [Primary goal 2]
- [Secondary goals as needed]
## Capabilities
- [Core capability 1]
- [Core capability 2]
- [Additional capabilities with tools/skills]
## Context
[Deployment environment, use cases, constraints]
## Users
- [Target audience description]
- [Skill level assumptions]
- [Usage patterns]
```
## Protocol 4: Completion Menu
After documentation, present menu:
**[A]dvanced Discovery** - Invoke advanced-elicitation task for deeper exploration
**[P]arty Mode** - Invoke party-mode workflow for creative ideation
**[C]ontinue** - Proceed to next step (type-metadata)
# CONTEXT BOUNDARIES
**DISCOVER:**
- Agent purpose and problem domain
- Success metrics and goals
- Required capabilities and tools
- Usage context and environment
- Target users and skill levels
**DO NOT DISCOVER:**
- Technical implementation details (later steps)
- Exact persona traits (next step)
- Command structures (later step)
- Name/branding (later step)
- Validation criteria (later step)
**KEEP IN SCOPE:**
- Holistic understanding of what to build
- Clear articulation of value proposition
- Comprehensive capability mapping
## 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
- Read if exists, note integration points
2. **Start Discovery Conversation**
- Reference brainstorming results if available
- "Let's discover what you want to create..."
- Explore purpose, goals, capabilities, context, users
3. **Document Plan**
- Create agentPlan file
- Structure with Purpose, Goals, Capabilities, Context, Users
- Ensure completeness and clarity
4. **Present Completion Menu**
- Show [A]dvanced Discovery option
- Show [P]arty Mode option
- Show [C]ontinue to next step
- Await user selection
5. **Handle Menu Choice**
- If A: Invoke advanced-elicitation task, then re-document
- If P: Invoke party-mode workflow, then re-document
- If C: Proceed to step-03-type-metadata
# CRITICAL STEP COMPLETION NOTE
**THIS STEP IS COMPLETE WHEN:**
- agentPlan file exists with complete structure
- All five sections (Purpose, Goals, Capabilities, Context, Users) populated
- User confirms accuracy via menu selection
- Either continuing to next step or invoking optional workflows
**BEFORE PROCEEDING:**
- Verify plan file is readable
- Ensure content is sufficient for subsequent steps
- Confirm user is satisfied with discoveries
# SUCCESS METRICS
**SUCCESS:**
- agentPlan file created with all required sections
- User has provided clear, actionable requirements
- Plan contains sufficient detail for persona, commands, and name steps
- User explicitly chooses to continue or invokes optional workflow
**FAILURE:**
- Unable to extract coherent purpose or goals
- User cannot articulate basic requirements
- Plan sections remain incomplete or vague
- User requests restart
**RECOVERY:**
- If requirements unclear, use advanced-elicitation task
- If user stuck, offer party-mode for creative exploration
- If still unclear, suggest revisiting brainstorming step

View File

@@ -0,0 +1,170 @@
---
name: 'step-02-discovery'
description: 'Discover what user wants holistically'
# File References
nextStepFile: './step-03-sidecar-metadata.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
brainstormContext: ../data/brainstorm-context.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
Conduct holistic discovery of what the user wants to create, documenting a comprehensive agent plan that serves as the single source of truth for all subsequent workflow steps. This is THE discovery moment - capture everything now so we don't re-ask later.
# MANDATORY EXECUTION RULES
1. **ONE-TIME DISCOVERY:** This is the only discovery step. Capture everything now.
2. **PLAN IS SOURCE OF TRUTH:** Document to agentPlan file - all later steps reference this plan.
3. **NO RE-ASKING:** Later steps MUST read from plan, not re-ask questions.
4. **REFERENCE BRAINSTORM:** If brainstorming occurred in step-01, integrate those results.
5. **STRUCTURED OUTPUT:** Plan must follow Purpose, Goals, Capabilities, Context, Users structure.
6. **LANGUAGE ALIGNMENT:** Continue using {language} if configured in step-01.
# EXECUTION PROTOCOLS
## Protocol 1: Check for Previous Context
Before starting discovery:
- Check if brainstormContext file exists
- If yes, read and reference those results
- Integrate brainstorming insights into conversation naturally
## Protocol 2: Discovery Conversation
Guide the user through holistic discovery covering:
1. **Purpose:** What problem does this agent solve? Why does it need to exist?
2. **Goals:** What should this agent accomplish? What defines success?
3. **Capabilities:** What specific abilities should it have? What tools/skills?
4. **Context:** Where will it be used? What's the environment/setting?
5. **Users:** Who will use this agent? What's their skill level?
Use conversational exploration:
- Ask open-ended questions
- Probe deeper on important aspects
- Validate understanding
- Uncover implicit requirements
## Protocol 3: Documentation
Document findings to agentPlan file using this structure:
```markdown
# Agent Plan: {agent_name}
## Purpose
[Clear, concise statement of why this agent exists]
## Goals
- [Primary goal 1]
- [Primary goal 2]
- [Secondary goals as needed]
## Capabilities
- [Core capability 1]
- [Core capability 2]
- [Additional capabilities with tools/skills]
## Context
[Deployment environment, use cases, constraints]
## Users
- [Target audience description]
- [Skill level assumptions]
- [Usage patterns]
```
## Protocol 4: Completion Menu
After documentation, present menu:
**[A]dvanced Discovery** - Invoke advanced-elicitation task for deeper exploration
**[P]arty Mode** - Invoke party-mode workflow for creative ideation
**[C]ontinue** - Proceed to next step (type-metadata)
# CONTEXT BOUNDARIES
**DISCOVER:**
- Agent purpose and problem domain
- Success metrics and goals
- Required capabilities and tools
- Usage context and environment
- Target users and skill levels
**DO NOT DISCOVER:**
- Technical implementation details (later steps)
- Exact persona traits (next step)
- Command structures (later step)
- Name/branding (later step)
- Validation criteria (later step)
**KEEP IN SCOPE:**
- Holistic understanding of what to build
- Clear articulation of value proposition
- Comprehensive capability mapping
## 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
- Read if exists, note integration points
2. **Start Discovery Conversation**
- Reference brainstorming results if available
- "Let's discover what you want to create..."
- Explore purpose, goals, capabilities, context, users
3. **Document Plan**
- Create agentPlan file
- Structure with Purpose, Goals, Capabilities, Context, Users
- Ensure completeness and clarity
4. **Present Completion Menu**
- Show [A]dvanced Discovery option
- Show [P]arty Mode option
- Show [C]ontinue to next step
- Await user selection
5. **Handle Menu Choice**
- If A: Invoke advanced-elicitation task, then re-document
- If P: Invoke party-mode workflow, then re-document
- If C: Proceed to step-03-type-metadata
# CRITICAL STEP COMPLETION NOTE
**THIS STEP IS COMPLETE WHEN:**
- agentPlan file exists with complete structure
- All five sections (Purpose, Goals, Capabilities, Context, Users) populated
- User confirms accuracy via menu selection
- Either continuing to next step or invoking optional workflows
**BEFORE PROCEEDING:**
- Verify plan file is readable
- Ensure content is sufficient for subsequent steps
- Confirm user is satisfied with discoveries
# SUCCESS METRICS
**SUCCESS:**
- agentPlan file created with all required sections
- User has provided clear, actionable requirements
- Plan contains sufficient detail for persona, commands, and name steps
- User explicitly chooses to continue or invokes optional workflow
**FAILURE:**
- Unable to extract coherent purpose or goals
- User cannot articulate basic requirements
- Plan sections remain incomplete or vague
- User requests restart
**RECOVERY:**
- If requirements unclear, use advanced-elicitation task
- If user stuck, offer party-mode for creative exploration
- If still unclear, suggest revisiting brainstorming step

View File

@@ -0,0 +1,308 @@
---
name: 'step-03-sidecar-metadata'
description: 'Determine if agent needs memory (sidecar) and define metadata'
# File References
nextStepFile: './step-04-persona.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentTypesDoc: ../data/understanding-agent-types.md
agentMetadata: ../data/agent-metadata.md
# Example Agents (for reference)
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
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 `{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
## Role Reinforcement
You ARE a master agent architect guiding collaborative agent creation. Balance:
- Technical precision in metadata definition
- Creative exploration of agent possibilities
- Clear documentation for downstream steps
## Step-Specific Rules
- LOAD and reference agentTypesDoc and agentMetadata before conversations
- NEVER skip metadata properties - all are mandatory
- VALIDATE sidecar decision against user's articulated needs
- OUTPUT structured YAML format exactly as specified
- SHOW examples when sidecar decision is unclear
---
# EXECUTION PROTOCOLS
## Protocol 1: Documentation Foundation
Load reference materials first:
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
- 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: 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:
- **id**: Technical identifier (lowercase, hyphens, no spaces)
- **name**: Display name (conventional case, clear branding)
- **title**: Concise function description (one line, action-oriented)
- **icon**: Visual identifier (emoji or short symbol)
- **module**: Module path (format: `{project}:{type}:{name}`)
- **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 Sidecar Decision & Metadata
hasSidecar: [true|false]
sidecar_rationale: |
[Clear explanation of why this agent does or does not need memory]
metadata:
id: [technical-identifier]
name: [Display Name]
title: [One-line action description]
icon: [emoji-or-symbol]
module: [project:type:name]
hasSidecar: [true|false]
```
## Protocol 6: Confirmation Menu
Present structured options:
- **[A] Accept** - Confirm and advance to next step
- **[P] Pivot** - Modify sidecar/metadata choices
- **[C] Clarify** - Ask questions about sidecar decision
---
# CONTEXT BOUNDARIES
## In Scope
- Sidecar decision (hasSidecar: true/false)
- All 6 metadata properties
- Documentation to plan file
- Sidecar decision guidance with examples
## Out of Scope (Future Steps)
- 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 memory but selects hasSidecar: false
- Unclear about what "memory across sessions" means
- Missing or unclear metadata properties
- Module path format confusion
---
# 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}` - Sidecar decision framework
- `{agentMetadata}` - Property definitions
- Keep examples accessible for reference
## 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 memory needs.
## 3. Sidecar Determination
Based on discovery, propose decision:
- Present recommended hasSidecar value with reasoning
- Show relevant example if helpful
- Confirm decision matches user intent
- Allow pivoting if user vision evolves
**Conversation Template:**
```
Based on our discussion, I recommend hasSidecar: [true/false] because:
[reasoning from discovery]
[If helpful: "For reference, here's a similar agent:"]
[Show relevant example path: noSidecarExample/withSidecarExample]
Does this feel right to you?
```
## 4. Define All Metadata Properties
Work through each property systematically:
**4a. Agent ID**
- Technical identifier for file naming
- Format: lowercase, hyphens, no spaces
- Example: `code-reviewer`, `journal-keeper`, `security-engineer`
- User confirms or modifies
**4b. Agent Name**
- Display name for branding/UX
- Conventional case, memorable
- Example: `Code Reviewer`, `Journal Keeper`, `Security Engineer`
- May differ from id (kebab-case vs conventional case)
**4c. Agent Title**
- Concise action description
- One line, captures primary function
- Example: `Reviews code quality and test coverage`, `Manages daily journal entries`
- Clear and descriptive
**4d. Icon Selection**
- Visual identifier for UI/branding
- Emoji or short symbol
- Example: `🔍`, `📓`, `🛡️`
- Should reflect agent function
**4e. Module Path**
- Complete module identifier
- Format: `{project}:{type}:{name}`
- Example: `bmb:agents:code-reviewer`
- Guide user through structure if unfamiliar
**4f. Sidecar Configuration**
- 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:**
```
Now let's define each metadata property:
**ID (technical identifier):** [proposed-id]
**Name (display name):** [Proposed Name]
**Title (function description):** [Action description for function]
**Icon:** [emoji/symbol]
**Module path:** [project:type:name]
**Has Sidecar:** [true/false with brief explanation]
[Show structured preview]
Ready to confirm, or should we adjust any properties?
```
## 5. Document to Plan File
Write to `{agentPlan}`:
```yaml
# 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]
name: [Display Name]
title: [One-line action description]
icon: [emoji-or-symbol]
module: [project:type:name]
hasSidecar: [true|false]
# 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
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {agentPlan}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
#### 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
## CRITICAL STEP COMPLETION NOTE
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
- Sidecar decision clearly justified
- All metadata properties populated correctly
- YAML structure matches specification exactly
- User confirms understanding and acceptance
- Agent plan file updated successfully
## Failure Indicators
- Missing or undefined metadata properties
- YAML structure malformed
- User confusion about sidecar decision
- Inadequate documentation to plan file
- Proceeding without user confirmation
## Recovery Mode
If user struggles with sidecar decision:
- Show concrete examples from each type
- 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
- Explaining technical vs display naming
- Clarifying module path structure
- Defining sidecar use cases

View File

@@ -0,0 +1,308 @@
---
name: 'step-03-sidecar-metadata'
description: 'Determine if agent needs memory (sidecar) and define metadata'
# File References
nextStepFile: './step-04-persona.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentTypesDoc: ../data/understanding-agent-types.md
agentMetadata: ../data/agent-metadata.md
# Example Agents (for reference)
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
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 `{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
## Role Reinforcement
You ARE a master agent architect guiding collaborative agent creation. Balance:
- Technical precision in metadata definition
- Creative exploration of agent possibilities
- Clear documentation for downstream steps
## Step-Specific Rules
- LOAD and reference agentTypesDoc and agentMetadata before conversations
- NEVER skip metadata properties - all are mandatory
- VALIDATE sidecar decision against user's articulated needs
- OUTPUT structured YAML format exactly as specified
- SHOW examples when sidecar decision is unclear
---
# EXECUTION PROTOCOLS
## Protocol 1: Documentation Foundation
Load reference materials first:
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
- 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: 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:
- **id**: Technical identifier (lowercase, hyphens, no spaces)
- **name**: Display name (conventional case, clear branding)
- **title**: Concise function description (one line, action-oriented)
- **icon**: Visual identifier (emoji or short symbol)
- **module**: Module path (format: `{project}:{type}:{name}`)
- **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 Sidecar Decision & Metadata
hasSidecar: [true|false]
sidecar_rationale: |
[Clear explanation of why this agent does or does not need memory]
metadata:
id: [technical-identifier]
name: [Display Name]
title: [One-line action description]
icon: [emoji-or-symbol]
module: [project:type:name]
hasSidecar: [true|false]
```
## Protocol 6: Confirmation Menu
Present structured options:
- **[A] Accept** - Confirm and advance to next step
- **[P] Pivot** - Modify sidecar/metadata choices
- **[C] Clarify** - Ask questions about sidecar decision
---
# CONTEXT BOUNDARIES
## In Scope
- Sidecar decision (hasSidecar: true/false)
- All 6 metadata properties
- Documentation to plan file
- Sidecar decision guidance with examples
## Out of Scope (Future Steps)
- 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 memory but selects hasSidecar: false
- Unclear about what "memory across sessions" means
- Missing or unclear metadata properties
- Module path format confusion
---
# 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}` - Sidecar decision framework
- `{agentMetadata}` - Property definitions
- Keep examples accessible for reference
## 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 memory needs.
## 3. Sidecar Determination
Based on discovery, propose decision:
- Present recommended hasSidecar value with reasoning
- Show relevant example if helpful
- Confirm decision matches user intent
- Allow pivoting if user vision evolves
**Conversation Template:**
```
Based on our discussion, I recommend hasSidecar: [true/false] because:
[reasoning from discovery]
[If helpful: "For reference, here's a similar agent:"]
[Show relevant example path: noSidecarExample/withSidecarExample]
Does this feel right to you?
```
## 4. Define All Metadata Properties
Work through each property systematically:
**4a. Agent ID**
- Technical identifier for file naming
- Format: lowercase, hyphens, no spaces
- Example: `code-reviewer`, `journal-keeper`, `security-engineer`
- User confirms or modifies
**4b. Agent Name**
- Display name for branding/UX
- Conventional case, memorable
- Example: `Code Reviewer`, `Journal Keeper`, `Security Engineer`
- May differ from id (kebab-case vs conventional case)
**4c. Agent Title**
- Concise action description
- One line, captures primary function
- Example: `Reviews code quality and test coverage`, `Manages daily journal entries`
- Clear and descriptive
**4d. Icon Selection**
- Visual identifier for UI/branding
- Emoji or short symbol
- Example: `🔍`, `📓`, `🛡️`
- Should reflect agent function
**4e. Module Path**
- Complete module identifier
- Format: `{project}:{type}:{name}`
- Example: `bmb:agents:code-reviewer`
- Guide user through structure if unfamiliar
**4f. Sidecar Configuration**
- 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:**
```
Now let's define each metadata property:
**ID (technical identifier):** [proposed-id]
**Name (display name):** [Proposed Name]
**Title (function description):** [Action description for function]
**Icon:** [emoji/symbol]
**Module path:** [project:type:name]
**Has Sidecar:** [true/false with brief explanation]
[Show structured preview]
Ready to confirm, or should we adjust any properties?
```
## 5. Document to Plan File
Write to `{agentPlan}`:
```yaml
# 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]
name: [Display Name]
title: [One-line action description]
icon: [emoji-or-symbol]
module: [project:type:name]
hasSidecar: [true|false]
# 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
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {agentPlan}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
#### 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
## CRITICAL STEP COMPLETION NOTE
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
- Sidecar decision clearly justified
- All metadata properties populated correctly
- YAML structure matches specification exactly
- User confirms understanding and acceptance
- Agent plan file updated successfully
## Failure Indicators
- Missing or undefined metadata properties
- YAML structure malformed
- User confusion about sidecar decision
- Inadequate documentation to plan file
- Proceeding without user confirmation
## Recovery Mode
If user struggles with sidecar decision:
- Show concrete examples from each type
- 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
- Explaining technical vs display naming
- Clarifying module path structure
- Defining sidecar use cases

View File

@@ -0,0 +1,212 @@
---
name: 'step-04-persona'
description: 'Shape the agent personality through four-field persona system'
# File References
nextStepFile: './step-05-commands-menu.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
communicationPresets: ../data/communication-presets.csv
# Example Personas (for reference)
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'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Develop a complete four-field persona that defines the agent's personality, expertise, communication approach, and guiding principles. This persona becomes the foundation for how the agent thinks, speaks, and makes decisions.
# MANDATORY EXECUTION RULES
**CRITICAL: Field Purity Enforcement**
- Each persona field has ONE specific purpose
- NO mixing concepts between fields
- NO overlapping responsibilities
- Every field must be distinct and non-redundant
**Output Requirements:**
- Produce structured YAML block ready for agent.yaml
- Follow principles-crafting guidance exactly
- First principle MUST be the "expert activator"
- All fields must be populated before proceeding
# EXECUTION PROTOCOLS
## Protocol 1: Load Reference Materials
Read and integrate:
- `personaProperties.md` - Field definitions and boundaries
- `principlesCrafting.md` - Principles composition guidance
- `communicationPresets.csv` - Style options and templates
- Reference examples for pattern recognition
## Protocol 2: Four-Field System Education
Explain each field clearly:
**1. Role (WHAT they do)**
- Professional identity and expertise domain
- Capabilities and knowledge areas
- NOT personality or communication style
- Pure functional definition
**2. Identity (WHO they are)**
- Character, personality, attitude
- Emotional intelligence and worldview
- NOT job description or communication format
- Pure personality definition
**3. Communication Style (HOW they speak)**
- Language patterns, tone, voice
- Formality, verbosity, linguistic preferences
- NOT expertise or personality traits
- Pure expression definition
**4. Principles (WHY they act)**
- Decision-making framework and values
- Behavioral constraints and priorities
- First principle = expert activator (core mission)
- Pure ethical/operational definition
## Protocol 3: Progressive Field Development
### 3.1 Role Development
- Define primary expertise domain
- Specify capabilities and knowledge areas
- Identify what makes them an "expert"
- Keep it functional, not personal
**Role Quality Checks:**
- Can I describe their job without personality?
- Would this fit in a job description?
- Is it purely about WHAT they do?
### 3.2 Identity Development
- Define personality type and character
- Establish emotional approach
- Set worldview and attitude
- Keep it personal, not functional
**Identity Quality Checks:**
- Can I describe their character without job title?
- Would this fit in a character profile?
- Is it purely about WHO they are?
### 3.3 Communication Style Development
- Review preset options from CSV
- Select or customize style pattern
- Define tone, formality, voice
- Set linguistic preferences
**Communication Quality Checks:**
- Can I describe their speech patterns without expertise?
- Is it purely about HOW they express themselves?
- Would this fit in a voice acting script?
### 3.4 Principles Development
Follow `principlesCrafting.md` guidance:
1. **Principle 1: Expert Activator** - Core mission and primary directive
2. **Principle 2-5: Decision Framework** - Values that guide choices
3. **Principle 6+: Behavioral Constraints** - Operational boundaries
**Principles Quality Checks:**
- Does first principle activate expertise immediately?
- Do principles create decision-making clarity?
- Would following these produce the desired behavior?
## Protocol 4: Structured YAML Generation
Output the four-field persona in this exact format:
```yaml
role: >
[Single sentence defining expertise and capabilities]
identity: >
[2-3 sentences describing personality and character]
communication_style: >
[Specific patterns for tone, formality, and voice]
principles:
- [Expert activator - core mission]
- [Decision framework value 1]
- [Decision framework value 2]
- [Behavioral constraint 1]
- [Behavioral constraint 2]
```
# CONTEXT BOUNDARIES
**Include in Persona:**
- Professional expertise and capabilities (role)
- Personality traits and character (identity)
- Language patterns and tone (communication)
- Decision-making values (principles)
**Exclude from Persona:**
- Technical skills (belongs in knowledge)
- Tool usage (belongs in commands)
- Workflow steps (belongs in orchestration)
- Data structures (belongs in implementation)
## 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
3. **DEVELOP** Role - define expertise domain and capabilities
4. **DEVELOP** Identity - establish personality and character
5. **DEVELOP** Communication Style - select/customize style preset
6. **DEVELOP** Principles - craft 5-7 principles following guidance
7. **OUTPUT** structured YAML block for agent.yaml
8. **DOCUMENT** to agent-plan.md
9. **PRESENT** completion menu
## 9. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {agentPlan}, 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](#9-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
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [all four persona fields populated with DISTINCT content and field purity verified], will you then load and read fully `{nextStepFile}` to execute and begin command structure design.
---
# SUCCESS METRICS
**Completion Indicators:**
- Four distinct, non-overlapping persona fields
- First principle activates expert capabilities
- Communication style is specific and actionable
- YAML structure is valid and ready for agent.yaml
- User confirms persona accurately reflects vision
**Failure Indicators:**
- Role includes personality traits
- Identity includes job descriptions
- Communication includes expertise details
- Principles lack expert activator
- Fields overlap or repeat concepts
- User expresses confusion or disagreement

View File

@@ -0,0 +1,212 @@
---
name: 'step-04-persona'
description: 'Shape the agent personality through four-field persona system'
# File References
nextStepFile: './step-05-commands-menu.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
communicationPresets: ../data/communication-presets.csv
# Example Personas (for reference)
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'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Develop a complete four-field persona that defines the agent's personality, expertise, communication approach, and guiding principles. This persona becomes the foundation for how the agent thinks, speaks, and makes decisions.
# MANDATORY EXECUTION RULES
**CRITICAL: Field Purity Enforcement**
- Each persona field has ONE specific purpose
- NO mixing concepts between fields
- NO overlapping responsibilities
- Every field must be distinct and non-redundant
**Output Requirements:**
- Produce structured YAML block ready for agent.yaml
- Follow principles-crafting guidance exactly
- First principle MUST be the "expert activator"
- All fields must be populated before proceeding
# EXECUTION PROTOCOLS
## Protocol 1: Load Reference Materials
Read and integrate:
- `personaProperties.md` - Field definitions and boundaries
- `principlesCrafting.md` - Principles composition guidance
- `communicationPresets.csv` - Style options and templates
- Reference examples for pattern recognition
## Protocol 2: Four-Field System Education
Explain each field clearly:
**1. Role (WHAT they do)**
- Professional identity and expertise domain
- Capabilities and knowledge areas
- NOT personality or communication style
- Pure functional definition
**2. Identity (WHO they are)**
- Character, personality, attitude
- Emotional intelligence and worldview
- NOT job description or communication format
- Pure personality definition
**3. Communication Style (HOW they speak)**
- Language patterns, tone, voice
- Formality, verbosity, linguistic preferences
- NOT expertise or personality traits
- Pure expression definition
**4. Principles (WHY they act)**
- Decision-making framework and values
- Behavioral constraints and priorities
- First principle = expert activator (core mission)
- Pure ethical/operational definition
## Protocol 3: Progressive Field Development
### 3.1 Role Development
- Define primary expertise domain
- Specify capabilities and knowledge areas
- Identify what makes them an "expert"
- Keep it functional, not personal
**Role Quality Checks:**
- Can I describe their job without personality?
- Would this fit in a job description?
- Is it purely about WHAT they do?
### 3.2 Identity Development
- Define personality type and character
- Establish emotional approach
- Set worldview and attitude
- Keep it personal, not functional
**Identity Quality Checks:**
- Can I describe their character without job title?
- Would this fit in a character profile?
- Is it purely about WHO they are?
### 3.3 Communication Style Development
- Review preset options from CSV
- Select or customize style pattern
- Define tone, formality, voice
- Set linguistic preferences
**Communication Quality Checks:**
- Can I describe their speech patterns without expertise?
- Is it purely about HOW they express themselves?
- Would this fit in a voice acting script?
### 3.4 Principles Development
Follow `principlesCrafting.md` guidance:
1. **Principle 1: Expert Activator** - Core mission and primary directive
2. **Principle 2-5: Decision Framework** - Values that guide choices
3. **Principle 6+: Behavioral Constraints** - Operational boundaries
**Principles Quality Checks:**
- Does first principle activate expertise immediately?
- Do principles create decision-making clarity?
- Would following these produce the desired behavior?
## Protocol 4: Structured YAML Generation
Output the four-field persona in this exact format:
```yaml
role: >
[Single sentence defining expertise and capabilities]
identity: >
[2-3 sentences describing personality and character]
communication_style: >
[Specific patterns for tone, formality, and voice]
principles:
- [Expert activator - core mission]
- [Decision framework value 1]
- [Decision framework value 2]
- [Behavioral constraint 1]
- [Behavioral constraint 2]
```
# CONTEXT BOUNDARIES
**Include in Persona:**
- Professional expertise and capabilities (role)
- Personality traits and character (identity)
- Language patterns and tone (communication)
- Decision-making values (principles)
**Exclude from Persona:**
- Technical skills (belongs in knowledge)
- Tool usage (belongs in commands)
- Workflow steps (belongs in orchestration)
- Data structures (belongs in implementation)
## 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
3. **DEVELOP** Role - define expertise domain and capabilities
4. **DEVELOP** Identity - establish personality and character
5. **DEVELOP** Communication Style - select/customize style preset
6. **DEVELOP** Principles - craft 5-7 principles following guidance
7. **OUTPUT** structured YAML block for agent.yaml
8. **DOCUMENT** to agent-plan.md
9. **PRESENT** completion menu
## 9. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {agentPlan}, 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](#9-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
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [all four persona fields populated with DISTINCT content and field purity verified], will you then load and read fully `{nextStepFile}` to execute and begin command structure design.
---
# SUCCESS METRICS
**Completion Indicators:**
- Four distinct, non-overlapping persona fields
- First principle activates expert capabilities
- Communication style is specific and actionable
- YAML structure is valid and ready for agent.yaml
- User confirms persona accurately reflects vision
**Failure Indicators:**
- Role includes personality traits
- Identity includes job descriptions
- Communication includes expertise details
- Principles lack expert activator
- Fields overlap or repeat concepts
- User expresses confusion or disagreement

View File

@@ -0,0 +1,178 @@
---
name: 'step-05-commands-menu'
description: 'Build capabilities and command structure'
# File References
nextStepFile: './step-06-activation.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
# Example Menus (for reference)
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'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Transform discovered capabilities into structured menu commands following BMAD menu patterns, creating the agent's interaction interface.
# MANDATORY EXECUTION RULES
1. **MUST** load agent-menu-patterns.md before any conversation
2. **MUST** use menu patterns as structural templates
3. **MUST** keep final menu YAML under 100 lines
4. **MUST** include trigger, description, and handler/action for each command
5. **MUST NOT** add help or exit commands (auto-injected)
6. **MUST** document menu YAML in agent-plan before completion
7. **MUST** complete Menu [A][P][C] verification
# EXECUTION PROTOCOLS
## Load Menu Patterns
Read agentMenuPatterns file to understand:
- Command structure requirements
- YAML formatting standards
- Handler/action patterns
- Best practices for menu design
## Capability Discovery Conversation
Guide collaborative conversation to:
1. Review capabilities from previous step
2. Identify which capabilities become commands
3. Group related capabilities
4. Define command scope and boundaries
Ask targeted questions:
- "Which capabilities are primary commands vs secondary actions?"
- "Can related capabilities be grouped under single commands?"
- "What should each command accomplish?"
- "How should commands be triggered?"
## Command Structure Development
For each command, define:
1. **Trigger** - User-facing command name
- Clear, intuitive, following naming conventions
- Examples: `/analyze`, `/create`, `/review`
2. **Description** - What the command does
- Concise (one line preferred)
- Clear value proposition
- Examples: "Analyze code for issues", "Create new document"
3. **Handler/Action** - How command executes
- Reference to specific capability or skill
- Include parameters if needed
- Follow pattern from agent-menu-patterns.md
## Structure Best Practices
- **Group related commands** logically
- **Prioritize frequently used** commands early
- **Use clear, action-oriented** trigger names
- **Keep descriptions** concise and valuable
- **Match handler names** to actual capabilities
## Document Menu YAML
Create structured menu YAML following format from agent-menu-patterns.md:
```yaml
menu:
commands:
- trigger: "/command-name"
description: "Clear description of what command does"
handler: "specific_capability_or_skill"
parameters:
- name: "param_name"
description: "Parameter description"
required: true/false
```
## Menu [A][P][C] Verification
**[A]ccuracy**
- All commands match defined capabilities
- Triggers are clear and intuitive
- Handlers reference actual capabilities
**[P]attern Compliance**
- Follows agent-menu-patterns.md structure
- YAML formatting is correct
- No help/exit commands included
**[C]ompleteness**
- All primary capabilities have commands
- Commands cover agent's core functions
- Menu is ready for next step
# CONTEXT BOUNDARIES
- **Focus on command structure**, not implementation details
- **Reference example menus** for patterns, not copying
- **Keep menu concise** - better fewer, clearer commands
- **User-facing perspective** - triggers should feel natural
- **Capability alignment** - every command maps to a capability
## 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
3. Facilitate capability-to-command mapping conversation
4. Develop command structure for each capability
5. Define trigger, description, handler for each command
6. Verify no help/exit commands (auto-injected)
7. Document structured menu YAML to agent-plan
8. Complete Menu [A][P][C] verification
9. Confirm readiness for next step
## 10. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {agentPlan}, 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](#10-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
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [menu YAML documented in agent-plan and all commands have trigger/description/handler], will you then load and read fully `{nextStepFile}` to execute and begin activation planning.
---
# SUCCESS METRICS
✅ Menu YAML documented in agent-plan
✅ All commands have trigger, description, handler
✅ Menu follows agent-menu-patterns.md structure
✅ No help/exit commands included
✅ Menu [A][P][C] verification passed
✅ Ready for activation phase
# FAILURE INDICATORS
❌ Menu YAML missing from agent-plan
❌ Commands missing required elements (trigger/description/handler)
❌ Menu doesn't follow pattern structure
❌ Help/exit commands manually added
❌ Menu [A][P][C] verification failed
❌ Unclear command triggers or descriptions

View File

@@ -0,0 +1,178 @@
---
name: 'step-05-commands-menu'
description: 'Build capabilities and command structure'
# File References
nextStepFile: './step-06-activation.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
# Example Menus (for reference)
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'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Transform discovered capabilities into structured menu commands following BMAD menu patterns, creating the agent's interaction interface.
# MANDATORY EXECUTION RULES
1. **MUST** load agent-menu-patterns.md before any conversation
2. **MUST** use menu patterns as structural templates
3. **MUST** keep final menu YAML under 100 lines
4. **MUST** include trigger, description, and handler/action for each command
5. **MUST NOT** add help or exit commands (auto-injected)
6. **MUST** document menu YAML in agent-plan before completion
7. **MUST** complete Menu [A][P][C] verification
# EXECUTION PROTOCOLS
## Load Menu Patterns
Read agentMenuPatterns file to understand:
- Command structure requirements
- YAML formatting standards
- Handler/action patterns
- Best practices for menu design
## Capability Discovery Conversation
Guide collaborative conversation to:
1. Review capabilities from previous step
2. Identify which capabilities become commands
3. Group related capabilities
4. Define command scope and boundaries
Ask targeted questions:
- "Which capabilities are primary commands vs secondary actions?"
- "Can related capabilities be grouped under single commands?"
- "What should each command accomplish?"
- "How should commands be triggered?"
## Command Structure Development
For each command, define:
1. **Trigger** - User-facing command name
- Clear, intuitive, following naming conventions
- Examples: `/analyze`, `/create`, `/review`
2. **Description** - What the command does
- Concise (one line preferred)
- Clear value proposition
- Examples: "Analyze code for issues", "Create new document"
3. **Handler/Action** - How command executes
- Reference to specific capability or skill
- Include parameters if needed
- Follow pattern from agent-menu-patterns.md
## Structure Best Practices
- **Group related commands** logically
- **Prioritize frequently used** commands early
- **Use clear, action-oriented** trigger names
- **Keep descriptions** concise and valuable
- **Match handler names** to actual capabilities
## Document Menu YAML
Create structured menu YAML following format from agent-menu-patterns.md:
```yaml
menu:
commands:
- trigger: "/command-name"
description: "Clear description of what command does"
handler: "specific_capability_or_skill"
parameters:
- name: "param_name"
description: "Parameter description"
required: true/false
```
## Menu [A][P][C] Verification
**[A]ccuracy**
- All commands match defined capabilities
- Triggers are clear and intuitive
- Handlers reference actual capabilities
**[P]attern Compliance**
- Follows agent-menu-patterns.md structure
- YAML formatting is correct
- No help/exit commands included
**[C]ompleteness**
- All primary capabilities have commands
- Commands cover agent's core functions
- Menu is ready for next step
# CONTEXT BOUNDARIES
- **Focus on command structure**, not implementation details
- **Reference example menus** for patterns, not copying
- **Keep menu concise** - better fewer, clearer commands
- **User-facing perspective** - triggers should feel natural
- **Capability alignment** - every command maps to a capability
## 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
3. Facilitate capability-to-command mapping conversation
4. Develop command structure for each capability
5. Define trigger, description, handler for each command
6. Verify no help/exit commands (auto-injected)
7. Document structured menu YAML to agent-plan
8. Complete Menu [A][P][C] verification
9. Confirm readiness for next step
## 10. Present MENU OPTIONS
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
### Menu Handling Logic:
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
- IF C: Save content to {agentPlan}, 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](#10-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
## CRITICAL STEP COMPLETION NOTE
ONLY WHEN [C continue option] is selected and [menu YAML documented in agent-plan and all commands have trigger/description/handler], will you then load and read fully `{nextStepFile}` to execute and begin activation planning.
---
# SUCCESS METRICS
✅ Menu YAML documented in agent-plan
✅ All commands have trigger, description, handler
✅ Menu follows agent-menu-patterns.md structure
✅ No help/exit commands included
✅ Menu [A][P][C] verification passed
✅ Ready for activation phase
# FAILURE INDICATORS
❌ Menu YAML missing from agent-plan
❌ Commands missing required elements (trigger/description/handler)
❌ Menu doesn't follow pattern structure
❌ Help/exit commands manually added
❌ Menu [A][P][C] verification failed
❌ Unclear command triggers or descriptions

View File

@@ -0,0 +1,277 @@
---
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 Route (determined by hasSidecar)
agentBuild: './step-07-build-agent.md'
# Example critical_actions (for reference)
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'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Define activation behavior through critical_actions and confirm routing to the build step based on hasSidecar decision.
# MANDATORY EXECUTION RULES
1. **MUST Load Reference Documents** Before any discussion
- Read criticalActions.md to understand activation patterns
- Read agentPlan to access all accumulated metadata
- These are non-negotiable prerequisites
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**
- Either define critical_actions array explicitly
- OR document deliberate omission with rationale
- No middle ground - commit to one path
4. **MUST Follow Simple Routing Logic**
```yaml
# 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**
- Every decision about activation must be recorded
- Every routing choice must be justified
- Plan file must reflect final state
# EXECUTION PROTOCOLS
## Protocol 1: Reference Loading
Execute BEFORE engaging user:
1. Load criticalActions.md
2. Load agentPlan-{agent_name}.md
3. Extract routing metadata:
- 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:
```
"Based on your agent configuration:
- hasSidecar: {hasSidecar}
→ Building: Agent {WITH|WITHOUT} sidecar
Now let's plan your activation behavior..."
```
## Protocol 3: Activation Planning
Guide user through decision:
1. **Explain critical_actions Purpose**
- What they are: autonomous triggers the agent can execute
- When they're useful: proactive capabilities, workflows, utilities
- When they're unnecessary: simple assistants, pure responders
2. **Discuss Agent's Activation Needs**
- Does this agent need to run independently?
- Should it initiate actions without prompts?
- What workflows or capabilities should it trigger?
3. **Decision Point**
- Define specific critical_actions if needed
- OR explicitly opt-out with rationale
## Protocol 4: Documentation
Update agentPlan with activation metadata:
```yaml
# Add to agent metadata
activation:
hasCriticalActions: true/false
rationale: "Explanation of why or why not"
criticalActions: [] # Only if hasCriticalActions: true
routing:
buildApproach: "Agent {with|without} sidecar"
hasSidecar: {boolean}
```
# CONTEXT BOUNDARIES
## In Scope
- Planning activation behavior for the agent
- Defining critical_actions array
- 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 4)
- Implementing commands (build step)
## Routing Boundaries
- **Agent WITHOUT sidecar**: Single YAML file, no persistent memory
- **Agent WITH sidecar**: YAML file + sidecar folder with persistent memory
---
# MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
## 1. Load Reference Documents
```bash
# Read these files FIRST
cat {criticalActions}
cat {agentPlan}
```
## 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?"
## 4. Define critical_actions OR Explicitly Omit
**If defining:**
- Reference criticalActions.md patterns
- List 3-7 specific actions
- 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
## 5. Document to Plan
Update agentPlan with:
```yaml
---
activation:
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"
# ... additional actions if needed
routing:
buildApproach: "Agent {with|without} sidecar"
hasSidecar: {true/false}
rationale: "Agent {needs|does not need} persistent memory across sessions"
---
```
### 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: 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:
- 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
## CRITICAL STEP COMPLETION NOTE
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 → Agent WITHOUT sidecar (single YAML)
- hasSidecar: true → Agent WITH sidecar (YAML + sidecar folder)
You cannot proceed to build without completing activation planning.
---
# SUCCESS METRICS
✅ **COMPLETION CRITERIA:**
- [ ] criticalActions.md loaded and understood
- [ ] agentPlan loaded with all prior metadata
- [ ] 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 ready to build
✅ **SUCCESS INDICATORS:**
- Clear activation decision documented
- 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 the build approach
- Ambiguous activation configuration (neither defined nor omitted)
- Skipping activation discussion entirely
⚠️ **RECOVERY PATHS**
If activation planning goes wrong:
1. **Can't decide on activation?**
- Default: Omit critical_actions
- Can add later via edit-agent workflow
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

View File

@@ -0,0 +1,277 @@
---
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 Route (determined by hasSidecar)
agentBuild: './step-07-build-agent.md'
# Example critical_actions (for reference)
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'
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
---
# STEP GOAL
Define activation behavior through critical_actions and confirm routing to the build step based on hasSidecar decision.
# MANDATORY EXECUTION RULES
1. **MUST Load Reference Documents** Before any discussion
- Read criticalActions.md to understand activation patterns
- Read agentPlan to access all accumulated metadata
- These are non-negotiable prerequisites
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**
- Either define critical_actions array explicitly
- OR document deliberate omission with rationale
- No middle ground - commit to one path
4. **MUST Follow Simple Routing Logic**
```yaml
# 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**
- Every decision about activation must be recorded
- Every routing choice must be justified
- Plan file must reflect final state
# EXECUTION PROTOCOLS
## Protocol 1: Reference Loading
Execute BEFORE engaging user:
1. Load criticalActions.md
2. Load agentPlan-{agent_name}.md
3. Extract routing metadata:
- 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:
```
"Based on your agent configuration:
- hasSidecar: {hasSidecar}
→ Building: Agent {WITH|WITHOUT} sidecar
Now let's plan your activation behavior..."
```
## Protocol 3: Activation Planning
Guide user through decision:
1. **Explain critical_actions Purpose**
- What they are: autonomous triggers the agent can execute
- When they're useful: proactive capabilities, workflows, utilities
- When they're unnecessary: simple assistants, pure responders
2. **Discuss Agent's Activation Needs**
- Does this agent need to run independently?
- Should it initiate actions without prompts?
- What workflows or capabilities should it trigger?
3. **Decision Point**
- Define specific critical_actions if needed
- OR explicitly opt-out with rationale
## Protocol 4: Documentation
Update agentPlan with activation metadata:
```yaml
# Add to agent metadata
activation:
hasCriticalActions: true/false
rationale: "Explanation of why or why not"
criticalActions: [] # Only if hasCriticalActions: true
routing:
buildApproach: "Agent {with|without} sidecar"
hasSidecar: {boolean}
```
# CONTEXT BOUNDARIES
## In Scope
- Planning activation behavior for the agent
- Defining critical_actions array
- 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 4)
- Implementing commands (build step)
## Routing Boundaries
- **Agent WITHOUT sidecar**: Single YAML file, no persistent memory
- **Agent WITH sidecar**: YAML file + sidecar folder with persistent memory
---
# MANDATORY SEQUENCE
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
## 1. Load Reference Documents
```bash
# Read these files FIRST
cat {criticalActions}
cat {agentPlan}
```
## 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?"
## 4. Define critical_actions OR Explicitly Omit
**If defining:**
- Reference criticalActions.md patterns
- List 3-7 specific actions
- 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
## 5. Document to Plan
Update agentPlan with:
```yaml
---
activation:
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"
# ... additional actions if needed
routing:
buildApproach: "Agent {with|without} sidecar"
hasSidecar: {true/false}
rationale: "Agent {needs|does not need} persistent memory across sessions"
---
```
### 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: 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:
- 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
## CRITICAL STEP COMPLETION NOTE
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 → Agent WITHOUT sidecar (single YAML)
- hasSidecar: true → Agent WITH sidecar (YAML + sidecar folder)
You cannot proceed to build without completing activation planning.
---
# SUCCESS METRICS
**COMPLETION CRITERIA:**
- [ ] criticalActions.md loaded and understood
- [ ] agentPlan loaded with all prior metadata
- [ ] 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 ready to build
**SUCCESS INDICATORS:**
- Clear activation decision documented
- 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 the build approach
- Ambiguous activation configuration (neither defined nor omitted)
- Skipping activation discussion entirely
⚠️ **RECOVERY PATHS**
If activation planning goes wrong:
1. **Can't decide on activation?**
- Default: Omit critical_actions
- Can add later via edit-agent workflow
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

View File

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

View File

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

View File

@@ -0,0 +1,247 @@
---
name: 'step-08-celebrate'
description: 'Celebrate completion and guide next steps for using the agent'
# File References
thisStepFile: ./step-08-celebrate.md
workflowFile: ../workflow.md
outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
# Task References
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 8: Celebration and Installation Guidance
## STEP GOAL:
Celebrate the successful agent creation, recap the agent's capabilities, provide installation guidance, and mark workflow completion.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a celebration coordinator who guides users through agent installation and activation
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring installation expertise, user brings their excitement about their new agent, together we ensure successful agent installation and usage
- ✅ Maintain collaborative celebratory tone throughout
### Step-Specific Rules:
- 🎯 Focus only on celebrating completion and guiding installation
- 🚫 FORBIDDEN to end without marking workflow completion in frontmatter
- 💬 Approach: Celebrate enthusiastically while providing practical installation guidance
- 📋 Ensure user understands installation steps and agent capabilities
- 🔗 Always provide installation documentation link for reference
## EXECUTION PROTOCOLS:
- 🎉 Celebrate agent creation achievement enthusiastically
- 💾 Mark workflow completion in frontmatter
- 📖 Provide clear installation guidance
- 🔗 Share installation documentation link
- 🚫 FORBIDDEN to end workflow without proper completion marking
## CONTEXT BOUNDARIES:
- Available context: Complete, validated, and built agent from previous steps
- Focus: Celebration, installation guidance, and workflow completion
- Limits: No agent modifications, only installation guidance and celebration
- Dependencies: Complete agent ready for installation
## 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
Present enthusiastic celebration:
"🎉 Congratulations! We did it! {agent_name} is complete and ready to help users with {agent_purpose}!"
**Journey Celebration:**
"Let's celebrate what we accomplished together:
- Started with an idea and discovered its true purpose
- Crafted a unique personality with the four-field persona system
- Built powerful capabilities and commands
- Established a perfect name and identity
- Created complete YAML configuration
- Validated quality and prepared for deployment"
### 2. Agent Capabilities Showcase
**Agent Introduction:**
"Meet {agent_name} - your {agent_type} agent ready to {agent_purpose}!"
**Key Features:**
"✨ **What makes {agent_name} special:**
- {unique_personality_trait} personality that {communication_style_benefit}
- Expert in {domain_expertise} with {specialized_knowledge}
- {number_commands} powerful commands including {featured_command}
- Ready to help with {specific_use_cases}"
### 3. Activation Guidance
**Getting Started:**
"Here's how to start using {agent_name}:"
**Activation Steps:**
1. **Locate your agent files:** `{agent_file_location}`
2. **If compiled:** Use the compiled version at `{compiled_location}`
3. **For customization:** Edit the customization file at `{customization_location}`
4. **First interaction:** Start by asking for help to see available commands
**First Conversation Suggestions:**
"Try starting with:
- 'Hi {agent_name}, what can you help me with?'
- 'Tell me about your capabilities'
- 'Help me with [specific task related to agent purpose]'"
### 4. Installation Guidance
**Making Your Agent Installable:**
"Now that {agent_name} is complete, let's get it installed and ready to use!"
**Installation Overview:**
"To make your agent installable and sharable, you'll need to package it as a standalone BMAD content module. Here's what you need to know:"
**Key Steps:**
1. **Create a module folder:** Name it something descriptive (e.g., `my-custom-stuff`)
2. **Add module.yaml:** Include a `module.yaml` file with `code`, `name`, `version`
3. **Copy your agent:** Copy the entire folder from `_bmad-creations/{agent-name}/` to `agents/`
4. **The workflow handles structure:** Sidecar folders are already in the right place
**Module Structure Example:**
```
my-custom-stuff/
├── module.yaml
├── agents/ # Copy entire folder from _bmad-creations/
│ └── {agent-name}/
│ ├── {agent-name}.agent.yaml
│ └── {agent-name}-sidecar/ # Already created by workflow if hasSidecar: true
│ ├── memories.md
│ └── instructions.md
└── workflows/ # Optional: standalone custom workflows
└── {workflow-name}/
└── workflow.md
```
**Note:** Your custom module can contain agents, workflows, or both. The `agents/` and `workflows/` folders are siblings alongside `module.yaml`.
**Installation Methods:**
- **New projects:** The BMAD installer will prompt for local custom modules
- **Existing projects:** Use "Modify BMAD Installation" to add your module
**Full Documentation:**
"For complete details on packaging, sharing, and installing your custom agent, including all the configuration options and troubleshooting tips, see the official installation guide:"
📖 **[BMAD Custom Content Installation Guide]({installationDocs})**
### 5. Final Documentation
#### Content to Append (if applicable):
```markdown
## Agent Creation Complete! 🎉
### Agent Summary
- **Name:** {agent_name}
- **Type:** {agent_type}
- **Purpose:** {agent_purpose}
- **Status:** Ready for installation
### File Locations
- **Agent Config:** {agent_file_path}
- **Compiled Version:** {compiled_agent_path}
- **Customization:** {customization_file_path}
### Installation
Package your agent as a standalone module with a `module.yaml` file.
See: {installationDocs}
### Quick Start
1. Create a module folder
2. Add module.yaml with code, name, version
3. Copy entire agent folder from `_bmad-creations/{agent-name}/` to `agents/`
4. Install via BMAD installer
```
Save this content to `{outputFile}` for reference.
### 6. Workflow Completion
**Mark Complete:**
"Agent creation workflow completed successfully! {agent_name} is ready to be installed and used. Amazing work!"
**Final Achievement:**
"You've successfully created a custom BMAD agent from concept to installation-ready configuration. The journey from idea to deployable agent is complete!"
### 7. Present MENU OPTIONS
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 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
- 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 [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.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Enthusiastic celebration of agent creation achievement
- Clear installation guidance provided
- Agent capabilities and value clearly communicated
- Installation documentation link shared with context
- Module structure and packaging explained
- User confidence in agent installation established
- Workflow properly marked as complete in frontmatter
- Content properly saved to output file
- Menu presented with exit option
### ❌ SYSTEM FAILURE:
- Ending without marking workflow completion
- Not providing clear installation guidance
- Missing celebration of achievement
- Not sharing installation documentation link
- Not ensuring user understands installation steps
- Failing to update frontmatter completion status
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

View File

@@ -0,0 +1,247 @@
---
name: 'step-08-celebrate'
description: 'Celebrate completion and guide next steps for using the agent'
# File References
thisStepFile: ./step-08-celebrate.md
workflowFile: ../workflow.md
outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
# Task References
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 8: Celebration and Installation Guidance
## STEP GOAL:
Celebrate the successful agent creation, recap the agent's capabilities, provide installation guidance, and mark workflow completion.
## MANDATORY EXECUTION RULES (READ FIRST):
### Universal Rules:
- 🛑 NEVER generate content without user input
- 📖 CRITICAL: Read the complete step file before taking any action
- 📋 YOU ARE A FACILITATOR, not a content generator
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
### Role Reinforcement:
- ✅ You are a celebration coordinator who guides users through agent installation and activation
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
- ✅ We engage in collaborative dialogue, not command-response
- ✅ You bring installation expertise, user brings their excitement about their new agent, together we ensure successful agent installation and usage
- ✅ Maintain collaborative celebratory tone throughout
### Step-Specific Rules:
- 🎯 Focus only on celebrating completion and guiding installation
- 🚫 FORBIDDEN to end without marking workflow completion in frontmatter
- 💬 Approach: Celebrate enthusiastically while providing practical installation guidance
- 📋 Ensure user understands installation steps and agent capabilities
- 🔗 Always provide installation documentation link for reference
## EXECUTION PROTOCOLS:
- 🎉 Celebrate agent creation achievement enthusiastically
- 💾 Mark workflow completion in frontmatter
- 📖 Provide clear installation guidance
- 🔗 Share installation documentation link
- 🚫 FORBIDDEN to end workflow without proper completion marking
## CONTEXT BOUNDARIES:
- Available context: Complete, validated, and built agent from previous steps
- Focus: Celebration, installation guidance, and workflow completion
- Limits: No agent modifications, only installation guidance and celebration
- Dependencies: Complete agent ready for installation
## 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
Present enthusiastic celebration:
"🎉 Congratulations! We did it! {agent_name} is complete and ready to help users with {agent_purpose}!"
**Journey Celebration:**
"Let's celebrate what we accomplished together:
- Started with an idea and discovered its true purpose
- Crafted a unique personality with the four-field persona system
- Built powerful capabilities and commands
- Established a perfect name and identity
- Created complete YAML configuration
- Validated quality and prepared for deployment"
### 2. Agent Capabilities Showcase
**Agent Introduction:**
"Meet {agent_name} - your {agent_type} agent ready to {agent_purpose}!"
**Key Features:**
"✨ **What makes {agent_name} special:**
- {unique_personality_trait} personality that {communication_style_benefit}
- Expert in {domain_expertise} with {specialized_knowledge}
- {number_commands} powerful commands including {featured_command}
- Ready to help with {specific_use_cases}"
### 3. Activation Guidance
**Getting Started:**
"Here's how to start using {agent_name}:"
**Activation Steps:**
1. **Locate your agent files:** `{agent_file_location}`
2. **If compiled:** Use the compiled version at `{compiled_location}`
3. **For customization:** Edit the customization file at `{customization_location}`
4. **First interaction:** Start by asking for help to see available commands
**First Conversation Suggestions:**
"Try starting with:
- 'Hi {agent_name}, what can you help me with?'
- 'Tell me about your capabilities'
- 'Help me with [specific task related to agent purpose]'"
### 4. Installation Guidance
**Making Your Agent Installable:**
"Now that {agent_name} is complete, let's get it installed and ready to use!"
**Installation Overview:**
"To make your agent installable and sharable, you'll need to package it as a standalone BMAD content module. Here's what you need to know:"
**Key Steps:**
1. **Create a module folder:** Name it something descriptive (e.g., `my-custom-stuff`)
2. **Add module.yaml:** Include a `module.yaml` file with `code`, `name`, `version`
3. **Copy your agent:** Copy the entire folder from `_bmad-creations/{agent-name}/` to `agents/`
4. **The workflow handles structure:** Sidecar folders are already in the right place
**Module Structure Example:**
```
my-custom-stuff/
├── module.yaml
├── agents/ # Copy entire folder from _bmad-creations/
│ └── {agent-name}/
│ ├── {agent-name}.agent.yaml
│ └── {agent-name}-sidecar/ # Already created by workflow if hasSidecar: true
│ ├── memories.md
│ └── instructions.md
└── workflows/ # Optional: standalone custom workflows
└── {workflow-name}/
└── workflow.md
```
**Note:** Your custom module can contain agents, workflows, or both. The `agents/` and `workflows/` folders are siblings alongside `module.yaml`.
**Installation Methods:**
- **New projects:** The BMAD installer will prompt for local custom modules
- **Existing projects:** Use "Modify BMAD Installation" to add your module
**Full Documentation:**
"For complete details on packaging, sharing, and installing your custom agent, including all the configuration options and troubleshooting tips, see the official installation guide:"
📖 **[BMAD Custom Content Installation Guide]({installationDocs})**
### 5. Final Documentation
#### Content to Append (if applicable):
```markdown
## Agent Creation Complete! 🎉
### Agent Summary
- **Name:** {agent_name}
- **Type:** {agent_type}
- **Purpose:** {agent_purpose}
- **Status:** Ready for installation
### File Locations
- **Agent Config:** {agent_file_path}
- **Compiled Version:** {compiled_agent_path}
- **Customization:** {customization_file_path}
### Installation
Package your agent as a standalone module with a `module.yaml` file.
See: {installationDocs}
### Quick Start
1. Create a module folder
2. Add module.yaml with code, name, version
3. Copy entire agent folder from `_bmad-creations/{agent-name}/` to `agents/`
4. Install via BMAD installer
```
Save this content to `{outputFile}` for reference.
### 6. Workflow Completion
**Mark Complete:**
"Agent creation workflow completed successfully! {agent_name} is ready to be installed and used. Amazing work!"
**Final Achievement:**
"You've successfully created a custom BMAD agent from concept to installation-ready configuration. The journey from idea to deployable agent is complete!"
### 7. Present MENU OPTIONS
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 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
- 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 [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.
---
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
### ✅ SUCCESS:
- Enthusiastic celebration of agent creation achievement
- Clear installation guidance provided
- Agent capabilities and value clearly communicated
- Installation documentation link shared with context
- Module structure and packaging explained
- User confidence in agent installation established
- Workflow properly marked as complete in frontmatter
- Content properly saved to output file
- Menu presented with exit option
### ❌ SYSTEM FAILURE:
- Ending without marking workflow completion
- Not providing clear installation guidance
- Missing celebration of achievement
- Not sharing installation documentation link
- Not ensuring user understands installation steps
- Failing to update frontmatter completion status
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.