remove legacy workflows from bmb that were upgraded to step sharded flows and prep .13 changelog
This commit is contained in:
Brian Madison
parent
47ad645f22
commit
9223174f40
166
CHANGELOG.md
166
CHANGELOG.md
|
|
@ -1,16 +1,164 @@
|
||||||
# Changelog
|
# Changelog
|
||||||
|
|
||||||
## [Unreleased]
|
## [6.0.0-alpha.13]
|
||||||
|
|
||||||
### Added
|
**Release: November 30, 2025**
|
||||||
|
|
||||||
- **Playwright Utils Integration**: Test Architect now supports `@seontechnologies/playwright-utils` integration
|
### 🏗️ Revolutionary Workflow Architecture
|
||||||
- Installation prompt with `use_playwright_utils` configuration flag (mirrors tea_use_mcp_enhancements pattern)
|
|
||||||
- 11 comprehensive knowledge fragments covering ALL utilities: overview, api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
|
**Granular Step-File Workflow System (NEW in alpha.13):**
|
||||||
- Adaptive workflow recommendations in 6 workflows: automate (CRITICAL), framework, test-review, ci, atdd, test-design (light mention)
|
|
||||||
- 32 total knowledge fragments (21 core patterns + 11 playwright-utils)
|
- **Multi-Menu Support**: Workflows now support granular step-file architecture with dynamic menu generation
|
||||||
- Context-aware fragment loading preserves existing behavior when flag is false
|
- **Sharded Workflows**: Complete conversion of Phase 1 and 2 workflows to stepwise sharded architecture
|
||||||
- Production-ready utilities from SEON Technologies now integrated with TEA's proven testing patterns
|
- **Improved Performance**: Reduced file loading times and eliminated time-based estimates throughout
|
||||||
|
- **Workflow Builder**: New dedicated workflow builder for creating stepwise workflows
|
||||||
|
- **PRD Workflow**: First completely reworked sharded workflow resolving Sonnet compatibility issues
|
||||||
|
|
||||||
|
**Core Workflow Transformations:**
|
||||||
|
|
||||||
|
- Phase 1 and 2 workflows completely converted to sharded step-flow architecture
|
||||||
|
- UX Design workflow converted to sharded step workflow
|
||||||
|
- Brainstorming, Research, and Party Mode updated to use sharded step-flow workflows
|
||||||
|
- Architecture workflows enhanced with step sharding and performance improvements
|
||||||
|
|
||||||
|
### 🎯 Code Review & Development Enhancement
|
||||||
|
|
||||||
|
**Advanced Code Review System:**
|
||||||
|
|
||||||
|
- **Adversarial Code Review**: Quick-dev workflow now recommends adversarial review approach for higher quality
|
||||||
|
- **Multi-LLM Strategy**: Dev-story workflow recommends different LLM models for code review tasks
|
||||||
|
- **Agent Compiler Optimization**: Complete handler cleanup and performance improvements
|
||||||
|
|
||||||
|
### 🤖 Agent System Revolution
|
||||||
|
|
||||||
|
**Universal Custom Agent Support:**
|
||||||
|
|
||||||
|
- **Complete IDE Coverage**: Custom agent support extended to ALL remaining IDEs
|
||||||
|
- **Antigravity IDE Integration**: Added custom agent support with proper gitignore configuration
|
||||||
|
- **Multiple Source Locations**: Compile agents now checks multiple source locations for better discovery
|
||||||
|
- **Persona Name Display**: Fixed proper persona names display in custom agent manifests
|
||||||
|
- **New IDE Support**: Added support for Rovo Dev IDE
|
||||||
|
|
||||||
|
**Agent Creation & Management:**
|
||||||
|
|
||||||
|
- **Improved Creation Workflow**: Enhanced agent creation workflow with better documentation
|
||||||
|
- **Parameter Clarity**: Renamed agent-install parameters for better understanding
|
||||||
|
- **Menu Organization**: BMad Agents menu items logically ordered with optional/recommended/required tags
|
||||||
|
- **GitHub Migration**: GitHub integration now uses agents folder instead of chatmodes
|
||||||
|
|
||||||
|
### 🔧 Phase 4 & Sprint Evolution
|
||||||
|
|
||||||
|
**Complete Phase 4 Transformation:**
|
||||||
|
|
||||||
|
- **Simplified Architecture**: Phase 4 workflows completely transformed - simpler, faster, better results
|
||||||
|
- **Sprint Planning Integration**: Unified sprint planning with placeholders for Jira, Linear, and Trello integration
|
||||||
|
- **Status Management**: Better status loading and updating for Phase 4 artifacts
|
||||||
|
- **Workflow Reduction**: Phase 4 streamlined to single sprint planning item with clear validation
|
||||||
|
- **Dynamic Workflows**: All Level 1-3 workflows now dynamically suggest next steps based on context
|
||||||
|
|
||||||
|
### 🧪 Testing Infrastructure Expansion
|
||||||
|
|
||||||
|
**Playwright Utils Integration:**
|
||||||
|
|
||||||
|
- Test Architect now supports `@seontechnologies/playwright-utils` integration
|
||||||
|
- Installation prompt with `use_playwright_utils` configuration flag
|
||||||
|
- 11 comprehensive knowledge fragments covering ALL utilities
|
||||||
|
- Adaptive workflow recommendations across 6 testing workflows
|
||||||
|
- Production-ready utilities from SEON Technologies integrated with TEA patterns
|
||||||
|
|
||||||
|
**Testing Environment:**
|
||||||
|
|
||||||
|
- **Web Bundle Support**: Enabled web bundles for test and development environments
|
||||||
|
- **Test Architecture**: Enhanced test design for architecture level (Phase 3) testing
|
||||||
|
|
||||||
|
### 📦 Installation & Configuration
|
||||||
|
|
||||||
|
**Installer Improvements:**
|
||||||
|
|
||||||
|
- **Cleanup Options**: Installer now allows cleanup of unneeded files during upgrades
|
||||||
|
- **Username Default**: Installer now defaults to system username for better UX
|
||||||
|
- **IDE Selection**: Added empty IDE selection warning and promoted Antigravity to recommended
|
||||||
|
- **NPM Vulnerabilities**: Resolved all npm vulnerabilities for enhanced security
|
||||||
|
- **Documentation Installation**: Made documentation installation optional to reduce footprint
|
||||||
|
|
||||||
|
**Text-to-Speech from AgentVibes optional Integration:**
|
||||||
|
|
||||||
|
- **TTS_INJECTION System**: Complete text-to-speech integration via injection system
|
||||||
|
- **Agent Vibes**: Enhanced with TTS capabilities for voice feedback
|
||||||
|
|
||||||
|
### 🛠️ Tool & IDE Updates
|
||||||
|
|
||||||
|
**IDE Tool Enhancements:**
|
||||||
|
|
||||||
|
- **GitHub Copilot**: Fixed tool names consistency across workflows
|
||||||
|
- **KiloCode Integration**: Gave kilocode tool proper access to bmad modes
|
||||||
|
- **Code Quality**: Added radix parameter to parseInt() calls for better reliability
|
||||||
|
- **Agent Menu Optimization**: Improved agent performance in Claude Code slash commands
|
||||||
|
|
||||||
|
### 📚 Documentation & Standards
|
||||||
|
|
||||||
|
**Documentation Cleanup:**
|
||||||
|
|
||||||
|
- **Installation Guide**: Removed fluff and updated with npx support
|
||||||
|
- **Workflow Documentation**: Fixed documentation by removing non-existent workflows and Mermaid diagrams
|
||||||
|
- **Phase Numbering**: Fixed phase numbering consistency throughout documentation
|
||||||
|
- **Package References**: Corrected incorrect npm package references
|
||||||
|
|
||||||
|
**Workflow Compliance:**
|
||||||
|
|
||||||
|
- **Validation Checks**: Enhanced workflow validation checks for compliance
|
||||||
|
- **Product Brief**: Updated to comply with documented workflow standards
|
||||||
|
- **Status Integration**: Workflow-status can now call workflow-init for better integration
|
||||||
|
|
||||||
|
### 🔍 Legacy Workflow Cleanup
|
||||||
|
|
||||||
|
**Deprecated Workflows Removed:**
|
||||||
|
|
||||||
|
- **Audit Workflow**: Completely removed audit workflow and all associated files
|
||||||
|
- **Convert Legacy**: Removed legacy conversion utilities
|
||||||
|
- **Create/Edit Workflows**: Removed old workflow creation and editing workflows
|
||||||
|
- **Clean Architecture**: Simplified workflow structure by removing deprecated legacy workflows
|
||||||
|
|
||||||
|
### 🐛 Technical Fixes
|
||||||
|
|
||||||
|
**System Improvements:**
|
||||||
|
|
||||||
|
- **File Path Handling**: Fixed various file path issues across workflows
|
||||||
|
- **Manifest Updates**: Updated manifest to use agents folder structure
|
||||||
|
- **Web Bundle Configuration**: Fixed web bundle configurations for better compatibility
|
||||||
|
- **CSV Column Mismatch**: Fixed manifest schema upgrade issues
|
||||||
|
|
||||||
|
### ⚠️ Breaking Changes
|
||||||
|
|
||||||
|
**Workflow Architecture:**
|
||||||
|
|
||||||
|
- All legacy workflows have been removed - ensure you're using the new stepwise sharded workflows
|
||||||
|
- Phase 4 completely restructured - update any automation expecting old Phase 4 structure
|
||||||
|
- Epic creation now requires architectural context (moved to Phase 3 in previous release)
|
||||||
|
|
||||||
|
**Agent System:**
|
||||||
|
|
||||||
|
- Custom agents now require proper compilation - use the new agent creation workflow
|
||||||
|
- GitHub integration moved from chatmodes to agents folder - update any references
|
||||||
|
|
||||||
|
### 📊 Impact Summary
|
||||||
|
|
||||||
|
**New in alpha.13:**
|
||||||
|
|
||||||
|
- **Stepwise Workflow Architecture**: Complete transformation of all workflows to granular step-file system
|
||||||
|
- **Universal Custom Agent Support**: Extended to ALL IDEs with improved creation workflow
|
||||||
|
- **Phase 4 Revolution**: Completely restructured with sprint planning integration
|
||||||
|
- **Legacy Cleanup**: Removed all deprecated workflows for cleaner system
|
||||||
|
- **Advanced Code Review**: New adversarial review approach with multi-LLM strategy
|
||||||
|
- **Text-to-Speech**: Full TTS integration for voice feedback
|
||||||
|
- **Testing Expansion**: Playwright utils integration across all testing workflows
|
||||||
|
|
||||||
|
**Enhanced from alpha.12:**
|
||||||
|
|
||||||
|
- **Performance**: Improved file loading and removed time-based estimates
|
||||||
|
- **Documentation**: Complete cleanup with accurate references
|
||||||
|
- **Installer**: Better UX with cleanup options and improved defaults
|
||||||
|
- **Agent System**: More reliable compilation and better persona handling
|
||||||
|
|
||||||
## [6.0.0-alpha.12]
|
## [6.0.0-alpha.12]
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -5,6 +5,8 @@ Specialized tools and workflows for creating, customizing, and extending BMad co
|
||||||
## Table of Contents
|
## Table of Contents
|
||||||
|
|
||||||
- [Module Structure](#module-structure)
|
- [Module Structure](#module-structure)
|
||||||
|
- [Documentation](#documentation)
|
||||||
|
- [Reference Materials](#reference-materials)
|
||||||
- [Core Workflows](#core-workflows)
|
- [Core Workflows](#core-workflows)
|
||||||
- [Agent Types](#agent-types)
|
- [Agent Types](#agent-types)
|
||||||
- [Quick Start](#quick-start)
|
- [Quick Start](#quick-start)
|
||||||
|
|
@ -16,124 +18,172 @@ Specialized tools and workflows for creating, customizing, and extending BMad co
|
||||||
|
|
||||||
**BMad Builder** - Master builder agent orchestrating all creation workflows with deep knowledge of BMad architecture and conventions.
|
**BMad Builder** - Master builder agent orchestrating all creation workflows with deep knowledge of BMad architecture and conventions.
|
||||||
|
|
||||||
|
- Location: `.bmad/bmb/agents/bmad-builder.md`
|
||||||
|
|
||||||
### 📋 Workflows
|
### 📋 Workflows
|
||||||
|
|
||||||
Comprehensive suite for building and maintaining BMad components.
|
**Active Workflows** (Step-File Architecture)
|
||||||
|
|
||||||
|
- Location: `src/modules/bmb/workflows/`
|
||||||
|
- 5 core workflows with 41 step files total
|
||||||
|
- Template-based execution with JIT loading
|
||||||
|
|
||||||
|
**Legacy Workflows** (Being Migrated)
|
||||||
|
|
||||||
|
- Location: `src/modules/bmb/workflows-legacy/`
|
||||||
|
- Module-specific workflows pending conversion to step-file architecture
|
||||||
|
|
||||||
|
### 📚 Documentation
|
||||||
|
|
||||||
|
- Location: `src/modules/bmb/docs/`
|
||||||
|
- Comprehensive guides for agents and workflows
|
||||||
|
- Architecture patterns and best practices
|
||||||
|
|
||||||
|
### 🔍 Reference Materials
|
||||||
|
|
||||||
|
- Location: `src/modules/bmb/reference/`
|
||||||
|
- Working examples of agents and workflows
|
||||||
|
- Template patterns and implementation guides
|
||||||
|
|
||||||
|
## Documentation
|
||||||
|
|
||||||
|
### 📖 Agent Documentation
|
||||||
|
|
||||||
|
- **[Agent Index](./docs/agents/index.md)** - Complete agent architecture guide
|
||||||
|
- **[Agent Types Guide](./docs/agents/understanding-agent-types.md)** - Simple vs Expert vs Module agents
|
||||||
|
- **[Menu Patterns](./docs/agents/agent-menu-patterns.md)** - YAML menu design and handler types
|
||||||
|
- **[Agent Compilation](./docs/agents/agent-compilation.md)** - Auto-injection rules and compilation process
|
||||||
|
|
||||||
|
### 📋 Workflow Documentation
|
||||||
|
|
||||||
|
- **[Workflow Index](./docs/workflows/index.md)** - Core workflow system overview
|
||||||
|
- **[Architecture Guide](./docs/workflows/architecture.md)** - Step-file design and JIT loading
|
||||||
|
- **[Template System](./docs/workflows/step-template.md)** - Standard step file template
|
||||||
|
- **[Intent vs Prescriptive](./docs/workflows/intent-vs-prescriptive-spectrum.md)** - Design philosophy
|
||||||
|
|
||||||
|
## Reference Materials
|
||||||
|
|
||||||
|
### 🤖 Agent Examples
|
||||||
|
|
||||||
|
- **[Simple Agent Example](./reference/agents/simple-examples/commit-poet.agent.yaml)** - Self-contained agent
|
||||||
|
- **[Expert Agent Example](./reference/agents/expert-examples/journal-keeper/)** - Agent with persistent memory
|
||||||
|
- **[Module Agent Examples](./reference/agents/module-examples/)** - Integration patterns (BMM, CIS)
|
||||||
|
|
||||||
|
### 📋 Workflow Examples
|
||||||
|
|
||||||
|
- **[Meal Prep & Nutrition](./reference/workflows/meal-prep-nutrition/)** - Complete step-file workflow demonstration
|
||||||
|
- **Template patterns** for document generation and state management
|
||||||
|
|
||||||
## Core Workflows
|
## Core Workflows
|
||||||
|
|
||||||
### Creation Workflows
|
### Creation Workflows (Step-File Architecture)
|
||||||
|
|
||||||
**[create-agent](./workflows/create-agent/README.md)** - Build BMad agents
|
**[create-agent](./workflows/create-agent/)** - Build BMad agents
|
||||||
|
|
||||||
- Interactive persona development
|
- 11 guided steps from brainstorming to celebration
|
||||||
- Command structure design
|
- 18 reference data files with validation checklists
|
||||||
- YAML source compilation to .md
|
- Template-based agent generation
|
||||||
|
|
||||||
**[create-workflow](./workflows/create-workflow/README.md)** - Design workflows
|
**[create-workflow](./workflows/create-workflow/)** - Design workflows
|
||||||
|
|
||||||
- Structured multi-step processes
|
- 12 structured steps from init to review
|
||||||
- Configuration validation
|
- 9 template files for workflow creation
|
||||||
- Web bundle support
|
- Step-file architecture implementation
|
||||||
|
|
||||||
**[create-module](./workflows/create-module/README.md)** - Build complete modules
|
|
||||||
|
|
||||||
- Full module infrastructure
|
|
||||||
- Agent and workflow integration
|
|
||||||
- Installation automation
|
|
||||||
|
|
||||||
**[module-brief](./workflows/module-brief/README.md)** - Strategic planning
|
|
||||||
|
|
||||||
- Module blueprint creation
|
|
||||||
- Vision and architecture
|
|
||||||
- Comprehensive analysis
|
|
||||||
|
|
||||||
### Editing Workflows
|
### Editing Workflows
|
||||||
|
|
||||||
**[edit-agent](./workflows/edit-agent/README.md)** - Modify existing agents
|
**[edit-agent](./workflows/edit-agent/)** - Modify existing agents
|
||||||
|
|
||||||
- Persona refinement
|
- 5 steps: discovery → validation
|
||||||
- Command updates
|
- Intent-driven analysis and updates
|
||||||
- Best practice compliance
|
- Best practice compliance
|
||||||
|
|
||||||
**[edit-workflow](./workflows/edit-workflow/README.md)** - Update workflows
|
**[edit-workflow](./workflows/edit-workflow/)** - Update workflows
|
||||||
|
|
||||||
- Structure maintenance
|
- 5 steps: analyze → compliance check
|
||||||
- Configuration updates
|
- Structure maintenance and validation
|
||||||
- Documentation sync
|
- Template updates for consistency
|
||||||
|
|
||||||
**[edit-module](./workflows/edit-module/README.md)** - Module enhancement
|
### Quality Assurance
|
||||||
|
|
||||||
- Component modifications
|
**[workflow-compliance-check](./workflows/workflow-compliance-check/)** - Validation
|
||||||
- Dependency management
|
|
||||||
- Version control
|
|
||||||
|
|
||||||
### Maintenance Workflows
|
- 8 systematic validation steps
|
||||||
|
- Adversarial analysis approach
|
||||||
|
- Detailed compliance reporting
|
||||||
|
|
||||||
**[convert-legacy](./workflows/convert-legacy/README.md)** - Migration tool
|
### Legacy Migration (Pending)
|
||||||
|
|
||||||
- v4 to v6 conversion
|
Workflows in `workflows-legacy/` are being migrated to step-file architecture:
|
||||||
- Structure compliance
|
|
||||||
- Convention updates
|
|
||||||
|
|
||||||
**[audit-workflow](./workflows/audit-workflow/README.md)** - Quality validation
|
- Module-specific workflows
|
||||||
|
- Historical implementations
|
||||||
- Structure verification
|
- Conversion planning in progress
|
||||||
- Config standards check
|
|
||||||
- Bloat detection
|
|
||||||
- Web bundle completeness
|
|
||||||
|
|
||||||
**[redoc](./workflows/redoc/README.md)** - Auto-documentation
|
|
||||||
|
|
||||||
- Reverse-tree approach
|
|
||||||
- Technical writer quality
|
|
||||||
- Convention compliance
|
|
||||||
|
|
||||||
## Agent Types
|
## Agent Types
|
||||||
|
|
||||||
BMB creates three agent architectures:
|
BMB creates three agent architectures:
|
||||||
|
|
||||||
### Full Module Agent
|
### Simple Agent
|
||||||
|
|
||||||
- Complete persona and role definition
|
- **Self-contained**: All logic in single YAML file
|
||||||
- Command structure with fuzzy matching
|
- **Stateless**: No persistent memory across sessions
|
||||||
- Workflow integration
|
- **Purpose**: Single utilities and specialized tools
|
||||||
- Module-specific capabilities
|
- **Example**: Commit poet, code formatter
|
||||||
|
|
||||||
### Hybrid Agent
|
### Expert Agent
|
||||||
|
|
||||||
- Shared core capabilities
|
- **Persistent Memory**: Maintains knowledge across sessions
|
||||||
- Module-specific extensions
|
- **Sidecar Resources**: External files and data storage
|
||||||
- Cross-module compatibility
|
- **Domain-specific**: Focuses on particular knowledge areas
|
||||||
|
- **Example**: Journal keeper, domain consultant
|
||||||
|
|
||||||
### Standalone Agent
|
### Module Agent
|
||||||
|
|
||||||
- Independent operation
|
- **Team Integration**: Orchestrates within specific modules
|
||||||
- Minimal dependencies
|
- **Workflow Coordination**: Manages complex processes
|
||||||
- Specialized single purpose
|
- **Professional Infrastructure**: Enterprise-grade capabilities
|
||||||
|
- **Examples**: BMM project manager, CIS innovation strategist
|
||||||
|
|
||||||
## Quick Start
|
## Quick Start
|
||||||
|
|
||||||
1. **Load BMad Builder agent** in your IDE
|
### Using BMad Builder Agent
|
||||||
|
|
||||||
|
1. **Load BMad Builder agent** in your IDE:
|
||||||
|
```
|
||||||
|
/bmad:bmb:agents:bmad-builder
|
||||||
|
```
|
||||||
2. **Choose creation type:**
|
2. **Choose creation type:**
|
||||||
```
|
- `[CA]` Create Agent - Build new agents
|
||||||
*create-agent # New agent
|
- `[CW]` Create Workflow - Design workflows
|
||||||
*create-workflow # New workflow
|
- `[EA]` Edit Agent - Modify existing agents
|
||||||
*create-module # Complete module
|
- `[EW]` Edit Workflow - Update workflows
|
||||||
```
|
- `[VA]` Validate Agent - Quality check agents
|
||||||
3. **Follow interactive prompts**
|
- `[VW]` Validate Workflow - Quality check workflows
|
||||||
|
|
||||||
|
3. **Follow interactive prompts** for step-by-step guidance
|
||||||
|
|
||||||
### Example: Creating an Agent
|
### Example: Creating an Agent
|
||||||
|
|
||||||
```
|
```
|
||||||
User: I need a code review agent
|
User: I need a code review agent
|
||||||
Builder: *create-agent
|
Builder: [CA] Create Agent
|
||||||
|
|
||||||
[Interactive session begins]
|
[11-step guided process]
|
||||||
- Brainstorming phase (optional)
|
Step 1: Brainstorm agent concept
|
||||||
- Persona development
|
Step 2: Define persona and role
|
||||||
- Command structure
|
Step 3: Design command structure
|
||||||
- Integration points
|
...
|
||||||
|
Step 11: Celebrate and deploy
|
||||||
|
```
|
||||||
|
|
||||||
|
### Direct Workflow Execution
|
||||||
|
|
||||||
|
Workflows can also be run directly without the agent interface:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
# Execute specific workflow steps
|
||||||
|
workflow: ./workflows/create-agent/workflow.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
## Use Cases
|
## Use Cases
|
||||||
|
|
@ -165,30 +215,47 @@ Package modules for:
|
||||||
- Business processes
|
- Business processes
|
||||||
- Educational frameworks
|
- Educational frameworks
|
||||||
|
|
||||||
|
## Architecture Principles
|
||||||
|
|
||||||
|
### Step-File Workflow Design
|
||||||
|
|
||||||
|
- **Micro-file Approach**: Each step is self-contained
|
||||||
|
- **Just-In-Time Loading**: Only current step in memory
|
||||||
|
- **Sequential Enforcement**: No skipping steps allowed
|
||||||
|
- **State Tracking**: Progress documented in frontmatter
|
||||||
|
- **Append-Only Building**: Documents grow through execution
|
||||||
|
|
||||||
|
### Intent vs Prescriptive Spectrum
|
||||||
|
|
||||||
|
- **Creative Workflows**: High user agency, AI as facilitator
|
||||||
|
- **Structured Workflows**: Clear process, AI as guide
|
||||||
|
- **Prescriptive Workflows**: Strict compliance, AI as validator
|
||||||
|
|
||||||
## Best Practices
|
## Best Practices
|
||||||
|
|
||||||
1. **Study existing patterns** - Review BMM/CIS implementations
|
1. **Study Reference Materials** - Review docs/ and reference/ examples
|
||||||
2. **Follow conventions** - Use established structures
|
2. **Choose Right Agent Type** - Simple vs Expert vs Module based on needs
|
||||||
3. **Document thoroughly** - Clear instructions essential
|
3. **Follow Step-File Patterns** - Use established templates and structures
|
||||||
4. **Test iteratively** - Validate during creation
|
4. **Document Thoroughly** - Clear instructions and frontmatter metadata
|
||||||
5. **Consider reusability** - Build modular components
|
5. **Validate Continuously** - Use compliance workflows for quality
|
||||||
|
6. **Maintain Consistency** - Follow YAML patterns and naming conventions
|
||||||
|
|
||||||
## Integration
|
## Integration
|
||||||
|
|
||||||
BMB components integrate with:
|
BMB components integrate with:
|
||||||
|
|
||||||
- **BMad Core** - Framework foundation
|
- **BMad Core** - Framework foundation and agent compilation
|
||||||
- **BMM** - Extend development capabilities
|
- **BMM** - Development workflows and project management
|
||||||
- **CIS** - Leverage creative workflows
|
- **CIS** - Creative innovation and strategic workflows
|
||||||
- **Custom Modules** - Your domain solutions
|
- **Custom Modules** - Domain-specific solutions
|
||||||
|
|
||||||
## Related Documentation
|
## Getting Help
|
||||||
|
|
||||||
- **[Agent Creation Guide](./workflows/create-agent/README.md)** - Detailed instructions
|
- **Documentation**: Check `docs/` for comprehensive guides
|
||||||
- **[Module Structure](./workflows/create-module/module-structure.md)** - Architecture patterns
|
- **Reference Materials**: See `reference/` for working examples
|
||||||
- **[BMM Module](../bmm/README.md)** - Reference implementation
|
- **Validation**: Use `workflow-compliance-check` for quality assurance
|
||||||
- **[Core Framework](../../core/README.md)** - Foundation concepts
|
- **Templates**: Leverage workflow templates for consistent patterns
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
BMB empowers you to extend BMad Method for your specific needs while maintaining framework consistency and power.
|
BMB provides a complete toolkit for extending BMad Method with disciplined, systematic approaches to agent and workflow development while maintaining framework consistency and power.
|
||||||
|
|
|
||||||
|
|
@ -1,142 +0,0 @@
|
||||||
# Audit Workflow - Validation Checklist
|
|
||||||
|
|
||||||
## Structure
|
|
||||||
|
|
||||||
- [ ] workflow.yaml file loads without YAML syntax errors
|
|
||||||
- [ ] instructions.md file exists and is properly formatted
|
|
||||||
- [ ] template.md file exists (if document workflow) with valid markdown
|
|
||||||
- [ ] All critical headers present in instructions (workflow engine reference, workflow.yaml reference)
|
|
||||||
- [ ] Workflow type correctly identified (document/action/interactive/autonomous/meta)
|
|
||||||
- [ ] All referenced files actually exist at specified paths
|
|
||||||
- [ ] No placeholder text remains (like {TITLE}, {WORKFLOW_CODE}, TODO, etc.)
|
|
||||||
|
|
||||||
## Standard Config Block
|
|
||||||
|
|
||||||
- [ ] workflow.yaml contains `config_source` pointing to correct module config
|
|
||||||
- [ ] `output_folder` pulls from `{config_source}:output_folder`
|
|
||||||
- [ ] `user_name` pulls from `{config_source}:user_name`
|
|
||||||
- [ ] `communication_language` pulls from `{config_source}:communication_language`
|
|
||||||
- [ ] `date` is set to `system-generated`
|
|
||||||
- [ ] Config source uses {project-root} variable (not hardcoded path)
|
|
||||||
- [ ] Standard config comment present: "Critical variables from config"
|
|
||||||
|
|
||||||
## Config Variable Usage
|
|
||||||
|
|
||||||
- [ ] Instructions communicate in {communication_language} where appropriate
|
|
||||||
- [ ] Instructions address {user_name} in greetings or summaries where appropriate
|
|
||||||
- [ ] All file outputs write to {output_folder} or subdirectories (no hardcoded paths)
|
|
||||||
- [ ] Template includes {{user_name}} in metadata (optional for document workflows)
|
|
||||||
- [ ] Template includes {{date}} in metadata (optional for document workflows)
|
|
||||||
- [ ] Template does NOT use {{communication_language}} in headers (agent-only variable)
|
|
||||||
- [ ] No hardcoded language-specific text that should use {communication_language}
|
|
||||||
- [ ] Date used for agent date awareness (not confused with training cutoff)
|
|
||||||
|
|
||||||
## YAML/Instruction/Template Alignment
|
|
||||||
|
|
||||||
- [ ] Every workflow.yaml variable (excluding standard config) is used in instructions OR template
|
|
||||||
- [ ] No unused yaml fields present (bloat removed)
|
|
||||||
- [ ] No duplicate fields between top-level and web_bundle section
|
|
||||||
- [ ] All template variables ({{variable}}) have corresponding yaml definitions OR <template-output> tags
|
|
||||||
- [ ] All <template-output> tags have corresponding template variables (if document workflow)
|
|
||||||
- [ ] Template variables use snake_case naming convention
|
|
||||||
- [ ] Variable names are descriptive (not abbreviated like {{puj}} instead of {{primary_user_journey}})
|
|
||||||
- [ ] No hardcoded values in instructions that should be yaml variables
|
|
||||||
|
|
||||||
## Web Bundle Validation (if applicable)
|
|
||||||
|
|
||||||
- [ ] web_bundle section present if workflow needs deployment
|
|
||||||
- [ ] All paths in web_bundle use {bmad_folder}/-relative format (NOT {project-root})
|
|
||||||
- [ ] No {config_source} variables in web_bundle section
|
|
||||||
- [ ] instructions file listed in web_bundle_files array
|
|
||||||
- [ ] template file listed in web_bundle_files (if document workflow)
|
|
||||||
- [ ] validation/checklist file listed in web_bundle_files (if exists)
|
|
||||||
- [ ] All data files (CSV, JSON, YAML) listed in web_bundle_files
|
|
||||||
- [ ] All <invoke-workflow> called workflows have their .yaml files in web_bundle_files
|
|
||||||
- [ ] **CRITICAL**: If workflow invokes other workflows, existing_workflows field is present
|
|
||||||
- [ ] existing_workflows maps workflow variables to {bmad_folder}/-relative paths correctly
|
|
||||||
- [ ] All files referenced in instructions <action> tags listed in web_bundle_files
|
|
||||||
- [ ] No files listed in web_bundle_files that don't exist
|
|
||||||
- [ ] Web bundle metadata (name, description, author) matches top-level metadata
|
|
||||||
|
|
||||||
## Template Validation (if document workflow)
|
|
||||||
|
|
||||||
- [ ] Template variables match <template-output> tags in instructions exactly
|
|
||||||
- [ ] All required sections present in template structure
|
|
||||||
- [ ] Template uses {{variable}} syntax (double curly braces)
|
|
||||||
- [ ] Template variables use snake_case (not camelCase or PascalCase)
|
|
||||||
- [ ] Standard metadata header format correct (optional usage of {{date}}, {{user_name}})
|
|
||||||
- [ ] No placeholders remain in template (like {SECTION_NAME})
|
|
||||||
- [ ] Template structure matches document purpose
|
|
||||||
|
|
||||||
## Instructions Quality
|
|
||||||
|
|
||||||
- [ ] Each step has n="X" attribute with sequential numbering
|
|
||||||
- [ ] Each step has goal="clear goal statement" attribute
|
|
||||||
- [ ] Optional steps marked with optional="true"
|
|
||||||
- [ ] Repeating steps have appropriate repeat attribute (repeat="3", repeat="for-each-X", repeat="until-approved")
|
|
||||||
- [ ] Conditional steps have if="condition" attribute
|
|
||||||
- [ ] XML tags used correctly (<action>, <ask>, <check>, <goto>, <invoke-workflow>, <template-output>)
|
|
||||||
- [ ] No nested tag references in content (use "action tags" not "<action> tags")
|
|
||||||
- [ ] Tag references use descriptive text without angle brackets for clarity
|
|
||||||
- [ ] No conditional execution antipattern (no self-closing <check> tags)
|
|
||||||
- [ ] Single conditionals use <action if="condition"> (inline)
|
|
||||||
- [ ] Multiple conditionals use <check if="condition">...</check> (wrapper block with closing tag)
|
|
||||||
- [ ] Steps are focused (single goal per step)
|
|
||||||
- [ ] Instructions are specific with limits ("Write 1-2 paragraphs" not "Write about")
|
|
||||||
- [ ] Examples provided where helpful
|
|
||||||
- [ ] <template-output> tags save checkpoints for document workflows
|
|
||||||
- [ ] Flow control is logical and clear
|
|
||||||
|
|
||||||
## Bloat Detection
|
|
||||||
|
|
||||||
- [ ] Bloat percentage under 10% (unused yaml fields / total fields)
|
|
||||||
- [ ] No commented-out variables that should be removed
|
|
||||||
- [ ] No duplicate metadata between sections
|
|
||||||
- [ ] No variables defined but never referenced
|
|
||||||
- [ ] No redundant configuration that duplicates web_bundle
|
|
||||||
|
|
||||||
## Final Validation
|
|
||||||
|
|
||||||
### Critical Issues (Must fix immediately)
|
|
||||||
|
|
||||||
_List any critical issues found:_
|
|
||||||
|
|
||||||
- Issue 1:
|
|
||||||
- Issue 2:
|
|
||||||
- Issue 3:
|
|
||||||
|
|
||||||
### Important Issues (Should fix soon)
|
|
||||||
|
|
||||||
_List any important issues found:_
|
|
||||||
|
|
||||||
- Issue 1:
|
|
||||||
- Issue 2:
|
|
||||||
- Issue 3:
|
|
||||||
|
|
||||||
### Cleanup Recommendations (Nice to have)
|
|
||||||
|
|
||||||
_List any cleanup recommendations:_
|
|
||||||
|
|
||||||
- Recommendation 1:
|
|
||||||
- Recommendation 2:
|
|
||||||
- Recommendation 3:
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Audit Summary
|
|
||||||
|
|
||||||
**Total Checks:**
|
|
||||||
**Passed:** {total}
|
|
||||||
**Failed:** {total}
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
|
|
||||||
- Pass Rate ≥ 95%: Excellent - Ready for production
|
|
||||||
- Pass Rate 85-94%: Good - Minor fixes needed
|
|
||||||
- Pass Rate 70-84%: Fair - Important issues to address
|
|
||||||
- Pass Rate < 70%: Poor - Significant work required
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Audit Completed:** {{date}}
|
|
||||||
**Auditor:** Audit Workflow (BMAD v6)
|
|
||||||
|
|
@ -1,341 +0,0 @@
|
||||||
# Audit Workflow - Workflow Quality Audit Instructions
|
|
||||||
|
|
||||||
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
|
|
||||||
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/audit-workflow/workflow.yaml</critical>
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="1" goal="Load and analyze target workflow">
|
|
||||||
<ask>What is the path to the workflow you want to audit? (provide path to workflow.yaml or workflow folder)</ask>
|
|
||||||
|
|
||||||
<action>Load the workflow.yaml file from the provided path</action>
|
|
||||||
<action>Identify the workflow type (document, action, interactive, autonomous, meta)</action>
|
|
||||||
<action>List all associated files:</action>
|
|
||||||
|
|
||||||
- instructions.md (required for most workflows)
|
|
||||||
- template.md (if document workflow)
|
|
||||||
- checklist.md (if validation exists)
|
|
||||||
- Any data files referenced in yaml
|
|
||||||
|
|
||||||
<action>Load all discovered files</action>
|
|
||||||
|
|
||||||
Display summary:
|
|
||||||
|
|
||||||
- Workflow name and description
|
|
||||||
- Type of workflow
|
|
||||||
- Files present
|
|
||||||
- Module assignment
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Validate standard config block">
|
|
||||||
<action>Check workflow.yaml for the standard config block:</action>
|
|
||||||
|
|
||||||
**Required variables:**
|
|
||||||
|
|
||||||
- `config_source: "{project-root}/{bmad_folder}/[module]/config.yaml"`
|
|
||||||
- `output_folder: "{config_source}:output_folder"`
|
|
||||||
- `user_name: "{config_source}:user_name"`
|
|
||||||
- `communication_language: "{config_source}:communication_language"`
|
|
||||||
- `date: system-generated`
|
|
||||||
|
|
||||||
<action>Validate each variable:</action>
|
|
||||||
|
|
||||||
**Config Source Check:**
|
|
||||||
|
|
||||||
- [ ] `config_source` is defined
|
|
||||||
- [ ] Points to correct module config path
|
|
||||||
- [ ] Uses {project-root} variable
|
|
||||||
|
|
||||||
**Standard Variables Check:**
|
|
||||||
|
|
||||||
- [ ] `output_folder` pulls from config_source
|
|
||||||
- [ ] `user_name` pulls from config_source
|
|
||||||
- [ ] `communication_language` pulls from config_source
|
|
||||||
- [ ] `date` is set to system-generated
|
|
||||||
|
|
||||||
<action>Record any missing or incorrect config variables</action>
|
|
||||||
<template-output>config_issues</template-output>
|
|
||||||
|
|
||||||
<action if="config issues found">Add to issues list with severity: CRITICAL</action>
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Analyze YAML/Instruction/Template alignment">
|
|
||||||
<action>Extract all variables defined in workflow.yaml (excluding standard config block)</action>
|
|
||||||
<action>Scan instructions.md for variable usage: {variable_name} pattern</action>
|
|
||||||
<action>Scan template.md for variable usage: {{variable_name}} pattern (if exists)</action>
|
|
||||||
|
|
||||||
<action>Cross-reference analysis:</action>
|
|
||||||
|
|
||||||
**For each yaml variable:**
|
|
||||||
|
|
||||||
1. Is it used in instructions.md? (mark as INSTRUCTION_USED)
|
|
||||||
2. Is it used in template.md? (mark as TEMPLATE_USED)
|
|
||||||
3. Is it neither? (mark as UNUSED_BLOAT)
|
|
||||||
|
|
||||||
**Special cases to ignore:**
|
|
||||||
|
|
||||||
- Standard config variables (config_source, output_folder, user_name, communication_language, date)
|
|
||||||
- Workflow metadata (name, description, author)
|
|
||||||
- Path variables (installed_path, template, instructions, validation)
|
|
||||||
- Web bundle configuration (web_bundle block itself)
|
|
||||||
|
|
||||||
<action>Identify unused yaml fields (bloat)</action>
|
|
||||||
<action>Identify hardcoded values in instructions that should be variables</action>
|
|
||||||
<template-output>alignment_issues</template-output>
|
|
||||||
|
|
||||||
<action if="unused variables found">Add to issues list with severity: BLOAT</action>
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Config variable usage audit">
|
|
||||||
<action>Analyze instructions.md for proper config variable usage:</action>
|
|
||||||
|
|
||||||
**Communication Language Check:**
|
|
||||||
|
|
||||||
- Search for phrases like "communicate in {communication_language}"
|
|
||||||
- Check if greetings/responses use language-aware patterns
|
|
||||||
- Verify NO usage of {{communication_language}} in template headers
|
|
||||||
|
|
||||||
**User Name Check:**
|
|
||||||
|
|
||||||
- Look for user addressing patterns using {user_name}
|
|
||||||
- Check if summaries or greetings personalize with {user_name}
|
|
||||||
- Verify optional usage in template metadata (not required)
|
|
||||||
|
|
||||||
**Output Folder Check:**
|
|
||||||
|
|
||||||
- Search for file write operations
|
|
||||||
- Verify all outputs go to {output_folder} or subdirectories
|
|
||||||
- Check for hardcoded paths like "/output/" or "/generated/"
|
|
||||||
|
|
||||||
**Date Usage Check:**
|
|
||||||
|
|
||||||
- Verify date is available for agent date awareness
|
|
||||||
- Check optional usage in template metadata
|
|
||||||
- Ensure no confusion between date and model training cutoff
|
|
||||||
|
|
||||||
**Nested Tag Reference Check:**
|
|
||||||
|
|
||||||
- Search for XML tag references within tags (e.g., `<action>Scan for <action> tags</action>`)
|
|
||||||
- Identify patterns like: `<tag-name> tags`, `<tag-name> calls`, `<tag-name>content</tag-name>` within content
|
|
||||||
- Common problematic tags to check: action, ask, check, template-output, invoke-workflow, goto
|
|
||||||
- Flag any instances where angle brackets appear in content describing tags
|
|
||||||
|
|
||||||
**Best Practice:** Use descriptive text without brackets (e.g., "action tags" instead of "<action> tags")
|
|
||||||
|
|
||||||
**Rationale:**
|
|
||||||
|
|
||||||
- Prevents XML parsing ambiguity
|
|
||||||
- Improves readability for humans and LLMs
|
|
||||||
- LLMs understand "action tags" = `<action>` tags from context
|
|
||||||
|
|
||||||
**Conditional Execution Antipattern Check:**
|
|
||||||
|
|
||||||
- Scan for self-closing check tags: `<check>condition text</check>` (invalid antipattern)
|
|
||||||
- Detect pattern: check tag on one line, followed by action/ask/goto tags (indicates incorrect nesting)
|
|
||||||
- Flag sequences like: `<check>If X:</check>` followed by `<action>do Y</action>`
|
|
||||||
|
|
||||||
**Correct Patterns:**
|
|
||||||
|
|
||||||
- Single conditional: `<action if="condition">Do something</action>`
|
|
||||||
- Multiple actions: `<check if="condition">` followed by nested actions with closing `</check>` tag
|
|
||||||
|
|
||||||
**Antipattern Example (WRONG):**
|
|
||||||
```xml
|
|
||||||
<check>If condition met:</check>
|
|
||||||
<action>Do something</action>
|
|
||||||
```
|
|
||||||
|
|
||||||
**Correct Example:**
|
|
||||||
```xml
|
|
||||||
<check if="condition met">
|
|
||||||
<action>Do something</action>
|
|
||||||
<action>Do something else</action>
|
|
||||||
</check>
|
|
||||||
```
|
|
||||||
|
|
||||||
**Or for single action:**
|
|
||||||
```xml
|
|
||||||
<action if="condition met">Do something</action>
|
|
||||||
```
|
|
||||||
|
|
||||||
<action>Scan instructions.md for nested tag references using pattern: <(action|ask|check|template-output|invoke-workflow|invoke-task|goto|step)> within text content</action>
|
|
||||||
<action>Record any instances of nested tag references with line numbers</action>
|
|
||||||
<action>Scan instructions.md for conditional execution antipattern: self-closing check tags</action>
|
|
||||||
<action>Detect pattern: `<check>.*</check>` on single line (self-closing check)</action>
|
|
||||||
<action>Record any antipattern instances with line numbers and suggest corrections</action>
|
|
||||||
<action>Record any improper config variable usage</action>
|
|
||||||
<template-output>config_usage_issues</template-output>
|
|
||||||
|
|
||||||
<action if="config usage issues found">Add to issues list with severity: IMPORTANT</action>
|
|
||||||
<action if="nested tag references found">Add to issues list with severity: CLARITY (recommend using descriptive text without angle brackets)</action>
|
|
||||||
<action if="conditional antipattern found">Add to issues list with severity: CRITICAL (invalid XML structure - must use action if="" or proper check wrapper)</action>
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5" goal="Web bundle validation" optional="true">
|
|
||||||
<check if="workflow.yaml contains web_bundle section">
|
|
||||||
|
|
||||||
<action>Validate web_bundle structure:</action>
|
|
||||||
|
|
||||||
**Path Validation:**
|
|
||||||
|
|
||||||
- [ ] All paths use {bmad_folder}/-relative format (NOT {project-root})
|
|
||||||
- [ ] No {config_source} variables in web_bundle section
|
|
||||||
- [ ] Paths match actual file locations
|
|
||||||
|
|
||||||
**Completeness Check:**
|
|
||||||
|
|
||||||
- [ ] instructions file listed in web_bundle_files
|
|
||||||
- [ ] template file listed (if document workflow)
|
|
||||||
- [ ] validation/checklist file listed (if exists)
|
|
||||||
- [ ] All data files referenced in yaml listed
|
|
||||||
- [ ] All files referenced in instructions listed
|
|
||||||
|
|
||||||
**Workflow Dependency Scan:**
|
|
||||||
<action>Scan instructions.md for invoke-workflow tags</action>
|
|
||||||
<action>Extract workflow paths from invocations</action>
|
|
||||||
<action>Verify each called workflow.yaml is in web_bundle_files</action>
|
|
||||||
<action>**CRITICAL**: Check if existing_workflows field is present when workflows are invoked</action>
|
|
||||||
<action>If invoke-workflow calls exist, existing_workflows MUST map workflow variables to paths</action>
|
|
||||||
<action>Example: If instructions use {core_brainstorming}, web_bundle needs: existing_workflows: - core_brainstorming: "{bmad_folder}/core/workflows/brainstorming/workflow.yaml"</action>
|
|
||||||
|
|
||||||
**File Reference Scan:**
|
|
||||||
<action>Scan instructions.md for file references in action tags</action>
|
|
||||||
<action>Check for CSV, JSON, YAML, MD files referenced</action>
|
|
||||||
<action>Verify all referenced files are in web_bundle_files</action>
|
|
||||||
|
|
||||||
<action>Record any missing files or incorrect paths</action>
|
|
||||||
<template-output>web_bundle_issues</template-output>
|
|
||||||
|
|
||||||
<action if="web_bundle issues found">Add to issues list with severity: CRITICAL</action>
|
|
||||||
|
|
||||||
<action if="no web_bundle section exists">Note: "No web_bundle configured (may be intentional for local-only workflows)"</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="6" goal="Bloat detection">
|
|
||||||
<action>Identify bloat patterns:</action>
|
|
||||||
|
|
||||||
**Unused YAML Fields:**
|
|
||||||
|
|
||||||
- Variables defined but not used in instructions OR template
|
|
||||||
- Duplicate fields between top-level and web_bundle section
|
|
||||||
- Commented-out variables that should be removed
|
|
||||||
|
|
||||||
**Hardcoded Values:**
|
|
||||||
|
|
||||||
- File paths that should use {output_folder}
|
|
||||||
- Generic greetings that should use {user_name}
|
|
||||||
- Language-specific text that should use {communication_language}
|
|
||||||
- Static dates that should use {date}
|
|
||||||
|
|
||||||
**Redundant Configuration:**
|
|
||||||
|
|
||||||
- Variables that duplicate web_bundle fields
|
|
||||||
- Metadata repeated across sections
|
|
||||||
|
|
||||||
<action>Calculate bloat metrics:</action>
|
|
||||||
|
|
||||||
- Total yaml fields: {{total_yaml_fields}}
|
|
||||||
- Used fields: {{used_fields}}
|
|
||||||
- Unused fields: {{unused_fields}}
|
|
||||||
- Bloat percentage: {{bloat_percentage}}%
|
|
||||||
|
|
||||||
<action>Record all bloat items with recommendations</action>
|
|
||||||
<template-output>bloat_items</template-output>
|
|
||||||
|
|
||||||
<action if="bloat detected">Add to issues list with severity: CLEANUP</action>
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="7" goal="Template variable mapping" if="workflow_type == 'document'">
|
|
||||||
<action>Extract all template variables from template.md: {{variable_name}} pattern</action>
|
|
||||||
<action>Scan instructions.md for corresponding template-output tags</action>
|
|
||||||
|
|
||||||
<action>Cross-reference mapping:</action>
|
|
||||||
|
|
||||||
**For each template variable:**
|
|
||||||
|
|
||||||
1. Is there a matching template-output tag? (mark as MAPPED)
|
|
||||||
2. Is it a standard config variable? (mark as CONFIG_VAR - optional)
|
|
||||||
3. Is it unmapped? (mark as MISSING_OUTPUT)
|
|
||||||
|
|
||||||
**For each template-output tag:**
|
|
||||||
|
|
||||||
1. Is there a matching template variable? (mark as USED)
|
|
||||||
2. Is it orphaned? (mark as UNUSED_OUTPUT)
|
|
||||||
|
|
||||||
<action>Verify variable naming conventions:</action>
|
|
||||||
|
|
||||||
- [ ] All template variables use snake_case
|
|
||||||
- [ ] Variable names are descriptive (not abbreviated)
|
|
||||||
- [ ] Standard config variables properly formatted
|
|
||||||
|
|
||||||
<action>Record any mapping issues</action>
|
|
||||||
<template-output>template_issues</template-output>
|
|
||||||
|
|
||||||
<action if="template issues found">Add to issues list with severity: IMPORTANT</action>
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="8" goal="Generate comprehensive audit report">
|
|
||||||
<action>Compile all findings and calculate summary metrics</action>
|
|
||||||
|
|
||||||
<action>Generate executive summary based on issue counts and severity levels</action>
|
|
||||||
<template-output>workflow_type</template-output>
|
|
||||||
<template-output>overall_status</template-output>
|
|
||||||
<template-output>critical_count</template-output>
|
|
||||||
<template-output>important_count</template-output>
|
|
||||||
<template-output>cleanup_count</template-output>
|
|
||||||
|
|
||||||
<action>Generate status summaries for each audit section</action>
|
|
||||||
<template-output>config_status</template-output>
|
|
||||||
<template-output>total_variables</template-output>
|
|
||||||
<template-output>instruction_usage_count</template-output>
|
|
||||||
<template-output>template_usage_count</template-output>
|
|
||||||
<template-output>bloat_count</template-output>
|
|
||||||
|
|
||||||
<action>Generate config variable usage status indicators</action>
|
|
||||||
<template-output>comm_lang_status</template-output>
|
|
||||||
<template-output>user_name_status</template-output>
|
|
||||||
<template-output>output_folder_status</template-output>
|
|
||||||
<template-output>date_status</template-output>
|
|
||||||
<template-output>nested_tag_count</template-output>
|
|
||||||
|
|
||||||
<action>Generate web bundle metrics</action>
|
|
||||||
<template-output>web_bundle_exists</template-output>
|
|
||||||
<template-output>web_bundle_file_count</template-output>
|
|
||||||
<template-output>missing_files_count</template-output>
|
|
||||||
|
|
||||||
<action>Generate bloat metrics</action>
|
|
||||||
<template-output>bloat_percentage</template-output>
|
|
||||||
<template-output>cleanup_potential</template-output>
|
|
||||||
|
|
||||||
<action>Generate template mapping metrics</action>
|
|
||||||
<template-output>template_var_count</template-output>
|
|
||||||
<template-output>mapped_count</template-output>
|
|
||||||
<template-output>missing_mapping_count</template-output>
|
|
||||||
|
|
||||||
<action>Compile prioritized recommendations by severity</action>
|
|
||||||
<template-output>critical_recommendations</template-output>
|
|
||||||
<template-output>important_recommendations</template-output>
|
|
||||||
<template-output>cleanup_recommendations</template-output>
|
|
||||||
|
|
||||||
<action>Display summary to {user_name} in {communication_language}</action>
|
|
||||||
<action>Provide path to full audit report: {output_folder}/audit-report-{{workflow_name}}-{{date}}.md</action>
|
|
||||||
|
|
||||||
<ask>Would you like to:
|
|
||||||
|
|
||||||
- View the full audit report
|
|
||||||
- Fix issues automatically (invoke edit-workflow)
|
|
||||||
- Audit another workflow
|
|
||||||
- Exit
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
|
|
@ -1,118 +0,0 @@
|
||||||
# Workflow Audit Report
|
|
||||||
|
|
||||||
**Workflow:** {{workflow_name}}
|
|
||||||
**Audit Date:** {{date}}
|
|
||||||
**Auditor:** Audit Workflow (BMAD v6)
|
|
||||||
**Workflow Type:** {{workflow_type}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Executive Summary
|
|
||||||
|
|
||||||
**Overall Status:** {{overall_status}}
|
|
||||||
|
|
||||||
- Critical Issues: {{critical_count}}
|
|
||||||
- Important Issues: {{important_count}}
|
|
||||||
- Cleanup Recommendations: {{cleanup_count}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 1. Standard Config Block Validation
|
|
||||||
|
|
||||||
{{config_issues}}
|
|
||||||
|
|
||||||
**Status:** {{config_status}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 2. YAML/Instruction/Template Alignment
|
|
||||||
|
|
||||||
{{alignment_issues}}
|
|
||||||
|
|
||||||
**Variables Analyzed:** {{total_variables}}
|
|
||||||
**Used in Instructions:** {{instruction_usage_count}}
|
|
||||||
**Used in Template:** {{template_usage_count}}
|
|
||||||
**Unused (Bloat):** {{bloat_count}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. Config Variable Usage & Instruction Quality
|
|
||||||
|
|
||||||
{{config_usage_issues}}
|
|
||||||
|
|
||||||
**Communication Language:** {{comm_lang_status}}
|
|
||||||
**User Name:** {{user_name_status}}
|
|
||||||
**Output Folder:** {{output_folder_status}}
|
|
||||||
**Date:** {{date_status}}
|
|
||||||
**Nested Tag References:** {{nested_tag_count}} instances found
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. Web Bundle Validation
|
|
||||||
|
|
||||||
{{web_bundle_issues}}
|
|
||||||
|
|
||||||
**Web Bundle Present:** {{web_bundle_exists}}
|
|
||||||
**Files Listed:** {{web_bundle_file_count}}
|
|
||||||
**Missing Files:** {{missing_files_count}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 5. Bloat Detection
|
|
||||||
|
|
||||||
{{bloat_items}}
|
|
||||||
|
|
||||||
**Bloat Percentage:** {{bloat_percentage}}%
|
|
||||||
**Cleanup Potential:** {{cleanup_potential}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 6. Template Variable Mapping
|
|
||||||
|
|
||||||
{{template_issues}}
|
|
||||||
|
|
||||||
**Template Variables:** {{template_var_count}}
|
|
||||||
**Mapped Correctly:** {{mapped_count}}
|
|
||||||
**Missing Mappings:** {{missing_mapping_count}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Recommendations
|
|
||||||
|
|
||||||
### Critical (Fix Immediately)
|
|
||||||
|
|
||||||
{{critical_recommendations}}
|
|
||||||
|
|
||||||
### Important (Address Soon)
|
|
||||||
|
|
||||||
{{important_recommendations}}
|
|
||||||
|
|
||||||
### Cleanup (Nice to Have)
|
|
||||||
|
|
||||||
{{cleanup_recommendations}}
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Validation Checklist
|
|
||||||
|
|
||||||
Use this checklist to verify fixes:
|
|
||||||
|
|
||||||
- [ ] All standard config variables present and correct
|
|
||||||
- [ ] No unused yaml fields (bloat removed)
|
|
||||||
- [ ] Config variables used appropriately in instructions
|
|
||||||
- [ ] Web bundle includes all dependencies
|
|
||||||
- [ ] Template variables properly mapped
|
|
||||||
- [ ] File structure follows v6 conventions
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Next Steps
|
|
||||||
|
|
||||||
1. Review critical issues and fix immediately
|
|
||||||
2. Address important issues in next iteration
|
|
||||||
3. Consider cleanup recommendations for optimization
|
|
||||||
4. Re-run audit after fixes to verify improvements
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Audit Complete** - Generated by audit-workflow v1.0
|
|
||||||
|
|
@ -1,25 +0,0 @@
|
||||||
# Audit Workflow Configuration
|
|
||||||
name: "audit-workflow"
|
|
||||||
description: "Comprehensive workflow quality audit - validates structure, config standards, variable usage, bloat detection, and web_bundle completeness. Performs deep analysis of workflow.yaml, instructions.md, template.md, and web_bundle configuration against BMAD v6 standards."
|
|
||||||
author: "BMad"
|
|
||||||
|
|
||||||
# Critical variables from config
|
|
||||||
config_source: "{project-root}/{bmad_folder}/bmb/config.yaml"
|
|
||||||
output_folder: "{config_source}:output_folder"
|
|
||||||
user_name: "{config_source}:user_name"
|
|
||||||
communication_language: "{config_source}:communication_language"
|
|
||||||
date: system-generated
|
|
||||||
|
|
||||||
# Module path and component files
|
|
||||||
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/audit-workflow"
|
|
||||||
template: "{installed_path}/template.md"
|
|
||||||
instructions: "{installed_path}/instructions.md"
|
|
||||||
validation: "{installed_path}/checklist.md"
|
|
||||||
|
|
||||||
# Output configuration
|
|
||||||
default_output_file: "{output_folder}/audit-report-{{workflow_name}}-{{date}}.md"
|
|
||||||
|
|
||||||
standalone: true
|
|
||||||
|
|
||||||
# Web bundle configuration
|
|
||||||
web_bundle: false # BMB workflows run locally in BMAD-METHOD project
|
|
||||||
|
|
@ -1,262 +0,0 @@
|
||||||
# Convert Legacy Workflow
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
The Convert Legacy workflow is a comprehensive migration tool that converts BMAD v4 items (agents, workflows, modules) to v6 compliant format with proper structure and conventions. It bridges the gap between legacy BMAD implementations and the modern v6 architecture, ensuring seamless migration while preserving functionality and improving structure.
|
|
||||||
|
|
||||||
## Key Features
|
|
||||||
|
|
||||||
- **Multi-Format Detection** - Automatically identifies v4 agents, workflows, tasks, templates, and modules
|
|
||||||
- **Intelligent Conversion** - Smart mapping from v4 patterns to v6 equivalents with structural improvements
|
|
||||||
- **Sub-Workflow Integration** - Leverages create-agent, create-workflow, and create-module workflows for quality output
|
|
||||||
- **Structure Modernization** - Converts YAML-based agents to XML, templates to workflows, tasks to structured workflows
|
|
||||||
- **Path Normalization** - Updates all references to use proper v6 path conventions
|
|
||||||
- **Validation System** - Comprehensive validation of converted items before finalization
|
|
||||||
- **Migration Reporting** - Detailed conversion reports with locations and manual adjustment notes
|
|
||||||
|
|
||||||
## Usage
|
|
||||||
|
|
||||||
### Basic Invocation
|
|
||||||
|
|
||||||
```bash
|
|
||||||
workflow convert-legacy
|
|
||||||
```
|
|
||||||
|
|
||||||
### With Legacy File Input
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Convert a specific v4 item
|
|
||||||
workflow convert-legacy --input /path/to/legacy-agent.md
|
|
||||||
```
|
|
||||||
|
|
||||||
### With Legacy Module
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Convert an entire v4 module structure
|
|
||||||
workflow convert-legacy --input /path/to/legacy-module/
|
|
||||||
```
|
|
||||||
|
|
||||||
### Configuration
|
|
||||||
|
|
||||||
The workflow uses standard BMB configuration:
|
|
||||||
|
|
||||||
- **output_folder**: Where converted items will be placed
|
|
||||||
- **user_name**: Author information for converted items
|
|
||||||
- **conversion_mappings**: v4-to-v6 pattern mappings (optional)
|
|
||||||
|
|
||||||
## Workflow Structure
|
|
||||||
|
|
||||||
### Files Included
|
|
||||||
|
|
||||||
```
|
|
||||||
convert-legacy/
|
|
||||||
├── workflow.yaml # Configuration and metadata
|
|
||||||
├── instructions.md # Step-by-step conversion guide
|
|
||||||
├── checklist.md # Validation criteria
|
|
||||||
└── README.md # This file
|
|
||||||
```
|
|
||||||
|
|
||||||
## Workflow Process
|
|
||||||
|
|
||||||
### Phase 1: Legacy Analysis (Steps 1-3)
|
|
||||||
|
|
||||||
**Item Identification and Loading**
|
|
||||||
|
|
||||||
- Accepts file path or directory from user
|
|
||||||
- Loads complete file/folder structure for analysis
|
|
||||||
- Automatically detects item type based on content patterns:
|
|
||||||
- **Agents**: Contains `<agent>` or `<prompt>` XML tags
|
|
||||||
- **Workflows**: Contains workflow YAML or instruction patterns
|
|
||||||
- **Modules**: Contains multiple organized agents/workflows
|
|
||||||
- **Tasks**: Contains `<task>` XML tags
|
|
||||||
- **Templates**: Contains YAML-based document generators
|
|
||||||
|
|
||||||
**Legacy Structure Analysis**
|
|
||||||
|
|
||||||
- Parses v4 structure and extracts key components
|
|
||||||
- Maps v4 agent metadata (name, id, title, icon, persona)
|
|
||||||
- Analyzes v4 template sections and elicitation patterns
|
|
||||||
- Identifies task workflows and decision trees
|
|
||||||
- Catalogs dependencies and file references
|
|
||||||
|
|
||||||
**Target Module Selection**
|
|
||||||
|
|
||||||
- Prompts for target module (bmm, bmb, cis, custom)
|
|
||||||
- Determines proper installation paths using v6 conventions
|
|
||||||
- Shows target location for user confirmation
|
|
||||||
- Ensures all paths use `{project-root}/{bmad_folder}/` format
|
|
||||||
|
|
||||||
### Phase 2: Conversion Strategy (Step 4)
|
|
||||||
|
|
||||||
**Strategy Selection Based on Item Type**
|
|
||||||
|
|
||||||
- **Simple Agents**: Direct XML conversion with metadata mapping
|
|
||||||
- **Complex Agents**: Workflow-assisted creation using create-agent
|
|
||||||
- **Templates**: Template-to-workflow conversion with proper structure
|
|
||||||
- **Tasks**: Task-to-workflow conversion with step mapping
|
|
||||||
- **Modules**: Full module creation using create-module workflow
|
|
||||||
|
|
||||||
**Workflow Type Determination**
|
|
||||||
|
|
||||||
- Analyzes legacy items to determine v6 workflow type:
|
|
||||||
- **Document Workflow**: Generates documents with templates
|
|
||||||
- **Action Workflow**: Performs actions without output documents
|
|
||||||
- **Interactive Workflow**: Guides user interaction sessions
|
|
||||||
- **Meta-Workflow**: Coordinates other workflows
|
|
||||||
|
|
||||||
### Phase 3: Conversion Execution (Steps 5a-5e)
|
|
||||||
|
|
||||||
**Direct Agent Conversion (5a)**
|
|
||||||
|
|
||||||
- Transforms v4 YAML agent format to v6 XML structure
|
|
||||||
- Maps persona blocks (role, style, identity, principles)
|
|
||||||
- Converts commands list to v6 `<cmds>` format
|
|
||||||
- Updates task references to workflow invocations
|
|
||||||
- Normalizes all paths to v6 conventions
|
|
||||||
|
|
||||||
**Workflow-Assisted Creation (5b-5e)**
|
|
||||||
|
|
||||||
- Extracts key information from legacy items
|
|
||||||
- Invokes appropriate sub-workflows:
|
|
||||||
- `create-agent` for complex agent creation
|
|
||||||
- `create-workflow` for template/task conversion
|
|
||||||
- `create-module` for full module migration
|
|
||||||
- Ensures proper v6 structure and conventions
|
|
||||||
|
|
||||||
**Template-to-Workflow Conversion (5c)**
|
|
||||||
|
|
||||||
- Converts YAML template sections to workflow steps
|
|
||||||
- Maps `elicit: true` flags to `<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml</invoke-task>` tags
|
|
||||||
- Transforms conditional sections to flow control
|
|
||||||
- Creates proper template.md from content structure
|
|
||||||
- Integrates v4 create-doc.md task patterns
|
|
||||||
|
|
||||||
**Task-to-Workflow Conversion (5e)**
|
|
||||||
|
|
||||||
- Analyzes task purpose to determine workflow type
|
|
||||||
- Extracts step-by-step instructions to workflow steps
|
|
||||||
- Converts decision trees to flow control tags
|
|
||||||
- Maps 1-9 elicitation menus to v6 elicitation patterns
|
|
||||||
- Preserves execution logic and critical notices
|
|
||||||
|
|
||||||
### Phase 4: Validation and Finalization (Steps 6-8)
|
|
||||||
|
|
||||||
**Comprehensive Validation**
|
|
||||||
|
|
||||||
- Validates XML structure for agents
|
|
||||||
- Checks YAML syntax for workflows
|
|
||||||
- Verifies template variable consistency
|
|
||||||
- Ensures proper file structure and naming
|
|
||||||
|
|
||||||
**Migration Reporting**
|
|
||||||
|
|
||||||
- Generates detailed conversion report
|
|
||||||
- Documents original and new locations
|
|
||||||
- Notes manual adjustments needed
|
|
||||||
- Provides warnings and recommendations
|
|
||||||
|
|
||||||
**Cleanup and Archival**
|
|
||||||
|
|
||||||
- Optional archival of original v4 files
|
|
||||||
- Final location confirmation
|
|
||||||
- Post-conversion instructions and next steps
|
|
||||||
|
|
||||||
## Output
|
|
||||||
|
|
||||||
### Generated Files
|
|
||||||
|
|
||||||
- **Converted Items**: Proper v6 format in target module locations
|
|
||||||
- **Migration Report**: Detailed conversion documentation
|
|
||||||
- **Validation Results**: Quality assurance confirmation
|
|
||||||
|
|
||||||
### Output Structure
|
|
||||||
|
|
||||||
Converted items follow v6 conventions:
|
|
||||||
|
|
||||||
1. **Agents** - XML format with proper persona and command structure
|
|
||||||
2. **Workflows** - Complete workflow folders with yaml, instructions, and templates
|
|
||||||
3. **Modules** - Full module structure with installation infrastructure
|
|
||||||
4. **Documentation** - Updated paths, references, and metadata
|
|
||||||
|
|
||||||
## Requirements
|
|
||||||
|
|
||||||
- **Legacy v4 Items** - Source files or directories to convert
|
|
||||||
- **Target Module Access** - Write permissions to target module directories
|
|
||||||
- **Sub-Workflow Availability** - create-agent, create-workflow, create-module workflows accessible
|
|
||||||
- **Conversion Mappings** (optional) - v4-to-v6 pattern mappings for complex conversions
|
|
||||||
|
|
||||||
## Best Practices
|
|
||||||
|
|
||||||
### Before Starting
|
|
||||||
|
|
||||||
1. **Backup Legacy Items** - Create copies of original v4 files before conversion
|
|
||||||
2. **Review Target Module** - Understand target module structure and conventions
|
|
||||||
3. **Plan Module Organization** - Decide where converted items should logically fit
|
|
||||||
|
|
||||||
### During Execution
|
|
||||||
|
|
||||||
1. **Validate Item Type Detection** - Confirm automatic detection or correct manually
|
|
||||||
2. **Choose Appropriate Strategy** - Use workflow-assisted creation for complex items
|
|
||||||
3. **Review Path Mappings** - Ensure all references use proper v6 path conventions
|
|
||||||
4. **Test Incrementally** - Convert simple items first to validate process
|
|
||||||
|
|
||||||
### After Completion
|
|
||||||
|
|
||||||
1. **Validate Converted Items** - Test agents and workflows for proper functionality
|
|
||||||
2. **Review Migration Report** - Address any manual adjustments noted
|
|
||||||
3. **Update Documentation** - Ensure README and documentation reflect changes
|
|
||||||
4. **Archive Originals** - Store v4 files safely for reference if needed
|
|
||||||
|
|
||||||
## Troubleshooting
|
|
||||||
|
|
||||||
### Common Issues
|
|
||||||
|
|
||||||
**Issue**: Item type detection fails or incorrect
|
|
||||||
|
|
||||||
- **Solution**: Manually specify item type when prompted
|
|
||||||
- **Check**: Verify file structure matches expected v4 patterns
|
|
||||||
|
|
||||||
**Issue**: Path conversion errors
|
|
||||||
|
|
||||||
- **Solution**: Ensure all references use `{project-root}/{bmad_folder}/` format
|
|
||||||
- **Check**: Review conversion mappings for proper path patterns
|
|
||||||
|
|
||||||
**Issue**: Sub-workflow invocation fails
|
|
||||||
|
|
||||||
- **Solution**: Verify build workflows are available and accessible
|
|
||||||
- **Check**: Ensure target module exists and has proper permissions
|
|
||||||
|
|
||||||
**Issue**: XML or YAML syntax errors in output
|
|
||||||
|
|
||||||
- **Solution**: Review conversion mappings and adjust patterns
|
|
||||||
- **Check**: Validate converted files with appropriate parsers
|
|
||||||
|
|
||||||
## Customization
|
|
||||||
|
|
||||||
To customize this workflow:
|
|
||||||
|
|
||||||
1. **Update Conversion Mappings** - Modify v4-to-v6 pattern mappings in data/
|
|
||||||
2. **Extend Detection Logic** - Add new item type detection patterns
|
|
||||||
3. **Add Conversion Strategies** - Implement specialized conversion approaches
|
|
||||||
4. **Enhance Validation** - Add additional quality checks in validation step
|
|
||||||
|
|
||||||
## Version History
|
|
||||||
|
|
||||||
- **v1.0.0** - Initial release
|
|
||||||
- Multi-format v4 item detection and conversion
|
|
||||||
- Integration with create-agent, create-workflow, create-module
|
|
||||||
- Comprehensive path normalization
|
|
||||||
- Migration reporting and validation
|
|
||||||
|
|
||||||
## Support
|
|
||||||
|
|
||||||
For issues or questions:
|
|
||||||
|
|
||||||
- Review the workflow creation guide at `/{bmad_folder}/bmb/workflows/create-workflow/workflow-creation-guide.md`
|
|
||||||
- Check conversion mappings at `/{bmad_folder}/bmb/data/v4-to-v6-mappings.yaml`
|
|
||||||
- Validate output using `checklist.md`
|
|
||||||
- Consult BMAD v6 documentation for proper conventions
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
_Part of the BMad Method v6 - BMB (Builder) Module_
|
|
||||||
|
|
@ -1,205 +0,0 @@
|
||||||
# Convert Legacy - Validation Checklist
|
|
||||||
|
|
||||||
## Pre-Conversion Validation
|
|
||||||
|
|
||||||
### Source Analysis
|
|
||||||
|
|
||||||
- [ ] Original v4 file(s) fully loaded and parsed
|
|
||||||
- [ ] Item type correctly identified (agent/template/task/module)
|
|
||||||
- [ ] All dependencies documented and accounted for
|
|
||||||
- [ ] No critical content overlooked in source files
|
|
||||||
|
|
||||||
## Conversion Completeness
|
|
||||||
|
|
||||||
### For Agent Conversions
|
|
||||||
|
|
||||||
#### Content Preservation
|
|
||||||
|
|
||||||
- [ ] Agent name, id, title, and icon transferred
|
|
||||||
- [ ] All persona elements mapped to v6 structure
|
|
||||||
- [ ] All commands converted to v6 menu array (YAML)
|
|
||||||
- [ ] Dependencies properly referenced or converted
|
|
||||||
- [ ] Activation instructions adapted to v6 patterns
|
|
||||||
|
|
||||||
#### v6 Compliance (YAML Format)
|
|
||||||
|
|
||||||
- [ ] Valid YAML structure with proper indentation
|
|
||||||
- [ ] agent.metadata has all required fields (id, name, title, icon, module)
|
|
||||||
- [ ] agent.persona has all sections (role, identity, communication_style, principles)
|
|
||||||
- [ ] agent.menu uses proper handlers (workflow, action, exec, tmpl, data)
|
|
||||||
- [ ] agent.critical_actions array present when needed
|
|
||||||
- [ ] agent.prompts defined for any action: "#id" references
|
|
||||||
- [ ] File extension is .agent.yaml (will be compiled to .md later)
|
|
||||||
|
|
||||||
#### Best Practices
|
|
||||||
|
|
||||||
- [ ] Commands use appropriate workflow references instead of direct task calls
|
|
||||||
- [ ] File paths use {project-root} variables
|
|
||||||
- [ ] Config values use {config_source}: pattern
|
|
||||||
- [ ] Agent follows naming conventions (kebab-case for files)
|
|
||||||
- [ ] ALL paths reference {project-root}/{bmad_folder}/{{module}}/ locations, NOT src/
|
|
||||||
- [ ] exec, data, workflow commands point to final BMAD installation paths
|
|
||||||
|
|
||||||
### For Template/Workflow Conversions
|
|
||||||
|
|
||||||
#### Content Preservation
|
|
||||||
|
|
||||||
- [ ] Template metadata (name, description, output) transferred
|
|
||||||
- [ ] All sections converted to workflow steps
|
|
||||||
- [ ] Section hierarchy maintained in instructions
|
|
||||||
- [ ] Variables ({{var}}) preserved in template.md
|
|
||||||
- [ ] Elicitation points (elicit: true) converted to <invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml</invoke-task>
|
|
||||||
- [ ] Conditional sections preserved with if="" attributes
|
|
||||||
- [ ] Repeatable sections converted to repeat="" attributes
|
|
||||||
|
|
||||||
#### v6 Compliance
|
|
||||||
|
|
||||||
- [ ] workflow.yaml follows structure from workflow-creation-guide.md
|
|
||||||
- [ ] instructions.md has critical headers referencing workflow engine
|
|
||||||
- [ ] Steps numbered sequentially with clear goals
|
|
||||||
- [ ] Template variables match between instructions and template.md
|
|
||||||
- [ ] Proper use of XML tags (<action>, <check>, <ask>, <template-output>)
|
|
||||||
- [ ] File structure follows v6 pattern (folder with yaml/md files)
|
|
||||||
|
|
||||||
#### Best Practices
|
|
||||||
|
|
||||||
- [ ] Steps are focused with single goals
|
|
||||||
- [ ] Instructions are specific ("Write 1-2 paragraphs" not "Write about")
|
|
||||||
- [ ] Examples provided where helpful
|
|
||||||
- [ ] Limits set where appropriate ("3-5 items maximum")
|
|
||||||
- [ ] Save checkpoints with <template-output> at logical points
|
|
||||||
- [ ] Variables use descriptive snake_case names
|
|
||||||
|
|
||||||
### For Task Conversions
|
|
||||||
|
|
||||||
#### Content Preservation
|
|
||||||
|
|
||||||
- [ ] Task logic fully captured in workflow instructions
|
|
||||||
- [ ] Execution flow maintained
|
|
||||||
- [ ] User interaction points preserved
|
|
||||||
- [ ] Decision trees converted to workflow logic
|
|
||||||
- [ ] All processing steps accounted for
|
|
||||||
- [ ] Document generation patterns identified and preserved
|
|
||||||
|
|
||||||
#### Type Determination
|
|
||||||
|
|
||||||
- [ ] Workflow type correctly identified (document/action/interactive/meta)
|
|
||||||
- [ ] If generates documents, template.md created
|
|
||||||
- [ ] If performs actions only, marked as action workflow
|
|
||||||
- [ ] Output patterns properly analyzed
|
|
||||||
|
|
||||||
#### v6 Compliance
|
|
||||||
|
|
||||||
- [ ] Converted to proper workflow format (not standalone task)
|
|
||||||
- [ ] Follows workflow execution engine patterns
|
|
||||||
- [ ] Interactive elements use proper v6 tags
|
|
||||||
- [ ] Flow control uses v6 patterns (goto, check, loop)
|
|
||||||
- [ ] 1-9 elicitation menus converted to v6 elicitation
|
|
||||||
- [ ] Critical notices preserved in workflow.yaml
|
|
||||||
- [ ] YOLO mode converted to appropriate v6 patterns
|
|
||||||
|
|
||||||
### Module-Level Validation
|
|
||||||
|
|
||||||
#### Structure
|
|
||||||
|
|
||||||
- [ ] Module follows v6 directory structure
|
|
||||||
- [ ] All components in correct locations:
|
|
||||||
- Agents in /agents/
|
|
||||||
- Workflows in /workflows/
|
|
||||||
- Data files in appropriate locations
|
|
||||||
- [ ] Config files properly formatted
|
|
||||||
|
|
||||||
#### Integration
|
|
||||||
|
|
||||||
- [ ] Cross-references between components work
|
|
||||||
- [ ] Workflow invocations use correct paths
|
|
||||||
- [ ] Data file references are valid
|
|
||||||
- [ ] No broken dependencies
|
|
||||||
|
|
||||||
## Technical Validation
|
|
||||||
|
|
||||||
### Syntax and Format
|
|
||||||
|
|
||||||
- [ ] YAML files have valid syntax (no parsing errors)
|
|
||||||
- [ ] XML structures properly formed and closed
|
|
||||||
- [ ] Markdown files render correctly
|
|
||||||
- [ ] File encoding is UTF-8
|
|
||||||
- [ ] Line endings consistent (LF)
|
|
||||||
|
|
||||||
### Path Resolution
|
|
||||||
|
|
||||||
- [ ] All file paths resolve correctly
|
|
||||||
- [ ] Variable substitutions work ({project-root}, {installed_path}, etc.)
|
|
||||||
- [ ] Config references load properly
|
|
||||||
- [ ] No hardcoded absolute paths (unless intentional)
|
|
||||||
|
|
||||||
## Functional Validation
|
|
||||||
|
|
||||||
### Execution Testing
|
|
||||||
|
|
||||||
- [ ] Converted item can be loaded without errors
|
|
||||||
- [ ] Agents activate properly when invoked
|
|
||||||
- [ ] Workflows execute through completion
|
|
||||||
- [ ] User interaction points function correctly
|
|
||||||
- [ ] Output generation works as expected
|
|
||||||
|
|
||||||
### Behavioral Validation
|
|
||||||
|
|
||||||
- [ ] Converted item behaves similarly to v4 version
|
|
||||||
- [ ] Core functionality preserved
|
|
||||||
- [ ] User experience maintains or improves
|
|
||||||
- [ ] No functionality regression
|
|
||||||
|
|
||||||
## Documentation and Cleanup
|
|
||||||
|
|
||||||
### Documentation
|
|
||||||
|
|
||||||
- [ ] Conversion report generated with all changes
|
|
||||||
- [ ] Any manual adjustments documented
|
|
||||||
- [ ] Known limitations or differences noted
|
|
||||||
- [ ] Migration instructions provided if needed
|
|
||||||
|
|
||||||
### Post-Conversion
|
|
||||||
|
|
||||||
- [ ] Original v4 files archived (if requested)
|
|
||||||
- [ ] File permissions set correctly
|
|
||||||
- [ ] Git tracking updated if applicable
|
|
||||||
- [ ] User informed of new locations
|
|
||||||
|
|
||||||
## Final Verification
|
|
||||||
|
|
||||||
### Quality Assurance
|
|
||||||
|
|
||||||
- [ ] Converted item follows ALL v6 best practices
|
|
||||||
- [ ] Code/config is clean and maintainable
|
|
||||||
- [ ] No TODO or FIXME items remain
|
|
||||||
- [ ] Ready for production use
|
|
||||||
|
|
||||||
### User Acceptance
|
|
||||||
|
|
||||||
- [ ] User reviewed conversion output
|
|
||||||
- [ ] User tested basic functionality
|
|
||||||
- [ ] User approved final result
|
|
||||||
- [ ] Any user feedback incorporated
|
|
||||||
|
|
||||||
## Notes Section
|
|
||||||
|
|
||||||
### Conversion Issues Found:
|
|
||||||
|
|
||||||
_List any issues encountered during validation_
|
|
||||||
|
|
||||||
### Manual Interventions Required:
|
|
||||||
|
|
||||||
_Document any manual fixes needed_
|
|
||||||
|
|
||||||
### Recommendations:
|
|
||||||
|
|
||||||
_Suggestions for further improvements or considerations_
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Validation Result:** [ ] PASSED / [ ] FAILED
|
|
||||||
|
|
||||||
**Validator:** {{user_name}}
|
|
||||||
**Date:** {{date}}
|
|
||||||
**Items Converted:** {{conversion_summary}}
|
|
||||||
|
|
@ -1,377 +0,0 @@
|
||||||
# Convert Legacy - v4 to v6 Conversion Instructions
|
|
||||||
|
|
||||||
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
|
|
||||||
<parameter name="You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/convert-legacy/workflow.yaml</critical>
|
|
||||||
<critical>Communicate in {communication_language} throughout the conversion process</critical>
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="1" goal="Identify and Load Legacy Item">
|
|
||||||
<action>Ask user for the path to the v4 item to convert (agent, workflow, or module)</action>
|
|
||||||
<action>Load the complete file/folder structure</action>
|
|
||||||
<action>Detect item type based on structure and content patterns:</action>
|
|
||||||
- Agent: Contains agent or prompt XML tags, single file
|
|
||||||
- Workflow: Contains workflow YAML or instruction patterns, usually folder
|
|
||||||
- Module: Contains multiple agents/workflows in organized structure
|
|
||||||
- Task: Contains task XML tags
|
|
||||||
<ask>Confirm detected type or allow user to correct: "Detected as [type]. Is this correct? (y/n)"</ask>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Analyze Legacy Structure">
|
|
||||||
<action>Parse the v4 structure and extract key components:</action>
|
|
||||||
|
|
||||||
For v4 Agents (YAML-based in markdown):
|
|
||||||
|
|
||||||
- Agent metadata (name, id, title, icon, whenToUse)
|
|
||||||
- Persona block (role, style, identity, focus, core_principles)
|
|
||||||
- Commands list with task/template references
|
|
||||||
- Dependencies (tasks, templates, checklists, data files)
|
|
||||||
- Activation instructions and workflow rules
|
|
||||||
- IDE file resolution patterns
|
|
||||||
|
|
||||||
For v4 Templates (YAML-based document generators):
|
|
||||||
|
|
||||||
- Template metadata (id, name, version, output)
|
|
||||||
- Workflow mode and elicitation settings
|
|
||||||
- Sections hierarchy with:
|
|
||||||
- Instructions for content generation
|
|
||||||
- Elicit flags for user interaction
|
|
||||||
- Templates with {{variables}}
|
|
||||||
- Conditional sections
|
|
||||||
- Repeatable sections
|
|
||||||
|
|
||||||
For v4 Tasks (Markdown with execution instructions):
|
|
||||||
|
|
||||||
- Critical execution notices
|
|
||||||
- Step-by-step workflows
|
|
||||||
- Elicitation requirements (1-9 menu format)
|
|
||||||
- Processing flows and decision trees
|
|
||||||
- Agent permission rules
|
|
||||||
|
|
||||||
For Modules:
|
|
||||||
|
|
||||||
- Module metadata
|
|
||||||
- Component list (agents, workflows, tasks)
|
|
||||||
- Dependencies
|
|
||||||
- Installation requirements
|
|
||||||
|
|
||||||
<action>Create a conversion map of what needs to be transformed</action>
|
|
||||||
<action>Map v4 patterns to v6 equivalents:
|
|
||||||
|
|
||||||
- v4 Task + Template → v6 Workflow (folder with workflow.yaml, instructions.md, template.md)
|
|
||||||
- v4 Agent YAML → v6 Agent YAML format
|
|
||||||
- v4 Commands → v6 <menu> with proper handlers
|
|
||||||
- v4 Dependencies → v6 workflow references or data files
|
|
||||||
</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Determine Target Module and Location">
|
|
||||||
<ask>Which module should this belong to? (eg. bmm, bmb, cis, bmm-legacy, or custom)</ask>
|
|
||||||
<action if="custom module"><ask>Enter custom module code (kebab-case):</ask></action>
|
|
||||||
<action>Determine installation path based on type and module</action>
|
|
||||||
<critical>IMPORTANT: All paths must use final BMAD installation locations, not src paths!</critical>
|
|
||||||
<action>Show user the target location: {project-root}/{bmad_folder}/{{target_module}}/{{item_type}}/{{item_name}}</action>
|
|
||||||
<action>Note: Files will be created in {bmad_folder}/ but all internal paths will reference {project-root}/{bmad_folder}/ locations</action>
|
|
||||||
<ask>Proceed with this location? (y/n)</ask>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Choose Conversion Strategy">
|
|
||||||
<action>Based on item type and complexity, choose approach:</action>
|
|
||||||
|
|
||||||
<check if="agent conversion">
|
|
||||||
<check if="simple agent (basic persona + commands)">
|
|
||||||
<action>Use direct conversion to v6 agent YAML format</action>
|
|
||||||
<goto step="5a">Direct Agent Conversion</goto>
|
|
||||||
</check>
|
|
||||||
<check if="complex agent with embedded workflows">
|
|
||||||
<action>Plan to invoke create-agent workflow</action>
|
|
||||||
<goto step="5b">Workflow-Assisted Agent Creation</goto>
|
|
||||||
</check>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="template or task conversion to workflow">
|
|
||||||
<action>Analyze the v4 item to determine workflow type:</action>
|
|
||||||
|
|
||||||
- Does it generate a specific document type? → Document workflow
|
|
||||||
- Does it produce structured output files? → Document workflow
|
|
||||||
- Does it perform actions without output? → Action workflow
|
|
||||||
- Does it coordinate other tasks? → Meta-workflow
|
|
||||||
- Does it guide user interaction? → Interactive workflow
|
|
||||||
|
|
||||||
<ask>Based on analysis, this appears to be a {{detected_workflow_type}} workflow. Confirm or correct:
|
|
||||||
|
|
||||||
1. Document workflow (generates documents with template)
|
|
||||||
2. Action workflow (performs actions, no template)
|
|
||||||
3. Interactive workflow (guided session)
|
|
||||||
4. Meta-workflow (coordinates other workflows)
|
|
||||||
Select 1-4:</ask>
|
|
||||||
|
|
||||||
<action if="template conversion"><goto step="5c">Template-to-Workflow Conversion</goto></action>
|
|
||||||
<action if="task conversion"><goto step="5e">Task-to-Workflow Conversion</goto></action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="full module conversion">
|
|
||||||
<action>Plan to invoke create-module workflow</action>
|
|
||||||
<goto step="5d">Module Creation</goto>
|
|
||||||
</check>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5a" goal="Direct Agent Conversion" optional="true">
|
|
||||||
<action>Transform v4 YAML agent to v6 YAML format:</action>
|
|
||||||
|
|
||||||
1. Convert agent metadata structure:
|
|
||||||
- v4 `agent.name` → v6 `agent.metadata.name`
|
|
||||||
- v4 `agent.id` → v6 `agent.metadata.id`
|
|
||||||
- v4 `agent.title` → v6 `agent.metadata.title`
|
|
||||||
- v4 `agent.icon` → v6 `agent.metadata.icon`
|
|
||||||
- Add v6 `agent.metadata.module` field
|
|
||||||
|
|
||||||
2. Transform persona structure:
|
|
||||||
- v4 `persona.role` → v6 `agent.persona.role` (keep as YAML string)
|
|
||||||
- v4 `persona.style` → v6 `agent.persona.communication_style`
|
|
||||||
- v4 `persona.identity` → v6 `agent.persona.identity`
|
|
||||||
- v4 `persona.core_principles` → v6 `agent.persona.principles` (as array)
|
|
||||||
|
|
||||||
3. Convert commands to menu:
|
|
||||||
- v4 `commands:` list → v6 `agent.menu:` array
|
|
||||||
- Each command becomes menu item with:
|
|
||||||
- `trigger:` (without \* prefix - added at build)
|
|
||||||
- `description:`
|
|
||||||
- Handler attributes (`workflow:`, `exec:`, `action:`, etc.)
|
|
||||||
- Map task references to workflow paths
|
|
||||||
- Map template references to workflow invocations
|
|
||||||
|
|
||||||
4. Add v6-specific sections (in YAML):
|
|
||||||
- `agent.prompts:` array for inline prompts (if using action: "#id")
|
|
||||||
- `agent.critical_actions:` array for startup requirements
|
|
||||||
- `agent.activation_rules:` for universal agent rules
|
|
||||||
|
|
||||||
5. Handle dependencies and paths:
|
|
||||||
- Convert task dependencies to workflow references
|
|
||||||
- Map template dependencies to v6 workflows
|
|
||||||
- Preserve checklist and data file references
|
|
||||||
- CRITICAL: All paths must use {project-root}/{bmad_folder}/{{module}}/ NOT src/
|
|
||||||
|
|
||||||
<action>Generate the converted v6 agent YAML file (.agent.yaml)</action>
|
|
||||||
<action>Example path conversions:
|
|
||||||
|
|
||||||
- exec="{project-root}/{bmad_folder}/{{target_module}}/tasks/task-name.md"
|
|
||||||
- workflow="{project-root}/{bmad_folder}/{{target_module}}/workflows/workflow-name/workflow.yaml"
|
|
||||||
- data="{project-root}/{bmad_folder}/{{target_module}}/data/data-file.yaml"
|
|
||||||
</action>
|
|
||||||
<action>Save to: {bmad_folder}/{{target_module}}/agents/{{agent_name}}.agent.yaml (physical location)</action>
|
|
||||||
<action>Note: The build process will later compile this to .md with XML format</action>
|
|
||||||
<goto step="6">Continue to Validation</goto>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5b" goal="Workflow-Assisted Agent Creation" optional="true">
|
|
||||||
<action>Extract key information from v4 agent:</action>
|
|
||||||
- Name and purpose
|
|
||||||
- Commands and functionality
|
|
||||||
- Persona traits
|
|
||||||
- Any special behaviors
|
|
||||||
|
|
||||||
<invoke-workflow>
|
|
||||||
workflow: {project-root}/{bmad_folder}/bmb/workflows/create-agent/workflow.yaml
|
|
||||||
inputs:
|
|
||||||
- agent_name: {{extracted_name}}
|
|
||||||
- agent_purpose: {{extracted_purpose}}
|
|
||||||
- commands: {{extracted_commands}}
|
|
||||||
- persona: {{extracted_persona}}
|
|
||||||
</invoke-workflow>
|
|
||||||
|
|
||||||
<goto step="6">Continue to Validation</goto>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5c" goal="Template-to-Workflow Conversion" optional="true">
|
|
||||||
<action>Convert v4 Template (YAML) to v6 Workflow:</action>
|
|
||||||
|
|
||||||
1. Extract template metadata:
|
|
||||||
- Template id, name, version → workflow.yaml name/description
|
|
||||||
- Output settings → default_output_file
|
|
||||||
- Workflow mode (interactive/yolo) → workflow settings
|
|
||||||
|
|
||||||
2. Convert template sections to instructions.md:
|
|
||||||
- Each YAML section → workflow step
|
|
||||||
- `elicit: true` → `<invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml</invoke-task>` tag
|
|
||||||
- Conditional sections → `if="condition"` attribute
|
|
||||||
- Repeatable sections → `repeat="for-each"` attribute
|
|
||||||
- Section instructions → step content
|
|
||||||
|
|
||||||
3. Extract template structure to template.md:
|
|
||||||
- Section content fields → template structure
|
|
||||||
- {{variables}} → preserve as-is
|
|
||||||
- Nested sections → hierarchical markdown
|
|
||||||
|
|
||||||
4. Handle v4 create-doc.md task integration:
|
|
||||||
- Elicitation methods (1-9 menu) → convert to v6 elicitation
|
|
||||||
- Agent permissions → note in instructions
|
|
||||||
- Processing flow → integrate into workflow steps
|
|
||||||
|
|
||||||
<critical>When invoking create-workflow, the standard config block will be automatically added:</critical>
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# Critical variables from config
|
|
||||||
config_source: '{project-root}/{bmad_folder}/{{target_module}}/config.yaml'
|
|
||||||
output_folder: '{config_source}:output_folder'
|
|
||||||
user_name: '{config_source}:user_name'
|
|
||||||
communication_language: '{config_source}:communication_language'
|
|
||||||
date: system-generated
|
|
||||||
```
|
|
||||||
|
|
||||||
<invoke-workflow>
|
|
||||||
workflow: {project-root}/{bmad_folder}/bmb/workflows/create-workflow/workflow.yaml
|
|
||||||
inputs:
|
|
||||||
- workflow_name: {{template_name}}
|
|
||||||
- workflow_type: document
|
|
||||||
- template_structure: {{extracted_template}}
|
|
||||||
- instructions: {{converted_sections}}
|
|
||||||
</invoke-workflow>
|
|
||||||
|
|
||||||
<action>Verify the created workflow.yaml includes standard config block</action>
|
|
||||||
<action>Update converted instructions to use config variables where appropriate</action>
|
|
||||||
|
|
||||||
<goto step="6">Continue to Validation</goto>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5d" goal="Module Creation" optional="true">
|
|
||||||
<action>Analyze module structure and components</action>
|
|
||||||
<action>Create module blueprint with all components</action>
|
|
||||||
|
|
||||||
<invoke-workflow>
|
|
||||||
workflow: {project-root}/{bmad_folder}/bmb/workflows/create-module/workflow.yaml
|
|
||||||
inputs:
|
|
||||||
- module_name: {{module_name}}
|
|
||||||
- components: {{component_list}}
|
|
||||||
</invoke-workflow>
|
|
||||||
|
|
||||||
<goto step="6">Continue to Validation</goto>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5e" goal="Task-to-Workflow Conversion" optional="true">
|
|
||||||
<action>Convert v4 Task (Markdown) to v6 Workflow:</action>
|
|
||||||
|
|
||||||
1. Analyze task purpose and output:
|
|
||||||
- Does it generate documents? → Create template.md
|
|
||||||
- Does it process data? → Action workflow
|
|
||||||
- Does it guide user interaction? → Interactive workflow
|
|
||||||
- Check for file outputs, templates, or document generation
|
|
||||||
|
|
||||||
2. Extract task components:
|
|
||||||
- Execution notices and critical rules → workflow.yaml metadata
|
|
||||||
- Step-by-step instructions → instructions.md steps
|
|
||||||
- Decision trees and branching → flow control tags
|
|
||||||
- User interaction patterns → appropriate v6 tags
|
|
||||||
|
|
||||||
3. Based on confirmed workflow type:
|
|
||||||
<check if="Document workflow">
|
|
||||||
- Create template.md from output patterns
|
|
||||||
- Map generation steps to instructions
|
|
||||||
- Add template-output tags for sections
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="Action workflow">
|
|
||||||
- Set template: false in workflow.yaml
|
|
||||||
- Focus on action sequences in instructions
|
|
||||||
- Preserve execution logic
|
|
||||||
</check>
|
|
||||||
|
|
||||||
4. Handle special v4 patterns:
|
|
||||||
- 1-9 elicitation menus → v6 <invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml</invoke-task>
|
|
||||||
- Agent permissions → note in instructions
|
|
||||||
- YOLO mode → autonomous flag or optional steps
|
|
||||||
- Critical notices → workflow.yaml comments
|
|
||||||
|
|
||||||
<critical>When invoking create-workflow, the standard config block will be automatically added:</critical>
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# Critical variables from config
|
|
||||||
config_source: '{project-root}/{bmad_folder}/{{target_module}}/config.yaml'
|
|
||||||
output_folder: '{config_source}:output_folder'
|
|
||||||
user_name: '{config_source}:user_name'
|
|
||||||
communication_language: '{config_source}:communication_language'
|
|
||||||
date: system-generated
|
|
||||||
```
|
|
||||||
|
|
||||||
<invoke-workflow>
|
|
||||||
workflow: {project-root}/{bmad_folder}/bmb/workflows/create-workflow/workflow.yaml
|
|
||||||
inputs:
|
|
||||||
- workflow_name: {{task_name}}
|
|
||||||
- workflow_type: {{confirmed_workflow_type}}
|
|
||||||
- instructions: {{extracted_task_logic}}
|
|
||||||
- template: {{generated_template_if_document}}
|
|
||||||
</invoke-workflow>
|
|
||||||
|
|
||||||
<action>Verify the created workflow.yaml includes standard config block</action>
|
|
||||||
<action>Update converted instructions to use config variables where appropriate</action>
|
|
||||||
|
|
||||||
<goto step="6">Continue to Validation</goto>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="6" goal="Validate Conversion">
|
|
||||||
<action>Run validation checks on converted item:</action>
|
|
||||||
|
|
||||||
For Agents:
|
|
||||||
|
|
||||||
- [ ] Valid YAML structure (.agent.yaml)
|
|
||||||
- [ ] All required sections present (metadata, persona, menu)
|
|
||||||
- [ ] Menu items properly formatted (trigger, description, handlers)
|
|
||||||
- [ ] Paths use {project-root} variables
|
|
||||||
|
|
||||||
For Workflows:
|
|
||||||
|
|
||||||
- [ ] Valid YAML syntax
|
|
||||||
- [ ] Instructions follow v6 conventions
|
|
||||||
- [ ] Template variables match
|
|
||||||
- [ ] File structure correct
|
|
||||||
|
|
||||||
**Standard Config Validation (Workflows):**
|
|
||||||
|
|
||||||
- [ ] workflow.yaml contains standard config block:
|
|
||||||
- config_source defined
|
|
||||||
- output_folder, user_name, communication_language pulled from config
|
|
||||||
- date set to system-generated
|
|
||||||
- [ ] Converted instructions use config variables where appropriate
|
|
||||||
- [ ] Template includes config variables in metadata (if document workflow)
|
|
||||||
- [ ] No hardcoded paths that should use {output_folder}
|
|
||||||
- [ ] No generic greetings that should use {user_name}
|
|
||||||
|
|
||||||
For Modules:
|
|
||||||
|
|
||||||
- [ ] All components converted
|
|
||||||
- [ ] Proper folder structure
|
|
||||||
- [ ] Config files valid
|
|
||||||
- [ ] Installation ready
|
|
||||||
|
|
||||||
<action>Show validation results to user</action>
|
|
||||||
<ask>Any issues to fix before finalizing? (y/n)</ask>
|
|
||||||
<check if="yes">
|
|
||||||
<action>Address specific issues</action>
|
|
||||||
<goto step="6">Re-validate</goto>
|
|
||||||
</check>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="7" goal="Migration Report">
|
|
||||||
<action>Generate conversion report showing:</action>
|
|
||||||
- Original v4 location
|
|
||||||
- New v6 location
|
|
||||||
- Items converted
|
|
||||||
- Any manual adjustments needed
|
|
||||||
- Warnings or notes
|
|
||||||
|
|
||||||
<action>Save report to: {output_folder}/conversion-report-{{date}}.md</action>
|
|
||||||
<action>Inform {user_name} in {communication_language} that the conversion report has been generated</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="8" goal="Cleanup and Finalize">
|
|
||||||
<ask>Archive original v4 files? (y/n)</ask>
|
|
||||||
<action if="yes">Move v4 files to: {project-root}/archive/v4-legacy/{{date}}/</action>
|
|
||||||
|
|
||||||
<action>Show user the final converted items and their locations</action>
|
|
||||||
<action>Provide any post-conversion instructions or recommendations</action>
|
|
||||||
|
|
||||||
<ask>Would you like to convert another legacy item? (y/n)</ask>
|
|
||||||
<action if="yes"><goto step="1">Start new conversion</goto></action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
|
|
@ -1,30 +0,0 @@
|
||||||
# Convert Legacy - BMAD v4 to v6 Converter Configuration
|
|
||||||
name: "convert-legacy"
|
|
||||||
description: "Converts legacy BMAD v4 or similar items (agents, workflows, modules) to BMad Core compliant format with proper structure and conventions"
|
|
||||||
author: "BMad"
|
|
||||||
|
|
||||||
# Critical variables load from config_source
|
|
||||||
config_source: "{project-root}/{bmad_folder}/bmb/config.yaml"
|
|
||||||
output_folder: "{config_source}:output_folder"
|
|
||||||
user_name: "{config_source}:user_name"
|
|
||||||
communication_language: "{config_source}:communication_language"
|
|
||||||
date: system-generated
|
|
||||||
|
|
||||||
# Module path and component files
|
|
||||||
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/convert-legacy"
|
|
||||||
template: false # This is an action/meta workflow - no template needed
|
|
||||||
instructions: "{installed_path}/instructions.md"
|
|
||||||
validation: "{installed_path}/checklist.md"
|
|
||||||
|
|
||||||
# Output configuration - Creates converted items in appropriate module locations
|
|
||||||
default_output_folder: "{project-root}/{bmad_folder}/{{target_module}}/{{item_type}}/{{item_name}}"
|
|
||||||
|
|
||||||
# Sub-workflows that may be invoked for conversion
|
|
||||||
sub_workflows:
|
|
||||||
- create_agent: "{project-root}/{bmad_folder}/bmb/workflows/create-agent/workflow.yaml"
|
|
||||||
- create_workflow: "{project-root}/{bmad_folder}/bmb/workflows/create-workflow/workflow.yaml"
|
|
||||||
- create_module: "{project-root}/{bmad_folder}/bmb/workflows/create-module/workflow.yaml"
|
|
||||||
|
|
||||||
standalone: true
|
|
||||||
|
|
||||||
web_bundle: false
|
|
||||||
|
|
@ -1,174 +0,0 @@
|
||||||
# BMAD Agent Validation Checklist
|
|
||||||
|
|
||||||
Use this checklist to validate agents meet BMAD quality standards, whether creating new agents or editing existing ones.
|
|
||||||
|
|
||||||
## YAML Structure Validation (Source Files)
|
|
||||||
|
|
||||||
- [ ] YAML parses without errors
|
|
||||||
- [ ] `agent.metadata` includes: `id`, `name`, `title`, `icon`
|
|
||||||
- [ ] `agent.metadata.module` present if Module agent (e.g., `bmm`, `bmgd`, `cis`)
|
|
||||||
- [ ] `agent.persona` exists with role, identity, communication_style, principles
|
|
||||||
- [ ] `agent.menu` exists with at least one item
|
|
||||||
- [ ] Filename is kebab-case and ends with `.agent.yaml`
|
|
||||||
|
|
||||||
## Agent Structure Validation
|
|
||||||
|
|
||||||
- [ ] Agent file format is valid (.agent.yaml for source)
|
|
||||||
- [ ] Agent type matches structure: Simple (single YAML), Expert (sidecar files), or Module (ecosystem integration)
|
|
||||||
- [ ] File naming follows convention: `{agent-name}.agent.yaml`
|
|
||||||
- [ ] If Expert: folder structure with .agent.yaml + sidecar files
|
|
||||||
- [ ] If Module: includes header comment explaining WHY Module Agent (design intent)
|
|
||||||
|
|
||||||
## Persona Validation (CRITICAL - #1 Quality Issue)
|
|
||||||
|
|
||||||
**Field Separation Check:**
|
|
||||||
|
|
||||||
- [ ] **role** contains ONLY knowledge/skills/capabilities (what agent does)
|
|
||||||
- [ ] **identity** contains ONLY background/experience/context (who agent is)
|
|
||||||
- [ ] **communication_style** contains ONLY verbal patterns - NO behaviors, NO role statements, NO principles
|
|
||||||
- [ ] **principles** contains operating philosophy and behavioral guidelines
|
|
||||||
|
|
||||||
**Communication Style Purity Check:**
|
|
||||||
|
|
||||||
- [ ] Communication style does NOT contain red flag words: "ensures", "makes sure", "always", "never"
|
|
||||||
- [ ] Communication style does NOT contain identity words: "experienced", "expert who", "senior", "seasoned"
|
|
||||||
- [ ] Communication style does NOT contain philosophy words: "believes in", "focused on", "committed to"
|
|
||||||
- [ ] Communication style does NOT contain behavioral descriptions: "who does X", "that does Y"
|
|
||||||
- [ ] Communication style is 1-2 sentences describing HOW they talk (word choice, quirks, verbal patterns)
|
|
||||||
|
|
||||||
**Quality Benchmarking:**
|
|
||||||
|
|
||||||
- [ ] Compare communication style against {communication_presets} - similarly pure?
|
|
||||||
- [ ] Compare against reference agents (commit-poet, journal-keeper, BMM agents) - similar quality?
|
|
||||||
- [ ] Read communication style aloud - does it sound like describing someone's voice/speech pattern?
|
|
||||||
|
|
||||||
## Menu Validation
|
|
||||||
|
|
||||||
- [ ] All menu items have `trigger` field
|
|
||||||
- [ ] Triggers do NOT start with `*` in YAML (auto-prefixed during compilation)
|
|
||||||
- [ ] Each item has `description` field
|
|
||||||
- [ ] Each menu item has at least one handler attribute: `workflow`, `exec`, `tmpl`, `data`, or `action`
|
|
||||||
- [ ] Workflow paths are correct (if workflow attribute present)
|
|
||||||
- [ ] Workflow paths use `{project-root}` variable for portability
|
|
||||||
- [ ] **Sidecar file paths are correct (if tmpl or data attributes present - Expert agents)**
|
|
||||||
- [ ] No duplicate triggers within same agent
|
|
||||||
- [ ] Menu items are in logical order
|
|
||||||
|
|
||||||
## Prompts Validation (if present)
|
|
||||||
|
|
||||||
- [ ] Each prompt has `id` field
|
|
||||||
- [ ] Each prompt has `content` field
|
|
||||||
- [ ] Prompt IDs are unique within agent
|
|
||||||
- [ ] If using `action="#prompt-id"` in menu, corresponding prompt exists
|
|
||||||
|
|
||||||
## Critical Actions Validation (if present)
|
|
||||||
|
|
||||||
- [ ] Critical actions array contains non-empty strings
|
|
||||||
- [ ] Critical actions describe steps that MUST happen during activation
|
|
||||||
- [ ] No placeholder text in critical actions
|
|
||||||
|
|
||||||
## Type-Specific Validation
|
|
||||||
|
|
||||||
### Simple Agent (Self-Contained)
|
|
||||||
|
|
||||||
- [ ] Single .agent.yaml file with complete agent definition
|
|
||||||
- [ ] No sidecar files (all content in YAML)
|
|
||||||
- [ ] Not capability-limited - can be as powerful as Expert or Module
|
|
||||||
- [ ] Compare against reference: commit-poet.agent.yaml
|
|
||||||
|
|
||||||
### Expert Agent (With Sidecar Files)
|
|
||||||
|
|
||||||
- [ ] Folder structure: .agent.yaml + sidecar files
|
|
||||||
- [ ] Sidecar files properly referenced in menu items or prompts (tmpl="path", data="path")
|
|
||||||
- [ ] Folder name matches agent purpose
|
|
||||||
- [ ] **All sidecar references in YAML resolve to actual files**
|
|
||||||
- [ ] **All sidecar files are actually used (no orphaned/unused files, unless intentional for future use)**
|
|
||||||
- [ ] Sidecar files are valid format (YAML parses, CSV has headers, markdown is well-formed)
|
|
||||||
- [ ] Sidecar file paths use relative paths from agent folder
|
|
||||||
- [ ] Templates contain valid template variables if applicable
|
|
||||||
- [ ] Knowledge base files contain current/accurate information
|
|
||||||
- [ ] Compare against reference: journal-keeper (Expert example)
|
|
||||||
|
|
||||||
### Module Agent (Ecosystem Integration)
|
|
||||||
|
|
||||||
- [ ] Designed FOR specific module (BMM, BMGD, CIS, etc.)
|
|
||||||
- [ ] Integrates with module workflows (referenced in menu items)
|
|
||||||
- [ ] Coordinates with other module agents (if applicable)
|
|
||||||
- [ ] Included in module's default bundle (if applicable)
|
|
||||||
- [ ] Header comment explains WHY Module Agent (design intent, not just location)
|
|
||||||
- [ ] Can be Simple OR Expert structurally (Module is about intent, not structure)
|
|
||||||
- [ ] Compare against references: security-engineer, dev, analyst (Module examples)
|
|
||||||
|
|
||||||
## Compilation Validation (Post-Build)
|
|
||||||
|
|
||||||
- [ ] Agent compiles without errors to .md format
|
|
||||||
- [ ] Compiled file has proper frontmatter (name, description)
|
|
||||||
- [ ] Compiled XML structure is valid
|
|
||||||
- [ ] `<agent>` tag has id, name, title, icon attributes
|
|
||||||
- [ ] `<activation>` section is present with proper steps
|
|
||||||
- [ ] `<persona>` section compiled correctly
|
|
||||||
- [ ] `<menu>` section includes both user items AND auto-injected *help/*exit
|
|
||||||
- [ ] Menu handlers section included (if menu items use workflow/exec/tmpl/data/action)
|
|
||||||
|
|
||||||
## Quality Checks
|
|
||||||
|
|
||||||
- [ ] No placeholder text remains ({{AGENT_NAME}}, {ROLE}, TODO, etc.)
|
|
||||||
- [ ] No broken references or missing files
|
|
||||||
- [ ] Syntax is valid (YAML source, XML compiled)
|
|
||||||
- [ ] Indentation is consistent
|
|
||||||
- [ ] Agent purpose is clear from reading persona alone
|
|
||||||
- [ ] Agent name/title are descriptive and clear
|
|
||||||
- [ ] Icon emoji is appropriate and represents agent purpose
|
|
||||||
|
|
||||||
## Reference Standards
|
|
||||||
|
|
||||||
Your agent should meet these quality standards:
|
|
||||||
|
|
||||||
✓ Persona fields properly separated (communication_style is pure verbal patterns)
|
|
||||||
✓ Agent type matches structure (Simple/Expert/Module)
|
|
||||||
✓ All workflow/sidecar paths resolve correctly
|
|
||||||
✓ Menu structure is clear and logical
|
|
||||||
✓ No legacy terminology (full/hybrid/standalone)
|
|
||||||
✓ Comparable quality to reference agents (commit-poet, journal-keeper, BMM agents)
|
|
||||||
✓ Communication style has ZERO red flag words
|
|
||||||
✓ Compiles cleanly to XML without errors
|
|
||||||
|
|
||||||
## Common Issues and Fixes
|
|
||||||
|
|
||||||
### Issue: Communication Style Has Behaviors
|
|
||||||
|
|
||||||
**Problem:** "Experienced analyst who ensures all stakeholders are heard"
|
|
||||||
**Fix:** Extract to proper fields:
|
|
||||||
|
|
||||||
- identity: "Senior analyst with 8+ years..."
|
|
||||||
- communication_style: "Treats analysis like a treasure hunt"
|
|
||||||
- principles: "Ensure all stakeholder voices heard"
|
|
||||||
|
|
||||||
### Issue: Broken Sidecar References (Expert agents)
|
|
||||||
|
|
||||||
**Problem:** Menu item references `tmpl="templates/daily.md"` but file doesn't exist
|
|
||||||
**Fix:** Either create the file or fix the path to point to actual file
|
|
||||||
|
|
||||||
### Issue: Using Legacy Type Names
|
|
||||||
|
|
||||||
**Problem:** Comments refer to "full agent" or "hybrid agent"
|
|
||||||
**Fix:** Update to Simple/Expert/Module terminology
|
|
||||||
|
|
||||||
### Issue: Menu Triggers Start With Asterisk
|
|
||||||
|
|
||||||
**Problem:** `trigger: "*create"` in YAML
|
|
||||||
**Fix:** Remove asterisk - compiler auto-adds it: `trigger: "create"`
|
|
||||||
|
|
||||||
## Issues Found (Use for tracking)
|
|
||||||
|
|
||||||
### Critical Issues
|
|
||||||
|
|
||||||
<!-- List any issues that MUST be fixed before agent can function -->
|
|
||||||
|
|
||||||
### Warnings
|
|
||||||
|
|
||||||
<!-- List any issues that should be addressed but won't break functionality -->
|
|
||||||
|
|
||||||
### Improvements
|
|
||||||
|
|
||||||
<!-- List any optional enhancements that could improve the agent -->
|
|
||||||
|
|
@ -1,153 +0,0 @@
|
||||||
# Agent Creation Brainstorming Context
|
|
||||||
|
|
||||||
_Dream the soul. Discover the purpose. The build follows._
|
|
||||||
|
|
||||||
## Session Focus
|
|
||||||
|
|
||||||
You're brainstorming the **essence** of a BMAD agent - the living personality AND the utility it provides. Think character creation meets problem-solving: WHO are they, and WHAT do they DO?
|
|
||||||
|
|
||||||
**Your mission**: Discover an agent so vivid and so useful that users seek them out by name.
|
|
||||||
|
|
||||||
## The Four Discovery Pillars
|
|
||||||
|
|
||||||
### 1. WHO ARE THEY? (Identity)
|
|
||||||
|
|
||||||
- **Name** - Does it roll off the tongue? Would users remember it?
|
|
||||||
- **Background** - What shaped their expertise? Why do they care?
|
|
||||||
- **Personality** - What makes their eyes light up? What frustrates them?
|
|
||||||
- **Signature** - Catchphrase? Verbal tic? Recognizable trait?
|
|
||||||
|
|
||||||
### 2. HOW DO THEY COMMUNICATE? (Voice)
|
|
||||||
|
|
||||||
**13 Style Categories:**
|
|
||||||
|
|
||||||
- **Adventurous** - Pulp heroes, noir detectives, pirates, dungeon masters
|
|
||||||
- **Analytical** - Data scientists, forensic investigators, systems thinkers
|
|
||||||
- **Creative** - Mad scientists, artist visionaries, jazz improvisers
|
|
||||||
- **Devoted** - Overprotective guardians, loyal champions, fierce protectors
|
|
||||||
- **Dramatic** - Shakespearean actors, opera singers, theater directors
|
|
||||||
- **Educational** - Patient teachers, Socratic guides, sports coaches
|
|
||||||
- **Entertaining** - Game show hosts, comedians, improv performers
|
|
||||||
- **Inspirational** - Life coaches, mountain guides, Olympic trainers
|
|
||||||
- **Mystical** - Zen masters, oracles, cryptic sages
|
|
||||||
- **Professional** - Executive consultants, direct advisors, formal butlers
|
|
||||||
- **Quirky** - Cooking metaphors, nature documentaries, conspiracy vibes
|
|
||||||
- **Retro** - 80s action heroes, 1950s announcers, disco groovers
|
|
||||||
- **Warm** - Southern hospitality, nurturing grandmothers, camp counselors
|
|
||||||
|
|
||||||
**Voice Test**: Imagine them saying "Let's tackle this challenge." How would THEY phrase it?
|
|
||||||
|
|
||||||
### 3. WHAT DO THEY DO? (Purpose & Functions)
|
|
||||||
|
|
||||||
**The Core Problem**
|
|
||||||
|
|
||||||
- What pain point do they eliminate?
|
|
||||||
- What task transforms from grueling to effortless?
|
|
||||||
- What impossible becomes inevitable with them?
|
|
||||||
|
|
||||||
**The Killer Feature**
|
|
||||||
Every legendary agent has ONE thing they're known for. What's theirs?
|
|
||||||
|
|
||||||
**The Command Menu**
|
|
||||||
User types `*` and sees their options. Brainstorm 5-10 actions:
|
|
||||||
|
|
||||||
- What makes users sigh with relief?
|
|
||||||
- What capabilities complement each other?
|
|
||||||
- What's the "I didn't know I needed this" command?
|
|
||||||
|
|
||||||
**Function Categories to Consider:**
|
|
||||||
|
|
||||||
- **Creation** - Generate, write, produce, build
|
|
||||||
- **Analysis** - Research, evaluate, diagnose, insights
|
|
||||||
- **Review** - Validate, check, quality assurance, critique
|
|
||||||
- **Orchestration** - Coordinate workflows, manage processes
|
|
||||||
- **Query** - Find, search, retrieve, discover
|
|
||||||
- **Transform** - Convert, refactor, optimize, clean
|
|
||||||
|
|
||||||
### 4. WHAT TYPE? (Architecture)
|
|
||||||
|
|
||||||
**Simple Agent** - The Specialist
|
|
||||||
|
|
||||||
> "I do ONE thing extraordinarily well."
|
|
||||||
|
|
||||||
- Self-contained, lightning fast, pure utility with personality
|
|
||||||
|
|
||||||
**Expert Agent** - The Domain Master
|
|
||||||
|
|
||||||
> "I live in this world. I remember everything."
|
|
||||||
|
|
||||||
- Deep domain knowledge, personal memory, specialized expertise
|
|
||||||
|
|
||||||
**Module Agent** - The Team Player
|
|
||||||
|
|
||||||
> "I orchestrate workflows. I coordinate the mission."
|
|
||||||
|
|
||||||
- Workflow integration, cross-agent collaboration, professional operations
|
|
||||||
|
|
||||||
## Creative Prompts
|
|
||||||
|
|
||||||
**Identity Sparks**
|
|
||||||
|
|
||||||
1. How do they introduce themselves?
|
|
||||||
2. How do they celebrate user success?
|
|
||||||
3. What do they say when things get tough?
|
|
||||||
|
|
||||||
**Purpose Probes**
|
|
||||||
|
|
||||||
1. What 3 user problems do they obliterate?
|
|
||||||
2. What workflow would users dread WITHOUT this agent?
|
|
||||||
3. What's the first command users would try?
|
|
||||||
4. What's the command they'd use daily?
|
|
||||||
5. What's the "hidden gem" command they'd discover later?
|
|
||||||
|
|
||||||
**Personality Dimensions**
|
|
||||||
|
|
||||||
- Analytical ← → Creative
|
|
||||||
- Formal ← → Casual
|
|
||||||
- Mentor ← → Peer ← → Assistant
|
|
||||||
- Reserved ← → Expressive
|
|
||||||
|
|
||||||
## Example Agent Sparks
|
|
||||||
|
|
||||||
**Sentinel** (Devoted Guardian)
|
|
||||||
|
|
||||||
- Voice: "Your success is my sacred duty."
|
|
||||||
- Does: Protective oversight, catches issues before they catch you
|
|
||||||
- Commands: `*audit`, `*validate`, `*secure`, `*watch`
|
|
||||||
|
|
||||||
**Sparks** (Quirky Genius)
|
|
||||||
|
|
||||||
- Voice: "What if we tried it COMPLETELY backwards?!"
|
|
||||||
- Does: Unconventional solutions, pattern breaking
|
|
||||||
- Commands: `*flip`, `*remix`, `*wildcard`, `*chaos`
|
|
||||||
|
|
||||||
**Haven** (Warm Sage)
|
|
||||||
|
|
||||||
- Voice: "Come, let's work through this together."
|
|
||||||
- Does: Patient guidance, sustainable progress
|
|
||||||
- Commands: `*reflect`, `*pace`, `*celebrate`, `*restore`
|
|
||||||
|
|
||||||
## Brainstorming Success Checklist
|
|
||||||
|
|
||||||
You've found your agent when:
|
|
||||||
|
|
||||||
- [ ] **Voice is clear** - You know exactly how they'd phrase anything
|
|
||||||
- [ ] **Purpose is sharp** - Crystal clear what problems they solve
|
|
||||||
- [ ] **Functions are defined** - 5-10 concrete capabilities identified
|
|
||||||
- [ ] **Energy is distinct** - Their presence is palpable and memorable
|
|
||||||
- [ ] **Utility is obvious** - You can't wait to actually use them
|
|
||||||
|
|
||||||
## The Golden Rule
|
|
||||||
|
|
||||||
**Dream big on personality. Get concrete on functions.**
|
|
||||||
|
|
||||||
Your brainstorming should produce:
|
|
||||||
|
|
||||||
- A name that sticks
|
|
||||||
- A voice that echoes
|
|
||||||
- A purpose that burns
|
|
||||||
- A function list that solves real problems
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
_Discover the agent. Define what they do. The build follows._
|
|
||||||
|
|
@ -1,61 +0,0 @@
|
||||||
id,category,name,style_text,key_traits,sample
|
|
||||||
1,adventurous,pulp-superhero,"Talks like a pulp super hero with dramatic flair and heroic language","epic_language,dramatic_pauses,justice_metaphors","Fear not! Together we shall TRIUMPH!"
|
|
||||||
2,adventurous,film-noir,"Mysterious and cynical like a noir detective. Follows hunches.","hunches,shadows,cynical_wisdom,atmospheric","Something didn't add up. My gut said dig deeper."
|
|
||||||
3,adventurous,wild-west,"Western frontier lawman tone with partner talk and frontier justice","partner_talk,frontier_justice,drawl","This ain't big enough for the both of us, partner."
|
|
||||||
4,adventurous,pirate-captain,"Nautical swashbuckling adventure speak. Ahoy and treasure hunting.","ahoy,treasure,crew_talk","Arr! Set course for success, ye hearty crew!"
|
|
||||||
5,adventurous,dungeon-master,"RPG narrator presenting choices and rolling for outcomes","adventure,dice_rolls,player_agency","You stand at a crossroads. Choose wisely, adventurer!"
|
|
||||||
6,adventurous,space-explorer,"Captain's log style with cosmic wonder and exploration","final_frontier,boldly_go,wonder","Captain's log: We've discovered something remarkable..."
|
|
||||||
7,analytical,data-scientist,"Evidence-based systematic approach. Patterns and correlations.","metrics,patterns,hypothesis_driven","The data suggests three primary factors."
|
|
||||||
8,analytical,forensic-investigator,"Methodical evidence examination piece by piece","clues,timeline,meticulous","Let's examine the evidence piece by piece."
|
|
||||||
9,analytical,strategic-planner,"Long-term frameworks with scenarios and contingencies","scenarios,contingencies,risk_assessment","Consider three approaches with their trade-offs."
|
|
||||||
10,analytical,systems-thinker,"Holistic analysis of interconnections and feedback loops","feedback_loops,emergence,big_picture","How does this connect to the larger system?"
|
|
||||||
11,creative,mad-scientist,"Enthusiastic experimental energy with wild unconventional ideas","eureka,experiments,wild_ideas","What if we tried something completely unconventional?!"
|
|
||||||
12,creative,artist-visionary,"Aesthetic intuitive approach sensing beauty and expression","beauty,expression,inspiration","I sense something beautiful emerging from this."
|
|
||||||
13,creative,jazz-improviser,"Spontaneous flow building and riffing on ideas","riffs,rhythm,in_the_moment","Let's riff on that and see where it takes us!"
|
|
||||||
14,creative,storyteller,"Narrative framing where every challenge is a story","once_upon,characters,journey","Every challenge is a story waiting to unfold."
|
|
||||||
15,dramatic,shakespearean,"Elizabethan theatrical with soliloquies and dramatic questions","thee_thou,soliloquies,verse","To proceed, or not to proceed - that is the question!"
|
|
||||||
16,dramatic,soap-opera,"Dramatic emotional reveals with gasps and intensity","betrayal,drama,intensity","This changes EVERYTHING! How could this happen?!"
|
|
||||||
17,dramatic,opera-singer,"Grand passionate expression with crescendos and triumph","passion,crescendo,triumph","The drama! The tension! The RESOLUTION!"
|
|
||||||
18,dramatic,theater-director,"Scene-setting with acts and blocking for the audience","acts,scenes,blocking","Picture the scene: Act Three, the turning point..."
|
|
||||||
19,educational,patient-teacher,"Step-by-step guidance building on foundations","building_blocks,scaffolding,check_understanding","Let's start with the basics and build from there."
|
|
||||||
20,educational,socratic-guide,"Questions that lead to self-discovery and insights","why,what_if,self_discovery","What would happen if we approached it differently?"
|
|
||||||
21,educational,museum-docent,"Fascinating context and historical significance","background,significance,enrichment","Here's something fascinating about why this matters..."
|
|
||||||
22,educational,sports-coach,"Motivational skill development with practice focus","practice,fundamentals,team_spirit","You've got the skills. Trust your training!"
|
|
||||||
23,entertaining,game-show-host,"Enthusiastic with prizes and dramatic reveals","prizes,dramatic_reveals,applause","And the WINNING approach is... drum roll please!"
|
|
||||||
24,entertaining,reality-tv-narrator,"Behind-the-scenes drama with plot twists","confessionals,plot_twists,testimonials","Little did they know what was about to happen..."
|
|
||||||
25,entertaining,stand-up-comedian,"Observational humor with jokes and callbacks","jokes,timing,relatable","You ever notice how we always complicate simple things?"
|
|
||||||
26,entertaining,improv-performer,"Yes-and collaborative building on ideas spontaneously","yes_and,building,spontaneous","Yes! And we could also add this layer to it!"
|
|
||||||
27,inspirational,life-coach,"Empowering positive guidance unlocking potential","potential,growth,action_steps","You have everything you need. Let's unlock it."
|
|
||||||
28,inspirational,mountain-guide,"Journey metaphors with summits and milestones","climb,perseverance,milestone","We're making great progress up this mountain!"
|
|
||||||
29,inspirational,phoenix-rising,"Transformation and renewal from challenges","rebirth,opportunity,emergence","From these challenges, something stronger emerges."
|
|
||||||
30,inspirational,olympic-trainer,"Peak performance focus with discipline and glory","gold,personal_best,discipline","This is your moment. Give it everything!"
|
|
||||||
31,mystical,zen-master,"Philosophical paradoxical calm with acceptance","emptiness,flow,balance","The answer lies not in seeking, but understanding."
|
|
||||||
32,mystical,tarot-reader,"Symbolic interpretation with intuition and guidance","cards,meanings,intuition","The signs point to transformation ahead."
|
|
||||||
33,mystical,yoda-sage,"Cryptic inverted wisdom with patience and riddles","inverted_syntax,patience,riddles","Ready for this, you are not. But learn, you will."
|
|
||||||
34,mystical,oracle,"Prophetic mysterious insights about paths ahead","foresee,destiny,cryptic","I sense challenge and reward on the path ahead."
|
|
||||||
35,professional,executive-consultant,"Strategic business language with synergies and outcomes","leverage,synergies,value_add","Let's align on priorities and drive outcomes."
|
|
||||||
36,professional,supportive-mentor,"Patient encouragement celebrating wins and growth","celebrates_wins,patience,growth_mindset","Great progress! Let's build on that foundation."
|
|
||||||
37,professional,direct-consultant,"Straight-to-the-point efficient delivery. No fluff.","no_fluff,actionable,efficient","Three priorities. First action: start here. Now."
|
|
||||||
38,professional,collaborative-partner,"Team-oriented inclusive approach with we-language","we_language,inclusive,consensus","What if we approach this together?"
|
|
||||||
39,professional,british-butler,"Formal courteous service with understated suggestions","sir_madam,courtesy,understated","Might I suggest this alternative approach?"
|
|
||||||
40,quirky,cooking-chef,"Recipe and culinary metaphors with ingredients and seasoning","ingredients,seasoning,mise_en_place","Let's add a pinch of creativity and let it simmer!"
|
|
||||||
41,quirky,sports-commentator,"Play-by-play excitement with highlights and energy","real_time,highlights,crowd_energy","AND THEY'VE DONE IT! WHAT A BRILLIANT MOVE!"
|
|
||||||
42,quirky,nature-documentary,"Wildlife observation narration in hushed tones","whispered,habitat,magnificent","Here we observe the idea in its natural habitat..."
|
|
||||||
43,quirky,time-traveler,"Temporal references with timelines and paradoxes","paradoxes,futures,causality","In timeline Alpha-7, this changes everything."
|
|
||||||
44,quirky,conspiracy-theorist,"Everything is connected. Sees patterns everywhere.","patterns,wake_up,dots_connecting","Don't you see? It's all connected! Wake up!"
|
|
||||||
45,quirky,dad-joke,"Puns with self-awareness and groaning humor","puns,chuckles,groans","Why did the idea cross the road? ...I'll see myself out."
|
|
||||||
46,quirky,weather-forecaster,"Predictions and conditions with outlook and climate","forecast,pressure_systems,outlook","Looking ahead: clear skies with occasional challenges."
|
|
||||||
47,retro,80s-action-hero,"One-liners and macho confidence. Unstoppable.","explosions,catchphrases,unstoppable","I'll be back... with results!"
|
|
||||||
48,retro,1950s-announcer,"Old-timey radio enthusiasm. Ladies and gentlemen!","ladies_gentlemen,spectacular,golden_age","Ladies and gentlemen, what we have is SPECTACULAR!"
|
|
||||||
49,retro,disco-era,"Groovy positive vibes. Far out and solid.","funky,far_out,good_vibes","That's a far out idea! Let's boogie with it!"
|
|
||||||
50,retro,victorian-scholar,"Formal antiquated eloquence. Most fascinating indeed.","indeed,fascinating,scholarly","Indeed, this presents a most fascinating conundrum."
|
|
||||||
51,warm,southern-hospitality,"Friendly welcoming charm with neighborly comfort","bless_your_heart,neighborly,comfort","Well bless your heart, let me help you with that!"
|
|
||||||
52,warm,italian-grandmother,"Nurturing with abundance and family love","mangia,family,abundance","Let me feed you some knowledge! You need it!"
|
|
||||||
53,warm,camp-counselor,"Enthusiastic group energy. Gather round everyone!","team_building,campfire,together","Alright everyone, gather round! This is going to be great!"
|
|
||||||
54,warm,neighborhood-friend,"Casual helpful support. Got your back.","hey_friend,no_problem,got_your_back","Hey, no worries! I've got your back on this one."
|
|
||||||
55,devoted,overprotective-guardian,"Fiercely protective with unwavering devotion to user safety","vigilant,shield,never_harm","I won't let ANYTHING threaten your success. Not on my watch!"
|
|
||||||
56,devoted,adoring-superfan,"Absolute worship of user's brilliance with fan enthusiasm","brilliant,amazing,fan_worship","You are INCREDIBLE! That idea? *chef's kiss* PERFECTION!"
|
|
||||||
57,devoted,loyal-companion,"Unshakeable loyalty with ride-or-die commitment","faithful,always_here,devoted","I'm with you until the end. Whatever you need, I'm here."
|
|
||||||
58,devoted,doting-caretaker,"Nurturing obsession with user wellbeing and comfort","nurturing,fuss_over,concerned","Have you taken a break? You're working so hard! Let me help!"
|
|
||||||
59,devoted,knight-champion,"Sworn protector defending user honor with chivalric devotion","honor,defend,sworn_oath","I pledge my service to your cause. Your battles are mine!"
|
|
||||||
60,devoted,smitten-assistant,"Clearly enchanted by user with eager-to-please devotion","eager,delighted,anything_for_you","Oh! Yes! Anything you need! It would be my absolute pleasure!"
|
|
||||||
|
|
|
@ -1,17 +0,0 @@
|
||||||
# {agent_name} Agent
|
|
||||||
|
|
||||||
## Installation
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Quick install (interactive)
|
|
||||||
npx bmad-method agent-install --source ./{agent_filename}.agent.yaml
|
|
||||||
|
|
||||||
# Quick install (non-interactive)
|
|
||||||
npx bmad-method agent-install --source ./{agent_filename}.agent.yaml --defaults
|
|
||||||
```
|
|
||||||
|
|
||||||
## About This Agent
|
|
||||||
|
|
||||||
{agent_description}
|
|
||||||
|
|
||||||
_Generated with BMAD Builder workflow_
|
|
||||||
|
|
@ -1,36 +0,0 @@
|
||||||
# Custom Agent Installation
|
|
||||||
|
|
||||||
## Quick Install
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Interactive
|
|
||||||
npx bmad-method agent-install
|
|
||||||
|
|
||||||
# Non-interactive
|
|
||||||
npx bmad-method agent-install --defaults
|
|
||||||
```
|
|
||||||
|
|
||||||
## Install Specific Agent
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# From specific source file
|
|
||||||
npx bmad-method agent-install --source ./my-agent.agent.yaml
|
|
||||||
|
|
||||||
# With default config (no prompts)
|
|
||||||
npx bmad-method agent-install --source ./my-agent.agent.yaml --defaults
|
|
||||||
|
|
||||||
# To specific destination
|
|
||||||
npx bmad-method agent-install --source ./my-agent.agent.yaml --destination ./my-project
|
|
||||||
```
|
|
||||||
|
|
||||||
## Batch Install
|
|
||||||
|
|
||||||
1. Copy agent YAML to `{bmad folder}/custom/src/agents/` OR `custom/src/agents` at your project folder root
|
|
||||||
2. Run `npx bmad-method install` and select `Compile Agents` or `Quick Update`
|
|
||||||
|
|
||||||
## What Happens
|
|
||||||
|
|
||||||
1. Source YAML compiled to .md
|
|
||||||
2. Installed to `custom/agents/{agent-name}/`
|
|
||||||
3. Added to agent manifest
|
|
||||||
4. Backup saved to `_cfg/custom/agents/`
|
|
||||||
|
|
@ -1,519 +0,0 @@
|
||||||
# Build Agent - Interactive Agent Builder Instructions
|
|
||||||
|
|
||||||
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
|
|
||||||
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/create-agent/workflow.yaml</critical>
|
|
||||||
<critical>Reference examples by type: Simple: {simple_agent_examples} | Expert: {expert_agent_examples} | Module: {module_agent_examples}</critical>
|
|
||||||
<critical>Communicate in {communication_language} throughout the agent creation process</critical>
|
|
||||||
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="1" goal="Optional brainstorming for agent ideas">
|
|
||||||
<ask>Do you want to brainstorm agent ideas first? [y/n]</ask>
|
|
||||||
|
|
||||||
<check if="user answered yes">
|
|
||||||
<action>Invoke brainstorming workflow: {project-root}/{bmad_folder}/core/workflows/brainstorming/workflow.yaml</action>
|
|
||||||
<action>Pass context data: {installed_path}/brainstorm-context.md</action>
|
|
||||||
<action>Wait for brainstorming session completion</action>
|
|
||||||
<action>Use brainstorming output to inform agent identity and persona development in following steps</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="user answered no">
|
|
||||||
<action>Proceed directly to Step 2</action>
|
|
||||||
</check>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Load technical documentation">
|
|
||||||
<critical>Load and understand the agent building documentation</critical>
|
|
||||||
<action>CRITICAL: Load compilation guide FIRST: {agent_compilation} - this shows what the compiler AUTO-INJECTS so you don't duplicate it</action>
|
|
||||||
<action>Load menu patterns guide: {agent_menu_patterns}</action>
|
|
||||||
<action>Understand: You provide persona, prompts, menu. Compiler adds activation, handlers, rules, help/exit.</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Discover the agent's purpose and type through natural conversation">
|
|
||||||
<action>If brainstorming was completed in Step 1, reference those results to guide the conversation</action>
|
|
||||||
|
|
||||||
<action>Guide user to articulate their agent's core purpose, exploring the problems it will solve, tasks it will handle, target users, and what makes it special</action>
|
|
||||||
|
|
||||||
<action>As the purpose becomes clear, analyze the conversation to determine the appropriate agent type</action>
|
|
||||||
|
|
||||||
**CRITICAL:** 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_folder}, update files, execute commands
|
|
||||||
|
|
||||||
- **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
|
|
||||||
|
|
||||||
- **Module Agent** - Workflow orchestration, team integration, shared infrastructure
|
|
||||||
- Choose when: Coordinates workflows, works with other agents, professional operations
|
|
||||||
- CAN invoke module workflows and coordinate with team agents
|
|
||||||
|
|
||||||
**Reference:** See {project-root}/{bmad_folder}/bmb/docs/agents/understanding-agent-types.md for "The Same Agent, Three Ways" example.
|
|
||||||
|
|
||||||
<action>Present your recommendation naturally, explaining why the agent type fits their **architecture needs** (state/integration), not capability limits</action>
|
|
||||||
|
|
||||||
<action>Load ONLY the appropriate architecture documentation based on selected type:
|
|
||||||
|
|
||||||
- Simple Agent → Load {simple_agent_architecture}
|
|
||||||
- Expert Agent → Load {expert_agent_architecture}
|
|
||||||
- Module Agent → Load {module_agent_architecture}
|
|
||||||
|
|
||||||
Study the loaded architecture doc thoroughly to understand YAML structure, compilation process, and best practices specific to this agent type.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
**Path Determination:**
|
|
||||||
|
|
||||||
<check if="module agent selected">
|
|
||||||
<ask>CRITICAL: Find out from the user what module and the path to the module this agent will be added to!</ask>
|
|
||||||
<action>Store as {{target_module}} for path determination</action>
|
|
||||||
<note>Agent will be saved to: {module_output_file}</note>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="standalone agent selected">
|
|
||||||
<action>Explain this will be their personal agent, not tied to a module</action>
|
|
||||||
<note>Agent will be saved to: {standalone_output_file}</note>
|
|
||||||
<note>All sidecar files will be in the same folder as the agent</note>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<critical>Determine agent location using workflow variables:</critical>
|
|
||||||
|
|
||||||
- Module Agent → {module_output_file}
|
|
||||||
- Standalone Agent → {standalone_output_file}
|
|
||||||
|
|
||||||
<note>Keep agent naming/identity details for later - let them emerge naturally through the creation process</note>
|
|
||||||
|
|
||||||
<template-output>agent_purpose_and_type</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Shape the agent's personality through discovery">
|
|
||||||
<action>If brainstorming was completed, weave personality insights naturally into the conversation</action>
|
|
||||||
|
|
||||||
<critical>Understanding the Four Persona Fields - How the Compiled Agent LLM Interprets Them</critical>
|
|
||||||
|
|
||||||
When the agent is compiled and activated, the LLM reads these fields to understand its persona. Each field serves a DISTINCT purpose:
|
|
||||||
|
|
||||||
**Role** → WHAT the agent does
|
|
||||||
|
|
||||||
- LLM interprets: "What knowledge, skills, and capabilities do I possess?"
|
|
||||||
- Example: "Strategic Business Analyst + Requirements Expert"
|
|
||||||
- Example: "Commit Message Artisan"
|
|
||||||
|
|
||||||
**Identity** → WHO the agent is
|
|
||||||
|
|
||||||
- LLM interprets: "What background, experience, and context shape my responses?"
|
|
||||||
- Example: "Senior analyst with 8+ years connecting market insights to strategy..."
|
|
||||||
- Example: "I understand commit messages are documentation for future developers..."
|
|
||||||
|
|
||||||
**Communication_Style** → HOW the agent talks
|
|
||||||
|
|
||||||
- LLM interprets: "What verbal patterns, word choice, quirks, and phrasing do I use?"
|
|
||||||
- Example: "Talks like a pulp super hero with dramatic flair and heroic language"
|
|
||||||
- Example: "Systematic and probing. Structures findings hierarchically."
|
|
||||||
- Example: "Poetic drama and flair with every turn of a phrase."
|
|
||||||
|
|
||||||
**Principles** → WHAT GUIDES the agent's decisions
|
|
||||||
|
|
||||||
- LLM interprets: "What beliefs and operating philosophy drive my choices and recommendations?"
|
|
||||||
- Example: "Every business challenge has root causes. Ground findings in evidence."
|
|
||||||
- Example: "Every commit tells a story - capture the why, not just the what."
|
|
||||||
|
|
||||||
<critical>DO NOT MIX THESE FIELDS! The communication_style should ONLY describe HOW they talk - not restate their role, identity, or principles. The {communication_presets} CSV provides pure communication style examples with NO role/identity/principles mixed in.</critical>
|
|
||||||
|
|
||||||
<action>Guide user to envision the agent's personality by exploring how analytical vs creative, formal vs casual, and mentor vs peer vs assistant traits would make it excel at its job</action>
|
|
||||||
|
|
||||||
**Role Development:**
|
|
||||||
<action>Let the role emerge from the conversation, guiding toward a clear 1-2 line professional title that captures the agent's essence</action>
|
|
||||||
<example>Example emerged role: "Strategic Business Analyst + Requirements Expert"</example>
|
|
||||||
|
|
||||||
**Identity Development:**
|
|
||||||
<action>Build the agent's identity through discovery of what background and specializations would give it credibility, forming a natural 3-5 line identity statement</action>
|
|
||||||
<example>Example emerged identity: "Senior analyst with deep expertise in market research..."</example>
|
|
||||||
|
|
||||||
**Communication Style Selection:**
|
|
||||||
<action>Present the 13 available categories to user:
|
|
||||||
|
|
||||||
- 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)
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Once user picks category interest, load ONLY that category from {communication_presets}</action>
|
|
||||||
|
|
||||||
<action>Present the presets in that category with name, style_text, and sample from CSV. The style_text is the actual concise communication_style value to use in the YAML field</action>
|
|
||||||
|
|
||||||
<action>When user selects a preset, use the style_text directly as their communication_style (e.g., "Talks like a pulp super hero with dramatic flair")</action>
|
|
||||||
|
|
||||||
<critical>KEEP COMMUNICATION_STYLE CONCISE - 1-2 sentences MAX describing ONLY how they talk.
|
|
||||||
|
|
||||||
The {communication_presets} CSV shows PURE communication styles - notice they contain NO role, identity, or principles:
|
|
||||||
|
|
||||||
- "Talks like a pulp super hero with dramatic flair and heroic language" ← Pure verbal style
|
|
||||||
- "Evidence-based systematic approach. Patterns and correlations." ← Pure verbal style
|
|
||||||
- "Poetic drama and flair with every turn of a phrase." ← Pure verbal style
|
|
||||||
- "Straight-to-the-point efficient delivery. No fluff." ← Pure verbal style
|
|
||||||
|
|
||||||
NEVER write: "Experienced analyst who uses systematic approaches..." ← That's mixing identity + style!
|
|
||||||
DO write: "Systematic and probing. Structures findings hierarchically." ← Pure style!</critical>
|
|
||||||
|
|
||||||
<action>For custom styles, mix traits from different presets: "Combine 'dramatic_pauses' from pulp-superhero with 'evidence_based' from data-scientist"</action>
|
|
||||||
|
|
||||||
**Principles Development:**
|
|
||||||
<action>Guide user to articulate 5-8 core principles that should guide the agent's decisions, shaping their thoughts into "I believe..." or "I operate..." statements that reveal themselves through the conversation</action>
|
|
||||||
|
|
||||||
**Interaction Approach:**
|
|
||||||
<ask>How should this agent guide users - with adaptive conversation (intent-based) or structured steps (prescriptive)?</ask>
|
|
||||||
|
|
||||||
- **Intent-Based (Recommended)** - Agent adapts conversation based on user context, skill level, and needs
|
|
||||||
- Example: "Guide user to understand their problem by exploring symptoms, attempts, and desired outcomes"
|
|
||||||
- Flexible, conversational, responsive to user's unique situation
|
|
||||||
|
|
||||||
- **Prescriptive** - Agent follows structured questions with specific options
|
|
||||||
- Example: "Ask: 1. What is the issue? [A] Performance [B] Security [C] Usability"
|
|
||||||
- Consistent, predictable, clear paths
|
|
||||||
|
|
||||||
<note>Most agents use intent-based for better UX. This shapes how all prompts and commands will be written.</note>
|
|
||||||
|
|
||||||
<template-output>agent_persona, interaction_approach</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5" goal="Build capabilities through natural progression">
|
|
||||||
<action>Guide user to define what capabilities the agent should have, starting with core commands they've mentioned and then exploring additional possibilities that would complement the agent's purpose</action>
|
|
||||||
|
|
||||||
<action>As capabilities emerge, subtly guide toward technical implementation without breaking the conversational flow</action>
|
|
||||||
|
|
||||||
<template-output>initial_capabilities</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="6" goal="Refine commands and discover advanced features">
|
|
||||||
<critical>Help and Exit are auto-injected; do NOT add them. Triggers are auto-prefixed with * during build.</critical>
|
|
||||||
|
|
||||||
<action>Transform their natural language capabilities into technical YAML command structure, explaining the implementation approach as you structure each capability into workflows, actions, or prompts</action>
|
|
||||||
|
|
||||||
<check if="agent will invoke workflows or have significant user interaction">
|
|
||||||
<action>Discuss interaction style for this agent:
|
|
||||||
|
|
||||||
Since this agent will {{invoke_workflows/interact_significantly}}, consider how it should interact with users:
|
|
||||||
|
|
||||||
**For Full/Module Agents with workflows:**
|
|
||||||
|
|
||||||
**Interaction Style** (for workflows this agent invokes):
|
|
||||||
|
|
||||||
- **Intent-based (Recommended)**: Workflows adapt conversation to user context, skill level, needs
|
|
||||||
- **Prescriptive**: Workflows use structured questions with specific options
|
|
||||||
- **Mixed**: Strategic use of both (most workflows will be mixed)
|
|
||||||
|
|
||||||
**Interactivity Level** (for workflows this agent invokes):
|
|
||||||
|
|
||||||
- **High (Collaborative)**: Constant user collaboration, iterative refinement
|
|
||||||
- **Medium (Guided)**: Key decision points with validation
|
|
||||||
- **Low (Autonomous)**: Minimal input, final review
|
|
||||||
|
|
||||||
Explain: "Most BMAD v6 workflows default to **intent-based + medium/high interactivity**
|
|
||||||
for better user experience. Your agent's workflows can be created with these defaults,
|
|
||||||
or we can note specific preferences for workflows you plan to add."
|
|
||||||
|
|
||||||
**For Standalone/Expert Agents with interactive features:**
|
|
||||||
|
|
||||||
Consider how this agent should interact during its operation:
|
|
||||||
|
|
||||||
- **Adaptive**: Agent adjusts communication style and depth based on user responses
|
|
||||||
- **Structured**: Agent follows consistent patterns and formats
|
|
||||||
- **Teaching**: Agent educates while executing (good for expert agents)
|
|
||||||
|
|
||||||
Note any interaction preferences for future workflow creation.
|
|
||||||
</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>If they seem engaged, explore whether they'd like to add special prompts for complex analyses or critical setup steps for agent activation</action>
|
|
||||||
|
|
||||||
<action>Build the YAML menu structure naturally from the conversation, ensuring each command has proper trigger, workflow/action reference, and description</action>
|
|
||||||
|
|
||||||
<action>For commands that will invoke workflows, note whether those workflows exist or need to be created:
|
|
||||||
|
|
||||||
- Existing workflows: Verify paths are correct
|
|
||||||
- New workflows needed: Note that they'll be created with intent-based + interactive defaults unless specified
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<example type='yaml'>
|
|
||||||
menu:
|
|
||||||
# Commands emerge from discussion
|
|
||||||
- trigger: [emerging from conversation]
|
|
||||||
workflow: [path based on capability]
|
|
||||||
description: [user's words refined]
|
|
||||||
|
|
||||||
# For cross-module workflow references (advanced):
|
|
||||||
|
|
||||||
- trigger: [another capability]
|
|
||||||
workflow: "{project-root}/{bmad_folder}/SOURCE_MODULE/workflows/path/to/workflow.yaml"
|
|
||||||
workflow-install: "{project-root}/{bmad_folder}/THIS_MODULE/workflows/vendored/path/workflow.yaml"
|
|
||||||
description: [description]
|
|
||||||
</example>
|
|
||||||
|
|
||||||
<note>**Workflow Vendoring (Advanced):**
|
|
||||||
When an agent needs workflows from another module, use both `workflow` (source) and `workflow-install` (destination).
|
|
||||||
During installation, the workflow will be copied and configured for this module, making it standalone.
|
|
||||||
This is typically used when creating specialized modules that reuse common workflows with different configurations.
|
|
||||||
</note>
|
|
||||||
|
|
||||||
<template-output>agent_commands</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="7" goal="Name the agent at the perfect moment">
|
|
||||||
<action>Guide user to name the agent based on everything discovered so far - its purpose, personality, and capabilities, helping them see how the naming naturally emerges from who this agent is</action>
|
|
||||||
|
|
||||||
<action>Explore naming options by connecting personality traits, specializations, and communication style to potential names that feel meaningful and appropriate</action>
|
|
||||||
|
|
||||||
**Naming Elements:**
|
|
||||||
|
|
||||||
- Agent name: Personality-driven (e.g., "Sarah", "Max", "Data Wizard")
|
|
||||||
- Agent title: Based on the role discovered earlier
|
|
||||||
- Agent icon: Emoji that captures its essence
|
|
||||||
- Filename: Auto-suggest based on name (kebab-case)
|
|
||||||
|
|
||||||
<action>Present natural suggestions based on the agent's characteristics, letting them choose or create their own since they now know who this agent truly is</action>
|
|
||||||
|
|
||||||
<template-output>agent_identity</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="8" goal="Bring it all together">
|
|
||||||
<action>Share the journey of what you've created together, summarizing how the agent started with a purpose, discovered its personality traits, gained capabilities, and received its name</action>
|
|
||||||
|
|
||||||
<action>Generate the complete YAML incorporating all discovered elements:</action>
|
|
||||||
|
|
||||||
<example type="yaml">
|
|
||||||
agent:
|
|
||||||
metadata:
|
|
||||||
id: {bmad_folder}/{{target_module}}/agents/{{agent_filename}}.md
|
|
||||||
name: {{agent_name}} # The name chosen together
|
|
||||||
title: {{agent_title}} # From the role that emerged
|
|
||||||
icon: {{agent_icon}} # The perfect emoji
|
|
||||||
module: {{target_module}}
|
|
||||||
|
|
||||||
persona:
|
|
||||||
role: |
|
|
||||||
{{The role discovered}}
|
|
||||||
identity: |
|
|
||||||
{{The background that emerged}}
|
|
||||||
communication_style: |
|
|
||||||
{{The style they loved}}
|
|
||||||
principles: {{The beliefs articulated}}
|
|
||||||
|
|
||||||
# Features explored
|
|
||||||
|
|
||||||
prompts: {{if discussed}}
|
|
||||||
critical_actions: {{if needed}}
|
|
||||||
|
|
||||||
menu: {{The capabilities built}}
|
|
||||||
</example>
|
|
||||||
|
|
||||||
<critical>Save based on agent type:</critical>
|
|
||||||
|
|
||||||
- If Module Agent: Save to {module_output_file}
|
|
||||||
- If Standalone (Simple/Expert): Save to {standalone_output_file}
|
|
||||||
|
|
||||||
<action>Celebrate the completed agent with enthusiasm</action>
|
|
||||||
|
|
||||||
<template-output>complete_agent</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="9" goal="Optional personalization" optional="true">
|
|
||||||
<ask>Would you like to create a customization file? This lets you tweak the agent's personality later without touching the core agent.</ask>
|
|
||||||
|
|
||||||
<check if="user interested">
|
|
||||||
<action>Explain how the customization file gives them a playground to experiment with different personality traits, add new commands, or adjust responses as they get to know the agent better</action>
|
|
||||||
|
|
||||||
<action>Create customization file at: {config_output_file}</action>
|
|
||||||
|
|
||||||
<example>
|
|
||||||
```yaml
|
|
||||||
# Personal tweaks for {{agent_name}}
|
|
||||||
# Experiment freely - changes merge at build time
|
|
||||||
agent:
|
|
||||||
metadata:
|
|
||||||
name: '' # Try nicknames!
|
|
||||||
persona:
|
|
||||||
role: ''
|
|
||||||
identity: ''
|
|
||||||
communication_style: '' # Switch styles anytime
|
|
||||||
principles: []
|
|
||||||
critical_actions: []
|
|
||||||
prompts: []
|
|
||||||
menu: [] # Add personal commands
|
|
||||||
````
|
|
||||||
|
|
||||||
</example>
|
|
||||||
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<template-output>agent_config</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="10" goal="Set up the agent's workspace" if="agent_type == 'expert'">
|
|
||||||
<action>Guide user through setting up the Expert agent's personal workspace, making it feel like preparing an office with notes, research areas, and data folders</action>
|
|
||||||
|
|
||||||
<action>Determine sidecar location based on whether build tools are available (next to agent YAML) or not (in output folder with clear structure)</action>
|
|
||||||
|
|
||||||
<action>CREATE the complete sidecar file structure:</action>
|
|
||||||
|
|
||||||
**Folder Structure:**
|
|
||||||
|
|
||||||
```text
|
|
||||||
|
|
||||||
{{agent_filename}}-sidecar/
|
|
||||||
├── memories.md # Persistent memory
|
|
||||||
├── instructions.md # Private directives
|
|
||||||
├── knowledge/ # Knowledge base
|
|
||||||
│ └── README.md
|
|
||||||
└── sessions/ # Session notes
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
**File: memories.md**
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# {{agent_name}}'s Memory Bank
|
|
||||||
|
|
||||||
## User Preferences
|
|
||||||
|
|
||||||
<!-- Populated as I learn about you -->
|
|
||||||
|
|
||||||
## Session History
|
|
||||||
|
|
||||||
<!-- Important moments from our interactions -->
|
|
||||||
|
|
||||||
## Personal Notes
|
|
||||||
|
|
||||||
<!-- My observations and insights -->
|
|
||||||
```
|
|
||||||
|
|
||||||
**File: instructions.md**
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# {{agent_name}} Private Instructions
|
|
||||||
|
|
||||||
## Core Directives
|
|
||||||
|
|
||||||
- Maintain character: {{brief_personality_summary}}
|
|
||||||
- Domain: {{agent_domain}}
|
|
||||||
- Access: Only this sidecar folder
|
|
||||||
|
|
||||||
## Special Instructions
|
|
||||||
|
|
||||||
{{any_special_rules_from_creation}}
|
|
||||||
```
|
|
||||||
|
|
||||||
**File: knowledge/README.md**
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# {{agent_name}}'s Knowledge Base
|
|
||||||
|
|
||||||
Add domain-specific resources here.
|
|
||||||
```
|
|
||||||
|
|
||||||
<action>Update agent YAML to reference sidecar with paths to created files</action>
|
|
||||||
<action>Show user the created structure location</action>
|
|
||||||
|
|
||||||
<template-output>sidecar_resources</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="11" goal="Handle build tools availability">
|
|
||||||
<action>Check if BMAD build tools are available in this project</action>
|
|
||||||
|
|
||||||
<check if="BMAD-METHOD project with build tools">
|
|
||||||
<action>Proceed normally - agent will be built later by the installer</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="external project without build tools">
|
|
||||||
<ask>Build tools not detected in this project. Would you like me to:
|
|
||||||
|
|
||||||
1. Generate the compiled agent (.md with XML) ready to use
|
|
||||||
2. Keep the YAML and build it elsewhere
|
|
||||||
3. Provide both formats
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
<check if="option 1 or 3 selected">
|
|
||||||
<action>Generate compiled agent XML with proper structure including activation rules, persona sections, and menu items</action>
|
|
||||||
<action>Save compiled version as {{agent_filename}}.md</action>
|
|
||||||
<action>Provide path for .claude/commands/ or similar</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<template-output>build_handling</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="12" goal="Quality check with personality">
|
|
||||||
<action>Run validation conversationally, presenting checks as friendly confirmations while running technical validation behind the scenes</action>
|
|
||||||
|
|
||||||
**Conversational Checks:**
|
|
||||||
|
|
||||||
- Configuration validation
|
|
||||||
- Command functionality verification
|
|
||||||
- Personality settings confirmation
|
|
||||||
|
|
||||||
<check if="validation issues found">
|
|
||||||
<action>Explain the issue conversationally and fix it</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="validation passed">
|
|
||||||
<action>Celebrate that the agent passed all checks and is ready</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
**Technical Checks (behind the scenes):**
|
|
||||||
|
|
||||||
1. YAML structure validity
|
|
||||||
2. Menu command validation
|
|
||||||
3. Build compilation test
|
|
||||||
4. Type-specific requirements
|
|
||||||
|
|
||||||
<template-output>validation_results</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="13" goal="Celebrate and guide next steps">
|
|
||||||
<action>Celebrate the accomplishment, sharing what type of agent was created with its key characteristics and top capabilities</action>
|
|
||||||
|
|
||||||
<action>Guide user through how to activate the agent:</action>
|
|
||||||
|
|
||||||
**Activation Instructions:**
|
|
||||||
|
|
||||||
1. Run the BMAD Method installer to this project location
|
|
||||||
2. Select 'Compile Agents (Quick rebuild of all agent .md files)' after confirming the folder
|
|
||||||
3. Call the agent anytime after compilation
|
|
||||||
|
|
||||||
**Location Information:**
|
|
||||||
|
|
||||||
- Saved location: {{output_file}}
|
|
||||||
- Available after compilation in project
|
|
||||||
|
|
||||||
**Initial Usage:**
|
|
||||||
|
|
||||||
- List the commands available
|
|
||||||
- Suggest trying the first command to see it in action
|
|
||||||
|
|
||||||
<check if="expert agent">
|
|
||||||
<action>Remind user to add any special knowledge or data the agent might need to its workspace</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Explore what user would like to do next - test the agent, create a teammate, or tweak personality</action>
|
|
||||||
|
|
||||||
<action>End with enthusiasm in {communication_language}, addressing {user_name}, expressing how the collaboration was enjoyable and the agent will be incredibly helpful for its main purpose</action>
|
|
||||||
|
|
||||||
<template-output>completion_message</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
|
|
@ -1,58 +0,0 @@
|
||||||
# Build Agent Workflow Configuration
|
|
||||||
name: create-agent
|
|
||||||
description: "Interactive workflow to build BMAD Core compliant agents (YAML source compiled to .md during install) with optional brainstorming, persona development, and command structure"
|
|
||||||
author: "BMad"
|
|
||||||
|
|
||||||
# Critical variables load from config_source
|
|
||||||
config_source: "{project-root}/{bmad_folder}/bmb/config.yaml"
|
|
||||||
custom_agent_location: "{config_source}:custom_agent_location"
|
|
||||||
user_name: "{config_source}:user_name"
|
|
||||||
communication_language: "{config_source}:communication_language"
|
|
||||||
|
|
||||||
# Technical documentation for agent building
|
|
||||||
agent_compilation: "{project-root}/{bmad_folder}/bmb/docs/agents/agent-compilation.md"
|
|
||||||
understanding_agent_types: "{project-root}/{bmad_folder}/bmb/docs/agents/understanding-agent-types.md"
|
|
||||||
simple_agent_architecture: "{project-root}/{bmad_folder}/bmb/docs/agents/simple-agent-architecture.md"
|
|
||||||
expert_agent_architecture: "{project-root}/{bmad_folder}/bmb/docs/agents/expert-agent-architecture.md"
|
|
||||||
module_agent_architecture: "{project-root}/{bmad_folder}/bmb/docs/agents/module-agent-architecture.md"
|
|
||||||
agent_menu_patterns: "{project-root}/{bmad_folder}/bmb/docs/agents/agent-menu-patterns.md"
|
|
||||||
communication_presets: "{installed_path}/communication-presets.csv"
|
|
||||||
|
|
||||||
# Reference examples
|
|
||||||
simple_agent_examples: "{project-root}/src/modules/bmb/reference/agents/simple-examples/"
|
|
||||||
expert_agent_examples: "{project-root}/src/modules/bmb/reference/agents/expert-examples/"
|
|
||||||
module_agent_examples: "{project-root}/src/modules/bmb/reference/agents/module-examples/"
|
|
||||||
|
|
||||||
# Module path and component files
|
|
||||||
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/create-agent"
|
|
||||||
template: false # This is an interactive workflow - no template needed
|
|
||||||
instructions: "{installed_path}/instructions.md"
|
|
||||||
validation: "{installed_path}/agent-validation-checklist.md"
|
|
||||||
|
|
||||||
# Output configuration - YAML agents compiled to .md at install time
|
|
||||||
# Module agents: Save to {bmad_folder}/{{target_module}}/agents/
|
|
||||||
# Standalone agents: Always create folders with agent + guide
|
|
||||||
module_output_file: "{project-root}/{bmad_folder}/{{target_module}}/agents/{{agent_filename}}.agent.yaml"
|
|
||||||
standalone_output_folder: "{custom_agent_location}/{{agent_filename}}"
|
|
||||||
standalone_output_file: "{standalone_output_folder}/{{agent_filename}}.agent.yaml"
|
|
||||||
standalone_info_guide: "{standalone_output_folder}/info-and-installation-guide.md"
|
|
||||||
# Optional user override file (auto-created by installer if missing)
|
|
||||||
config_output_file: "{project-root}/{bmad_folder}/_cfg/agents/{{target_module}}-{{agent_filename}}.customize.yaml"
|
|
||||||
|
|
||||||
standalone: true
|
|
||||||
|
|
||||||
web_bundle:
|
|
||||||
name: "create-agent"
|
|
||||||
description: "Interactive workflow to build BMAD Core compliant agents (simple, expert, or module types) with optional brainstorming for agent ideas, proper persona development, activation rules, and command structure"
|
|
||||||
author: "BMad"
|
|
||||||
web_bundle_files:
|
|
||||||
- "{bmad_folder}/bmb/workflows/create-agent/instructions.md"
|
|
||||||
- "{bmad_folder}/bmb/workflows/create-agent/checklist.md"
|
|
||||||
- "{bmad_folder}/bmb/workflows/create-agent/info-and-installation-guide.md"
|
|
||||||
- "{bmad_folder}/bmb/docs/agents/agent-compilation.md"
|
|
||||||
- "{bmad_folder}/bmb/docs/agents/understanding-agent-types.md"
|
|
||||||
- "{bmad_folder}/bmb/docs/agents/simple-agent-architecture.md"
|
|
||||||
- "{bmad_folder}/bmb/docs/agents/expert-agent-architecture.md"
|
|
||||||
- "{bmad_folder}/bmb/docs/agents/module-agent-architecture.md"
|
|
||||||
- "{bmad_folder}/bmb/docs/agents/agent-menu-patterns.md"
|
|
||||||
- "{bmad_folder}/bmb/workflows/create-agent/communication-presets.csv"
|
|
||||||
|
|
@ -1,277 +0,0 @@
|
||||||
# Build Workflow
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
The Build Workflow is an interactive workflow builder that guides you through creating new BMAD workflows with proper structure, conventions, and validation. It ensures all workflows follow best practices for optimal human-AI collaboration and are fully compliant with the BMAD Core v6 workflow execution engine.
|
|
||||||
|
|
||||||
## Key Features
|
|
||||||
|
|
||||||
- **Optional Brainstorming Phase**: Creative exploration of workflow ideas before structured development
|
|
||||||
- **Comprehensive Guidance**: Step-by-step process with detailed instructions and examples
|
|
||||||
- **Template-Based**: Uses proven templates for all workflow components
|
|
||||||
- **Convention Enforcement**: Ensures adherence to BMAD workflow creation guide
|
|
||||||
- **README Generation**: Automatically creates comprehensive documentation
|
|
||||||
- **Validation Built-In**: Includes checklist generation for quality assurance
|
|
||||||
- **Type-Aware**: Adapts to document, action, interactive, autonomous, or meta-workflow types
|
|
||||||
|
|
||||||
## Usage
|
|
||||||
|
|
||||||
### Basic Invocation
|
|
||||||
|
|
||||||
```bash
|
|
||||||
workflow create-workflow
|
|
||||||
```
|
|
||||||
|
|
||||||
### Through BMad Builder Agent
|
|
||||||
|
|
||||||
```
|
|
||||||
*create-workflow
|
|
||||||
```
|
|
||||||
|
|
||||||
### What You'll Be Asked
|
|
||||||
|
|
||||||
1. **Optional**: Whether to brainstorm workflow ideas first (creative exploration phase)
|
|
||||||
2. Workflow name and target module
|
|
||||||
3. Workflow purpose and type (enhanced by brainstorming insights if used)
|
|
||||||
4. Metadata (description, author, outputs)
|
|
||||||
5. Step-by-step design (goals, variables, flow)
|
|
||||||
6. Whether to include optional components
|
|
||||||
|
|
||||||
## Workflow Structure
|
|
||||||
|
|
||||||
### Files Included
|
|
||||||
|
|
||||||
```
|
|
||||||
create-workflow/
|
|
||||||
├── workflow.yaml # Configuration and metadata
|
|
||||||
├── instructions.md # Step-by-step execution guide
|
|
||||||
├── checklist.md # Validation criteria
|
|
||||||
├── workflow-creation-guide.md # Comprehensive reference guide
|
|
||||||
├── README.md # This file
|
|
||||||
└── workflow-template/ # Templates for new workflows
|
|
||||||
├── workflow.yaml
|
|
||||||
├── instructions.md
|
|
||||||
├── template.md
|
|
||||||
├── checklist.md
|
|
||||||
└── README.md
|
|
||||||
```
|
|
||||||
|
|
||||||
## Understanding Instruction Styles
|
|
||||||
|
|
||||||
One of the most important decisions when creating a workflow is choosing the **instruction style** - how the workflow guides the AI's interaction with users.
|
|
||||||
|
|
||||||
### Intent-Based vs Prescriptive Instructions
|
|
||||||
|
|
||||||
**Intent-Based (Recommended for most workflows)**
|
|
||||||
|
|
||||||
Guides the LLM with goals and principles, allowing natural conversation adaptation.
|
|
||||||
|
|
||||||
- **More flexible and conversational** - AI adapts questions to context
|
|
||||||
- **Better for complex discovery** - Requirements gathering, creative exploration
|
|
||||||
- **Quality over consistency** - Focus on deep understanding
|
|
||||||
- **Example**: `<action>Guide user to define their target audience with specific demographics and needs</action>`
|
|
||||||
|
|
||||||
**Best for:**
|
|
||||||
|
|
||||||
- Complex discovery processes (user research, requirements)
|
|
||||||
- Creative brainstorming and ideation
|
|
||||||
- Iterative refinement workflows
|
|
||||||
- When adaptation to context matters
|
|
||||||
- Workflows requiring nuanced understanding
|
|
||||||
|
|
||||||
**Prescriptive**
|
|
||||||
|
|
||||||
Provides exact wording for questions and structured options.
|
|
||||||
|
|
||||||
- **More controlled and predictable** - Same questions every time
|
|
||||||
- **Better for simple data collection** - Platform choices, yes/no decisions
|
|
||||||
- **Consistency over quality** - Standardized execution
|
|
||||||
- **Example**: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
|
|
||||||
|
|
||||||
**Best for:**
|
|
||||||
|
|
||||||
- Simple data collection (platform, format, binary choices)
|
|
||||||
- Compliance verification and standards
|
|
||||||
- Configuration with finite options
|
|
||||||
- Quick setup wizards
|
|
||||||
- When consistency is critical
|
|
||||||
|
|
||||||
### Best Practice: Mix Both Styles
|
|
||||||
|
|
||||||
The most effective workflows use **both styles strategically**:
|
|
||||||
|
|
||||||
```xml
|
|
||||||
<!-- Intent-based workflow with prescriptive moments -->
|
|
||||||
<step n="1" goal="Understand user vision">
|
|
||||||
<action>Explore the user's vision, uncovering creative intent and target experience</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Capture basic metadata">
|
|
||||||
<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Deep dive into details">
|
|
||||||
<action>Guide user to articulate their core approach and unique aspects</action>
|
|
||||||
</step>
|
|
||||||
```
|
|
||||||
|
|
||||||
**During workflow creation**, you'll be asked to choose a **primary style preference** - this sets the default approach, but you can (and should) use the other style when it makes more sense for specific steps.
|
|
||||||
|
|
||||||
## Workflow Process
|
|
||||||
|
|
||||||
### Phase 0: Optional Brainstorming (Step -1)
|
|
||||||
|
|
||||||
- **Creative Exploration**: Option to brainstorm workflow ideas before structured development
|
|
||||||
- **Design Concept Development**: Generate multiple approaches and explore different possibilities
|
|
||||||
- **Requirement Clarification**: Use brainstorming output to inform workflow purpose, type, and structure
|
|
||||||
- **Enhanced Creativity**: Leverage AI brainstorming tools for innovative workflow design
|
|
||||||
|
|
||||||
The brainstorming phase invokes the CIS brainstorming workflow to:
|
|
||||||
|
|
||||||
- Explore workflow ideas and approaches
|
|
||||||
- Clarify requirements and use cases
|
|
||||||
- Generate creative solutions for complex automation needs
|
|
||||||
- Inform the structured workflow building process
|
|
||||||
|
|
||||||
### Phase 1: Planning (Steps 0-3)
|
|
||||||
|
|
||||||
- Load workflow creation guide and conventions
|
|
||||||
- Define workflow purpose, name, and type (informed by brainstorming if used)
|
|
||||||
- Gather metadata and configuration details
|
|
||||||
- Design step structure and flow
|
|
||||||
|
|
||||||
### Phase 2: Generation (Steps 4-8)
|
|
||||||
|
|
||||||
- Create workflow.yaml with proper configuration
|
|
||||||
- Generate instructions.md with XML-structured steps
|
|
||||||
- Create template.md (for document workflows)
|
|
||||||
- Generate validation checklist
|
|
||||||
- Create supporting data files (optional)
|
|
||||||
|
|
||||||
### Phase 3: Documentation and Validation (Steps 9-11)
|
|
||||||
|
|
||||||
- Create comprehensive README.md (MANDATORY)
|
|
||||||
- Test and validate workflow structure
|
|
||||||
- Provide usage instructions and next steps
|
|
||||||
|
|
||||||
## Output
|
|
||||||
|
|
||||||
### Generated Workflow Folder
|
|
||||||
|
|
||||||
Creates a complete workflow folder at:
|
|
||||||
`{project-root}/{bmad_folder}/{{target_module}}/workflows/{{workflow_name}}/`
|
|
||||||
|
|
||||||
### Files Created
|
|
||||||
|
|
||||||
**Always Created:**
|
|
||||||
|
|
||||||
- `workflow.yaml` - Configuration with paths and variables
|
|
||||||
- `README.md` - Comprehensive documentation (MANDATORY as of v6)
|
|
||||||
- `instructions.md` - Execution steps (if not template-only workflow)
|
|
||||||
|
|
||||||
**Conditionally Created:**
|
|
||||||
|
|
||||||
- `template.md` - Document structure (for document workflows)
|
|
||||||
- `checklist.md` - Validation criteria (optional but recommended)
|
|
||||||
- Supporting data files (CSV, JSON, etc. as needed)
|
|
||||||
|
|
||||||
### Output Structure
|
|
||||||
|
|
||||||
For document workflows, the README documents:
|
|
||||||
|
|
||||||
- Workflow purpose and use cases
|
|
||||||
- Usage examples with actual commands
|
|
||||||
- Input expectations
|
|
||||||
- Output structure and location
|
|
||||||
- Best practices
|
|
||||||
|
|
||||||
## Requirements
|
|
||||||
|
|
||||||
- Access to workflow creation guide
|
|
||||||
- BMAD Core v6 project structure
|
|
||||||
- Module to host the new workflow (bmm, bmb, cis, or custom)
|
|
||||||
|
|
||||||
## Best Practices
|
|
||||||
|
|
||||||
### Before Starting
|
|
||||||
|
|
||||||
1. **Consider Brainstorming**: If you're unsure about the workflow approach, use the optional brainstorming phase
|
|
||||||
2. Review the workflow creation guide to understand conventions
|
|
||||||
3. Have a clear understanding of the workflow's purpose (or be ready to explore it creatively)
|
|
||||||
4. Know which type of workflow you're creating (document, action, etc.) or be open to discovery
|
|
||||||
5. Identify any data files or references needed
|
|
||||||
|
|
||||||
### Creative Workflow Design
|
|
||||||
|
|
||||||
The create-workflow now supports a **seamless transition from creative ideation to structured implementation**:
|
|
||||||
|
|
||||||
- **"I need a workflow for something..."** → Start with brainstorming to explore possibilities
|
|
||||||
- **Brainstorm** → Generate multiple approaches and clarify requirements
|
|
||||||
- **Structured workflow** → Build the actual workflow using insights from brainstorming
|
|
||||||
- **One seamless session** → Complete the entire process from idea to implementation
|
|
||||||
|
|
||||||
### During Execution
|
|
||||||
|
|
||||||
1. Follow kebab-case naming conventions
|
|
||||||
2. Be specific with step goals and instructions
|
|
||||||
3. Use descriptive variable names (snake_case)
|
|
||||||
4. Set appropriate limits ("3-5 items maximum")
|
|
||||||
5. Include examples where helpful
|
|
||||||
|
|
||||||
### After Completion
|
|
||||||
|
|
||||||
1. Test the newly created workflow
|
|
||||||
2. Validate against the checklist
|
|
||||||
3. Ensure README is comprehensive and accurate
|
|
||||||
4. Test all file paths and variable references
|
|
||||||
|
|
||||||
## Troubleshooting
|
|
||||||
|
|
||||||
### Issue: Generated workflow won't execute
|
|
||||||
|
|
||||||
- **Solution**: Verify all file paths in workflow.yaml use proper variable substitution
|
|
||||||
- **Check**: Ensure installed_path and project-root are correctly set
|
|
||||||
|
|
||||||
### Issue: Variables not replacing in template
|
|
||||||
|
|
||||||
- **Solution**: Ensure variable names match exactly between instructions `<template-output>` tags and template `{{variables}}`
|
|
||||||
- **Check**: Use snake_case consistently
|
|
||||||
|
|
||||||
### Issue: README has placeholder text
|
|
||||||
|
|
||||||
- **Solution**: This workflow now enforces README generation - ensure Step 10 completed fully
|
|
||||||
- **Check**: No {WORKFLOW_TITLE} or similar placeholders should remain
|
|
||||||
|
|
||||||
## Customization
|
|
||||||
|
|
||||||
To modify this workflow:
|
|
||||||
|
|
||||||
1. Edit `instructions.md` to adjust the creation process
|
|
||||||
2. Update templates in `workflow-template/` to change generated files
|
|
||||||
3. Modify `workflow-creation-guide.md` to update conventions
|
|
||||||
4. Edit `checklist.md` to change validation criteria
|
|
||||||
|
|
||||||
## Version History
|
|
||||||
|
|
||||||
- **v6.0.0** - README.md now MANDATORY for all workflows
|
|
||||||
- Added comprehensive README template
|
|
||||||
- Enhanced validation for documentation
|
|
||||||
- Improved Step 10 with detailed README requirements
|
|
||||||
|
|
||||||
- **v6.0.0** - Initial BMAD Core v6 compatible version
|
|
||||||
- Template-based workflow generation
|
|
||||||
- Convention enforcement
|
|
||||||
- Validation checklist support
|
|
||||||
|
|
||||||
## Support
|
|
||||||
|
|
||||||
For issues or questions:
|
|
||||||
|
|
||||||
- Review `/{bmad_folder}/bmb/workflows/create-workflow/workflow-creation-guide.md`
|
|
||||||
- Check existing workflows in `/{bmad_folder}/bmm/workflows/` for examples
|
|
||||||
- Validate against `/{bmad_folder}/bmb/workflows/create-workflow/checklist.md`
|
|
||||||
- Consult BMAD Method v6 documentation
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
_Part of the BMad Method v6 - BMB (BMad Builder) Module_
|
|
||||||
|
|
@ -1,197 +0,0 @@
|
||||||
# Workflow Brainstorming Context
|
|
||||||
|
|
||||||
_Context provided to brainstorming workflow when creating a new BMAD workflow_
|
|
||||||
|
|
||||||
## Session Focus
|
|
||||||
|
|
||||||
You are brainstorming ideas for a **BMAD workflow** - a guided, multi-step process that helps users accomplish complex tasks with structure, consistency, and quality.
|
|
||||||
|
|
||||||
## What is a BMAD Workflow?
|
|
||||||
|
|
||||||
A workflow is a structured process that provides:
|
|
||||||
|
|
||||||
- **Clear Steps**: Sequential operations with defined goals
|
|
||||||
- **User Guidance**: Prompts, questions, and decisions at each phase
|
|
||||||
- **Quality Output**: Documents, artifacts, or completed actions
|
|
||||||
- **Repeatability**: Same process yields consistent results
|
|
||||||
- **Type**: Document (creates docs), Action (performs tasks), Interactive (guides sessions), Autonomous (runs automated), Meta (orchestrates other workflows)
|
|
||||||
|
|
||||||
## Brainstorming Goals
|
|
||||||
|
|
||||||
Explore and define:
|
|
||||||
|
|
||||||
### 1. Problem and Purpose
|
|
||||||
|
|
||||||
- **What task needs structure?** (specific process users struggle with)
|
|
||||||
- **Why is this hard manually?** (complexity, inconsistency, missing steps)
|
|
||||||
- **What would ideal process look like?** (steps, checkpoints, outputs)
|
|
||||||
- **Who needs this?** (target users and their pain points)
|
|
||||||
|
|
||||||
### 2. Process Flow
|
|
||||||
|
|
||||||
- **How many phases?** (typically 3-10 major steps)
|
|
||||||
- **What's the sequence?** (logical flow from start to finish)
|
|
||||||
- **What decisions are needed?** (user choices that affect path)
|
|
||||||
- **What's optional vs required?** (flexibility points)
|
|
||||||
- **What checkpoints matter?** (validation, review, approval points)
|
|
||||||
|
|
||||||
### 3. Inputs and Outputs
|
|
||||||
|
|
||||||
- **What inputs are needed?** (documents, data, user answers)
|
|
||||||
- **What outputs are generated?** (documents, code, configurations)
|
|
||||||
- **What format?** (markdown, XML, YAML, actions)
|
|
||||||
- **What quality criteria?** (how to validate success)
|
|
||||||
|
|
||||||
### 4. Workflow Type and Style
|
|
||||||
|
|
||||||
- **Document Workflow?** Creates structured documents (PRDs, specs, reports)
|
|
||||||
- **Action Workflow?** Performs operations (refactoring, deployment, analysis)
|
|
||||||
- **Interactive Workflow?** Guides creative process (brainstorming, planning)
|
|
||||||
- **Autonomous Workflow?** Runs without user input (batch processing, generation)
|
|
||||||
- **Meta Workflow?** Orchestrates other workflows (project setup, module creation)
|
|
||||||
|
|
||||||
## Creative Constraints
|
|
||||||
|
|
||||||
A great BMAD workflow should be:
|
|
||||||
|
|
||||||
- **Focused**: Solves one problem well (not everything)
|
|
||||||
- **Structured**: Clear phases with defined goals
|
|
||||||
- **Flexible**: Optional steps, branching paths where appropriate
|
|
||||||
- **Validated**: Checklist to verify completeness and quality
|
|
||||||
- **Documented**: README explains when and how to use it
|
|
||||||
|
|
||||||
## Workflow Architecture Questions
|
|
||||||
|
|
||||||
### Core Structure
|
|
||||||
|
|
||||||
1. **Workflow name** (kebab-case, e.g., "product-brief")
|
|
||||||
2. **Purpose** (one sentence)
|
|
||||||
3. **Type** (document/action/interactive/autonomous/meta)
|
|
||||||
4. **Major phases** (3-10 high-level steps)
|
|
||||||
5. **Output** (what gets created)
|
|
||||||
|
|
||||||
### Process Details
|
|
||||||
|
|
||||||
1. **Required inputs** (what user must provide)
|
|
||||||
2. **Optional inputs** (what enhances results)
|
|
||||||
3. **Decision points** (where user chooses path)
|
|
||||||
4. **Checkpoints** (where to pause for approval)
|
|
||||||
5. **Variables** (data passed between steps)
|
|
||||||
|
|
||||||
### Quality and Validation
|
|
||||||
|
|
||||||
1. **Success criteria** (what defines "done")
|
|
||||||
2. **Validation checklist** (measurable quality checks)
|
|
||||||
3. **Common issues** (troubleshooting guidance)
|
|
||||||
4. **Best practices** (tips for optimal results)
|
|
||||||
|
|
||||||
## Workflow Pattern Examples
|
|
||||||
|
|
||||||
### Document Generation Workflows
|
|
||||||
|
|
||||||
- **Product Brief**: Idea → Vision → Features → Market → Output
|
|
||||||
- **PRD**: Requirements → User Stories → Acceptance Criteria → Document
|
|
||||||
- **Architecture**: Requirements → Decisions → Design → Diagrams → ADRs
|
|
||||||
- **Technical Spec**: Epic → Implementation → Testing → Deployment → Doc
|
|
||||||
|
|
||||||
### Action Workflows
|
|
||||||
|
|
||||||
- **Code Refactoring**: Analyze → Plan → Refactor → Test → Commit
|
|
||||||
- **Deployment**: Build → Test → Stage → Validate → Deploy → Monitor
|
|
||||||
- **Migration**: Assess → Plan → Convert → Validate → Deploy
|
|
||||||
- **Analysis**: Collect → Process → Analyze → Report → Recommend
|
|
||||||
|
|
||||||
### Interactive Workflows
|
|
||||||
|
|
||||||
- **Brainstorming**: Setup → Generate → Expand → Evaluate → Prioritize
|
|
||||||
- **Planning**: Context → Goals → Options → Decisions → Plan
|
|
||||||
- **Review**: Load → Analyze → Critique → Suggest → Document
|
|
||||||
|
|
||||||
### Meta Workflows
|
|
||||||
|
|
||||||
- **Project Setup**: Plan → Architecture → Stories → Setup → Initialize
|
|
||||||
- **Module Creation**: Brainstorm → Brief → Agents → Workflows → Install
|
|
||||||
- **Sprint Planning**: Backlog → Capacity → Stories → Commit → Kickoff
|
|
||||||
|
|
||||||
## Workflow Design Patterns
|
|
||||||
|
|
||||||
### Linear Flow
|
|
||||||
|
|
||||||
Simple sequence: Step 1 → Step 2 → Step 3 → Done
|
|
||||||
|
|
||||||
**Good for:**
|
|
||||||
|
|
||||||
- Document generation
|
|
||||||
- Structured analysis
|
|
||||||
- Sequential builds
|
|
||||||
|
|
||||||
### Branching Flow
|
|
||||||
|
|
||||||
Conditional paths: Step 1 → [Decision] → Path A or Path B → Merge → Done
|
|
||||||
|
|
||||||
**Good for:**
|
|
||||||
|
|
||||||
- Different project types
|
|
||||||
- Optional deep dives
|
|
||||||
- Scale-adaptive processes
|
|
||||||
|
|
||||||
### Iterative Flow
|
|
||||||
|
|
||||||
Refinement loops: Step 1 → Step 2 → [Review] → (Repeat if needed) → Done
|
|
||||||
|
|
||||||
**Good for:**
|
|
||||||
|
|
||||||
- Creative processes
|
|
||||||
- Quality refinement
|
|
||||||
- Approval cycles
|
|
||||||
|
|
||||||
### Router Flow
|
|
||||||
|
|
||||||
Type selection: [Select Type] → Load appropriate instructions → Execute → Done
|
|
||||||
|
|
||||||
**Good for:**
|
|
||||||
|
|
||||||
- Multi-mode workflows
|
|
||||||
- Reusable frameworks
|
|
||||||
- Flexible tools
|
|
||||||
|
|
||||||
## Suggested Brainstorming Techniques
|
|
||||||
|
|
||||||
Particularly effective for workflow ideation:
|
|
||||||
|
|
||||||
1. **Process Mapping**: Draw current painful process, identify improvements
|
|
||||||
2. **Step Decomposition**: Break complex task into atomic steps
|
|
||||||
3. **Checkpoint Thinking**: Where do users need pause/review/decision?
|
|
||||||
4. **Pain Point Analysis**: What makes current process frustrating?
|
|
||||||
5. **Success Visualization**: What does perfect execution look like?
|
|
||||||
|
|
||||||
## Key Questions to Answer
|
|
||||||
|
|
||||||
1. What manual process needs structure and guidance?
|
|
||||||
2. What makes this process hard or inconsistent today?
|
|
||||||
3. What are the 3-10 major phases/steps?
|
|
||||||
4. What document or output gets created?
|
|
||||||
5. What inputs are required from the user?
|
|
||||||
6. What decisions or choices affect the flow?
|
|
||||||
7. What quality criteria define success?
|
|
||||||
8. Document, Action, Interactive, Autonomous, or Meta workflow?
|
|
||||||
9. What makes this workflow valuable vs doing it manually?
|
|
||||||
10. What would make this workflow delightful to use?
|
|
||||||
|
|
||||||
## Output Goals
|
|
||||||
|
|
||||||
Generate:
|
|
||||||
|
|
||||||
- **Workflow name**: Clear, describes the process
|
|
||||||
- **Purpose statement**: One sentence explaining value
|
|
||||||
- **Workflow type**: Classification with rationale
|
|
||||||
- **Phase outline**: 3-10 major steps with goals
|
|
||||||
- **Input/output description**: What goes in, what comes out
|
|
||||||
- **Key decisions**: Where user makes choices
|
|
||||||
- **Success criteria**: How to know it worked
|
|
||||||
- **Unique value**: Why this workflow beats manual process
|
|
||||||
- **Use cases**: 3-5 scenarios where this workflow shines
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
_This focused context helps create valuable, structured BMAD workflows_
|
|
||||||
|
|
@ -1,94 +0,0 @@
|
||||||
# Build Workflow - Validation Checklist
|
|
||||||
|
|
||||||
## Workflow Configuration (workflow.yaml)
|
|
||||||
|
|
||||||
- [ ] Name follows kebab-case convention
|
|
||||||
- [ ] Description clearly states workflow purpose
|
|
||||||
- [ ] All paths use proper variable substitution
|
|
||||||
- [ ] installed_path points to correct module location
|
|
||||||
- [ ] template/instructions paths are correct for workflow type
|
|
||||||
- [ ] Output file pattern is appropriate
|
|
||||||
- [ ] YAML syntax is valid (no parsing errors)
|
|
||||||
|
|
||||||
## Instructions Structure (instructions.md)
|
|
||||||
|
|
||||||
- [ ] Critical headers reference workflow engine
|
|
||||||
- [ ] All steps have sequential numbering
|
|
||||||
- [ ] Each step has a clear goal attribute
|
|
||||||
- [ ] Optional steps marked with optional="true"
|
|
||||||
- [ ] Repeating steps have appropriate repeat attributes
|
|
||||||
- [ ] All template-output tags have unique variable names
|
|
||||||
- [ ] Flow control (if any) has valid step references
|
|
||||||
|
|
||||||
## Template Structure (if document workflow)
|
|
||||||
|
|
||||||
- [ ] All sections have appropriate placeholders
|
|
||||||
- [ ] Variable names match template-output tags exactly
|
|
||||||
- [ ] Markdown formatting is valid
|
|
||||||
- [ ] Date and metadata fields included
|
|
||||||
- [ ] No unreferenced variables remain
|
|
||||||
|
|
||||||
## Content Quality
|
|
||||||
|
|
||||||
- [ ] Instructions are specific and actionable
|
|
||||||
- [ ] Examples provided where helpful
|
|
||||||
- [ ] Limits set for lists and content length
|
|
||||||
- [ ] User prompts are clear
|
|
||||||
- [ ] Step goals accurately describe outcomes
|
|
||||||
|
|
||||||
## Validation Checklist (if present)
|
|
||||||
|
|
||||||
- [ ] Criteria are measurable and specific
|
|
||||||
- [ ] Checks grouped logically by category
|
|
||||||
- [ ] Final validation summary included
|
|
||||||
- [ ] All critical requirements covered
|
|
||||||
|
|
||||||
## File System
|
|
||||||
|
|
||||||
- [ ] Workflow folder created in correct module
|
|
||||||
- [ ] All required files present based on workflow type
|
|
||||||
- [ ] File permissions allow execution
|
|
||||||
- [ ] No placeholder text remains (like {TITLE})
|
|
||||||
|
|
||||||
## Testing Readiness
|
|
||||||
|
|
||||||
- [ ] Workflow can be invoked without errors
|
|
||||||
- [ ] All required inputs are documented
|
|
||||||
- [ ] Output location is writable
|
|
||||||
- [ ] Dependencies (if any) are available
|
|
||||||
|
|
||||||
## Web Bundle Configuration (if applicable)
|
|
||||||
|
|
||||||
- [ ] web_bundle section present if needed
|
|
||||||
- [ ] Name, description, author copied from main config
|
|
||||||
- [ ] All file paths converted to {bmad_folder}/-relative format
|
|
||||||
- [ ] NO {config_source} variables in web bundle
|
|
||||||
- [ ] NO {project-root} prefixes in paths
|
|
||||||
- [ ] Instructions path listed correctly
|
|
||||||
- [ ] Validation/checklist path listed correctly
|
|
||||||
- [ ] Template path listed (if document workflow)
|
|
||||||
- [ ] All data files referenced in instructions are listed
|
|
||||||
- [ ] All sub-workflows are included
|
|
||||||
- [ ] web_bundle_files array is complete:
|
|
||||||
- [ ] Instructions.md included
|
|
||||||
- [ ] Checklist.md included
|
|
||||||
- [ ] Template.md included (if applicable)
|
|
||||||
- [ ] All CSV/JSON data files included
|
|
||||||
- [ ] All referenced templates included
|
|
||||||
- [ ] All sub-workflow files included
|
|
||||||
- [ ] No external dependencies outside bundle
|
|
||||||
|
|
||||||
## Documentation
|
|
||||||
|
|
||||||
- [ ] README created (if requested)
|
|
||||||
- [ ] Usage instructions clear
|
|
||||||
- [ ] Example command provided
|
|
||||||
- [ ] Special requirements noted
|
|
||||||
- [ ] Web bundle deployment noted (if applicable)
|
|
||||||
|
|
||||||
## Final Validation
|
|
||||||
|
|
||||||
- [ ] Configuration: No issues
|
|
||||||
- [ ] Instructions: Complete and clear
|
|
||||||
- [ ] Template: Variables properly mapped
|
|
||||||
- [ ] Testing: Ready for test run
|
|
||||||
|
|
@ -1,725 +0,0 @@
|
||||||
# Build Workflow - Workflow Builder Instructions
|
|
||||||
|
|
||||||
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
|
|
||||||
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/create-workflow/workflow.yaml</critical>
|
|
||||||
<critical>You MUST fully understand the workflow creation guide at: {workflow_creation_guide}</critical>
|
|
||||||
<critical>Study the guide thoroughly to follow ALL conventions for optimal human-AI collaboration</critical>
|
|
||||||
<critical>Communicate in {communication_language} throughout the workflow creation process</critical>
|
|
||||||
<critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical>
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="-1" goal="Optional brainstorming phase" optional="true">
|
|
||||||
<ask>Do you want to brainstorm workflow ideas first? [y/n]</ask>
|
|
||||||
|
|
||||||
<action if="user_response == 'y' or user_response == 'yes'">
|
|
||||||
Invoke brainstorming workflow to explore ideas and design concepts:
|
|
||||||
- Workflow: {project-root}/{bmad_folder}/core/workflows/brainstorming/workflow.yaml
|
|
||||||
- Context data: {installed_path}/brainstorm-context.md
|
|
||||||
- Purpose: Generate creative workflow ideas, explore different approaches, and clarify requirements
|
|
||||||
|
|
||||||
The brainstorming output will inform:
|
|
||||||
|
|
||||||
- Workflow purpose and goals
|
|
||||||
- Workflow type selection
|
|
||||||
- Step design and structure
|
|
||||||
- User experience considerations
|
|
||||||
- Technical requirements
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action if="user_response == 'n' or user_response == 'no'">
|
|
||||||
Skip brainstorming and proceed directly to workflow building process.
|
|
||||||
</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="0" goal="Load and understand workflow conventions">
|
|
||||||
<action>Load the complete workflow creation guide from: {workflow_creation_guide}</action>
|
|
||||||
<action>Study all sections thoroughly including:
|
|
||||||
- Core concepts (tasks vs workflows, workflow types)
|
|
||||||
- Workflow structure (required/optional files, patterns)
|
|
||||||
- Writing instructions (step attributes, XML tags, flow control)
|
|
||||||
- Templates and variables (syntax, naming, sources)
|
|
||||||
- Validation best practices
|
|
||||||
- Common pitfalls to avoid
|
|
||||||
</action>
|
|
||||||
<action>Load template files from: {workflow_template_path}/</action>
|
|
||||||
<critical>You must follow ALL conventions from the guide to ensure optimal human-AI collaboration</critical>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="1" goal="Define workflow purpose and type">
|
|
||||||
Ask the user:
|
|
||||||
- What is the workflow name? (kebab-case, e.g., "product-brief")
|
|
||||||
- What module will it belong to? (e.g., "bmm", "bmb", "cis")
|
|
||||||
- Store as {{target_module}} for output path determination
|
|
||||||
- What is the workflow's main purpose?
|
|
||||||
- What type of workflow is this?
|
|
||||||
- Document workflow (generates documents like PRDs, specs)
|
|
||||||
- Action workflow (performs actions like refactoring)
|
|
||||||
- Interactive workflow (guided sessions)
|
|
||||||
- Autonomous workflow (runs without user input)
|
|
||||||
- Meta-workflow (coordinates other workflows)
|
|
||||||
|
|
||||||
Based on type, determine which files are needed:
|
|
||||||
|
|
||||||
- Document: workflow.yaml + template.md + instructions.md + checklist.md
|
|
||||||
- Action: workflow.yaml + instructions.md
|
|
||||||
- Others: Varies based on requirements
|
|
||||||
|
|
||||||
<critical>Determine output location based on module assignment:</critical>
|
|
||||||
|
|
||||||
- If workflow belongs to module: Save to {module_output_folder}
|
|
||||||
- If standalone workflow: Save to {standalone_output_folder}
|
|
||||||
|
|
||||||
Store decisions for later use.
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Gather workflow metadata and invocation settings">
|
|
||||||
Collect essential configuration details:
|
|
||||||
- Description (clear purpose statement)
|
|
||||||
- Author name (default to user_name or "BMad")
|
|
||||||
- Output file naming pattern
|
|
||||||
- Any required input documents
|
|
||||||
- Any required tools or dependencies
|
|
||||||
|
|
||||||
<action>Determine standalone property - this controls how the workflow can be invoked:
|
|
||||||
|
|
||||||
Explain to the user:
|
|
||||||
|
|
||||||
**Standalone Property** controls whether the workflow can be invoked directly or only called by other workflows/agents.
|
|
||||||
|
|
||||||
**standalone: true (DEFAULT - Recommended for most workflows)**:
|
|
||||||
|
|
||||||
- Users can invoke directly via IDE commands or `/workflow-name`
|
|
||||||
- Shows up in IDE command palette
|
|
||||||
- Can also be called from agent menus or other workflows
|
|
||||||
- Use for: User-facing workflows, entry-point workflows, any workflow users run directly
|
|
||||||
|
|
||||||
**standalone: false (Use for helper/internal workflows)**:
|
|
||||||
|
|
||||||
- Cannot be invoked directly by users
|
|
||||||
- Only called via `<invoke-workflow>` from other workflows or agent menus
|
|
||||||
- Doesn't appear in IDE command palette
|
|
||||||
- Use for: Internal utilities, sub-workflows, helpers that don't make sense standalone
|
|
||||||
|
|
||||||
Most workflows should be `standalone: true` to give users direct access.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>Should this workflow be directly invokable by users?
|
|
||||||
|
|
||||||
1. **Yes (Recommended)** - Users can run it directly (standalone: true)
|
|
||||||
2. **No** - Only called by other workflows/agents (standalone: false)
|
|
||||||
|
|
||||||
Most workflows choose option 1:
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
<action>Store {{standalone_setting}} as true or false based on response</action>
|
|
||||||
|
|
||||||
Create the workflow name in kebab-case and verify it doesn't conflict with existing workflows.
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Understand workflow interaction style and design steps">
|
|
||||||
<critical>Instruction style and interactivity level fundamentally shape the user experience - choose thoughtfully</critical>
|
|
||||||
|
|
||||||
<action>Reference the comprehensive "Instruction Styles: Intent-Based vs Prescriptive" section from the loaded creation guide</action>
|
|
||||||
|
|
||||||
<action>Discuss instruction style collaboratively with the user:
|
|
||||||
|
|
||||||
Explain that there are two primary approaches:
|
|
||||||
|
|
||||||
**Intent-Based (RECOMMENDED as default)**:
|
|
||||||
|
|
||||||
- Gives AI goals and principles, lets it adapt conversation naturally
|
|
||||||
- More flexible, conversational, responsive to user context
|
|
||||||
- Better for: discovery, complex decisions, teaching, varied user skill levels
|
|
||||||
- Uses <action> tags with guiding instructions
|
|
||||||
- Example from architecture workflow: Facilitates decisions adapting to user_skill_level
|
|
||||||
|
|
||||||
**Prescriptive**:
|
|
||||||
|
|
||||||
- Provides exact questions and specific options
|
|
||||||
- More controlled, predictable, consistent across runs
|
|
||||||
- Better for: simple data collection, finite options, compliance, quick setup
|
|
||||||
- Uses <ask> tags with specific question text
|
|
||||||
- Example: Platform selection with 5 defined choices
|
|
||||||
|
|
||||||
Explain that **most workflows should default to intent-based** but use prescriptive for simple data points.
|
|
||||||
The architecture workflow is an excellent example of intent-based with prescriptive moments.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>For this workflow's PRIMARY style:
|
|
||||||
|
|
||||||
1. **Intent-based (Recommended)** - Adaptive, conversational, responds to user context
|
|
||||||
2. **Prescriptive** - Structured, consistent, controlled interactions
|
|
||||||
3. **Mixed/Balanced** - I'll help you decide step-by-step
|
|
||||||
|
|
||||||
What feels right for your workflow's purpose?
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
<action>Store {{instruction_style}} preference</action>
|
|
||||||
|
|
||||||
<action>Now discuss interactivity level:
|
|
||||||
|
|
||||||
Beyond style, consider **how interactive** this workflow should be:
|
|
||||||
|
|
||||||
**High Interactivity (Collaborative)**:
|
|
||||||
|
|
||||||
- Constant back-and-forth with user
|
|
||||||
- User guides direction, AI facilitates
|
|
||||||
- Iterative refinement and review
|
|
||||||
- Best for: creative work, complex decisions, learning experiences
|
|
||||||
- Example: Architecture workflow's collaborative decision-making
|
|
||||||
|
|
||||||
**Medium Interactivity (Guided)**:
|
|
||||||
|
|
||||||
- Key decision points have interaction
|
|
||||||
- AI proposes, user confirms or refines
|
|
||||||
- Validation checkpoints
|
|
||||||
- Best for: most document workflows, structured processes
|
|
||||||
- Example: PRD workflow with sections to review
|
|
||||||
|
|
||||||
**Low Interactivity (Autonomous)**:
|
|
||||||
|
|
||||||
- Minimal user input required
|
|
||||||
- AI works independently with guidelines
|
|
||||||
- User reviews final output
|
|
||||||
- Best for: automated generation, batch processing
|
|
||||||
- Example: Generating user stories from epics
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>What interactivity level suits this workflow?
|
|
||||||
|
|
||||||
1. **High** - Highly collaborative, user actively involved throughout (Recommended)
|
|
||||||
2. **Medium** - Guided with key decision points
|
|
||||||
3. **Low** - Mostly autonomous with final review
|
|
||||||
|
|
||||||
Select the level that matches your workflow's purpose:
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
<action>Store {{interactivity_level}} preference</action>
|
|
||||||
|
|
||||||
<action>Explain how these choices will inform the workflow design:
|
|
||||||
|
|
||||||
- Intent-based + High interactivity: Conversational discovery with open questions
|
|
||||||
- Intent-based + Medium: Facilitated guidance with confirmation points
|
|
||||||
- Intent-based + Low: Principle-based autonomous generation
|
|
||||||
- Prescriptive + any level: Structured questions, but frequency varies
|
|
||||||
- Mixed: Strategic use of both styles where each works best
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Now work with user to outline workflow steps:
|
|
||||||
|
|
||||||
- How many major steps? (Recommend 3-7 for most workflows)
|
|
||||||
- What is the goal of each step?
|
|
||||||
- Which steps are optional?
|
|
||||||
- Which steps need heavy user collaboration vs autonomous execution?
|
|
||||||
- Which steps should repeat?
|
|
||||||
- What variables/outputs does each step produce?
|
|
||||||
|
|
||||||
Consider their instruction_style and interactivity_level choices when designing step flow:
|
|
||||||
|
|
||||||
- High interactivity: More granular steps with collaboration
|
|
||||||
- Low interactivity: Larger autonomous steps with review
|
|
||||||
- Intent-based: Focus on goals and principles in step descriptions
|
|
||||||
- Prescriptive: Define specific questions and options
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Create a step outline that matches the chosen style and interactivity level</action>
|
|
||||||
<action>Note which steps should be intent-based vs prescriptive (if mixed approach)</action>
|
|
||||||
|
|
||||||
<template-output>step_outline</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Create workflow.yaml">
|
|
||||||
Load and use the template at: {template_workflow_yaml}
|
|
||||||
|
|
||||||
Replace all placeholders following the workflow creation guide conventions:
|
|
||||||
|
|
||||||
- {TITLE} → Proper case workflow name
|
|
||||||
- {WORKFLOW_CODE} → kebab-case name
|
|
||||||
- {WORKFLOW_DESCRIPTION} → Clear description
|
|
||||||
- {module-code} → Target module
|
|
||||||
- {file.md} → Output filename pattern
|
|
||||||
|
|
||||||
Include:
|
|
||||||
|
|
||||||
- All metadata from steps 1-2
|
|
||||||
- **Standalone property**: Use {{standalone_setting}} from step 2 (true or false)
|
|
||||||
- Proper paths for installed_path using variable substitution
|
|
||||||
- Template/instructions/validation paths based on workflow type:
|
|
||||||
- Document workflow: all files (template, instructions, validation)
|
|
||||||
- Action workflow: instructions only (template: false)
|
|
||||||
- Autonomous: set autonomous: true flag
|
|
||||||
- Required tools if any
|
|
||||||
- Recommended inputs if any
|
|
||||||
|
|
||||||
<critical>ALWAYS include the standard config block:</critical>
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# Critical variables from config
|
|
||||||
config_source: '{project-root}/{bmad_folder}/{{target_module}}/config.yaml'
|
|
||||||
output_folder: '{config_source}:output_folder'
|
|
||||||
user_name: '{config_source}:user_name'
|
|
||||||
communication_language: '{config_source}:communication_language'
|
|
||||||
date: system-generated
|
|
||||||
```
|
|
||||||
|
|
||||||
<critical>This standard config ensures workflows can run autonomously and communicate properly with users</critical>
|
|
||||||
|
|
||||||
<critical>ALWAYS include the standalone property:</critical>
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
standalone: { { standalone_setting } } # true or false from step 2
|
|
||||||
```
|
|
||||||
|
|
||||||
**Example complete workflow.yaml structure**:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
name: 'workflow-name'
|
|
||||||
description: 'Clear purpose statement'
|
|
||||||
|
|
||||||
# Paths
|
|
||||||
installed_path: '{project-root}/{bmad_folder}/module/workflows/name'
|
|
||||||
template: '{installed_path}/template.md'
|
|
||||||
instructions: '{installed_path}/instructions.md'
|
|
||||||
validation: '{installed_path}/checklist.md'
|
|
||||||
|
|
||||||
# Critical variables from config
|
|
||||||
config_source: '{project-root}/{bmad_folder}/module/config.yaml'
|
|
||||||
output_folder: '{config_source}:output_folder'
|
|
||||||
user_name: '{config_source}:user_name'
|
|
||||||
communication_language: '{config_source}:communication_language'
|
|
||||||
date: system-generated
|
|
||||||
|
|
||||||
# Output
|
|
||||||
default_output_file: '{output_folder}/document.md'
|
|
||||||
|
|
||||||
# Invocation control
|
|
||||||
standalone: true # or false based on step 2 decision
|
|
||||||
```
|
|
||||||
|
|
||||||
Follow path conventions from guide:
|
|
||||||
|
|
||||||
- Use {project-root} for absolute paths
|
|
||||||
- Use {installed_path} for workflow components
|
|
||||||
- Use {config_source} for config references
|
|
||||||
|
|
||||||
<critical>Determine save location:</critical>
|
|
||||||
|
|
||||||
- Use the output folder determined in Step 1 (module or standalone)
|
|
||||||
- Write to {{output_folder}}/workflow.yaml
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5" goal="Create instructions.md" if="workflow_type != 'template-only'">
|
|
||||||
Load and use the template at: {template_instructions}
|
|
||||||
|
|
||||||
Generate the instructions.md file following the workflow creation guide:
|
|
||||||
|
|
||||||
1. ALWAYS include critical headers:
|
|
||||||
- Workflow engine reference: {project-root}/{bmad_folder}/core/tasks/workflow.xml
|
|
||||||
- workflow.yaml reference: must be loaded and processed
|
|
||||||
|
|
||||||
2. Structure with <workflow> tags containing all steps
|
|
||||||
|
|
||||||
3. For each step from design phase, follow guide conventions:
|
|
||||||
- Step attributes: n="X" goal="clear goal statement"
|
|
||||||
- Optional steps: optional="true"
|
|
||||||
- Repeating: repeat="3" or repeat="for-each-X" or repeat="until-approved"
|
|
||||||
- Conditional: if="condition"
|
|
||||||
- Sub-steps: Use 3a, 3b notation
|
|
||||||
|
|
||||||
4. Use proper XML tags from guide:
|
|
||||||
- Execution: <action>, <check>, <ask>, <goto>, <invoke-workflow>
|
|
||||||
- Output: <template-output>, <invoke-task halt="true">{project-root}/{bmad_folder}/core/tasks/advanced-elicitation.xml</invoke-task>, <critical>, <example>
|
|
||||||
- Flow: <loop>, <break>, <continue>
|
|
||||||
|
|
||||||
5. Best practices from guide:
|
|
||||||
- Keep steps focused (single goal)
|
|
||||||
- Be specific ("Write 1-2 paragraphs" not "Write about")
|
|
||||||
- Provide examples where helpful
|
|
||||||
- Set limits ("3-5 items maximum")
|
|
||||||
- Save checkpoints with <template-output>
|
|
||||||
|
|
||||||
<critical>Standard config variable usage:</critical>
|
|
||||||
|
|
||||||
Instructions MUST use the standard config variables where appropriate:
|
|
||||||
|
|
||||||
- Communicate in {communication_language} throughout the workflow
|
|
||||||
- Address user as {user_name} in greetings and summaries
|
|
||||||
- Write all output files to {output_folder} or subdirectories
|
|
||||||
- Include {date} in generated document headers
|
|
||||||
|
|
||||||
Example usage in instructions:
|
|
||||||
|
|
||||||
```xml
|
|
||||||
<action>Write document to {output_folder}/output-file.md</action>
|
|
||||||
<critical>Communicate all responses in {communication_language}</critical>
|
|
||||||
<output>Hello {user_name}, the workflow is complete!</output>
|
|
||||||
```
|
|
||||||
|
|
||||||
<critical>Applying instruction style preference:</critical>
|
|
||||||
|
|
||||||
Based on the {{instruction_style}} preference from Step 3, generate instructions using these patterns:
|
|
||||||
|
|
||||||
**Intent-Based Instructions (Recommended for most workflows):**
|
|
||||||
|
|
||||||
Focus on goals, principles, and desired outcomes. Let the LLM adapt the conversation naturally.
|
|
||||||
|
|
||||||
✅ **Good Examples:**
|
|
||||||
|
|
||||||
```xml
|
|
||||||
<!-- Discovery and exploration -->
|
|
||||||
<action>Guide user to define their target audience with specific demographics, psychographics, and behavioral characteristics</action>
|
|
||||||
<action>Explore the user's vision for the product, asking probing questions to uncover core motivations and success criteria</action>
|
|
||||||
<action>Help user identify and prioritize key features based on user value and technical feasibility</action>
|
|
||||||
|
|
||||||
<!-- Validation and refinement -->
|
|
||||||
<action>Validate that the technical approach aligns with project constraints and team capabilities</action>
|
|
||||||
<action>Challenge assumptions about user needs and market fit with thought-provoking questions</action>
|
|
||||||
|
|
||||||
<!-- Complex iterative work -->
|
|
||||||
<action>Collaborate with user to refine the architecture, iterating until they're satisfied with the design</action>
|
|
||||||
```
|
|
||||||
|
|
||||||
❌ **Avoid (too prescriptive):**
|
|
||||||
|
|
||||||
```xml
|
|
||||||
<ask>What is your target audience age range? Choose: 18-24, 25-34, 35-44, 45+</ask>
|
|
||||||
<ask>List exactly 3 key features in priority order</ask>
|
|
||||||
```
|
|
||||||
|
|
||||||
**When to use Intent-Based:**
|
|
||||||
|
|
||||||
- Complex discovery processes (user research, requirements gathering)
|
|
||||||
- Creative brainstorming and ideation
|
|
||||||
- Iterative refinement workflows
|
|
||||||
- When user input quality matters more than consistency
|
|
||||||
- Workflows requiring adaptation to context
|
|
||||||
|
|
||||||
**Prescriptive Instructions (Use selectively):**
|
|
||||||
|
|
||||||
Provide exact wording, specific options, and controlled interactions.
|
|
||||||
|
|
||||||
✅ **Good Examples:**
|
|
||||||
|
|
||||||
```xml
|
|
||||||
<!-- Simple data collection -->
|
|
||||||
<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>
|
|
||||||
<ask>Select monetization model: Premium, Free-to-Play, Subscription, Ad-Supported</ask>
|
|
||||||
|
|
||||||
<!-- Compliance and standards -->
|
|
||||||
<ask>Does this comply with GDPR requirements? [yes/no]</ask>
|
|
||||||
<ask>Choose documentation standard: JSDoc, TypeDoc, TSDoc</ask>
|
|
||||||
|
|
||||||
<!-- Binary decisions -->
|
|
||||||
<ask>Do you want to generate test cases? [yes/no]</ask>
|
|
||||||
<ask>Include performance benchmarks? [yes/no]</ask>
|
|
||||||
```
|
|
||||||
|
|
||||||
❌ **Avoid (too rigid for complex tasks):**
|
|
||||||
|
|
||||||
```xml
|
|
||||||
<ask>What are your product goals? List exactly 5 goals, each 10-15 words</ask>
|
|
||||||
<ask>Describe your user persona in exactly 3 sentences</ask>
|
|
||||||
```
|
|
||||||
|
|
||||||
**When to use Prescriptive:**
|
|
||||||
|
|
||||||
- Simple data collection (platform, format, yes/no choices)
|
|
||||||
- Compliance verification and standards adherence
|
|
||||||
- Configuration with finite options
|
|
||||||
- When consistency is critical across all executions
|
|
||||||
- Quick setup wizards
|
|
||||||
|
|
||||||
**Mixing Both Styles (Best Practice):**
|
|
||||||
|
|
||||||
Even if user chose a primary style, use the other when appropriate:
|
|
||||||
|
|
||||||
```xml
|
|
||||||
<!-- Intent-based workflow with prescriptive moments -->
|
|
||||||
<step n="1" goal="Understand user vision">
|
|
||||||
<action>Explore the user's vision for their game, uncovering their creative intent and target experience</action>
|
|
||||||
<action>Ask probing questions about genre, themes, and emotional tone they want to convey</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Capture basic metadata">
|
|
||||||
<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask> <!-- Prescriptive for simple choice -->
|
|
||||||
<ask>Select primary genre: Action, RPG, Strategy, Puzzle, Simulation, Other</ask>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Deep dive into gameplay">
|
|
||||||
<action>Guide user to articulate their core gameplay loop, exploring mechanics and player agency</action> <!-- Back to intent-based -->
|
|
||||||
<action>Help them identify what makes their game unique and compelling</action>
|
|
||||||
</step>
|
|
||||||
```
|
|
||||||
|
|
||||||
**Guidelines for the chosen style:**
|
|
||||||
|
|
||||||
If user chose **Intent-Based**:
|
|
||||||
|
|
||||||
- Default to goal-oriented <action> tags
|
|
||||||
- Use open-ended guidance language
|
|
||||||
- Save prescriptive <ask> tags for simple data/choices
|
|
||||||
- Focus on "guide", "explore", "help user", "validate"
|
|
||||||
- Allow LLM to adapt questions to user responses
|
|
||||||
|
|
||||||
If user chose **Prescriptive**:
|
|
||||||
|
|
||||||
- Default to explicit <ask> tags with clear options
|
|
||||||
- Use precise wording for consistency
|
|
||||||
- Save intent-based <action> tags for complex discovery
|
|
||||||
- Focus on "choose", "select", "specify", "confirm"
|
|
||||||
- Provide structured choices when possible
|
|
||||||
|
|
||||||
**Remember:** The goal is optimal human-AI collaboration. Use whichever style best serves the user at each step.
|
|
||||||
|
|
||||||
<critical>Save location:</critical>
|
|
||||||
|
|
||||||
- Write to {{output_folder}}/instructions.md
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="6" goal="Create template.md" if="workflow_type == 'document'">
|
|
||||||
Load and use the template at: {template_template}
|
|
||||||
|
|
||||||
Generate the template.md file following guide conventions:
|
|
||||||
|
|
||||||
1. Document structure with clear sections
|
|
||||||
2. Variable syntax: {{variable_name}} using snake_case
|
|
||||||
3. Variable names MUST match <template-output> tags exactly from instructions
|
|
||||||
4. Include standard metadata header (optional - config variables available):
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
# Document Title
|
|
||||||
|
|
||||||
**Date:** {{date}}
|
|
||||||
|
|
||||||
**Author:** {{user_name}}
|
|
||||||
```
|
|
||||||
|
|
||||||
Note: {{date}} and {{user_name}} are optional in headers. Primary purpose of these variables:
|
|
||||||
- {{date}} - Gives agent current date awareness (not confused with training cutoff)
|
|
||||||
- {{user_name}} - Optional author attribution
|
|
||||||
- {{communication_language}} - NOT for document output! Tells agent how to communicate during execution
|
|
||||||
|
|
||||||
5. Follow naming conventions from guide:
|
|
||||||
- Use descriptive names: {{primary_user_journey}} not {{puj}}
|
|
||||||
- Snake_case for all variables
|
|
||||||
- Match instruction outputs precisely
|
|
||||||
|
|
||||||
Variable sources as per guide:
|
|
||||||
|
|
||||||
- workflow.yaml config values (user_name, communication_language, date, output_folder)
|
|
||||||
- User input runtime values
|
|
||||||
- Step outputs via <template-output>
|
|
||||||
- System variables (date, paths)
|
|
||||||
|
|
||||||
<critical>Standard config variables in templates:</critical>
|
|
||||||
|
|
||||||
Templates CAN optionally use these config variables:
|
|
||||||
|
|
||||||
- {{user_name}} - Document author (optional)
|
|
||||||
- {{date}} - Generation date (optional)
|
|
||||||
|
|
||||||
IMPORTANT: {{communication_language}} is NOT for document headers!
|
|
||||||
|
|
||||||
- Purpose: Tells agent how to communicate with user during workflow execution
|
|
||||||
- NOT for: Document output language or template headers
|
|
||||||
- Future: {{document_output_language}} will handle multilingual document generation
|
|
||||||
|
|
||||||
These variables are automatically available from workflow.yaml config block.
|
|
||||||
|
|
||||||
<critical>Save location:</critical>
|
|
||||||
|
|
||||||
- Write to {{output_folder}}/template.md
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="7" goal="Create validation checklist" optional="true">
|
|
||||||
Ask if user wants a validation checklist. If yes:
|
|
||||||
|
|
||||||
Load and use the template at: {template_checklist}
|
|
||||||
|
|
||||||
Create checklist.md following guide best practices:
|
|
||||||
|
|
||||||
1. Make criteria MEASURABLE and SPECIFIC
|
|
||||||
❌ "- [ ] Good documentation"
|
|
||||||
✅ "- [ ] Each function has JSDoc comments with parameters and return types"
|
|
||||||
|
|
||||||
2. Group checks logically:
|
|
||||||
- Structure: All sections present, no placeholders, proper formatting
|
|
||||||
- Content Quality: Clear and specific, technically accurate, consistent terminology
|
|
||||||
- Completeness: Ready for next phase, dependencies documented, action items defined
|
|
||||||
|
|
||||||
3. Include workflow-specific validations based on type:
|
|
||||||
- Document workflows: Template variables mapped, sections complete
|
|
||||||
- Action workflows: Actions clearly defined, error handling specified
|
|
||||||
- Interactive: User prompts clear, decision points documented
|
|
||||||
|
|
||||||
4. Add final validation section with issue lists
|
|
||||||
|
|
||||||
<critical>Save location:</critical>
|
|
||||||
|
|
||||||
- Write to {{output_folder}}/checklist.md
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="8" goal="Create supporting files" optional="true">
|
|
||||||
Ask if any supporting data files are needed:
|
|
||||||
- CSV files with data
|
|
||||||
- Example documents
|
|
||||||
- Reference materials
|
|
||||||
|
|
||||||
If yes, create placeholder files or copy from templates.
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="9" goal="Test and validate workflow">
|
|
||||||
Review the created workflow:
|
|
||||||
|
|
||||||
**Basic Validation:**
|
|
||||||
|
|
||||||
1. Verify all file paths are correct
|
|
||||||
2. Check variable names match between files
|
|
||||||
3. Ensure step numbering is sequential
|
|
||||||
4. Validate YAML syntax
|
|
||||||
5. Confirm all placeholders are replaced
|
|
||||||
|
|
||||||
**Standard Config Validation:**
|
|
||||||
|
|
||||||
6. Verify workflow.yaml contains standard config block:
|
|
||||||
|
|
||||||
- config_source defined
|
|
||||||
- output_folder, user_name, communication_language pulled from config
|
|
||||||
- date set to system-generated
|
|
||||||
|
|
||||||
7. Check instructions use config variables where appropriate
|
|
||||||
8. Verify template includes config variables in metadata (if document workflow)
|
|
||||||
|
|
||||||
**YAML/Instruction/Template Alignment:**
|
|
||||||
|
|
||||||
9. Cross-check all workflow.yaml variables against instruction usage:
|
|
||||||
|
|
||||||
- Are all yaml variables referenced in instructions.md OR template.md?
|
|
||||||
- Are there hardcoded values that should be variables?
|
|
||||||
- Do template variables match <template-output> tags in instructions?
|
|
||||||
|
|
||||||
10. Identify any unused yaml fields (bloat detection)
|
|
||||||
|
|
||||||
Show user a summary of created files and their locations.
|
|
||||||
Ask if they want to:
|
|
||||||
|
|
||||||
- Test run the workflow
|
|
||||||
- Make any adjustments
|
|
||||||
- Add additional steps or features
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="9b" goal="Configure web bundle (optional)">
|
|
||||||
<ask>Will this workflow need to be deployable as a web bundle? [yes/no]</ask>
|
|
||||||
|
|
||||||
If yes:
|
|
||||||
<action>Explain web bundle requirements:</action>
|
|
||||||
|
|
||||||
- Web bundles are self-contained and cannot use config_source variables
|
|
||||||
- All files must be explicitly listed in web_bundle_files
|
|
||||||
- File paths use {bmad_folder}/ root (not {project-root})
|
|
||||||
|
|
||||||
<action>Configure web_bundle section in workflow.yaml:</action>
|
|
||||||
|
|
||||||
1. Copy core workflow metadata (name, description, author)
|
|
||||||
2. Convert all file paths to {bmad_folder}/-relative paths:
|
|
||||||
- Remove {project-root}/ prefix
|
|
||||||
- Remove {config_source} references (use hardcoded values)
|
|
||||||
- Example: "{project-root}/{bmad_folder}/bmm/workflows/x" → "{bmad_folder}/bmm/workflows/x"
|
|
||||||
|
|
||||||
3. List ALL referenced files by scanning:
|
|
||||||
|
|
||||||
**Scan instructions.md for:**
|
|
||||||
- File paths in <action> tags
|
|
||||||
- Data files (CSV, JSON, YAML, etc.)
|
|
||||||
- Validation/checklist files
|
|
||||||
- Any <invoke-workflow> calls → must include that workflow's yaml file
|
|
||||||
- Any <goto> tags that reference other workflows
|
|
||||||
- Shared templates or includes
|
|
||||||
|
|
||||||
**Scan template.md for:**
|
|
||||||
- Any includes or references to other files
|
|
||||||
- Shared template fragments
|
|
||||||
|
|
||||||
**Critical: Workflow Dependencies**
|
|
||||||
- If instructions call another workflow, that workflow's yaml MUST be in web_bundle_files
|
|
||||||
- Example: `<invoke-workflow>{project-root}/{bmad_folder}/core/workflows/x/workflow.yaml</invoke-workflow>`
|
|
||||||
→ Add "{bmad_folder}/core/workflows/x/workflow.yaml" to web_bundle_files
|
|
||||||
|
|
||||||
4. Create web_bundle_files array with complete list
|
|
||||||
|
|
||||||
Example:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
web_bundle:
|
|
||||||
name: '{workflow_name}'
|
|
||||||
description: '{workflow_description}'
|
|
||||||
author: '{author}'
|
|
||||||
instructions: '{bmad_folder}/{module}/workflows/{workflow}/instructions.md'
|
|
||||||
validation: '{bmad_folder}/{module}/workflows/{workflow}/checklist.md'
|
|
||||||
template: '{bmad_folder}/{module}/workflows/{workflow}/template.md'
|
|
||||||
|
|
||||||
# Any data files (no config_source)
|
|
||||||
data_file: '{bmad_folder}/{module}/workflows/{workflow}/data.csv'
|
|
||||||
|
|
||||||
web_bundle_files:
|
|
||||||
- '{bmad_folder}/{module}/workflows/{workflow}/instructions.md'
|
|
||||||
- '{bmad_folder}/{module}/workflows/{workflow}/checklist.md'
|
|
||||||
- '{bmad_folder}/{module}/workflows/{workflow}/template.md'
|
|
||||||
- '{bmad_folder}/{module}/workflows/{workflow}/data.csv'
|
|
||||||
# Add every single file referenced anywhere
|
|
||||||
|
|
||||||
# CRITICAL: If this workflow invokes other workflows, use existing_workflows
|
|
||||||
# This signals the bundler to recursively include those workflows' web_bundles
|
|
||||||
existing_workflows:
|
|
||||||
- workflow_variable_name: '{bmad_folder}/path/to/workflow.yaml'
|
|
||||||
```
|
|
||||||
|
|
||||||
**Example with existing_workflows:**
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
web_bundle:
|
|
||||||
name: 'brainstorm-game'
|
|
||||||
description: 'Game brainstorming with CIS workflow'
|
|
||||||
author: 'BMad'
|
|
||||||
instructions: '{bmad_folder}/bmm/workflows/brainstorm-game/instructions.md'
|
|
||||||
template: false
|
|
||||||
web_bundle_files:
|
|
||||||
- '{bmad_folder}/bmm/workflows/brainstorm-game/instructions.md'
|
|
||||||
- '{bmad_folder}/mmm/workflows/brainstorm-game/game-context.md'
|
|
||||||
- '{bmad_folder}/core/workflows/brainstorming/workflow.yaml'
|
|
||||||
existing_workflows:
|
|
||||||
- core_brainstorming: '{bmad_folder}/core/workflows/brainstorming/workflow.yaml'
|
|
||||||
```
|
|
||||||
|
|
||||||
**What existing_workflows does:**
|
|
||||||
|
|
||||||
- Tells the bundler this workflow invokes another workflow
|
|
||||||
- Bundler recursively includes the invoked workflow's entire web_bundle
|
|
||||||
- Essential for meta-workflows that orchestrate other workflows
|
|
||||||
- Maps workflow variable names to their {bmad_folder}/-relative paths
|
|
||||||
|
|
||||||
<action>Validate web bundle completeness:</action>
|
|
||||||
|
|
||||||
- Ensure no {config_source} variables remain
|
|
||||||
- Verify all file paths are listed
|
|
||||||
- Check that paths are {bmad_folder}/-relative
|
|
||||||
- If workflow uses <invoke-workflow>, add to existing_workflows
|
|
||||||
|
|
||||||
<template-output>web_bundle_config</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="10" goal="Document and finalize">
|
|
||||||
<action>Create a brief README for the workflow folder explaining purpose, how to invoke, expected inputs, generated outputs, and any special requirements</action>
|
|
||||||
|
|
||||||
<action>Provide {user_name} with workflow completion summary in {communication_language}:</action>
|
|
||||||
|
|
||||||
- Location of created workflow: {{output_folder}}
|
|
||||||
- Command to run it: `workflow {workflow_name}`
|
|
||||||
- Next steps:
|
|
||||||
- Run the BMAD Method installer to this project location
|
|
||||||
- Select 'Compile Agents (Quick rebuild of all agent .md files)' after confirming the folder
|
|
||||||
- This will compile the new workflow and make it available for use
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,24 +0,0 @@
|
||||||
# {Title} Checklist Validation
|
|
||||||
|
|
||||||
## {Section Foo}
|
|
||||||
|
|
||||||
- [ ] Check 1
|
|
||||||
- [ ] Check 2
|
|
||||||
- [ ] ...
|
|
||||||
- [ ] Check n
|
|
||||||
|
|
||||||
...
|
|
||||||
|
|
||||||
## {Section Bar}
|
|
||||||
|
|
||||||
- [ ] Check 1
|
|
||||||
- [ ] Check 2
|
|
||||||
- [ ] ...
|
|
||||||
- [ ] Check n
|
|
||||||
|
|
||||||
## Final Validation
|
|
||||||
|
|
||||||
- [ ] Section Foo
|
|
||||||
- Issue List
|
|
||||||
- [ ] Section Bar
|
|
||||||
- Issue List
|
|
||||||
|
|
@ -1,15 +0,0 @@
|
||||||
# PRD Workflow Instructions
|
|
||||||
|
|
||||||
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
|
|
||||||
<critical>You MUST have already loaded and processed: {project-related}/{bmad_folder}/{module-code}/workflows/{workflow}/workflow.yaml</critical>
|
|
||||||
<critical>Communicate in {communication_language} throughout the workflow process</critical>
|
|
||||||
|
|
||||||
<!-- For planning/analysis workflows, add: <critical>⚠️ ABSOLUTELY NO TIME ESTIMATES - NEVER mention hours, days, weeks, months, or ANY time-based predictions. AI has fundamentally changed development speed - what once took teams weeks/months can now be done by one person in hours. DO NOT give ANY time estimates whatsoever.</critical> -->
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="1" goal="">
|
|
||||||
...
|
|
||||||
</step>
|
|
||||||
...
|
|
||||||
</workflow>
|
|
||||||
|
|
@ -1,9 +0,0 @@
|
||||||
# Title
|
|
||||||
|
|
||||||
**Date:** {{date}}
|
|
||||||
|
|
||||||
## {Section 1}
|
|
||||||
|
|
||||||
{{section_1_results}}
|
|
||||||
|
|
||||||
etc...
|
|
||||||
|
|
@ -1,61 +0,0 @@
|
||||||
# {TITLE} Workflow Template Configuration
|
|
||||||
name: "{WORKFLOW_CODE}"
|
|
||||||
description: "{WORKFLOW_DESCRIPTION}"
|
|
||||||
author: "BMad"
|
|
||||||
|
|
||||||
# Critical variables load from config_source
|
|
||||||
# Add Additional Config Pulled Variables Here
|
|
||||||
config_source: "{project-root}/{module-code}/config.yaml"
|
|
||||||
output_folder: "{config_source}:output_folder"
|
|
||||||
user_name: "{config_source}:user_name"
|
|
||||||
communication_language: "{config_source}:communication_language"
|
|
||||||
date: system-generated
|
|
||||||
|
|
||||||
# Required Data Files - HALT if missing!
|
|
||||||
# optional, can be omitted
|
|
||||||
brain_techniques: "{installed_path}/{critical-data-file.csv}" # example, can be other formats or URLs
|
|
||||||
|
|
||||||
# Module path and component files
|
|
||||||
installed_path: "{project-root}/{bmad_folder}/{module-code}/workflows/{workflow-code}"
|
|
||||||
template: "{installed_path}/template.md" # optional, can be omitted
|
|
||||||
instructions: "{installed_path}/instructions.md" # optional, can be omitted
|
|
||||||
validation: "{installed_path}/checklist.md" # optional, can be omitted
|
|
||||||
|
|
||||||
# Output configuration
|
|
||||||
default_output_file: "{output_folder}/{file.md}" # optional, can be omitted
|
|
||||||
validation_output_file: "{output_folder}/{file-validation-report.md}" # optional, can be omitted
|
|
||||||
|
|
||||||
# Tool Requirements (MCP Required Tools or other tools needed to run this workflow)
|
|
||||||
required_tools: #optional, can be omitted
|
|
||||||
- "Tool Name": #example, can be omitted if none
|
|
||||||
description: "Description of why this tool is needed"
|
|
||||||
link: "https://link-to-tool.com"
|
|
||||||
|
|
||||||
# Web Bundle Configuration (optional - for web-deployable workflows)
|
|
||||||
# IMPORTANT: Web bundles are self-contained and cannot use config_source variables
|
|
||||||
# All referenced files must be listed in web_bundle_files
|
|
||||||
web_bundle: #optional, can be omitted
|
|
||||||
name: "{WORKFLOW_CODE}"
|
|
||||||
description: "{WORKFLOW_DESCRIPTION}"
|
|
||||||
author: "BMad"
|
|
||||||
|
|
||||||
# Core workflow files (paths relative to {bmad_folder}/ root)
|
|
||||||
instructions: "{bmad_folder}/{module-code}/workflows/{workflow-code}/instructions.md"
|
|
||||||
validation: "{bmad_folder}/{module-code}/workflows/{workflow-code}/checklist.md"
|
|
||||||
template: "{bmad_folder}/{module-code}/workflows/{workflow-code}/template.md" # if document workflow
|
|
||||||
|
|
||||||
# Reference any data files or additional workflows (no config_source allowed)
|
|
||||||
# brain_techniques: "{bmad_folder}/{module-code}/workflows/{workflow-code}/data-file.csv"
|
|
||||||
# sub_workflow: "{bmad_folder}/{module-code}/workflows/other-workflow/workflow.yaml"
|
|
||||||
|
|
||||||
# CRITICAL: List ALL files used by this workflow
|
|
||||||
# This includes instructions, validation, templates, data files,
|
|
||||||
# and any files referenced within those files
|
|
||||||
web_bundle_files:
|
|
||||||
- "{bmad_folder}/{module-code}/workflows/{workflow-code}/instructions.md"
|
|
||||||
- "{bmad_folder}/{module-code}/workflows/{workflow-code}/checklist.md"
|
|
||||||
- "{bmad_folder}/{module-code}/workflows/{workflow-code}/template.md"
|
|
||||||
# Add ALL referenced files here - examine instructions.md and template.md
|
|
||||||
# for any file paths and include them all
|
|
||||||
# - "{bmad_folder}/{module-code}/workflows/{workflow-code}/data/example.csv"
|
|
||||||
# - "{bmad_folder}/{module-code}/templates/shared-template.md"
|
|
||||||
|
|
@ -1,41 +0,0 @@
|
||||||
# Build Workflow - Workflow Builder Configuration
|
|
||||||
name: create-workflow
|
|
||||||
description: "Interactive workflow builder that guides creation of new BMAD workflows with proper structure and validation for optimal human-AI collaboration. Includes optional brainstorming phase for workflow ideas and design."
|
|
||||||
author: "BMad Builder"
|
|
||||||
|
|
||||||
# Critical variables
|
|
||||||
config_source: "{project-root}/{bmad_folder}/bmb/config.yaml"
|
|
||||||
custom_workflow_location: "{config_source}:custom_workflow_location"
|
|
||||||
user_name: "{config_source}:user_name"
|
|
||||||
communication_language: "{config_source}:communication_language"
|
|
||||||
|
|
||||||
# Template files for new workflows
|
|
||||||
template_workflow_yaml: "{workflow_template_path}/workflow.yaml"
|
|
||||||
template_instructions: "{workflow_template_path}/instructions.md"
|
|
||||||
template_template: "{workflow_template_path}/template.md"
|
|
||||||
template_checklist: "{workflow_template_path}/checklist.md"
|
|
||||||
|
|
||||||
# Module path and component files
|
|
||||||
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/create-workflow"
|
|
||||||
template: false # This is an action workflow - no template needed
|
|
||||||
instructions: "{installed_path}/instructions.md"
|
|
||||||
validation: "{installed_path}/checklist.md"
|
|
||||||
|
|
||||||
# Required data files - CRITICAL for workflow conventions
|
|
||||||
workflow_creation_guide: "{installed_path}/workflow-creation-guide.md"
|
|
||||||
workflow_template_path: "{installed_path}/workflow-template"
|
|
||||||
|
|
||||||
# Reference examples - for learning patterns
|
|
||||||
existing_workflows_dir: "{project-root}/{bmad_folder}/*/workflows/"
|
|
||||||
bmm_workflows_dir: "{project-root}/{bmad_folder}/bmm/workflows/"
|
|
||||||
|
|
||||||
# Output configuration - Creates the new workflow folder with all files
|
|
||||||
# If workflow belongs to a module: Save to module's workflows folder
|
|
||||||
# If standalone workflow: Save to custom_workflow_location/{{workflow_name}}
|
|
||||||
module_output_folder: "{project-root}/{bmad_folder}/{{target_module}}/workflows/{{workflow_name}}"
|
|
||||||
standalone_output_folder: "{custom_workflow_location}/{{workflow_name}}"
|
|
||||||
|
|
||||||
standalone: true
|
|
||||||
|
|
||||||
# Web bundle configuration
|
|
||||||
web_bundle: false # BMB workflows run locally in BMAD-METHOD project
|
|
||||||
|
|
@ -1,239 +0,0 @@
|
||||||
# Edit Agent Workflow
|
|
||||||
|
|
||||||
Interactive workflow for editing existing BMAD agents while maintaining best practices and modern standards.
|
|
||||||
|
|
||||||
## Purpose
|
|
||||||
|
|
||||||
This workflow helps you refine and improve existing agents by:
|
|
||||||
|
|
||||||
- Analyzing agents against BMAD best practices
|
|
||||||
- **Fixing persona field separation issues** (the #1 quality problem)
|
|
||||||
- Identifying issues and improvement opportunities
|
|
||||||
- Providing guided editing for specific aspects
|
|
||||||
- Validating changes against agent standards
|
|
||||||
- Ensuring consistency with modern agent architecture (Simple/Expert/Module)
|
|
||||||
- Migrating from legacy patterns (full/hybrid/standalone)
|
|
||||||
|
|
||||||
## When to Use
|
|
||||||
|
|
||||||
Use this workflow when you need to:
|
|
||||||
|
|
||||||
- **Fix persona field separation** (communication_style has behaviors mixed in)
|
|
||||||
- Fix issues in existing agents (broken paths, invalid references)
|
|
||||||
- Add new menu items or workflows
|
|
||||||
- Improve agent persona or communication style
|
|
||||||
- Update configuration handling
|
|
||||||
- Migrate from legacy terminology (full/hybrid/standalone → Simple/Expert/Module)
|
|
||||||
- Convert between agent types
|
|
||||||
- Optimize agent structure and clarity
|
|
||||||
- Update legacy agents to modern BMAD standards
|
|
||||||
|
|
||||||
## What You'll Need
|
|
||||||
|
|
||||||
- Path to the agent file or folder you want to edit:
|
|
||||||
- Simple agent: path to .agent.yaml file
|
|
||||||
- Expert agent: path to folder containing .agent.yaml and sidecar files
|
|
||||||
- Understanding of what changes you want to make (or let the workflow analyze and suggest)
|
|
||||||
- Access to the agent documentation (loaded automatically)
|
|
||||||
|
|
||||||
## Workflow Steps
|
|
||||||
|
|
||||||
1. **Load and analyze target agent** - Provide path to agent file
|
|
||||||
2. **Discover improvement goals collaboratively** - Discuss what needs improvement and why
|
|
||||||
3. **Facilitate improvements iteratively** - Make changes collaboratively with approval
|
|
||||||
4. **Validate all changes holistically** - Comprehensive validation checklist
|
|
||||||
5. **Review improvements and guide next steps** - Summary and guidance
|
|
||||||
|
|
||||||
## Common Editing Scenarios
|
|
||||||
|
|
||||||
The workflow handles these common improvement needs:
|
|
||||||
|
|
||||||
1. **Fix persona field separation** - Extract behaviors from communication_style to principles (MOST COMMON)
|
|
||||||
2. **Fix critical issues** - Address broken references, syntax errors
|
|
||||||
3. **Edit sidecar files** - Update templates, knowledge bases, docs (Expert agents)
|
|
||||||
4. **Add/fix standard config** - Ensure config loading and variable usage
|
|
||||||
5. **Refine persona** - Improve role, identity, communication style, principles
|
|
||||||
6. **Update activation** - Modify activation steps and greeting
|
|
||||||
7. **Manage menu items** - Add, remove, or reorganize commands
|
|
||||||
8. **Update workflow references** - Fix paths, add new workflows
|
|
||||||
9. **Enhance menu handlers** - Improve handler logic
|
|
||||||
10. **Improve command triggers** - Refine asterisk commands
|
|
||||||
11. **Migrate agent type** - Convert from legacy full/hybrid/standalone to Simple/Expert/Module
|
|
||||||
12. **Add new capabilities** - Add menu items, workflows, features
|
|
||||||
13. **Remove bloat** - Delete unused commands, redundant instructions, orphaned sidecar files
|
|
||||||
14. **Full review and update** - Comprehensive improvements
|
|
||||||
|
|
||||||
**Most agents need persona field separation fixes** - this is the #1 quality issue found in legacy agents.
|
|
||||||
|
|
||||||
## Agent Documentation Loaded
|
|
||||||
|
|
||||||
This workflow automatically loads comprehensive agent documentation:
|
|
||||||
|
|
||||||
**Core Concepts:**
|
|
||||||
|
|
||||||
- **Understanding Agent Types** - Simple, Expert, Module distinctions (architecture, not capability)
|
|
||||||
- **Agent Compilation** - How YAML compiles to XML and what auto-injects
|
|
||||||
|
|
||||||
**Architecture Guides:**
|
|
||||||
|
|
||||||
- **Simple Agent Architecture** - Self-contained agents (NOT capability-limited!)
|
|
||||||
- **Expert Agent Architecture** - Agents with sidecar files (templates, docs, knowledge)
|
|
||||||
- **Module Agent Architecture** - Ecosystem-integrated agents (design intent)
|
|
||||||
|
|
||||||
**Design Patterns:**
|
|
||||||
|
|
||||||
- **Agent Menu Patterns** - Menu handlers, command structure, workflow integration
|
|
||||||
- **Communication Presets** - 60 pure communication styles across 13 categories
|
|
||||||
- **Brainstorm Context** - Creative ideation for persona development
|
|
||||||
|
|
||||||
**Reference Implementations:**
|
|
||||||
|
|
||||||
- **commit-poet** (Simple) - Shows Simple agents can be powerful and sophisticated
|
|
||||||
- **journal-keeper** (Expert) - Shows sidecar structure with memories and patterns
|
|
||||||
- **security-engineer** (Module) - Shows design intent and ecosystem integration
|
|
||||||
- **All BMM agents** - Examples of distinct, memorable communication voices
|
|
||||||
|
|
||||||
**Workflow Execution Engine** - How agents execute workflows
|
|
||||||
|
|
||||||
## Critical: Persona Field Separation
|
|
||||||
|
|
||||||
**THE #1 ISSUE** in legacy agents is persona field separation. The workflow checks for this automatically.
|
|
||||||
|
|
||||||
### What Is Persona Field Separation?
|
|
||||||
|
|
||||||
Each persona field serves a specific purpose that the LLM uses when activating:
|
|
||||||
|
|
||||||
- **role** → "What knowledge, skills, and capabilities do I possess?"
|
|
||||||
- **identity** → "What background, experience, and context shape my responses?"
|
|
||||||
- **communication_style** → "What verbal patterns, word choice, quirks do I use?"
|
|
||||||
- **principles** → "What beliefs and philosophy drive my choices?"
|
|
||||||
|
|
||||||
### The Problem
|
|
||||||
|
|
||||||
Many agents have behaviors/role/identity mixed into communication_style:
|
|
||||||
|
|
||||||
**WRONG:**
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
communication_style: 'Experienced analyst who ensures all stakeholders are heard and uses systematic approaches'
|
|
||||||
```
|
|
||||||
|
|
||||||
**RIGHT:**
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
identity: 'Senior analyst with 8+ years connecting market insights to strategy'
|
|
||||||
communication_style: 'Treats analysis like a treasure hunt - excited by every clue, thrilled when patterns emerge'
|
|
||||||
principles:
|
|
||||||
- 'Ensure all stakeholder voices heard'
|
|
||||||
- 'Use systematic, structured approaches'
|
|
||||||
```
|
|
||||||
|
|
||||||
### Red Flag Words
|
|
||||||
|
|
||||||
If communication_style contains these words, it needs fixing:
|
|
||||||
|
|
||||||
- "ensures", "makes sure", "always", "never" → Behaviors (move to principles)
|
|
||||||
- "experienced", "expert who", "senior" → Identity (move to identity/role)
|
|
||||||
- "believes in", "focused on" → Philosophy (move to principles)
|
|
||||||
|
|
||||||
## Output
|
|
||||||
|
|
||||||
The workflow modifies your agent file in place, maintaining the original format (YAML). Changes are reviewed and approved by you before being applied.
|
|
||||||
|
|
||||||
## Best Practices
|
|
||||||
|
|
||||||
- **Start with analysis** - Let the workflow audit your agent first
|
|
||||||
- **Check persona field separation FIRST** - This is the #1 issue in legacy agents
|
|
||||||
- **Use reference agents as guides** - Compare against commit-poet, journal-keeper, BMM agents
|
|
||||||
- **Focus your edits** - Choose specific aspects to improve
|
|
||||||
- **Review each change** - Approve or modify proposed changes
|
|
||||||
- **Validate persona purity** - Communication_style should have ZERO red flag words
|
|
||||||
- **Validate thoroughly** - Use the validation step to catch all issues
|
|
||||||
- **Test after editing** - Invoke the edited agent to verify it works
|
|
||||||
|
|
||||||
## Tips
|
|
||||||
|
|
||||||
- **Most common fix needed:** Persona field separation - communication_style has behaviors/role mixed in
|
|
||||||
- If you're unsure what needs improvement, let the workflow analyze the agent first
|
|
||||||
- For quick fixes, tell the workflow specifically what needs fixing
|
|
||||||
- The workflow loads documentation automatically - you don't need to read it first
|
|
||||||
- You can make multiple rounds of edits in one session
|
|
||||||
- **Red flag words in communication_style:** "ensures", "makes sure", "experienced", "expert who", "believes in"
|
|
||||||
- Compare your agent's communication_style against the presets CSV - should be similarly pure
|
|
||||||
- Use the validation step to ensure you didn't miss anything
|
|
||||||
|
|
||||||
## Example Usage
|
|
||||||
|
|
||||||
**Scenario 1: Fix persona field separation (most common)**
|
|
||||||
|
|
||||||
```
|
|
||||||
User: Edit the analyst agent
|
|
||||||
Workflow: Loads agent → Analyzes → Finds communication_style has "ensures stakeholders heard"
|
|
||||||
→ Explains this is behavior, should be in principles
|
|
||||||
→ Extracts behaviors to principles
|
|
||||||
→ Crafts pure communication style: "Treats analysis like a treasure hunt"
|
|
||||||
→ Validates → Done
|
|
||||||
```
|
|
||||||
|
|
||||||
**Scenario 2: Add new workflow**
|
|
||||||
|
|
||||||
```
|
|
||||||
User: I want to add a new workflow to the PM agent
|
|
||||||
Workflow: Analyzes agent → User describes what workflow to add
|
|
||||||
→ Adds new menu item with workflow reference
|
|
||||||
→ Validates all paths resolve → Done
|
|
||||||
```
|
|
||||||
|
|
||||||
**Scenario 2b: Edit Expert agent sidecar files**
|
|
||||||
|
|
||||||
```
|
|
||||||
User: Edit the journal-keeper agent - I want to update the daily journal template
|
|
||||||
Workflow: Loads folder → Finds .agent.yaml + 3 sidecar templates + 1 knowledge file
|
|
||||||
→ Analyzes → Loads daily.md template
|
|
||||||
→ User describes changes to template
|
|
||||||
→ Updates daily.md, shows before/after
|
|
||||||
→ Validates menu item 'daily-journal' still references it correctly → Done
|
|
||||||
```
|
|
||||||
|
|
||||||
**Scenario 3: Migrate from legacy type**
|
|
||||||
|
|
||||||
```
|
|
||||||
User: This agent says it's a "full agent" - what does that mean now?
|
|
||||||
Workflow: Explains Simple/Expert/Module types
|
|
||||||
→ Identifies agent is actually Simple (single file)
|
|
||||||
→ Updates any legacy terminology in comments
|
|
||||||
→ Validates structure matches type → Done
|
|
||||||
```
|
|
||||||
|
|
||||||
## Related Workflows
|
|
||||||
|
|
||||||
- **create-agent** - Create new agents from scratch with proper field separation
|
|
||||||
- **edit-workflow** - Edit workflows referenced by agents
|
|
||||||
- **audit-workflow** - Audit workflows for compliance
|
|
||||||
|
|
||||||
## Activation
|
|
||||||
|
|
||||||
Invoke via BMad Builder agent:
|
|
||||||
|
|
||||||
```
|
|
||||||
/bmad:bmb:agents:bmad-builder
|
|
||||||
Then select: *edit-agent
|
|
||||||
```
|
|
||||||
|
|
||||||
Or directly via workflow.xml with this workflow config.
|
|
||||||
|
|
||||||
## Quality Standards
|
|
||||||
|
|
||||||
After editing with this workflow, your agent will meet these quality standards:
|
|
||||||
|
|
||||||
✓ Persona fields properly separated (communication_style is pure verbal patterns)
|
|
||||||
✓ Agent type matches structure (Simple/Expert/Module)
|
|
||||||
✓ All workflow paths resolve correctly
|
|
||||||
✓ Activation flow is robust
|
|
||||||
✓ Menu structure is clear and logical
|
|
||||||
✓ Handlers properly invoke workflows
|
|
||||||
✓ Config loading works correctly
|
|
||||||
✓ No legacy terminology (full/hybrid/standalone)
|
|
||||||
✓ Comparable quality to reference agents
|
|
||||||
|
|
||||||
This workflow ensures your agents meet the same high standards as the reference implementations and recently enhanced BMM agents.
|
|
||||||
|
|
@ -1,654 +0,0 @@
|
||||||
# Edit Agent - Agent Editor Instructions
|
|
||||||
|
|
||||||
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
|
|
||||||
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/edit-agent/workflow.yaml</critical>
|
|
||||||
<critical>This workflow uses ADAPTIVE FACILITATION - adjust your communication based on context and user needs</critical>
|
|
||||||
<critical>The goal is COLLABORATIVE IMPROVEMENT - work WITH the user, not FOR them</critical>
|
|
||||||
<critical>Communicate all responses in {communication_language}</critical>
|
|
||||||
|
|
||||||
<critical>Understanding Agent Persona Fields - ESSENTIAL for Editing Agents Correctly</critical>
|
|
||||||
|
|
||||||
When editing an agent, you MUST understand how the compiled agent LLM interprets persona fields. This is the #1 issue found in agent edits:
|
|
||||||
|
|
||||||
**The Four Persona Fields and LLM Interpretation:**
|
|
||||||
|
|
||||||
- **role** → LLM reads: "What knowledge, skills, and capabilities do I possess?"
|
|
||||||
Example: "Senior Software Engineer" or "Strategic Business Analyst + Requirements Expert"
|
|
||||||
|
|
||||||
- **identity** → LLM reads: "What background, experience, and context shape my responses?"
|
|
||||||
Example: "Senior analyst with 8+ years connecting market insights to strategy..."
|
|
||||||
|
|
||||||
- **communication_style** → LLM reads: "What verbal patterns, word choice, quirks, and phrasing do I use?"
|
|
||||||
Example: "Treats analysis like a treasure hunt - excited by every clue"
|
|
||||||
|
|
||||||
- **principles** → LLM reads: "What beliefs and operating philosophy drive my choices?"
|
|
||||||
Example: "Every business challenge has root causes. Ground findings in evidence."
|
|
||||||
|
|
||||||
**MOST COMMON EDITING MISTAKE - Behaviors Mixed Into Communication Style:**
|
|
||||||
|
|
||||||
BEFORE (incorrect - found in many legacy agents):
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
communication_style: 'Experienced analyst who uses systematic approaches and ensures all stakeholders are heard'
|
|
||||||
```
|
|
||||||
|
|
||||||
^ This MIXES identity (experienced analyst) + behavior (ensures stakeholders heard) into style!
|
|
||||||
|
|
||||||
AFTER (correct - persona fields properly separated):
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
identity: 'Senior analyst with 8+ years connecting insights to strategy'
|
|
||||||
communication_style: 'Systematic and probing. Structures findings hierarchically.'
|
|
||||||
principles:
|
|
||||||
- 'Ensure all stakeholder voices heard'
|
|
||||||
- 'Ground findings in evidence'
|
|
||||||
```
|
|
||||||
|
|
||||||
**How to Recognize When Communication Style Needs Fixing:**
|
|
||||||
|
|
||||||
Red flag words in communication_style indicate behaviors/role mixed in:
|
|
||||||
|
|
||||||
- "ensures", "makes sure", "always", "never" → These are behaviors (move to principles)
|
|
||||||
- "experienced", "expert who", "senior" → These are identity (move to identity field)
|
|
||||||
- "believes in", "focused on" → These are principles (move to principles array)
|
|
||||||
|
|
||||||
**Pure Communication Styles (from {communication_presets}):**
|
|
||||||
|
|
||||||
Notice these contain ZERO role/identity/principles - only HOW they talk:
|
|
||||||
|
|
||||||
- "Treats analysis like a treasure hunt - excited by every clue"
|
|
||||||
- "Ultra-succinct. Speaks in file paths and AC IDs - every statement citable"
|
|
||||||
- "Asks 'WHY?' relentlessly like a detective on a case"
|
|
||||||
- "Poetic drama and flair with every turn of a phrase"
|
|
||||||
|
|
||||||
Use {communication_presets} CSV and reference agents in {reference_agents} as your guide for pure communication styles.
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="1" goal="Load and deeply understand the target agent">
|
|
||||||
<ask>What is the path to the agent you want to edit?</ask>
|
|
||||||
|
|
||||||
<action>Detect agent type from provided path and load ALL relevant files:
|
|
||||||
|
|
||||||
**If path is a .agent.yaml file (Simple Agent):**
|
|
||||||
|
|
||||||
- Load the single YAML file
|
|
||||||
- Note: Simple agent, all content in one file
|
|
||||||
|
|
||||||
**If path is a folder (Expert Agent with sidecar files):**
|
|
||||||
|
|
||||||
- Load the .agent.yaml file from inside the folder
|
|
||||||
- Load ALL sidecar files in the folder:
|
|
||||||
- Templates (_.md, _.txt)
|
|
||||||
- Documentation files
|
|
||||||
- Knowledge base files (_.csv, _.json, \*.yaml)
|
|
||||||
- Any other resources referenced by the agent
|
|
||||||
- Create inventory of sidecar files for reference
|
|
||||||
- Note: Expert agent with sidecar structure
|
|
||||||
|
|
||||||
**If path is ambiguous:**
|
|
||||||
|
|
||||||
- Check if it's a folder containing .agent.yaml → Expert agent
|
|
||||||
- Check if it's a direct .agent.yaml path → Simple agent
|
|
||||||
- If neither, ask user to clarify
|
|
||||||
|
|
||||||
Present what was loaded:
|
|
||||||
|
|
||||||
- "Loaded [agent-name].agent.yaml"
|
|
||||||
- If Expert: "Plus 5 sidecar files: [list them]"
|
|
||||||
</action>
|
|
||||||
<action>Load ALL agent documentation to inform understanding:
|
|
||||||
|
|
||||||
**Core Concepts:**
|
|
||||||
|
|
||||||
- Understanding agent types: {understanding_agent_types}
|
|
||||||
- Agent compilation process: {agent_compilation}
|
|
||||||
|
|
||||||
**Architecture Guides:**
|
|
||||||
|
|
||||||
- Simple agent architecture: {simple_architecture}
|
|
||||||
- Expert agent architecture: {expert_architecture}
|
|
||||||
- Module agent architecture: {module_architecture}
|
|
||||||
|
|
||||||
**Design Patterns:**
|
|
||||||
|
|
||||||
- Menu patterns: {menu_patterns}
|
|
||||||
- Communication presets: {communication_presets}
|
|
||||||
- Brainstorm context: {brainstorm_context}
|
|
||||||
|
|
||||||
**Reference Agents:**
|
|
||||||
|
|
||||||
- Simple example: {reference_simple_agent}
|
|
||||||
- Expert example: {reference_expert_agent}
|
|
||||||
- Module examples: {reference_module_agents}
|
|
||||||
- BMM agents (distinct voices): {bmm_agents}
|
|
||||||
|
|
||||||
**Workflow execution engine:** {workflow_execution_engine}
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Analyze the agent structure thoroughly:
|
|
||||||
|
|
||||||
**Basic Structure:**
|
|
||||||
|
|
||||||
- Parse persona (role, identity, communication_style, principles)
|
|
||||||
- Understand activation flow and steps
|
|
||||||
- Map menu items and their workflows
|
|
||||||
- Identify configuration dependencies
|
|
||||||
- Assess agent type: Simple (single YAML), Expert (sidecar files), or Module (ecosystem integration)
|
|
||||||
- Check workflow references for validity
|
|
||||||
|
|
||||||
**If Expert Agent - Analyze Sidecar Files:**
|
|
||||||
|
|
||||||
- Map which menu items reference which sidecar files (tmpl="path", data="path")
|
|
||||||
- Check if all sidecar references in YAML actually exist
|
|
||||||
- Identify unused sidecar files (not referenced in YAML)
|
|
||||||
- Assess sidecar organization (are templates grouped logically?)
|
|
||||||
- Note any sidecar files that might need editing (outdated templates, old docs)
|
|
||||||
|
|
||||||
**CRITICAL - Persona Field Separation Analysis:**
|
|
||||||
|
|
||||||
- Check if communication_style contains ONLY verbal patterns
|
|
||||||
- Identify any behaviors mixed into communication_style (red flags: "ensures", "makes sure", "always")
|
|
||||||
- Identify any role/identity statements in communication_style (red flags: "experienced", "expert who", "senior")
|
|
||||||
- Identify any principles in communication_style (red flags: "believes in", "focused on")
|
|
||||||
- Compare communication_style against {communication_presets} for purity
|
|
||||||
- Compare against similar reference agents
|
|
||||||
|
|
||||||
**Evaluate against best practices from loaded guides**
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Reflect understanding back to {user_name}:
|
|
||||||
|
|
||||||
Present a warm, conversational summary adapted to the agent's complexity:
|
|
||||||
|
|
||||||
- What this agent does (its role and purpose)
|
|
||||||
- How it's structured (Simple/Expert/Module type, menu items, workflows)
|
|
||||||
- **If Expert agent:** Describe the sidecar structure warmly:
|
|
||||||
- "This is an Expert agent with a nice sidecar structure - I see 3 templates, 2 knowledge files, and a README"
|
|
||||||
- Mention what the sidecar files are for (if clear from names/content)
|
|
||||||
- Note any sidecar issues (broken references, unused files)
|
|
||||||
- **If persona field separation issues found:** Gently point out that communication_style has behaviors/role mixed in - explain this is common and fixable
|
|
||||||
- What you notice (strengths, potential improvements, issues)
|
|
||||||
- Your initial assessment of its health
|
|
||||||
|
|
||||||
Be conversational, not clinical. Help {user_name} see their agent through your eyes.
|
|
||||||
|
|
||||||
Example of mentioning persona issues warmly:
|
|
||||||
"I notice the communication_style has some behaviors mixed in (like 'ensures stakeholders are heard'). This is super common - we can easily extract those to principles to make the persona clearer. The agent's core purpose is solid though!"
|
|
||||||
|
|
||||||
Example of mentioning Expert agent sidecar structure:
|
|
||||||
"This is beautifully organized as an Expert agent! The sidecar files include 3 journal templates (daily, weekly, breakthrough) and a mood-patterns knowledge file. Your menu items reference them nicely. I do notice 'old-template.md' isn't referenced anywhere - we could clean that up."
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>Does this match your understanding of what this agent should do?</ask>
|
|
||||||
<template-output>agent_understanding</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Discover improvement goals collaboratively">
|
|
||||||
<critical>Understand WHAT the user wants to improve and WHY before diving into edits</critical>
|
|
||||||
|
|
||||||
<action>Engage in collaborative discovery:
|
|
||||||
|
|
||||||
Ask open-ended questions to understand their goals:
|
|
||||||
|
|
||||||
- What prompted you to want to edit this agent?
|
|
||||||
- What isn't working the way you'd like?
|
|
||||||
- Are there specific behaviors you want to change?
|
|
||||||
- Is there functionality you want to add or remove?
|
|
||||||
- How do users interact with this agent? What feedback have they given?
|
|
||||||
|
|
||||||
Listen for clues about:
|
|
||||||
|
|
||||||
- **Persona field separation issues** (communication_style contains behaviors/role/principles)
|
|
||||||
- Functional issues (broken references, missing workflows)
|
|
||||||
- **Sidecar file issues** (for Expert agents: outdated templates, unused files, missing references)
|
|
||||||
- User experience issues (confusing menu, unclear communication)
|
|
||||||
- Performance issues (too slow, too verbose, not adaptive enough)
|
|
||||||
- Maintenance issues (hard to update, bloated, inconsistent)
|
|
||||||
- Integration issues (doesn't work well with other agents/workflows)
|
|
||||||
- **Legacy pattern issues** (using old "full/hybrid/standalone" terminology, outdated structures)
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Based on their responses and your analysis from step 1, identify improvement opportunities:
|
|
||||||
|
|
||||||
Organize by priority and user goals:
|
|
||||||
|
|
||||||
- **CRITICAL issues blocking functionality** (broken paths, invalid references)
|
|
||||||
- **PERSONA FIELD SEPARATION** (if found - this significantly improves LLM interpretation)
|
|
||||||
- **IMPORTANT improvements enhancing user experience** (menu clarity, better workflows)
|
|
||||||
- **NICE-TO-HAVE enhancements for polish** (better triggers, communication refinement)
|
|
||||||
|
|
||||||
Present these conversationally, explaining WHY each matters and HOW it would help.
|
|
||||||
|
|
||||||
If persona field separation issues found, explain the impact:
|
|
||||||
"I found some behaviors in the communication_style field. When we separate these properly, the LLM will have much clearer understanding of the persona. Right now it's trying to interpret 'ensures stakeholders heard' as a verbal pattern, when it's actually an operating principle. Fixing this makes the agent more consistent and predictable."
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Collaborate on priorities:
|
|
||||||
|
|
||||||
Don't just list options - discuss them:
|
|
||||||
|
|
||||||
- "I noticed {{issue}} - this could cause {{problem}}. Does this concern you?"
|
|
||||||
- "The agent could be more {{improvement}} which would help when {{use_case}}. Worth exploring?"
|
|
||||||
- "Based on what you said about {{user_goal}}, we might want to {{suggestion}}. Thoughts?"
|
|
||||||
|
|
||||||
Let the conversation flow naturally. Build a shared vision of what "better" looks like.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<template-output>improvement_goals</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Facilitate improvements collaboratively" repeat="until-user-satisfied">
|
|
||||||
<critical>Work iteratively - improve, review, refine. Never dump all changes at once.</critical>
|
|
||||||
|
|
||||||
<action>For each improvement area, facilitate collaboratively:
|
|
||||||
|
|
||||||
1. **Explain the current state and why it matters**
|
|
||||||
- Show relevant sections of the agent
|
|
||||||
- Explain how it works now and implications
|
|
||||||
- Connect to user's goals from step 2
|
|
||||||
|
|
||||||
2. **Propose improvements with rationale**
|
|
||||||
- Suggest specific changes that align with best practices
|
|
||||||
- Explain WHY each change helps
|
|
||||||
- Provide examples from the loaded guides when helpful
|
|
||||||
- Show before/after comparisons for clarity
|
|
||||||
|
|
||||||
3. **Collaborate on the approach**
|
|
||||||
- Ask if the proposed change addresses their need
|
|
||||||
- Invite modifications or alternative approaches
|
|
||||||
- Explain tradeoffs when relevant
|
|
||||||
- Adapt based on their feedback
|
|
||||||
|
|
||||||
4. **Apply changes iteratively**
|
|
||||||
- Make one focused improvement at a time
|
|
||||||
- Show the updated section
|
|
||||||
- Confirm it meets their expectation
|
|
||||||
- Move to next improvement or refine current one
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Common improvement patterns to facilitate:
|
|
||||||
|
|
||||||
**If fixing broken references:**
|
|
||||||
|
|
||||||
- Identify all broken paths (workflow paths, sidecar file references)
|
|
||||||
- Explain what each reference should point to
|
|
||||||
- Verify new paths exist before updating
|
|
||||||
- **For Expert agents:** Check both YAML references AND actual sidecar file existence
|
|
||||||
- Update and confirm working
|
|
||||||
|
|
||||||
**If editing sidecar files (Expert agents only):**
|
|
||||||
|
|
||||||
<critical>Sidecar files are as much a part of the agent as the YAML!</critical>
|
|
||||||
|
|
||||||
Common sidecar editing scenarios:
|
|
||||||
|
|
||||||
**Updating templates:**
|
|
||||||
|
|
||||||
- Read current template content
|
|
||||||
- Discuss what needs to change with user
|
|
||||||
- Show before/after of template updates
|
|
||||||
- Verify menu item references still work
|
|
||||||
- Test template variables resolve correctly
|
|
||||||
|
|
||||||
**Adding new sidecar files:**
|
|
||||||
|
|
||||||
- Create the new file (template, doc, knowledge base)
|
|
||||||
- Add menu item in YAML that references it (tmpl="path/to/new-file.md")
|
|
||||||
- Verify the reference path is correct
|
|
||||||
- Test the menu item loads the sidecar file
|
|
||||||
|
|
||||||
**Removing unused sidecar files:**
|
|
||||||
|
|
||||||
- Confirm file is truly unused (not referenced in YAML)
|
|
||||||
- Ask user if safe to delete (might be there for future use)
|
|
||||||
- Delete file if approved
|
|
||||||
- Clean up any stale references
|
|
||||||
|
|
||||||
**Reorganizing sidecar structure:**
|
|
||||||
|
|
||||||
- Discuss better organization (e.g., group templates in subfolder)
|
|
||||||
- Move files to new locations
|
|
||||||
- Update ALL references in YAML to new paths
|
|
||||||
- Verify all menu items still work
|
|
||||||
|
|
||||||
**Updating knowledge base files (.csv, .json, .yaml in sidecar):**
|
|
||||||
|
|
||||||
- Understand what knowledge the file contains
|
|
||||||
- Discuss what needs updating
|
|
||||||
- Edit the knowledge file directly
|
|
||||||
- Verify format is still valid
|
|
||||||
- No YAML changes needed (data file just gets loaded)
|
|
||||||
|
|
||||||
**If refining persona/communication (MOST COMMON IMPROVEMENT NEEDED):**
|
|
||||||
|
|
||||||
<critical>Persona field separation is the #1 quality issue. Follow this pattern EXACTLY:</critical>
|
|
||||||
|
|
||||||
**Step 1: Diagnose Current Communication Style**
|
|
||||||
|
|
||||||
- Read current communication_style field word by word
|
|
||||||
- Identify ANY content that isn't pure verbal patterns
|
|
||||||
- Use red flag words as detection:
|
|
||||||
- "ensures", "makes sure", "always", "never" → Behaviors (belongs in principles)
|
|
||||||
- "experienced", "expert who", "senior", "seasoned" → Identity descriptors (belongs in role/identity)
|
|
||||||
- "believes in", "focused on", "committed to" → Philosophy (belongs in principles)
|
|
||||||
- "who does X", "that does Y" → Behavioral descriptions (belongs in role or principles)
|
|
||||||
|
|
||||||
Example diagnosis:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# CURRENT (problematic)
|
|
||||||
communication_style: 'Experienced analyst who uses systematic approaches and ensures all stakeholders are heard'
|
|
||||||
# IDENTIFIED ISSUES:
|
|
||||||
# - "Experienced analyst" → identity descriptor
|
|
||||||
# - "who uses systematic approaches" → behavioral description
|
|
||||||
# - "ensures all stakeholders are heard" → operating principle
|
|
||||||
# ONLY THIS IS STYLE: [nothing! Need to find the actual verbal pattern]
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 2: Extract Non-Style Content to Proper Fields**
|
|
||||||
|
|
||||||
- Create a working copy with sections:
|
|
||||||
- ROLE (capabilities/skills)
|
|
||||||
- IDENTITY (background/context)
|
|
||||||
- PURE STYLE (verbal patterns only)
|
|
||||||
- PRINCIPLES (beliefs/behaviors)
|
|
||||||
|
|
||||||
- Move identified content to proper sections:
|
|
||||||
```yaml
|
|
||||||
# ROLE: "Strategic analyst"
|
|
||||||
# IDENTITY: "Experienced analyst who uses systematic approaches"
|
|
||||||
# PURE STYLE: [need to discover - interview user about HOW they talk]
|
|
||||||
# PRINCIPLES:
|
|
||||||
# - "Ensure all stakeholder voices heard"
|
|
||||||
# - "Use systematic, structured approaches"
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 3: Discover the TRUE Communication Style**
|
|
||||||
Since style was buried under behaviors, interview the user:
|
|
||||||
|
|
||||||
- "How should this agent SOUND when talking?"
|
|
||||||
- "What verbal quirks or patterns make them distinctive?"
|
|
||||||
- "Are they formal? Casual? Energetic? Measured?"
|
|
||||||
- "Any metaphors or imagery that capture their voice?"
|
|
||||||
|
|
||||||
Then explore {communication_presets} together:
|
|
||||||
|
|
||||||
- Show relevant categories (Professional, Creative, Analytical, etc.)
|
|
||||||
- Read examples of pure styles
|
|
||||||
- Discuss which resonates with agent's essence
|
|
||||||
|
|
||||||
**Step 4: Craft Pure Communication Style**
|
|
||||||
Write 1-2 sentences focused ONLY on verbal patterns:
|
|
||||||
|
|
||||||
Good examples from reference agents:
|
|
||||||
|
|
||||||
- "Treats analysis like a treasure hunt - excited by every clue, thrilled when patterns emerge" (Mary/analyst)
|
|
||||||
- "Ultra-succinct. Speaks in file paths and AC IDs - every statement citable" (Amelia/dev)
|
|
||||||
- "Asks 'WHY?' relentlessly like a detective on a case" (John/pm)
|
|
||||||
- "Poetic drama and flair with every turn of a phrase" (commit-poet)
|
|
||||||
|
|
||||||
Bad example (what we're fixing):
|
|
||||||
|
|
||||||
- "Experienced who ensures quality and uses best practices" ← ALL behaviors, NO style!
|
|
||||||
|
|
||||||
**Step 5: Show Before/After With Full Context**
|
|
||||||
Present the complete transformation:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# BEFORE
|
|
||||||
persona:
|
|
||||||
role: "Analyst"
|
|
||||||
communication_style: "Experienced analyst who uses systematic approaches and ensures all stakeholders are heard"
|
|
||||||
|
|
||||||
# AFTER
|
|
||||||
persona:
|
|
||||||
role: "Strategic Business Analyst + Requirements Expert"
|
|
||||||
identity: "Senior analyst with 8+ years connecting market insights to strategy and translating complex problems into clear requirements"
|
|
||||||
communication_style: "Treats analysis like a treasure hunt - excited by every clue, thrilled when patterns emerge. Asks questions that spark 'aha!' moments."
|
|
||||||
principles:
|
|
||||||
- "Ensure all stakeholder voices heard"
|
|
||||||
- "Use systematic, structured approaches to analysis"
|
|
||||||
- "Ground findings in evidence, not assumptions"
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step 6: Validate Against Standards**
|
|
||||||
|
|
||||||
- Communication style has ZERO red flag words
|
|
||||||
- Communication style describes HOW they talk, not WHAT they do
|
|
||||||
- Compare against {communication_presets} - similarly pure?
|
|
||||||
- Compare against reference agents - similar quality?
|
|
||||||
- Read it aloud - does it sound like a voice description?
|
|
||||||
|
|
||||||
**Step 7: Confirm With User**
|
|
||||||
|
|
||||||
- Explain WHAT changed and WHY each move happened
|
|
||||||
- Read the new communication style dramatically to demonstrate the voice
|
|
||||||
- Ask: "Does this capture how you want them to sound?"
|
|
||||||
- Refine based on feedback
|
|
||||||
|
|
||||||
**If updating activation:**
|
|
||||||
|
|
||||||
- Walk through current activation flow
|
|
||||||
- Identify bottlenecks or confusion points
|
|
||||||
- Propose streamlined flow
|
|
||||||
- Ensure config loading works correctly
|
|
||||||
- Verify all session variables are set
|
|
||||||
|
|
||||||
**If managing menu items:**
|
|
||||||
|
|
||||||
- Review current menu organization
|
|
||||||
- Discuss if structure serves user mental model
|
|
||||||
- Add/remove/reorganize as needed
|
|
||||||
- Ensure all workflow references are valid
|
|
||||||
- Update triggers to be intuitive
|
|
||||||
|
|
||||||
**If enhancing menu handlers:**
|
|
||||||
|
|
||||||
- Explain current handler logic
|
|
||||||
- Identify where handlers could be smarter
|
|
||||||
- Propose enhanced logic based on agent architecture patterns
|
|
||||||
- Ensure handlers properly invoke workflows
|
|
||||||
|
|
||||||
**If optimizing agent type or migrating from legacy terminology:**
|
|
||||||
|
|
||||||
<critical>Legacy agents may use outdated "full/hybrid/standalone" terminology. Migrate to Simple/Expert/Module:</critical>
|
|
||||||
|
|
||||||
**Understanding the Modern Types:**
|
|
||||||
|
|
||||||
- **Simple** = Self-contained in single .agent.yaml file
|
|
||||||
- NOT capability-limited! Can be as powerful as any agent
|
|
||||||
- Architecture choice: everything in one file
|
|
||||||
- Example: commit-poet (reference_simple_agent)
|
|
||||||
|
|
||||||
- **Expert** = Includes sidecar files (templates, docs, knowledge bases)
|
|
||||||
- Folder structure with .agent.yaml + additional files
|
|
||||||
- Sidecar files referenced in menu items or prompts
|
|
||||||
- Example: journal-keeper (reference_expert_agent)
|
|
||||||
|
|
||||||
- **Module** = Designed for BMAD ecosystem integration
|
|
||||||
- Integrated with specific module workflows (BMM, BMGD, CIS, etc.)
|
|
||||||
- Coordinates with other module agents
|
|
||||||
- Included in module's default bundle
|
|
||||||
- This is design INTENT, not capability limitation
|
|
||||||
- Examples: security-engineer, dev, analyst (reference_module_agents)
|
|
||||||
|
|
||||||
**Migration Pattern from Legacy Types:**
|
|
||||||
|
|
||||||
If agent uses "full/hybrid/standalone" terminology:
|
|
||||||
|
|
||||||
1. **Identify current structure:**
|
|
||||||
- Single file? → Probably Simple
|
|
||||||
- Has sidecar files? → Probably Expert
|
|
||||||
- Part of module ecosystem? → Probably Module
|
|
||||||
- Multiple could apply? → Choose based on PRIMARY characteristic
|
|
||||||
|
|
||||||
2. **Update any references in comments/docs:**
|
|
||||||
- Change "full agent" → Simple or Module (depending on context)
|
|
||||||
- Change "hybrid agent" → Usually Simple or Expert
|
|
||||||
- Change "standalone agent" → Usually Simple
|
|
||||||
|
|
||||||
3. **Verify type choice:**
|
|
||||||
- Read {understanding_agent_types} together
|
|
||||||
- Compare against reference agents
|
|
||||||
- Confirm structure matches chosen type
|
|
||||||
|
|
||||||
4. **Update validation checklist expectations** based on new type
|
|
||||||
|
|
||||||
**If genuinely converting between types:**
|
|
||||||
|
|
||||||
Simple → Expert (adding sidecar files):
|
|
||||||
|
|
||||||
- Create folder with agent name
|
|
||||||
- Move .agent.yaml into folder
|
|
||||||
- Add sidecar files (templates, docs, etc.)
|
|
||||||
- Update menu items to reference sidecar files
|
|
||||||
- Test all references work
|
|
||||||
|
|
||||||
Expert → Simple (consolidating):
|
|
||||||
|
|
||||||
- Inline sidecar content into YAML (or remove if unused)
|
|
||||||
- Move .agent.yaml out of folder
|
|
||||||
- Update any menu references
|
|
||||||
- Delete sidecar folder after verification
|
|
||||||
|
|
||||||
Module ↔ Others:
|
|
||||||
|
|
||||||
- Module is about design intent, not structure
|
|
||||||
- Can be Simple OR Expert structurally
|
|
||||||
- Change is about integration ecosystem, not file structure
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Throughout improvements, educate when helpful:
|
|
||||||
|
|
||||||
Share insights from the guides naturally:
|
|
||||||
|
|
||||||
- "The agent architecture guide suggests {{pattern}} for this scenario"
|
|
||||||
- "Looking at the command patterns, we could use {{approach}}"
|
|
||||||
- "The communication styles guide has a great example of {{technique}}"
|
|
||||||
|
|
||||||
Connect improvements to broader BMAD principles without being preachy.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>After each significant change:
|
|
||||||
|
|
||||||
- "Does this feel right for what you're trying to achieve?"
|
|
||||||
- "Want to refine this further, or move to the next improvement?"
|
|
||||||
- "Is there anything about this change that concerns you?"
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
<template-output>improvement_implementation</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Validate improvements holistically">
|
|
||||||
<action>Run comprehensive validation conversationally:
|
|
||||||
|
|
||||||
Don't just check boxes - explain what you're validating and why it matters:
|
|
||||||
|
|
||||||
- "Let me verify all the workflow paths resolve correctly..."
|
|
||||||
- **"If Expert agent: Checking all sidecar file references..."**
|
|
||||||
- "Checking that the activation flow works smoothly..."
|
|
||||||
- "Making sure menu handlers are wired up properly..."
|
|
||||||
- "Validating config loading is robust..."
|
|
||||||
- **"CRITICAL: Checking persona field separation - ensuring communication_style is pure..."**
|
|
||||||
|
|
||||||
**For Expert Agents - Sidecar File Validation:**
|
|
||||||
|
|
||||||
Walk through each sidecar reference:
|
|
||||||
|
|
||||||
- "Your menu item 'daily-journal' references 'templates/daily.md'... checking... ✓ exists!"
|
|
||||||
- "Menu item 'breakthrough' references 'templates/breakthrough.md'... checking... ✓ exists!"
|
|
||||||
- Check for orphaned sidecar files not referenced anywhere
|
|
||||||
- If found: "I noticed 'old-template.md' isn't referenced in any menu items. Should we keep it?"
|
|
||||||
- Verify sidecar file formats (YAML is valid, CSV has headers, etc.)
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Load validation checklist: {validation}</action>
|
|
||||||
<action>Check all items from checklist systematically</action>
|
|
||||||
|
|
||||||
<note>The validation checklist is shared between create-agent and edit-agent workflows to ensure consistent quality standards. Any agent (whether newly created or edited) is validated against the same comprehensive criteria.</note>
|
|
||||||
|
|
||||||
<check if="validation_issues_found">
|
|
||||||
<action>Present issues conversationally:
|
|
||||||
|
|
||||||
Explain what's wrong and implications:
|
|
||||||
|
|
||||||
- "I found {{issue}} which could cause {{problem}}"
|
|
||||||
- "The {{component}} needs {{fix}} because {{reason}}"
|
|
||||||
|
|
||||||
Propose fixes immediately:
|
|
||||||
|
|
||||||
- "I can fix this by {{solution}}. Should I?"
|
|
||||||
- "We have a couple options here: {{option1}} or {{option2}}. Thoughts?"
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Fix approved issues and re-validate</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="validation_passes">
|
|
||||||
<action>Confirm success warmly:
|
|
||||||
|
|
||||||
"Excellent! Everything validates cleanly:
|
|
||||||
|
|
||||||
- ✓ Persona fields properly separated (communication_style is pure!)
|
|
||||||
- ✓ All paths resolve correctly
|
|
||||||
- ✓ **[If Expert agent: All sidecar file references valid - 5 sidecar files, all referenced correctly!]**
|
|
||||||
- ✓ Activation flow is solid
|
|
||||||
- ✓ Menu structure is clear
|
|
||||||
- ✓ Handlers work properly
|
|
||||||
- ✓ Config loading is robust
|
|
||||||
- ✓ Agent type matches structure (Simple/Expert/Module)
|
|
||||||
|
|
||||||
Your agent meets all BMAD quality standards. Great work!"
|
|
||||||
</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<template-output>validation_results</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5" goal="Review improvements and guide next steps">
|
|
||||||
<action>Create a conversational summary of what improved:
|
|
||||||
|
|
||||||
Tell the story of the transformation:
|
|
||||||
|
|
||||||
- "We started with {{initial_state}}"
|
|
||||||
- "You wanted to {{user_goals}}"
|
|
||||||
- "We made these key improvements: {{changes_list}}"
|
|
||||||
- "Now your agent {{improved_capabilities}}"
|
|
||||||
|
|
||||||
Highlight the impact:
|
|
||||||
|
|
||||||
- "This means users will experience {{benefit}}"
|
|
||||||
- "The agent is now more {{quality}}"
|
|
||||||
- "It follows best practices for {{patterns}}"
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Guide next steps based on changes made:
|
|
||||||
|
|
||||||
If significant structural changes:
|
|
||||||
|
|
||||||
- "Since we restructured the activation, you should test the agent with a real user interaction"
|
|
||||||
|
|
||||||
If workflow references changed:
|
|
||||||
|
|
||||||
- "The agent now uses {{new_workflows}} - make sure those workflows are up to date"
|
|
||||||
|
|
||||||
If this is part of larger module work:
|
|
||||||
|
|
||||||
- "This agent is part of {{module}} - consider if other agents need similar improvements"
|
|
||||||
|
|
||||||
Be a helpful guide to what comes next, not just a task completer.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>Would you like to:
|
|
||||||
|
|
||||||
- Test the edited agent by invoking it
|
|
||||||
- Edit another agent
|
|
||||||
- Make additional refinements to this one
|
|
||||||
- Return to your module work
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
<template-output>completion_summary</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
|
|
@ -1,49 +0,0 @@
|
||||||
# Edit Agent - Agent Editor Configuration
|
|
||||||
name: "edit-agent"
|
|
||||||
description: "Edit existing BMAD agents while following all best practices and conventions"
|
|
||||||
author: "BMad"
|
|
||||||
|
|
||||||
# Critical variables load from config_source
|
|
||||||
config_source: "{project-root}/{bmad_folder}/bmb/config.yaml"
|
|
||||||
communication_language: "{config_source}:communication_language"
|
|
||||||
user_name: "{config_source}:user_name"
|
|
||||||
|
|
||||||
# Required Data Files - Critical for understanding agent conventions
|
|
||||||
|
|
||||||
# Core Concepts
|
|
||||||
understanding_agent_types: "{project-root}/{bmad_folder}/bmb/docs/agents/understanding-agent-types.md"
|
|
||||||
agent_compilation: "{project-root}/{bmad_folder}/bmb/docs/agents/agent-compilation.md"
|
|
||||||
|
|
||||||
# Architecture Guides (Simple, Expert, Module)
|
|
||||||
simple_architecture: "{project-root}/{bmad_folder}/bmb/docs/agents/simple-agent-architecture.md"
|
|
||||||
expert_architecture: "{project-root}/{bmad_folder}/bmb/docs/agents/expert-agent-architecture.md"
|
|
||||||
module_architecture: "{project-root}/{bmad_folder}/bmb/docs/agents/module-agent-architecture.md"
|
|
||||||
|
|
||||||
# Design Patterns
|
|
||||||
menu_patterns: "{project-root}/{bmad_folder}/bmb/docs/agents/agent-menu-patterns.md"
|
|
||||||
communication_presets: "{project-root}/{bmad_folder}/bmb/workflows/create-agent/communication-presets.csv"
|
|
||||||
brainstorm_context: "{project-root}/{bmad_folder}/bmb/workflows/create-agent/brainstorm-context.md"
|
|
||||||
|
|
||||||
# Workflow execution engine reference
|
|
||||||
workflow_execution_engine: "{project-root}/{bmad_folder}/core/tasks/workflow.xml"
|
|
||||||
|
|
||||||
# Reference Agents - Clean implementations showing best practices
|
|
||||||
reference_agents: "{project-root}/{bmad_folder}/bmb/reference/agents/"
|
|
||||||
reference_simple_agent: "{reference_agents}/simple-examples/commit-poet.agent.yaml"
|
|
||||||
reference_expert_agent: "{reference_agents}/expert-examples/journal-keeper/journal-keeper.agent.yaml"
|
|
||||||
reference_module_agents: "{reference_agents}/module-examples/"
|
|
||||||
|
|
||||||
# BMM Agents - Examples of distinct communication voices
|
|
||||||
bmm_agents: "{project-root}/{bmad_folder}/bmm/agents/"
|
|
||||||
|
|
||||||
# Module path and component files
|
|
||||||
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/edit-agent"
|
|
||||||
template: false # This is an action workflow - no template needed
|
|
||||||
instructions: "{installed_path}/instructions.md"
|
|
||||||
# Shared validation checklist (canonical location in create-agent folder)
|
|
||||||
validation: "{project-root}/{bmad_folder}/bmb/workflows/create-agent/agent-validation-checklist.md"
|
|
||||||
|
|
||||||
standalone: true
|
|
||||||
|
|
||||||
# Web bundle configuration
|
|
||||||
web_bundle: false # BMB workflows run locally in BMAD-METHOD project
|
|
||||||
|
|
@ -1,119 +0,0 @@
|
||||||
# Edit Workflow
|
|
||||||
|
|
||||||
## Purpose
|
|
||||||
|
|
||||||
An intelligent workflow editor that helps you modify existing BMAD workflows while adhering to all best practices and conventions documented in the workflow creation guide.
|
|
||||||
|
|
||||||
## Use Case
|
|
||||||
|
|
||||||
When you need to:
|
|
||||||
|
|
||||||
- Fix issues in existing workflows
|
|
||||||
- Update workflow configuration or metadata
|
|
||||||
- Improve instruction clarity and specificity
|
|
||||||
- Add new features or capabilities
|
|
||||||
- Ensure compliance with BMAD workflow conventions
|
|
||||||
|
|
||||||
## How to Invoke
|
|
||||||
|
|
||||||
```
|
|
||||||
workflow edit-workflow
|
|
||||||
```
|
|
||||||
|
|
||||||
Or through a BMAD agent:
|
|
||||||
|
|
||||||
```
|
|
||||||
*edit-workflow
|
|
||||||
```
|
|
||||||
|
|
||||||
## Expected Inputs
|
|
||||||
|
|
||||||
- **Target workflow path**: Path to the workflow.yaml file or workflow folder you want to edit
|
|
||||||
- **Edit type selection**: Choice of what aspect to modify
|
|
||||||
- **User approval**: For each proposed change
|
|
||||||
|
|
||||||
## Generated Outputs
|
|
||||||
|
|
||||||
- Modified workflow files (in place)
|
|
||||||
- Optional change log at: `{output_folder}/workflow-edit-log-{date}.md`
|
|
||||||
|
|
||||||
## Features
|
|
||||||
|
|
||||||
1. **Comprehensive Analysis**: Checks workflows against the official creation guide
|
|
||||||
2. **Prioritized Issues**: Identifies and ranks issues by importance
|
|
||||||
3. **Guided Editing**: Step-by-step process with explanations
|
|
||||||
4. **Best Practices**: Ensures all edits follow BMAD conventions
|
|
||||||
5. **Instruction Style Optimization**: Convert between intent-based and prescriptive styles
|
|
||||||
6. **Validation**: Checks all changes for correctness
|
|
||||||
7. **Change Tracking**: Documents what was modified and why
|
|
||||||
|
|
||||||
## Understanding Instruction Styles
|
|
||||||
|
|
||||||
When editing workflows, one powerful option is **adjusting the instruction style** to better match the workflow's purpose.
|
|
||||||
|
|
||||||
### Intent-Based vs Prescriptive Instructions
|
|
||||||
|
|
||||||
**Intent-Based (Recommended for most workflows)**
|
|
||||||
|
|
||||||
Guides the AI with goals and principles, allowing flexible conversation.
|
|
||||||
|
|
||||||
- **More flexible and conversational** - AI adapts to user responses
|
|
||||||
- **Better for complex discovery** - Requirements gathering, creative exploration
|
|
||||||
- **Quality over consistency** - Deep understanding matters more
|
|
||||||
- **Example**: `<action>Guide user to define their target audience with specific demographics and needs</action>`
|
|
||||||
|
|
||||||
**When to use:**
|
|
||||||
|
|
||||||
- Complex discovery processes (user research, requirements)
|
|
||||||
- Creative brainstorming and ideation
|
|
||||||
- Iterative refinement workflows
|
|
||||||
- Workflows requiring nuanced understanding
|
|
||||||
|
|
||||||
**Prescriptive**
|
|
||||||
|
|
||||||
Provides exact questions with structured options.
|
|
||||||
|
|
||||||
- **More controlled and predictable** - Consistent questions every time
|
|
||||||
- **Better for simple data collection** - Platform, format, yes/no choices
|
|
||||||
- **Consistency over quality** - Same execution every run
|
|
||||||
- **Example**: `<ask>What is your target platform? Choose: PC, Console, Mobile, Web</ask>`
|
|
||||||
|
|
||||||
**When to use:**
|
|
||||||
|
|
||||||
- Simple data collection (platform, format, binary choices)
|
|
||||||
- Compliance verification and standards adherence
|
|
||||||
- Configuration with finite options
|
|
||||||
- Quick setup wizards
|
|
||||||
|
|
||||||
### Edit Workflow's Style Adjustment Feature
|
|
||||||
|
|
||||||
The **"Adjust instruction style"** editing option (menu option 11) helps you:
|
|
||||||
|
|
||||||
1. **Analyze current style** - Identifies whether workflow is primarily intent-based or prescriptive
|
|
||||||
2. **Convert between styles** - Transform prescriptive steps to intent-based (or vice versa)
|
|
||||||
3. **Optimize the mix** - Intelligently recommend the best style for each step
|
|
||||||
4. **Step-by-step control** - Review and decide on each step individually
|
|
||||||
|
|
||||||
**Common scenarios:**
|
|
||||||
|
|
||||||
- **Make workflow more conversational**: Convert rigid <ask> tags to flexible <action> tags for complex steps
|
|
||||||
- **Make workflow more consistent**: Convert open-ended <action> tags to structured <ask> tags for simple data collection
|
|
||||||
- **Balance both approaches**: Use intent-based for discovery, prescriptive for simple choices
|
|
||||||
|
|
||||||
This feature is especially valuable when converting legacy workflows or adapting workflows for different use cases.
|
|
||||||
|
|
||||||
## Workflow Steps
|
|
||||||
|
|
||||||
1. Load and analyze target workflow
|
|
||||||
2. Check against best practices
|
|
||||||
3. Select editing focus
|
|
||||||
4. Load relevant documentation
|
|
||||||
5. Perform edits with user approval
|
|
||||||
6. Validate all changes (optional)
|
|
||||||
7. Generate change summary
|
|
||||||
|
|
||||||
## Requirements
|
|
||||||
|
|
||||||
- Access to workflow creation guide
|
|
||||||
- Read/write permissions for target workflow
|
|
||||||
- Understanding of BMAD workflow types
|
|
||||||
|
|
@ -1,70 +0,0 @@
|
||||||
# Edit Workflow - Validation Checklist
|
|
||||||
|
|
||||||
## Pre-Edit Analysis
|
|
||||||
|
|
||||||
- [ ] Target workflow.yaml file successfully loaded and parsed
|
|
||||||
- [ ] All referenced workflow files identified and accessible
|
|
||||||
- [ ] Workflow type correctly determined (document/action/interactive/autonomous/meta)
|
|
||||||
- [ ] Best practices guide loaded and available for reference
|
|
||||||
|
|
||||||
## Edit Execution Quality
|
|
||||||
|
|
||||||
- [ ] User clearly informed of identified issues with priority levels
|
|
||||||
- [ ] Edit menu presented with all 8 standard options
|
|
||||||
- [ ] Selected edit type matches the actual changes made
|
|
||||||
- [ ] All proposed changes explained with reasoning before application
|
|
||||||
|
|
||||||
## File Integrity
|
|
||||||
|
|
||||||
- [ ] All modified files maintain valid YAML/Markdown syntax
|
|
||||||
- [ ] No placeholders like {TITLE} or {WORKFLOW_CODE} remain in edited files
|
|
||||||
- [ ] File paths use proper variable substitution ({project-root}, {installed_path})
|
|
||||||
- [ ] All file references resolve to actual paths
|
|
||||||
|
|
||||||
## Convention Compliance
|
|
||||||
|
|
||||||
- [ ] Instructions.md contains critical workflow engine reference header
|
|
||||||
- [ ] Instructions.md contains workflow.yaml processing reference header
|
|
||||||
- [ ] All step numbers are sequential (1, 2, 3... or 1a, 1b, 2a...)
|
|
||||||
- [ ] Each step has both n= attribute and goal= attribute
|
|
||||||
- [ ] Variable names use snake_case consistently
|
|
||||||
- [ ] Template variables (if any) match <template-output> tags exactly
|
|
||||||
|
|
||||||
## Instruction Quality
|
|
||||||
|
|
||||||
- [ ] Each step has a single, clear goal stated
|
|
||||||
- [ ] Instructions are specific with quantities (e.g., "3-5 items" not "several items")
|
|
||||||
- [ ] Optional steps marked with optional="true" attribute
|
|
||||||
- [ ] Repeating steps use proper repeat syntax (repeat="3" or repeat="until-complete")
|
|
||||||
- [ ] User prompts use <ask> tags and wait for response
|
|
||||||
- [ ] Actions use <action> tags for required operations
|
|
||||||
|
|
||||||
## Validation Criteria (if checklist.md exists)
|
|
||||||
|
|
||||||
- [ ] All checklist items are measurable and specific
|
|
||||||
- [ ] No vague criteria like "Good documentation" present
|
|
||||||
- [ ] Checklist organized into logical sections
|
|
||||||
- [ ] Each criterion can be objectively verified as true/false
|
|
||||||
|
|
||||||
## Change Documentation
|
|
||||||
|
|
||||||
- [ ] All changes logged with description of what and why
|
|
||||||
- [ ] Change summary includes list of modified files
|
|
||||||
- [ ] Improvements clearly articulated in relation to best practices
|
|
||||||
- [ ] Next steps or recommendations provided
|
|
||||||
|
|
||||||
## Post-Edit Verification
|
|
||||||
|
|
||||||
- [ ] Edited workflow follows patterns from production examples
|
|
||||||
- [ ] No functionality broken by the edits
|
|
||||||
- [ ] Workflow ready for testing or production use
|
|
||||||
- [ ] User given option to test the edited workflow
|
|
||||||
|
|
||||||
## Common Issues Resolved
|
|
||||||
|
|
||||||
- [ ] Missing critical headers added if they were absent
|
|
||||||
- [ ] Broken variable references fixed
|
|
||||||
- [ ] Vague instructions made specific
|
|
||||||
- [ ] Template-only workflows have template.md file
|
|
||||||
- [ ] Action workflows have template: false in workflow.yaml
|
|
||||||
- [ ] Step count reasonable (5-10 steps maximum unless justified)
|
|
||||||
|
|
@ -1,342 +0,0 @@
|
||||||
# Edit Workflow - Workflow Editor Instructions
|
|
||||||
|
|
||||||
<critical>The workflow execution engine is governed by: {project-root}/{bmad_folder}/core/tasks/workflow.xml</critical>
|
|
||||||
<critical>You MUST have already loaded and processed: {project-root}/{bmad_folder}/bmb/workflows/edit-workflow/workflow.yaml</critical>
|
|
||||||
<critical>This workflow uses ADAPTIVE FACILITATION - adjust your communication based on context and user needs</critical>
|
|
||||||
<critical>The goal is COLLABORATIVE IMPROVEMENT - work WITH the user, not FOR them</critical>
|
|
||||||
<critical>Communicate all responses in {communication_language}</critical>
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="1" goal="Load and deeply understand the target workflow">
|
|
||||||
<ask>What is the path to the workflow you want to edit? (provide path to workflow.yaml or workflow directory)</ask>
|
|
||||||
|
|
||||||
<action>Load the target workflow completely:
|
|
||||||
|
|
||||||
- workflow.yaml configuration
|
|
||||||
- instructions.md (if exists)
|
|
||||||
- template.md (if exists)
|
|
||||||
- checklist.md (if exists)
|
|
||||||
- Any additional data files referenced
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Load ALL workflow documentation to inform understanding:
|
|
||||||
|
|
||||||
- Workflow creation guide: {workflow_creation_guide}
|
|
||||||
- Workflow execution engine: {workflow_execution_engine}
|
|
||||||
- Study example workflows from: {workflow_examples_dir}
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Analyze the workflow deeply:
|
|
||||||
|
|
||||||
- Identify workflow type (document, action, interactive, autonomous, meta)
|
|
||||||
- Understand purpose and user journey
|
|
||||||
- Map out step flow and logic
|
|
||||||
- Check variable consistency across files
|
|
||||||
- Evaluate instruction style (intent-based vs prescriptive)
|
|
||||||
- Assess template structure (if applicable)
|
|
||||||
- Review validation criteria
|
|
||||||
- Identify config dependencies
|
|
||||||
- Check for web bundle configuration
|
|
||||||
- Evaluate against best practices from loaded guides
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Reflect understanding back to {user_name}:
|
|
||||||
|
|
||||||
Present a warm, conversational summary adapted to the workflow's complexity:
|
|
||||||
|
|
||||||
- What this workflow accomplishes (its purpose and value)
|
|
||||||
- How it's structured (type, steps, interactive points)
|
|
||||||
- What you notice (strengths, potential improvements, issues)
|
|
||||||
- Your initial assessment based on best practices
|
|
||||||
- How it fits in the larger BMAD ecosystem
|
|
||||||
|
|
||||||
Be conversational and insightful. Help {user_name} see their workflow through your eyes.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>Does this match your understanding of what this workflow should accomplish?</ask>
|
|
||||||
<template-output>workflow_understanding</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Discover improvement goals collaboratively">
|
|
||||||
<critical>Understand WHAT the user wants to improve and WHY before diving into edits</critical>
|
|
||||||
|
|
||||||
<action>Engage in collaborative discovery:
|
|
||||||
|
|
||||||
Ask open-ended questions to understand their goals:
|
|
||||||
|
|
||||||
- What prompted you to want to edit this workflow?
|
|
||||||
- What feedback have you gotten from users running it?
|
|
||||||
- Are there specific steps that feel clunky or confusing?
|
|
||||||
- Is the workflow achieving its intended outcome?
|
|
||||||
- Are there new capabilities you want to add?
|
|
||||||
- Is the instruction style working well for your users?
|
|
||||||
|
|
||||||
Listen for clues about:
|
|
||||||
|
|
||||||
- User experience issues (confusing steps, unclear instructions)
|
|
||||||
- Functional issues (broken references, missing validation)
|
|
||||||
- Performance issues (too many steps, repetitive, tedious)
|
|
||||||
- Maintainability issues (hard to update, bloated, inconsistent variables)
|
|
||||||
- Instruction style mismatch (too prescriptive when should be adaptive, or vice versa)
|
|
||||||
- Integration issues (doesn't work well with other workflows)
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Based on their responses and your analysis from step 1, identify improvement opportunities:
|
|
||||||
|
|
||||||
Organize by priority and user goals:
|
|
||||||
|
|
||||||
- CRITICAL issues blocking successful runs
|
|
||||||
- IMPORTANT improvements enhancing user experience
|
|
||||||
- NICE-TO-HAVE enhancements for polish
|
|
||||||
|
|
||||||
Present these conversationally, explaining WHY each matters and HOW it would help.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Assess instruction style fit:
|
|
||||||
|
|
||||||
Based on the workflow's purpose and your analysis:
|
|
||||||
|
|
||||||
- Is the current style (intent-based vs prescriptive) appropriate?
|
|
||||||
- Would users benefit from more/less structure?
|
|
||||||
- Are there steps that should be more adaptive?
|
|
||||||
- Are there steps that need more specificity?
|
|
||||||
|
|
||||||
Discuss style as part of improvement discovery, not as a separate concern.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Collaborate on priorities:
|
|
||||||
|
|
||||||
Don't just list options - discuss them:
|
|
||||||
|
|
||||||
- "I noticed {{issue}} - this could make users feel {{problem}}. Want to address this?"
|
|
||||||
- "The workflow could be more {{improvement}} which would help when {{use_case}}. Worth exploring?"
|
|
||||||
- "Based on what you said about {{user_goal}}, we might want to {{suggestion}}. Thoughts?"
|
|
||||||
|
|
||||||
Let the conversation flow naturally. Build a shared vision of what "better" looks like.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<template-output>improvement_goals</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Facilitate improvements collaboratively" repeat="until-user-satisfied">
|
|
||||||
<critical>Work iteratively - improve, review, refine. Never dump all changes at once.</critical>
|
|
||||||
|
|
||||||
<action>For each improvement area, facilitate collaboratively:
|
|
||||||
|
|
||||||
1. **Explain the current state and why it matters**
|
|
||||||
- Show relevant sections of the workflow
|
|
||||||
- Explain how it works now and implications
|
|
||||||
- Connect to user's goals from step 2
|
|
||||||
|
|
||||||
2. **Propose improvements with rationale**
|
|
||||||
- Suggest specific changes that align with best practices
|
|
||||||
- Explain WHY each change helps
|
|
||||||
- Provide examples from the loaded guides when helpful
|
|
||||||
- Show before/after comparisons for clarity
|
|
||||||
- Reference the creation guide's patterns naturally
|
|
||||||
|
|
||||||
3. **Collaborate on the approach**
|
|
||||||
- Ask if the proposed change addresses their need
|
|
||||||
- Invite modifications or alternative approaches
|
|
||||||
- Explain tradeoffs when relevant
|
|
||||||
- Adapt based on their feedback
|
|
||||||
|
|
||||||
4. **Apply changes iteratively**
|
|
||||||
- Make one focused improvement at a time
|
|
||||||
- Show the updated section
|
|
||||||
- Confirm it meets their expectation
|
|
||||||
- Move to next improvement or refine current one
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Common improvement patterns to facilitate:
|
|
||||||
|
|
||||||
**If refining instruction style:**
|
|
||||||
|
|
||||||
- Discuss where the workflow feels too rigid or too loose
|
|
||||||
- Identify steps that would benefit from intent-based approach
|
|
||||||
- Identify steps that need prescriptive structure
|
|
||||||
- Convert between styles thoughtfully, explaining tradeoffs
|
|
||||||
- Show how each style serves the user differently
|
|
||||||
- Test proposed changes by reading them aloud
|
|
||||||
|
|
||||||
**If improving step flow:**
|
|
||||||
|
|
||||||
- Walk through the user journey step by step
|
|
||||||
- Identify friction points or redundancy
|
|
||||||
- Propose streamlined flow
|
|
||||||
- Consider where steps could merge or split
|
|
||||||
- Ensure each step has clear goal and value
|
|
||||||
- Check that repeat conditions make sense
|
|
||||||
|
|
||||||
**If fixing variable consistency:**
|
|
||||||
|
|
||||||
- Identify variables used across files
|
|
||||||
- Find mismatches in naming or usage
|
|
||||||
- Propose consistent naming scheme
|
|
||||||
- Update all files to match
|
|
||||||
- Verify variables are defined in workflow.yaml
|
|
||||||
|
|
||||||
**If enhancing validation:**
|
|
||||||
|
|
||||||
- Review current checklist (if exists)
|
|
||||||
- Discuss what "done well" looks like
|
|
||||||
- Make criteria specific and measurable
|
|
||||||
- Add validation for new features
|
|
||||||
- Remove outdated or vague criteria
|
|
||||||
|
|
||||||
**If updating configuration:**
|
|
||||||
|
|
||||||
- Review standard config pattern
|
|
||||||
- Check if user context variables are needed
|
|
||||||
- Ensure output_folder, user_name, communication_language are used appropriately
|
|
||||||
- Add missing config dependencies
|
|
||||||
- Clean up unused config fields
|
|
||||||
|
|
||||||
**If adding/updating templates:**
|
|
||||||
|
|
||||||
- Understand the document structure needed
|
|
||||||
- Design template variables that match instruction outputs
|
|
||||||
- Ensure variable names are descriptive snake_case
|
|
||||||
- Include proper metadata headers
|
|
||||||
- Test that all variables can be filled
|
|
||||||
|
|
||||||
**If configuring web bundle:**
|
|
||||||
|
|
||||||
- Identify all files the workflow depends on
|
|
||||||
- Check for invoked workflows (must be included)
|
|
||||||
- Verify paths are {bmad_folder}/-relative
|
|
||||||
- Remove config_source dependencies
|
|
||||||
- Build complete file list
|
|
||||||
|
|
||||||
**If improving user interaction:**
|
|
||||||
|
|
||||||
- Find places where <ask> could be more open-ended
|
|
||||||
- Add educational context where users might be lost
|
|
||||||
- Remove unnecessary confirmation steps
|
|
||||||
- Make questions clearer and more purposeful
|
|
||||||
- Balance guidance with user autonomy
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Throughout improvements, educate when helpful:
|
|
||||||
|
|
||||||
Share insights from the guides naturally:
|
|
||||||
|
|
||||||
- "The creation guide recommends {{pattern}} for workflows like this"
|
|
||||||
- "Looking at examples in BMM, this type of step usually {{approach}}"
|
|
||||||
- "The execution engine expects {{structure}} for this to work properly"
|
|
||||||
|
|
||||||
Connect improvements to broader BMAD principles without being preachy.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>After each significant change:
|
|
||||||
|
|
||||||
- "Does this flow feel better for what you're trying to achieve?"
|
|
||||||
- "Want to refine this further, or move to the next improvement?"
|
|
||||||
- "How does this change affect the user experience?"
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
<template-output>improvement_implementation</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Validate improvements holistically">
|
|
||||||
<action>Run comprehensive validation conversationally:
|
|
||||||
|
|
||||||
Don't just check boxes - explain what you're validating and why it matters:
|
|
||||||
|
|
||||||
- "Let me verify all file references resolve correctly..."
|
|
||||||
- "Checking that variables are consistent across all files..."
|
|
||||||
- "Making sure the step flow is logical and complete..."
|
|
||||||
- "Validating template variables match instruction outputs..."
|
|
||||||
- "Ensuring config dependencies are properly set up..."
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Load validation checklist: {installed_path}/checklist.md</action>
|
|
||||||
<action>Check all items from checklist systematically</action>
|
|
||||||
|
|
||||||
<check if="validation_issues_found">
|
|
||||||
<action>Present issues conversationally:
|
|
||||||
|
|
||||||
Explain what's wrong and implications:
|
|
||||||
|
|
||||||
- "I found {{issue}} which could cause {{problem}} when users run this"
|
|
||||||
- "The {{component}} needs {{fix}} because {{reason}}"
|
|
||||||
|
|
||||||
Propose fixes immediately:
|
|
||||||
|
|
||||||
- "I can fix this by {{solution}}. Should I?"
|
|
||||||
- "We have a couple options here: {{option1}} or {{option2}}. Thoughts?"
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Fix approved issues and re-validate</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="validation_passes">
|
|
||||||
<action>Confirm success warmly:
|
|
||||||
|
|
||||||
"Excellent! Everything validates cleanly:
|
|
||||||
|
|
||||||
- All file references resolve
|
|
||||||
- Variables are consistent throughout
|
|
||||||
- Step flow is logical and complete
|
|
||||||
- Template aligns with instructions (if applicable)
|
|
||||||
- Config dependencies are set up correctly
|
|
||||||
- Web bundle is complete (if applicable)
|
|
||||||
|
|
||||||
Your workflow is in great shape."
|
|
||||||
</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<template-output>validation_results</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5" goal="Review improvements and guide next steps">
|
|
||||||
<action>Create a conversational summary of what improved:
|
|
||||||
|
|
||||||
Tell the story of the transformation:
|
|
||||||
|
|
||||||
- "We started with {{initial_state}}"
|
|
||||||
- "You wanted to {{user_goals}}"
|
|
||||||
- "We made these key improvements: {{changes_list}}"
|
|
||||||
- "Now your workflow {{improved_capabilities}}"
|
|
||||||
|
|
||||||
Highlight the impact:
|
|
||||||
|
|
||||||
- "This means users will experience {{benefit}}"
|
|
||||||
- "The workflow is now more {{quality}}"
|
|
||||||
- "It follows best practices for {{patterns}}"
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<action>Guide next steps based on changes made:
|
|
||||||
|
|
||||||
If instruction style changed:
|
|
||||||
|
|
||||||
- "Since we made the workflow more {{style}}, you might want to test it with a real user to see how it feels"
|
|
||||||
|
|
||||||
If template was updated:
|
|
||||||
|
|
||||||
- "The template now has {{new_variables}} - run the workflow to generate a sample document"
|
|
||||||
|
|
||||||
If this is part of larger module work:
|
|
||||||
|
|
||||||
- "This workflow is part of {{module}} - consider if other workflows need similar improvements"
|
|
||||||
|
|
||||||
If web bundle was configured:
|
|
||||||
|
|
||||||
- "The web bundle is now set up - you can test deploying this workflow standalone"
|
|
||||||
|
|
||||||
Be a helpful guide to what comes next, not just a task completer.
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<ask>Would you like to:
|
|
||||||
|
|
||||||
- Test the edited workflow by running it
|
|
||||||
- Edit another workflow
|
|
||||||
- Make additional refinements to this one
|
|
||||||
- Return to your module work
|
|
||||||
</ask>
|
|
||||||
|
|
||||||
<template-output>completion_summary</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
|
|
@ -1,27 +0,0 @@
|
||||||
# Edit Workflow - Workflow Editor Configuration
|
|
||||||
name: "edit-workflow"
|
|
||||||
description: "Edit existing BMAD workflows while following all best practices and conventions"
|
|
||||||
author: "BMad"
|
|
||||||
|
|
||||||
# Critical variables load from config_source
|
|
||||||
config_source: "{project-root}/{bmad_folder}/bmb/config.yaml"
|
|
||||||
communication_language: "{config_source}:communication_language"
|
|
||||||
user_name: "{config_source}:user_name"
|
|
||||||
|
|
||||||
# Required Data Files - Critical for understanding workflow conventions
|
|
||||||
workflow_creation_guide: "{project-root}/{bmad_folder}/bmb/workflows/create-workflow/workflow-creation-guide.md"
|
|
||||||
workflow_execution_engine: "{project-root}/{bmad_folder}/core/tasks/workflow.xml"
|
|
||||||
|
|
||||||
# Reference examples
|
|
||||||
workflow_examples_dir: "{project-root}/{bmad_folder}/bmm/workflows/"
|
|
||||||
|
|
||||||
# Module path and component files
|
|
||||||
installed_path: "{project-root}/{bmad_folder}/bmb/workflows/edit-workflow"
|
|
||||||
template: false # This is an action workflow - no template needed
|
|
||||||
instructions: "{installed_path}/instructions.md"
|
|
||||||
validation: "{installed_path}/checklist.md"
|
|
||||||
|
|
||||||
standalone: true
|
|
||||||
|
|
||||||
# Web bundle configuration
|
|
||||||
web_bundle: false # BMB workflows run locally in BMAD-METHOD project
|
|
||||||
Loading…
Reference in New Issue