Initial commit: Brachnha Insight project setup

- Next.js 14+ with App Router and TypeScript
- Tailwind CSS and ShadCN UI styling
- Zustand state management
- Dexie.js for IndexedDB (local-first data)
- Auth.js v5 for authentication
- BMAD framework integration

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Max
2026-01-26 12:28:43 +07:00
commit 3fbbb1a93b
812 changed files with 150531 additions and 0 deletions

View File

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

View File

@@ -0,0 +1,170 @@
---
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

View File

@@ -0,0 +1,296 @@
---
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

View File

@@ -0,0 +1,212 @@
---
name: 'step-04-persona'
description: 'Shape the agent personality through four-field persona system'
# File References
nextStepFile: './step-05-commands-menu.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
personaProperties: ../data/persona-properties.md
principlesCrafting: ../data/principles-crafting.md
communicationPresets: ../data/communication-presets.csv
# Example Personas (for reference)
simpleExample: ../data/reference/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

View File

@@ -0,0 +1,178 @@
---
name: 'step-05-commands-menu'
description: 'Build capabilities and command structure'
# File References
nextStepFile: './step-06-activation.md'
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
agentMenuPatterns: ../data/agent-menu-patterns.md
# Example Menus (for reference)
simpleExample: ../data/reference/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

View File

@@ -0,0 +1,279 @@
---
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

View File

@@ -0,0 +1,187 @@
---
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

View File

@@ -0,0 +1,201 @@
---
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

View File

@@ -0,0 +1,258 @@
---
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)

View 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.