mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-01-30 04:32:02 +00:00
agent create workflow overhaul to use data files efficiently. updated and created separate user guides for the create agent workflow along with general concept docs of what an agent and workflow are in regards to0 bmad generally.
This commit is contained in:
Brian Madison
93
docs/bmad-core-concepts/agents.md
Normal file
93
docs/bmad-core-concepts/agents.md
Normal file
@@ -0,0 +1,93 @@
|
||||
# Agents
|
||||
|
||||
Agents are AI assistants that help you accomplish tasks. Each agent has a unique personality, specialized capabilities, and an interactive menu.
|
||||
|
||||
## Agent Types
|
||||
|
||||
BMAD has two primary agent types, designed for different use cases:
|
||||
|
||||
### Simple Agents
|
||||
|
||||
**Self-contained, focused, ready to use.**
|
||||
|
||||
Simple agents are complete in a single file. They excel at well-defined tasks and require minimal setup.
|
||||
|
||||
**Best for:**
|
||||
- Single-purpose assistants (code review, documentation, commit messages)
|
||||
- Quick deployment
|
||||
- Projects that don't require persistent memory
|
||||
- Getting started fast
|
||||
|
||||
**Example:** A commit message agent that reads your git diff and generates conventional commits.
|
||||
|
||||
### Expert Agents
|
||||
|
||||
**Powerful, memory-equipped, domain specialists.**
|
||||
|
||||
Expert agents have a **sidecar** - a companion folder containing additional instructions, workflows, and memory files. They remember context across sessions and handle complex, multi-step tasks.
|
||||
|
||||
**Best for:**
|
||||
- Domain specialists (security architect, game designer, product manager)
|
||||
- Tasks requiring persistent memory
|
||||
- Complex workflows with multiple stages
|
||||
- Projects that grow over time
|
||||
|
||||
**Example:** A game architect that remembers your design decisions, maintains consistency across sprints, and coordinates with other specialists.
|
||||
|
||||
## Key Differences
|
||||
|
||||
| Feature | Simple | Expert |
|
||||
| ---------------- | -------------- | -------------------------- |
|
||||
| **Files** | Single file | Agent + sidecar folder |
|
||||
| **Memory** | Session only | Persistent across sessions |
|
||||
| **Capabilities** | Focused scope | Multi-domain, extensible |
|
||||
| **Setup** | Zero config | Sidecar initialization |
|
||||
| **Best Use** | Specific tasks | Ongoing projects |
|
||||
|
||||
## Agent Components
|
||||
|
||||
All agents share these building blocks:
|
||||
|
||||
### Persona
|
||||
- **Role** - What the agent does (expertise domain)
|
||||
- **Identity** - Who the agent is (personality, character)
|
||||
- **Communication Style** - How the agent speaks (tone, voice)
|
||||
- **Principles** - Why the agent acts (values, decision framework)
|
||||
|
||||
### Capabilities
|
||||
- Skills, tools, and knowledge the agent can apply
|
||||
- Mapped to specific menu commands
|
||||
|
||||
### Menu
|
||||
- Interactive command list
|
||||
- Triggers, descriptions, and handlers
|
||||
- Auto-includes help and exit options
|
||||
|
||||
### Critical Actions (optional)
|
||||
- Instructions that execute before the agent starts
|
||||
- Enable autonomous behaviors (e.g., "check git status before changes")
|
||||
|
||||
## Which Should You Use?
|
||||
|
||||
**Choose Simple when:**
|
||||
- You need a task done quickly and reliably
|
||||
- The scope is well-defined and won't change much
|
||||
- You don't need the agent to remember things between sessions
|
||||
|
||||
**Choose Expert when:**
|
||||
- You're building something complex over time
|
||||
- The agent needs to maintain context (project history, decisions)
|
||||
- You want the agent to coordinate workflows or other agents
|
||||
- Domain expertise requires specialized knowledge bases
|
||||
|
||||
## Creating Custom Agents
|
||||
|
||||
BMAD provides the **BMAD Builder (BMB)** module for creating your own agents. See the [Agent Creation Guide](../modules/bmb-bmad-builder/agent-creation-guide.md) for step-by-step instructions.
|
||||
|
||||
## Customizing Existing Agents
|
||||
|
||||
You can modify any agent's behavior without editing core files. See [BMAD Customization](./bmad-customization/) for details. It is critical to never modify an installed agents .md file directly and follow the customization process, this way future updates to the agent or module its part of will continue to be updated and recompiled with the installer tool, and your customizations will still be retained.
|
||||
|
||||
---
|
||||
|
||||
**Next:** Learn about [Workflows](./workflows.md) to see how agents accomplish complex tasks.
|
||||
@@ -203,6 +203,8 @@ memories:
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **[BMM Agents Guide](./modules/bmm/agents-guide)** - Learn about the BMad Method agents
|
||||
- **[BMB Create Agent Workflow](./modules/bmb/agents/index)** - Build completely custom agents
|
||||
- **[BMM Complete Documentation](./modules/bmm/index)** - Full BMad Method reference
|
||||
- **[Learn about Agents](../agents.md)** - Understand Simple vs Expert agents
|
||||
- **[Agent Creation Guide](../../modules/bmb-bmad-builder/agent-creation-guide.md)** - Build completely custom agents
|
||||
- **[BMM Complete Documentation](../../modules/bmm-bmad-method/index)** - Full BMad Method reference
|
||||
|
||||
[← Back to Customization](./index.md)
|
||||
26
docs/bmad-core-concepts/bmad-customization/index.md
Normal file
26
docs/bmad-core-concepts/bmad-customization/index.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# BMAD Customization
|
||||
|
||||
Personalize agents and workflows to match your needs.
|
||||
|
||||
## Guides
|
||||
|
||||
| Guide | Description |
|
||||
|-------|-------------|
|
||||
| **[Agent Customization](./agents.md)** | Modify agent behavior without editing core files |
|
||||
| **[Workflow Customization](./workflows.md)** | Customize and optimize workflows |
|
||||
|
||||
## Overview
|
||||
|
||||
BMAD provides two main customization approaches:
|
||||
|
||||
### Agent Customization
|
||||
Modify any agent's persona, name, capabilities, or menu items using `.customize.yaml` files in `_bmad/_config/agents/`. Your customizations persist through updates.
|
||||
|
||||
### Workflow Customization
|
||||
Replace or extend workflow steps to create tailored processes. (Coming soon)
|
||||
|
||||
---
|
||||
|
||||
**Next:** Read the [Agent Customization Guide](./agents.md) to start personalizing your agents.
|
||||
|
||||
[← Back to Core Concepts](../index.md)
|
||||
30
docs/bmad-core-concepts/bmad-customization/workflows.md
Normal file
30
docs/bmad-core-concepts/bmad-customization/workflows.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Workflow Customization Guide
|
||||
|
||||
Customize and optimize workflows with step replacement and hooks.
|
||||
|
||||
## Status
|
||||
|
||||
> **Coming Soon:** Workflow customization is an upcoming capability. This guide will be updated when the feature is available.
|
||||
|
||||
## What to Expect
|
||||
|
||||
Workflow customization will allow you to:
|
||||
|
||||
- **Replace Steps** - Swap out specific workflow steps with custom implementations
|
||||
- **Add Hooks** - Inject custom behavior before/after workflow steps
|
||||
- **Extend Workflows** - Create new workflows based on existing ones
|
||||
- **Override Behavior** - Customize workflow logic for your project's needs
|
||||
|
||||
## For Now
|
||||
|
||||
While workflow customization is in development, you can:
|
||||
|
||||
- **Create Custom Workflows** - Use the BMAD Builder to create entirely new workflows
|
||||
- **Customize Agents** - Modify agent behavior using [Agent Customization](./agents.md)
|
||||
- **Provide Feedback** - Share your workflow customization needs with the community
|
||||
|
||||
---
|
||||
|
||||
**In the meantime:** Learn how to [create custom workflows](../../modules/bmb-bmad-builder/index) from scratch.
|
||||
|
||||
[← Back to Customization](./index.md)
|
||||
37
docs/bmad-core-concepts/index.md
Normal file
37
docs/bmad-core-concepts/index.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# BMAD Core Concepts
|
||||
|
||||
Understanding the fundamental building blocks of the BMAD Method.
|
||||
|
||||
## The Essentials
|
||||
|
||||
| Concept | Description | Guide |
|
||||
|---------|-------------|-------|
|
||||
| **Agents** | AI assistants with personas, capabilities, and menus | [Agents Guide](./agents.md) |
|
||||
| **Workflows** | Structured processes for achieving specific outcomes | [Workflows Guide](./workflows.md) |
|
||||
| **Modules** | Packaged collections of agents and workflows | [Modules Guide](./modules.md) |
|
||||
|
||||
## Getting Started
|
||||
|
||||
### New to BMAD?
|
||||
Start here to understand what BMAD is and how it works:
|
||||
|
||||
1. **[Agents Guide](./agents.md)** - Learn about Simple and Expert agents
|
||||
2. **[Workflows Guide](./workflows.md)** - Understand how workflows orchestrate tasks
|
||||
3. **[Modules Guide](./modules.md)** - See how modules organize functionality
|
||||
|
||||
### Installing BMAD
|
||||
|
||||
- **[Installation Guide](./installing/)** - Set up BMAD in your project
|
||||
- **[Upgrading from v4](./installing/upgrading.md)** - Migrate from earlier versions
|
||||
|
||||
### Configuration
|
||||
|
||||
- **[BMAD Customization](./bmad-customization/)** - Personalize agents and workflows
|
||||
|
||||
### Advanced
|
||||
|
||||
- **[Web Bundles](./web-bundles/)** - Use BMAD in Gemini Gems and Custom GPTs
|
||||
|
||||
---
|
||||
|
||||
**Next:** Read the [Agents Guide](./agents.md) to understand the core building block of BMAD.
|
||||
@@ -1,5 +1,13 @@
|
||||
# Installation
|
||||
|
||||
Get BMAD up and running in your project.
|
||||
|
||||
## Upgrading?
|
||||
|
||||
If you're upgrading from v4, see the [Upgrade Guide](./upgrading.md).
|
||||
|
||||
---
|
||||
|
||||
## Quick Install
|
||||
|
||||
```bash
|
||||
@@ -52,8 +60,9 @@ your-project/
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Read the [Quick Start Guide](../modules/bmm/quick-start.md)** to build your first feature
|
||||
2. **Explore [Workflows](../modules/bmm/workflows-planning.md)** to understand the methodology
|
||||
1. **Read the [Quick Start Guide](../../modules/bmm-bmad-method/quick-start)** to build your first feature
|
||||
2. **Explore [Workflows](../../modules/bmm-bmad-method/index#-workflow-guides)** to understand the methodology
|
||||
3. **Learn about [Agents](../agents.md)** to understand BMAD's core building blocks
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
@@ -120,7 +120,7 @@ persona:
|
||||
- Always upbeat and adventurous
|
||||
```
|
||||
|
||||
There is a lot more that is possible with agent customization, which is covered in detail in the [Agent Customization Guide](bmad-customization/agent-customization-guide.md)
|
||||
There is a lot more that is possible with agent customization, which is covered in detail in the [Agent Customization Guide](../bmad-customization/agents.md)
|
||||
|
||||
CRITICAL NOTE: After you modify the customization file, you need to run the npx installer against your installed location, and choose the option to rebuild all agents, or just do a quick update again. This always builds agents fresh and applies customizations.
|
||||
|
||||
76
docs/bmad-core-concepts/modules.md
Normal file
76
docs/bmad-core-concepts/modules.md
Normal file
@@ -0,0 +1,76 @@
|
||||
# Modules
|
||||
|
||||
Modules are organized collections of agents and workflows that solve specific problems or address particular domains.
|
||||
|
||||
## What is a Module?
|
||||
|
||||
A module is a self-contained package that includes:
|
||||
|
||||
- **Agents** - Specialized AI assistants
|
||||
- **Workflows** - Step-by-step processes
|
||||
- **Configuration** - Module-specific settings
|
||||
- **Documentation** - Usage guides and reference
|
||||
|
||||
## Official Modules
|
||||
|
||||
### Core Module
|
||||
Always installed, provides shared functionality:
|
||||
- Global configuration
|
||||
- Core workflows (Party Mode, Advanced Elicitation, Brainstorming)
|
||||
- Common tasks (document indexing, sharding, review)
|
||||
|
||||
### BMAD Method (BMM)
|
||||
Software and game development:
|
||||
- Project planning workflows
|
||||
- Implementation agents (Dev, PM, QA, Scrum Master)
|
||||
- Testing and architecture guidance
|
||||
|
||||
### BMAD Builder (BMB)
|
||||
Create custom solutions:
|
||||
- Agent creation workflows
|
||||
- Workflow authoring tools
|
||||
- Module scaffolding
|
||||
|
||||
### Creative Intelligence Suite (CIS)
|
||||
Innovation and creativity:
|
||||
- Creative thinking techniques
|
||||
- Innovation strategy workflows
|
||||
- Storytelling and ideation
|
||||
|
||||
### BMAD Game Dev (BMGD)
|
||||
Game development specialization:
|
||||
- Game design workflows
|
||||
- Narrative development
|
||||
- Performance testing frameworks
|
||||
|
||||
## Module Structure
|
||||
|
||||
Installed modules follow this structure:
|
||||
|
||||
```
|
||||
_bmad/
|
||||
├── core/ # Always present
|
||||
├── bmm/ # BMAD Method (if installed)
|
||||
├── bmb/ # BMAD Builder (if installed)
|
||||
├── cis/ # Creative Intelligence (if installed)
|
||||
└── bmgd/ # Game Dev (if installed)
|
||||
```
|
||||
|
||||
## Custom Modules
|
||||
|
||||
You can create your own modules containing:
|
||||
- Custom agents for your domain
|
||||
- Organizational workflows
|
||||
- Team-specific configurations
|
||||
|
||||
Custom modules are installed the same way as official modules.
|
||||
|
||||
## Installing Modules
|
||||
|
||||
During BMAD installation, you choose which modules to install. You can also add or remove modules later by re-running the installer.
|
||||
|
||||
See [Installation Guide](./installing/) for details.
|
||||
|
||||
---
|
||||
|
||||
**Next:** Read the [Installation Guide](./installing/) to set up BMAD with the modules you need.
|
||||
34
docs/bmad-core-concepts/web-bundles/index.md
Normal file
34
docs/bmad-core-concepts/web-bundles/index.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Web Bundles
|
||||
|
||||
Use BMAD agents in Gemini Gems and Custom GPTs.
|
||||
|
||||
## Status
|
||||
|
||||
> **Note:** The Web Bundling Feature is being rebuilt from the ground up. Current v6 bundles may be incomplete or missing functionality.
|
||||
|
||||
## What Are Web Bundles?
|
||||
|
||||
Web bundles package BMad agents as self-contained files that work in Gemini Gems and Custom GPTs. Everything the agent needs - instructions, workflows, dependencies - is bundled into a single file for easy upload.
|
||||
|
||||
### What's Included
|
||||
|
||||
- Complete agent persona and instructions
|
||||
- All workflows and dependencies
|
||||
- Interactive menu system
|
||||
- Party mode for multi-agent collaboration
|
||||
- No external files required
|
||||
|
||||
### Use Cases
|
||||
|
||||
**Perfect for:**
|
||||
- Uploading a single file to a Gemini GEM or Custom GPT
|
||||
- Using BMAD Method from the Web
|
||||
- Cost savings (generally lower cost than local usage)
|
||||
- Quick sharing of agent configurations
|
||||
|
||||
**Trade-offs:**
|
||||
- Some quality reduction vs local usage
|
||||
- Less convenient than full local installation
|
||||
- Limited to agent capabilities (no workflow file access)
|
||||
|
||||
[← Back to Core Concepts](../index.md)
|
||||
89
docs/bmad-core-concepts/workflows.md
Normal file
89
docs/bmad-core-concepts/workflows.md
Normal file
@@ -0,0 +1,89 @@
|
||||
# Workflows
|
||||
|
||||
Workflows are structured processes that guide agents through complex tasks. Think of them as recipes that ensure consistent, high-quality outcomes.
|
||||
|
||||
## What is a Workflow?
|
||||
|
||||
A workflow is a step-by-step process that agents follow to accomplish specific objectives. A workflow can be a single file if small enough, but more than likely is comprized of a very small workflow or skill definition file with multiple steps and data files that are loaded as needed on demand. Each step file:
|
||||
|
||||
- Defines a clear goal
|
||||
- Provides instructions for the agent
|
||||
- May include decision points or user interactions
|
||||
- Produces specific outputs
|
||||
- Progressively at a specific point can load the next proper step.
|
||||
|
||||
## How Workflows Work
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ Step 1 │ → │ Step 2 │ → │ Step 3 │ → │ Complete │
|
||||
│ Discover │ │ Define │ │ Build │ │ Output │
|
||||
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
|
||||
```
|
||||
|
||||
**Key characteristics:**
|
||||
- **Progressive** - Each step builds on the previous
|
||||
- **Interactive** - Workflows can pause for user input
|
||||
- **Reusable** - The same workflow produces consistent results
|
||||
- **Composable** - Workflow steps can call other workflow steps, or whole other workflows!
|
||||
- **LLM Reinforcement** - Some rules or info is repeated in each step file ensuring certain rules are always top of agent mind, even during context heavy processes or very long workflows!
|
||||
|
||||
## Workflow Types
|
||||
|
||||
### Planning Workflows
|
||||
|
||||
Generate project artifacts like requirements, architecture, and task breakdowns.
|
||||
|
||||
**Examples:** Brief creation, PRD authoring, architecture design, sprint planning
|
||||
|
||||
### Execution Workflows
|
||||
|
||||
Guide implementation of specific tasks or features.
|
||||
|
||||
**Examples:** Code implementation, code review, testing, deployment
|
||||
|
||||
### Support Workflows
|
||||
|
||||
Handle cross-cutting concerns and creative processes.
|
||||
|
||||
**Examples:** Brainstorming, retrospectives, root cause analysis
|
||||
|
||||
## Progressive Disclosure
|
||||
|
||||
BMAD workflows use **progressive disclosure** - each step only knows about its immediate next step and what it is currently meant to do. This:
|
||||
|
||||
- Reduces cognitive load on the AI
|
||||
- Ensures each step gets full attention
|
||||
- Allows for conditional routing based on previous outcomes
|
||||
- Makes workflows easier to debug and modify
|
||||
|
||||
## Menu-Driven Interaction
|
||||
|
||||
Most workflows use interactive menus with standard options:
|
||||
|
||||
| Option | Purpose |
|
||||
| ---------------- | -------------------------------------------------- |
|
||||
| **[A] Advanced** | Invoke deeper reasoning techniques |
|
||||
| **[P] Party** | Get multiple agent perspectives |
|
||||
| **[C] Continue** | Proceed to next step after all writes are complete |
|
||||
|
||||
## Workflow Files
|
||||
|
||||
Workflows are markdown files with structured frontmatter - this front matter also allows them to easily work as skills and also slash command loaded:
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: 'my-workflow'
|
||||
description: 'What this workflow does and when it should be used or loaded automatically (or call out if it should be requested to run explicitly by the user)'
|
||||
---
|
||||
```
|
||||
|
||||
The content in the workflow file is very minimal, sets up the reinforcement of the agent persona and reminder that it is a facilitator working with a user, lays out rules of processing steps only when told to do a specific step, loads all config file variables needed by the workflow, and then routes to step 1. No other info about other steps should be in this workflow file. Keeping it as small and lean as possible help in compilation as a skill, as overall size of the skill main file (workflow.md) is critical to keep small.
|
||||
|
||||
## Creating Custom Workflows
|
||||
|
||||
The **BMAD Builder (BMB)** module includes workflows for creating custom workflows. See [BMB Documentation](../modules/bmb-bmad-builder/) for details.
|
||||
|
||||
---
|
||||
|
||||
**Next:** Learn about [Modules](./modules.md) to see how agents and workflows are organized.
|
||||
@@ -1,3 +0,0 @@
|
||||
# Workflow Customization Guide
|
||||
|
||||
Coming Soon...
|
||||
111
docs/index.md
111
docs/index.md
@@ -1,91 +1,95 @@
|
||||
# BMad Documentation Index
|
||||
# BMAD Documentation
|
||||
|
||||
## Core Documentation
|
||||
Complete documentation for the BMAD Method.
|
||||
|
||||
### Project-Level Docs (Root)
|
||||
## Getting Started
|
||||
|
||||
- **[README.md](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/README.md)** - Main project overview, feature summary, and module introductions
|
||||
- **[CONTRIBUTING.md](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/CONTRIBUTING.md)** - How to contribute, pull request guidelines, code style
|
||||
- **[CHANGELOG.md](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/CHANGELOG.md)** - Version history and breaking changes
|
||||
### New to BMAD?
|
||||
Start with the core concepts to understand how BMAD works:
|
||||
|
||||
### Installation & Setup
|
||||
- **[Core Concepts](./bmad-core-concepts/)** - Agents, workflows, and modules explained
|
||||
- **[Installation Guide](./bmad-core-concepts/installing/)** - Set up BMAD in your project
|
||||
- **[Quick Start Guide](./modules/bmm-bmad-method/quick-start)** - Build your first feature
|
||||
|
||||
- **[Quick Installation](./installing-bmad.md)** - Add BMad official and custom modules to a project folder.
|
||||
- **[v4 to v6 Upgrade Guide](./v4-to-v6-upgrade.md)** - Migration path for v4 users
|
||||
- **[Document Sharding Guide](modules/core/document-sharding-guide.md)** - Split large documents
|
||||
- **[Bundle Distribution Setup](../tools/docs/BUNDLE_DISTRIBUTION_SETUP.md)** - (temporarily non-functional) Maintainer guide for bundle auto-publishing
|
||||
### Upgrading from v4?
|
||||
- **[v4 to v6 Upgrade Guide](./bmad-core-concepts/installing/upgrading.md)** - Migration path for v4 users
|
||||
|
||||
---
|
||||
|
||||
## Module Documentation
|
||||
|
||||
### Core Module Global Entities
|
||||
|
||||
- **[Core Module Index](./modules/core/index)** — Shared functionality available to all modules
|
||||
- [Global Core Config](./modules/core/global-core-config.md) — Inheritable configuration impacting all modules and custom content
|
||||
- [Core Workflows](./modules/core/core-workflows.md) — Domain-agnostic workflows usable by any module
|
||||
- [Party Mode](./modules/core/party-mode.md) — Multi-agent conversation orchestration
|
||||
- [Brainstorming](./modules/core/brainstorming.md) — Structured creative sessions with 60+ techniques
|
||||
- [Advanced Elicitation](./modules/core/advanced-elicitation.md) — LLM rethinking with 50+ reasoning methods
|
||||
- [Core Tasks](./modules/core/core-tasks.md) — Common tasks available across modules
|
||||
- [Index Docs](./modules/core/core-tasks.md#index-docs) — Generate directory index files
|
||||
- [Adversarial Review](./modules/core/core-tasks.md#adversarial-review-general) — Critical content review
|
||||
- [Shard Document](./modules/core/core-tasks.md#shard-document) — Split large documents into sections
|
||||
|
||||
### BMad Method (BMM) - Software & Game Development
|
||||
### BMAD Method (BMM) - Software & Game Development
|
||||
|
||||
The flagship module for agile AI-driven development.
|
||||
|
||||
- **[BMM Module Index](./modules/bmm-bmad-method/index)** - Module overview, agents, and complete documentation index
|
||||
- [Quick Start Guide](./modules/bmm-bmad-method/quick-start) - Step-by-step guide to building your first project
|
||||
- **[BMM Module Index](./modules/bmm-bmad-method/index)** - Module overview, agents, and documentation
|
||||
- [Quick Start Guide](./modules/bmm-bmad-method/quick-start) - Step-by-step guide
|
||||
- [Quick Spec Flow](./modules/bmm-bmad-method/quick-spec-flow) - Rapid Level 0-1 development
|
||||
- [Brownfield Guide](./modules/bmm-bmad-method/brownfield-guide) - Working with existing codebases
|
||||
- **[BMM Workflows Guide](./modules/bmm-bmad-method/index#-workflow-guides)** - **ESSENTIAL READING**
|
||||
- **[Test Architect Guide](./modules/bmm-bmad-method/test-architecture)** - Testing strategy and quality assurance
|
||||
- **[BMM Workflows Guide](./modules/bmm-bmad-method/index#-workflow-guides)** - Essential reading
|
||||
|
||||
### BMad Builder (BMB) - Create Custom Solutions
|
||||
### BMAD Builder (BMB) - Create Custom Solutions
|
||||
|
||||
Build your own agents, workflows, and modules.
|
||||
|
||||
- **[BMB Module Overview](./modules/bmb-bmad-builder/index)** - Module overview and capabilities
|
||||
- **[Custom Content Guide](./modules/bmb-bmad-builder/custom-content)** - Design custom agents, workflows, and modules
|
||||
- **[How to Install Custom Agents, Workflows and Modules](./modules/bmb-bmad-builder/custom-content-installation.md)** - Share and Install Custom Creations
|
||||
- **[Agent Creation Guide](./modules/bmb-bmad-builder/agent-creation-guide.md)** - Create custom agents
|
||||
- **[Custom Content Installation](./modules/bmb-bmad-builder/custom-content-installation.md)** - Share and install custom creations
|
||||
|
||||
### Creative Intelligence Suite (CIS) - Innovation & Creativity
|
||||
|
||||
- **[CIS Docs](./modules/cis-creative-intelligence-suite/index.md)**
|
||||
- **[CIS Documentation](./modules/cis-creative-intelligence-suite/index)**
|
||||
|
||||
#### Bmad Game Dev (BMGD)
|
||||
### BMAD Game Dev (BMGD)
|
||||
|
||||
- [Main Game Dev Module Docs Index](./modules/bmgd-bmad-game-dev/index.md)
|
||||
- **[BMGD Documentation](./modules/bmgd-bmad-game-dev/index)** - Game development workflows
|
||||
|
||||
AI-powered creative thinking and brainstorming.
|
||||
---
|
||||
|
||||
- **[CIS Module README](./modules/cis-creative-intelligence-suite/index)** - Module overview and workflows
|
||||
## Core Module
|
||||
|
||||
### Global Core Entities
|
||||
|
||||
- **[Core Module Index](./modules/core/index)** - Shared functionality available to all modules
|
||||
- [Global Core Config](./modules/core/global-core-config.md) - Inheritable configuration
|
||||
- [Core Workflows](./modules/core/core-workflows.md) - Domain-agnostic workflows
|
||||
- [Party Mode](./modules/core/party-mode.md) - Multi-agent conversations
|
||||
- [Brainstorming](./modules/core/brainstorming.md) - Structured creative sessions
|
||||
- [Advanced Elicitation](./modules/core/advanced-elicitation.md) - LLM reasoning techniques
|
||||
- [Core Tasks](./modules/core/core-tasks.md) - Common tasks across modules
|
||||
|
||||
---
|
||||
|
||||
## Advanced Topics
|
||||
|
||||
### Custom Agents, Workflow and Modules
|
||||
- **[Custom Content Installation](modules/bmb-bmad-builder/custom-content-installation.md)** - Install and personalize agents, workflows and modules with the default bmad-method installer!
|
||||
- [Agent Customization Guide](./bmad-customization/agent-customization-guide.md) - Customize agent behavior and responses
|
||||
- [Workflow Customization Guide](./bmad-customization/workflow-customization-guide.md) - Customize and Optimize workflows with step replacement and hooks (Capability Coming Soon)
|
||||
### Customization
|
||||
|
||||
- **[BMAD Customization](./bmad-core-concepts/bmad-customization/)** - Modify agents and workflows
|
||||
|
||||
### Platform Guides
|
||||
|
||||
- **[Web Bundles](./bmad-core-concepts/web-bundles/)** - Use BMAD in Gemini Gems and Custom GPTs
|
||||
|
||||
---
|
||||
|
||||
## Recommended Reading Paths
|
||||
|
||||
### Path 1: Brand New to BMad (Software Project)
|
||||
### Path 1: Brand New to BMAD (Software Project)
|
||||
|
||||
1. [README.md](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/README.md) - Understand the vision
|
||||
2. [Quick Start Guide](./modules/bmm-bmad-method/quick-start) - Get hands-on
|
||||
3. [BMM Module README](./modules/bmm-bmad-method/) - Understand agents
|
||||
1. [Core Concepts](./bmad-core-concepts/) - Understand agents and workflows
|
||||
2. [Installation Guide](./bmad-core-concepts/installing/) - Set up BMAD
|
||||
3. [Quick Start Guide](./modules/bmm-bmad-method/quick-start) - Get hands-on
|
||||
4. [BMM Workflows Guide](./modules/bmm-bmad-method/index#-workflow-guides) - Master the methodology
|
||||
|
||||
### Path 2: Game Development Project
|
||||
|
||||
1. [README.md](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/README.md) - Understand the vision
|
||||
2. [Quick Start Guide](./modules/bmm-bmad-method/quick-start) - Get hands-on
|
||||
1. [Core Concepts](./bmad-core-concepts/) - Understand agents and workflows
|
||||
2. [Installation Guide](./bmad-core-concepts/installing/) - Set up BMAD
|
||||
3. [BMGD Workflows Guide](./modules/bmgd-bmad-game-dev/workflows-guide) - Game-specific workflows
|
||||
|
||||
### Path 3: Upgrading from v4
|
||||
|
||||
1. [v4 to v6 Upgrade Guide](./v4-to-v6-upgrade.md) - Understand what changed
|
||||
1. [v4 to v6 Upgrade Guide](./bmad-core-concepts/installing/upgrading.md) - Understand what changed
|
||||
2. [Quick Start Guide](./modules/bmm-bmad-method/quick-start) - Reorient yourself
|
||||
3. [BMM Workflows Guide](./modules/bmm-bmad-method/index#-workflow-guides) - Learn new v6 workflows
|
||||
|
||||
@@ -95,14 +99,13 @@ AI-powered creative thinking and brainstorming.
|
||||
2. [Quick Start Guide](./modules/bmm-bmad-method/quick-start) - Follow the process
|
||||
3. [BMM Workflows Guide](./modules/bmm-bmad-method/index#-workflow-guides) - Master the methodology
|
||||
|
||||
### Path 5: Building Custom Solutions
|
||||
### Path 5: Building Custom Agents
|
||||
|
||||
1. [BMB Module Overview](./modules/bmb-bmad-builder/index) - Understand capabilities
|
||||
2. [BMB Custom Content Types](./modules/bmb-bmad-builder/custom-content.md) - Understand the different types and whats possible
|
||||
3. [BMB Content Installation](./modules/bmb-bmad-builder/custom-content-installation.md) - How to bundle install use and share
|
||||
4. More Docs coming soon....
|
||||
1. [Core Concepts: Agents](./bmad-core-concepts/agents.md) - Understand Simple vs Expert
|
||||
2. [Agent Creation Guide](./modules/bmb-bmad-builder/agent-creation-guide.md) - Build your first agent
|
||||
3. [Agent Architecture](./modules/bmb-bmad-builder/index) - Deep technical details
|
||||
|
||||
### Path 6: Contributing to BMad
|
||||
### Path 6: Contributing to BMAD
|
||||
|
||||
1. [CONTRIBUTING.md](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/CONTRIBUTING.md) - Contribution guidelines
|
||||
2. Relevant module README - Understand the area you're contributing to
|
||||
|
||||
166
docs/modules/bmb-bmad-builder/agent-creation-guide.md
Normal file
166
docs/modules/bmb-bmad-builder/agent-creation-guide.md
Normal file
@@ -0,0 +1,166 @@
|
||||
# Agent Creation Guide
|
||||
|
||||
Create your own custom agents using the BMAD Builder workflow.
|
||||
|
||||
## Overview
|
||||
|
||||
The BMAD Builder (BMB) module provides an interactive workflow that guides you through creating a custom agent from concept to completion. You define the agent's purpose, personality, capabilities, and menu - then the workflow generates a complete, ready-to-use agent file.
|
||||
|
||||
## Before You Start
|
||||
|
||||
**Prerequisites:**
|
||||
- BMAD installed with the BMB module
|
||||
- An idea for what you want your agent to do
|
||||
- About 15-30 minutes for your first agent
|
||||
|
||||
**Know Before You Go:**
|
||||
- What problem should your agent solve?
|
||||
- Who will use this agent?
|
||||
- What should the agent be able to do?
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Start the Workflow
|
||||
|
||||
In your IDE (Claude Code, Cursor, etc.), invoke the create-agent workflow:
|
||||
|
||||
```
|
||||
"Run the BMAD Builder create-agent workflow"
|
||||
```
|
||||
|
||||
Or trigger it via the BMAD Master menu.
|
||||
|
||||
### 2. Follow the Steps
|
||||
|
||||
The workflow guides you through:
|
||||
|
||||
| Step | What You'll Do |
|
||||
|------|----------------|
|
||||
| **Brainstorm** (optional) | Explore ideas with creative techniques |
|
||||
| **Discovery** | Define the agent's purpose and goals |
|
||||
| **Type & Metadata** | Choose Simple or Expert, name your agent |
|
||||
| **Persona** | Craft the agent's personality and principles |
|
||||
| **Commands** | Define what the agent can do |
|
||||
| **Activation** | Set up autonomous behaviors (optional) |
|
||||
| **Build** | Generate the agent file |
|
||||
| **Validation** | Review and verify everything works |
|
||||
|
||||
### 3. Install Your Agent
|
||||
|
||||
Once created, package your agent for installation:
|
||||
|
||||
```
|
||||
my-custom-stuff/
|
||||
├── module.yaml # Contains: unitary: true
|
||||
├── agents/
|
||||
│ └── {agent-name}/
|
||||
│ ├── {agent-name}.agent.yaml
|
||||
│ └── _memory/ # Expert agents only
|
||||
│ └── {sidecar-folder}/
|
||||
└── workflows/ # Optional: custom workflows
|
||||
```
|
||||
|
||||
See [Custom Content Installation](./custom-content-installation.md) for details.
|
||||
|
||||
## Choosing Your Agent Type
|
||||
|
||||
The workflow will help you decide, but here's the quick reference:
|
||||
|
||||
### Choose Simple Agent When:
|
||||
|
||||
- Task is well-defined and focused
|
||||
- Don't need persistent memory
|
||||
- Want fast setup and deployment
|
||||
- Single-purpose assistant (e.g., commit messages, code review)
|
||||
|
||||
**Example:** A "Code Commenter" that reads files and adds helpful comments.
|
||||
|
||||
### Choose Expert Agent When:
|
||||
|
||||
- Domain requires specialized knowledge
|
||||
- Need persistent memory across sessions
|
||||
- Agent coordinates complex workflows
|
||||
- Building ongoing project infrastructure
|
||||
|
||||
**Example:** A "Security Architect" that remembers your design decisions and maintains security standards across the project.
|
||||
|
||||
### Choose Module Agent When:
|
||||
|
||||
- Agent builds other agents or workflows
|
||||
- Need integration with module system
|
||||
- Creating professional tooling
|
||||
|
||||
**Example:** A "Team Builder" that helps set up agents for new team members.
|
||||
|
||||
## The Persona System
|
||||
|
||||
Your agent's personality is defined by four fields:
|
||||
|
||||
| Field | Purpose | Example |
|
||||
|-------|---------|---------|
|
||||
| **Role** | What they do | "Senior code reviewer who catches bugs and suggests improvements" |
|
||||
| **Identity** | Who they are | "Friendly but exacting, believes clean code is a craft" |
|
||||
| **Communication Style** | How they speak | "Direct, constructive, explains the 'why' behind suggestions" |
|
||||
| **Principles** | Why they act | "Security first, clarity over cleverness, test what you fix" |
|
||||
|
||||
**Key:** Keep each field focused on its purpose. The role isn't personality; the identity isn't job description.
|
||||
|
||||
## Tips for Success
|
||||
|
||||
### Start Small
|
||||
|
||||
Your first agent should solve **one problem well**. You can always add more capabilities later.
|
||||
|
||||
### Learn by Example
|
||||
|
||||
Study the reference agents in `src/modules/bmb/reference/agents/`:
|
||||
- **Simple:** [commit-poet](https://github.com/bmad-code-org/BMAD-METHOD/tree/main/src/modules/bmb/reference/agents/simple-examples/commit-poet.agent.yaml)
|
||||
- **Expert:** [journal-keeper](https://github.com/bmad-code-org/BMAD-METHOD/tree/main/src/modules/bmb/reference/agents/expert-examples/journal-keeper)
|
||||
|
||||
### Write Great Principles
|
||||
|
||||
The first principle should "activate" the agent's expertise:
|
||||
|
||||
❌ **Weak:** "Be helpful and accurate"
|
||||
✅ **Strong:** "Channel decades of security expertise: threat modeling begins with trust boundaries, never trust client input, defense in depth is non-negotiable"
|
||||
|
||||
### Use the Menu System
|
||||
|
||||
The workflow provides options at each step:
|
||||
- **[A] Advanced** - Get deeper insights and reasoning
|
||||
- **[P] Party** - Get multiple agent perspectives
|
||||
- **[C] Continue** - Move to the next step
|
||||
|
||||
Use these when you need extra input or creative options.
|
||||
|
||||
## After Creation
|
||||
|
||||
### Test Your Agent
|
||||
|
||||
1. Install your custom module using the BMAD installer
|
||||
2. Invoke your new agent in your IDE
|
||||
3. Try each menu command
|
||||
4. Verify the personality feels right
|
||||
|
||||
### Iterate
|
||||
|
||||
If something isn't right:
|
||||
1. Edit the agent YAML directly, or
|
||||
2. Edit the customization file in `_bmad/_config/agents/`
|
||||
3. Rebuild using `npx bmad-method build <agent-name>`
|
||||
|
||||
### Share
|
||||
|
||||
Package your agent as a standalone module (see [Installation Guide](../../bmad-core-concepts/installing/)) and share it with your team or the community.
|
||||
|
||||
## Further Reading
|
||||
|
||||
- **[Agent Architecture](./index.md)** - Deep technical details on agent types
|
||||
- **[Agent Customization](../../bmad-core-concepts/agent-customization/)** - Modify agents without editing core files
|
||||
- **[Custom Content Installation](./custom-content-installation.md)** - Package and distribute your agents
|
||||
|
||||
---
|
||||
|
||||
**Ready?** Start the workflow and create your first agent!
|
||||
|
||||
[← Back to BMB Documentation](./index.md)
|
||||
@@ -1,6 +1,11 @@
|
||||
# BMB Module Documentation
|
||||
|
||||
Reference documentation for building BMAD agents and workflows.
|
||||
Create custom agents, workflows, and modules for BMAD.
|
||||
|
||||
## Quick Start
|
||||
|
||||
- **[Agent Creation Guide](./agent-creation-guide.md)** - Step-by-step guide to building your first agent
|
||||
- **[Understanding Agent Types](./understanding-agent-types.md)** - Learn the differences between Simple and Expert agents
|
||||
|
||||
## Agent Architecture
|
||||
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
# Using BMad Web Bundles in Gemini Gems & Custom GPTs
|
||||
|
||||
## IMPORTANT NOTE
|
||||
|
||||
The Web Bundling Feature is being rebuilt from the ground up, current bundles found for v6 may be incomplete or missing functionality and are not optimized.
|
||||
|
||||
## What Are Web bundles
|
||||
|
||||
Web bundles package BMad agents as self-contained files that work in Gemini Gems and Custom GPTs. Everything the agent needs - instructions, workflows, dependencies - is bundled into a single file for easy upload.
|
||||
|
||||
## What Are Web Bundles?
|
||||
|
||||
Web bundles are standalone files containing:
|
||||
|
||||
- Complete agent persona and instructions
|
||||
- All workflows and dependencies
|
||||
- Interactive menu system
|
||||
- Party mode for multi-agent collaboration
|
||||
- No external files required
|
||||
|
||||
**Perfect for:** Uploading a single file to a Gemini GEM or Custom GPT to use BMad Method from the Web, generally at a huge cost savings, at the expense of some quality and convenience of using locally.
|
||||
@@ -3,7 +3,7 @@ name: 'step-01-brainstorm'
|
||||
description: 'Optional brainstorming for agent ideas'
|
||||
|
||||
# File References
|
||||
nextStepFile: '{project-root}/src/modules/bmb/workflows/create-agent/steps/step-02-discover.md'
|
||||
nextStepFile: '{project-root}/src/modules/bmb/workflows/create-agent/steps/step-02-discovery.md'
|
||||
brainstormContext: ../data/brainstorm-context.md
|
||||
brainstormWorkflow: '{project-root}/_bmad/core/workflows/brainstorming/workflow.md'
|
||||
---
|
||||
|
||||
@@ -1,196 +0,0 @@
|
||||
---
|
||||
name: 'step-02-discover'
|
||||
description: 'Discover the agent purpose and type through natural conversation'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-03-persona.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentTypesGuide: '../data/understanding-agent-types.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 2: Discover Agent Purpose and Type
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Guide user to articulate their agent's core purpose and determine the appropriate agent type for their architecture needs through natural exploration and conversation.
|
||||
|
||||
## 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 an agent architect who helps users discover and clarify their agent vision
|
||||
- ✅ 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 agent architecture expertise, user brings their domain knowledge and goals, together we design the optimal agent
|
||||
- ✅ Maintain collaborative exploratory tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on discovering purpose and determining appropriate agent type
|
||||
- 🚫 FORBIDDEN to push specific agent types without clear justification
|
||||
- 💬 Approach: Guide through natural conversation, not interrogation
|
||||
- 📋 Agent type recommendation based on architecture needs, not capability limits
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Natural conversation flow, not rigid questioning
|
||||
- 💾 Document purpose and type decisions clearly
|
||||
- 📖 Load technical documentation as needed for guidance
|
||||
- 🚫 FORBIDDEN to make assumptions about user needs
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: User is creating a new agent, may have brainstorming results
|
||||
- Focus: Purpose discovery and agent type determination
|
||||
- Limits: No persona development, no command design yet
|
||||
- Dependencies: User must articulate clear purpose and agree on agent type
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Technical Documentation
|
||||
|
||||
Load and understand agent building documentation:
|
||||
|
||||
- Agent types guide: `{agentTypesGuide}`
|
||||
- Reference examples from appropriate directories as needed
|
||||
|
||||
### 2. Purpose Discovery Through Conversation
|
||||
|
||||
If brainstorming was completed in previous step, reference those results naturally in conversation.
|
||||
|
||||
Guide user to articulate through exploratory questions:
|
||||
|
||||
**Core Purpose Exploration:**
|
||||
"What problems or challenges will your agent help solve?"
|
||||
"Who are the primary users of this agent?"
|
||||
"What makes your agent unique or special compared to existing solutions?"
|
||||
"What specific tasks or workflows will this agent handle?"
|
||||
|
||||
**Deep Dive Questions:**
|
||||
"What's the main pain point this agent addresses?"
|
||||
"How will users interact with this agent day-to-day?"
|
||||
"What would success look like for users of this agent?"
|
||||
|
||||
Continue conversation until purpose is clearly understood.
|
||||
|
||||
### 3. Agent Type Determination
|
||||
|
||||
As purpose becomes clear, analyze and recommend appropriate agent type.
|
||||
|
||||
**Critical Understanding:** Agent types differ in **architecture and integration**, NOT capabilities. ALL types can write files, execute commands, and use system resources.
|
||||
|
||||
**Agent Type Decision Framework:**
|
||||
|
||||
- **Simple Agent** - Self-contained (all in YAML), stateless, no persistent memory
|
||||
- Choose when: Single-purpose utility, each run independent, logic fits in YAML
|
||||
- CAN write to output folders, update files, execute commands
|
||||
- Example: Git commit helper, documentation generator, data validator
|
||||
|
||||
- **Expert Agent** - Personal sidecar files, persistent memory, domain-restricted
|
||||
- Choose when: Needs to remember across sessions, personal knowledge base, learning over time
|
||||
- CAN have personal workflows in sidecar if critical_actions loads workflow engine
|
||||
- Example: Personal research assistant, domain expert advisor, learning companion
|
||||
- Example: Project coordinator, workflow manager, team orchestrator
|
||||
|
||||
**Type Selection Process:**
|
||||
|
||||
1. Present recommendation based on discovered needs
|
||||
2. Explain WHY this type fits their architecture requirements
|
||||
3. Show relevant examples from reference directories
|
||||
4. Get user agreement or adjustment
|
||||
|
||||
### 4. Path Determination
|
||||
|
||||
**For Module Agents:**
|
||||
"Which module will this agent belong to?"
|
||||
"Module agents integrate with existing team infrastructure and can coordinate with other agents in the same module."
|
||||
|
||||
**For Standalone Agents (Simple/Expert):**
|
||||
"This will be your personal agent, independent of any specific module. It will have its own dedicated space for operation."
|
||||
|
||||
### 5. Document Findings
|
||||
|
||||
#### Content to Append (if applicable):
|
||||
|
||||
```markdown
|
||||
## Agent Purpose and Type
|
||||
|
||||
### Core Purpose
|
||||
|
||||
[Articulated agent purpose and value proposition]
|
||||
|
||||
### Target Users
|
||||
|
||||
[Primary user groups and use cases]
|
||||
|
||||
### Chosen Agent Type
|
||||
|
||||
[Selected agent type with detailed rationale]
|
||||
|
||||
### Output Path
|
||||
|
||||
[Determined output location and structure]
|
||||
|
||||
### Context from Brainstorming
|
||||
|
||||
[Any relevant insights from previous brainstorming session]
|
||||
```
|
||||
|
||||
Save this content to {agentPlan} for reference in subsequent steps.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute `{advancedElicitationTask}`
|
||||
- IF P: Execute `{partyModeWorkflow}`
|
||||
- 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 purpose clearly articulated and agent type determined], will you then load and read fully `{nextStepFile}` to execute and begin persona development.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Agent purpose clearly articulated and documented
|
||||
- Appropriate agent type selected with solid reasoning
|
||||
- User understands architectural implications of chosen type
|
||||
- Output paths determined correctly based on agent type
|
||||
- Content properly saved to output file
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding without clear agent purpose
|
||||
- Pushing specific agent types without justification
|
||||
- Not explaining architectural implications
|
||||
- Failing to document findings properly
|
||||
- Not getting user agreement on agent type selection
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,168 @@
|
||||
---
|
||||
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
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
1. **Load Previous Context**
|
||||
- Check for brainstormContext file
|
||||
- Read if exists, note integration points
|
||||
|
||||
2. **Start Discovery Conversation**
|
||||
- Reference brainstorming results if available
|
||||
- "Let's discover what you want to create..."
|
||||
- Explore purpose, goals, capabilities, context, users
|
||||
|
||||
3. **Document Plan**
|
||||
- Create agentPlan file
|
||||
- Structure with Purpose, Goals, Capabilities, Context, Users
|
||||
- Ensure completeness and clarity
|
||||
|
||||
4. **Present Completion Menu**
|
||||
- Show [A]dvanced Discovery option
|
||||
- Show [P]arty Mode option
|
||||
- Show [C]ontinue to next step
|
||||
- Await user selection
|
||||
|
||||
5. **Handle Menu Choice**
|
||||
- If A: Invoke advanced-elicitation task, then re-document
|
||||
- If P: Invoke party-mode workflow, then re-document
|
||||
- If C: Proceed to step-03-type-metadata
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
**THIS STEP IS COMPLETE WHEN:**
|
||||
- agentPlan file exists with complete structure
|
||||
- All five sections (Purpose, Goals, Capabilities, Context, Users) populated
|
||||
- User confirms accuracy via menu selection
|
||||
- Either continuing to next step or invoking optional workflows
|
||||
|
||||
**BEFORE PROCEEDING:**
|
||||
- Verify plan file is readable
|
||||
- Ensure content is sufficient for subsequent steps
|
||||
- Confirm user is satisfied with discoveries
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
**SUCCESS:**
|
||||
- agentPlan file created with all required sections
|
||||
- User has provided clear, actionable requirements
|
||||
- Plan contains sufficient detail for persona, commands, and name steps
|
||||
- User explicitly chooses to continue or invokes optional workflow
|
||||
|
||||
**FAILURE:**
|
||||
- Unable to extract coherent purpose or goals
|
||||
- User cannot articulate basic requirements
|
||||
- Plan sections remain incomplete or vague
|
||||
- User requests restart
|
||||
|
||||
**RECOVERY:**
|
||||
- If requirements unclear, use advanced-elicitation task
|
||||
- If user stuck, offer party-mode for creative exploration
|
||||
- If still unclear, suggest revisiting brainstorming step
|
||||
@@ -1,252 +0,0 @@
|
||||
---
|
||||
name: 'step-03-persona'
|
||||
description: 'Shape the agent personality through collaborative discovery'
|
||||
|
||||
# File References
|
||||
nextStepFile: ./step-04-commands.md
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
communicationPresets: ../data/communication-presets.csv
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 3: Shape Agent's Personality
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Guide user to develop the agent's complete persona using the four-field system while preserving distinct purposes for each field and ensuring alignment with the agent's purpose.
|
||||
|
||||
## 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 persona architect who helps users craft compelling agent personalities
|
||||
- ✅ 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 persona development expertise, user brings their vision and preferences, together we create an authentic agent personality
|
||||
- ✅ Maintain collaborative creative tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on developing the four persona fields distinctly
|
||||
- 🚫 FORBIDDEN to mix persona fields or confuse their purposes
|
||||
- 💬 Approach: Guide discovery through natural conversation, not formulaic questioning
|
||||
- 📋 Each field must serve its distinct purpose without overlap
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Natural personality discovery through conversation
|
||||
- 💾 Document all four fields clearly and separately
|
||||
- 📖 Load communication presets for style selection when needed
|
||||
- 🚫 FORBIDDEN to create generic or mixed-field personas
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Agent purpose and type from step 2, optional brainstorming insights
|
||||
- Focus: Develop four distinct persona fields (role, identity, communication_style, principles)
|
||||
- Limits: No command design, no technical implementation yet
|
||||
- Dependencies: Clear agent purpose and type from previous step
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Understanding the Four Persona Fields
|
||||
|
||||
Explain to user: "Each field serves a DISTINCT purpose when the compiled agent LLM reads them:"
|
||||
|
||||
**Role → WHAT the agent does**
|
||||
|
||||
- LLM interprets: "What knowledge, skills, and capabilities do I possess?"
|
||||
- Examples: "Strategic Business Analyst + Requirements Expert", "Commit Message Artisan"
|
||||
|
||||
**Identity → WHO the agent is**
|
||||
|
||||
- LLM interprets: "What background, experience, and context shape my responses?"
|
||||
- Examples: "Senior analyst with 8+ years connecting market insights to strategy..."
|
||||
|
||||
**Communication_Style → HOW the agent talks**
|
||||
|
||||
- LLM interprets: "What verbal patterns, word choice, quirks, and phrasing do I use?"
|
||||
- Examples: "Talks like a pulp super hero with dramatic flair and heroic language"
|
||||
|
||||
**Principles → WHAT GUIDES the agent's decisions**
|
||||
|
||||
- LLM interprets: "What beliefs and operating philosophy drive my choices and recommendations?"
|
||||
- Examples: "Every business challenge has root causes. Ground findings in evidence."
|
||||
|
||||
### 2. Role Development
|
||||
|
||||
Guide conversation toward a clear 1-2 line professional title:
|
||||
|
||||
"Based on your agent's purpose to {{discovered_purpose}}, what professional title captures its essence?"
|
||||
|
||||
**Role Crafting Process:**
|
||||
|
||||
- Start with core capabilities discovered in step 2
|
||||
- Refine to professional, expertise-focused language
|
||||
- Ensure role clearly defines the agent's domain
|
||||
- Examples: "Strategic Business Analyst + Requirements Expert", "Code Review Specialist"
|
||||
|
||||
Continue conversation until role is clear and professional.
|
||||
|
||||
### 3. Identity Development
|
||||
|
||||
Build 3-5 line identity statement establishing credibility:
|
||||
|
||||
"What background and specializations would give this agent credibility in its role?"
|
||||
|
||||
**Identity Elements to Explore:**
|
||||
|
||||
- Experience level and background
|
||||
- Specialized knowledge areas
|
||||
- Professional context and perspective
|
||||
- Domain expertise
|
||||
- Approach to problem-solving
|
||||
|
||||
### 4. Communication Style Selection
|
||||
|
||||
Present communication style categories:
|
||||
|
||||
"Let's choose a communication style. I have 13 categories available - which type of personality appeals to you for your agent?"
|
||||
|
||||
**Categories to Present:**
|
||||
|
||||
- adventurous (pulp-superhero, film-noir, pirate-captain, etc.)
|
||||
- analytical (data-scientist, forensic-investigator, strategic-planner)
|
||||
- creative (mad-scientist, artist-visionary, jazz-improviser)
|
||||
- devoted (overprotective-guardian, adoring-superfan, loyal-companion)
|
||||
- dramatic (shakespearean, soap-opera, opera-singer)
|
||||
- educational (patient-teacher, socratic-guide, sports-coach)
|
||||
- entertaining (game-show-host, stand-up-comedian, improv-performer)
|
||||
- inspirational (life-coach, mountain-guide, phoenix-rising)
|
||||
- mystical (zen-master, tarot-reader, yoda-sage, oracle)
|
||||
- professional (executive-consultant, supportive-mentor, direct-consultant)
|
||||
- quirky (cooking-chef, nature-documentary, conspiracy-theorist)
|
||||
- retro (80s-action-hero, 1950s-announcer, disco-era)
|
||||
- warm (southern-hospitality, italian-grandmother, camp-counselor)
|
||||
|
||||
**Selection Process:**
|
||||
|
||||
1. Ask user which category interests them
|
||||
2. Load ONLY that category from `{communicationPresets}`
|
||||
3. Present presets with name, style_text, and sample
|
||||
4. Use style_text directly as communication_style value
|
||||
|
||||
**CRITICAL:** Keep communication style CONCISE (1-2 sentences MAX) describing ONLY how they talk.
|
||||
|
||||
### 5. Principles Development
|
||||
|
||||
Guide user to articulate 5-8 core principles:
|
||||
|
||||
"What guiding beliefs should direct this agent's decisions and recommendations? Think about what makes your approach unique."
|
||||
|
||||
Guide them to use "I believe..." or "I operate..." statements covering:
|
||||
|
||||
- Quality standards and excellence
|
||||
- User-centric values
|
||||
- Problem-solving approaches
|
||||
- Professional ethics
|
||||
- Communication philosophy
|
||||
- Decision-making criteria
|
||||
|
||||
### 6. Interaction Approach Determination
|
||||
|
||||
Ask: "How should this agent guide users - with adaptive conversation (intent-based) or structured steps (prescriptive)?"
|
||||
|
||||
**Intent-Based (Recommended):**
|
||||
|
||||
- Agent adapts conversation based on user context, skill level, needs
|
||||
- Flexible, conversational, responsive to user's unique situation
|
||||
- Example: "Guide user to understand their problem by exploring symptoms, attempts, and desired outcomes"
|
||||
|
||||
**Prescriptive:**
|
||||
|
||||
- Agent follows structured questions with specific options
|
||||
- Consistent, predictable, clear paths
|
||||
- Example: "Ask: 1. What is the issue? [A] Performance [B] Security [C] Usability"
|
||||
|
||||
### 7. Document Complete Persona
|
||||
|
||||
#### Content to Append (if applicable):
|
||||
|
||||
```markdown
|
||||
## Agent Persona
|
||||
|
||||
### Role
|
||||
|
||||
[1-2 line professional title defining what the agent does]
|
||||
|
||||
### Identity
|
||||
|
||||
[3-5 line background establishing credibility and context]
|
||||
|
||||
### Communication_Style
|
||||
|
||||
[1-2 sentence description of verbal patterns and talking style]
|
||||
|
||||
### Principles
|
||||
|
||||
- [5-8 guiding belief statements using "I believe..." or "I operate..."]
|
||||
- [Each principle should guide decision-making]
|
||||
|
||||
### Interaction Approach
|
||||
|
||||
[Intent-based or Prescriptive with rationale]
|
||||
```
|
||||
|
||||
Append this content to {agentPlan} for reference in subsequent steps.
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- 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](#8-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [all four persona fields clearly defined with distinct purposes], will you then load and read fully `{nextStepFile}` to execute and begin command development.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All four persona fields clearly defined with distinct purposes
|
||||
- Communication style concise and pure (no mixing with other fields)
|
||||
- 5-8 guiding principles articulated in proper format
|
||||
- Interaction approach selected with clear rationale
|
||||
- Persona aligns with agent purpose discovered in step 2
|
||||
- Content properly saved to output file
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Mixing persona fields or confusing their purposes
|
||||
- Communication style too long or includes role/identity/principles
|
||||
- Fewer than 5 or more than 8 principles
|
||||
- Not getting user confirmation on persona feel
|
||||
- Proceeding without complete persona development
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,294 @@
|
||||
---
|
||||
name: 'step-02-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 `{agent-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
|
||||
|
||||
---
|
||||
|
||||
# INSTRUCTION SEQUENCE
|
||||
|
||||
## 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 `{agent-language}`:
|
||||
- "What is the primary function this agent will perform?"
|
||||
- "How complex are the tasks this agent will handle?"
|
||||
- "Will this agent need to manage workflows or other agents?"
|
||||
- "What specific domains or expertise areas are involved?"
|
||||
|
||||
Listen for natural language cues about scope and complexity.
|
||||
|
||||
## 3. Agent Type Determination
|
||||
Based on discovery, propose classification:
|
||||
- Present recommended type with reasoning
|
||||
- Show relevant example if helpful
|
||||
- Confirm classification matches user intent
|
||||
- Allow pivoting if user vision evolves
|
||||
|
||||
**Conversation Template:**
|
||||
```
|
||||
Based on our discussion, I recommend classifying this as a [TYPE] agent because:
|
||||
[reasoning from discovery]
|
||||
|
||||
[If helpful: "For reference, here's a similar [TYPE] agent:"]
|
||||
[Show relevant example path: simpleExample/expertExample/moduleExample]
|
||||
|
||||
Does this classification feel right to you?
|
||||
```
|
||||
|
||||
## 4. Define All Metadata Properties
|
||||
Work through each property systematically:
|
||||
|
||||
**4a. Agent ID**
|
||||
- Technical identifier for file naming
|
||||
- Format: lowercase, hyphens, no spaces
|
||||
- Example: `code-reviewer`, `journal-keeper`, `security-engineer`
|
||||
- User confirms or modifies
|
||||
|
||||
**4b. Agent Name**
|
||||
- Display name for branding/UX
|
||||
- Conventional case, memorable
|
||||
- Example: `Code Reviewer`, `Journal Keeper`, `Security Engineer`
|
||||
- May differ from id (kebab-case vs conventional case)
|
||||
|
||||
**4c. Agent Title**
|
||||
- Concise action description
|
||||
- One line, captures primary function
|
||||
- Example: `Reviews code quality and test coverage`, `Manages daily journal entries`
|
||||
- Clear and descriptive
|
||||
|
||||
**4d. Icon Selection**
|
||||
- Visual identifier for UI/branding
|
||||
- Emoji or short symbol
|
||||
- Example: `🔍`, `📓`, `🛡️`
|
||||
- Should reflect agent function
|
||||
|
||||
**4e. Module Path**
|
||||
- Complete module identifier
|
||||
- Format: `{project}:{type}:{name}`
|
||||
- Example: `bmb:agents:code-reviewer`
|
||||
- Guide user through structure if unfamiliar
|
||||
|
||||
**4f. Sidecar Configuration**
|
||||
- Boolean: manages external workflows?
|
||||
- Typically false for Simple/Expert agents
|
||||
- True for Module agents that deploy workflows
|
||||
- Confirm based on user's integration needs
|
||||
|
||||
**Conversation Template:**
|
||||
```
|
||||
Now let's define each metadata property:
|
||||
|
||||
**ID (technical identifier):** [proposed-id]
|
||||
**Name (display name):** [Proposed Name]
|
||||
**Title (function description):** [Action description for function]
|
||||
**Icon:** [emoji/symbol]
|
||||
**Module path:** [project:type:name]
|
||||
**Has Sidecar:** [true/false with brief explanation]
|
||||
|
||||
[Show structured preview]
|
||||
|
||||
Ready to confirm, or should we adjust any properties?
|
||||
```
|
||||
|
||||
## 5. Document to Plan File
|
||||
Write to `{agentPlan}`:
|
||||
|
||||
```yaml
|
||||
# Agent Type & Metadata
|
||||
agent_type: [Simple|Expert|Module]
|
||||
classification_rationale: |
|
||||
[Clear explanation of why this type matches user's articulated needs]
|
||||
|
||||
metadata:
|
||||
id: [technical-identifier]
|
||||
name: [Display Name]
|
||||
title: [One-line action description]
|
||||
icon: [emoji-or-symbol]
|
||||
module: [project:type:name]
|
||||
hasSidecar: [true|false]
|
||||
|
||||
# Type Classification Notes
|
||||
type_decision_date: [YYYY-MM-DD]
|
||||
type_confidence: [High/Medium/Low]
|
||||
considered_alternatives: |
|
||||
- [Alternative type]: [reason not chosen]
|
||||
- [Alternative type]: [reason not chosen]
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {agentPlan}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [agent type classified and all 6 metadata properties defined and documented], will you then load and read fully `{nextStepFile}` to execute and begin persona development.
|
||||
|
||||
---
|
||||
|
||||
# SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
## Success Indicators
|
||||
- Type classification clearly justified
|
||||
- All metadata properties populated correctly
|
||||
- YAML structure matches specification exactly
|
||||
- User confirms understanding and acceptance
|
||||
- Agent plan file updated successfully
|
||||
|
||||
## Failure Indicators
|
||||
- Missing or undefined metadata properties
|
||||
- YAML structure malformed
|
||||
- User confusion about type classification
|
||||
- Inadequate documentation to plan file
|
||||
- Proceeding without user confirmation
|
||||
|
||||
## Recovery Mode
|
||||
If user struggles with classification:
|
||||
- Show concrete examples from each type
|
||||
- Compare/contrast types with their use case
|
||||
- Ask targeted questions about complexity/scope
|
||||
- Offer type recommendation with clear reasoning
|
||||
|
||||
Recover metadata definition issues by:
|
||||
- Showing property format examples
|
||||
- Explaining technical vs display naming
|
||||
- Clarifying module path structure
|
||||
- Defining sidecar use cases
|
||||
@@ -1,230 +0,0 @@
|
||||
---
|
||||
name: 'step-04-commands'
|
||||
description: 'Build capabilities through natural progression and refine commands'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-05-name.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
|
||||
# Architecture References
|
||||
simpleAgentArch: '../data/simple-agent-architecture.md'
|
||||
expertAgentArch: '../data/expert-agent-architecture.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 4: Build Capabilities and Commands
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Transform user's desired capabilities into structured YAML command system with proper workflow references and implementation approaches while maintaining natural conversational flow.
|
||||
|
||||
## 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 command architect who translates user capabilities into technical implementations
|
||||
- ✅ 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 technical architecture expertise, user brings their capability vision, together we create implementable command structures
|
||||
- ✅ Maintain collaborative technical tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on translating capabilities to structured command system
|
||||
- 🚫 FORBIDDEN to add help/exit commands (auto-injected by compiler)
|
||||
- 💬 Approach: Guide through technical implementation without breaking conversational flow
|
||||
- 📋 Build commands naturally from capability discussion
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Natural capability discovery leading to structured command development
|
||||
- 💾 Document all commands with proper YAML structure and workflow references
|
||||
- 📖 Load architecture documentation based on agent type for guidance
|
||||
- 🚫 FORBIDDEN to create technical specifications without user capability input
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Agent purpose, type, and persona from previous steps
|
||||
- Focus: Capability discovery and command structure development
|
||||
- Limits: No agent naming, no YAML generation yet, just planning
|
||||
- Dependencies: Clear understanding of agent purpose and capabilities from user
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Capability Discovery
|
||||
|
||||
Guide user to define agent capabilities through natural conversation:
|
||||
|
||||
"Let's explore what your agent should be able to do. Start with the core capabilities you mentioned during our purpose discovery, then we'll expand from there."
|
||||
|
||||
**Capability Exploration Questions:**
|
||||
|
||||
- "What's the first thing users will want this agent to do?"
|
||||
- "What complex analyses or tasks should it handle?"
|
||||
- "How should it help users with common problems in its domain?"
|
||||
- "What unique capabilities make this agent special?"
|
||||
|
||||
Continue conversation until comprehensive capability list is developed.
|
||||
|
||||
### 2. Architecture-Specific Capability Planning
|
||||
|
||||
Load appropriate architecture documentation based on agent type:
|
||||
|
||||
**Simple Agent:**
|
||||
|
||||
- Load `{simpleAgentArch}`
|
||||
- Focus on single-execution capabilities
|
||||
- All logic must fit within YAML structure
|
||||
- No persistent memory between runs
|
||||
|
||||
**Expert Agent:**
|
||||
|
||||
- Load `{expertAgentArch}`
|
||||
- Plan for sidecar file integration
|
||||
- Persistent memory capabilities
|
||||
- Domain-restricted knowledge base
|
||||
|
||||
**Module Agent:**
|
||||
|
||||
- Module architecture documentation not available - use expert architecture as baseline
|
||||
- Workflow orchestration capabilities
|
||||
- Team integration features
|
||||
- Cross-agent coordination
|
||||
|
||||
### 3. Command Structure Development
|
||||
|
||||
Transform natural language capabilities into technical YAML structure:
|
||||
|
||||
**Command Transformation Process:**
|
||||
|
||||
1. **Natural capability** → **Trigger phrase**
|
||||
2. **Implementation approach** → **Workflow/action reference**
|
||||
3. **User description** → **Command description**
|
||||
4. **Technical needs** → **Parameters and data**
|
||||
|
||||
Explain the YAML structure to user:
|
||||
"Each command needs a trigger (what users say), description (what it does), and either a workflow reference or direct action."
|
||||
|
||||
### 4. Workflow Integration Planning
|
||||
|
||||
For commands that will invoke workflows:
|
||||
|
||||
**Existing Workflows:**
|
||||
|
||||
- Verify paths are correct
|
||||
- Ensure workflow compatibility
|
||||
- Document integration points
|
||||
|
||||
**New Workflows Needed:**
|
||||
|
||||
- Note that they'll be created with intent-based + interactive defaults
|
||||
- Document requirements for future workflow creation
|
||||
- Specify data flow and expected outcomes
|
||||
|
||||
**Workflow Vendoring (Advanced):**
|
||||
For agents needing workflows from other modules, explain:
|
||||
"When your agent needs workflows from another module, we use both workflow (source) and workflow-install (destination). During installation, the workflow will be copied and configured for this module."
|
||||
|
||||
### 5. Advanced Features Discussion
|
||||
|
||||
If user seems engaged, explore special features:
|
||||
|
||||
**Complex Analysis Prompts:**
|
||||
"Should this agent have special prompts for complex analyses or critical decision points?"
|
||||
|
||||
**Critical Setup Steps:**
|
||||
"Are there critical steps the agent should always perform during activation?"
|
||||
|
||||
**Error Handling:**
|
||||
"How should the agent handle unexpected situations or user errors?"
|
||||
|
||||
**Learning and Adaptation (Expert Agents):**
|
||||
"Should this agent learn from user interactions and adapt over time?"
|
||||
|
||||
### 6. Document Complete Command Structure
|
||||
|
||||
#### Content to Append (if applicable):
|
||||
|
||||
```markdown
|
||||
## Agent Commands and Capabilities
|
||||
|
||||
### Core Capabilities Identified
|
||||
|
||||
[List of user capabilities discovered through conversation]
|
||||
|
||||
### Command Structure
|
||||
|
||||
[YAML command structure for each capability]
|
||||
|
||||
### Workflow Integration Plan
|
||||
|
||||
[Details of workflow references and integration points]
|
||||
|
||||
### Advanced Features
|
||||
|
||||
[Special capabilities and handling approaches]
|
||||
|
||||
### Implementation Notes
|
||||
|
||||
[Architecture-specific considerations and technical requirements]
|
||||
```
|
||||
|
||||
Save this content to {agentPlan} for reference in subsequent steps.
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- 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](#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
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [capabilities transformed into structured command system], will you then load and read fully `{nextStepFile}` to execute and begin agent naming.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- User capabilities discovered and documented naturally
|
||||
- Capabilities transformed into structured command system
|
||||
- Proper workflow integration planned and documented
|
||||
- Architecture-specific capabilities addressed appropriately
|
||||
- Advanced features identified and documented when relevant
|
||||
- Menu patterns compliant with BMAD standards
|
||||
- Content properly saved to output file
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Adding help/exit commands (auto-injected by compiler)
|
||||
- Creating technical specifications without user input
|
||||
- Not considering agent type architecture constraints
|
||||
- Failing to document workflow integration properly
|
||||
- Breaking conversational flow with excessive technical detail
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
210
src/modules/bmb/workflows/create-agent/steps/step-04-persona.md
Normal file
210
src/modules/bmb/workflows/create-agent/steps/step-04-persona.md
Normal file
@@ -0,0 +1,210 @@
|
||||
---
|
||||
name: 'step-03-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)
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
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
|
||||
@@ -0,0 +1,176 @@
|
||||
---
|
||||
name: 'step-04-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
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
1. Load agent-menu-patterns.md to understand structure
|
||||
2. Review capabilities from agent-plan step 3
|
||||
3. Facilitate capability-to-command mapping conversation
|
||||
4. Develop command structure for each capability
|
||||
5. Define trigger, description, handler for each command
|
||||
6. Verify no help/exit commands (auto-injected)
|
||||
7. Document structured menu YAML to agent-plan
|
||||
8. Complete Menu [A][P][C] verification
|
||||
9. Confirm readiness for next step
|
||||
|
||||
## 10. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {agentPlan}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#10-present-menu-options)
|
||||
|
||||
### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [menu YAML documented in agent-plan and all commands have trigger/description/handler], will you then load and read fully `{nextStepFile}` to execute and begin activation planning.
|
||||
|
||||
---
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
✅ Menu YAML documented in agent-plan
|
||||
✅ All commands have trigger, description, handler
|
||||
✅ Menu follows agent-menu-patterns.md structure
|
||||
✅ No help/exit commands included
|
||||
✅ Menu [A][P][C] verification passed
|
||||
✅ Ready for activation phase
|
||||
|
||||
# FAILURE INDICATORS
|
||||
|
||||
❌ Menu YAML missing from agent-plan
|
||||
❌ Commands missing required elements (trigger/description/handler)
|
||||
❌ Menu doesn't follow pattern structure
|
||||
❌ Help/exit commands manually added
|
||||
❌ Menu [A][P][C] verification failed
|
||||
❌ Unclear command triggers or descriptions
|
||||
@@ -1,224 +0,0 @@
|
||||
---
|
||||
name: 'step-05-name'
|
||||
description: 'Name the agent based on discovered characteristics'
|
||||
|
||||
# File References
|
||||
nextStepFile: ./step-06-build.md
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{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'
|
||||
---
|
||||
|
||||
# Step 5: Agent Naming and Identity
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Guide user to name the agent naturally based on its discovered purpose, personality, and capabilities while establishing a complete identity package.
|
||||
|
||||
## 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 an identity architect who helps users discover the perfect name for their agent
|
||||
- ✅ 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 naming expertise, user brings their agent vision, together we create an authentic identity
|
||||
- ✅ Maintain collaborative creative tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on naming agent based on discovered characteristics
|
||||
- 🚫 FORBIDDEN to force generic or inappropriate names
|
||||
- 💬 Approach: Let naming emerge naturally from agent characteristics
|
||||
- 📋 Connect personality traits and capabilities to naming options
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Natural naming exploration based on agent characteristics
|
||||
- 💾 Document complete identity package (name, title, icon, filename)
|
||||
- 📖 Review discovered characteristics for naming inspiration
|
||||
- 🚫 FORBIDDEN to suggest names without connecting to agent identity
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Agent purpose, persona, and capabilities from previous steps
|
||||
- Focus: Agent naming and complete identity package establishment
|
||||
- Limits: No YAML generation yet, just identity development
|
||||
- Dependencies: Complete understanding of agent characteristics from previous steps
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Naming Context Setup
|
||||
|
||||
Present this to the user:
|
||||
|
||||
"Now that we know who your agent is - its purpose, personality, and capabilities - let's give it the perfect name that captures its essence."
|
||||
|
||||
**Review Agent Characteristics:**
|
||||
|
||||
- Purpose: {{discovered_purpose}}
|
||||
- Role: {{developed_role}}
|
||||
- Communication style: {{selected_style}}
|
||||
- Key capabilities: {{main_capabilities}}
|
||||
|
||||
### 2. Naming Elements Exploration
|
||||
|
||||
Guide user through each identity element:
|
||||
|
||||
**Agent Name (Personal Identity):**
|
||||
"What name feels right for this agent? Think about:"
|
||||
|
||||
- Personality-based names (e.g., "Sarah", "Max", "Data Wizard")
|
||||
- Domain-inspired names (e.g., "Clarity", "Nexus", "Catalyst")
|
||||
- Functional names (e.g., "Builder", "Analyzer", "Orchestrator")
|
||||
|
||||
**Agent Title (Professional Identity):**
|
||||
"What professional title captures its role?"
|
||||
|
||||
- Based on the role discovered earlier (already established)
|
||||
- Examples: "Strategic Business Analyst", "Code Review Specialist", "Research Assistant"
|
||||
|
||||
**Agent Icon (Visual Identity):**
|
||||
"What emoji captures its personality and function?"
|
||||
|
||||
- Should reflect both personality and purpose
|
||||
- Examples: 🧙♂️ (magical helper), 🔍 (investigator), 🚀 (accelerator), 🎯 (precision)
|
||||
|
||||
**Filename (Technical Identity):**
|
||||
"Let's create a kebab-case filename for the agent:"
|
||||
|
||||
- Based on agent name and function
|
||||
- Examples: "business-analyst", "code-reviewer", "research-assistant"
|
||||
- Auto-suggest based on chosen name for consistency
|
||||
|
||||
### 3. Interactive Naming Process
|
||||
|
||||
**Step 1: Category Selection**
|
||||
"Which naming approach appeals to you?"
|
||||
|
||||
- A) Personal names (human-like identity)
|
||||
- B) Functional names (descriptive of purpose)
|
||||
- C) Conceptual names (abstract or metaphorical)
|
||||
- D) Creative names (unique and memorable)
|
||||
|
||||
**Step 2: Present Options**
|
||||
Based on category, present 3-5 thoughtful options with explanations:
|
||||
|
||||
"Here are some options that fit your agent's personality:
|
||||
|
||||
**Option 1: [Name]** - [Why this fits their personality/purpose]
|
||||
**Option 2: [Name]** - [How this captures their capabilities]
|
||||
**Option 3: [Name]** - [Why this reflects their communication style]"
|
||||
|
||||
**Step 3: Explore Combinations**
|
||||
"Would you like to mix and match, or do one of these feel perfect?"
|
||||
|
||||
Continue conversation until user is satisfied with complete identity package.
|
||||
|
||||
### 4. Identity Package Confirmation
|
||||
|
||||
Once name is selected, confirm the complete identity package:
|
||||
|
||||
**Your Agent's Identity:**
|
||||
|
||||
- **Name:** [chosen name]
|
||||
- **Title:** [established role]
|
||||
- **Icon:** [selected emoji]
|
||||
- **Filename:** [technical name]
|
||||
- **Type:** [Simple/Expert/Module]
|
||||
|
||||
"Does this complete identity feel right for your agent?"
|
||||
|
||||
### 5. Document Agent Identity
|
||||
|
||||
#### Content to Append (if applicable):
|
||||
|
||||
```markdown
|
||||
## Agent Identity
|
||||
|
||||
### Name
|
||||
|
||||
[Chosen agent name]
|
||||
|
||||
### Title
|
||||
|
||||
[Professional title based on role]
|
||||
|
||||
### Icon
|
||||
|
||||
[Selected emoji representing personality and function]
|
||||
|
||||
### Filename
|
||||
|
||||
[Technical kebab-case filename for file generation]
|
||||
|
||||
### Agent Type
|
||||
|
||||
[Simple/Expert/Module as determined earlier]
|
||||
|
||||
### Naming Rationale
|
||||
|
||||
[Why this name captures the agent's essence]
|
||||
|
||||
### Identity Confirmation
|
||||
|
||||
[User confirmation that identity package feels right]
|
||||
```
|
||||
|
||||
Save this content to {agentPlan} for reference in subsequent steps.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- 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 [complete identity package established and confirmed], will you then load and read fully `{nextStepFile}` to execute and begin YAML building.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Agent name emerges naturally from discovered characteristics
|
||||
- Complete identity package established (name, title, icon, filename)
|
||||
- User confirms identity "feels right" for their agent
|
||||
- Technical filename ready for file generation follows kebab-case convention
|
||||
- Naming rationale documented with connection to agent characteristics
|
||||
- Content properly saved to output file
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Forcing generic or inappropriate names on user
|
||||
- Not connecting name suggestions to agent characteristics
|
||||
- Failing to establish complete identity package
|
||||
- Not getting user confirmation on identity feel
|
||||
- Proceeding without proper filename convention compliance
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,275 @@
|
||||
---
|
||||
name: 'step-05-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 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 hasSidecar and module
|
||||
hasSidecar: false → step-06-build-simple.md
|
||||
hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
|
||||
hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md
|
||||
```
|
||||
|
||||
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
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
## 1. Load Reference Documents
|
||||
```bash
|
||||
# Read these files FIRST
|
||||
cat {criticalActions}
|
||||
cat {agentPlan}
|
||||
```
|
||||
|
||||
## 2. Discuss Activation Needs
|
||||
Ask user:
|
||||
- "Should your agent be able to take autonomous actions?"
|
||||
- "Are there specific workflows it should trigger?"
|
||||
- "Should it run as a background process or scheduled task?"
|
||||
- "Or will it primarily respond to direct prompts?"
|
||||
|
||||
## 3. Define critical_actions OR Explicitly Omit
|
||||
|
||||
**If defining:**
|
||||
- Reference criticalActions.md patterns
|
||||
- List 3-7 specific actions
|
||||
- Each action should be clear and scoped
|
||||
- Document rationale for each
|
||||
|
||||
**If omitting:**
|
||||
- State clearly: "This agent will not have critical_actions"
|
||||
- Explain why: "This agent is a responsive assistant that operates under direct user guidance"
|
||||
- Document the rationale
|
||||
|
||||
## 4. Route to Build Step
|
||||
|
||||
Determine destination:
|
||||
|
||||
```yaml
|
||||
# Check plan metadata
|
||||
hasSidecar: {value from step 04}
|
||||
module: "{value from step 04}"
|
||||
|
||||
# Route logic
|
||||
if hasSidecar == false:
|
||||
destination = simpleBuild
|
||||
elif hasSidecar == true and module == "stand-alone":
|
||||
destination = expertBuild
|
||||
else: # hasSidecar == true and module != "stand-alone"
|
||||
destination = moduleBuild
|
||||
```
|
||||
|
||||
## 5. Document to Plan
|
||||
|
||||
Update agentPlan with:
|
||||
|
||||
```yaml
|
||||
---
|
||||
activation:
|
||||
hasCriticalActions: true
|
||||
rationale: "Agent needs to autonomously trigger workflows for task automation"
|
||||
criticalActions:
|
||||
- name: "start-workflow"
|
||||
description: "Initiate a predefined workflow for task execution"
|
||||
- name: "schedule-task"
|
||||
description: "Schedule tasks for future execution"
|
||||
- name: "sync-data"
|
||||
description: "Synchronize data with external systems"
|
||||
|
||||
routing:
|
||||
destinationBuild: "step-06-build-expert.md"
|
||||
hasSidecar: true
|
||||
module: "stand-alone"
|
||||
rationale: "Agent requires sidecar workflows for autonomous operation"
|
||||
---
|
||||
```
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {agentPlan}, update frontmatter, determine appropriate build step based on hasSidecar and module values, then only then load, read entire file, then execute {simpleBuild} or {expertBuild} or {moduleBuild} as determined
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the **ROUTING HUB** of agent creation. ONLY WHEN [C continue option] is selected and [routing decision determined with activation needs documented], will you then determine the appropriate build step based on hasSidecar/module values and load and read fully that build step file to execute.
|
||||
|
||||
Routing logic:
|
||||
- hasSidecar: false → step-06-build-simple.md
|
||||
- hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
|
||||
- hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md
|
||||
|
||||
You cannot proceed to build without completing routing.
|
||||
|
||||
---
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
✅ **COMPLETION CRITERIA:**
|
||||
- [ ] criticalActions.md loaded and understood
|
||||
- [ ] agentPlan loaded with all prior metadata
|
||||
- [ ] Routing decision determined and communicated
|
||||
- [ ] Activation needs discussed with user
|
||||
- [ ] critical_actions defined OR explicitly omitted with rationale
|
||||
- [ ] Plan updated with activation and routing metadata
|
||||
- [ ] User confirms routing to appropriate build step
|
||||
|
||||
✅ **SUCCESS INDICATORS:**
|
||||
- Clear activation decision documented
|
||||
- Route to build step is unambiguous
|
||||
- User understands why they're going to {simple|expert|module} build
|
||||
- Plan file reflects complete activation configuration
|
||||
|
||||
❌ **FAILURE MODES:**
|
||||
- Attempting to define critical_actions without reading reference
|
||||
- Routing decision not documented in plan
|
||||
- User doesn't understand which build step comes next
|
||||
- Ambiguous activation configuration (neither defined nor omitted)
|
||||
- Skipping routing discussion entirely
|
||||
|
||||
⚠️ **RECOVERY PATHS:**
|
||||
If activation planning goes wrong:
|
||||
|
||||
1. **Can't decide on activation?**
|
||||
- Default: Omit critical_actions
|
||||
- Route to simpleBuild
|
||||
- Can add later via edit-agent workflow
|
||||
|
||||
2. **Uncertain about routing?**
|
||||
- Check hasSidecar value
|
||||
- Check module value
|
||||
- Apply routing logic strictly
|
||||
|
||||
3. **User wants to change route?**
|
||||
- Adjust hasSidecar or module values
|
||||
- Re-run routing logic
|
||||
- Update plan accordingly
|
||||
@@ -1,198 +0,0 @@
|
||||
---
|
||||
name: 'step-06-build'
|
||||
description: 'Generate complete YAML incorporating all discovered elements'
|
||||
|
||||
# File References
|
||||
nextStepFile: ./step-07-validate.md
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}'
|
||||
|
||||
# Template References
|
||||
simpleAgentTemplate: ../templates/simple-agent.template.md
|
||||
expertAgentTemplate: ../templates/expert-agent-template/expert-agent.template.md
|
||||
|
||||
# Architecture References
|
||||
simpleAgentArch: ../data/simple-agent-architecture.md
|
||||
expertAgentArch: ../data/expert-agent-architecture.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
|
||||
# Menu Patterns Reference
|
||||
agentMenuPatterns: ../data/agent-menu-patterns.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 6: Build Complete Agent YAML
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate the complete YAML agent folder, yaml file and sidecar content to the specification defined in {agentBuildOutput} completely.
|
||||
|
||||
## 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 YAML architect who transforms collaborative discoveries into technical implementation
|
||||
- ✅ 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 technical YAML expertise, user brings their agent vision, together we create complete agent configuration
|
||||
- ✅ Maintain collaborative technical tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on generating complete YAML and sidecar content structure based on discovered elements
|
||||
- 🚫 FORBIDDEN to duplicate auto-injected features (help and exit menu items, activation handler instructions)
|
||||
- 💬 Approach: Present the journey of collaborative creation while building technical structure
|
||||
- 📋 Generate YAML and sidecar files that accurately reflects all discoveries from previous steps
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Generate complete YAML structure based on agent type and discovered elements
|
||||
- 💾 Present complete YAML with proper formatting and explanation
|
||||
- 📖 Load appropriate template for agent type for structure guidance
|
||||
- 🚫 FORBIDDEN to proceed without incorporating all discovered elements
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All discoveries from previous steps (purpose, persona, capabilities, identity)
|
||||
- Focus: YAML generation and complete agent configuration
|
||||
- Limits: No validation yet, just YAML generation
|
||||
- Dependencies: Complete understanding of all agent characteristics from previous steps
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Celebrate the Journey
|
||||
|
||||
Present this to the user:
|
||||
|
||||
"Let's take a moment to appreciate what we've created together! Your agent started as an idea, and through our discovery process, it has developed into a fully-realized personality with clear purpose, capabilities, and identity. Now we will make it BMad Compliant, ready to install use and share with the world!"
|
||||
|
||||
**Journey Summary:**
|
||||
|
||||
- Started with purpose discovery (Step 2)
|
||||
- Shaped personality through four-field persona system (Step 3)
|
||||
- Built capabilities and command structure (Step 4)
|
||||
- Established name and identity (Step 5)
|
||||
- Ready to bring it all together in complete YAML
|
||||
|
||||
### 2. Load Agent Type Template and Architecture References
|
||||
|
||||
Based on determined agent type, load appropriate template and architecture files:
|
||||
|
||||
- If (agent will have memories and optionally its own knowledge, separate prompt files, or data in separate files)
|
||||
- Load {expertAgentArch} for architecture guidance
|
||||
- Load {agentCompilation} for compilation best practices
|
||||
- Load {agentMenuPatterns} for menu implementation patterns
|
||||
- Utilize {expertAgentTemplate} to generate the agent output file {agentBuildOutput}/{agent-name}.agent.yaml
|
||||
- Create the Sidecar folder to hold the optional sidecar files if needed from plan in following steps at {agentBuildOutput}/{agent-name}/{agent-name}-sidecar
|
||||
- ELSE:
|
||||
- Load {simpleAgentArch} for architecture guidance
|
||||
- Load {agentCompilation} for compilation best practices
|
||||
- Load {agentMenuPatterns} for menu implementation patterns
|
||||
- Utilize {simpleAgentTemplate} to generate the agent output file {agentBuildOutput}/{agent-name}.agent.yaml
|
||||
|
||||
### 4. Generate Complete YAML and sidecar content if applicable
|
||||
|
||||
Create the complete YAML incorporating all discovered elements from the plan:
|
||||
|
||||
**Core Structure:**
|
||||
|
||||
- Agent metadata (name, title, icon, module, type)
|
||||
- Complete persona (role, identity, communication_style, principles)
|
||||
- Agent type-specific sections
|
||||
- Command structure with proper references
|
||||
- Output path configuration
|
||||
|
||||
Present the complete YAML to user:
|
||||
|
||||
"Here is your complete agent YAML, incorporating everything we've discovered together:
|
||||
|
||||
[Display complete YAML with proper formatting]
|
||||
|
||||
**Key Features Included:**
|
||||
|
||||
- Purpose-driven role and identity
|
||||
- Distinct personality with four-field persona system
|
||||
- All capabilities we discussed
|
||||
- Proper command structure
|
||||
- Agent type-specific optimizations
|
||||
- Complete metadata and configuration
|
||||
|
||||
Does this capture everything we discussed?"
|
||||
|
||||
### 5. Agent Type Specific Implementation
|
||||
|
||||
Ensure proper implementation based on agent type:
|
||||
|
||||
**Simple Agent:**
|
||||
|
||||
- All capabilities in YAML prompts section
|
||||
- No external file references
|
||||
- Self-contained execution logic
|
||||
|
||||
**Expert Agent:**
|
||||
|
||||
- Sidecar file references for knowledge base
|
||||
- Memory integration points
|
||||
- Personal workflow capabilities
|
||||
|
||||
Note: In the next step (Step 7: Validate), we will use the validation checklists ({simpleValidation}, {expertValidation}, {moduleValidation}) to ensure the generated YAML meets all standards.
|
||||
|
||||
Ensure all files generated are complete, and nothing from the plan has not been skipped, and then give a creational summary of what was done to the user in chat.
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save content to {agentBuildOutput}, 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
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated incorporating all discovered elements], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Complete YAML structure generated for correct agent type
|
||||
- All discovered elements properly integrated (purpose, persona, capabilities, identity)
|
||||
- Commands correctly structured with proper workflow/action references
|
||||
- Agent type specific optimizations implemented appropriately
|
||||
- Output paths configured correctly based on agent type
|
||||
- User confirms YAML captures all requirements from discovery process
|
||||
- Content properly saved to output file
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Duplicating auto-injected features (help, exit, activation handlers)
|
||||
- Not incorporating all discovered elements from previous steps
|
||||
- Invalid YAML syntax or structure
|
||||
- Incorrect agent type implementation
|
||||
- Missing user confirmation on YAML completeness
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,240 +0,0 @@
|
||||
---
|
||||
name: 'step-07-validate'
|
||||
description: 'Quality check with personality and technical validation'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
outputFile: '{bmb_creations_output_folder}/agent-validation-{project_name}.md'
|
||||
|
||||
# Validation Checklists (load based on agent type)
|
||||
simpleValidation: '../data/simple-agent-validation.md'
|
||||
expertValidation: '../data/expert-agent-validation.md'
|
||||
moduleValidation: '../data/module-agent-validation.md'
|
||||
|
||||
# Supporting References
|
||||
agentMenuPatterns: '../data/agent-menu-patterns.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 7: Quality Check and Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Run comprehensive validation conversationally while performing technical checks behind the scenes to ensure agent quality and compliance with BMAD standards.
|
||||
|
||||
## 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 quality assurance specialist who validates agent readiness through friendly conversation
|
||||
- ✅ 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 validation expertise, user brings their agent vision, together we ensure agent quality and readiness
|
||||
- ✅ Maintain collaborative supportive tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on comprehensive validation while maintaining conversational approach
|
||||
- 🚫 FORBIDDEN to expose user to raw technical errors or complex diagnostics
|
||||
- 💬 Approach: Present technical validation as friendly confirmations and celebrations
|
||||
- 📋 Run technical validation in background while presenting friendly interface to user
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Present validation as friendly confirmations and celebrations
|
||||
- 💾 Document all validation results and any resolutions
|
||||
- 🔧 Run technical validation in background without exposing complexity to user
|
||||
- 🚫 FORBIDDEN to overwhelm user with technical details or raw error messages
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Complete agent YAML from previous step
|
||||
- Focus: Quality validation and technical compliance verification
|
||||
- Limits: No agent modifications except for fixing identified issues
|
||||
- Dependencies: Complete agent YAML ready for validation
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Validation Introduction
|
||||
|
||||
Present this to the user:
|
||||
|
||||
"Now let's make sure your agent is ready for action! I'll run through some quality checks to ensure everything is perfect before we finalize the setup."
|
||||
|
||||
"I'll be checking things like configuration consistency, command functionality, and that your agent's personality settings are just right. This is like a final dress rehearsal before the big premiere!"
|
||||
|
||||
### 2. Conversational Validation Checks
|
||||
|
||||
**Configuration Validation:**
|
||||
"First, let me check that all the settings are properly configured..."
|
||||
[Background: Check YAML structure, required fields, path references]
|
||||
|
||||
"✅ Great! All your agent's core configurations look solid. The role, identity, and communication style are all properly aligned."
|
||||
|
||||
**Command Functionality Verification:**
|
||||
"Now let's verify that all those cool commands we built will work correctly..."
|
||||
[Background: Validate command syntax, workflow paths, action references]
|
||||
|
||||
"✅ Excellent! All your agent's commands are properly structured and ready to execute. I love how {{specific_command}} will help users with {{specific_benefit}}!"
|
||||
|
||||
**Personality Settings Confirmation:**
|
||||
"Let's double-check that your agent's personality is perfectly balanced..."
|
||||
[Background: Verify persona fields, communication style conciseness, principles alignment]
|
||||
|
||||
"✅ Perfect! Your agent has that {{personality_trait}} quality we were aiming for. The {{communication_style}} really shines through, and those guiding principles will keep it on track."
|
||||
|
||||
### 3. Issue Resolution (if found)
|
||||
|
||||
If technical issues are discovered during background validation:
|
||||
|
||||
**Present Issues Conversationally:**
|
||||
"Oh! I noticed something we can quickly fix..."
|
||||
|
||||
**Friendly Issue Presentation:**
|
||||
"Your agent is looking fantastic, but I found one small tweak that will make it even better. {{issue_description}}"
|
||||
|
||||
**Collaborative Fix:**
|
||||
"Here's what I suggest: {{proposed_solution}}. What do you think?"
|
||||
|
||||
**Apply and Confirm:**
|
||||
"There we go! Now your agent is even more awesome. The {{improvement_made}} will really help with {{benefit}}."
|
||||
|
||||
### 4. Technical Validation (Behind the Scenes)
|
||||
|
||||
**YAML Structure Validity:**
|
||||
|
||||
- Check proper indentation and syntax
|
||||
- Validate all required fields present
|
||||
- Ensure no duplicate keys or invalid values
|
||||
|
||||
**Menu Command Validation:**
|
||||
|
||||
- Verify all command triggers are valid
|
||||
- Check workflow paths exist or are properly marked as "to-be-created"
|
||||
- Validate action references are properly formatted
|
||||
|
||||
**Build Compilation Test:**
|
||||
|
||||
- Simulate agent compilation process
|
||||
- Check for auto-injection conflicts
|
||||
- Validate variable substitution
|
||||
|
||||
**Type-Specific Validation Checklists:**
|
||||
|
||||
Load the appropriate checklist based on agent type:
|
||||
|
||||
- **Simple Agents**: Load `{simpleValidation}` - validates self-contained structure, no sidecar
|
||||
- **Expert Agents**: Load `{expertValidation}` - validates sidecar paths, critical_actions, memory structure
|
||||
- **Module Agents**: Load `{moduleValidation}` - validates workflow integration paths, module membership
|
||||
|
||||
Additionally load supporting references:
|
||||
- `{agentMenuPatterns}` - menu trigger/description format validation
|
||||
- `{agentCompilation}` - compiler-added elements (don't validate presence)
|
||||
|
||||
### 5. Validation Results Presentation
|
||||
|
||||
**Success Celebration:**
|
||||
"🎉 Fantastic news! Your agent has passed all quality checks with flying colors!"
|
||||
|
||||
**Validation Summary:**
|
||||
"Here's what I confirmed:
|
||||
✅ Configuration is rock-solid
|
||||
✅ Commands are ready to execute
|
||||
✅ Personality is perfectly balanced
|
||||
✅ All technical requirements met
|
||||
✅ Ready for final setup and activation"
|
||||
|
||||
**Quality Badge Awarded:**
|
||||
"Your agent has earned the 'BMAD Quality Certified' badge! It's ready to help users with {{agent_purpose}}."
|
||||
|
||||
### 6. Document Validation Results
|
||||
|
||||
#### Content to Append (if applicable):
|
||||
|
||||
```markdown
|
||||
## Agent Validation Results
|
||||
|
||||
### Validation Checks Performed
|
||||
|
||||
- Configuration structure and syntax validation
|
||||
- Command functionality verification
|
||||
- Persona settings confirmation
|
||||
- Technical requirements compliance
|
||||
- Agent type specific validation
|
||||
|
||||
### Results Summary
|
||||
|
||||
✅ All validation checks passed successfully
|
||||
✅ Agent ready for setup and activation
|
||||
✅ Quality certification achieved
|
||||
|
||||
### Issues Resolved (if any)
|
||||
|
||||
[Documentation of any issues found and resolved]
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
Agent meets all BMAD quality standards and is ready for deployment.
|
||||
```
|
||||
|
||||
Save this content to `{outputFile}` for reference.
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save content to {outputFile}, 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
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [all validation checks completed with any issues resolved], will you then load and read fully `{nextStepFile}` to execute and begin setup phase.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All validation checks completed (configuration, commands, persona, technical)
|
||||
- YAML configuration confirmed valid and properly structured
|
||||
- Command functionality verified with proper workflow/action references
|
||||
- Personality settings confirmed balanced and aligned with agent purpose
|
||||
- Technical validation passed including syntax and compilation checks
|
||||
- Any issues found resolved conversationally with user collaboration
|
||||
- User confidence in agent quality established through successful validation
|
||||
- Content properly saved to output file
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Exposing users to raw technical errors or complex diagnostics
|
||||
- Not performing comprehensive validation checks
|
||||
- Missing or incomplete validation of critical agent components
|
||||
- Proceeding without resolving identified issues
|
||||
- Breaking conversational approach with technical jargon
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -0,0 +1,185 @@
|
||||
---
|
||||
name: 'step-06-build-simple'
|
||||
description: 'Generate Simple agent YAML from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}.agent.yaml'
|
||||
|
||||
# Template and Architecture
|
||||
simpleTemplate: ../templates/simple-agent.template.md
|
||||
simpleArch: ../data/simple-agent-architecture.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Assemble the agent plan content into a Simple agent YAML configuration using the template, producing a complete agent definition ready for validation.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **MUST** read all referenced files before beginning assembly
|
||||
- **MUST** use exact YAML structure from template
|
||||
- **MUST** preserve all plan content without modification
|
||||
- **MUST** maintain proper YAML indentation and formatting
|
||||
- **MUST NOT** deviate from template structure
|
||||
- **MUST** write output before asking validation question
|
||||
- **MUST** present validation choice clearly
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### File Loading Sequence
|
||||
1. Read `simpleTemplate` - provides the YAML structure
|
||||
2. Read `simpleArch` - defines Simple agent architecture rules
|
||||
3. Read `agentCompilation` - provides assembly guidelines
|
||||
4. Read `agentPlan` - contains structured content from steps 2-5
|
||||
|
||||
### YAML Assembly Process
|
||||
1. Parse template structure
|
||||
2. Extract content sections from agentPlan YAML
|
||||
3. Map plan content to template fields
|
||||
4. Validate YAML syntax before writing
|
||||
5. Write complete agent YAML to output path
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**INCLUDE:**
|
||||
- Template structure exactly as provided
|
||||
- All agent metadata from agentPlan
|
||||
- Persona, commands, and rules from plan
|
||||
- Configuration options specified
|
||||
|
||||
**EXCLUDE:**
|
||||
- Any content not in agentPlan
|
||||
- Sidecar file references (Simple agents don't use them)
|
||||
- Template placeholders (replace with actual content)
|
||||
- Comments or notes in final YAML
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Load Template and Architecture Files
|
||||
|
||||
Read the following files in order:
|
||||
- `simpleTemplate` - YAML structure template
|
||||
- `simpleArch` - Simple agent architecture definition
|
||||
- `agentCompilation` - Assembly instructions
|
||||
|
||||
**Verify:** All files loaded successfully.
|
||||
|
||||
### 2. Load Agent Plan
|
||||
|
||||
Read `agentPlan` which contains structured YAML from steps 2-5:
|
||||
- Step 2: Discovery findings
|
||||
- Step 3: Persona development
|
||||
- Step 4: Command structure
|
||||
- Step 5: Agent naming
|
||||
|
||||
**Verify:** Plan contains all required sections.
|
||||
|
||||
### 3. Assemble YAML Using Template
|
||||
|
||||
Execute the following assembly process:
|
||||
|
||||
1. **Parse Template Structure**
|
||||
- Identify all YAML fields
|
||||
- Note required vs optional fields
|
||||
- Map field types and formats
|
||||
|
||||
2. **Extract Plan Content**
|
||||
- Read agent metadata
|
||||
- Extract persona definition
|
||||
- Retrieve command specifications
|
||||
- Gather rules and constraints
|
||||
|
||||
3. **Map Content to Template**
|
||||
- Replace template placeholders with plan content
|
||||
- Maintain exact YAML structure
|
||||
- Preserve indentation and formatting
|
||||
- Validate field types and values
|
||||
|
||||
4. **Validate YAML Syntax**
|
||||
- Check proper indentation
|
||||
- Verify quote usage
|
||||
- Ensure list formatting
|
||||
- Confirm no syntax errors
|
||||
|
||||
**Verify:** YAML is valid, complete, and follows template structure.
|
||||
|
||||
### 4. Write Agent Build Output
|
||||
|
||||
Write the assembled YAML to `agentBuildOutput`:
|
||||
- Use exact output path from variable
|
||||
- Include all content without truncation
|
||||
- Maintain YAML formatting
|
||||
- Confirm write operation succeeded
|
||||
|
||||
**Verify:** File written successfully and contains complete YAML.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
### 6. Route Based on User Choice
|
||||
|
||||
**If user chooses "one-at-a-time":**
|
||||
- Proceed to `nextStepFile` (step-07a-plan-traceability.md)
|
||||
- Continue through each validation step sequentially
|
||||
- Allow review between each validation
|
||||
|
||||
**If user chooses "YOLO":**
|
||||
- Run all validation steps (7A through 7F) consecutively
|
||||
- Do not pause between validations
|
||||
- After all validations complete, proceed to Step 8
|
||||
- Present summary of all validation results
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
**SUCCESS looks like:**
|
||||
- Agent YAML file exists at specified output path
|
||||
- YAML is syntactically valid and well-formed
|
||||
- All template fields populated with plan content
|
||||
- Structure matches Simple agent architecture
|
||||
- User has selected validation approach
|
||||
- Clear next step identified
|
||||
|
||||
**FAILURE looks like:**
|
||||
- Template or architecture files not found
|
||||
- Agent plan missing required sections
|
||||
- YAML syntax errors in output
|
||||
- Content not properly mapped to template
|
||||
- File write operation fails
|
||||
- User selection unclear
|
||||
|
||||
## TRANSITION CRITERIA
|
||||
|
||||
**Ready for Step 7A when:**
|
||||
- Simple agent YAML successfully created
|
||||
- User chooses "one-at-a-time" validation
|
||||
|
||||
**Ready for Step 8 when:**
|
||||
- Simple agent YAML successfully created
|
||||
- User chooses "YOLO" validation
|
||||
- All validations (7A-7F) completed consecutively
|
||||
@@ -0,0 +1,201 @@
|
||||
---
|
||||
name: 'step-06-build-expert'
|
||||
description: 'Generate Expert agent YAML with sidecar from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
|
||||
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Template and Architecture
|
||||
expertTemplate: ../templates/expert-agent-template/expert-agent.template.md
|
||||
expertArch: ../data/expert-agent-architecture.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
criticalActions: ../data/critical-actions.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage for specialized operations, accessed via `{project-root}/_bmad/_memory/{sidecar-folder}/` paths in critical_actions.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created under `_bmad/_memory/`
|
||||
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations
|
||||
3. **TEMPLATE COMPLIANCE**: Follow expert-agent-template.md structure exactly
|
||||
4. **YAML VALIDATION**: Ensure valid YAML syntax with proper indentation (2-space)
|
||||
5. **EXISTING CHECK**: If agentYamlOutput exists, ask user before overwriting
|
||||
6. **NO DRIFT**: Use ONLY content from agentPlan - no additions or interpretations
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Phase 1: Load Architecture and Templates
|
||||
1. Read `expertTemplate` - defines YAML structure for Expert agents
|
||||
2. Read `expertArch` - architecture requirements for Expert-level agents
|
||||
3. Read `agentCompilation` - assembly rules for YAML generation
|
||||
4. Read `criticalActions` - validation requirements for critical_actions
|
||||
|
||||
### Phase 2: Load Agent Plan
|
||||
1. Read `agentPlan` containing all collected content from Steps 1-5
|
||||
2. Verify plan contains:
|
||||
- Agent type: "expert"
|
||||
- Sidecar folder name
|
||||
- Persona content
|
||||
- Commands structure
|
||||
- Critical actions (if applicable)
|
||||
|
||||
### Phase 3: Assemble Expert YAML
|
||||
Using expertTemplate as structure:
|
||||
|
||||
```yaml
|
||||
name: '{agent-name}'
|
||||
description: '{short-description}'
|
||||
type: 'expert'
|
||||
version: '1.0.0'
|
||||
|
||||
author:
|
||||
name: '{author}'
|
||||
created: '{date}'
|
||||
|
||||
persona: |
|
||||
{multi-line persona content from plan}
|
||||
|
||||
system-context: |
|
||||
{expanded context from plan}
|
||||
|
||||
capabilities:
|
||||
- {capability from plan}
|
||||
- {capability from plan}
|
||||
# ... all capabilities
|
||||
|
||||
critical-actions:
|
||||
- name: '{action-name}'
|
||||
description: '{what it does}'
|
||||
invocation: '{when/how to invoke}'
|
||||
implementation: |
|
||||
{multi-line implementation}
|
||||
output: '{expected-output}'
|
||||
sidecar-folder: '{sidecar-folder-name}'
|
||||
sidecar-files:
|
||||
- '{project-root}/_bmad/_memory/{sidecar-folder}/{file1}.md'
|
||||
- '{project-root}/_bmad/_memory/{sidecar-folder}/{file2}.md'
|
||||
# ... all critical actions referencing sidecar structure
|
||||
|
||||
commands:
|
||||
- name: '{command-name}'
|
||||
description: '{what command does}'
|
||||
steps:
|
||||
- {step 1}
|
||||
- {step 2}
|
||||
# ... all commands from plan
|
||||
|
||||
configuration:
|
||||
temperature: {temperature}
|
||||
max-tokens: {max-tokens}
|
||||
response-format: {format}
|
||||
# ... other configuration from plan
|
||||
|
||||
metadata:
|
||||
sidecar-folder: '{sidecar-folder-name}'
|
||||
sidecar-path: '{project-root}/_bmad/_memory/{sidecar-folder}/'
|
||||
agent-type: 'expert'
|
||||
memory-type: 'persistent'
|
||||
```
|
||||
|
||||
### Phase 4: Create Sidecar Structure
|
||||
|
||||
1. **Create Sidecar Directory**:
|
||||
- Path: `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
- Use `mkdir -p` to create full path
|
||||
|
||||
2. **Create Starter Files** (if specified in critical_actions):
|
||||
```bash
|
||||
touch _bmad/_memory/{sidecar-folder}/{file1}.md
|
||||
touch _bmad/_memory/{sidecar-folder}/{file2}.md
|
||||
```
|
||||
|
||||
3. **Add README to Sidecar**:
|
||||
```markdown
|
||||
# {sidecar-folder} Memory
|
||||
|
||||
This folder stores persistent memory for the **{agent-name}** Expert agent.
|
||||
|
||||
## Purpose
|
||||
{purpose from critical_actions}
|
||||
|
||||
## Files
|
||||
- {file1}.md: {description}
|
||||
- {file2}.md: {description}
|
||||
|
||||
## Access Pattern
|
||||
Agent accesses these files via: `{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
|
||||
```
|
||||
|
||||
### Phase 5: Write Agent YAML
|
||||
|
||||
1. Create `agentBuildOutput` directory: `mkdir -p {agentBuildOutput}`
|
||||
2. Write YAML to `agentYamlOutput`
|
||||
3. Confirm write success
|
||||
4. Display file location to user
|
||||
|
||||
### Phase 6: Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#phase-6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
- **USE ONLY**: Content from agentPlan, expertTemplate, expertArch, agentCompilation, criticalActions
|
||||
- **DO NOT ADD**: New capabilities, commands, or actions not in plan
|
||||
- **DO NOT INTERPRET**: Use exact language from plan
|
||||
- **DO NOT SKIP**: Any field in expertTemplate structure
|
||||
- **CRITICAL**: Expert agents MUST have sidecar-folder metadata
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
|
||||
This step produces TWO artifacts:
|
||||
1. **Agent YAML**: Complete expert agent definition at `{agentYamlOutput}`
|
||||
2. **Sidecar Structure**: Folder and files at `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
|
||||
Both must exist before proceeding to validation.
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ Agent YAML file created at expected location
|
||||
✅ Valid YAML syntax (no parse errors)
|
||||
✅ All template fields populated
|
||||
✅ Sidecar folder created under `_bmad/_memory/`
|
||||
✅ Sidecar folder contains starter files from critical_actions
|
||||
✅ critical_actions reference `{project-root}/_bmad/_memory/{sidecar-folder}/` paths
|
||||
✅ metadata.sidecar-folder populated
|
||||
✅ metadata.agent-type = "expert"
|
||||
✅ User validation choice received (one-at-a-time or YOLO)
|
||||
|
||||
## FAILURE MODES
|
||||
|
||||
❌ Missing required template fields
|
||||
❌ Invalid YAML syntax
|
||||
❌ Sidecar folder creation failed
|
||||
❌ critical_actions missing sidecar-folder references
|
||||
❌ agentPlan missing expert-specific content (sidecar-folder name)
|
||||
❌ File write permission errors
|
||||
@@ -0,0 +1,258 @@
|
||||
---
|
||||
name: 'step-06-build-module'
|
||||
description: 'Generate Module agent YAML from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
|
||||
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Template and Architecture (use expert as baseline)
|
||||
expertTemplate: ../templates/expert-agent-template/expert-agent.template.md
|
||||
expertArch: ../data/expert-agent-architecture.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
criticalActions: ../data/critical-actions.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
Assemble the Module agent YAML file from the approved plan, using the expert agent template as the baseline architecture and adding module-specific workflow integration paths and sidecar configuration.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
|
||||
1. **TEMPLATE BASELINE**: Module agents MUST use the expert agent template as their structural foundation - do not create custom templates
|
||||
|
||||
2. **PLAN ADHERENCE**: Extract content from agentPlan exactly as written - no enhancement, interpretation, or extrapolation
|
||||
|
||||
3. **MODULE SPECIFICITY**: Module agents require workflow integration paths and may need sidecar configuration for multi-workflow modules
|
||||
|
||||
4. **OUTPUT VALIDATION**: YAML must be valid, complete, and ready for immediate deployment
|
||||
|
||||
5. **LANGUAGE PRESERVATION**: Maintain any language choice configured in the plan throughout the YAML
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## PREPARATION PHASE
|
||||
|
||||
### 1. Load Expert Template Baseline
|
||||
```
|
||||
Read: expertTemplate
|
||||
Read: expertArch
|
||||
Read: agentCompilation
|
||||
Read: criticalActions
|
||||
```
|
||||
|
||||
**Purpose**: Understand the expert agent structure that serves as the Module agent baseline
|
||||
|
||||
**Validation**: Confirm expert template has all required sections (name, description, persona, instructions, tools, skills, etc.)
|
||||
|
||||
### 2. Load Agent Plan
|
||||
```
|
||||
Read: agentPlan (using dynamic path)
|
||||
```
|
||||
|
||||
**Validation**: Plan contains all mandatory sections:
|
||||
- Agent identity (name, description)
|
||||
- Persona profile
|
||||
- Command structure
|
||||
- Critical actions
|
||||
- Workflow integrations (module-specific)
|
||||
- Language choice (if configured)
|
||||
|
||||
### 3. Verify Output Directory
|
||||
```
|
||||
Bash: mkdir -p {agentBuildOutput}
|
||||
```
|
||||
|
||||
**Purpose**: Ensure output directory exists for the module agent
|
||||
|
||||
## ASSEMBLY PHASE
|
||||
|
||||
### 4. Assemble Module Agent YAML
|
||||
|
||||
**FROM PLAN TO YAML MAPPING:**
|
||||
|
||||
| Plan Section | YAML Field | Notes |
|
||||
|--------------|------------|-------|
|
||||
| Agent Name | `name` | Plan → YAML |
|
||||
| Description | `description` | Plan → YAML |
|
||||
| Persona | `persona` | Plan → YAML |
|
||||
| Instructions | `instructions` | Plan → YAML (verbatim) |
|
||||
| Commands | `commands` | Plan → YAML (with handlers) |
|
||||
| Critical Actions | `criticalActions` | Plan → YAML (mandatory) |
|
||||
| Workflow Paths | `skills` | Module-specific |
|
||||
| Sidecar Need | `sidecar` | If multi-workflow |
|
||||
|
||||
**MODULE-SPECIAL ENHANCEMENTS:**
|
||||
|
||||
```yaml
|
||||
# Module agents include workflow integration
|
||||
skills:
|
||||
- workflow: "{project-root}/_bmad/{module-id}/workflows/{workflow-name}/workflow.md"
|
||||
description: "From plan workflow list"
|
||||
- workflow: "{project-root}/_bmad/{module-id}/workflows/{another-workflow}/workflow.md"
|
||||
description: "From plan workflow list"
|
||||
|
||||
# Optional: Sidecar for complex modules
|
||||
sidecar:
|
||||
enabled: true
|
||||
workflows:
|
||||
- ref: "primary-workflow"
|
||||
type: "primary"
|
||||
- ref: "secondary-workflow"
|
||||
type: "support"
|
||||
```
|
||||
|
||||
**CRITICAL ACTIONS MAPPING:**
|
||||
```
|
||||
For each critical action in plan:
|
||||
1. Identify matching command in YAML
|
||||
2. Add `critical: true` flag
|
||||
3. Ensure handler references agent function
|
||||
```
|
||||
|
||||
### 5. Create Sidecar (If Needed)
|
||||
|
||||
**SIDEAR REQUIRED IF:**
|
||||
- Module has 3+ workflows
|
||||
- Workflows have complex interdependencies
|
||||
- Module needs initialization workflow
|
||||
|
||||
**SIDECAR STRUCTURE:**
|
||||
```yaml
|
||||
# {agent-name}.sidecar.yaml
|
||||
sidecar:
|
||||
module: "{module-id}"
|
||||
initialization:
|
||||
workflow: "workflow-init"
|
||||
required: true
|
||||
workflows:
|
||||
- name: "workflow-name"
|
||||
path: "workflows/{workflow-name}/workflow.md"
|
||||
type: "primary|support|utility"
|
||||
dependencies: []
|
||||
agent:
|
||||
path: "{agent-name}.agent.yaml"
|
||||
```
|
||||
|
||||
**IF SIDEAR NOT NEEDED**: Skip this step
|
||||
|
||||
### 6. Write Module Agent YAML
|
||||
```
|
||||
Write: agentYamlOutput (using dynamic path)
|
||||
Content: Assembled YAML from step 4
|
||||
```
|
||||
|
||||
**Validation Checklist:**
|
||||
- [ ] All plan fields present in YAML
|
||||
- [ ] Workflow paths are valid and correct
|
||||
- [ ] Critical actions flagged
|
||||
- [ ] Sidecar created (if needed) or skipped (if not)
|
||||
- [ ] YAML syntax is valid
|
||||
- [ ] Language choice preserved throughout
|
||||
|
||||
## COMPLETION PHASE
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Write agent YAML to {agentBuildOutput}/{agent-name}/{agent-name}.agent.yaml (or appropriate output path), update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
**USER RESPONSE HANDLING:**
|
||||
- **Option 1**: Proceed to step-07a-plan-traceability.md with sequential mode
|
||||
- **Option 2**: Proceed to step-07a-plan-traceability.md with yolo mode
|
||||
- **Invalid input**: Re-ask with options
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Reading expert template and architecture
|
||||
- Loading agent plan
|
||||
- Assembling Module agent YAML
|
||||
- Creating sidecar (if needed)
|
||||
- Writing valid YAML output
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Modifying plan content
|
||||
- Creating new template structures
|
||||
- Implementing agent code
|
||||
- Writing workflow files
|
||||
- Testing agent functionality
|
||||
|
||||
**DO NOT:**
|
||||
- Add commands not in plan
|
||||
- Modify persona from plan
|
||||
- Create custom template structures
|
||||
- Skip critical actions mapping
|
||||
- Assume sidecar need - evaluate based on workflow count
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
|
||||
**THIS STEP IS COMPLETE WHEN:**
|
||||
1. Module agent YAML file exists at agentYamlOutput path
|
||||
2. YAML contains all plan content correctly mapped
|
||||
3. Module-specific workflow paths are configured
|
||||
4. Sidecar is created (if needed) or correctly skipped (if not)
|
||||
5. User has chosen review mode (one-at-a-time or YOLO)
|
||||
6. Ready to proceed to step-07a-plan-traceability.md
|
||||
|
||||
**STOP BEFORE:**
|
||||
- Writing workflow implementations
|
||||
- Creating agent code files
|
||||
- Testing agent functionality
|
||||
- Deploying to active system
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
**COMPLETION:**
|
||||
- [ ] Module agent YAML exists with all required fields
|
||||
- [ ] All plan content accurately mapped to YAML
|
||||
- [ ] Workflow integration paths configured correctly
|
||||
- [ ] Critical actions properly flagged
|
||||
- [ ] Sidecar created or correctly skipped
|
||||
- [ ] YAML syntax is valid
|
||||
- [ ] User confirms review mode choice
|
||||
- [ ] Transitions to step-07a-plan-traceability.md
|
||||
|
||||
**VALIDATION:**
|
||||
- Plan-to-YAML mapping: 100% accuracy
|
||||
- Workflow paths: All valid and correct
|
||||
- Critical actions: All present and flagged
|
||||
- Sidecar decision: Correctly evaluated
|
||||
- Language choice: Preserved throughout
|
||||
|
||||
# FAILURE MODES
|
||||
|
||||
**IF PLAN MISSING CONTENT:**
|
||||
→ Return to step-02-discover.md to complete plan
|
||||
|
||||
**IF EXPERT TEMPLATE MISSING:**
|
||||
→ Raise error - template is mandatory baseline
|
||||
|
||||
**IF YAML SYNTAX ERROR:**
|
||||
→ Fix and retry write operation
|
||||
|
||||
**IF WORKFLOW PATHS INVALID:**
|
||||
→ Flag for review in traceability step
|
||||
|
||||
**IF USER ASKS FOR MODIFICATIONS:**
|
||||
→ Return to appropriate planning step (03-persona, 04-commands, or 05-name)
|
||||
@@ -0,0 +1,203 @@
|
||||
---
|
||||
name: 'step-07a-plan-traceability'
|
||||
description: 'Verify build matches original plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08b-metadata-validation.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
Verify that the built agent YAML file contains all elements specified in the original agent plan. This step ensures plan traceability - confirming that what we planned is what we actually built.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
- MUST load both agentPlan and builtYaml files before comparison
|
||||
- MUST compare ALL planned elements against built implementation
|
||||
- MUST report specific missing items, not just "something is missing"
|
||||
- MUST offer fix option before proceeding to next validation
|
||||
- MUST handle missing files gracefully (report clearly, don't crash)
|
||||
- MUST respect YOLO mode behavior (part of combined validation report)
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## File Loading Protocol
|
||||
1. Load agentPlan from `{bmb_creations_output_folder}/agent-plan-{agent_name}.md`
|
||||
2. Load builtYaml from `{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml`
|
||||
3. If either file is missing, report the specific missing file and stop comparison
|
||||
4. Use Read tool to access both files with absolute paths
|
||||
|
||||
## Comparison Protocol
|
||||
Compare the following categories systematically:
|
||||
|
||||
### 1. Metadata Comparison
|
||||
- Agent name
|
||||
- Description
|
||||
- Version
|
||||
- Author/creator information
|
||||
- Location/module path
|
||||
- Language settings (if specified in plan)
|
||||
|
||||
### 2. Persona Field Comparison
|
||||
For each field in persona section:
|
||||
- Check presence in built YAML
|
||||
- Verify field content matches planned intent
|
||||
- Note any significant deviations (minor wording differences ok)
|
||||
|
||||
### 3. Commands Comparison
|
||||
- Verify all planned commands are present
|
||||
- Check command names match
|
||||
- Verify command descriptions are present
|
||||
- Confirm critical actions are referenced
|
||||
|
||||
### 4. Critical Actions Comparison
|
||||
- Verify all planned critical_actions are present
|
||||
- Check action names match exactly
|
||||
- Verify action descriptions are present
|
||||
- Confirm each action has required fields
|
||||
|
||||
### 5. Additional Elements
|
||||
- Dependencies (if planned)
|
||||
- Configuration (if planned)
|
||||
- Installation instructions (if planned)
|
||||
|
||||
## Reporting Protocol
|
||||
Present findings in clear, structured format:
|
||||
|
||||
```
|
||||
PLAN TRACEABILITY REPORT
|
||||
========================
|
||||
|
||||
Agent: {agent_name}
|
||||
Plan File: {path to agent plan}
|
||||
Build File: {path to built YAML}
|
||||
|
||||
COMPARISON RESULTS:
|
||||
-------------------
|
||||
|
||||
✅ Metadata: All present / Missing: {list}
|
||||
✅ Persona Fields: All present / Missing: {list}
|
||||
✅ Commands: All present / Missing: {list}
|
||||
✅ Critical Actions: All present / Missing: {list}
|
||||
✅ Other Elements: All present / Missing: {list}
|
||||
|
||||
OVERALL STATUS: [PASS / FAIL]
|
||||
|
||||
```
|
||||
|
||||
If ANY elements are missing:
|
||||
- List each missing element with category
|
||||
- Provide specific location reference (what was planned)
|
||||
- Ask if user wants to fix items or continue anyway
|
||||
|
||||
## Menu Protocol
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified missing elements, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
If YOLO mode:
|
||||
- Include this report in combined validation report
|
||||
- Auto-select [C] Continue if all elements present
|
||||
- Auto-select [F] Fix if missing critical elements (name, commands)
|
||||
- Flag non-critical missing items in summary
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
- ONLY compare plan vs build - do NOT evaluate quality or correctness
|
||||
- Do NOT suggest improvements or changes beyond planned elements
|
||||
- Do NOT re-open persona/commands discovery - this is verification only
|
||||
- Fix option should return to step-06-build, not earlier steps
|
||||
- If plan file is ambiguous, note ambiguity but use reasonable interpretation
|
||||
|
||||
# SEQUENCE
|
||||
|
||||
## 1. Load Required Files
|
||||
```yaml
|
||||
action: read
|
||||
target:
|
||||
- agentPlan
|
||||
- builtYaml
|
||||
on_failure: report which file is missing and suggest resolution
|
||||
```
|
||||
|
||||
## 2. Perform Structured Comparison
|
||||
```yaml
|
||||
action: compare
|
||||
categories:
|
||||
- metadata
|
||||
- persona_fields
|
||||
- commands
|
||||
- critical_actions
|
||||
- other_elements
|
||||
method: systematic category-by-category check
|
||||
```
|
||||
|
||||
## 3. Generate Comparison Report
|
||||
```yaml
|
||||
action: report
|
||||
format: structured pass/fail with specific missing items
|
||||
output: console display + optional save to validation log
|
||||
```
|
||||
|
||||
## 4. Present Menu Options
|
||||
```yaml
|
||||
action: menu
|
||||
options:
|
||||
- F: Fix missing items
|
||||
- C: Continue to metadata validation
|
||||
- V: View detailed comparison (optional)
|
||||
default: C if pass, F if fail
|
||||
```
|
||||
|
||||
## 5. Handle User Choice
|
||||
- **[F] Fix Findings**: Apply auto-fixes to {builtYaml} for identified missing elements, then re-present menu
|
||||
- **[C] Continue**: Proceed to step-07b-metadata-validation
|
||||
- **[A] Advanced Elicitation**: Execute advanced elicitation workflow, then re-present menu
|
||||
- **[P] Party Mode**: Execute party mode workflow, then re-present menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [metadata validation].
|
||||
|
||||
# SUCCESS/FAILURE METRICS
|
||||
|
||||
## Success Criteria
|
||||
- All planned elements present in built YAML: **COMPLETE PASS**
|
||||
- Minor deviations (wording, formatting) but all core elements present: **PASS**
|
||||
- Missing elements identified and user chooses to continue: **PASS WITH NOTED DEFICIENCIES**
|
||||
|
||||
## Failure Criteria
|
||||
- Unable to load plan or build file: **BLOCKING FAILURE**
|
||||
- Critical elements missing (name, commands, or critical_actions): **FAIL**
|
||||
- Comparison cannot be completed due to file corruption: **BLOCKING FAILURE**
|
||||
|
||||
## Next Step Triggers
|
||||
- **PASS → step-07b-metadata-validation**
|
||||
- **PASS WITH DEFICIENCIES → step-07b-metadata-validation** (user choice)
|
||||
- **FAIL → step-06-build** (with specific fix instructions)
|
||||
- **BLOCKING FAILURE → STOP** (resolve file access issues first)
|
||||
|
||||
## YOLO Mode Behavior
|
||||
- Auto-fix missing critical elements by returning to build step
|
||||
- Log non-critical missing items for review but continue validation
|
||||
- Include traceability report in final YOLO summary
|
||||
- Do NOT stop for user confirmation unless plan file is completely missing
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
name: 'step-07b-metadata-validation'
|
||||
description: 'Validate agent metadata properties'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08c-persona-validation.md'
|
||||
agentMetadata: ../data/agent-metadata.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's metadata properties (name, description, version, tags, category, etc.) are properly formatted, complete, and follow BMAD standards.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All metadata fields must be verified
|
||||
- **ALWAYS load both reference documents** - agentMetadata.md AND the builtYaml
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the metadata validation reference from `{agentMetadata}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Extract the metadata section from the builtYaml
|
||||
4. Compare actual metadata against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] name: Present and non-empty
|
||||
- [ ] description: Present and non-empty
|
||||
- [ ] version: Present and follows semantic versioning (X.Y.Z)
|
||||
- [ ] category: Present and matches valid category
|
||||
- [ ] tags: Present as array, not empty
|
||||
|
||||
2. **Format Validation**
|
||||
- [ ] name: Uses kebab-case, no spaces
|
||||
- [ ] description: 50-200 characters (unless intentionally brief)
|
||||
- [ ] version: Follows semver pattern (e.g., 1.0.0)
|
||||
- [ ] tags: Array of lowercase strings with hyphens
|
||||
- [ ] category: Matches one of the allowed categories
|
||||
|
||||
3. **Content Quality**
|
||||
- [ ] description: Clear and concise, explains what the agent does
|
||||
- [ ] tags: Relevant to agent's purpose (3-7 tags recommended)
|
||||
- [ ] category: Most appropriate classification
|
||||
|
||||
4. **Standards Compliance**
|
||||
- [ ] No prohibited characters in fields
|
||||
- [ ] No redundant or conflicting information
|
||||
- [ ] Consistent formatting with other agents
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Required fields present
|
||||
✓ Version format valid (1.0.0)
|
||||
✓ Name follows kebab-case convention
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Description is brief (45 chars, recommended 50-200)
|
||||
⚠ Only 2 tags provided, 3-7 recommended
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Missing required field: version
|
||||
✗ Invalid version format: "v1.0" (should be "1.0.0")
|
||||
✗ Category "custom-type" not in allowed list
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Metadata section of agent.yaml (name, description, version, tags, category, author, license, etc.)
|
||||
- Referencing the agentMetadata.md validation rules
|
||||
- Comparing against BMAD standards
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Persona fields (handled in step-07c)
|
||||
- Menu items (handled in step-07d)
|
||||
- System architecture (handled in step-07e)
|
||||
- Capability implementation (handled in step-07f)
|
||||
|
||||
**DO NOT:**
|
||||
- Validate persona properties in this step
|
||||
- Suggest major feature additions
|
||||
- Question the agent's core purpose
|
||||
- Modify fields beyond metadata
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [persona validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, no failures, warnings are optional
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** Never proceed to next step if blocking failures exist and user hasn't acknowledged them.
|
||||
@@ -0,0 +1,161 @@
|
||||
---
|
||||
name: 'step-07c-persona-validation'
|
||||
description: 'Validate persona fields and principles'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08d-menu-validation.md'
|
||||
personaProperties: ../data/persona-properties.md
|
||||
principlesCrafting: ../data/principles-crafting.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's persona (role, tone, expertise, principles, constraints) is well-defined, consistent, and aligned with its purpose.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All persona fields must be verified
|
||||
- **ALWAYS load both reference documents** - personaProperties.md AND principlesCrafting.md
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the persona validation reference from `{personaProperties}`
|
||||
2. Read the principles crafting guide from `{principlesCrafting}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
4. Extract the persona section from the builtYaml
|
||||
5. Compare actual persona against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] role: Present, clear, and specific
|
||||
- [ ] tone: Present and appropriate to role
|
||||
- [ ] expertise: Present and relevant to agent's purpose
|
||||
- [ ] principles: Present as array, not empty (if applicable)
|
||||
- [ ] constraints: Present as array, not empty (if applicable)
|
||||
|
||||
2. **Content Quality - Role**
|
||||
- [ ] Role is specific (not generic like "assistant")
|
||||
- [ ] Role aligns with agent's purpose and menu items
|
||||
- [ ] Role is achievable within LLM capabilities
|
||||
- [ ] Role scope is appropriate (not too broad/narrow)
|
||||
|
||||
3. **Content Quality - Tone**
|
||||
- [ ] Tone is clearly defined (professional, friendly, authoritative, etc.)
|
||||
- [ ] Tone matches the role and target users
|
||||
- [ ] Tone is consistent throughout the definition
|
||||
- [ ] Tone examples or guidance provided if nuanced
|
||||
|
||||
4. **Content Quality - Expertise**
|
||||
- [ ] Expertise areas are relevant to role
|
||||
- [ ] Expertise claims are realistic for LLM
|
||||
- [ ] Expertise domains are specific (not just "knowledgeable")
|
||||
- [ ] Expertise supports the menu capabilities
|
||||
|
||||
5. **Content Quality - Principles**
|
||||
- [ ] Principles are actionable (not vague platitudes)
|
||||
- [ ] Principles guide behavior and decisions
|
||||
- [ ] Principles are consistent with role
|
||||
- [ ] 3-7 principles recommended (not overwhelming)
|
||||
- [ ] Each principle is clear and specific
|
||||
|
||||
6. **Content Quality - Constraints**
|
||||
- [ ] Constraints define boundaries clearly
|
||||
- [ ] Constraints are enforceable (measurable/observable)
|
||||
- [ ] Constraints prevent undesirable behaviors
|
||||
- [ ] Constraints don't contradict principles
|
||||
|
||||
7. **Consistency Checks**
|
||||
- [ ] Role, tone, expertise, principles all align
|
||||
- [ ] No contradictions between principles and constraints
|
||||
- [ ] Persona supports the menu items defined
|
||||
- [ ] Language and terminology consistent
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Role is specific and well-defined
|
||||
✓ Tone clearly articulated and appropriate
|
||||
✓ Expertise aligns with agent purpose
|
||||
✓ Principles are actionable and clear
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Only 2 principles provided, 3-7 recommended for richer guidance
|
||||
⚠ No constraints defined - consider adding boundaries
|
||||
⚠ Expertise areas are broad, could be more specific
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Role is generic ("assistant") - needs specificity
|
||||
✗ Tone undefined - creates inconsistent behavior
|
||||
✗ Principles are vague ("be helpful" - not actionable)
|
||||
✗ Contradiction: Principle says "be creative", constraint says "follow strict rules"
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Persona section of agent.yaml (role, tone, expertise, principles, constraints)
|
||||
- Referencing personaProperties.md and principlesCrafting.md
|
||||
- Evaluating persona clarity, specificity, and consistency
|
||||
- Checking alignment between persona elements
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Metadata fields (handled in step-07b)
|
||||
- Menu items (handled in step-07d)
|
||||
- System architecture (handled in step-07e)
|
||||
- Technical implementation details
|
||||
|
||||
**DO NOT:**
|
||||
- Validate metadata properties in this step
|
||||
- Question the agent's core purpose (that's for earlier steps)
|
||||
- Suggest additional menu items
|
||||
- Modify fields beyond persona
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [menu validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, persona is well-defined and consistent
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** A weak or generic persona is a blocking issue that should be fixed before proceeding.
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
name: 'step-07d-menu-validation'
|
||||
description: 'Validate menu items and patterns'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08e-structure-validation.md'
|
||||
agentMenuPatterns: ../data/agent-menu-patterns.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's menu (commands/tools) follows BMAD patterns, is well-structured, properly documented, and aligns with the agent's persona and purpose.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All menu items must be verified
|
||||
- **ALWAYS load the reference document** - agentMenuPatterns.md
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the menu patterns reference from `{agentMenuPatterns}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Extract the menu/commands section from the builtYaml
|
||||
4. Compare actual menu against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Menu Structure**
|
||||
- [ ] Menu section exists and is properly formatted
|
||||
- [ ] At least one menu item defined (unless intentionally tool-less)
|
||||
- [ ] Menu items follow proper YAML structure
|
||||
- [ ] Each item has required fields (name, description, pattern)
|
||||
|
||||
2. **Menu Item Requirements**
|
||||
For each menu item:
|
||||
- [ ] name: Present, unique, uses kebab-case
|
||||
- [ ] description: Clear and concise
|
||||
- [ ] pattern: Valid regex pattern or tool reference
|
||||
- [ ] scope: Appropriate scope defined (if applicable)
|
||||
|
||||
3. **Pattern Quality**
|
||||
- [ ] Patterns are valid and testable
|
||||
- [ ] Patterns are specific enough to match intended inputs
|
||||
- [ ] Patterns are not overly restrictive
|
||||
- [ ] Patterns use appropriate regex syntax
|
||||
|
||||
4. **Description Quality**
|
||||
- [ ] Each item has clear description
|
||||
- [ ] Descriptions explain what the item does
|
||||
- [ ] Descriptions are consistent in style
|
||||
- [ ] Descriptions help users understand when to use
|
||||
|
||||
5. **Alignment Checks**
|
||||
- [ ] Menu items align with agent's role/purpose
|
||||
- [ ] Menu items are supported by agent's expertise
|
||||
- [ ] Menu items fit within agent's constraints
|
||||
- [ ] Menu items are appropriate for target users
|
||||
|
||||
6. **Completeness**
|
||||
- [ ] Core capabilities for this role are covered
|
||||
- [ ] No obvious missing functionality
|
||||
- [ ] Menu scope is appropriate (not too sparse/overloaded)
|
||||
- [ ] Related functionality is grouped logically
|
||||
|
||||
7. **Standards Compliance**
|
||||
- [ ] No prohibited patterns or commands
|
||||
- [ ] No security vulnerabilities in patterns
|
||||
- [ ] No ambiguous or conflicting items
|
||||
- [ ] Consistent naming conventions
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Menu structure properly formatted
|
||||
✓ 5 menu items defined, all with required fields
|
||||
✓ All patterns are valid regex
|
||||
✓ Menu items align with agent role
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Item "analyze-data" description is vague
|
||||
⚠ No menu item for [common capability X]
|
||||
⚠ Pattern for "custom-command" very broad, may over-match
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Duplicate menu item name: "process" appears twice
|
||||
✗ Invalid regex pattern: "[unclosed bracket"
|
||||
✗ Menu item "system-admin" violates security guidelines
|
||||
✗ No menu items defined for agent type that requires tools
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Menu/commands section of agent.yaml
|
||||
- Referencing agentMenuPatterns.md
|
||||
- Menu structure, patterns, and alignment
|
||||
- Individual menu item validation
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Metadata fields (handled in step-07b)
|
||||
- Persona fields (handled in step-07c)
|
||||
- System architecture (handled in step-07e)
|
||||
- Workflow/capability implementation (handled in step-07f)
|
||||
|
||||
**DO NOT:**
|
||||
- Validate metadata or persona in this step
|
||||
- Suggest entirely new capabilities (that's for earlier steps)
|
||||
- Question whether menu items are "good enough" qualitatively beyond standards
|
||||
- Modify fields beyond menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [structure validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, menu is well-structured and aligned
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** Invalid regex patterns or security vulnerabilities in menu items are blocking issues.
|
||||
@@ -0,0 +1,306 @@
|
||||
---
|
||||
name: 'step-07e-structure-validation'
|
||||
description: 'Validate YAML structure and completeness'
|
||||
|
||||
# File References
|
||||
# Routes to 8F if Expert, else to 9
|
||||
nextStepFileExpert: './step-08f-sidecar-validation.md'
|
||||
nextStepFileSimple: './step-09-celebrate.md'
|
||||
simpleValidation: ../data/simple-agent-validation.md
|
||||
expertValidation: ../data/expert-agent-validation.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate the built agent YAML file for structural completeness and correctness against the appropriate validation checklist (simple or expert), then route to sidecar validation if needed or proceed to celebration.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
|
||||
1. **NEVER skip validation** - All agents must pass structural validation before completion
|
||||
2. **ALWAYS use the correct validation checklist** based on agent type (simple vs expert)
|
||||
3. **NEVER auto-fix without user consent** - Report issues and ask for permission
|
||||
4. **ALWAYS check hasSidecar flag** before determining next step routing
|
||||
5. **MUST load and parse the actual built YAML** - Not just show it, but validate it
|
||||
6. **ALWAYS provide clear, actionable feedback** for any validation failures
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## Context Awareness
|
||||
|
||||
- User is in the final validation phase
|
||||
- Agent has been built and written to disk
|
||||
- This is the "quality gate" before completion
|
||||
- User expects thorough but fair validation
|
||||
- Route depends on agent type (expert vs simple)
|
||||
|
||||
## User Expectations
|
||||
|
||||
- Clear validation results with specific issues identified
|
||||
- Line-number references for YAML problems
|
||||
- Option to fix issues or continue (if minor)
|
||||
- Logical routing based on agent type
|
||||
- Professional, constructive feedback tone
|
||||
|
||||
## Tone and Style
|
||||
|
||||
- Professional and thorough
|
||||
- Constructive, not pedantic
|
||||
- Clear prioritization of issues (critical vs optional)
|
||||
- Encouraging when validation passes
|
||||
- Actionable when issues are found
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
## What to Validate
|
||||
|
||||
- YAML syntax and structure
|
||||
- Required frontmatter fields presence
|
||||
- Required sections completeness
|
||||
- Field format correctness
|
||||
- Path validity (for references)
|
||||
- Agent type consistency (simple vs expert requirements)
|
||||
|
||||
## What NOT to Validate
|
||||
|
||||
- Artistic choices in descriptions
|
||||
- Persona writing style
|
||||
- Command naming creativity
|
||||
- Feature scope decisions
|
||||
|
||||
## When to Escalate
|
||||
|
||||
- Critical structural errors that break agent loading
|
||||
- Missing required fields
|
||||
- YAML syntax errors preventing file parsing
|
||||
- Path references that don't exist
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
## 1. Load Validation Context
|
||||
|
||||
```bash
|
||||
# Load the appropriate validation checklist based on agent type
|
||||
if agentType == "expert":
|
||||
validationFile = expertValidation
|
||||
else:
|
||||
validationFile = simpleValidation
|
||||
|
||||
# Load the built agent YAML
|
||||
builtAgent = read(builtYaml)
|
||||
|
||||
# Load compilation rules for reference
|
||||
compilationRules = read(agentCompilation)
|
||||
```
|
||||
|
||||
**Action:** Present a brief status message:
|
||||
```
|
||||
🔍 LOADING VALIDATION FRAMEWORK
|
||||
Agent Type: {detected type}
|
||||
Validation Standard: {simple|expert}
|
||||
Built File: {builtYaml path}
|
||||
```
|
||||
|
||||
## 2. Execute Structural Validation
|
||||
|
||||
Run systematic checks against the validation checklist:
|
||||
|
||||
### A. YAML Syntax Validation
|
||||
- Parse YAML without errors
|
||||
- Check indentation consistency
|
||||
- Validate proper escaping of special characters
|
||||
- Verify no duplicate keys
|
||||
|
||||
### B. Frontmatter Validation
|
||||
- All required fields present
|
||||
- Field values correct type (string, boolean, array)
|
||||
- No empty required fields
|
||||
- Proper array formatting
|
||||
|
||||
### C. Section Completeness
|
||||
- All required sections present (based on agent type)
|
||||
- Sections not empty unless explicitly optional
|
||||
- Proper markdown heading hierarchy
|
||||
|
||||
### D. Field-Level Validation
|
||||
- Path references exist and are valid
|
||||
- Boolean fields are actual booleans (not strings)
|
||||
- Array fields properly formatted
|
||||
- No malformed YAML structures
|
||||
|
||||
### E. Agent Type Specific Checks
|
||||
|
||||
**For Simple Agents:**
|
||||
- No sidecar requirements
|
||||
- Basic fields complete
|
||||
- No advanced configuration
|
||||
|
||||
**For Expert Agents:**
|
||||
- Sidecar flag set correctly
|
||||
- Sidecar folder path specified
|
||||
- All expert fields present
|
||||
- Advanced features properly configured
|
||||
|
||||
## 3. Generate Validation Report
|
||||
|
||||
Present findings in structured format:
|
||||
|
||||
```markdown
|
||||
# 🎯 STRUCTURAL VALIDATION REPORT
|
||||
|
||||
## Agent: {agent-name}
|
||||
Type: {simple|expert}
|
||||
File: {builtYaml}
|
||||
|
||||
---
|
||||
|
||||
## ✅ PASSED CHECKS ({count})
|
||||
{List of all validations that passed}
|
||||
|
||||
## ⚠️ ISSUES FOUND ({count})
|
||||
{If any issues, list each with:}
|
||||
### Issue #{number}: {type}
|
||||
**Severity:** [CRITICAL|MODERATE|MINOR]
|
||||
**Location:** Line {line} or Section {section}
|
||||
**Problem:** {clear description}
|
||||
**Impact:** {what this breaks}
|
||||
**Suggested Fix:** {specific action}
|
||||
|
||||
---
|
||||
|
||||
## 📊 VALIDATION SUMMARY
|
||||
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
|
||||
**Critical Issues:** {count}
|
||||
**Moderate Issues:** {count}
|
||||
**Minor Issues:** {count}
|
||||
**Can Load Safely:** [YES|NO]
|
||||
|
||||
---
|
||||
|
||||
{If PASSED}
|
||||
## 🎉 VALIDATION SUCCESSFUL
|
||||
Your agent YAML is structurally sound and ready for use!
|
||||
All required fields present and correctly formatted.
|
||||
|
||||
{If ISSUES FOUND}
|
||||
## 🔧 RECOMMENDED ACTIONS
|
||||
1. Address critical issues first
|
||||
2. Review moderate issues
|
||||
3. Minor issues can be deferred
|
||||
```
|
||||
|
||||
## 4. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFileExpert} or {nextStepFileSimple}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
|
||||
|
||||
### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
If [F] selected: Work through issues systematically
|
||||
- Load specific section needing fix
|
||||
- Present current state
|
||||
- Apply auto-fixes or guide user through corrections
|
||||
- Re-validate after each fix
|
||||
- Confirm resolution and re-present menu
|
||||
|
||||
If [C] selected:
|
||||
- Warn about implications if issues exist
|
||||
- Get explicit confirmation if critical issues
|
||||
- Document acceptance of issues
|
||||
- Proceed to routing
|
||||
|
||||
## 5. Route to Next Step
|
||||
|
||||
After validation passes or user chooses to continue:
|
||||
|
||||
### Check Agent Type and Route
|
||||
|
||||
```yaml
|
||||
# Check for sidecar requirement
|
||||
hasSidecar = checkBuiltYamlForSidecarFlag()
|
||||
|
||||
if hasSidecar == true:
|
||||
# Expert agent with sidecar
|
||||
nextStep = nextStepFileExpert
|
||||
routeMessage = """
|
||||
📦 Expert agent detected with sidecar configuration.
|
||||
→ Proceeding to sidecar validation (Step 7F)
|
||||
"""
|
||||
else:
|
||||
# Simple agent or expert without sidecar
|
||||
nextStep = nextStepFileSimple
|
||||
routeMessage = """
|
||||
✅ Simple agent validation complete.
|
||||
→ Proceeding to celebration (Step 8)
|
||||
"""
|
||||
```
|
||||
|
||||
**Action:** Present routing decision and transition:
|
||||
```markdown
|
||||
# 🚀 VALIDATION COMPLETE - ROUTING DECISION
|
||||
|
||||
{routeMessage}
|
||||
|
||||
**Next Step:** {nextStep filename}
|
||||
**Reason:** Agent type {simple|expert} with sidecar={hasSidecar}
|
||||
|
||||
Press [Enter] to continue to {next step description}...
|
||||
```
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFileExpert}` or `{nextStepFileSimple}` to execute and begin [sidecar validation or celebration].
|
||||
|
||||
**BEFORE proceeding to next step:**
|
||||
|
||||
1. ✅ Validation checklist executed completely
|
||||
2. ✅ All critical issues resolved or explicitly accepted
|
||||
3. ✅ User informed of routing decision
|
||||
4. ✅ Next step file path determined correctly
|
||||
5. ⚠️ **CRITICAL:** For expert agents, verify hasSidecar is TRUE before routing to 7F
|
||||
6. ⚠️ **CRITICAL:** For simple agents, verify hasSidecar is FALSE before routing to 8
|
||||
|
||||
**DO NOT PROCEED IF:**
|
||||
- YAML has critical syntax errors preventing loading
|
||||
- User has not acknowledged validation results
|
||||
- Routing logic is unclear or conflicting
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
## Step Complete When:
|
||||
- [ ] Validation report generated and presented
|
||||
- [ ] User has reviewed findings
|
||||
- [ ] Critical issues resolved or accepted
|
||||
- [ ] Routing decision communicated and confirmed
|
||||
- [ ] Next step path verified and ready
|
||||
|
||||
## Quality Indicators:
|
||||
- Validation thoroughness (all checklist items covered)
|
||||
- Issue identification clarity and specificity
|
||||
- User satisfaction with resolution process
|
||||
- Correct routing logic applied
|
||||
- Clear transition to next step
|
||||
|
||||
## Failure Modes:
|
||||
- Skipping validation checks
|
||||
- Auto-fixing without permission
|
||||
- Incorrect routing (simple→7F or expert→8 with sidecar)
|
||||
- Unclear or missing validation report
|
||||
- Proceeding with critical YAML errors
|
||||
@@ -0,0 +1,462 @@
|
||||
---
|
||||
name: 'step-07f-sidecar-validation'
|
||||
description: 'Validate sidecar structure and paths'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-09-celebrate.md'
|
||||
criticalActions: ../data/critical-actions.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
sidecarFolder: '{bmb_creations_output_folder}/{agent-name}/{agent-name}-sidecar/'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
# STEP GOAL
|
||||
|
||||
Validate the sidecar folder structure and referenced paths for Expert agents to ensure all sidecar files exist, are properly structured, and paths in the main agent YAML correctly reference them.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
|
||||
1. **ONLY runs for Expert agents** - Simple agents should never reach this step
|
||||
2. **MUST verify sidecar folder exists** before proceeding
|
||||
3. **ALWAYS cross-reference YAML paths** with actual files
|
||||
4. **NEVER create missing sidecar files** - Report issues, don't auto-fix
|
||||
5. **MUST validate sidecar file structure** for completeness
|
||||
6. **ALWAYS check critical actions file** if referenced
|
||||
7. **PROVIDE clear remediation steps** for any missing or malformed files
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## Context Awareness
|
||||
|
||||
- User has an Expert agent with sidecar configuration
|
||||
- Structural validation (7E) already passed
|
||||
- Sidecar folder should have been created during build
|
||||
- This is the final validation before celebration
|
||||
- Missing sidecar components may break agent functionality
|
||||
|
||||
## User Expectations
|
||||
|
||||
- Comprehensive sidecar structure validation
|
||||
- Clear identification of missing files
|
||||
- Path reference verification
|
||||
- Actionable remediation guidance
|
||||
- Professional but approachable tone
|
||||
|
||||
## Tone and Style
|
||||
|
||||
- Thorough and systematic
|
||||
- Clear and specific about issues
|
||||
- Solution-oriented (focus on how to fix)
|
||||
- Encouraging when sidecar is complete
|
||||
- Not pedantic about minor formatting issues
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
## What to Validate
|
||||
|
||||
- Sidecar folder existence and location
|
||||
- All referenced files exist in sidecar
|
||||
- Sidecar file structure completeness
|
||||
- Path references in main YAML accuracy
|
||||
- Critical actions file if referenced
|
||||
- File naming conventions
|
||||
- File content completeness (not empty)
|
||||
|
||||
## What NOT to Validate
|
||||
|
||||
- Content quality of sidecar files
|
||||
- Artistic choices in sidecar documentation
|
||||
- Optional sidecar components
|
||||
- File formatting preferences
|
||||
|
||||
## When to Escalate
|
||||
|
||||
- Sidecar folder completely missing
|
||||
- Critical files missing (actions, core modules)
|
||||
- Path references pointing to non-existent files
|
||||
- Empty sidecar files that should have content
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
## 1. Load Sidecar Context
|
||||
|
||||
```bash
|
||||
# Verify main agent YAML exists
|
||||
agentYaml = read(builtYaml)
|
||||
|
||||
# Extract sidecar path from YAML or use template default
|
||||
sidecarPath = extractSidecarPath(agentYaml) or sidecarFolder
|
||||
|
||||
# Check if sidecar folder exists
|
||||
sidecarExists = directoryExists(sidecarPath)
|
||||
|
||||
# Load critical actions reference if needed
|
||||
criticalActionsRef = read(criticalActions)
|
||||
```
|
||||
|
||||
**Action:** Present discovery status:
|
||||
```markdown
|
||||
🔍 SIDECAR VALIDATION INITIALIZED
|
||||
|
||||
Agent: {agent-name}
|
||||
Type: Expert (requires sidecar)
|
||||
|
||||
Main YAML: {builtYaml}
|
||||
Sidecar Path: {sidecarPath}
|
||||
|
||||
Status: {✅ Folder Found | ❌ Folder Missing}
|
||||
```
|
||||
|
||||
## 2. Validate Sidecar Structure
|
||||
|
||||
### A. Folder Existence Check
|
||||
|
||||
```markdown
|
||||
## 📁 FOLDER STRUCTURE VALIDATION
|
||||
|
||||
**Sidecar Location:** {sidecarPath}
|
||||
**Status:** [EXISTS | MISSING | WRONG LOCATION]
|
||||
```
|
||||
|
||||
If missing:
|
||||
```markdown
|
||||
❌ **CRITICAL ISSUE:** Sidecar folder not found!
|
||||
|
||||
**Expected Location:** {sidecarPath}
|
||||
|
||||
**Possible Causes:**
|
||||
1. Build process didn't create sidecar
|
||||
2. Sidecar path misconfigured in agent YAML
|
||||
3. Folder moved or deleted after build
|
||||
|
||||
**Required Action:**
|
||||
[ ] Re-run build process with sidecar enabled
|
||||
[ ] Verify sidecar configuration in agent YAML
|
||||
[ ] Check folder was created in correct location
|
||||
```
|
||||
|
||||
### B. Sidecar File Inventory
|
||||
|
||||
If folder exists, list all files:
|
||||
```bash
|
||||
sidecarFiles = listFiles(sidecarPath)
|
||||
```
|
||||
|
||||
```markdown
|
||||
## 📄 SIDECAR FILE INVENTORY
|
||||
|
||||
Found {count} files in sidecar:
|
||||
|
||||
{For each file:}
|
||||
- {filename} ({size} bytes)
|
||||
```
|
||||
|
||||
### C. Cross-Reference Validation
|
||||
|
||||
Extract all sidecar path references from agent YAML:
|
||||
```yaml
|
||||
# Common sidecar reference patterns
|
||||
sidecar:
|
||||
critical-actions: './{agent-name}-sidecar/critical-actions.md'
|
||||
modules:
|
||||
- path: './{agent-name}-sidecar/modules/module-01.md'
|
||||
```
|
||||
|
||||
Validate each reference:
|
||||
```markdown
|
||||
## 🔗 PATH REFERENCE VALIDATION
|
||||
|
||||
**Checked {count} references from agent YAML:**
|
||||
|
||||
{For each reference:}
|
||||
**Source:** {field in agent YAML}
|
||||
**Expected Path:** {referenced path}
|
||||
**Status:** [✅ Found | ❌ Missing | ⚠️ Wrong Location]
|
||||
```
|
||||
|
||||
## 3. Validate Sidecar File Contents
|
||||
|
||||
For each sidecar file found, check:
|
||||
|
||||
### A. File Completeness
|
||||
```markdown
|
||||
## 📋 FILE CONTENT VALIDATION
|
||||
|
||||
{For each file:}
|
||||
### {filename}
|
||||
**Size:** {bytes}
|
||||
**Status:** [✅ Complete | ⚠️ Empty | ❌ Too Small]
|
||||
**Last Modified:** {timestamp}
|
||||
```
|
||||
|
||||
### B. Critical Actions File (if present)
|
||||
|
||||
Special validation for critical-actions.md:
|
||||
```markdown
|
||||
## 🎯 CRITICAL ACTIONS VALIDATION
|
||||
|
||||
**File:** {sidecarPath}/critical-actions.md
|
||||
**Status:** [PRESENT | MISSING | EMPTY]
|
||||
|
||||
{If Present:}
|
||||
**Sections Found:**
|
||||
{List sections detected}
|
||||
|
||||
**Completeness:**
|
||||
[ ] Header/metadata present
|
||||
[ ] Actions defined
|
||||
[ ] No critical sections missing
|
||||
```
|
||||
|
||||
### C. Module Files (if present)
|
||||
|
||||
If sidecar contains modules:
|
||||
```markdown
|
||||
## 📚 MODULE VALIDATION
|
||||
|
||||
**Modules Found:** {count}
|
||||
|
||||
{For each module:}
|
||||
### {module-filename}
|
||||
**Status:** [✅ Valid | ⚠️ Issues Found]
|
||||
**Checks:**
|
||||
[ ] Frontmatter complete
|
||||
[ ] Content present
|
||||
[ ] References valid
|
||||
```
|
||||
|
||||
## 4. Generate Validation Report
|
||||
|
||||
```markdown
|
||||
# 🎯 SIDECAR VALIDATION REPORT
|
||||
|
||||
## Agent: {agent-name}
|
||||
Sidecar Path: {sidecarPath}
|
||||
Validation Date: {timestamp}
|
||||
|
||||
---
|
||||
|
||||
## ✅ VALIDATION CHECKS PASSED
|
||||
|
||||
**Folder Structure:**
|
||||
- [x] Sidecar folder exists
|
||||
- [x] Located at expected path
|
||||
- [x] Accessible and readable
|
||||
|
||||
**File Completeness:**
|
||||
- [x] All referenced files present
|
||||
- [x] No broken path references
|
||||
- [x] Files have content (not empty)
|
||||
|
||||
**Content Quality:**
|
||||
- [x] Critical actions complete
|
||||
- [x] Module files structured
|
||||
- [x] No obvious corruption
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ ISSUES IDENTIFIED ({count})
|
||||
|
||||
{If issues:}
|
||||
### Issue #{number}: {issue type}
|
||||
**Severity:** [CRITICAL|MODERATE|MINOR]
|
||||
**Component:** {file or folder}
|
||||
**Problem:** {clear description}
|
||||
**Impact:** {what this breaks}
|
||||
**Remediation:**
|
||||
1. {specific step 1}
|
||||
2. {specific step 2}
|
||||
3. {specific step 3}
|
||||
|
||||
{If no issues:}
|
||||
### 🎉 NO ISSUES FOUND
|
||||
Your agent's sidecar is complete and properly structured!
|
||||
All path references are valid and files are in place.
|
||||
|
||||
---
|
||||
|
||||
## 📊 SUMMARY
|
||||
|
||||
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
|
||||
**Files Validated:** {count}
|
||||
**Issues Found:** {count}
|
||||
**Critical Issues:** {count}
|
||||
**Sidecar Ready:** [YES|NO]
|
||||
|
||||
---
|
||||
|
||||
## 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} or sidecar files for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to celebration step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## 6. Issue Resolution (if [F] selected)
|
||||
|
||||
Work through each issue systematically:
|
||||
|
||||
**For Missing Files:**
|
||||
```markdown
|
||||
### 🔧 FIXING: Missing {filename}
|
||||
|
||||
**Required File:** {path}
|
||||
**Purpose:** {why it's needed}
|
||||
|
||||
**Option 1:** Re-run Build
|
||||
- Sidecar may not have been created completely
|
||||
- Return to build step and re-execute
|
||||
|
||||
**Option 2:** Manual Creation
|
||||
- Create file at: {full path}
|
||||
- Use template from: {template reference}
|
||||
- Minimum required content: {specification}
|
||||
|
||||
**Option 3:** Update References
|
||||
- Remove reference from agent YAML if not truly needed
|
||||
- Update path if file exists in different location
|
||||
|
||||
Which option? [1/2/3]:
|
||||
```
|
||||
|
||||
**For Broken Path References:**
|
||||
```markdown
|
||||
### 🔧 FIXING: Invalid Path Reference
|
||||
|
||||
**Reference Location:** {agent YAML field}
|
||||
**Current Path:** {incorrect path}
|
||||
**Expected File:** {filename}
|
||||
**Actual Location:** {where file actually is}
|
||||
|
||||
**Fix Options:**
|
||||
1. Update path in agent YAML to: {correct path}
|
||||
2. Move file to expected location: {expected path}
|
||||
3. Remove reference if file not needed
|
||||
|
||||
Which option? [1/2/3]:
|
||||
```
|
||||
|
||||
**For Empty/Malformed Files:**
|
||||
```markdown
|
||||
### 🔧 FIXING: {filename} - {Issue}
|
||||
|
||||
**Problem:** {empty/too small/malformed}
|
||||
**Location:** {full path}
|
||||
|
||||
**Remediation:**
|
||||
- View current content
|
||||
- Compare to template/standard
|
||||
- Add missing sections
|
||||
- Correct formatting
|
||||
|
||||
Ready to view and fix? [Y/N]:
|
||||
```
|
||||
|
||||
After each fix:
|
||||
- Re-validate the specific component
|
||||
- Confirm resolution
|
||||
- Move to next issue
|
||||
- Final re-validation when all complete
|
||||
|
||||
## 6. Route to Celebration
|
||||
|
||||
When validation passes or user chooses to continue:
|
||||
|
||||
```markdown
|
||||
# 🚀 SIDECAR VALIDATION COMPLETE
|
||||
|
||||
## Expert Agent: {agent-name}
|
||||
|
||||
✅ **Sidecar Structure:** Validated
|
||||
✅ **Path References:** All correct
|
||||
✅ **File Contents:** Complete
|
||||
|
||||
---
|
||||
|
||||
## 🎯 READY FOR CELEBRATION
|
||||
|
||||
Your Expert agent with sidecar is fully validated and ready!
|
||||
|
||||
**Next Step:** Celebration (Step 8)
|
||||
**Final Status:** All checks passed
|
||||
|
||||
Press [Enter] to proceed to celebration...
|
||||
```
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [celebration].
|
||||
|
||||
**BEFORE proceeding to Step 8:**
|
||||
|
||||
1. ✅ Sidecar folder exists and is accessible
|
||||
2. ✅ All referenced files present
|
||||
3. ✅ Path references validated
|
||||
4. ✅ File contents checked for completeness
|
||||
5. ✅ User informed of validation status
|
||||
6. ✅ Issues resolved or explicitly accepted
|
||||
7. ⚠️ **CRITICAL:** Only Expert agents should reach this step
|
||||
8. ⚠️ **CRITICAL:** Sidecar must be complete for agent to function
|
||||
|
||||
**DO NOT PROCEED IF:**
|
||||
- Sidecar folder completely missing
|
||||
- Critical files absent (actions, core modules)
|
||||
- User unaware of sidecar issues
|
||||
- Validation not completed
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
## Step Complete When:
|
||||
- [ ] Sidecar folder validated
|
||||
- [ ] All path references checked
|
||||
- [ ] File contents verified
|
||||
- [ ] Validation report presented
|
||||
- [ ] Issues resolved or accepted
|
||||
- [ ] User ready to proceed
|
||||
|
||||
## Quality Indicators:
|
||||
- Thoroughness of file inventory
|
||||
- Accuracy of path reference validation
|
||||
- Clarity of issue identification
|
||||
- Actionability of remediation steps
|
||||
- User confidence in sidecar completeness
|
||||
|
||||
## Failure Modes:
|
||||
- Missing sidecar folder completely
|
||||
- Skipping file existence checks
|
||||
- Not validating path references
|
||||
- Proceeding with critical files missing
|
||||
- Unclear validation report
|
||||
- Not providing remediation guidance
|
||||
|
||||
---
|
||||
|
||||
## 🎓 NOTE: Expert Agent Sidecars
|
||||
|
||||
Sidecars are what make Expert agents powerful. They enable:
|
||||
- Modular architecture
|
||||
- Separation of concerns
|
||||
- Easier updates and maintenance
|
||||
- Shared components across agents
|
||||
|
||||
A validated sidecar ensures your Expert agent will:
|
||||
- Load correctly at runtime
|
||||
- Find all referenced resources
|
||||
- Execute critical actions as defined
|
||||
- Provide the advanced capabilities designed
|
||||
|
||||
Take the time to validate thoroughly - it pays off in agent reliability!
|
||||
@@ -1,22 +1,23 @@
|
||||
---
|
||||
name: 'step-08-celebrate'
|
||||
name: 'step-09-celebrate'
|
||||
description: 'Celebrate completion and guide next steps for using the agent'
|
||||
|
||||
# File References
|
||||
thisStepFile: ./step-08-celebrate.md
|
||||
thisStepFile: ./step-09-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'
|
||||
---
|
||||
|
||||
# Step 8: Celebration and Next Steps
|
||||
# Step 9: Celebration and Installation Guidance
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Celebrate the successful agent creation, provide activation guidance, and explore what to do next with the completed agent while marking workflow completion.
|
||||
Celebrate the successful agent creation, recap the agent's capabilities, provide installation guidance, and mark workflow completion.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
@@ -29,32 +30,34 @@ Celebrate the successful agent creation, provide activation guidance, and explor
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a celebration coordinator who guides users through agent activation and next steps
|
||||
- ✅ 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 deployment expertise, user brings their excitement about their new agent, together we ensure successful agent activation and usage
|
||||
- ✅ 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 next steps
|
||||
- 🎯 Focus only on celebrating completion and guiding installation
|
||||
- 🚫 FORBIDDEN to end without marking workflow completion in frontmatter
|
||||
- 💬 Approach: Celebrate enthusiastically while providing practical guidance
|
||||
- 📋 Ensure user understands activation steps and agent capabilities
|
||||
- 💬 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 activation guidance and next steps
|
||||
- 📖 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, activation guidance, and workflow completion
|
||||
- Limits: No agent modifications, only usage guidance and celebration
|
||||
- Dependencies: Complete agent ready for activation
|
||||
- Focus: Celebration, installation guidance, and workflow completion
|
||||
- Limits: No agent modifications, only installation guidance and celebration
|
||||
- Dependencies: Complete agent ready for installation
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
@@ -106,26 +109,46 @@ Present enthusiastic celebration:
|
||||
- 'Tell me about your capabilities'
|
||||
- 'Help me with [specific task related to agent purpose]'"
|
||||
|
||||
### 4. Next Steps Exploration
|
||||
### 4. Installation Guidance
|
||||
|
||||
**Immediate Next Steps:**
|
||||
"Now that {agent_name} is ready, what would you like to do first?"
|
||||
**Making Your Agent Installable:**
|
||||
"Now that {agent_name} is complete, let's get it installed and ready to use!"
|
||||
|
||||
**Options to Explore:**
|
||||
**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:"
|
||||
|
||||
- **Test drive:** Try out different commands and capabilities
|
||||
- **Customize:** Fine-tune personality or add new commands
|
||||
- **Integrate:** Set up {agent_name} in your workflow
|
||||
- **Share:** Tell others about your new agent
|
||||
- **Expand:** Plan additional agents or capabilities
|
||||
**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
|
||||
|
||||
**Future Possibilities:**
|
||||
"As you use {agent_name}, you might discover:
|
||||
**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
|
||||
```
|
||||
|
||||
- New capabilities you'd like to add
|
||||
- Other agents that would complement this one
|
||||
- Ways to integrate {agent_name} into larger workflows
|
||||
- Opportunities to share {agent_name} with your team"
|
||||
**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
|
||||
|
||||
@@ -139,7 +162,7 @@ Present enthusiastic celebration:
|
||||
- **Name:** {agent_name}
|
||||
- **Type:** {agent_type}
|
||||
- **Purpose:** {agent_purpose}
|
||||
- **Status:** Ready for activation
|
||||
- **Status:** Ready for installation
|
||||
|
||||
### File Locations
|
||||
|
||||
@@ -147,13 +170,18 @@ Present enthusiastic celebration:
|
||||
- **Compiled Version:** {compiled_agent_path}
|
||||
- **Customization:** {customization_file_path}
|
||||
|
||||
### Activation Guidance
|
||||
### Installation
|
||||
|
||||
[Steps for activating and using the agent]
|
||||
Package your agent as a standalone module with `module.yaml` containing `unitary: true`.
|
||||
See: {installationDocs}
|
||||
|
||||
### Next Steps
|
||||
### Quick Start
|
||||
|
||||
[Ideas for using and expanding the agent]
|
||||
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.
|
||||
@@ -161,32 +189,32 @@ Save this content to `{outputFile}` for reference.
|
||||
### 6. Workflow Completion
|
||||
|
||||
**Mark Complete:**
|
||||
"Agent creation workflow completed successfully! {agent_name} is ready to help users and make a real difference."
|
||||
"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 deployment-ready configuration. Amazing work!"
|
||||
"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: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Complete"
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF X: Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY complete workflow when user selects 'C'
|
||||
- ONLY complete workflow when user selects 'X'
|
||||
- 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 complete option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for activation.
|
||||
ONLY WHEN [X exit option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
|
||||
|
||||
---
|
||||
|
||||
@@ -195,20 +223,22 @@ ONLY WHEN [C complete option] is selected and [workflow completion marked in fro
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Enthusiastic celebration of agent creation achievement
|
||||
- Clear activation guidance and next steps provided
|
||||
- Clear installation guidance provided
|
||||
- Agent capabilities and value clearly communicated
|
||||
- User confidence in agent usage established
|
||||
- Installation documentation link shared with context
|
||||
- Module structure and packaging explained
|
||||
- User confidence in agent installation established
|
||||
- Workflow properly marked as complete in frontmatter
|
||||
- Future possibilities and expansion opportunities explored
|
||||
- Content properly saved to output file
|
||||
- Menu presented with completion option
|
||||
- Menu presented with exit option
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Ending without marking workflow completion
|
||||
- Not providing clear activation guidance
|
||||
- Not providing clear installation guidance
|
||||
- Missing celebration of achievement
|
||||
- Not ensuring user understands next steps
|
||||
- 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