Ignore and untrack BMad directories
This commit is contained in:
Max
@@ -1,128 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,170 +0,0 @@
|
||||
---
|
||||
name: 'step-02-discovery'
|
||||
description: 'Discover what user wants holistically'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-03-type-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
|
||||
@@ -1,296 +0,0 @@
|
||||
---
|
||||
name: 'step-03-type-metadata'
|
||||
description: 'Determine agent type 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)
|
||||
simpleExample: ../data/reference/simple-examples/commit-poet.agent.yaml
|
||||
expertExample: ../data/reference/expert-examples/journal-keeper/journal-keeper.agent.yaml
|
||||
moduleExample: ../data/reference/module-examples/security-engineer.agent.yaml
|
||||
|
||||
# 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 the agent's classification (Simple/Expert/Module) and define all mandatory metadata properties required for agent configuration. Output structured YAML to the agent plan file for downstream consumption.
|
||||
|
||||
---
|
||||
|
||||
# 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 type selection against user's articulated needs
|
||||
- OUTPUT structured YAML format exactly as specified
|
||||
- SHOW examples when type classification is unclear
|
||||
|
||||
---
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## Protocol 1: Documentation Foundation
|
||||
Load reference materials first:
|
||||
1. Read agentTypesDoc for classification criteria
|
||||
2. Read agentMetadata for property definitions
|
||||
3. Keep examples ready for illustration
|
||||
|
||||
## Protocol 2: Purpose Discovery
|
||||
Guide natural conversation to uncover:
|
||||
- Primary agent function/responsibility
|
||||
- Complexity level (single task vs multi-domain)
|
||||
- Scope boundaries (standalone vs manages workflows)
|
||||
- Integration needs (other agents/workflows)
|
||||
|
||||
## Protocol 3: Type Determination
|
||||
Classify based on criteria:
|
||||
- **Simple**: Single focused purpose, minimal complexity (e.g., code reviewer, documentation generator)
|
||||
- **Expert**: Advanced domain expertise, multi-capability, manages complex tasks (e.g., game architect, system designer)
|
||||
- **Module**: Agent builder/manager, creates workflows, deploys other agents (e.g., agent-builder, workflow-builder)
|
||||
|
||||
## Protocol 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 - manages external workflows? (default: false)
|
||||
|
||||
## Protocol 5: Documentation Structure
|
||||
Output to agent plan file in exact YAML format:
|
||||
|
||||
```yaml
|
||||
# Agent Type & Metadata
|
||||
agent_type: [Simple|Expert|Module]
|
||||
classification_rationale: |
|
||||
|
||||
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 type/metadata choices
|
||||
- **[C] Clarify** - Ask questions about classification
|
||||
|
||||
---
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
## In Scope
|
||||
- Agent type classification
|
||||
- All 6 metadata properties
|
||||
- Documentation to plan file
|
||||
- Type selection guidance with examples
|
||||
|
||||
## Out of Scope (Future Steps)
|
||||
- Persona/character development (Step 3)
|
||||
- Command structure design (Step 4)
|
||||
- Agent naming/branding refinement (Step 5)
|
||||
- Implementation/build (Step 6)
|
||||
- Validation/testing (Step 7)
|
||||
|
||||
## Red Flags to Address
|
||||
- User wants complex agent but selects "Simple" type
|
||||
- Module classification without workflow management needs
|
||||
- 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}` - Classification framework
|
||||
- `{agentMetadata}` - Property definitions
|
||||
- Keep examples accessible for reference
|
||||
|
||||
## 2. Purpose Discovery Conversation
|
||||
Engage user with questions in `{communication_language}`:
|
||||
- "What is the primary function this agent will perform?"
|
||||
- "How complex are the tasks this agent will handle?"
|
||||
- "Will this agent need to manage workflows or other agents?"
|
||||
- "What specific domains or expertise areas are involved?"
|
||||
|
||||
Listen for natural language cues about scope and complexity.
|
||||
|
||||
## 3. Agent Type Determination
|
||||
Based on discovery, propose classification:
|
||||
- Present recommended type with reasoning
|
||||
- Show relevant example if helpful
|
||||
- Confirm classification matches user intent
|
||||
- Allow pivoting if user vision evolves
|
||||
|
||||
**Conversation Template:**
|
||||
```
|
||||
Based on our discussion, I recommend classifying this as a [TYPE] agent because:
|
||||
[reasoning from discovery]
|
||||
|
||||
[If helpful: "For reference, here's a similar [TYPE] agent:"]
|
||||
[Show relevant example path: simpleExample/expertExample/moduleExample]
|
||||
|
||||
Does this classification 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: manages external workflows?
|
||||
- Typically false for Simple/Expert agents
|
||||
- True for Module agents that deploy workflows
|
||||
- Confirm based on user's integration 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 Type & Metadata
|
||||
agent_type: [Simple|Expert|Module]
|
||||
classification_rationale: |
|
||||
[Clear explanation of why this type matches user's articulated needs]
|
||||
|
||||
metadata:
|
||||
id: [technical-identifier]
|
||||
name: [Display Name]
|
||||
title: [One-line action description]
|
||||
icon: [emoji-or-symbol]
|
||||
module: [project:type:name]
|
||||
hasSidecar: [true|false]
|
||||
|
||||
# Type Classification Notes
|
||||
type_decision_date: [YYYY-MM-DD]
|
||||
type_confidence: [High/Medium/Low]
|
||||
considered_alternatives: |
|
||||
- [Alternative type]: [reason not chosen]
|
||||
- [Alternative type]: [reason not chosen]
|
||||
```
|
||||
|
||||
### 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 [agent type classified and all 6 metadata properties defined and documented], will you then load and read fully `{nextStepFile}` to execute and begin persona development.
|
||||
|
||||
---
|
||||
|
||||
# SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
## Success Indicators
|
||||
- Type classification 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 type classification
|
||||
- Inadequate documentation to plan file
|
||||
- Proceeding without user confirmation
|
||||
|
||||
## Recovery Mode
|
||||
If user struggles with classification:
|
||||
- Show concrete examples from each type
|
||||
- Compare/contrast types with their use case
|
||||
- Ask targeted questions about complexity/scope
|
||||
- Offer type recommendation with clear reasoning
|
||||
|
||||
Recover metadata definition issues by:
|
||||
- Showing property format examples
|
||||
- Explaining technical vs display naming
|
||||
- Clarifying module path structure
|
||||
- Defining sidecar use cases
|
||||
@@ -1,212 +0,0 @@
|
||||
---
|
||||
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/simple-examples/commit-poet.agent.yaml
|
||||
expertExample: ../data/reference/expert-examples/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
|
||||
@@ -1,178 +0,0 @@
|
||||
---
|
||||
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/simple-examples/commit-poet.agent.yaml
|
||||
expertExample: ../data/reference/expert-examples/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
|
||||
@@ -1,279 +0,0 @@
|
||||
---
|
||||
name: 'step-06-activation'
|
||||
description: 'Plan activation behavior and route to build'
|
||||
|
||||
# File References
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
criticalActions: ../data/critical-actions.md
|
||||
|
||||
# Build Step Routes (determined by agent type)
|
||||
simpleBuild: './step-07a-build-simple.md'
|
||||
expertBuild: './step-07b-build-expert.md'
|
||||
moduleBuild: './step-07c-build-module.md'
|
||||
|
||||
# Example critical_actions (for reference)
|
||||
expertExample: ../data/reference/expert-examples/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
|
||||
Define activation behavior through critical_actions and route to the appropriate build step based on agent complexity.
|
||||
|
||||
# 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 Determine Route Before Activation Discussion**
|
||||
- Check `module` and `hasSidecar` from plan metadata
|
||||
- Determine destination build step FIRST
|
||||
- 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 Routing Logic Exactly**
|
||||
```yaml
|
||||
# Route determination based on module and hasSidecar
|
||||
# Module agents: any module value other than "stand-alone"
|
||||
module ≠ "stand-alone" → step-07c-build-module.md
|
||||
# Stand-alone agents: determined by hasSidecar
|
||||
module = "stand-alone" + hasSidecar: true → step-07b-build-expert.md
|
||||
module = "stand-alone" + hasSidecar: false → step-07a-build-simple.md
|
||||
```
|
||||
|
||||
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)
|
||||
- module (string)
|
||||
- agentType (if defined)
|
||||
4. Determine destination build step
|
||||
|
||||
## Protocol 2: Routing Disclosure
|
||||
Inform user immediately of determined route:
|
||||
|
||||
```
|
||||
"Based on your agent configuration:
|
||||
- hasSidecar: {hasSidecar}
|
||||
- module: {module}
|
||||
|
||||
→ Routing to: {destinationStep}
|
||||
|
||||
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:
|
||||
destinationBuild: "step-06-{X}.md"
|
||||
hasSidecar: {boolean}
|
||||
module: "{module}"
|
||||
```
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
## In Scope
|
||||
- Planning activation behavior for the agent
|
||||
- Defining critical_actions array
|
||||
- Routing to appropriate build step
|
||||
- Documenting activation decisions
|
||||
|
||||
## Out of Scope
|
||||
- Writing actual activation code (build step)
|
||||
- Designing sidecar workflows (build step)
|
||||
- Changing core agent metadata (locked after step 04)
|
||||
- Implementing commands (build step)
|
||||
|
||||
## Routing Boundaries
|
||||
- Simple agents: No sidecar, straightforward activation
|
||||
- Expert agents: Sidecar + stand-alone module
|
||||
- Module agents: Sidecar + parent module integration
|
||||
|
||||
## 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. Discuss Activation Needs
|
||||
Ask user:
|
||||
- "Should your agent be able to take autonomous actions?"
|
||||
- "Are there specific workflows it should trigger?"
|
||||
- "Should it run as a background process or scheduled task?"
|
||||
- "Or will it primarily respond to direct prompts?"
|
||||
|
||||
## 3. Define critical_actions OR Explicitly Omit
|
||||
|
||||
**If defining:**
|
||||
- Reference criticalActions.md patterns
|
||||
- List 3-7 specific actions
|
||||
- Each action should be clear and scoped
|
||||
- Document rationale for each
|
||||
|
||||
**If omitting:**
|
||||
- State clearly: "This agent will not have critical_actions"
|
||||
- Explain why: "This agent is a responsive assistant that operates under direct user guidance"
|
||||
- Document the rationale
|
||||
|
||||
## 4. Route to Build Step
|
||||
|
||||
Determine destination:
|
||||
|
||||
```yaml
|
||||
# Check plan metadata
|
||||
hasSidecar: {value from step 04}
|
||||
module: "{value from step 04}"
|
||||
|
||||
# Route logic
|
||||
if hasSidecar == false:
|
||||
destination = simpleBuild
|
||||
elif hasSidecar == true and module == "stand-alone":
|
||||
destination = expertBuild
|
||||
else: # hasSidecar == true and module != "stand-alone"
|
||||
destination = moduleBuild
|
||||
```
|
||||
|
||||
## 5. Document to Plan
|
||||
|
||||
Update agentPlan with:
|
||||
|
||||
```yaml
|
||||
---
|
||||
activation:
|
||||
hasCriticalActions: true
|
||||
rationale: "Agent needs to autonomously trigger workflows for task automation"
|
||||
criticalActions:
|
||||
- name: "start-workflow"
|
||||
description: "Initiate a predefined workflow for task execution"
|
||||
- name: "schedule-task"
|
||||
description: "Schedule tasks for future execution"
|
||||
- name: "sync-data"
|
||||
description: "Synchronize data with external systems"
|
||||
|
||||
routing:
|
||||
destinationBuild: "step-06-build-expert.md"
|
||||
hasSidecar: true
|
||||
module: "stand-alone"
|
||||
rationale: "Agent requires sidecar workflows for autonomous operation"
|
||||
---
|
||||
```
|
||||
|
||||
### 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, determine appropriate build step based on hasSidecar and module values, then only then load, read entire file, then execute {simpleBuild} or {expertBuild} or {moduleBuild} as determined
|
||||
- IF 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 **ROUTING HUB** of agent creation. ONLY WHEN [C continue option] is selected and [routing decision determined with activation needs documented], will you then determine the appropriate build step based on hasSidecar/module values and load and read fully that build step file to execute.
|
||||
|
||||
Routing logic:
|
||||
- hasSidecar: false → step-06-build-simple.md
|
||||
- hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
|
||||
- hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md
|
||||
|
||||
You cannot proceed to build without completing routing.
|
||||
|
||||
---
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
✅ **COMPLETION CRITERIA:**
|
||||
- [ ] criticalActions.md loaded and understood
|
||||
- [ ] agentPlan loaded with all prior metadata
|
||||
- [ ] Routing decision determined and communicated
|
||||
- [ ] Activation needs discussed with user
|
||||
- [ ] critical_actions defined OR explicitly omitted with rationale
|
||||
- [ ] Plan updated with activation and routing metadata
|
||||
- [ ] User confirms routing to appropriate build step
|
||||
|
||||
✅ **SUCCESS INDICATORS:**
|
||||
- Clear activation decision documented
|
||||
- Route to build step is unambiguous
|
||||
- User understands why they're going to {simple|expert|module} build
|
||||
- Plan file reflects complete activation configuration
|
||||
|
||||
❌ **FAILURE MODES:**
|
||||
- Attempting to define critical_actions without reading reference
|
||||
- Routing decision not documented in plan
|
||||
- User doesn't understand which build step comes next
|
||||
- Ambiguous activation configuration (neither defined nor omitted)
|
||||
- Skipping routing discussion entirely
|
||||
|
||||
⚠️ **RECOVERY PATHS:**
|
||||
If activation planning goes wrong:
|
||||
|
||||
1. **Can't decide on activation?**
|
||||
- Default: Omit critical_actions
|
||||
- Route to simpleBuild
|
||||
- Can add later via edit-agent workflow
|
||||
|
||||
2. **Uncertain about routing?**
|
||||
- Check hasSidecar value
|
||||
- Check module value
|
||||
- Apply routing logic strictly
|
||||
|
||||
3. **User wants to change route?**
|
||||
- Adjust hasSidecar or module values
|
||||
- Re-run routing logic
|
||||
- Update plan accordingly
|
||||
@@ -1,187 +0,0 @@
|
||||
---
|
||||
name: 'step-07a-build-simple'
|
||||
description: 'Generate Simple agent YAML from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}.agent.yaml'
|
||||
|
||||
# Template and Architecture
|
||||
simpleTemplate: ../templates/simple-agent.template.md
|
||||
simpleArch: ../data/simple-agent-architecture.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Assemble the agent plan content into a Simple agent YAML configuration using the template, producing a complete agent definition ready for validation.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **MUST** read all referenced files before beginning assembly
|
||||
- **MUST** use exact YAML structure from template
|
||||
- **MUST** preserve all plan content without modification
|
||||
- **MUST** maintain proper YAML indentation and formatting
|
||||
- **MUST NOT** deviate from template structure
|
||||
- **MUST** write output before asking validation question
|
||||
- **MUST** present validation choice clearly
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### File Loading Sequence
|
||||
1. Read `simpleTemplate` - provides the YAML structure
|
||||
2. Read `simpleArch` - defines Simple agent architecture rules
|
||||
3. Read `agentCompilation` - provides assembly guidelines
|
||||
4. Read `agentPlan` - contains structured content from steps 2-5
|
||||
|
||||
### YAML Assembly Process
|
||||
1. Parse template structure
|
||||
2. Extract content sections from agentPlan YAML
|
||||
3. Map plan content to template fields
|
||||
4. Validate YAML syntax before writing
|
||||
5. Write complete agent YAML to output path
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**INCLUDE:**
|
||||
- Template structure exactly as provided
|
||||
- All agent metadata from agentPlan
|
||||
- Persona, commands, and rules from plan
|
||||
- Configuration options specified
|
||||
|
||||
**EXCLUDE:**
|
||||
- Any content not in agentPlan
|
||||
- Sidecar file references (Simple agents don't use them)
|
||||
- Template placeholders (replace with actual content)
|
||||
- Comments or notes in final YAML
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Template and Architecture Files
|
||||
|
||||
Read the following files in order:
|
||||
- `simpleTemplate` - YAML structure template
|
||||
- `simpleArch` - Simple agent architecture definition
|
||||
- `agentCompilation` - Assembly instructions
|
||||
|
||||
**Verify:** All files loaded successfully.
|
||||
|
||||
### 2. Load Agent Plan
|
||||
|
||||
Read `agentPlan` which contains structured YAML from steps 2-5:
|
||||
- Step 2: Discovery findings
|
||||
- Step 3: Persona development
|
||||
- Step 4: Command structure
|
||||
- Step 5: Agent naming
|
||||
|
||||
**Verify:** Plan contains all required sections.
|
||||
|
||||
### 3. Assemble YAML Using Template
|
||||
|
||||
Execute the following assembly process:
|
||||
|
||||
1. **Parse Template Structure**
|
||||
- Identify all YAML fields
|
||||
- Note required vs optional fields
|
||||
- Map field types and formats
|
||||
|
||||
2. **Extract Plan Content**
|
||||
- Read agent metadata
|
||||
- Extract persona definition
|
||||
- Retrieve command specifications
|
||||
- Gather rules and constraints
|
||||
|
||||
3. **Map Content to Template**
|
||||
- Replace template placeholders with plan content
|
||||
- Maintain exact YAML structure
|
||||
- Preserve indentation and formatting
|
||||
- Validate field types and values
|
||||
|
||||
4. **Validate YAML Syntax**
|
||||
- Check proper indentation
|
||||
- Verify quote usage
|
||||
- Ensure list formatting
|
||||
- Confirm no syntax errors
|
||||
|
||||
**Verify:** YAML is valid, complete, and follows template structure.
|
||||
|
||||
### 4. Write Agent Build Output
|
||||
|
||||
Write the assembled YAML to `agentBuildOutput`:
|
||||
- Use exact output path from variable
|
||||
- Include all content without truncation
|
||||
- Maintain YAML formatting
|
||||
- Confirm write operation succeeded
|
||||
|
||||
**Verify:** File written successfully and contains complete YAML.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
### 6. Route Based on User Choice
|
||||
|
||||
**If user chooses "one-at-a-time":**
|
||||
- Proceed to `nextStepFile` (step-08-celebrate.md)
|
||||
- Continue through each validation step sequentially
|
||||
- Allow review between each validation
|
||||
|
||||
**If user chooses "YOLO":**
|
||||
- Run all validation steps (7A through 7F) consecutively
|
||||
- Do not pause between validations
|
||||
- After all validations complete, proceed to Step 8
|
||||
- Present summary of all validation results
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
**SUCCESS looks like:**
|
||||
- Agent YAML file exists at specified output path
|
||||
- YAML is syntactically valid and well-formed
|
||||
- All template fields populated with plan content
|
||||
- Structure matches Simple agent architecture
|
||||
- User has selected validation approach
|
||||
- Clear next step identified
|
||||
|
||||
**FAILURE looks like:**
|
||||
- Template or architecture files not found
|
||||
- Agent plan missing required sections
|
||||
- YAML syntax errors in output
|
||||
- Content not properly mapped to template
|
||||
- File write operation fails
|
||||
- User selection unclear
|
||||
|
||||
## TRANSITION CRITERIA
|
||||
|
||||
**Ready for Step 7A when:**
|
||||
- Simple agent YAML successfully created
|
||||
- User chooses "one-at-a-time" validation
|
||||
|
||||
**Ready for Step 8 when:**
|
||||
- Simple agent YAML successfully created
|
||||
- User chooses "YOLO" validation
|
||||
- All validations (7A-7F) completed consecutively
|
||||
@@ -1,201 +0,0 @@
|
||||
---
|
||||
name: 'step-06-build-expert'
|
||||
description: 'Generate Expert agent YAML with sidecar from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
|
||||
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Template and Architecture
|
||||
expertTemplate: ../templates/expert-agent-template/expert-agent.template.md
|
||||
expertArch: ../data/expert-agent-architecture.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
criticalActions: ../data/critical-actions.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage, so the build creates a sidecar folder next to the agent.yaml (which gets installed to `_bmad/_memory/` during BMAD installation).
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created next to agent.yaml (build location), which will be installed to `_bmad/_memory/` during BMAD installation
|
||||
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations (runtime path)
|
||||
3. **TEMPLATE COMPLIANCE**: Follow expert-agent-template.md structure exactly
|
||||
4. **YAML VALIDATION**: Ensure valid YAML syntax with proper indentation (2-space)
|
||||
5. **EXISTING CHECK**: If agentYamlOutput exists, ask user before overwriting
|
||||
6. **NO DRIFT**: Use ONLY content from agentPlan - no additions or interpretations
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Phase 1: Load Architecture and Templates
|
||||
1. Read `expertTemplate` - defines YAML structure for Expert agents
|
||||
2. Read `expertArch` - architecture requirements for Expert-level agents
|
||||
3. Read `agentCompilation` - assembly rules for YAML generation
|
||||
4. Read `criticalActions` - validation requirements for critical_actions
|
||||
|
||||
### Phase 2: Load Agent Plan
|
||||
1. Read `agentPlan` containing all collected content from Steps 1-5
|
||||
2. Verify plan contains:
|
||||
- Agent type: "expert"
|
||||
- Sidecar folder name
|
||||
- Persona content
|
||||
- Commands structure
|
||||
- Critical actions (if applicable)
|
||||
|
||||
### Phase 3: Assemble Expert YAML
|
||||
Using expertTemplate as structure:
|
||||
|
||||
```yaml
|
||||
name: '{agent-name}'
|
||||
description: '{short-description}'
|
||||
|
||||
author:
|
||||
name: '{author}'
|
||||
created: '{date}'
|
||||
|
||||
persona: |
|
||||
{multi-line persona content from plan}
|
||||
|
||||
system-context: |
|
||||
{expanded context from plan}
|
||||
|
||||
capabilities:
|
||||
- {capability from plan}
|
||||
- {capability from plan}
|
||||
# ... all capabilities
|
||||
|
||||
critical-actions:
|
||||
- name: '{action-name}'
|
||||
description: '{what it does}'
|
||||
invocation: '{when/how to invoke}'
|
||||
implementation: |
|
||||
{multi-line implementation}
|
||||
output: '{expected-output}'
|
||||
sidecar-folder: '{sidecar-folder-name}'
|
||||
sidecar-files:
|
||||
- '{project-root}/_bmad/_memory/{sidecar-folder}/{file1}.md'
|
||||
- '{project-root}/_bmad/_memory/{sidecar-folder}/{file2}.md'
|
||||
# ... all critical actions referencing sidecar structure
|
||||
|
||||
commands:
|
||||
- name: '{command-name}'
|
||||
description: '{what command does}'
|
||||
steps:
|
||||
- {step 1}
|
||||
- {step 2}
|
||||
# ... all commands from plan
|
||||
|
||||
configuration:
|
||||
temperature: {temperature}
|
||||
max-tokens: {max-tokens}
|
||||
response-format: {format}
|
||||
# ... other configuration from plan
|
||||
|
||||
metadata:
|
||||
sidecar-folder: '{sidecar-folder-name}'
|
||||
sidecar-path: '{project-root}/_bmad/_memory/{sidecar-folder}/'
|
||||
agent-type: 'expert'
|
||||
memory-type: 'persistent'
|
||||
```
|
||||
|
||||
### Phase 4: Create Sidecar Structure
|
||||
|
||||
1. **Create Sidecar Directory** (NEXT TO agent.yaml):
|
||||
- Path: `{agentBuildOutput}/{agent-name}-sidecar/`
|
||||
- Use `mkdir -p` to create full path
|
||||
- Note: This folder gets installed to `_bmad/_memory/` during BMAD installation
|
||||
|
||||
2. **Create Starter Files** (if specified in critical_actions):
|
||||
```bash
|
||||
touch {agentBuildOutput}/{agent-name}-sidecar/{file1}.md
|
||||
touch {agentBuildOutput}/{agent-name}-sidecar/{file2}.md
|
||||
```
|
||||
|
||||
3. **Add README to Sidecar**:
|
||||
```markdown
|
||||
# {sidecar-folder} Sidecar
|
||||
|
||||
This folder stores persistent memory for the **{agent-name}** Expert agent.
|
||||
|
||||
## Purpose
|
||||
{purpose from critical_actions}
|
||||
|
||||
## Files
|
||||
- {file1}.md: {description}
|
||||
- {file2}.md: {description}
|
||||
|
||||
## Runtime Access
|
||||
After BMAD installation, this folder will be accessible at:
|
||||
`{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
|
||||
```
|
||||
|
||||
### Phase 5: Write Agent YAML
|
||||
|
||||
1. Create `agentBuildOutput` directory: `mkdir -p {agentBuildOutput}`
|
||||
2. Write YAML to `agentYamlOutput`
|
||||
3. Confirm write success
|
||||
4. Display file location to user
|
||||
|
||||
### Phase 6: Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#phase-6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
- **USE ONLY**: Content from agentPlan, expertTemplate, expertArch, agentCompilation, criticalActions
|
||||
- **DO NOT ADD**: New capabilities, commands, or actions not in plan
|
||||
- **DO NOT INTERPRET**: Use exact language from plan
|
||||
- **DO NOT SKIP**: Any field in expertTemplate structure
|
||||
- **CRITICAL**: Expert agents MUST have sidecar-folder metadata
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
|
||||
This step produces TWO artifacts:
|
||||
1. **Agent YAML**: Complete expert agent definition at `{agentYamlOutput}`
|
||||
2. **Sidecar Structure**: Folder and files at `{agentBuildOutput}/{agent-name}-sidecar/` (build location, installs to `_bmad/_memory/` during BMAD installation)
|
||||
|
||||
Both must exist before proceeding to validation.
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ Agent YAML file created at expected location
|
||||
✅ Valid YAML syntax (no parse errors)
|
||||
✅ All template fields populated
|
||||
✅ Sidecar folder created at `{agentBuildOutput}/{agent-name}-sidecar/` (build location)
|
||||
✅ Sidecar folder contains starter files from critical_actions
|
||||
✅ critical_actions reference `{project-root}/_bmad/_memory/{sidecar-folder}/` paths
|
||||
✅ metadata.sidecar-folder populated
|
||||
✅ metadata.agent-type = "expert"
|
||||
✅ User validation choice received (one-at-a-time or YOLO)
|
||||
|
||||
## FAILURE MODES
|
||||
|
||||
❌ Missing required template fields
|
||||
❌ Invalid YAML syntax
|
||||
❌ Sidecar folder creation failed
|
||||
❌ critical_actions missing sidecar-folder references
|
||||
❌ agentPlan missing expert-specific content (sidecar-folder name)
|
||||
❌ File write permission errors
|
||||
@@ -1,258 +0,0 @@
|
||||
---
|
||||
name: 'step-06-build-module'
|
||||
description: 'Generate Module agent YAML from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
|
||||
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Template and Architecture (use expert as baseline)
|
||||
expertTemplate: ../templates/expert-agent-template/expert-agent.template.md
|
||||
expertArch: ../data/expert-agent-architecture.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
criticalActions: ../data/critical-actions.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
Assemble the Module agent YAML file from the approved plan, using the expert agent template as the baseline architecture and adding module-specific workflow integration paths and sidecar configuration.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
|
||||
1. **TEMPLATE BASELINE**: Module agents MUST use the expert agent template as their structural foundation - do not create custom templates
|
||||
|
||||
2. **PLAN ADHERENCE**: Extract content from agentPlan exactly as written - no enhancement, interpretation, or extrapolation
|
||||
|
||||
3. **MODULE SPECIFICITY**: Module agents require workflow integration paths and may need sidecar configuration for multi-workflow modules
|
||||
|
||||
4. **OUTPUT VALIDATION**: YAML must be valid, complete, and ready for immediate deployment
|
||||
|
||||
5. **LANGUAGE PRESERVATION**: Maintain any language choice configured in the plan throughout the YAML
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## PREPARATION PHASE
|
||||
|
||||
### 1. Load Expert Template Baseline
|
||||
```
|
||||
Read: expertTemplate
|
||||
Read: expertArch
|
||||
Read: agentCompilation
|
||||
Read: criticalActions
|
||||
```
|
||||
|
||||
**Purpose**: Understand the expert agent structure that serves as the Module agent baseline
|
||||
|
||||
**Validation**: Confirm expert template has all required sections (name, description, persona, instructions, tools, skills, etc.)
|
||||
|
||||
### 2. Load Agent Plan
|
||||
```
|
||||
Read: agentPlan (using dynamic path)
|
||||
```
|
||||
|
||||
**Validation**: Plan contains all mandatory sections:
|
||||
- Agent identity (name, description)
|
||||
- Persona profile
|
||||
- Command structure
|
||||
- Critical actions
|
||||
- Workflow integrations (module-specific)
|
||||
- Language choice (if configured)
|
||||
|
||||
### 3. Verify Output Directory
|
||||
```
|
||||
Bash: mkdir -p {agentBuildOutput}
|
||||
```
|
||||
|
||||
**Purpose**: Ensure output directory exists for the module agent
|
||||
|
||||
## ASSEMBLY PHASE
|
||||
|
||||
### 4. Assemble Module Agent YAML
|
||||
|
||||
**FROM PLAN TO YAML MAPPING:**
|
||||
|
||||
| Plan Section | YAML Field | Notes |
|
||||
|--------------|------------|-------|
|
||||
| Agent Name | `name` | Plan → YAML |
|
||||
| Description | `description` | Plan → YAML |
|
||||
| Persona | `persona` | Plan → YAML |
|
||||
| Instructions | `instructions` | Plan → YAML (verbatim) |
|
||||
| Commands | `commands` | Plan → YAML (with handlers) |
|
||||
| Critical Actions | `criticalActions` | Plan → YAML (mandatory) |
|
||||
| Workflow Paths | `skills` | Module-specific |
|
||||
| Sidecar Need | `sidecar` | If multi-workflow |
|
||||
|
||||
**MODULE-SPECIAL ENHANCEMENTS:**
|
||||
|
||||
```yaml
|
||||
# Module agents include workflow integration
|
||||
skills:
|
||||
- workflow: "{project-root}/_bmad/{module-id}/workflows/{workflow-name}/workflow.md"
|
||||
description: "From plan workflow list"
|
||||
- workflow: "{project-root}/_bmad/{module-id}/workflows/{another-workflow}/workflow.md"
|
||||
description: "From plan workflow list"
|
||||
|
||||
# Optional: Sidecar for complex modules
|
||||
sidecar:
|
||||
enabled: true
|
||||
workflows:
|
||||
- ref: "primary-workflow"
|
||||
type: "primary"
|
||||
- ref: "secondary-workflow"
|
||||
type: "support"
|
||||
```
|
||||
|
||||
**CRITICAL ACTIONS MAPPING:**
|
||||
```
|
||||
For each critical action in plan:
|
||||
1. Identify matching command in YAML
|
||||
2. Add `critical: true` flag
|
||||
3. Ensure handler references agent function
|
||||
```
|
||||
|
||||
### 5. Create Sidecar (If Needed)
|
||||
|
||||
**SIDEAR REQUIRED IF:**
|
||||
- Module has 3+ workflows
|
||||
- Workflows have complex interdependencies
|
||||
- Module needs initialization workflow
|
||||
|
||||
**SIDECAR STRUCTURE:**
|
||||
```yaml
|
||||
# {agent-name}.sidecar.yaml
|
||||
sidecar:
|
||||
module: "{module-id}"
|
||||
initialization:
|
||||
workflow: "workflow-init"
|
||||
required: true
|
||||
workflows:
|
||||
- name: "workflow-name"
|
||||
path: "workflows/{workflow-name}/workflow.md"
|
||||
type: "primary|support|utility"
|
||||
dependencies: []
|
||||
agent:
|
||||
path: "{agent-name}.agent.yaml"
|
||||
```
|
||||
|
||||
**IF SIDEAR NOT NEEDED**: Skip this step
|
||||
|
||||
### 6. Write Module Agent YAML
|
||||
```
|
||||
Write: agentYamlOutput (using dynamic path)
|
||||
Content: Assembled YAML from step 4
|
||||
```
|
||||
|
||||
**Validation Checklist:**
|
||||
- [ ] All plan fields present in YAML
|
||||
- [ ] Workflow paths are valid and correct
|
||||
- [ ] Critical actions flagged
|
||||
- [ ] Sidecar created (if needed) or skipped (if not)
|
||||
- [ ] YAML syntax is valid
|
||||
- [ ] Language choice preserved throughout
|
||||
|
||||
## COMPLETION PHASE
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
**USER RESPONSE HANDLING:**
|
||||
- **Option 1**: Proceed to step-07a-plan-traceability.md with sequential mode
|
||||
- **Option 2**: Proceed to step-07a-plan-traceability.md with yolo mode
|
||||
- **Invalid input**: Re-ask with options
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Reading expert template and architecture
|
||||
- Loading agent plan
|
||||
- Assembling Module agent YAML
|
||||
- Creating sidecar (if needed)
|
||||
- Writing valid YAML output
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Modifying plan content
|
||||
- Creating new template structures
|
||||
- Implementing agent code
|
||||
- Writing workflow files
|
||||
- Testing agent functionality
|
||||
|
||||
**DO NOT:**
|
||||
- Add commands not in plan
|
||||
- Modify persona from plan
|
||||
- Create custom template structures
|
||||
- Skip critical actions mapping
|
||||
- Assume sidecar need - evaluate based on workflow count
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
|
||||
**THIS STEP IS COMPLETE WHEN:**
|
||||
1. Module agent YAML file exists at agentYamlOutput path
|
||||
2. YAML contains all plan content correctly mapped
|
||||
3. Module-specific workflow paths are configured
|
||||
4. Sidecar is created (if needed) or correctly skipped (if not)
|
||||
5. User has chosen review mode (one-at-a-time or YOLO)
|
||||
6. Ready to proceed to step-07a-plan-traceability.md
|
||||
|
||||
**STOP BEFORE:**
|
||||
- Writing workflow implementations
|
||||
- Creating agent code files
|
||||
- Testing agent functionality
|
||||
- Deploying to active system
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
**COMPLETION:**
|
||||
- [ ] Module agent YAML exists with all required fields
|
||||
- [ ] All plan content accurately mapped to YAML
|
||||
- [ ] Workflow integration paths configured correctly
|
||||
- [ ] Critical actions properly flagged
|
||||
- [ ] Sidecar created or correctly skipped
|
||||
- [ ] YAML syntax is valid
|
||||
- [ ] User confirms review mode choice
|
||||
- [ ] Transitions to step-07a-plan-traceability.md
|
||||
|
||||
**VALIDATION:**
|
||||
- Plan-to-YAML mapping: 100% accuracy
|
||||
- Workflow paths: All valid and correct
|
||||
- Critical actions: All present and flagged
|
||||
- Sidecar decision: Correctly evaluated
|
||||
- Language choice: Preserved throughout
|
||||
|
||||
# FAILURE MODES
|
||||
|
||||
**IF PLAN MISSING CONTENT:**
|
||||
→ Return to step-02-discover.md to complete plan
|
||||
|
||||
**IF EXPERT TEMPLATE MISSING:**
|
||||
→ Raise error - template is mandatory baseline
|
||||
|
||||
**IF YAML SYNTAX ERROR:**
|
||||
→ Fix and retry write operation
|
||||
|
||||
**IF WORKFLOW PATHS INVALID:**
|
||||
→ Flag for review in traceability step
|
||||
|
||||
**IF USER ASKS FOR MODIFICATIONS:**
|
||||
→ Return to appropriate planning step (03-persona, 04-commands, or 05-name)
|
||||
@@ -1,249 +0,0 @@
|
||||
---
|
||||
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 `unitary: true`
|
||||
3. **Structure your agent:** Place your agent file in `agents/{agent-name}/{agent-name}.agent.yaml`
|
||||
4. **Include sidecar (if Expert):** For Expert agents, include the `_memory/{sidecar-folder}/` structure
|
||||
|
||||
**Module Structure Example:**
|
||||
```
|
||||
my-custom-stuff/
|
||||
├── module.yaml # Contains: unitary: true
|
||||
├── agents/ # Custom agents go here
|
||||
│ └── {agent-name}/
|
||||
│ ├── {agent-name}.agent.yaml
|
||||
│ └── _memory/ # Expert agents only
|
||||
│ └── {sidecar-folder}/
|
||||
│ ├── 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 `module.yaml` containing `unitary: true`.
|
||||
See: {installationDocs}
|
||||
|
||||
### Quick Start
|
||||
|
||||
1. Create a module folder
|
||||
2. Add module.yaml with `unitary: true`
|
||||
3. Place agent in `agents/{agent-name}/` structure
|
||||
4. Include sidecar folder for Expert agents
|
||||
5. 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.
|
||||
Reference in New Issue
Block a user