Initial commit: BMAD framework + Story 1.1 Component Trait Definition
Features: - BMAD (Build Modular AI-driven Development) framework setup - BMM, BMB, CIS, Core modules configured - Story 1.1: Component trait with error handling - Workspace Cargo.toml with components crate - 31 tests passing (19 unit + 12 doc tests) Technical: - Component trait with compute_residuals, jacobian_entries, n_equations - ComponentError enum with thiserror - JacobianBuilder for sparse matrix construction - Object-safe trait supporting Box<dyn Component> - Comprehensive documentation and examples
This commit is contained in:
Sepehr
128
_bmad/bmb/workflows/agent/steps-c/step-01-brainstorm.md
Normal file
128
_bmad/bmb/workflows/agent/steps-c/step-01-brainstorm.md
Normal 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.
|
||||
170
_bmad/bmb/workflows/agent/steps-c/step-02-discovery.md
Normal file
170
_bmad/bmb/workflows/agent/steps-c/step-02-discovery.md
Normal 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
|
||||
308
_bmad/bmb/workflows/agent/steps-c/step-03-sidecar-metadata.md
Normal file
308
_bmad/bmb/workflows/agent/steps-c/step-03-sidecar-metadata.md
Normal 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
|
||||
212
_bmad/bmb/workflows/agent/steps-c/step-04-persona.md
Normal file
212
_bmad/bmb/workflows/agent/steps-c/step-04-persona.md
Normal 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
|
||||
178
_bmad/bmb/workflows/agent/steps-c/step-05-commands-menu.md
Normal file
178
_bmad/bmb/workflows/agent/steps-c/step-05-commands-menu.md
Normal 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
|
||||
277
_bmad/bmb/workflows/agent/steps-c/step-06-activation.md
Normal file
277
_bmad/bmb/workflows/agent/steps-c/step-06-activation.md
Normal 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
|
||||
315
_bmad/bmb/workflows/agent/steps-c/step-07-build-agent.md
Normal file
315
_bmad/bmb/workflows/agent/steps-c/step-07-build-agent.md
Normal 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
|
||||
249
_bmad/bmb/workflows/agent/steps-c/step-08-celebrate.md
Normal file
249
_bmad/bmb/workflows/agent/steps-c/step-08-celebrate.md
Normal file
@@ -0,0 +1,249 @@
|
||||
---
|
||||
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