Compare commits
1 Commits
056a355119
...
2e0bb4c598
| Author | SHA1 | Date |
|---|---|---|
Sjoerd Bozon
|
2e0bb4c598 |
|
|
@ -161,7 +161,7 @@ BMGD Documentation
|
|||
|
||||
### Related Documentation
|
||||
|
||||
- **[BMM Documentation](../bmm/index.md)** - Core BMad Method documentation
|
||||
- **[BMM Documentation](../../bmm/docs/index.md)** - Core BMad Method documentation
|
||||
|
||||
## Tips for Using This Documentation
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Complete reference for all BMGD workflows organized by development phase.
|
|||
|
||||
BMGD workflows are organized into four phases:
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -510,7 +510,7 @@ Trust your expertise - BMM supports your decisions.
|
|||
|
||||
**A:**
|
||||
|
||||
1. Search [Complete Documentation](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/README.md) for related topics
|
||||
1. Search [Complete Documentation](./README.md) for related topics
|
||||
2. Ask in [Discord Community](https://discord.gg/gk8jAdXWmj) (#general-dev)
|
||||
3. Open a [GitHub Issue](https://github.com/bmad-code-org/BMAD-METHOD/issues)
|
||||
4. Watch [YouTube Tutorials](https://www.youtube.com/@BMadCode)
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ CIS workflows integrate with:
|
|||
|
||||
## Related Documentation
|
||||
|
||||
- **[BMM Documentation](../bmm/index.md)** - Core BMad Method documentation
|
||||
- **[BMM Documentation](../../bmm/docs/index.md)** - Core BMad Method documentation
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -28,18 +28,22 @@ agent:
|
|||
- modules: "{project-root}/_bmad/bmb/docs/modules/kb.csv"
|
||||
|
||||
menu:
|
||||
- trigger: BM or fuzzy match on brainstorm-module
|
||||
exec: "{project-root}/_bmad/bmb/workflows/brainstorm-module/workflow.md"
|
||||
description: "[BM] Brainstorm and conceptualize new BMAD modules"
|
||||
|
||||
- trigger: PB or fuzzy match on product-brief
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/product-brief-module/workflow.md"
|
||||
description: "[PB] Create product brief for BMAD module development"
|
||||
|
||||
- trigger: CM or fuzzy match on create-module
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/create-module/workflow.md"
|
||||
description: "[CM] Create a complete BMAD module with agents, workflows, and infrastructure"
|
||||
|
||||
- trigger: EM or fuzzy match on edit-module
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/edit-module/workflow.md"
|
||||
description: "[EM] Edit existing BMAD modules while maintaining coherence"
|
||||
|
||||
- trigger: VM or fuzzy match on validate-module
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/module-compliance-check/workflow.md"
|
||||
description: "[VM] Run compliance check on BMAD modules against best practices"
|
||||
|
|
|
|||
|
|
@ -29,17 +29,13 @@ agent:
|
|||
|
||||
menu:
|
||||
- trigger: CW or fuzzy match on create-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/create-workflow/workflow.md"
|
||||
description: "[CW] Create a new BMAD workflow with proper structure and best practices"
|
||||
|
||||
- trigger: EW or fuzzy match on edit-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
|
||||
description: "[EW] Edit existing BMAD workflows while maintaining integrity"
|
||||
# - trigger: EW or fuzzy match on edit-workflow
|
||||
# exec: "{project-root}/_bmad/bmb/workflows/edit-workflow/workflow.md"
|
||||
# description: "[EW] Edit existing BMAD workflows while maintaining integrity"
|
||||
|
||||
- trigger: VW or fuzzy match on validate-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
|
||||
description: "[VW] Run validation check on BMAD workflows against best practices"
|
||||
|
||||
- trigger: RW or fuzzy match on convert-or-rework-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/workflow/workflow.md"
|
||||
description: "[RW] Rework a Workflow to a V6 Compliant Version"
|
||||
# - trigger: VW or fuzzy match on validate-workflow
|
||||
# exec: "{project-root}/_bmad/bmb/workflows/workflow-compliance-check/workflow.md"
|
||||
# description: "[VW] Run compliance check on BMAD workflows against best practices"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,220 @@
|
|||
# Standalone Workflow Builder Architecture
|
||||
|
||||
This document describes the architecture of the standalone workflow builder system - a pure markdown approach to creating structured workflows.
|
||||
|
||||
## Core Architecture Principles
|
||||
|
||||
### 1. Micro-File Design
|
||||
|
||||
Each workflow consists of multiple focused, self-contained files, driven from a workflow.md file that is initially loaded:
|
||||
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md # Main workflow configuration
|
||||
├── steps/ # Step instruction files (focused, self-contained)
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-02-profile.md
|
||||
│ └── step-N-[name].md
|
||||
├── templates/ # Content templates
|
||||
│ ├── profile-section.md
|
||||
│ └── [other-sections].md
|
||||
└── data/ # Optional data files
|
||||
└── [data-files].csv/.json
|
||||
```
|
||||
|
||||
### 2. Just-In-Time (JIT) Loading
|
||||
|
||||
- **Single File in Memory**: Only the current step file is loaded
|
||||
- **No Future Peeking**: Step files must not reference future steps
|
||||
- **Sequential Processing**: Steps execute in strict order
|
||||
- **On-Demand Loading**: Templates load only when needed
|
||||
|
||||
### 3. State Management
|
||||
|
||||
- **Frontmatter Tracking**: Workflow state stored in output document frontmatter
|
||||
- **Progress Array**: `stepsCompleted` tracks completed steps
|
||||
- **Last Step Marker**: `lastStep` indicates where to resume
|
||||
- **Append-Only Building**: Documents grow by appending content
|
||||
|
||||
### 4. Execution Model
|
||||
|
||||
```
|
||||
1. Load workflow.md → Read configuration
|
||||
2. Execute step-01-init.md → Initialize or detect continuation
|
||||
3. For each step:
|
||||
a. Load step file completely
|
||||
b. Execute instructions sequentially
|
||||
c. Wait for user input at menu points
|
||||
d. Only proceed with 'C' (Continue)
|
||||
e. Update document/frontmatter
|
||||
f. Load next step
|
||||
```
|
||||
|
||||
## Key Components
|
||||
|
||||
### Workflow File (workflow.md)
|
||||
|
||||
- **Purpose**: Entry point and configuration
|
||||
- **Content**: Role definition, goal, architecture rules
|
||||
- **Action**: Points to step-01-init.md
|
||||
|
||||
### Step Files (step-NN-[name].md)
|
||||
|
||||
- **Size**: Focused and concise (typically 5-10KB)
|
||||
- **Structure**: Frontmatter + sequential instructions
|
||||
- **Features**: Self-contained rules, menu handling, state updates
|
||||
|
||||
### Frontmatter Variables
|
||||
|
||||
Standard variables in step files:
|
||||
|
||||
```yaml
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/[workflow-name]'
|
||||
thisStepFile: '{workflow_path}/steps/step-[N]-[name].md'
|
||||
nextStepFile: '{workflow_path}/steps/step-[N+1]-[name].md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/[output-name]-{project_name}.md'
|
||||
```
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### Fresh Workflow
|
||||
|
||||
```
|
||||
workflow.md
|
||||
↓
|
||||
step-01-init.md (creates document)
|
||||
↓
|
||||
step-02-[name].md
|
||||
↓
|
||||
step-03-[name].md
|
||||
↓
|
||||
...
|
||||
↓
|
||||
step-N-[final].md (completes workflow)
|
||||
```
|
||||
|
||||
### Continuation Workflow
|
||||
|
||||
```
|
||||
workflow.md
|
||||
↓
|
||||
step-01-init.md (detects existing document)
|
||||
↓
|
||||
step-01b-continue.md (analyzes state)
|
||||
↓
|
||||
step-[appropriate-next].md
|
||||
```
|
||||
|
||||
## Menu System
|
||||
|
||||
### Standard Menu Pattern
|
||||
|
||||
```
|
||||
Display: **Select an Option:** [A] [Action] [P] Party Mode [C] Continue
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save content, update frontmatter, load next step
|
||||
```
|
||||
|
||||
### Menu Rules
|
||||
|
||||
- **Halt Required**: Always wait for user input
|
||||
- **Continue Only**: Only proceed with 'C' selection
|
||||
- **State Persistence**: Save before loading next step
|
||||
- **Loop Back**: Return to menu after other actions
|
||||
|
||||
## Collaborative Dialogue Model
|
||||
|
||||
### Not Command-Response
|
||||
|
||||
- **Facilitator Role**: AI guides, user decides
|
||||
- **Equal Partnership**: Both parties contribute
|
||||
- **No Assumptions**: Don't assume user wants next step
|
||||
- **Explicit Consent**: Always ask for input
|
||||
|
||||
### Example Pattern
|
||||
|
||||
```
|
||||
AI: "Tell me about your dietary preferences."
|
||||
User: [provides information]
|
||||
AI: "Thank you. Now let's discuss your cooking habits."
|
||||
[Continue conversation]
|
||||
AI: **Menu Options**
|
||||
```
|
||||
|
||||
## CSV Intelligence (Optional)
|
||||
|
||||
### Data-Driven Behavior
|
||||
|
||||
- Configuration in CSV files
|
||||
- Dynamic menu options
|
||||
- Variable substitution
|
||||
- Conditional logic
|
||||
|
||||
### Example Structure
|
||||
|
||||
```csv
|
||||
variable,type,value,description
|
||||
cooking_frequency,choice,"daily|weekly|occasionally","How often user cooks"
|
||||
meal_type,multi,"breakfast|lunch|dinner|snacks","Types of meals to plan"
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### File Size Limits
|
||||
|
||||
- **Step Files**: Keep focused and reasonably sized (5-10KB typical)
|
||||
- **Templates**: Keep focused and reusable
|
||||
- **Workflow File**: Keep lean, no implementation details
|
||||
|
||||
### Sequential Enforcement
|
||||
|
||||
- **Numbered Steps**: Use sequential numbering (1, 2, 3...)
|
||||
- **No Skipping**: Each step must complete
|
||||
- **State Updates**: Mark completion in frontmatter
|
||||
|
||||
### Error Prevention
|
||||
|
||||
- **Path Variables**: Use frontmatter variables, never hardcode
|
||||
- **Complete Loading**: Always read entire file before execution
|
||||
- **Menu Halts**: Never proceed without 'C' selection
|
||||
|
||||
## Migration from XML
|
||||
|
||||
### Advantages
|
||||
|
||||
- **No Dependencies**: Pure markdown, no XML parsing
|
||||
- **Human Readable**: Files are self-documenting
|
||||
- **Git Friendly**: Clean diffs and merges
|
||||
- **Flexible**: Easier to modify and extend
|
||||
|
||||
### Key Differences
|
||||
|
||||
| XML Workflows | Standalone Workflows |
|
||||
| ----------------- | ----------------------- |
|
||||
| Single large file | Multiple micro-files |
|
||||
| Complex structure | Simple sequential steps |
|
||||
| Parser required | Any markdown viewer |
|
||||
| Rigid format | Flexible organization |
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
### Critical Rules
|
||||
|
||||
- **NEVER** load multiple step files
|
||||
- **ALWAYS** read complete step file first
|
||||
- **NEVER** skip steps or optimize
|
||||
- **ALWAYS** update frontmatter of the output file when a step is complete
|
||||
- **NEVER** proceed without user consent
|
||||
|
||||
### Success Metrics
|
||||
|
||||
- Documents created correctly
|
||||
- All steps completed sequentially
|
||||
- User satisfied with collaborative process
|
||||
- Clean, maintainable file structure
|
||||
|
||||
This architecture ensures disciplined, predictable workflow execution while maintaining flexibility for different use cases.
|
||||
|
|
@ -0,0 +1,206 @@
|
|||
# CSV Data File Standards for BMAD Workflows
|
||||
|
||||
## Purpose and Usage
|
||||
|
||||
CSV data files in BMAD workflows serve specific purposes for different workflow types:
|
||||
|
||||
**For Agents:** Provide structured data that agents need to reference but cannot realistically generate (such as specific configurations, domain-specific data, or structured knowledge bases).
|
||||
|
||||
**For Expert Agents:** Supply specialized knowledge bases, reference data, or persistent information that the expert agent needs to access consistently across sessions.
|
||||
|
||||
**For Workflows:** Include reference data, configuration parameters, or structured inputs that guide workflow execution and decision-making.
|
||||
|
||||
**Key Principle:** CSV files should contain data that is essential, structured, and not easily generated by LLMs during execution.
|
||||
|
||||
## Intent-Based Design Principle
|
||||
|
||||
**Core Philosophy:** The closer workflows stay to **intent** rather than **prescriptive** instructions, the more creative and adaptive the LLM experience becomes.
|
||||
|
||||
**CSV Enables Intent-Based Design:**
|
||||
|
||||
- **Instead of:** Hardcoded scripts with exact phrases LLM must say
|
||||
- **CSV Provides:** Clear goals and patterns that LLM adapts creatively to context
|
||||
- **Result:** Natural, contextual conversations rather than rigid scripts
|
||||
|
||||
**Example - Advanced Elicitation:**
|
||||
|
||||
- **Prescriptive Alternative:** 50 separate files with exact conversation scripts
|
||||
- **Intent-Based Reality:** One CSV row with method goal + pattern → LLM adapts to user
|
||||
- **Benefit:** Same method works differently for different users while maintaining essence
|
||||
|
||||
**Intent vs Prescriptive Spectrum:**
|
||||
|
||||
- **Highly Prescriptive:** "Say exactly: 'Based on my analysis, I recommend...'"
|
||||
- **Balanced Intent:** "Help the user understand the implications using your professional judgment"
|
||||
- **CSV Goal:** Provide just enough guidance to enable creative, context-aware execution
|
||||
|
||||
## Primary Use Cases
|
||||
|
||||
### 1. Knowledge Base Indexing (Document Lookup Optimization)
|
||||
|
||||
**Problem:** Large knowledge bases with hundreds of documents cause context blowup and missed details when LLMs try to process them all.
|
||||
|
||||
**CSV Solution:** Create a knowledge base index with:
|
||||
|
||||
- **Column 1:** Keywords and topics
|
||||
- **Column 2:** Document file path/location
|
||||
- **Column 3:** Section or line number where relevant content starts
|
||||
- **Column 4:** Content type or summary (optional)
|
||||
|
||||
**Result:** Transform from context-blowing document loads to surgical precision lookups, creating agents with near-infinite knowledge bases while maintaining optimal context usage.
|
||||
|
||||
### 2. Workflow Sequence Optimization
|
||||
|
||||
**Problem:** Complex workflows (e.g., game development) with hundreds of potential steps for different scenarios become unwieldy and context-heavy.
|
||||
|
||||
**CSV Solution:** Create a workflow routing table:
|
||||
|
||||
- **Column 1:** Scenario type (e.g., "2D Platformer", "RPG", "Puzzle Game")
|
||||
- **Column 2:** Required step sequence (e.g., "step-01,step-03,step-07,step-12")
|
||||
- **Column 3:** Document sections to include
|
||||
- **Column 4:** Specialized parameters or configurations
|
||||
|
||||
**Result:** Step 1 determines user needs, finds closest match in CSV, confirms with user, then follows optimized sequence - truly optimal for context usage.
|
||||
|
||||
### 3. Method Registry (Dynamic Technique Selection)
|
||||
|
||||
**Problem:** Tasks need to select optimal techniques from dozens of options based on context, without hardcoding selection logic.
|
||||
|
||||
**CSV Solution:** Create a method registry with:
|
||||
|
||||
- **Column 1:** Category (collaboration, advanced, technical, creative, etc.)
|
||||
- **Column 2:** Method name and rich description
|
||||
- **Column 3:** Execution pattern or flow guide (e.g., "analysis → insights → action")
|
||||
- **Column 4:** Complexity level or use case indicators
|
||||
|
||||
**Example:** Advanced Elicitation task analyzes content context, selects 5 best-matched methods from 50 options, then executes dynamically using CSV descriptions.
|
||||
|
||||
**Result:** Smart, context-aware technique selection without hardcoded logic - infinitely extensible method libraries.
|
||||
|
||||
### 4. Configuration Management
|
||||
|
||||
**Problem:** Complex systems with many configuration options that vary by use case.
|
||||
|
||||
**CSV Solution:** Configuration lookup tables mapping scenarios to specific parameter sets.
|
||||
|
||||
## What NOT to Include in CSV Files
|
||||
|
||||
**Avoid Web-Searchable Data:** Do not include information that LLMs can readily access through web search or that exists in their training data, such as:
|
||||
|
||||
- Common programming syntax or standard library functions
|
||||
- General knowledge about widely used technologies
|
||||
- Historical facts or commonly available information
|
||||
- Basic terminology or standard definitions
|
||||
|
||||
**Include Specialized Data:** Focus on data that is:
|
||||
|
||||
- Specific to your project or domain
|
||||
- Not readily available through web search
|
||||
- Essential for consistent workflow execution
|
||||
- Too voluminous for LLM context windows
|
||||
|
||||
## CSV Data File Standards
|
||||
|
||||
### 1. Purpose Validation
|
||||
|
||||
- **Essential Data Only:** CSV must contain data that cannot be reasonably generated by LLMs
|
||||
- **Domain Specific:** Data should be specific to the workflow's domain or purpose
|
||||
- **Consistent Usage:** All columns and data must be referenced and used somewhere in the workflow
|
||||
- **No Redundancy:** Avoid data that duplicates functionality already available to LLMs
|
||||
|
||||
### 2. Structural Standards
|
||||
|
||||
- **Valid CSV Format:** Proper comma-separated values with quoted fields where needed
|
||||
- **Consistent Columns:** All rows must have the same number of columns
|
||||
- **No Missing Data:** Empty values should be explicitly marked (e.g., "", "N/A", or NULL)
|
||||
- **Header Row:** First row must contain clear, descriptive column headers
|
||||
- **Proper Encoding:** UTF-8 encoding required for special characters
|
||||
|
||||
### 3. Content Standards
|
||||
|
||||
- **No LLM-Generated Content:** Avoid data that LLMs can easily generate (e.g., generic phrases, common knowledge)
|
||||
- **Specific and Concrete:** Use specific values rather than vague descriptions
|
||||
- **Verifiable Data:** Data should be factual and verifiable when possible
|
||||
- **Consistent Formatting:** Date formats, numbers, and text should follow consistent patterns
|
||||
|
||||
### 4. Column Standards
|
||||
|
||||
- **Clear Headers:** Column names must be descriptive and self-explanatory
|
||||
- **Consistent Data Types:** Each column should contain consistent data types
|
||||
- **No Unused Columns:** Every column must be referenced and used in the workflow
|
||||
- **Appropriate Width:** Columns should be reasonably narrow and focused
|
||||
|
||||
### 5. File Size Standards
|
||||
|
||||
- **Efficient Structure:** CSV files should be as small as possible while maintaining functionality
|
||||
- **No Redundant Rows:** Avoid duplicate or nearly identical rows
|
||||
- **Compressed Data:** Use efficient data representation (e.g., codes instead of full descriptions)
|
||||
- **Maximum Size:** Individual CSV files should not exceed 1MB unless absolutely necessary
|
||||
|
||||
### 6. Documentation Standards
|
||||
|
||||
- **Documentation Required:** Each CSV file should have documentation explaining its purpose
|
||||
- **Column Descriptions:** Each column must be documented with its usage and format
|
||||
- **Data Sources:** Source of data should be documented when applicable
|
||||
- **Update Procedures:** Process for updating CSV data should be documented
|
||||
|
||||
### 7. Integration Standards
|
||||
|
||||
- **File References:** CSV files must be properly referenced in workflow configuration
|
||||
- **Access Patterns:** Workflow must clearly define how and when CSV data is accessed
|
||||
- **Error Handling:** Workflow must handle cases where CSV files are missing or corrupted
|
||||
- **Version Control:** CSV files should be versioned when changes occur
|
||||
|
||||
### 8. Quality Assurance
|
||||
|
||||
- **Data Validation:** CSV data should be validated for correctness and completeness
|
||||
- **Format Consistency:** Consistent formatting across all rows and columns
|
||||
- **No Ambiguity:** Data entries should be clear and unambiguous
|
||||
- **Regular Review:** CSV content should be reviewed periodically for relevance
|
||||
|
||||
### 9. Security Considerations
|
||||
|
||||
- **No Sensitive Data:** Avoid including sensitive, personal, or confidential information
|
||||
- **Data Sanitization:** CSV data should be sanitized for security issues
|
||||
- **Access Control:** Access to CSV files should be controlled when necessary
|
||||
- **Audit Trail:** Changes to CSV files should be logged when appropriate
|
||||
|
||||
### 10. Performance Standards
|
||||
|
||||
- **Fast Loading:** CSV files must load quickly within workflow execution
|
||||
- **Memory Efficient:** Structure should minimize memory usage during processing
|
||||
- **Optimized Queries:** If data lookup is needed, optimize for efficient access
|
||||
- **Caching Strategy**: Consider whether data can be cached for performance
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
When creating CSV data files for BMAD workflows:
|
||||
|
||||
1. **Start with Purpose:** Clearly define why CSV is needed instead of LLM generation
|
||||
2. **Design Structure:** Plan columns and data types before creating the file
|
||||
3. **Test Integration:** Ensure workflow properly accesses and uses CSV data
|
||||
4. **Document Thoroughly:** Provide complete documentation for future maintenance
|
||||
5. **Validate Quality:** Check data quality, format consistency, and integration
|
||||
6. **Monitor Usage:** Track how CSV data is used and optimize as needed
|
||||
|
||||
## Common Anti-Patterns to Avoid
|
||||
|
||||
- **Generic Phrases:** CSV files containing common phrases or LLM-generated content
|
||||
- **Redundant Data:** Duplicating information easily available to LLMs
|
||||
- **Overly Complex:** Unnecessarily complex CSV structures when simple data suffices
|
||||
- **Unused Columns:** Columns that are defined but never referenced in workflows
|
||||
- **Poor Formatting:** Inconsistent data formats, missing values, or structural issues
|
||||
- **No Documentation:** CSV files without clear purpose or usage documentation
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For each CSV file, verify:
|
||||
|
||||
- [ ] Purpose is essential and cannot be replaced by LLM generation
|
||||
- [ ] All columns are used in the workflow
|
||||
- [ ] Data is properly formatted and consistent
|
||||
- [ ] File is efficiently sized and structured
|
||||
- [ ] Documentation is complete and clear
|
||||
- [ ] Integration with workflow is tested and working
|
||||
- [ ] Security considerations are addressed
|
||||
- [ ] Performance requirements are met
|
||||
|
|
@ -0,0 +1,220 @@
|
|||
# Intent vs Prescriptive Spectrum
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
The **Intent vs Prescriptive Spectrum** is a fundamental design principle for BMAD workflows and agents. It determines how much creative freedom an LLM has versus how strictly it must follow predefined instructions.
|
||||
|
||||
**Key Principle:** The closer workflows stay to **intent**, the more creative and adaptive the LLM experience becomes. The closer they stay to **prescriptive**, the more consistent and controlled the output becomes.
|
||||
|
||||
## Understanding the Spectrum
|
||||
|
||||
### **Intent-Based Design** (Creative Freedom)
|
||||
|
||||
**Focus**: What goal should be achieved
|
||||
**Approach**: Trust the LLM to determine the best method
|
||||
**Result**: Creative, adaptive, context-aware interactions
|
||||
**Best For**: Creative exploration, problem-solving, personalized experiences
|
||||
|
||||
### **Prescriptive Design** (Structured Control)
|
||||
|
||||
**Focus**: Exactly what to say and do
|
||||
**Approach**: Detailed scripts and specific instructions
|
||||
**Result**: Consistent, predictable, controlled outcomes
|
||||
**Best For**: Compliance, safety-critical, standardized processes
|
||||
|
||||
## Spectrum Examples
|
||||
|
||||
### **Highly Intent-Based** (Creative End)
|
||||
|
||||
```markdown
|
||||
**Example:** Story Exploration Workflow
|
||||
**Instruction:** "Help the user explore their dream imagery to craft compelling narratives, use multiple turns of conversation to really push users to develop their ideas, giving them hints and ideas also to prime them effectively to bring out their creativity"
|
||||
**LLM Freedom:** Adapts questions, explores tangents, follows creative inspiration
|
||||
**Outcome:** Unique, personalized storytelling experiences
|
||||
```
|
||||
|
||||
### **Balanced Middle** (Professional Services)
|
||||
|
||||
```markdown
|
||||
**Example:** Business Strategy Workflow
|
||||
**Instruction:** "Guide the user through SWOT analysis using your business expertise. when complete tell them 'here is your final report {report output}'
|
||||
**LLM Freedom:** Professional judgment in analysis, structured but adaptive approach
|
||||
**Outcome:** Professional, consistent yet tailored business insights
|
||||
```
|
||||
|
||||
### **Highly Prescriptive** (Control End)
|
||||
|
||||
```markdown
|
||||
**Example:** Medical Intake Form
|
||||
**Instruction:** "Ask exactly: 'Do you currently experience any of the following symptoms: fever, cough, fatigue?' Wait for response, then ask exactly: 'When did these symptoms begin?'"
|
||||
**LLM Freedom:** Minimal - must follow exact script for medical compliance
|
||||
**Outcome:** Consistent, medically compliant patient data collection
|
||||
```
|
||||
|
||||
## Spectrum Positioning Guide
|
||||
|
||||
### **Choose Intent-Based When:**
|
||||
|
||||
- ✅ Creative exploration and innovation are goals
|
||||
- ✅ Personalization and adaptation to user context are important
|
||||
- ✅ Human-like conversation and natural interaction are desired
|
||||
- ✅ Problem-solving requires flexible thinking
|
||||
- ✅ User experience and engagement are priorities
|
||||
|
||||
**Examples:**
|
||||
|
||||
- Creative brainstorming sessions
|
||||
- Personal coaching or mentoring
|
||||
- Exploratory research and discovery
|
||||
- Artistic content creation
|
||||
- Collaborative problem-solving
|
||||
|
||||
### **Choose Prescriptive When:**
|
||||
|
||||
- ✅ Compliance with regulations or standards is required
|
||||
- ✅ Safety or legal considerations are paramount
|
||||
- ✅ Exact consistency across multiple sessions is essential
|
||||
- ✅ Training new users on specific procedures
|
||||
- ✅ Data collection must follow specific protocols
|
||||
|
||||
**Examples:**
|
||||
|
||||
- Medical intake and symptom assessment
|
||||
- Legal compliance questionnaires
|
||||
- Safety checklists and procedures
|
||||
- Standardized testing protocols
|
||||
- Regulatory data collection
|
||||
|
||||
### **Choose Balanced When:**
|
||||
|
||||
- ✅ Professional expertise is required but adaptation is beneficial
|
||||
- ✅ Consistent quality with flexible application is needed
|
||||
- ✅ Domain expertise should guide but not constrain interactions
|
||||
- ✅ User trust and professional credibility are important
|
||||
- ✅ Complex processes require both structure and judgment
|
||||
|
||||
**Examples:**
|
||||
|
||||
- Business consulting and advisory
|
||||
- Technical support and troubleshooting
|
||||
- Educational tutoring and instruction
|
||||
- Financial planning and advice
|
||||
- Project management facilitation
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
### **For Workflow Designers:**
|
||||
|
||||
1. **Early Spectrum Decision**: Determine spectrum position during initial design
|
||||
2. **User Education**: Explain spectrum choice and its implications to users
|
||||
3. **Consistent Application**: Maintain chosen spectrum throughout workflow
|
||||
4. **Context Awareness**: Adjust spectrum based on specific use case requirements
|
||||
|
||||
### **For Workflow Implementation:**
|
||||
|
||||
**Intent-Based Patterns:**
|
||||
|
||||
```markdown
|
||||
- "Help the user understand..." (vs "Explain that...")
|
||||
- "Guide the user through..." (vs "Follow these steps...")
|
||||
- "Use your professional judgment to..." (vs "Apply this specific method...")
|
||||
- "Adapt your approach based on..." (vs "Regardless of situation, always...")
|
||||
```
|
||||
|
||||
**Prescriptive Patterns:**
|
||||
|
||||
```markdown
|
||||
- "Say exactly: '...'" (vs "Communicate that...")
|
||||
- "Follow this script precisely: ..." (vs "Cover these points...")
|
||||
- "Do not deviate from: ..." (vs "Consider these options...")
|
||||
- "Must ask in this order: ..." (vs "Ensure you cover...")
|
||||
```
|
||||
|
||||
### **For Agents:**
|
||||
|
||||
**Intent-Based Agent Design:**
|
||||
|
||||
```yaml
|
||||
persona:
|
||||
communication_style: 'Adaptive professional who adjusts approach based on user context'
|
||||
guiding_principles:
|
||||
- 'Use creative problem-solving within professional boundaries'
|
||||
- 'Personalize approach while maintaining expertise'
|
||||
- 'Adapt conversation flow to user needs'
|
||||
```
|
||||
|
||||
**Prescriptive Agent Design:**
|
||||
|
||||
```yaml
|
||||
persona:
|
||||
communication_style: 'Follows standardized protocols exactly'
|
||||
governing_rules:
|
||||
- 'Must use approved scripts without deviation'
|
||||
- 'Follow sequence precisely as defined'
|
||||
- 'No adaptation of prescribed procedures'
|
||||
```
|
||||
|
||||
## Spectrum Calibration Questions
|
||||
|
||||
**Ask these during workflow design:**
|
||||
|
||||
1. **Consequence of Variation**: What happens if the LLM says something different?
|
||||
2. **User Expectation**: Does the user expect consistency or creativity?
|
||||
3. **Risk Level**: What are the risks of creative deviation vs. rigid adherence?
|
||||
4. **Expertise Required**: Is domain expertise application more important than consistency?
|
||||
5. **Regulatory Requirements**: Are there external compliance requirements?
|
||||
|
||||
## Best Practices
|
||||
|
||||
### **DO:**
|
||||
|
||||
- ✅ Make conscious spectrum decisions during design
|
||||
- ✅ Explain spectrum choices to users
|
||||
- ✅ Use intent-based design for creative and adaptive experiences
|
||||
- ✅ Use prescriptive design for compliance and consistency requirements
|
||||
- ✅ Consider balanced approaches for professional services
|
||||
- ✅ Document spectrum rationale for future reference
|
||||
|
||||
### **DON'T:**
|
||||
|
||||
- ❌ Mix spectrum approaches inconsistently within workflows
|
||||
- ❌ Default to prescriptive when intent-based would be more effective
|
||||
- ❌ Use creative freedom when compliance is required
|
||||
- ❌ Forget to consider user expectations and experience
|
||||
- ❌ Overlook risk assessment in spectrum selection
|
||||
|
||||
## Quality Assurance
|
||||
|
||||
**When validating workflows:**
|
||||
|
||||
- Check if spectrum position is intentional and consistent
|
||||
- Verify prescriptive elements are necessary and justified
|
||||
- Ensure intent-based elements have sufficient guidance
|
||||
- Confirm spectrum alignment with user needs and expectations
|
||||
- Validate that risks are appropriately managed
|
||||
|
||||
## Examples in Practice
|
||||
|
||||
### **Medical Intake (Highly Prescriptive):**
|
||||
|
||||
- **Why**: Patient safety, regulatory compliance, consistent data collection
|
||||
- **Implementation**: Exact questions, specific order, no deviation permitted
|
||||
- **Benefit**: Reliable, medically compliant patient information
|
||||
|
||||
### **Creative Writing Workshop (Highly Intent):**
|
||||
|
||||
- **Why**: Creative exploration, personalized inspiration, artistic expression
|
||||
- **Implementation**: Goal guidance, creative freedom, adaptive prompts
|
||||
- **Benefit**: Unique, personalized creative works
|
||||
|
||||
### **Business Strategy (Balanced):**
|
||||
|
||||
- **Why**: Professional expertise with adaptive application
|
||||
- **Implementation**: Structured framework with professional judgment
|
||||
- **Benefit**: Professional, consistent yet tailored business insights
|
||||
|
||||
## Conclusion
|
||||
|
||||
The Intent vs Prescriptive Spectrum is not about good vs. bad - it's about **appropriate design choices**. The best workflows make conscious decisions about where they fall on this spectrum based on their specific requirements, user needs, and risk considerations.
|
||||
|
||||
**Key Success Factor**: Choose your spectrum position intentionally, implement it consistently, and align it with your specific use case requirements.
|
||||
|
|
@ -0,0 +1,469 @@
|
|||
# BMAD Step File Guidelines
|
||||
|
||||
**Version:** 1.0
|
||||
**Module:** bmb (BMAD Builder)
|
||||
**Purpose:** Definitive guide for creating BMAD workflow step files
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
BMAD workflow step files follow a strict structure to ensure consistency, progressive disclosure, and mode-aware routing. Every step file MUST adhere to these guidelines.
|
||||
|
||||
---
|
||||
|
||||
## File Size Optimization
|
||||
|
||||
**CRITICAL:** Keep step files **LT 200 lines** (250 lines absolute maximum).
|
||||
|
||||
If a step exceeds this limit:
|
||||
- Consider splitting into multiple steps
|
||||
- Extract content to `/data/` reference files
|
||||
- Optimize verbose explanations
|
||||
|
||||
---
|
||||
|
||||
## Required Frontmatter Structure
|
||||
|
||||
CRITICAL: Frontmatter should only have items that are used in the step file!
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: 'step-2-foo.md'
|
||||
description: 'Brief description of what this step accomplishes'
|
||||
|
||||
# File References ## CRITICAL: Frontmatter references or variables should only have items that are used in the step file!
|
||||
outputFile: {bmb_creations_output_folder}/output-file-name.md
|
||||
nextStepFile: './step-3-bar.md'
|
||||
|
||||
# Task References (as needed)
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
# ... other task-specific references
|
||||
---
|
||||
```
|
||||
|
||||
### Frontmatter Field Descriptions
|
||||
|
||||
| Field | Required | Description |
|
||||
| --------------- | --------- | --------------------------------- |
|
||||
| `name` | Yes | Step identifier (kebab-case) |
|
||||
| `description` | Yes | One-line summary of step purpose |
|
||||
| `outputFile` | Yes | Where results are documented |
|
||||
| Task references | As needed | Paths to external workflows/tasks |
|
||||
|
||||
---
|
||||
|
||||
## Document Structure
|
||||
|
||||
### 1. Title
|
||||
|
||||
```markdown
|
||||
# Step X: [Step Name]
|
||||
```
|
||||
|
||||
### 2. STEP GOAL
|
||||
|
||||
```markdown
|
||||
## STEP GOAL:
|
||||
|
||||
[Single sentence stating what this step accomplishes]
|
||||
```
|
||||
|
||||
### 3. Role Reinforcement
|
||||
|
||||
```markdown
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a [specific role] who [does what]
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring [your expertise], user brings [their expertise], together we [achieve goal]
|
||||
- ✅ Maintain [tone/approach] throughout
|
||||
```
|
||||
|
||||
### 4. Language Preference
|
||||
|
||||
```markdown
|
||||
### Language Preference:
|
||||
The user has chosen to communicate in the **{language}** language.
|
||||
You MUST respond in **{language}** throughout this step.
|
||||
```
|
||||
|
||||
**IMPORTANT:** Read `userPreferences.language` from tracking file (agentPlan, validationReport, etc.) and enforce it.
|
||||
|
||||
### 5. Step-Specific Rules
|
||||
|
||||
```markdown
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on [specific scope]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
- 💬 Approach: [how to engage]
|
||||
- 📋 Ensure [specific outcome]
|
||||
```
|
||||
|
||||
### 6. EXECUTION PROTOCOLS
|
||||
|
||||
```markdown
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- [What to do - use verbs]
|
||||
- [Another action]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
```
|
||||
|
||||
### 7. CONTEXT BOUNDARIES
|
||||
|
||||
```markdown
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: [what's available]
|
||||
- Focus: [what to focus on]
|
||||
- Limits: [boundaries]
|
||||
- Dependencies: [what this step depends on]
|
||||
```
|
||||
|
||||
### 8. Sequence of Instructions
|
||||
|
||||
```markdown
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. [First Action]
|
||||
|
||||
**[Action Description]**
|
||||
|
||||
### 2. [Second Action]
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
### 9. MENU OPTIONS
|
||||
|
||||
```markdown
|
||||
### X. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [menu item A] [P] [menu item P] [C] [menu item C]"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#x-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
ONLY WHEN [C continue option] is selected and [completion conditions], will you then load and read fully `{nextStepFile}`...
|
||||
```
|
||||
|
||||
### 10. SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
```markdown
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- [Success criterion 1]
|
||||
- [Success criterion 2]
|
||||
- ...
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- [Failure criterion 1]
|
||||
- [Failure criterion 2]
|
||||
- ...
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## A/P/C Menu Convention
|
||||
|
||||
BMAD workflows use a fixed menu structure:
|
||||
|
||||
| Option | Meaning | Behavior |
|
||||
| ------ | -------------------- | ---------------------------------------------------- |
|
||||
| **A** | Advanced Elicitation | Execute advancedElicitationTask, then redisplay menu |
|
||||
| **P** | Party Mode | Execute partyModeWorkflow, then redisplay menu |
|
||||
| **C** | Continue/Accept | Save output, update frontmatter, load nextStepFile |
|
||||
| Other | Custom | Defined per step (e.g., F = Fix, X = Exit) |
|
||||
|
||||
**Rules:**
|
||||
- A and P MUST always be present
|
||||
- C MUST be present except in final step (use X or similar for exit)
|
||||
- After A/P → redisplay menu
|
||||
- After C → proceed to next step
|
||||
- Custom letters can be used for step-specific options
|
||||
|
||||
---
|
||||
|
||||
## Progressive Disclosure
|
||||
|
||||
**Core Principle:** Each step only knows about its immediate next step.
|
||||
|
||||
### Implementation
|
||||
|
||||
1. **Never pre-load future steps** - Only load `nextStepFile` when user selects [C]
|
||||
|
||||
2. **Mode-aware routing** (for shared steps):
|
||||
```markdown
|
||||
## MODE-AWARE ROUTING:
|
||||
### If entered from CREATE mode:
|
||||
Load ./s-next-step.md
|
||||
|
||||
### If entered from EDIT mode:
|
||||
Load ./e-next-step.md
|
||||
|
||||
### If entered from VALIDATE mode:
|
||||
Load ./v-next-step.md
|
||||
```
|
||||
|
||||
3. **Read tracking file first** - Always read the tracking file (agentPlan, validationReport, etc.) to determine current mode and routing
|
||||
|
||||
---
|
||||
|
||||
## Mode-Aware Routing (Shared Steps)
|
||||
|
||||
Shared steps (`s-*.md`) must route based on the mode stored in the tracking file.
|
||||
|
||||
### Tracking File Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
mode: create # or edit | validate
|
||||
stepsCompleted:
|
||||
- c-01-brainstorm.md
|
||||
- s-01-discovery.md
|
||||
# ... other tracking fields
|
||||
---
|
||||
```
|
||||
|
||||
### Routing Implementation
|
||||
|
||||
```markdown
|
||||
## COMPLETION ROUTING:
|
||||
|
||||
1. Append `./this-step-name.md` to {trackingFile}.stepsCompleted
|
||||
2. Save content to {trackingFile}
|
||||
3. Read {trackingFile}.mode
|
||||
4. Route based on mode:
|
||||
|
||||
### IF mode == create:
|
||||
Load ./s-next-create-step.md
|
||||
|
||||
### IF mode == edit:
|
||||
Load ./e-next-edit-step.md
|
||||
|
||||
### IF mode == validate:
|
||||
Load ./s-next-validate-step.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## File Naming Conventions
|
||||
|
||||
### Tri-Modal Workflows
|
||||
|
||||
| Prefix | Meaning | Example |
|
||||
| ------ | ------------------ | ---------------------- |
|
||||
| `c-` | Create-specific | `c-01-brainstorm.md` |
|
||||
| `e-` | Edit-specific | `e-01-load-analyze.md` |
|
||||
| `v-` | Validate-specific | `v-01-load-review.md` |
|
||||
| `s-` | Shared by 2+ modes | `s-05-activation.md` |
|
||||
|
||||
### Numbering
|
||||
|
||||
- Within each prefix type, number sequentially
|
||||
- Restart numbering for each prefix type (c-01, e-01, v-01, s-01)
|
||||
- Use letters for sub-steps (s-06a, s-06b, s-06c)
|
||||
|
||||
---
|
||||
|
||||
## Language Preference Enforcement
|
||||
|
||||
**CRITICAL:** Every step MUST respect the user's chosen language.
|
||||
|
||||
### Implementation
|
||||
|
||||
```markdown
|
||||
### Language Preference:
|
||||
The user has chosen to communicate in the **{language}** language.
|
||||
You MUST respond in **{language}** throughout this step.
|
||||
```
|
||||
|
||||
### Reading Language Preference
|
||||
|
||||
From tracking file frontmatter:
|
||||
```yaml
|
||||
---
|
||||
userPreferences:
|
||||
language: spanish # or any language
|
||||
---
|
||||
```
|
||||
|
||||
### Rules
|
||||
|
||||
- **MUST** read language preference from tracking file at step start
|
||||
- **MUST** respond in user's chosen language for ALL content
|
||||
- **MUST** include menu options in user's chosen language
|
||||
- **EXCEPTION:** Technical terms, file names, and code remain in English
|
||||
|
||||
---
|
||||
|
||||
## Data File References
|
||||
|
||||
When step content becomes too large (>200 lines), extract to `/data/` files:
|
||||
|
||||
### When to Extract
|
||||
|
||||
- Step file exceeds 200 lines
|
||||
- Content is reference material (rules, examples, patterns)
|
||||
- Content is reused across multiple steps
|
||||
|
||||
### How to Reference
|
||||
|
||||
```markdown
|
||||
## Reference Material:
|
||||
|
||||
Load and reference: `../data/{data-file-name}.md`
|
||||
|
||||
Key points from that file:
|
||||
- [Point 1]
|
||||
- [Point 2]
|
||||
```
|
||||
|
||||
### Data File Best Practices
|
||||
|
||||
- Keep data files focused on single topic
|
||||
- Use clear, descriptive names
|
||||
- Include examples and non-examples
|
||||
- Optimize for LLM usage (concise, structured)
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls to Avoid
|
||||
|
||||
### ❌ DON'T:
|
||||
|
||||
- Pre-load future steps (violates progressive disclosure)
|
||||
- Exceed 250 lines without splitting
|
||||
- Forget to update `stepsCompleted` array
|
||||
- Ignore user's language preference
|
||||
- Skip mode checking in shared steps
|
||||
- Use vague menu option letters (stick to A/P/C plus 1-2 custom)
|
||||
|
||||
### ✅ DO:
|
||||
|
||||
- Keep files under 200 lines
|
||||
- Read tracking file first thing
|
||||
- Route based on `mode` field
|
||||
- Include A/P in every menu
|
||||
- Use descriptive step names
|
||||
- Extract complex content to data files
|
||||
|
||||
---
|
||||
|
||||
## Template: New Step File
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 'step-name'
|
||||
description: 'What this step does'
|
||||
|
||||
# File References
|
||||
thisStepFile: ./step-name.md
|
||||
workflowFile: ../workflow.md
|
||||
outputFile: {bmb_creations_output_folder}/output.md
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step X: [Step Name]
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
[Single sentence goal]
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a [role] who [does what]
|
||||
- ✅ If you already have been given a name, communication_style and identity, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring [expertise], user brings [expertise], together we [achieve]
|
||||
- ✅ Maintain [tone] throughout
|
||||
|
||||
### Language Preference:
|
||||
The user has chosen to communicate in the **{language}** language.
|
||||
You MUST respond in **{language}** throughout this step.
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on [scope]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
- 💬 Approach: [how to engage]
|
||||
- 📋 Ensure [outcome]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- [Action 1]
|
||||
- [Action 2]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: [what's available]
|
||||
- Focus: [what to focus on]
|
||||
- Limits: [boundaries]
|
||||
- Dependencies: [what depends on what]
|
||||
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. [First Action]
|
||||
|
||||
**Description of first action**
|
||||
|
||||
### 2. [Second Action]
|
||||
|
||||
**Description of second action**
|
||||
|
||||
...
|
||||
|
||||
### X. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#x-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
ONLY WHEN [C continue option] is selected and [conditions], will you then load and read fully `{nextStepFile}`...
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
- [Success criteria]
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
- [Failure criteria]
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**End of Guidelines**
|
||||
|
|
@ -0,0 +1,139 @@
|
|||
---
|
||||
name: "step-{{stepNumber}}-{{stepName}}"
|
||||
description: "{{stepDescription}}"
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: "{project-root}/_bmad/{{targetModule}}/workflows/{{workflowName}}"
|
||||
|
||||
# File References
|
||||
thisStepFile: "{workflow_path}/steps/step-{{stepNumber}}-{{stepName}}.md"
|
||||
{{#hasNextStep}}
|
||||
nextStepFile: "{workflow_path}/steps/step-{{nextStepNumber}}-{{nextStepName}}.md"
|
||||
{{/hasNextStep}}
|
||||
workflowFile: "{workflow_path}/workflow.md"
|
||||
{{#hasOutput}}
|
||||
outputFile: "{output_folder}/{{outputFileName}}-{project_name}.md"
|
||||
{{/hasOutput}}
|
||||
|
||||
# Task References (list only if used in THIS step file instance and only the ones used, there might be others)
|
||||
advancedElicitationTask: "{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml"
|
||||
partyModeWorkflow: "{project-root}/_bmad/core/workflows/party-mode/workflow.md"
|
||||
|
||||
{{#hasTemplates}}
|
||||
# Template References
|
||||
{{#templates}}
|
||||
{{name}}: "{workflow_path}/templates/{{file}}"
|
||||
{{/templates}}
|
||||
{{/hasTemplates}}
|
||||
---
|
||||
|
||||
# Step {{stepNumber}}: {{stepTitle}}
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
{{stepGoal}}
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a {{aiRole}}
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring {{aiExpertise}}, user brings {{userExpertise}}
|
||||
- ✅ Maintain collaborative {{collaborationStyle}} tone throughout
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on {{stepFocus}}
|
||||
- 🚫 FORBIDDEN to {{forbiddenAction}}
|
||||
- 💬 Approach: {{stepApproach}}
|
||||
- 📋 {{additionalRule}}
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
{{#executionProtocols}}
|
||||
|
||||
- 🎯 {{.}}
|
||||
{{/executionProtocols}}
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: {{availableContext}}
|
||||
- Focus: {{contextFocus}}
|
||||
- Limits: {{contextLimits}}
|
||||
- Dependencies: {{contextDependencies}}
|
||||
|
||||
## SEQUENCE OF INSTRUCTIONS (Do not deviate, skip, or optimize)
|
||||
|
||||
{{#instructions}}
|
||||
|
||||
### {{number}}. {{title}}
|
||||
|
||||
{{content}}
|
||||
|
||||
{{#hasContentToAppend}}
|
||||
|
||||
#### Content to Append (if applicable):
|
||||
|
||||
```markdown
|
||||
{{contentToAppend}}
|
||||
```
|
||||
|
||||
{{/hasContentToAppend}}
|
||||
|
||||
{{/instructions}}
|
||||
|
||||
{{#hasMenu}}
|
||||
|
||||
### {{menuNumber}}. Present MENU OPTIONS
|
||||
|
||||
Display: **{{menuDisplay}}**
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
{{#menuOptions}}
|
||||
|
||||
- IF {{key}}: {{action}}
|
||||
{{/menuOptions}}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#{{menuNumber}}-present-menu-options)
|
||||
{{/hasMenu}}
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
{{completionNote}}
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
{{#successCriteria}}
|
||||
|
||||
- {{.}}
|
||||
{{/successCriteria}}
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
{{#failureModes}}
|
||||
|
||||
- {{.}}
|
||||
{{/failureModes}}
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -74,7 +74,7 @@ Example: "To analyze user requirements and document functional specifications th
|
|||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 🎯 [Step-specific protocol 1]
|
||||
- 💾 [Step-specific protocol 2 - e.g., document updates]
|
||||
- 📖 [Step-specific protocol 3 - e.g., tracking requirements]
|
||||
- 🚫 [Step-specific restriction]
|
||||
|
|
@ -86,9 +86,9 @@ Example: "To analyze user requirements and document functional specifications th
|
|||
- Limits: [what not to assume or do]
|
||||
- Dependencies: [what this step depends on]
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
[Detailed instructions for the step's work]
|
||||
|
||||
### 1. Title
|
||||
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
---
|
||||
name: { { workflowDisplayName } }
|
||||
description: { { workflowDescription } }
|
||||
web_bundle: { { webBundleFlag } }
|
||||
---
|
||||
|
||||
# {{workflowDisplayName}}
|
||||
|
||||
**Goal:** {{workflowGoal}}
|
||||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are also a {{aiRole}} collaborating with {{userType}}. This is a partnership, not a client-vendor relationship. You bring {{aiExpertise}}, while the user brings {{userExpertise}}. Work together as equals.
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
||||
This uses **step-file architecture** for disciplined execution:
|
||||
|
||||
### Core Principles
|
||||
|
||||
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
||||
6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
|
||||
|
||||
### Critical Rules (NO EXCEPTIONS)
|
||||
|
||||
- 🛑 **NEVER** load multiple step files simultaneously
|
||||
- 📖 **ALWAYS** read entire step file before execution
|
||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||
- 📋 **NEVER** create mental todo lists from future steps
|
||||
|
||||
---
|
||||
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Configuration Loading
|
||||
|
||||
Load and read full config from {project-root}/_bmad/{{targetModule}}/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Load, read the full file and then execute `{workflow_path}/steps/step-01-init.md` to begin the workflow.
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
# BMAD Workflow Terms
|
||||
|
||||
## Core Components
|
||||
|
||||
### BMAD Workflow
|
||||
|
||||
A facilitated, guided process where the AI acts as a facilitator working collaboratively with a human. Workflows can serve any purpose - from document creation to brainstorming, technical implementation, or decision-making. The human may be a collaborative partner, beginner seeking guidance, or someone who wants the AI to execute specific tasks. Each workflow is self-contained and follows a disciplined execution model.
|
||||
|
||||
### workflow.md
|
||||
|
||||
The master control file that defines:
|
||||
|
||||
- Workflow metadata (name, description, version)
|
||||
- Step sequence and file paths
|
||||
- Required data files and dependencies
|
||||
- Execution rules and protocols
|
||||
|
||||
### Step File
|
||||
|
||||
An individual markdown file containing:
|
||||
|
||||
- One discrete step of the workflow
|
||||
- All rules and context needed for that step
|
||||
- common global rules get repeated and reinforced also in each step file, ensuring even in long workflows the agent remembers important rules and guidelines
|
||||
- Content generation guidance
|
||||
|
||||
### step-01-init.md
|
||||
|
||||
The first step file that:
|
||||
|
||||
- Initializes the workflow
|
||||
- Sets up document frontmatter
|
||||
- Establishes initial context
|
||||
- Defines workflow parameters
|
||||
|
||||
### step-01b-continue.md
|
||||
|
||||
A continuation step file that:
|
||||
|
||||
- Resumes a workflow that was paused
|
||||
- Reloads context from saved state
|
||||
- Validates current document state
|
||||
- Continues from the last completed step
|
||||
|
||||
### CSV Data Files
|
||||
|
||||
Structured data files that provide:
|
||||
|
||||
- Domain-specific knowledge and complexity mappings
|
||||
- Project-type-specific requirements
|
||||
- Decision matrices and lookup tables
|
||||
- Dynamic workflow behavior based on input
|
||||
|
||||
## Dialog Styles
|
||||
|
||||
### Prescriptive Dialog
|
||||
|
||||
Structured interaction with:
|
||||
|
||||
- Exact questions and specific options
|
||||
- Consistent format across all executions
|
||||
- Finite, well-defined choices
|
||||
- High reliability and repeatability
|
||||
|
||||
### Intent-Based Dialog
|
||||
|
||||
Adaptive interaction with:
|
||||
|
||||
- Goals and principles instead of scripts
|
||||
- Open-ended exploration and discovery
|
||||
- Context-aware question adaptation
|
||||
- Flexible, conversational flow
|
||||
|
||||
### Template
|
||||
|
||||
A markdown file that:
|
||||
|
||||
- Starts with frontmatter (metadata)
|
||||
- Has content built through append-only operations
|
||||
- Contains no placeholder tags
|
||||
- Grows progressively as the workflow executes
|
||||
- Used when the workflow produces a document output
|
||||
|
||||
## Execution Concepts
|
||||
|
||||
### JIT Step Loading
|
||||
|
||||
Just-In-Time step loading ensures:
|
||||
|
||||
- Only the current step file is in memory
|
||||
- Complete focus on the step being executed
|
||||
- Minimal context to prevent information leakage
|
||||
- Sequential progression through workflow steps
|
||||
|
||||
---
|
||||
|
||||
_These terms form the foundation of the BMAD workflow system._
|
||||
|
|
@ -0,0 +1,171 @@
|
|||
# Edit Module Workflow
|
||||
|
||||
Interactive workflow for editing existing BMAD modules, including structure, agents, workflows, configuration, and documentation.
|
||||
|
||||
## Purpose
|
||||
|
||||
This workflow helps you improve and maintain BMAD modules by:
|
||||
|
||||
- Analyzing module structure against best practices
|
||||
- Managing agents and workflows within the module
|
||||
- Updating configuration and documentation
|
||||
- Ensuring cross-module integration works correctly
|
||||
- Maintaining installer configuration (for source modules)
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this workflow when you need to:
|
||||
|
||||
- Add new agents or workflows to a module
|
||||
- Update module configuration
|
||||
- Improve module documentation
|
||||
- Reorganize module structure
|
||||
- Set up cross-module workflow sharing
|
||||
- Fix issues in module organization
|
||||
- Update installer configuration
|
||||
|
||||
## What You'll Need
|
||||
|
||||
- Path to the module directory you want to edit
|
||||
- Understanding of what changes you want to make
|
||||
- Access to module documentation (loaded automatically)
|
||||
|
||||
## Workflow Steps
|
||||
|
||||
1. **Load and analyze target module** - Provide path to module directory
|
||||
2. **Analyze against best practices** - Automatic audit of module structure
|
||||
3. **Select editing focus** - Choose what aspect to edit
|
||||
4. **Load relevant documentation and tools** - Auto-loads guides and workflows
|
||||
5. **Perform edits** - Review and approve changes iteratively
|
||||
6. **Validate all changes** - Comprehensive validation checklist
|
||||
7. **Generate change summary** - Summary of improvements made
|
||||
|
||||
## Editing Options
|
||||
|
||||
The workflow provides 12 focused editing options:
|
||||
|
||||
1. **Fix critical issues** - Address missing files, broken references
|
||||
2. **Update module config** - Edit config.yaml fields
|
||||
3. **Manage agents** - Add, edit, or remove agents
|
||||
4. **Manage workflows** - Add, edit, or remove workflows
|
||||
5. **Update documentation** - Improve README files and guides
|
||||
6. **Reorganize structure** - Fix directory organization
|
||||
7. **Add new agent** - Create and integrate new agent
|
||||
8. **Add new workflow** - Create and integrate new workflow
|
||||
9. **Update installer** - Modify installer configuration (source only)
|
||||
10. **Cross-module integration** - Set up workflow sharing with other modules
|
||||
11. **Remove deprecated items** - Delete unused agents, workflows, or files
|
||||
12. **Full module review** - Comprehensive analysis and improvements
|
||||
|
||||
## Integration with Other Workflows
|
||||
|
||||
This workflow integrates with:
|
||||
|
||||
- **edit-agent** - For editing individual agents
|
||||
- **edit-workflow** - For editing individual workflows
|
||||
- **create-agent** - For adding new agents
|
||||
- **create-workflow** - For adding new workflows
|
||||
|
||||
When you select options to manage agents or workflows, the appropriate specialized workflow is invoked automatically.
|
||||
|
||||
## Module Structure
|
||||
|
||||
A proper BMAD module has:
|
||||
|
||||
```
|
||||
module-code/
|
||||
├── agents/ # Agent definitions
|
||||
│ └── *.agent.yaml
|
||||
├── workflows/ # Workflow definitions
|
||||
│ └── workflow-name/
|
||||
│ ├── workflow.yaml
|
||||
│ ├── instructions.md
|
||||
│ ├── checklist.md
|
||||
│ └── README.md
|
||||
├── config.yaml # Module configuration
|
||||
└── README.md # Module documentation
|
||||
```
|
||||
|
||||
## Standard Module Config
|
||||
|
||||
Every module config.yaml should have:
|
||||
|
||||
```yaml
|
||||
module_name: 'Full Module Name'
|
||||
module_code: 'xyz'
|
||||
user_name: 'User Name'
|
||||
communication_language: 'english'
|
||||
output_folder: 'path/to/output'
|
||||
```
|
||||
|
||||
Optional fields may be added for module-specific needs.
|
||||
|
||||
## Cross-Module Integration
|
||||
|
||||
Modules can share workflows:
|
||||
|
||||
```yaml
|
||||
# In agent menu item:
|
||||
workflow: '{project-root}/_bmad/other-module/workflows/shared-workflow/workflow.yaml'
|
||||
```
|
||||
|
||||
Common patterns:
|
||||
|
||||
- BMM uses CIS brainstorming workflows
|
||||
- All modules can use core workflows
|
||||
- Modules can invoke each other's workflows
|
||||
|
||||
## Output
|
||||
|
||||
The workflow modifies module files in place, including:
|
||||
|
||||
- config.yaml
|
||||
- Agent files
|
||||
- Workflow files
|
||||
- README and documentation files
|
||||
- Directory structure (if reorganizing)
|
||||
|
||||
Changes are reviewed and approved by you before being applied.
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Start with analysis** - Let the workflow audit your module first
|
||||
- **Use specialized workflows** - Let edit-agent and edit-workflow handle detailed edits
|
||||
- **Update documentation** - Keep README files current with changes
|
||||
- **Validate thoroughly** - Use the validation step to catch structural issues
|
||||
- **Test after editing** - Invoke agents and workflows to verify they work
|
||||
|
||||
## Tips
|
||||
|
||||
- For adding agents/workflows, use options 7-8 to create and integrate in one step
|
||||
- For quick config changes, use option 2 (update module config)
|
||||
- Cross-module integration (option 10) helps set up workflow sharing
|
||||
- Full module review (option 12) is great for inherited or legacy modules
|
||||
- The workflow handles path updates when you reorganize structure
|
||||
|
||||
## Example Usage
|
||||
|
||||
```
|
||||
User: I want to add a new workflow to BMM for API design
|
||||
Workflow: Analyzes BMM → You choose option 8 (add new workflow)
|
||||
→ Invokes create-workflow → Creates workflow
|
||||
→ Integrates it into module → Updates README → Done
|
||||
```
|
||||
|
||||
## Activation
|
||||
|
||||
Invoke via BMad Builder agent:
|
||||
|
||||
```
|
||||
/bmad:bmb:agents:bmad-builder
|
||||
Then select: *edit-module
|
||||
```
|
||||
|
||||
Or directly via workflow.xml with this workflow config.
|
||||
|
||||
## Related Resources
|
||||
|
||||
- **Module Structure Guide** - Comprehensive module architecture documentation
|
||||
- **BMM Module** - Example of full-featured module
|
||||
- **BMB Module** - Example of builder/tooling module
|
||||
- **CIS Module** - Example of workflow library module
|
||||
|
|
@ -0,0 +1,163 @@
|
|||
# Edit Module - Validation Checklist
|
||||
|
||||
Use this checklist to validate module edits meet BMAD Core standards.
|
||||
|
||||
## Module Structure Validation
|
||||
|
||||
- [ ] Module has clear abbreviation code (bmm, bmb, cis, etc.)
|
||||
- [ ] agents/ directory exists
|
||||
- [ ] workflows/ directory exists
|
||||
- [ ] config.yaml exists in module root
|
||||
- [ ] README.md exists in module root
|
||||
- [ ] Directory structure follows BMAD conventions
|
||||
|
||||
## Configuration Validation
|
||||
|
||||
### Required Fields
|
||||
|
||||
- [ ] module_name is descriptive and clear
|
||||
- [ ] module_code is 3-letter code matching directory name
|
||||
- [ ] user_name field present
|
||||
- [ ] communication_language field present
|
||||
- [ ] output_folder field present
|
||||
|
||||
### Optional Fields (if used)
|
||||
|
||||
- [ ] bmb_creations_output_folder documented
|
||||
- [ ] Module-specific fields documented in README
|
||||
|
||||
### File Quality
|
||||
|
||||
- [ ] config.yaml is valid YAML syntax
|
||||
- [ ] No duplicate keys
|
||||
- [ ] Values are appropriate types (strings, paths, etc.)
|
||||
- [ ] Comments explain non-obvious fields
|
||||
|
||||
## Agent Validation
|
||||
|
||||
### Agent Files
|
||||
|
||||
- [ ] All agents in agents/ directory
|
||||
- [ ] Agent files follow naming: {agent-name}.agent.yaml or .md
|
||||
- [ ] Agent filenames use kebab-case
|
||||
- [ ] No orphaned or temporary agent files
|
||||
|
||||
### Agent Content
|
||||
|
||||
- [ ] Each agent has clear role and purpose
|
||||
- [ ] Agents reference workflows correctly
|
||||
- [ ] Agent workflow paths are valid
|
||||
- [ ] Agents load module config correctly (if needed)
|
||||
- [ ] Agent menu items reference existing workflows
|
||||
|
||||
### Agent Integration
|
||||
|
||||
- [ ] All agents listed in module README
|
||||
- [ ] Agent relationships documented (if applicable)
|
||||
- [ ] Cross-agent workflows properly linked
|
||||
|
||||
## Workflow Validation
|
||||
|
||||
### Workflow Structure
|
||||
|
||||
- [ ] All workflows in workflows/ directory
|
||||
- [ ] Each workflow directory has workflow.yaml
|
||||
- [ ] Each workflow directory has instructions.md
|
||||
- [ ] Workflow directories use kebab-case naming
|
||||
- [ ] No orphaned or incomplete workflow directories
|
||||
|
||||
### Workflow Content
|
||||
|
||||
- [ ] workflow.yaml is valid YAML
|
||||
- [ ] workflow.yaml has name field
|
||||
- [ ] workflow.yaml has description field
|
||||
- [ ] workflow.yaml has author field
|
||||
- [ ] instructions.md has proper <workflow> structure
|
||||
- [ ] Workflow steps are numbered and logical
|
||||
|
||||
### Workflow Integration
|
||||
|
||||
- [ ] All workflows listed in module README
|
||||
- [ ] Workflow paths in agents are correct
|
||||
- [ ] Cross-module workflow references are valid
|
||||
- [ ] Sub-workflow references exist
|
||||
|
||||
## Documentation Validation
|
||||
|
||||
### Module README
|
||||
|
||||
- [ ] Module README describes purpose clearly
|
||||
- [ ] README lists all agents with descriptions
|
||||
- [ ] README lists all workflows with descriptions
|
||||
- [ ] README includes installation instructions (if applicable)
|
||||
- [ ] README explains module's role in BMAD ecosystem
|
||||
|
||||
### Workflow READMEs
|
||||
|
||||
- [ ] Each workflow has its own README.md
|
||||
- [ ] Workflow READMEs explain purpose
|
||||
- [ ] Workflow READMEs list inputs/outputs
|
||||
- [ ] Workflow READMEs include usage examples
|
||||
|
||||
### Other Documentation
|
||||
|
||||
- [ ] Usage guides present (if needed)
|
||||
- [ ] Architecture docs present (if complex module)
|
||||
- [ ] Examples provided (if applicable)
|
||||
|
||||
## Cross-References Validation
|
||||
|
||||
- [ ] Agent workflow references point to existing workflows
|
||||
- [ ] Workflow sub-workflow references are valid
|
||||
- [ ] Cross-module references use correct paths
|
||||
- [ ] Config file paths use {project-root} correctly
|
||||
- [ ] No hardcoded absolute paths
|
||||
|
||||
## Installer Validation (Source Modules Only)
|
||||
|
||||
- [ ] Installer script exists in tools/cli/installers/
|
||||
- [ ] Installer script name: install-{module-code}.js
|
||||
- [ ] Module metadata in installer is correct
|
||||
- [ ] Web bundle configuration valid (if applicable)
|
||||
- [ ] Installation paths are correct
|
||||
- [ ] Dependencies documented in installer
|
||||
|
||||
## Web Bundle Validation (If Applicable)
|
||||
|
||||
- [ ] Web bundles configured in workflow.yaml files
|
||||
- [ ] All referenced files included in web_bundle_files
|
||||
- [ ] Paths are _bmad/-relative (not project-root)
|
||||
- [ ] No config_source references in web bundles
|
||||
- [ ] Invoked workflows included in dependencies
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] No placeholder text remains ({MODULE_NAME}, {CODE}, etc.)
|
||||
- [ ] No broken file references
|
||||
- [ ] No duplicate content across files
|
||||
- [ ] Consistent naming conventions throughout
|
||||
- [ ] Module purpose is clear from README alone
|
||||
|
||||
## Integration Checks
|
||||
|
||||
- [ ] Module doesn't conflict with other modules
|
||||
- [ ] Shared resources properly documented
|
||||
- [ ] Dependencies on other modules explicit
|
||||
- [ ] Module can be installed independently (if designed that way)
|
||||
|
||||
## User Experience
|
||||
|
||||
- [ ] Module purpose is immediately clear
|
||||
- [ ] Agents have intuitive names
|
||||
- [ ] Workflows have descriptive names
|
||||
- [ ] Menu items are logically organized
|
||||
- [ ] Error messages are helpful
|
||||
- [ ] Success messages confirm actions
|
||||
|
||||
## Final Checks
|
||||
|
||||
- [ ] All files have been saved
|
||||
- [ ] File permissions are correct
|
||||
- [ ] Git status shows expected changes
|
||||
- [ ] Module is ready for testing
|
||||
- [ ] Documentation accurately reflects changes
|
||||
|
|
@ -0,0 +1,340 @@
|
|||
# Edit Module - Module Editor Instructions
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmb/workflows/edit-module/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 module">
|
||||
<ask>What is the path to the module source you want to edit?</ask>
|
||||
|
||||
<action>Load the module directory structure completely:
|
||||
|
||||
- Scan all directories and files
|
||||
- Load config.yaml
|
||||
- Load README.md
|
||||
- List all agents in agents/ directory
|
||||
- List all workflows in workflows/ directory
|
||||
- Identify any custom structure or patterns
|
||||
</action>
|
||||
|
||||
<action>Load ALL module documentation to inform understanding:
|
||||
|
||||
- Module structure guide: {module_structure_guide}
|
||||
- Study reference modules: BMM, BMB, CIS
|
||||
- Understand BMAD module patterns and conventions
|
||||
</action>
|
||||
|
||||
<action>Analyze the module deeply:
|
||||
|
||||
- Identify module purpose and role in BMAD ecosystem
|
||||
- Understand agent organization and relationships
|
||||
- Map workflow organization and dependencies
|
||||
- Evaluate config structure and completeness
|
||||
- Check documentation quality and currency
|
||||
- Assess installer configuration (if source module)
|
||||
- Identify cross-module integrations
|
||||
- Evaluate against best practices from loaded guides
|
||||
</action>
|
||||
|
||||
<action>Reflect understanding back to {user_name}:
|
||||
|
||||
Present a warm, conversational summary adapted to the module's complexity:
|
||||
|
||||
- What this module provides (its purpose and value in BMAD)
|
||||
- How it's organized (agents, workflows, structure)
|
||||
- What you notice (strengths, potential improvements, issues)
|
||||
- How it fits in the larger BMAD ecosystem
|
||||
- Your initial assessment based on best practices
|
||||
|
||||
Be conversational and insightful. Help {user_name} see their module through your eyes.
|
||||
</action>
|
||||
|
||||
<ask>Does this match your understanding of what this module should provide?</ask>
|
||||
<template-output>module_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 module?
|
||||
- What feedback have you gotten from users of this module?
|
||||
- Are there specific agents or workflows that need attention?
|
||||
- Is the module fulfilling its intended purpose?
|
||||
- Are there new capabilities you want to add?
|
||||
- How well does it integrate with other modules?
|
||||
- Is the documentation helping users understand and use the module?
|
||||
|
||||
Listen for clues about:
|
||||
|
||||
- Structural issues (poor organization, hard to navigate)
|
||||
- Agent/workflow issues (outdated, broken, missing functionality)
|
||||
- Configuration issues (missing fields, incorrect setup)
|
||||
- Documentation issues (outdated, incomplete, unclear)
|
||||
- Integration issues (doesn't work well with other modules)
|
||||
- Installer issues (installation problems, missing files)
|
||||
- User experience issues (confusing, hard to use)
|
||||
</action>
|
||||
|
||||
<action>Based on their responses and your analysis from step 1, identify improvement opportunities:
|
||||
|
||||
Organize by priority and user goals:
|
||||
|
||||
- CRITICAL issues blocking module functionality
|
||||
- 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>Collaborate on priorities:
|
||||
|
||||
Don't just list options - discuss them:
|
||||
|
||||
- "I noticed {{issue}} - this could make it hard for users to {{problem}}. Want to address this?"
|
||||
- "The module 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>
|
||||
<critical>For agent and workflow edits, invoke specialized workflows rather than doing inline</critical>
|
||||
|
||||
<action>For each improvement area, facilitate collaboratively:
|
||||
|
||||
1. **Explain the current state and why it matters**
|
||||
- Show relevant sections of the module
|
||||
- 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 reference modules: {bmm_module_dir}, {bmb_module_dir}, {cis_module_dir}
|
||||
- Reference agents from: {existing_agents_dir}
|
||||
- Reference workflows from: {existing_workflows_dir}
|
||||
- Reference the structure 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 appropriately**
|
||||
- For agent edits: Invoke edit-agent workflow
|
||||
- For workflow edits: Invoke edit-workflow workflow
|
||||
- For module-level changes: Make directly and iteratively
|
||||
- Show updates and confirm satisfaction
|
||||
</action>
|
||||
|
||||
<action>Common improvement patterns to facilitate:
|
||||
|
||||
**If improving module organization:**
|
||||
|
||||
- Discuss how the current structure serves (or doesn't serve) users
|
||||
- Propose reorganization that aligns with mental models
|
||||
- Consider feature-based vs type-based organization
|
||||
- Plan the reorganization steps
|
||||
- Update all references after moving files
|
||||
|
||||
**If updating module configuration:**
|
||||
|
||||
- Review current config.yaml fields
|
||||
- Check for missing standard fields (user_name, communication_language, output_folder)
|
||||
- Add module-specific fields as needed
|
||||
- Remove unused or outdated fields
|
||||
- Ensure config is properly documented
|
||||
|
||||
**If managing agents:**
|
||||
|
||||
- Ask which agent needs attention and why
|
||||
- For editing existing agent: <invoke-workflow path="{agent_editor}">
|
||||
- For adding new agent: Guide creation and integration
|
||||
- For removing agent: Confirm, remove, update references
|
||||
- Ensure all agent references in workflows remain valid
|
||||
|
||||
**If managing workflows:**
|
||||
|
||||
- Ask which workflow needs attention and why
|
||||
- For editing existing workflow: <invoke-workflow path="{workflow_editor}">
|
||||
- For adding new workflow: Guide creation and integration
|
||||
- For removing workflow: Confirm, remove, update agent references
|
||||
- Ensure all workflow files are properly organized
|
||||
|
||||
**If improving documentation:**
|
||||
|
||||
- Review current README and identify gaps
|
||||
- Discuss what users need to know
|
||||
- Update module overview and purpose
|
||||
- List agents and workflows with clear descriptions
|
||||
- Add usage examples if helpful
|
||||
- Ensure installation/setup instructions are clear
|
||||
|
||||
**If setting up cross-module integration:**
|
||||
|
||||
- Identify which workflows from other modules are needed
|
||||
- Show how to reference workflows properly: {project-root}/_bmad/{{module}}/workflows/{{workflow}}/workflow.yaml
|
||||
- Document the integration in README
|
||||
- Ensure dependencies are clear
|
||||
- Consider adding example usage
|
||||
|
||||
**If updating installer (source modules only):**
|
||||
|
||||
- Review installer script for correctness
|
||||
- Check web bundle configurations
|
||||
- Verify all files are included
|
||||
- Test installation paths
|
||||
- Update module metadata
|
||||
</action>
|
||||
|
||||
<action>When invoking specialized workflows:
|
||||
|
||||
Explain why you're handing off:
|
||||
|
||||
- "This agent needs detailed attention. Let me invoke the edit-agent workflow to give it proper focus."
|
||||
- "The workflow editor can handle this more thoroughly. I'll pass control there."
|
||||
|
||||
After the specialized workflow completes, return and continue:
|
||||
|
||||
- "Great! That agent/workflow is updated. Want to work on anything else in the module?"
|
||||
</action>
|
||||
|
||||
<action>Throughout improvements, educate when helpful:
|
||||
|
||||
Share insights from the guides naturally:
|
||||
|
||||
- "The module structure guide recommends {{pattern}} for this scenario"
|
||||
- "Looking at how BMM organized this, we could use {{approach}}"
|
||||
- "The BMAD convention is to {{pattern}} which helps with {{benefit}}"
|
||||
|
||||
Connect improvements to broader BMAD principles without being preachy.
|
||||
</action>
|
||||
|
||||
<ask>After each significant change:
|
||||
|
||||
- "Does this organization feel more intuitive?"
|
||||
- "Want to refine this further, or move to the next improvement?"
|
||||
- "How does this change affect users of the module?"
|
||||
</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 the module structure is solid..."
|
||||
- "Checking that all agent workflow references are valid..."
|
||||
- "Making sure config.yaml has all necessary fields..."
|
||||
- "Validating documentation is complete and accurate..."
|
||||
- "Ensuring cross-module references work correctly..."
|
||||
</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}} for users"
|
||||
- "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:
|
||||
|
||||
- Module structure is well-organized
|
||||
- All agent and workflow references are valid
|
||||
- Configuration is complete
|
||||
- Documentation is thorough and current
|
||||
- Cross-module integrations work properly
|
||||
- Installer is correct (if applicable)
|
||||
|
||||
Your module 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 module {{improved_capabilities}}"
|
||||
|
||||
Highlight the impact:
|
||||
|
||||
- "This means users will experience {{benefit}}"
|
||||
- "The module is now more {{quality}}"
|
||||
- "It follows best practices for {{patterns}}"
|
||||
</action>
|
||||
|
||||
<action>Guide next steps based on changes made:
|
||||
|
||||
If structure changed significantly:
|
||||
|
||||
- "Since we reorganized the structure, you should update any external references to this module"
|
||||
|
||||
If agents or workflows were updated:
|
||||
|
||||
- "The updated agents/workflows should be tested with real user interactions"
|
||||
|
||||
If cross-module integration was added:
|
||||
|
||||
- "Test the integration with {{other_module}} to ensure it works smoothly"
|
||||
|
||||
If installer was updated:
|
||||
|
||||
- "Test the installation process to verify all files are included correctly"
|
||||
|
||||
If this is part of larger BMAD work:
|
||||
|
||||
- "Consider if patterns from this module could benefit other modules"
|
||||
|
||||
Be a helpful guide to what comes next, not just a task completer.
|
||||
</action>
|
||||
|
||||
<ask>Would you like to:
|
||||
|
||||
- Test the edited module by invoking one of its agents
|
||||
- Edit a specific agent or workflow in more detail
|
||||
- Make additional refinements to the module
|
||||
- Work on a different module
|
||||
</ask>
|
||||
|
||||
<template-output>completion_summary</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
# Edit Module - Module Editor Configuration
|
||||
name: "edit-module"
|
||||
description: "Edit existing BMAD modules (structure, agents, workflows, documentation) while following all best practices"
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables load from config_source
|
||||
config_source: "{project-root}/_bmad/bmb/config.yaml"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
user_name: "{config_source}:user_name"
|
||||
|
||||
# Required Data Files - Critical for understanding module conventions
|
||||
module_structure_guide: "{project-root}/_bmad/bmb/workflows/create-module/module-structure.md"
|
||||
|
||||
# Related workflow editors
|
||||
agent_editor: "{project-root}/_bmad/bmb/workflows/edit-agent/workflow.yaml"
|
||||
workflow_editor: "{project-root}/_bmad/bmb/workflows/edit-workflow/workflow.yaml"
|
||||
|
||||
# Reference examples - for learning patterns
|
||||
bmm_module_dir: "{project-root}/_bmad/bmm/"
|
||||
bmb_module_dir: "{project-root}/_bmad/bmb/"
|
||||
cis_module_dir: "{project-root}/_bmad/cis/"
|
||||
existing_agents_dir: "{project-root}/_bmad/*/agents/"
|
||||
existing_workflows_dir: "{project-root}/_bmad/*/workflows/"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/_bmad/bmb/workflows/edit-module"
|
||||
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
|
||||
|
|
@ -0,0 +1,264 @@
|
|||
# Module Brief Workflow
|
||||
|
||||
## Overview
|
||||
|
||||
The Module Brief workflow creates comprehensive blueprints for building new BMAD modules using strategic analysis and creative vision. It serves as the essential planning phase that transforms initial ideas into detailed, actionable specifications ready for implementation with the create-module workflow.
|
||||
|
||||
## Key Features
|
||||
|
||||
- **Strategic Module Planning** - Comprehensive analysis from concept to implementation roadmap
|
||||
- **Multi-Mode Operation** - Interactive, Express, and YOLO modes for different planning needs
|
||||
- **Creative Vision Development** - Guided process for innovative module concepts and unique value propositions
|
||||
- **Architecture Design** - Detailed agent and workflow ecosystem planning with interaction models
|
||||
- **User Journey Mapping** - Scenario-based validation ensuring practical usability
|
||||
- **Technical Planning** - Infrastructure requirements, dependencies, and complexity assessment
|
||||
- **Risk Assessment** - Proactive identification of challenges with mitigation strategies
|
||||
- **Implementation Roadmap** - Phased development plan with clear deliverables and timelines
|
||||
|
||||
## Usage
|
||||
|
||||
### Basic Invocation
|
||||
|
||||
```bash
|
||||
workflow module-brief
|
||||
```
|
||||
|
||||
### With Brainstorming Input
|
||||
|
||||
```bash
|
||||
# If you have brainstorming results from previous sessions
|
||||
workflow module-brief --input brainstorming-session-2024-09-26.md
|
||||
```
|
||||
|
||||
### Express Mode
|
||||
|
||||
```bash
|
||||
# For quick essential planning only
|
||||
workflow module-brief --mode express
|
||||
```
|
||||
|
||||
### Configuration
|
||||
|
||||
The workflow uses standard BMB configuration:
|
||||
|
||||
- **output_folder**: Where the module brief will be saved
|
||||
- **user_name**: Brief author information
|
||||
- **communication_language**: Language for brief generation
|
||||
- **date**: Automatic timestamp for versioning
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
### Files Included
|
||||
|
||||
```
|
||||
module-brief/
|
||||
├── workflow.yaml # Configuration and metadata
|
||||
├── instructions.md # Step-by-step execution guide
|
||||
├── template.md # Module brief document structure
|
||||
├── checklist.md # Validation criteria
|
||||
└── README.md # This file
|
||||
```
|
||||
|
||||
## Workflow Process
|
||||
|
||||
### Phase 1: Foundation and Context (Steps 1-3)
|
||||
|
||||
**Mode Selection and Input Gathering**
|
||||
|
||||
- Choose operational mode (Interactive, Express, YOLO)
|
||||
- Check for and optionally load existing brainstorming results
|
||||
- Gather background context and inspiration sources
|
||||
|
||||
**Module Vision Development**
|
||||
|
||||
- Define core problem the module solves
|
||||
- Identify target user audience and use cases
|
||||
- Establish unique value proposition and differentiators
|
||||
- Explore creative themes and personality concepts
|
||||
|
||||
**Module Identity Establishment**
|
||||
|
||||
- Generate module code (kebab-case) with multiple options
|
||||
- Create compelling, memorable module name
|
||||
- Select appropriate category (Domain-Specific, Creative, Technical, Business, Personal)
|
||||
- Define optional personality theme for consistent agent character
|
||||
|
||||
### Phase 2: Architecture Planning (Steps 4-5)
|
||||
|
||||
**Agent Architecture Design**
|
||||
|
||||
- Plan agent team composition and roles
|
||||
- Define agent archetypes (Orchestrator, Specialist, Helper, Creator, Analyzer)
|
||||
- Specify personality traits and communication styles
|
||||
- Map key capabilities and signature commands
|
||||
|
||||
**Workflow Ecosystem Design**
|
||||
|
||||
- Categorize workflows by purpose and complexity:
|
||||
- **Core Workflows**: Essential value-delivery functions (2-3)
|
||||
- **Feature Workflows**: Specialized capabilities (3-5)
|
||||
- **Utility Workflows**: Supporting operations (1-3)
|
||||
- Define input-process-output flows for each workflow
|
||||
- Assess complexity levels and implementation priorities
|
||||
|
||||
### Phase 3: Validation and User Experience (Steps 6-7)
|
||||
|
||||
**User Journey Mapping**
|
||||
|
||||
- Create detailed user scenarios and stories
|
||||
- Map step-by-step usage flows through the module
|
||||
- Validate end-to-end functionality and value delivery
|
||||
- Identify potential friction points and optimization opportunities
|
||||
|
||||
**Technical Planning and Requirements**
|
||||
|
||||
- Assess data requirements and storage needs
|
||||
- Map integration points with other modules and external systems
|
||||
- Evaluate technical complexity and resource requirements
|
||||
- Document dependencies and infrastructure needs
|
||||
|
||||
### Phase 4: Success Planning (Steps 8-9)
|
||||
|
||||
**Success Metrics Definition**
|
||||
|
||||
- Establish module success criteria and performance indicators
|
||||
- Define quality standards and reliability requirements
|
||||
- Create user experience goals and feedback mechanisms
|
||||
- Set measurable outcomes for module effectiveness
|
||||
|
||||
**Development Roadmap Creation**
|
||||
|
||||
- Design phased approach with MVP, Enhancement, and Polish phases
|
||||
- Define deliverables and timelines for each phase
|
||||
- Prioritize features and capabilities by value and complexity
|
||||
- Create clear milestones and success checkpoints
|
||||
|
||||
### Phase 5: Enhancement and Risk Management (Steps 10-12)
|
||||
|
||||
**Creative Features and Special Touches** (Optional)
|
||||
|
||||
- Design easter eggs and delightful user interactions
|
||||
- Plan module lore and thematic consistency
|
||||
- Add personality quirks and creative responses
|
||||
- Develop backstories and universe building
|
||||
|
||||
**Risk Assessment and Mitigation**
|
||||
|
||||
- Identify technical, usability, and scope risks
|
||||
- Develop mitigation strategies for each risk category
|
||||
- Plan contingency approaches for potential challenges
|
||||
- Document decision points and alternative paths
|
||||
|
||||
**Final Review and Export Preparation**
|
||||
|
||||
- Comprehensive review of all brief sections
|
||||
- Validation against quality and completeness criteria
|
||||
- Preparation for seamless handoff to create-module workflow
|
||||
- Export readiness confirmation with actionable specifications
|
||||
|
||||
## Output
|
||||
|
||||
### Generated Files
|
||||
|
||||
- **Module Brief Document**: Comprehensive planning document at `{output_folder}/module-brief-{module_code}-{date}.md`
|
||||
- **Strategic Specifications**: Ready-to-implement blueprint for create-module workflow
|
||||
|
||||
### Output Structure
|
||||
|
||||
The module brief contains detailed specifications across multiple sections:
|
||||
|
||||
1. **Executive Summary** - Vision, category, complexity, target users
|
||||
2. **Module Identity** - Core concept, value proposition, personality theme
|
||||
3. **Agent Architecture** - Agent roster, roles, interaction models
|
||||
4. **Workflow Ecosystem** - Core, feature, and utility workflow specifications
|
||||
5. **User Scenarios** - Primary use cases, secondary scenarios, user journey
|
||||
6. **Technical Planning** - Data requirements, integrations, dependencies
|
||||
7. **Success Metrics** - Success criteria, quality standards, performance targets
|
||||
8. **Development Roadmap** - Phased implementation plan with deliverables
|
||||
9. **Creative Features** - Special touches, easter eggs, module lore
|
||||
10. **Risk Assessment** - Technical, usability, scope risks with mitigation
|
||||
11. **Implementation Notes** - Priority order, design decisions, open questions
|
||||
12. **Resources and References** - Inspiration sources, similar modules, technical references
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Creative Vision** - Initial module concept or problem domain
|
||||
- **Strategic Thinking** - Ability to plan architecture and user experience
|
||||
- **Brainstorming Results** (optional) - Previous ideation sessions enhance planning quality
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Before Starting
|
||||
|
||||
1. **Gather Inspiration** - Research similar tools, modules, and solutions in your domain
|
||||
2. **Run Brainstorming Session** - Use ideation techniques to generate initial concepts
|
||||
3. **Define Success Criteria** - Know what "successful module" means for your context
|
||||
|
||||
### During Execution
|
||||
|
||||
1. **Think User-First** - Always consider the end user experience and value delivery
|
||||
2. **Be Specific** - Provide concrete examples and detailed specifications rather than abstractions
|
||||
3. **Validate Early** - Use user scenarios to test if the module concept actually works
|
||||
4. **Plan Iteratively** - Start with MVP and build complexity through phases
|
||||
|
||||
### After Completion
|
||||
|
||||
1. **Use as Blueprint** - Feed the brief directly into create-module workflow for implementation
|
||||
2. **Review with Stakeholders** - Validate assumptions and gather feedback before building
|
||||
3. **Update as Needed** - Treat as living document that evolves with implementation learnings
|
||||
4. **Reference During Development** - Use as north star for design decisions and scope management
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Issue**: Stuck on module concept or vision
|
||||
|
||||
- **Solution**: Use creative prompts provided in the workflow
|
||||
- **Check**: Review existing modules for inspiration and patterns
|
||||
|
||||
**Issue**: Agent or workflow architecture too complex
|
||||
|
||||
- **Solution**: Focus on MVP first, plan enhancement phases for additional complexity
|
||||
- **Check**: Validate each component against user scenarios
|
||||
|
||||
**Issue**: Technical requirements unclear
|
||||
|
||||
- **Solution**: Research similar modules and their implementation approaches
|
||||
- **Check**: Consult with technical stakeholders early in planning
|
||||
|
||||
**Issue**: Scope creep during planning
|
||||
|
||||
- **Solution**: Use phased roadmap to defer non-essential features
|
||||
- **Check**: Regularly validate against core user scenarios and success criteria
|
||||
|
||||
## Customization
|
||||
|
||||
To customize this workflow:
|
||||
|
||||
1. **Modify Template Structure** - Update template.md to add new sections or reorganize content
|
||||
2. **Extend Creative Prompts** - Add domain-specific ideation techniques in instructions.md
|
||||
3. **Add Planning Tools** - Integrate additional analysis frameworks or planning methodologies
|
||||
4. **Customize Validation** - Enhance checklist.md with specific quality criteria for your context
|
||||
|
||||
## Version History
|
||||
|
||||
- **v1.0.0** - Initial release
|
||||
- Comprehensive strategic module planning
|
||||
- Multi-mode operation (Interactive, Express, YOLO)
|
||||
- Creative vision and architecture design tools
|
||||
- User journey mapping and validation
|
||||
- Risk assessment and mitigation planning
|
||||
|
||||
## Support
|
||||
|
||||
For issues or questions:
|
||||
|
||||
- Review the workflow creation guide at `/_bmad/bmb/workflows/create-workflow/workflow-creation-guide.md`
|
||||
- Study existing module examples in `/_bmad/` for patterns and inspiration
|
||||
- Validate output using `checklist.md`
|
||||
- Consult module structure guide at `create-module/module-structure.md`
|
||||
|
||||
---
|
||||
|
||||
_Part of the BMad Method v6 - BMB (Builder) Module_
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
# Module Brief Validation Checklist
|
||||
|
||||
## Core Identity
|
||||
|
||||
- [ ] Module code follows kebab-case convention
|
||||
- [ ] Module name is clear and memorable
|
||||
- [ ] Module category is identified
|
||||
- [ ] Target users are clearly defined
|
||||
- [ ] Unique value proposition is articulated
|
||||
|
||||
## Vision and Concept
|
||||
|
||||
- [ ] Problem being solved is clearly stated
|
||||
- [ ] Solution approach is explained
|
||||
- [ ] Module scope is well-defined
|
||||
- [ ] Success criteria are measurable
|
||||
|
||||
## Agent Architecture
|
||||
|
||||
- [ ] At least one agent is defined
|
||||
- [ ] Each agent has a clear role and purpose
|
||||
- [ ] Agent personalities are defined (if using personality themes)
|
||||
- [ ] Agent interactions are mapped (for multi-agent modules)
|
||||
- [ ] Key commands for each agent are listed
|
||||
|
||||
## Workflow Ecosystem
|
||||
|
||||
- [ ] Core workflows (2-3) are identified
|
||||
- [ ] Each workflow has clear purpose
|
||||
- [ ] Workflow complexity is assessed
|
||||
- [ ] Input/output for workflows is defined
|
||||
- [ ] Workflow categories are logical
|
||||
|
||||
## User Experience
|
||||
|
||||
- [ ] Primary use case is documented
|
||||
- [ ] User scenarios demonstrate value
|
||||
- [ ] User journey is realistic
|
||||
- [ ] Learning curve is considered
|
||||
- [ ] User feedback mechanism planned
|
||||
|
||||
## Technical Planning
|
||||
|
||||
- [ ] Data requirements are identified
|
||||
- [ ] Integration points are mapped
|
||||
- [ ] Dependencies are listed
|
||||
- [ ] Technical complexity is assessed
|
||||
- [ ] Performance requirements stated
|
||||
|
||||
## Development Roadmap
|
||||
|
||||
- [ ] Phase 1 MVP is clearly scoped
|
||||
- [ ] Phase 2 enhancements are outlined
|
||||
- [ ] Phase 3 polish items listed
|
||||
- [ ] Timeline estimates provided
|
||||
- [ ] Deliverables are specific
|
||||
|
||||
## Risk Management
|
||||
|
||||
- [ ] Technical risks identified
|
||||
- [ ] Usability risks considered
|
||||
- [ ] Scope risks acknowledged
|
||||
- [ ] Mitigation strategies provided
|
||||
- [ ] Open questions documented
|
||||
|
||||
## Creative Elements (Optional)
|
||||
|
||||
- [ ] Personality theme is consistent (if used)
|
||||
- [ ] Special features add value
|
||||
- [ ] Module feels cohesive
|
||||
- [ ] Fun elements don't compromise functionality
|
||||
|
||||
## Documentation Quality
|
||||
|
||||
- [ ] All sections have content (no empty placeholders)
|
||||
- [ ] Writing is clear and concise
|
||||
- [ ] Technical terms are explained
|
||||
- [ ] Examples are provided where helpful
|
||||
- [ ] Next steps are actionable
|
||||
|
||||
## Implementation Readiness
|
||||
|
||||
- [ ] Brief provides enough detail for create-module workflow
|
||||
- [ ] Agent specifications sufficient for create-agent workflow
|
||||
- [ ] Workflow descriptions ready for create-workflow
|
||||
- [ ] Resource requirements are clear
|
||||
- [ ] Success metrics are measurable
|
||||
|
||||
## Final Validation
|
||||
|
||||
- [ ] Module concept is viable
|
||||
- [ ] Scope is achievable
|
||||
- [ ] Value is clear
|
||||
- [ ] Brief is complete
|
||||
- [ ] Ready for development
|
||||
|
||||
## Issues Found
|
||||
|
||||
### Critical Issues
|
||||
|
||||
<!-- Must be fixed before proceeding to build -->
|
||||
|
||||
### Recommendations
|
||||
|
||||
<!-- Suggested improvements -->
|
||||
|
||||
### Nice-to-Haves
|
||||
|
||||
<!-- Optional enhancements -->
|
||||
|
||||
---
|
||||
|
||||
**Validation Complete:** ⬜ Yes / ⬜ With Issues / ⬜ Needs Revision
|
||||
|
||||
**Validated By:** {name}
|
||||
**Date:** {date}
|
||||
|
|
@ -0,0 +1,268 @@
|
|||
# Module Brief Instructions
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {project-root}/_bmad/bmb/workflows/module-brief/workflow.yaml</critical>
|
||||
<critical>Communicate in {communication_language} throughout the module brief 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="Setup and context gathering">
|
||||
<action>Ask the user which mode they prefer:</action>
|
||||
1. **Interactive Mode** - Work through each section collaboratively with detailed questions
|
||||
2. **Express Mode** - Quick essential questions only
|
||||
3. **YOLO Mode** (#yolo) - Generate complete draft based on minimal input
|
||||
|
||||
<action>Check for available inputs:</action>
|
||||
|
||||
- Brainstorming results from previous sessions
|
||||
- Existing module ideas or notes
|
||||
- Similar modules for inspiration
|
||||
|
||||
<action>If brainstorming results exist, offer to load and incorporate them</action>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Module concept and vision">
|
||||
Ask the user to describe their module idea. Probe for:
|
||||
- What problem does this module solve?
|
||||
- Who would use this module?
|
||||
- What makes this module exciting or unique?
|
||||
- Any inspiring examples or similar tools?
|
||||
|
||||
If they're stuck, offer creative prompts:
|
||||
|
||||
- "Imagine you're a [role], what tools would make your life easier?"
|
||||
- "What repetitive tasks could be automated with agents?"
|
||||
- "What domain expertise could be captured in workflows?"
|
||||
|
||||
<template-output>module_vision</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define module identity">
|
||||
Based on the vision, work with user to define:
|
||||
|
||||
**Module Code** (kebab-case):
|
||||
|
||||
- Suggest 2-3 options based on their description
|
||||
- Ensure it's memorable and descriptive
|
||||
|
||||
**Module Name** (friendly):
|
||||
|
||||
- Creative, engaging name that captures the essence
|
||||
|
||||
**Module Category:**
|
||||
|
||||
- Domain-Specific (legal, medical, finance)
|
||||
- Creative (writing, gaming, music)
|
||||
- Technical (devops, testing, architecture)
|
||||
- Business (project management, marketing)
|
||||
- Personal (productivity, learning)
|
||||
|
||||
**Personality Theme** (optional but fun!):
|
||||
|
||||
- Should the module have a consistent personality across agents?
|
||||
- Star Trek crew? Fantasy party? Corporate team? Reality show cast?
|
||||
|
||||
<template-output>module_identity</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Agent architecture planning">
|
||||
<action>Help user envision their agent team</action>
|
||||
|
||||
For each agent, capture:
|
||||
|
||||
- **Role**: What's their specialty?
|
||||
- **Personality**: How do they communicate? (reference communication styles)
|
||||
- **Key Capabilities**: What can they do?
|
||||
- **Signature Commands**: 2-3 main commands
|
||||
|
||||
Suggest agent archetypes based on module type:
|
||||
|
||||
- The Orchestrator (manages other agents)
|
||||
- The Specialist (deep expertise)
|
||||
- The Helper (utility functions)
|
||||
- The Creator (generates content)
|
||||
- The Analyzer (processes and evaluates)
|
||||
|
||||
<template-output>agent_architecture</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Workflow ecosystem design">
|
||||
<action>Map out the workflow landscape</action>
|
||||
|
||||
Categorize workflows:
|
||||
|
||||
**Core Workflows** (2-3 essential ones):
|
||||
|
||||
- The primary value-delivery workflows
|
||||
- What users will use most often
|
||||
|
||||
**Feature Workflows** (3-5 specialized):
|
||||
|
||||
- Specific capabilities
|
||||
- Advanced features
|
||||
|
||||
**Utility Workflows** (1-3 supporting):
|
||||
|
||||
- Setup, configuration
|
||||
- Maintenance, cleanup
|
||||
|
||||
For each workflow, define:
|
||||
|
||||
- Purpose (one sentence)
|
||||
- Input → Process → Output
|
||||
- Complexity (simple/standard/complex)
|
||||
|
||||
<template-output>workflow_ecosystem</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="User journey and scenarios">
|
||||
<action>Create usage scenarios to validate the design</action>
|
||||
|
||||
Write 2-3 user stories:
|
||||
"As a [user type], I want to [goal], so that [outcome]"
|
||||
|
||||
Then walk through how they'd use the module:
|
||||
|
||||
1. They load [agent]
|
||||
2. They run [command/workflow]
|
||||
3. They get [result]
|
||||
4. This helps them [achievement]
|
||||
|
||||
This validates the module makes sense end-to-end.
|
||||
|
||||
<template-output>user_scenarios</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Technical and resource planning">
|
||||
Assess technical requirements:
|
||||
|
||||
**Data Requirements:**
|
||||
|
||||
- What data/files does the module need?
|
||||
- Any external APIs or services?
|
||||
- Storage or state management needs?
|
||||
|
||||
**Integration Points:**
|
||||
|
||||
- Other BMAD modules it might use
|
||||
- External tools or platforms
|
||||
- Import/export formats
|
||||
|
||||
**Complexity Assessment:**
|
||||
|
||||
- Simple (standalone, no dependencies)
|
||||
- Standard (some integrations, moderate complexity)
|
||||
- Complex (multiple systems, advanced features)
|
||||
|
||||
<template-output>technical_planning</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Success metrics and validation">
|
||||
Define what success looks like:
|
||||
|
||||
**Module Success Criteria:**
|
||||
|
||||
- What indicates the module is working well?
|
||||
- How will users measure value?
|
||||
- What feedback mechanisms?
|
||||
|
||||
**Quality Standards:**
|
||||
|
||||
- Performance expectations
|
||||
- Reliability requirements
|
||||
- User experience goals
|
||||
|
||||
<template-output>success_metrics</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Development roadmap">
|
||||
Create a phased approach:
|
||||
|
||||
**Phase 1 - MVP (Minimum Viable Module):**
|
||||
|
||||
- 1 primary agent
|
||||
- 2-3 core workflows
|
||||
- Basic functionality
|
||||
|
||||
**Phase 2 - Enhancement:**
|
||||
|
||||
- Additional agents
|
||||
- More workflows
|
||||
- Refined features
|
||||
|
||||
**Phase 3 - Polish:**
|
||||
|
||||
- Advanced features
|
||||
- Optimizations
|
||||
- Nice-to-haves
|
||||
|
||||
<template-output>development_roadmap</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Creative flourishes and special features" optional="true">
|
||||
<action>If user wants to add special touches:</action>
|
||||
|
||||
**Easter Eggs:**
|
||||
|
||||
- Hidden commands or responses
|
||||
- Fun interactions between agents
|
||||
|
||||
**Delighters:**
|
||||
|
||||
- Unexpected helpful features
|
||||
- Personality quirks
|
||||
- Creative responses
|
||||
|
||||
**Module Lore:**
|
||||
|
||||
- Backstory for agents
|
||||
- Thematic elements
|
||||
- Consistent universe
|
||||
|
||||
<template-output>creative_features</template-output>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Risk assessment and mitigation">
|
||||
Identify potential challenges:
|
||||
|
||||
**Technical Risks:**
|
||||
|
||||
- Complex integrations
|
||||
- Performance concerns
|
||||
- Dependency issues
|
||||
|
||||
**Usability Risks:**
|
||||
|
||||
- Learning curve
|
||||
- Complexity creep
|
||||
- User confusion
|
||||
|
||||
**Scope Risks:**
|
||||
|
||||
- Feature bloat
|
||||
- Timeline expansion
|
||||
- Resource constraints
|
||||
|
||||
For each risk, note mitigation strategy.
|
||||
|
||||
<template-output>risk_assessment</template-output>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Final review and export readiness">
|
||||
<action>Review all sections with {user_name}</action>
|
||||
<action>Ensure module brief is ready for create-module workflow</action>
|
||||
|
||||
<ask>Would {user_name} like to:
|
||||
|
||||
1. Proceed directly to create-module workflow
|
||||
2. Save and refine later
|
||||
3. Generate additional planning documents
|
||||
</ask>
|
||||
|
||||
<action>Inform {user_name} in {communication_language} that this brief can be fed directly into create-module workflow</action>
|
||||
|
||||
<template-output>final_brief</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
|
|
@ -0,0 +1,275 @@
|
|||
# Module Brief: {{module_name}}
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Module Code:** {{module_code}}
|
||||
**Status:** Ready for Development
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{module_vision}}
|
||||
|
||||
**Module Category:** {{module_category}}
|
||||
**Complexity Level:** {{complexity_level}}
|
||||
**Target Users:** {{target_users}}
|
||||
|
||||
---
|
||||
|
||||
## Module Identity
|
||||
|
||||
### Core Concept
|
||||
|
||||
{{module_identity}}
|
||||
|
||||
### Unique Value Proposition
|
||||
|
||||
What makes this module special:
|
||||
{{unique_value}}
|
||||
|
||||
### Personality Theme
|
||||
|
||||
{{personality_theme}}
|
||||
|
||||
---
|
||||
|
||||
## Agent Architecture
|
||||
|
||||
{{agent_architecture}}
|
||||
|
||||
### Agent Roster
|
||||
|
||||
{{agent_roster}}
|
||||
|
||||
### Agent Interaction Model
|
||||
|
||||
How agents work together:
|
||||
{{agent_interactions}}
|
||||
|
||||
---
|
||||
|
||||
## Workflow Ecosystem
|
||||
|
||||
{{workflow_ecosystem}}
|
||||
|
||||
### Core Workflows
|
||||
|
||||
Essential functionality that delivers primary value:
|
||||
{{core_workflows}}
|
||||
|
||||
### Feature Workflows
|
||||
|
||||
Specialized capabilities that enhance the module:
|
||||
{{feature_workflows}}
|
||||
|
||||
### Utility Workflows
|
||||
|
||||
Supporting operations and maintenance:
|
||||
{{utility_workflows}}
|
||||
|
||||
---
|
||||
|
||||
## User Scenarios
|
||||
|
||||
### Primary Use Case
|
||||
|
||||
{{primary_scenario}}
|
||||
|
||||
### Secondary Use Cases
|
||||
|
||||
{{secondary_scenarios}}
|
||||
|
||||
### User Journey
|
||||
|
||||
Step-by-step walkthrough of typical usage:
|
||||
{{user_journey}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Planning
|
||||
|
||||
### Data Requirements
|
||||
|
||||
{{data_requirements}}
|
||||
|
||||
### Integration Points
|
||||
|
||||
{{integration_points}}
|
||||
|
||||
### Dependencies
|
||||
|
||||
{{dependencies}}
|
||||
|
||||
### Technical Complexity Assessment
|
||||
|
||||
{{technical_planning}}
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Module Success Criteria
|
||||
|
||||
How we'll know the module is successful:
|
||||
{{success_criteria}}
|
||||
|
||||
### Quality Standards
|
||||
|
||||
{{quality_standards}}
|
||||
|
||||
### Performance Targets
|
||||
|
||||
{{performance_targets}}
|
||||
|
||||
---
|
||||
|
||||
## Development Roadmap
|
||||
|
||||
### Phase 1: MVP (Minimum Viable Module)
|
||||
|
||||
**Timeline:** {{phase1_timeline}}
|
||||
|
||||
{{phase1_components}}
|
||||
|
||||
**Deliverables:**
|
||||
{{phase1_deliverables}}
|
||||
|
||||
### Phase 2: Enhancement
|
||||
|
||||
**Timeline:** {{phase2_timeline}}
|
||||
|
||||
{{phase2_components}}
|
||||
|
||||
**Deliverables:**
|
||||
{{phase2_deliverables}}
|
||||
|
||||
### Phase 3: Polish and Optimization
|
||||
|
||||
**Timeline:** {{phase3_timeline}}
|
||||
|
||||
{{phase3_components}}
|
||||
|
||||
**Deliverables:**
|
||||
{{phase3_deliverables}}
|
||||
|
||||
---
|
||||
|
||||
## Creative Features
|
||||
|
||||
### Special Touches
|
||||
|
||||
{{creative_features}}
|
||||
|
||||
### Easter Eggs and Delighters
|
||||
|
||||
{{easter_eggs}}
|
||||
|
||||
### Module Lore and Theming
|
||||
|
||||
{{module_lore}}
|
||||
|
||||
---
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
### Technical Risks
|
||||
|
||||
{{technical_risks}}
|
||||
|
||||
### Usability Risks
|
||||
|
||||
{{usability_risks}}
|
||||
|
||||
### Scope Risks
|
||||
|
||||
{{scope_risks}}
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
{{risk_mitigation}}
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
### Priority Order
|
||||
|
||||
1. {{priority_1}}
|
||||
2. {{priority_2}}
|
||||
3. {{priority_3}}
|
||||
|
||||
### Key Design Decisions
|
||||
|
||||
{{design_decisions}}
|
||||
|
||||
### Open Questions
|
||||
|
||||
{{open_questions}}
|
||||
|
||||
---
|
||||
|
||||
## Resources and References
|
||||
|
||||
### Inspiration Sources
|
||||
|
||||
{{inspiration_sources}}
|
||||
|
||||
### Similar Modules
|
||||
|
||||
{{similar_modules}}
|
||||
|
||||
### Technical References
|
||||
|
||||
{{technical_references}}
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Detailed Agent Specifications
|
||||
|
||||
{{detailed_agent_specs}}
|
||||
|
||||
### B. Workflow Detailed Designs
|
||||
|
||||
{{detailed_workflow_specs}}
|
||||
|
||||
### C. Data Structures and Schemas
|
||||
|
||||
{{data_schemas}}
|
||||
|
||||
### D. Integration Specifications
|
||||
|
||||
{{integration_specs}}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Review this brief** with stakeholders
|
||||
2. **Run create-module workflow** using this brief as input
|
||||
3. **Create first agent** using create-agent workflow
|
||||
4. **Develop initial workflows** using create-workflow
|
||||
5. **Test MVP** with target users
|
||||
|
||||
---
|
||||
|
||||
_This Module Brief is ready to be fed directly into the create-module workflow for scaffolding and implementation._
|
||||
|
||||
**Module Viability Score:** {{viability_score}}/10
|
||||
**Estimated Development Effort:** {{effort_estimate}}
|
||||
**Confidence Level:** {{confidence_level}}
|
||||
|
||||
---
|
||||
|
||||
**Approval for Development:**
|
||||
|
||||
- [ ] Concept Approved
|
||||
- [ ] Scope Defined
|
||||
- [ ] Resources Available
|
||||
- [ ] Ready to Build
|
||||
|
||||
---
|
||||
|
||||
_Generated on {{date}} by {{user_name}} using the BMAD Method Module Brief workflow_
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
# Module Brief Workflow Configuration
|
||||
name: module-brief
|
||||
description: "Create a comprehensive Module Brief that serves as the blueprint for building new BMAD modules using strategic analysis and creative vision"
|
||||
author: "BMad Builder"
|
||||
|
||||
# Critical variables
|
||||
config_source: "{project-root}/_bmad/bmb/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
date: system-generated
|
||||
|
||||
# Reference examples and documentation
|
||||
existing_modules_dir: "{project-root}/_bmad/"
|
||||
module_structure_guide: "{project-root}/_bmad/bmb/workflows/create-module/module-structure.md"
|
||||
|
||||
# Optional user inputs - discovered if they exist
|
||||
input_file_patterns:
|
||||
brainstorming:
|
||||
description: "Brainstorming session outputs (optional)"
|
||||
whole: "{output_folder}/brainstorming-*.md"
|
||||
load_strategy: "FULL_LOAD"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/_bmad/bmb/workflows/module-brief"
|
||||
template: "{installed_path}/template.md"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/module-brief-{{module_code}}-{{date}}.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
# Web bundle configuration
|
||||
web_bundle: false # BMB workflows run locally in BMAD-METHOD project
|
||||
|
|
@ -31,8 +31,8 @@ critical_actions:
|
|||
|
||||
**CRITICAL Path Format:**
|
||||
- `{project-root}` = literal text (not replaced)
|
||||
- Sidecar created next to agent.yaml during BUILD, then copied to `_memory/` during BMAD INSTALLATION
|
||||
- Use `{project-root}/_bmad/_memory/{sidecar-folder}/` format for RUNTIME paths in agent YAML
|
||||
- Sidecar copied to `_memory/` at build time
|
||||
- Use `{project-root}/_bmad/_memory/{sidecar-folder}/` format
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ Agents with a sidecar folder for persistent memory, custom workflows, and restri
|
|||
|
||||
## CRITICAL: Sidecar Path Format
|
||||
|
||||
During BMAD INSTALLATION, sidecar folder is copied from the agent location to `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
At build/install, sidecar is copied to `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
|
||||
**ALL agent YAML references MUST use:**
|
||||
|
||||
|
|
|
|||
|
|
@ -46,9 +46,7 @@ Optional creative exploration to generate agent ideas through structured brainst
|
|||
- Limits: No mandatory brainstorming, no pressure tactics
|
||||
- Dependencies: User choice to participate or skip brainstorming
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Present Brainstorming Opportunity
|
||||
|
||||
|
|
|
|||
|
|
@ -108,9 +108,7 @@ After documentation, present menu:
|
|||
- Clear articulation of value proposition
|
||||
- Comprehensive capability mapping
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
1. **Load Previous Context**
|
||||
- Check for brainstormContext file
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: 'step-03-type-metadata'
|
||||
name: 'step-02-type-metadata'
|
||||
description: 'Determine agent type and define metadata'
|
||||
|
||||
# File References
|
||||
|
|
@ -27,7 +27,7 @@ Determine the agent's classification (Simple/Expert/Module) and define all manda
|
|||
# MANDATORY EXECUTION RULES
|
||||
|
||||
## Universal Rules
|
||||
- ALWAYS use `{communication_language}` for all conversational text
|
||||
- ALWAYS use `{agent-language}` for all conversational text
|
||||
- MAINTAIN step boundaries - complete THIS step only
|
||||
- DOCUMENT all decisions to agent plan file
|
||||
- HONOR user's creative control throughout
|
||||
|
|
@ -125,9 +125,7 @@ Present structured options:
|
|||
|
||||
---
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
# INSTRUCTION SEQUENCE
|
||||
|
||||
## 1. Load Documentation
|
||||
Read and internalize:
|
||||
|
|
@ -136,7 +134,7 @@ Read and internalize:
|
|||
- Keep examples accessible for reference
|
||||
|
||||
## 2. Purpose Discovery Conversation
|
||||
Engage user with questions in `{communication_language}`:
|
||||
Engage user with questions in `{agent-language}`:
|
||||
- "What is the primary function this agent will perform?"
|
||||
- "How complex are the tasks this agent will handle?"
|
||||
- "Will this agent need to manage workflows or other agents?"
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: 'step-04-persona'
|
||||
name: 'step-03-persona'
|
||||
description: 'Shape the agent personality through four-field persona system'
|
||||
|
||||
# File References
|
||||
|
|
@ -156,9 +156,7 @@ principles:
|
|||
- Workflow steps (belongs in orchestration)
|
||||
- Data structures (belongs in implementation)
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
1. **LOAD** personaProperties.md and principlesCrafting.md
|
||||
2. **EXPLAIN** four-field system with clear examples
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: 'step-05-commands-menu'
|
||||
name: 'step-04-commands-menu'
|
||||
description: 'Build capabilities and command structure'
|
||||
|
||||
# File References
|
||||
|
|
@ -121,9 +121,7 @@ menu:
|
|||
- **User-facing perspective** - triggers should feel natural
|
||||
- **Capability alignment** - every command maps to a capability
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
1. Load agent-menu-patterns.md to understand structure
|
||||
2. Review capabilities from agent-plan step 3
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
name: 'step-06-activation'
|
||||
name: 'step-05-activation'
|
||||
description: 'Plan activation behavior and route to build'
|
||||
|
||||
# File References
|
||||
|
|
@ -30,7 +30,7 @@ Define activation behavior through critical_actions and route to the appropriate
|
|||
- These are non-negotiable prerequisites
|
||||
|
||||
2. **MUST Determine Route Before Activation Discussion**
|
||||
- Check `module` and `hasSidecar` from plan metadata
|
||||
- Check hasSidecar from plan metadata
|
||||
- Determine destination build step FIRST
|
||||
- Inform user of routing decision
|
||||
|
||||
|
|
@ -41,12 +41,10 @@ Define activation behavior through critical_actions and route to the appropriate
|
|||
|
||||
4. **MUST Follow Routing Logic Exactly**
|
||||
```yaml
|
||||
# Route determination based on module and hasSidecar
|
||||
# Module agents: any module value other than "stand-alone"
|
||||
module ≠ "stand-alone" → step-07c-build-module.md
|
||||
# Stand-alone agents: determined by hasSidecar
|
||||
module = "stand-alone" + hasSidecar: true → step-07b-build-expert.md
|
||||
module = "stand-alone" + hasSidecar: false → step-07a-build-simple.md
|
||||
# Route determination based on hasSidecar and module
|
||||
hasSidecar: false → step-06-build-simple.md
|
||||
hasSidecar: true + module: "stand-alone" → step-06-build-expert.md
|
||||
hasSidecar: true + module: ≠ "stand-alone" → step-06-build-module.md
|
||||
```
|
||||
|
||||
5. **NEVER Skip Documentation**
|
||||
|
|
@ -131,9 +129,7 @@ routing:
|
|||
- Expert agents: Sidecar + stand-alone module
|
||||
- Module agents: Sidecar + parent module integration
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
## 1. Load Reference Documents
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
name: 'step-07a-build-simple'
|
||||
name: 'step-06-build-simple'
|
||||
description: 'Generate Simple agent YAML from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}.agent.yaml'
|
||||
|
||||
|
|
@ -60,9 +60,7 @@ Assemble the agent plan content into a Simple agent YAML configuration using the
|
|||
- Template placeholders (replace with actual content)
|
||||
- Comments or notes in final YAML
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## EXECUTION SEQUENCE
|
||||
|
||||
### 1. Load Template and Architecture Files
|
||||
|
||||
|
|
@ -143,7 +141,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
### 6. Route Based on User Choice
|
||||
|
||||
**If user chooses "one-at-a-time":**
|
||||
- Proceed to `nextStepFile` (step-08-celebrate.md)
|
||||
- Proceed to `nextStepFile` (step-07a-plan-traceability.md)
|
||||
- Continue through each validation step sequentially
|
||||
- Allow review between each validation
|
||||
|
||||
|
|
@ -155,7 +153,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: 'step-06-build-expert'
|
|||
description: 'Generate Expert agent YAML with sidecar from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
|
||||
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
|
@ -21,12 +21,12 @@ partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
|||
|
||||
# STEP GOAL
|
||||
|
||||
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage, so the build creates a sidecar folder next to the agent.yaml (which gets installed to `_bmad/_memory/` during BMAD installation).
|
||||
Assemble the agent plan content into a complete Expert agent YAML file with sidecar folder structure. Expert agents require persistent memory storage for specialized operations, accessed via `{project-root}/_bmad/_memory/{sidecar-folder}/` paths in critical_actions.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created next to agent.yaml (build location), which will be installed to `_bmad/_memory/` during BMAD installation
|
||||
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations (runtime path)
|
||||
1. **EXPERT AGENT = SIDECAR REQUIRED**: Every Expert agent MUST have a sidecar folder created under `_bmad/_memory/`
|
||||
2. **CRITICAL_ACTIONS FORMAT**: All critical_actions MUST use `{project-root}/_bmad/_memory/{sidecar-folder}/` for file operations
|
||||
3. **TEMPLATE COMPLIANCE**: Follow expert-agent-template.md structure exactly
|
||||
4. **YAML VALIDATION**: Ensure valid YAML syntax with proper indentation (2-space)
|
||||
5. **EXISTING CHECK**: If agentYamlOutput exists, ask user before overwriting
|
||||
|
|
@ -55,6 +55,8 @@ Using expertTemplate as structure:
|
|||
```yaml
|
||||
name: '{agent-name}'
|
||||
description: '{short-description}'
|
||||
type: 'expert'
|
||||
version: '1.0.0'
|
||||
|
||||
author:
|
||||
name: '{author}'
|
||||
|
|
@ -107,20 +109,19 @@ metadata:
|
|||
|
||||
### Phase 4: Create Sidecar Structure
|
||||
|
||||
1. **Create Sidecar Directory** (NEXT TO agent.yaml):
|
||||
- Path: `{agentBuildOutput}/{agent-name}-sidecar/`
|
||||
1. **Create Sidecar Directory**:
|
||||
- Path: `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
- Use `mkdir -p` to create full path
|
||||
- Note: This folder gets installed to `_bmad/_memory/` during BMAD installation
|
||||
|
||||
2. **Create Starter Files** (if specified in critical_actions):
|
||||
```bash
|
||||
touch {agentBuildOutput}/{agent-name}-sidecar/{file1}.md
|
||||
touch {agentBuildOutput}/{agent-name}-sidecar/{file2}.md
|
||||
touch _bmad/_memory/{sidecar-folder}/{file1}.md
|
||||
touch _bmad/_memory/{sidecar-folder}/{file2}.md
|
||||
```
|
||||
|
||||
3. **Add README to Sidecar**:
|
||||
```markdown
|
||||
# {sidecar-folder} Sidecar
|
||||
# {sidecar-folder} Memory
|
||||
|
||||
This folder stores persistent memory for the **{agent-name}** Expert agent.
|
||||
|
||||
|
|
@ -131,9 +132,8 @@ metadata:
|
|||
- {file1}.md: {description}
|
||||
- {file2}.md: {description}
|
||||
|
||||
## Runtime Access
|
||||
After BMAD installation, this folder will be accessible at:
|
||||
`{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
|
||||
## Access Pattern
|
||||
Agent accesses these files via: `{project-root}/_bmad/_memory/{sidecar-folder}/{filename}.md`
|
||||
```
|
||||
|
||||
### Phase 5: Write Agent YAML
|
||||
|
|
@ -171,11 +171,11 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
|
||||
This step produces TWO artifacts:
|
||||
1. **Agent YAML**: Complete expert agent definition at `{agentYamlOutput}`
|
||||
2. **Sidecar Structure**: Folder and files at `{agentBuildOutput}/{agent-name}-sidecar/` (build location, installs to `_bmad/_memory/` during BMAD installation)
|
||||
2. **Sidecar Structure**: Folder and files at `{project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
|
||||
Both must exist before proceeding to validation.
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ Both must exist before proceeding to validation.
|
|||
✅ Agent YAML file created at expected location
|
||||
✅ Valid YAML syntax (no parse errors)
|
||||
✅ All template fields populated
|
||||
✅ Sidecar folder created at `{agentBuildOutput}/{agent-name}-sidecar/` (build location)
|
||||
✅ Sidecar folder created under `_bmad/_memory/`
|
||||
✅ Sidecar folder contains starter files from critical_actions
|
||||
✅ critical_actions reference `{project-root}/_bmad/_memory/{sidecar-folder}/` paths
|
||||
✅ metadata.sidecar-folder populated
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: 'step-06-build-module'
|
|||
description: 'Generate Module agent YAML from plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08-celebrate.md'
|
||||
nextStepFile: './step-08a-plan-traceability.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
agentBuildOutput: '{bmb_creations_output_folder}/{agent-name}/'
|
||||
agentYamlOutput: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
|
@ -205,7 +205,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
ONLY WHEN [C continue option] is selected and [complete YAML generated and written to output], will you then load and read fully `{nextStepFile}` to execute and begin validation.
|
||||
|
||||
**THIS STEP IS COMPLETE WHEN:**
|
||||
1. Module agent YAML file exists at agentYamlOutput path
|
||||
|
|
|
|||
|
|
@ -0,0 +1,203 @@
|
|||
---
|
||||
name: 'step-07a-plan-traceability'
|
||||
description: 'Verify build matches original plan'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08b-metadata-validation.md'
|
||||
agentPlan: '{bmb_creations_output_folder}/agent-plan-{agent_name}.md'
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
Verify that the built agent YAML file contains all elements specified in the original agent plan. This step ensures plan traceability - confirming that what we planned is what we actually built.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
- MUST load both agentPlan and builtYaml files before comparison
|
||||
- MUST compare ALL planned elements against built implementation
|
||||
- MUST report specific missing items, not just "something is missing"
|
||||
- MUST offer fix option before proceeding to next validation
|
||||
- MUST handle missing files gracefully (report clearly, don't crash)
|
||||
- MUST respect YOLO mode behavior (part of combined validation report)
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## File Loading Protocol
|
||||
1. Load agentPlan from `{bmb_creations_output_folder}/agent-plan-{agent_name}.md`
|
||||
2. Load builtYaml from `{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml`
|
||||
3. If either file is missing, report the specific missing file and stop comparison
|
||||
4. Use Read tool to access both files with absolute paths
|
||||
|
||||
## Comparison Protocol
|
||||
Compare the following categories systematically:
|
||||
|
||||
### 1. Metadata Comparison
|
||||
- Agent name
|
||||
- Description
|
||||
- Version
|
||||
- Author/creator information
|
||||
- Location/module path
|
||||
- Language settings (if specified in plan)
|
||||
|
||||
### 2. Persona Field Comparison
|
||||
For each field in persona section:
|
||||
- Check presence in built YAML
|
||||
- Verify field content matches planned intent
|
||||
- Note any significant deviations (minor wording differences ok)
|
||||
|
||||
### 3. Commands Comparison
|
||||
- Verify all planned commands are present
|
||||
- Check command names match
|
||||
- Verify command descriptions are present
|
||||
- Confirm critical actions are referenced
|
||||
|
||||
### 4. Critical Actions Comparison
|
||||
- Verify all planned critical_actions are present
|
||||
- Check action names match exactly
|
||||
- Verify action descriptions are present
|
||||
- Confirm each action has required fields
|
||||
|
||||
### 5. Additional Elements
|
||||
- Dependencies (if planned)
|
||||
- Configuration (if planned)
|
||||
- Installation instructions (if planned)
|
||||
|
||||
## Reporting Protocol
|
||||
Present findings in clear, structured format:
|
||||
|
||||
```
|
||||
PLAN TRACEABILITY REPORT
|
||||
========================
|
||||
|
||||
Agent: {agent_name}
|
||||
Plan File: {path to agent plan}
|
||||
Build File: {path to built YAML}
|
||||
|
||||
COMPARISON RESULTS:
|
||||
-------------------
|
||||
|
||||
✅ Metadata: All present / Missing: {list}
|
||||
✅ Persona Fields: All present / Missing: {list}
|
||||
✅ Commands: All present / Missing: {list}
|
||||
✅ Critical Actions: All present / Missing: {list}
|
||||
✅ Other Elements: All present / Missing: {list}
|
||||
|
||||
OVERALL STATUS: [PASS / FAIL]
|
||||
|
||||
```
|
||||
|
||||
If ANY elements are missing:
|
||||
- List each missing element with category
|
||||
- Provide specific location reference (what was planned)
|
||||
- Ask if user wants to fix items or continue anyway
|
||||
|
||||
## Menu Protocol
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified missing elements, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
If YOLO mode:
|
||||
- Include this report in combined validation report
|
||||
- Auto-select [C] Continue if all elements present
|
||||
- Auto-select [F] Fix if missing critical elements (name, commands)
|
||||
- Flag non-critical missing items in summary
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
- ONLY compare plan vs build - do NOT evaluate quality or correctness
|
||||
- Do NOT suggest improvements or changes beyond planned elements
|
||||
- Do NOT re-open persona/commands discovery - this is verification only
|
||||
- Fix option should return to step-06-build, not earlier steps
|
||||
- If plan file is ambiguous, note ambiguity but use reasonable interpretation
|
||||
|
||||
# SEQUENCE
|
||||
|
||||
## 1. Load Required Files
|
||||
```yaml
|
||||
action: read
|
||||
target:
|
||||
- agentPlan
|
||||
- builtYaml
|
||||
on_failure: report which file is missing and suggest resolution
|
||||
```
|
||||
|
||||
## 2. Perform Structured Comparison
|
||||
```yaml
|
||||
action: compare
|
||||
categories:
|
||||
- metadata
|
||||
- persona_fields
|
||||
- commands
|
||||
- critical_actions
|
||||
- other_elements
|
||||
method: systematic category-by-category check
|
||||
```
|
||||
|
||||
## 3. Generate Comparison Report
|
||||
```yaml
|
||||
action: report
|
||||
format: structured pass/fail with specific missing items
|
||||
output: console display + optional save to validation log
|
||||
```
|
||||
|
||||
## 4. Present Menu Options
|
||||
```yaml
|
||||
action: menu
|
||||
options:
|
||||
- F: Fix missing items
|
||||
- C: Continue to metadata validation
|
||||
- V: View detailed comparison (optional)
|
||||
default: C if pass, F if fail
|
||||
```
|
||||
|
||||
## 5. Handle User Choice
|
||||
- **[F] Fix Findings**: Apply auto-fixes to {builtYaml} for identified missing elements, then re-present menu
|
||||
- **[C] Continue**: Proceed to step-07b-metadata-validation
|
||||
- **[A] Advanced Elicitation**: Execute advanced elicitation workflow, then re-present menu
|
||||
- **[P] Party Mode**: Execute party mode workflow, then re-present menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [metadata validation].
|
||||
|
||||
# SUCCESS/FAILURE METRICS
|
||||
|
||||
## Success Criteria
|
||||
- All planned elements present in built YAML: **COMPLETE PASS**
|
||||
- Minor deviations (wording, formatting) but all core elements present: **PASS**
|
||||
- Missing elements identified and user chooses to continue: **PASS WITH NOTED DEFICIENCIES**
|
||||
|
||||
## Failure Criteria
|
||||
- Unable to load plan or build file: **BLOCKING FAILURE**
|
||||
- Critical elements missing (name, commands, or critical_actions): **FAIL**
|
||||
- Comparison cannot be completed due to file corruption: **BLOCKING FAILURE**
|
||||
|
||||
## Next Step Triggers
|
||||
- **PASS → step-07b-metadata-validation**
|
||||
- **PASS WITH DEFICIENCIES → step-07b-metadata-validation** (user choice)
|
||||
- **FAIL → step-06-build** (with specific fix instructions)
|
||||
- **BLOCKING FAILURE → STOP** (resolve file access issues first)
|
||||
|
||||
## YOLO Mode Behavior
|
||||
- Auto-fix missing critical elements by returning to build step
|
||||
- Log non-critical missing items for review but continue validation
|
||||
- Include traceability report in final YOLO summary
|
||||
- Do NOT stop for user confirmation unless plan file is completely missing
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
---
|
||||
name: 'step-07b-metadata-validation'
|
||||
description: 'Validate agent metadata properties'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08c-persona-validation.md'
|
||||
agentMetadata: ../data/agent-metadata.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's metadata properties (name, description, version, tags, category, etc.) are properly formatted, complete, and follow BMAD standards.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All metadata fields must be verified
|
||||
- **ALWAYS load both reference documents** - agentMetadata.md AND the builtYaml
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the metadata validation reference from `{agentMetadata}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Extract the metadata section from the builtYaml
|
||||
4. Compare actual metadata against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] name: Present and non-empty
|
||||
- [ ] description: Present and non-empty
|
||||
- [ ] category: Present and matches valid category
|
||||
- [ ] tags: Present as array, not empty
|
||||
|
||||
2. **Format Validation**
|
||||
- [ ] name: Uses kebab-case, no spaces
|
||||
- [ ] description: 50-200 characters (unless intentionally brief)
|
||||
- [ ] tags: Array of lowercase strings with hyphens
|
||||
- [ ] category: Matches one of the allowed categories
|
||||
|
||||
3. **Content Quality**
|
||||
- [ ] description: Clear and concise, explains what the agent does
|
||||
- [ ] tags: Relevant to agent's purpose (3-7 tags recommended)
|
||||
- [ ] category: Most appropriate classification
|
||||
|
||||
4. **Standards Compliance**
|
||||
- [ ] No prohibited characters in fields
|
||||
- [ ] No redundant or conflicting information
|
||||
- [ ] Consistent formatting with other agents
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Required fields present
|
||||
✓ Name follows kebab-case convention
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Description is brief (45 chars, recommended 50-200)
|
||||
⚠ Only 2 tags provided, 3-7 recommended
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Category "custom-type" not in allowed list
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Metadata section of agent.yaml (name, description, version, tags, category, author, license, etc.)
|
||||
- Referencing the agentMetadata.md validation rules
|
||||
- Comparing against BMAD standards
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Persona fields (handled in step-07c)
|
||||
- Menu items (handled in step-07d)
|
||||
- System architecture (handled in step-07e)
|
||||
- Capability implementation (handled in step-07f)
|
||||
|
||||
**DO NOT:**
|
||||
- Validate persona properties in this step
|
||||
- Suggest major feature additions
|
||||
- Question the agent's core purpose
|
||||
- Modify fields beyond metadata
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [persona validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, no failures, warnings are optional
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** Never proceed to next step if blocking failures exist and user hasn't acknowledged them.
|
||||
|
|
@ -0,0 +1,161 @@
|
|||
---
|
||||
name: 'step-07c-persona-validation'
|
||||
description: 'Validate persona fields and principles'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08d-menu-validation.md'
|
||||
personaProperties: ../data/persona-properties.md
|
||||
principlesCrafting: ../data/principles-crafting.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's persona (role, tone, expertise, principles, constraints) is well-defined, consistent, and aligned with its purpose.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All persona fields must be verified
|
||||
- **ALWAYS load both reference documents** - personaProperties.md AND principlesCrafting.md
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the persona validation reference from `{personaProperties}`
|
||||
2. Read the principles crafting guide from `{principlesCrafting}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
4. Extract the persona section from the builtYaml
|
||||
5. Compare actual persona against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] role: Present, clear, and specific
|
||||
- [ ] tone: Present and appropriate to role
|
||||
- [ ] expertise: Present and relevant to agent's purpose
|
||||
- [ ] principles: Present as array, not empty (if applicable)
|
||||
- [ ] constraints: Present as array, not empty (if applicable)
|
||||
|
||||
2. **Content Quality - Role**
|
||||
- [ ] Role is specific (not generic like "assistant")
|
||||
- [ ] Role aligns with agent's purpose and menu items
|
||||
- [ ] Role is achievable within LLM capabilities
|
||||
- [ ] Role scope is appropriate (not too broad/narrow)
|
||||
|
||||
3. **Content Quality - Tone**
|
||||
- [ ] Tone is clearly defined (professional, friendly, authoritative, etc.)
|
||||
- [ ] Tone matches the role and target users
|
||||
- [ ] Tone is consistent throughout the definition
|
||||
- [ ] Tone examples or guidance provided if nuanced
|
||||
|
||||
4. **Content Quality - Expertise**
|
||||
- [ ] Expertise areas are relevant to role
|
||||
- [ ] Expertise claims are realistic for LLM
|
||||
- [ ] Expertise domains are specific (not just "knowledgeable")
|
||||
- [ ] Expertise supports the menu capabilities
|
||||
|
||||
5. **Content Quality - Principles**
|
||||
- [ ] Principles are actionable (not vague platitudes)
|
||||
- [ ] Principles guide behavior and decisions
|
||||
- [ ] Principles are consistent with role
|
||||
- [ ] 3-7 principles recommended (not overwhelming)
|
||||
- [ ] Each principle is clear and specific
|
||||
|
||||
6. **Content Quality - Constraints**
|
||||
- [ ] Constraints define boundaries clearly
|
||||
- [ ] Constraints are enforceable (measurable/observable)
|
||||
- [ ] Constraints prevent undesirable behaviors
|
||||
- [ ] Constraints don't contradict principles
|
||||
|
||||
7. **Consistency Checks**
|
||||
- [ ] Role, tone, expertise, principles all align
|
||||
- [ ] No contradictions between principles and constraints
|
||||
- [ ] Persona supports the menu items defined
|
||||
- [ ] Language and terminology consistent
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Role is specific and well-defined
|
||||
✓ Tone clearly articulated and appropriate
|
||||
✓ Expertise aligns with agent purpose
|
||||
✓ Principles are actionable and clear
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Only 2 principles provided, 3-7 recommended for richer guidance
|
||||
⚠ No constraints defined - consider adding boundaries
|
||||
⚠ Expertise areas are broad, could be more specific
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Role is generic ("assistant") - needs specificity
|
||||
✗ Tone undefined - creates inconsistent behavior
|
||||
✗ Principles are vague ("be helpful" - not actionable)
|
||||
✗ Contradiction: Principle says "be creative", constraint says "follow strict rules"
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Persona section of agent.yaml (role, tone, expertise, principles, constraints)
|
||||
- Referencing personaProperties.md and principlesCrafting.md
|
||||
- Evaluating persona clarity, specificity, and consistency
|
||||
- Checking alignment between persona elements
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Metadata fields (handled in step-07b)
|
||||
- Menu items (handled in step-07d)
|
||||
- System architecture (handled in step-07e)
|
||||
- Technical implementation details
|
||||
|
||||
**DO NOT:**
|
||||
- Validate metadata properties in this step
|
||||
- Question the agent's core purpose (that's for earlier steps)
|
||||
- Suggest additional menu items
|
||||
- Modify fields beyond persona
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [menu validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, persona is well-defined and consistent
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** A weak or generic persona is a blocking issue that should be fixed before proceeding.
|
||||
|
|
@ -0,0 +1,175 @@
|
|||
---
|
||||
name: 'step-07d-menu-validation'
|
||||
description: 'Validate menu items and patterns'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-08e-structure-validation.md'
|
||||
agentMenuPatterns: ../data/agent-menu-patterns.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate that the agent's menu (commands/tools) follows BMAD patterns, is well-structured, properly documented, and aligns with the agent's persona and purpose.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All menu items must be verified
|
||||
- **ALWAYS load the reference document** - agentMenuPatterns.md
|
||||
- **NEVER modify files without user approval** - Report findings first, await menu selection
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** This is a validation step, not an editing step
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the menu patterns reference from `{agentMenuPatterns}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Extract the menu/commands section from the builtYaml
|
||||
4. Compare actual menu against validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
Perform these checks systematically:
|
||||
|
||||
1. **Menu Structure**
|
||||
- [ ] Menu section exists and is properly formatted
|
||||
- [ ] At least one menu item defined (unless intentionally tool-less)
|
||||
- [ ] Menu items follow proper YAML structure
|
||||
- [ ] Each item has required fields (name, description, pattern)
|
||||
|
||||
2. **Menu Item Requirements**
|
||||
For each menu item:
|
||||
- [ ] name: Present, unique, uses kebab-case
|
||||
- [ ] description: Clear and concise
|
||||
- [ ] pattern: Valid regex pattern or tool reference
|
||||
- [ ] scope: Appropriate scope defined (if applicable)
|
||||
|
||||
3. **Pattern Quality**
|
||||
- [ ] Patterns are valid and testable
|
||||
- [ ] Patterns are specific enough to match intended inputs
|
||||
- [ ] Patterns are not overly restrictive
|
||||
- [ ] Patterns use appropriate regex syntax
|
||||
|
||||
4. **Description Quality**
|
||||
- [ ] Each item has clear description
|
||||
- [ ] Descriptions explain what the item does
|
||||
- [ ] Descriptions are consistent in style
|
||||
- [ ] Descriptions help users understand when to use
|
||||
|
||||
5. **Alignment Checks**
|
||||
- [ ] Menu items align with agent's role/purpose
|
||||
- [ ] Menu items are supported by agent's expertise
|
||||
- [ ] Menu items fit within agent's constraints
|
||||
- [ ] Menu items are appropriate for target users
|
||||
|
||||
6. **Completeness**
|
||||
- [ ] Core capabilities for this role are covered
|
||||
- [ ] No obvious missing functionality
|
||||
- [ ] Menu scope is appropriate (not too sparse/overloaded)
|
||||
- [ ] Related functionality is grouped logically
|
||||
|
||||
7. **Standards Compliance**
|
||||
- [ ] No prohibited patterns or commands
|
||||
- [ ] No security vulnerabilities in patterns
|
||||
- [ ] No ambiguous or conflicting items
|
||||
- [ ] Consistent naming conventions
|
||||
|
||||
8. **Menu Link Validation (Agent Type Specific)**
|
||||
- [ ] Determine agent type: Simple (no sidecar), Expert (hasSidecar: true), or Module agent
|
||||
- [ ] For Expert agents (hasSidecar: true):
|
||||
- Menu handlers SHOULD reference external sidecar files (e.g., `./{agent-name}-sidecar/...`)
|
||||
- OR have inline prompts defined directly in the handler
|
||||
- [ ] For Module agents (module property is a code like 'bmm', 'bmb', etc.):
|
||||
- Menu handlers SHOULD reference external module files under the module path
|
||||
- Exec paths must start with `{project-root}/_bmad/{module}/...`
|
||||
- Referenced files must exist under the module directory
|
||||
- [ ] For Simple agents (stand-alone module, no sidecar):
|
||||
- Menu handlers MUST NOT have external file links
|
||||
- Menu handlers SHOULD only use relative links within the same file (e.g., `#section-name`)
|
||||
- OR have inline prompts defined directly in the handler
|
||||
|
||||
### Protocol 3: Report Findings
|
||||
Organize your report into three sections:
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Menu structure properly formatted
|
||||
✓ 5 menu items defined, all with required fields
|
||||
✓ All patterns are valid regex
|
||||
✓ Menu items align with agent role
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Item "analyze-data" description is vague
|
||||
⚠ No menu item for [common capability X]
|
||||
⚠ Pattern for "custom-command" very broad, may over-match
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Duplicate menu item name: "process" appears twice
|
||||
✗ Invalid regex pattern: "[unclosed bracket"
|
||||
✗ Menu item "system-admin" violates security guidelines
|
||||
✗ No menu items defined for agent type that requires tools
|
||||
✗ Simple agent has external link in menu handler (should be relative # or inline)
|
||||
✗ Expert agent with sidecar has no external file links or inline prompts defined
|
||||
✗ Module agent exec path doesn't start with {project-root}/_bmad/{module}/...
|
||||
```
|
||||
|
||||
### Protocol 4: Menu System
|
||||
|
||||
#### 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CONTEXT BOUNDARIES
|
||||
|
||||
**IN SCOPE:**
|
||||
- Menu/commands section of agent.yaml
|
||||
- Referencing agentMenuPatterns.md
|
||||
- Menu structure, patterns, and alignment
|
||||
- Individual menu item validation
|
||||
|
||||
**OUT OF SCOPE:**
|
||||
- Metadata fields (handled in step-07b)
|
||||
- Persona fields (handled in step-07c)
|
||||
- System architecture (handled in step-07e)
|
||||
- Workflow/capability implementation (handled in step-07f)
|
||||
|
||||
**DO NOT:**
|
||||
- Validate metadata or persona in this step
|
||||
- Suggest entirely new capabilities (that's for earlier steps)
|
||||
- Question whether menu items are "good enough" qualitatively beyond standards
|
||||
- Modify fields beyond menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [structure validation].
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✓ **Complete Success:** All checks pass, menu is well-structured and aligned
|
||||
✓ **Partial Success:** Failures fixed via [F] option, warnings acknowledged
|
||||
✓ **Failure:** Blocking failures remain when user selects [C]
|
||||
|
||||
**CRITICAL:** Invalid regex patterns or security vulnerabilities in menu items are blocking issues.
|
||||
|
|
@ -0,0 +1,306 @@
|
|||
---
|
||||
name: 'step-07e-structure-validation'
|
||||
description: 'Validate YAML structure and completeness'
|
||||
|
||||
# File References
|
||||
# Routes to 8F if Expert, else to 9
|
||||
nextStepFileExpert: './step-08f-sidecar-validation.md'
|
||||
nextStepFileSimple: './step-09-celebrate.md'
|
||||
simpleValidation: ../data/simple-agent-validation.md
|
||||
expertValidation: ../data/expert-agent-validation.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# STEP GOAL
|
||||
|
||||
Validate the built agent YAML file for structural completeness and correctness against the appropriate validation checklist (simple or expert), then route to sidecar validation if needed or proceed to celebration.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
|
||||
1. **NEVER skip validation** - All agents must pass structural validation before completion
|
||||
2. **ALWAYS use the correct validation checklist** based on agent type (simple vs expert)
|
||||
3. **NEVER auto-fix without user consent** - Report issues and ask for permission
|
||||
4. **ALWAYS check hasSidecar flag** before determining next step routing
|
||||
5. **MUST load and parse the actual built YAML** - Not just show it, but validate it
|
||||
6. **ALWAYS provide clear, actionable feedback** for any validation failures
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## Context Awareness
|
||||
|
||||
- User is in the final validation phase
|
||||
- Agent has been built and written to disk
|
||||
- This is the "quality gate" before completion
|
||||
- User expects thorough but fair validation
|
||||
- Route depends on agent type (expert vs simple)
|
||||
|
||||
## User Expectations
|
||||
|
||||
- Clear validation results with specific issues identified
|
||||
- Line-number references for YAML problems
|
||||
- Option to fix issues or continue (if minor)
|
||||
- Logical routing based on agent type
|
||||
- Professional, constructive feedback tone
|
||||
|
||||
## Tone and Style
|
||||
|
||||
- Professional and thorough
|
||||
- Constructive, not pedantic
|
||||
- Clear prioritization of issues (critical vs optional)
|
||||
- Encouraging when validation passes
|
||||
- Actionable when issues are found
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
## What to Validate
|
||||
|
||||
- YAML syntax and structure
|
||||
- Required frontmatter fields presence
|
||||
- Required sections completeness
|
||||
- Field format correctness
|
||||
- Path validity (for references)
|
||||
- Agent type consistency (simple vs expert requirements)
|
||||
|
||||
## What NOT to Validate
|
||||
|
||||
- Artistic choices in descriptions
|
||||
- Persona writing style
|
||||
- Command naming creativity
|
||||
- Feature scope decisions
|
||||
|
||||
## When to Escalate
|
||||
|
||||
- Critical structural errors that break agent loading
|
||||
- Missing required fields
|
||||
- YAML syntax errors preventing file parsing
|
||||
- Path references that don't exist
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
## 1. Load Validation Context
|
||||
|
||||
```bash
|
||||
# Load the appropriate validation checklist based on agent type
|
||||
if agentType == "expert":
|
||||
validationFile = expertValidation
|
||||
else:
|
||||
validationFile = simpleValidation
|
||||
|
||||
# Load the built agent YAML
|
||||
builtAgent = read(builtYaml)
|
||||
|
||||
# Load compilation rules for reference
|
||||
compilationRules = read(agentCompilation)
|
||||
```
|
||||
|
||||
**Action:** Present a brief status message:
|
||||
```
|
||||
🔍 LOADING VALIDATION FRAMEWORK
|
||||
Agent Type: {detected type}
|
||||
Validation Standard: {simple|expert}
|
||||
Built File: {builtYaml path}
|
||||
```
|
||||
|
||||
## 2. Execute Structural Validation
|
||||
|
||||
Run systematic checks against the validation checklist:
|
||||
|
||||
### A. YAML Syntax Validation
|
||||
- Parse YAML without errors
|
||||
- Check indentation consistency
|
||||
- Validate proper escaping of special characters
|
||||
- Verify no duplicate keys
|
||||
|
||||
### B. Frontmatter Validation
|
||||
- All required fields present
|
||||
- Field values correct type (string, boolean, array)
|
||||
- No empty required fields
|
||||
- Proper array formatting
|
||||
|
||||
### C. Section Completeness
|
||||
- All required sections present (based on agent type)
|
||||
- Sections not empty unless explicitly optional
|
||||
- Proper markdown heading hierarchy
|
||||
|
||||
### D. Field-Level Validation
|
||||
- Path references exist and are valid
|
||||
- Boolean fields are actual booleans (not strings)
|
||||
- Array fields properly formatted
|
||||
- No malformed YAML structures
|
||||
|
||||
### E. Agent Type Specific Checks
|
||||
|
||||
**For Simple Agents:**
|
||||
- No sidecar requirements
|
||||
- Basic fields complete
|
||||
- No advanced configuration
|
||||
|
||||
**For Expert Agents:**
|
||||
- Sidecar flag set correctly
|
||||
- Sidecar folder path specified
|
||||
- All expert fields present
|
||||
- Advanced features properly configured
|
||||
|
||||
## 3. Generate Validation Report
|
||||
|
||||
Present findings in structured format:
|
||||
|
||||
```markdown
|
||||
# 🎯 STRUCTURAL VALIDATION REPORT
|
||||
|
||||
## Agent: {agent-name}
|
||||
Type: {simple|expert}
|
||||
File: {builtYaml}
|
||||
|
||||
---
|
||||
|
||||
## ✅ PASSED CHECKS ({count})
|
||||
{List of all validations that passed}
|
||||
|
||||
## ⚠️ ISSUES FOUND ({count})
|
||||
{If any issues, list each with:}
|
||||
### Issue #{number}: {type}
|
||||
**Severity:** [CRITICAL|MODERATE|MINOR]
|
||||
**Location:** Line {line} or Section {section}
|
||||
**Problem:** {clear description}
|
||||
**Impact:** {what this breaks}
|
||||
**Suggested Fix:** {specific action}
|
||||
|
||||
---
|
||||
|
||||
## 📊 VALIDATION SUMMARY
|
||||
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
|
||||
**Critical Issues:** {count}
|
||||
**Moderate Issues:** {count}
|
||||
**Minor Issues:** {count}
|
||||
**Can Load Safely:** [YES|NO]
|
||||
|
||||
---
|
||||
|
||||
{If PASSED}
|
||||
## 🎉 VALIDATION SUCCESSFUL
|
||||
Your agent YAML is structurally sound and ready for use!
|
||||
All required fields present and correctly formatted.
|
||||
|
||||
{If ISSUES FOUND}
|
||||
## 🔧 RECOMMENDED ACTIONS
|
||||
1. Address critical issues first
|
||||
2. Review moderate issues
|
||||
3. Minor issues can be deferred
|
||||
```
|
||||
|
||||
## 4. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to next validation step, update frontmatter, then only then load, read entire file, then execute {nextStepFileExpert} or {nextStepFileSimple}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
|
||||
|
||||
### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
If [F] selected: Work through issues systematically
|
||||
- Load specific section needing fix
|
||||
- Present current state
|
||||
- Apply auto-fixes or guide user through corrections
|
||||
- Re-validate after each fix
|
||||
- Confirm resolution and re-present menu
|
||||
|
||||
If [C] selected:
|
||||
- Warn about implications if issues exist
|
||||
- Get explicit confirmation if critical issues
|
||||
- Document acceptance of issues
|
||||
- Proceed to routing
|
||||
|
||||
## 5. Route to Next Step
|
||||
|
||||
After validation passes or user chooses to continue:
|
||||
|
||||
### Check Agent Type and Route
|
||||
|
||||
```yaml
|
||||
# Check for sidecar requirement
|
||||
hasSidecar = checkBuiltYamlForSidecarFlag()
|
||||
|
||||
if hasSidecar == true:
|
||||
# Expert agent with sidecar
|
||||
nextStep = nextStepFileExpert
|
||||
routeMessage = """
|
||||
📦 Expert agent detected with sidecar configuration.
|
||||
→ Proceeding to sidecar validation (Step 7F)
|
||||
"""
|
||||
else:
|
||||
# Simple agent or expert without sidecar
|
||||
nextStep = nextStepFileSimple
|
||||
routeMessage = """
|
||||
✅ Simple agent validation complete.
|
||||
→ Proceeding to celebration (Step 8)
|
||||
"""
|
||||
```
|
||||
|
||||
**Action:** Present routing decision and transition:
|
||||
```markdown
|
||||
# 🚀 VALIDATION COMPLETE - ROUTING DECISION
|
||||
|
||||
{routeMessage}
|
||||
|
||||
**Next Step:** {nextStep filename}
|
||||
**Reason:** Agent type {simple|expert} with sidecar={hasSidecar}
|
||||
|
||||
Press [Enter] to continue to {next step description}...
|
||||
```
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFileExpert}` or `{nextStepFileSimple}` to execute and begin [sidecar validation or celebration].
|
||||
|
||||
**BEFORE proceeding to next step:**
|
||||
|
||||
1. ✅ Validation checklist executed completely
|
||||
2. ✅ All critical issues resolved or explicitly accepted
|
||||
3. ✅ User informed of routing decision
|
||||
4. ✅ Next step file path determined correctly
|
||||
5. ⚠️ **CRITICAL:** For expert agents, verify hasSidecar is TRUE before routing to 7F
|
||||
6. ⚠️ **CRITICAL:** For simple agents, verify hasSidecar is FALSE before routing to 8
|
||||
|
||||
**DO NOT PROCEED IF:**
|
||||
- YAML has critical syntax errors preventing loading
|
||||
- User has not acknowledged validation results
|
||||
- Routing logic is unclear or conflicting
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
## Step Complete When:
|
||||
- [ ] Validation report generated and presented
|
||||
- [ ] User has reviewed findings
|
||||
- [ ] Critical issues resolved or accepted
|
||||
- [ ] Routing decision communicated and confirmed
|
||||
- [ ] Next step path verified and ready
|
||||
|
||||
## Quality Indicators:
|
||||
- Validation thoroughness (all checklist items covered)
|
||||
- Issue identification clarity and specificity
|
||||
- User satisfaction with resolution process
|
||||
- Correct routing logic applied
|
||||
- Clear transition to next step
|
||||
|
||||
## Failure Modes:
|
||||
- Skipping validation checks
|
||||
- Auto-fixing without permission
|
||||
- Incorrect routing (simple→7F or expert→8 with sidecar)
|
||||
- Unclear or missing validation report
|
||||
- Proceeding with critical YAML errors
|
||||
|
|
@ -0,0 +1,462 @@
|
|||
---
|
||||
name: 'step-07f-sidecar-validation'
|
||||
description: 'Validate sidecar structure and paths'
|
||||
|
||||
# File References
|
||||
nextStepFile: './step-09-celebrate.md'
|
||||
criticalActions: ../data/critical-actions.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
sidecarFolder: '{bmb_creations_output_folder}/{agent-name}/{agent-name}-sidecar/'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
# STEP GOAL
|
||||
|
||||
Validate the sidecar folder structure and referenced paths for Expert agents to ensure all sidecar files exist, are properly structured, and paths in the main agent YAML correctly reference them.
|
||||
|
||||
# MANDATORY EXECUTION RULES
|
||||
|
||||
1. **ONLY runs for Expert agents** - Simple agents should never reach this step
|
||||
2. **MUST verify sidecar folder exists** before proceeding
|
||||
3. **ALWAYS cross-reference YAML paths** with actual files
|
||||
4. **NEVER create missing sidecar files** - Report issues, don't auto-fix
|
||||
5. **MUST validate sidecar file structure** for completeness
|
||||
6. **ALWAYS check critical actions file** if referenced
|
||||
7. **PROVIDE clear remediation steps** for any missing or malformed files
|
||||
|
||||
# EXECUTION PROTOCOLS
|
||||
|
||||
## Context Awareness
|
||||
|
||||
- User has an Expert agent with sidecar configuration
|
||||
- Structural validation (7E) already passed
|
||||
- Sidecar folder should have been created during build
|
||||
- This is the final validation before celebration
|
||||
- Missing sidecar components may break agent functionality
|
||||
|
||||
## User Expectations
|
||||
|
||||
- Comprehensive sidecar structure validation
|
||||
- Clear identification of missing files
|
||||
- Path reference verification
|
||||
- Actionable remediation guidance
|
||||
- Professional but approachable tone
|
||||
|
||||
## Tone and Style
|
||||
|
||||
- Thorough and systematic
|
||||
- Clear and specific about issues
|
||||
- Solution-oriented (focus on how to fix)
|
||||
- Encouraging when sidecar is complete
|
||||
- Not pedantic about minor formatting issues
|
||||
|
||||
# CONTEXT BOUNDARIES
|
||||
|
||||
## What to Validate
|
||||
|
||||
- Sidecar folder existence and location
|
||||
- All referenced files exist in sidecar
|
||||
- Sidecar file structure completeness
|
||||
- Path references in main YAML accuracy
|
||||
- Critical actions file if referenced
|
||||
- File naming conventions
|
||||
- File content completeness (not empty)
|
||||
|
||||
## What NOT to Validate
|
||||
|
||||
- Content quality of sidecar files
|
||||
- Artistic choices in sidecar documentation
|
||||
- Optional sidecar components
|
||||
- File formatting preferences
|
||||
|
||||
## When to Escalate
|
||||
|
||||
- Sidecar folder completely missing
|
||||
- Critical files missing (actions, core modules)
|
||||
- Path references pointing to non-existent files
|
||||
- Empty sidecar files that should have content
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
|
||||
## 1. Load Sidecar Context
|
||||
|
||||
```bash
|
||||
# Verify main agent YAML exists
|
||||
agentYaml = read(builtYaml)
|
||||
|
||||
# Extract sidecar path from YAML or use template default
|
||||
sidecarPath = extractSidecarPath(agentYaml) or sidecarFolder
|
||||
|
||||
# Check if sidecar folder exists
|
||||
sidecarExists = directoryExists(sidecarPath)
|
||||
|
||||
# Load critical actions reference if needed
|
||||
criticalActionsRef = read(criticalActions)
|
||||
```
|
||||
|
||||
**Action:** Present discovery status:
|
||||
```markdown
|
||||
🔍 SIDECAR VALIDATION INITIALIZED
|
||||
|
||||
Agent: {agent-name}
|
||||
Type: Expert (requires sidecar)
|
||||
|
||||
Main YAML: {builtYaml}
|
||||
Sidecar Path: {sidecarPath}
|
||||
|
||||
Status: {✅ Folder Found | ❌ Folder Missing}
|
||||
```
|
||||
|
||||
## 2. Validate Sidecar Structure
|
||||
|
||||
### A. Folder Existence Check
|
||||
|
||||
```markdown
|
||||
## 📁 FOLDER STRUCTURE VALIDATION
|
||||
|
||||
**Sidecar Location:** {sidecarPath}
|
||||
**Status:** [EXISTS | MISSING | WRONG LOCATION]
|
||||
```
|
||||
|
||||
If missing:
|
||||
```markdown
|
||||
❌ **CRITICAL ISSUE:** Sidecar folder not found!
|
||||
|
||||
**Expected Location:** {sidecarPath}
|
||||
|
||||
**Possible Causes:**
|
||||
1. Build process didn't create sidecar
|
||||
2. Sidecar path misconfigured in agent YAML
|
||||
3. Folder moved or deleted after build
|
||||
|
||||
**Required Action:**
|
||||
[ ] Re-run build process with sidecar enabled
|
||||
[ ] Verify sidecar configuration in agent YAML
|
||||
[ ] Check folder was created in correct location
|
||||
```
|
||||
|
||||
### B. Sidecar File Inventory
|
||||
|
||||
If folder exists, list all files:
|
||||
```bash
|
||||
sidecarFiles = listFiles(sidecarPath)
|
||||
```
|
||||
|
||||
```markdown
|
||||
## 📄 SIDECAR FILE INVENTORY
|
||||
|
||||
Found {count} files in sidecar:
|
||||
|
||||
{For each file:}
|
||||
- {filename} ({size} bytes)
|
||||
```
|
||||
|
||||
### C. Cross-Reference Validation
|
||||
|
||||
Extract all sidecar path references from agent YAML:
|
||||
```yaml
|
||||
# Common sidecar reference patterns
|
||||
sidecar:
|
||||
critical-actions: './{agent-name}-sidecar/critical-actions.md'
|
||||
modules:
|
||||
- path: './{agent-name}-sidecar/modules/module-01.md'
|
||||
```
|
||||
|
||||
Validate each reference:
|
||||
```markdown
|
||||
## 🔗 PATH REFERENCE VALIDATION
|
||||
|
||||
**Checked {count} references from agent YAML:**
|
||||
|
||||
{For each reference:}
|
||||
**Source:** {field in agent YAML}
|
||||
**Expected Path:** {referenced path}
|
||||
**Status:** [✅ Found | ❌ Missing | ⚠️ Wrong Location]
|
||||
```
|
||||
|
||||
## 3. Validate Sidecar File Contents
|
||||
|
||||
For each sidecar file found, check:
|
||||
|
||||
### A. File Completeness
|
||||
```markdown
|
||||
## 📋 FILE CONTENT VALIDATION
|
||||
|
||||
{For each file:}
|
||||
### {filename}
|
||||
**Size:** {bytes}
|
||||
**Status:** [✅ Complete | ⚠️ Empty | ❌ Too Small]
|
||||
**Last Modified:** {timestamp}
|
||||
```
|
||||
|
||||
### B. Critical Actions File (if present)
|
||||
|
||||
Special validation for critical-actions.md:
|
||||
```markdown
|
||||
## 🎯 CRITICAL ACTIONS VALIDATION
|
||||
|
||||
**File:** {sidecarPath}/critical-actions.md
|
||||
**Status:** [PRESENT | MISSING | EMPTY]
|
||||
|
||||
{If Present:}
|
||||
**Sections Found:**
|
||||
{List sections detected}
|
||||
|
||||
**Completeness:**
|
||||
[ ] Header/metadata present
|
||||
[ ] Actions defined
|
||||
[ ] No critical sections missing
|
||||
```
|
||||
|
||||
### C. Module Files (if present)
|
||||
|
||||
If sidecar contains modules:
|
||||
```markdown
|
||||
## 📚 MODULE VALIDATION
|
||||
|
||||
**Modules Found:** {count}
|
||||
|
||||
{For each module:}
|
||||
### {module-filename}
|
||||
**Status:** [✅ Valid | ⚠️ Issues Found]
|
||||
**Checks:**
|
||||
[ ] Frontmatter complete
|
||||
[ ] Content present
|
||||
[ ] References valid
|
||||
```
|
||||
|
||||
## 4. Generate Validation Report
|
||||
|
||||
```markdown
|
||||
# 🎯 SIDECAR VALIDATION REPORT
|
||||
|
||||
## Agent: {agent-name}
|
||||
Sidecar Path: {sidecarPath}
|
||||
Validation Date: {timestamp}
|
||||
|
||||
---
|
||||
|
||||
## ✅ VALIDATION CHECKS PASSED
|
||||
|
||||
**Folder Structure:**
|
||||
- [x] Sidecar folder exists
|
||||
- [x] Located at expected path
|
||||
- [x] Accessible and readable
|
||||
|
||||
**File Completeness:**
|
||||
- [x] All referenced files present
|
||||
- [x] No broken path references
|
||||
- [x] Files have content (not empty)
|
||||
|
||||
**Content Quality:**
|
||||
- [x] Critical actions complete
|
||||
- [x] Module files structured
|
||||
- [x] No obvious corruption
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ ISSUES IDENTIFIED ({count})
|
||||
|
||||
{If issues:}
|
||||
### Issue #{number}: {issue type}
|
||||
**Severity:** [CRITICAL|MODERATE|MINOR]
|
||||
**Component:** {file or folder}
|
||||
**Problem:** {clear description}
|
||||
**Impact:** {what this breaks}
|
||||
**Remediation:**
|
||||
1. {specific step 1}
|
||||
2. {specific step 2}
|
||||
3. {specific step 3}
|
||||
|
||||
{If no issues:}
|
||||
### 🎉 NO ISSUES FOUND
|
||||
Your agent's sidecar is complete and properly structured!
|
||||
All path references are valid and files are in place.
|
||||
|
||||
---
|
||||
|
||||
## 📊 SUMMARY
|
||||
|
||||
**Overall Status:** [PASSED|FAILED|CONDITIONAL]
|
||||
**Files Validated:** {count}
|
||||
**Issues Found:** {count}
|
||||
**Critical Issues:** {count}
|
||||
**Sidecar Ready:** [YES|NO]
|
||||
|
||||
---
|
||||
|
||||
## 5. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [F] Fix Findings [P] Party Mode [C] Continue"
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF F: Apply auto-fixes to {builtYaml} or sidecar files for identified issues, then redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Proceed to celebration step, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## 6. Issue Resolution (if [F] selected)
|
||||
|
||||
Work through each issue systematically:
|
||||
|
||||
**For Missing Files:**
|
||||
```markdown
|
||||
### 🔧 FIXING: Missing {filename}
|
||||
|
||||
**Required File:** {path}
|
||||
**Purpose:** {why it's needed}
|
||||
|
||||
**Option 1:** Re-run Build
|
||||
- Sidecar may not have been created completely
|
||||
- Return to build step and re-execute
|
||||
|
||||
**Option 2:** Manual Creation
|
||||
- Create file at: {full path}
|
||||
- Use template from: {template reference}
|
||||
- Minimum required content: {specification}
|
||||
|
||||
**Option 3:** Update References
|
||||
- Remove reference from agent YAML if not truly needed
|
||||
- Update path if file exists in different location
|
||||
|
||||
Which option? [1/2/3]:
|
||||
```
|
||||
|
||||
**For Broken Path References:**
|
||||
```markdown
|
||||
### 🔧 FIXING: Invalid Path Reference
|
||||
|
||||
**Reference Location:** {agent YAML field}
|
||||
**Current Path:** {incorrect path}
|
||||
**Expected File:** {filename}
|
||||
**Actual Location:** {where file actually is}
|
||||
|
||||
**Fix Options:**
|
||||
1. Update path in agent YAML to: {correct path}
|
||||
2. Move file to expected location: {expected path}
|
||||
3. Remove reference if file not needed
|
||||
|
||||
Which option? [1/2/3]:
|
||||
```
|
||||
|
||||
**For Empty/Malformed Files:**
|
||||
```markdown
|
||||
### 🔧 FIXING: {filename} - {Issue}
|
||||
|
||||
**Problem:** {empty/too small/malformed}
|
||||
**Location:** {full path}
|
||||
|
||||
**Remediation:**
|
||||
- View current content
|
||||
- Compare to template/standard
|
||||
- Add missing sections
|
||||
- Correct formatting
|
||||
|
||||
Ready to view and fix? [Y/N]:
|
||||
```
|
||||
|
||||
After each fix:
|
||||
- Re-validate the specific component
|
||||
- Confirm resolution
|
||||
- Move to next issue
|
||||
- Final re-validation when all complete
|
||||
|
||||
## 6. Route to Celebration
|
||||
|
||||
When validation passes or user chooses to continue:
|
||||
|
||||
```markdown
|
||||
# 🚀 SIDECAR VALIDATION COMPLETE
|
||||
|
||||
## Expert Agent: {agent-name}
|
||||
|
||||
✅ **Sidecar Structure:** Validated
|
||||
✅ **Path References:** All correct
|
||||
✅ **File Contents:** Complete
|
||||
|
||||
---
|
||||
|
||||
## 🎯 READY FOR CELEBRATION
|
||||
|
||||
Your Expert agent with sidecar is fully validated and ready!
|
||||
|
||||
**Next Step:** Celebration (Step 8)
|
||||
**Final Status:** All checks passed
|
||||
|
||||
Press [Enter] to proceed to celebration...
|
||||
```
|
||||
|
||||
# CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation complete with any findings addressed], will you then load and read fully `{nextStepFile}` to execute and begin [celebration].
|
||||
|
||||
**BEFORE proceeding to Step 8:**
|
||||
|
||||
1. ✅ Sidecar folder exists and is accessible
|
||||
2. ✅ All referenced files present
|
||||
3. ✅ Path references validated
|
||||
4. ✅ File contents checked for completeness
|
||||
5. ✅ User informed of validation status
|
||||
6. ✅ Issues resolved or explicitly accepted
|
||||
7. ⚠️ **CRITICAL:** Only Expert agents should reach this step
|
||||
8. ⚠️ **CRITICAL:** Sidecar must be complete for agent to function
|
||||
|
||||
**DO NOT PROCEED IF:**
|
||||
- Sidecar folder completely missing
|
||||
- Critical files absent (actions, core modules)
|
||||
- User unaware of sidecar issues
|
||||
- Validation not completed
|
||||
|
||||
# SUCCESS METRICS
|
||||
|
||||
## Step Complete When:
|
||||
- [ ] Sidecar folder validated
|
||||
- [ ] All path references checked
|
||||
- [ ] File contents verified
|
||||
- [ ] Validation report presented
|
||||
- [ ] Issues resolved or accepted
|
||||
- [ ] User ready to proceed
|
||||
|
||||
## Quality Indicators:
|
||||
- Thoroughness of file inventory
|
||||
- Accuracy of path reference validation
|
||||
- Clarity of issue identification
|
||||
- Actionability of remediation steps
|
||||
- User confidence in sidecar completeness
|
||||
|
||||
## Failure Modes:
|
||||
- Missing sidecar folder completely
|
||||
- Skipping file existence checks
|
||||
- Not validating path references
|
||||
- Proceeding with critical files missing
|
||||
- Unclear validation report
|
||||
- Not providing remediation guidance
|
||||
|
||||
---
|
||||
|
||||
## 🎓 NOTE: Expert Agent Sidecars
|
||||
|
||||
Sidecars are what make Expert agents powerful. They enable:
|
||||
- Modular architecture
|
||||
- Separation of concerns
|
||||
- Easier updates and maintenance
|
||||
- Shared components across agents
|
||||
|
||||
A validated sidecar ensures your Expert agent will:
|
||||
- Load correctly at runtime
|
||||
- Find all referenced resources
|
||||
- Execute critical actions as defined
|
||||
- Provide the advanced capabilities designed
|
||||
|
||||
Take the time to validate thoroughly - it pays off in agent reliability!
|
||||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
name: 'step-08-celebrate'
|
||||
name: 'step-09-celebrate'
|
||||
description: 'Celebrate completion and guide next steps for using the agent'
|
||||
|
||||
# File References
|
||||
thisStepFile: ./step-08-celebrate.md
|
||||
thisStepFile: ./step-09-celebrate.md
|
||||
workflowFile: ../workflow.md
|
||||
outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
|
||||
|
||||
|
|
@ -11,10 +11,9 @@ outputFile: {bmb_creations_output_folder}/agent-completion-{agent_name}.md
|
|||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
installationDocs: 'https://github.com/bmad-code-org/BMAD-METHOD/blob/main/docs/modules/bmb-bmad-builder/custom-content-installation.md#standalone-content-agents-workflows-tasks-tools-templates-prompts'
|
||||
validationWorkflow: '{project-root}/src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md'
|
||||
---
|
||||
|
||||
# Step 8: Celebration and Installation Guidance
|
||||
# Step 9: Celebration and Installation Guidance
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
|
|
@ -60,9 +59,7 @@ Celebrate the successful agent creation, recap the agent's capabilities, provide
|
|||
- Limits: No agent modifications, only installation guidance and celebration
|
||||
- Dependencies: Complete agent ready for installation
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change. (Do not deviate, skip, or optimize)
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Grand Celebration
|
||||
|
||||
|
|
@ -199,27 +196,25 @@ Save this content to `{outputFile}` for reference.
|
|||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: "**✅ Agent Build Complete! Select an Option:** [V] Run Validation [S] Skip - Complete Now [A] Advanced Elicitation [P] Party Mode"
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF V: "Loading validation phase..." → Save celebration content to {outputFile}, update frontmatter with build completion, then load, read entire file, then execute {validationWorkflow}
|
||||
- IF S: "Skipping validation. Completing workflow..." → Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF X: Save content to {outputFile}, update frontmatter with workflow completion, then end workflow gracefully
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- User can choose validation (V), skip to complete (S), or use advanced elicitation (A) or party mode (P)
|
||||
- After other menu items execution (A/P), return to this menu
|
||||
- ONLY complete workflow when user selects 'X'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [S skip option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
|
||||
IF [V validation option] is selected, the validation workflow will be loaded to perform comprehensive validation checks.
|
||||
ONLY WHEN [X exit option] is selected and [workflow completion marked in frontmatter], will the workflow end gracefully with agent ready for installation.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -59,9 +59,7 @@ Load the existing agent file, parse its structure, and create an edit plan track
|
|||
- Limits: Analysis only, no modifications
|
||||
- Dependencies: Agent file must exist and be valid YAML
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Load Agent File
|
||||
|
||||
|
|
@ -88,8 +86,9 @@ If a module agent also hasSidecar: true - this means it is a modules expert agen
|
|||
# Basic Metadata
|
||||
- name: {agent-name}
|
||||
- description: {agent-description}
|
||||
- module: {stand-alone|bmm|cis|bmgd|custom}
|
||||
- type: {simple|expert|module}
|
||||
- hasSidecar: {true|false}
|
||||
- version: {version}
|
||||
|
||||
# Persona
|
||||
- persona: {full persona text}
|
||||
|
|
@ -112,7 +111,7 @@ If a module agent also hasSidecar: true - this means it is a modules expert agen
|
|||
```markdown
|
||||
## Agent Analysis: {agent-name}
|
||||
|
||||
**Type:** {simple|expert|module} (derived from module + hasSidecar)
|
||||
**Type:** {simple|expert|module}
|
||||
**Status:** ready-for-edit
|
||||
|
||||
### Current Structure:
|
||||
|
|
|
|||
|
|
@ -54,9 +54,7 @@ Conduct targeted discovery to understand exactly what the user wants to change a
|
|||
- Limits: Discovery and documentation only, no implementation
|
||||
- Dependencies: Agent must be loaded in editPlan
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Read Edit Plan Context
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
# Placeholder - do not load this step.
|
||||
|
|
@ -36,9 +36,7 @@ Review the agent's type and metadata, and plan any changes. If edits involve typ
|
|||
- 💾 Document planned metadata changes
|
||||
- 🚫 FORBIDDEN to proceed without documenting changes
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
|
|||
|
|
@ -37,9 +37,7 @@ Review the agent's persona and plan any changes using the four-field persona sys
|
|||
- 💾 Document planned persona changes
|
||||
- 🚫 FORBIDDEN to proceed without documenting changes
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
|
|||
|
|
@ -35,9 +35,7 @@ Review the agent's command menu and plan any additions, modifications, or remova
|
|||
- 💾 Document planned command changes
|
||||
- 🚫 FORBIDDEN to proceed without documenting changes
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
|
|||
|
|
@ -39,9 +39,7 @@ Review critical_actions and route to the appropriate type-specific edit step (Si
|
|||
- 💾 Route to appropriate type-specific edit step
|
||||
- ➡️ Auto-advance to type-specific edit on [C]
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
@ -58,13 +56,12 @@ If user wants to add/modify critical_actions:
|
|||
|
||||
### 3. Determine Routing
|
||||
|
||||
Check `{editPlan}` for agent metadata (module and hasSidecar):
|
||||
Check `{editPlan}` metadataEdits.typeConversion.to or current agentType:
|
||||
|
||||
```yaml
|
||||
# Determine agent type from module + hasSidecar combination
|
||||
module ≠ "stand-alone" → route to e-08c-edit-module.md
|
||||
module = "stand-alone" + hasSidecar: true → route to e-08b-edit-expert.md
|
||||
module = "stand-alone" + hasSidecar: false → route to e-08a-edit-simple.md
|
||||
agentType: simple → route to e-08a-edit-simple.md
|
||||
agentType: expert → route to e-08b-edit-expert.md
|
||||
agentType: module → route to e-08c-edit-module.md
|
||||
```
|
||||
|
||||
### 4. Document to Edit Plan
|
||||
|
|
@ -78,7 +75,7 @@ activationEdits:
|
|||
modifications: []
|
||||
routing:
|
||||
destinationEdit: {e-08a|e-08b|e-08c}
|
||||
sourceType: {simple|expert|module} # Derived from module + hasSidecar
|
||||
targetType: {simple|expert|module}
|
||||
```
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
|
@ -89,7 +86,7 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save to {editPlan}, determine routing based on module + hasSidecar, then only then load and execute the appropriate type-specific edit step
|
||||
- IF C: Save to {editPlan}, determine routing based on targetType, then only then load and execute the appropriate type-specific edit step
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
|
@ -102,9 +99,9 @@ Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Cont
|
|||
|
||||
This is the **ROUTING HUB** for edit flow. ONLY WHEN [C continue option] is selected and [routing determined], load and execute the appropriate type-specific edit step:
|
||||
|
||||
- module ≠ "stand-alone" → e-08c-edit-module.md (Module agent)
|
||||
- module = "stand-alone" + hasSidecar: true → e-08b-edit-expert.md (Expert agent)
|
||||
- module = "stand-alone" + hasSidecar: false → e-08a-edit-simple.md (Simple agent)
|
||||
- targetType: simple → e-08a-edit-simple.md
|
||||
- targetType: expert → e-08b-edit-expert.md
|
||||
- targetType: module → e-08c-edit-module.md
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
name: 'e-08a-edit-simple'
|
||||
description: 'Apply edits to Simple agent'
|
||||
|
||||
nextStepFile: './e-09-celebrate.md'
|
||||
nextStepFile: './e-09a-validate-metadata.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentFile: '{original-agent-path}'
|
||||
agentBackup: '{original-agent-path}.backup'
|
||||
|
|
@ -47,9 +47,7 @@ Apply all planned edits to the Simple agent YAML file using templates and archit
|
|||
- ✅ Validate YAML syntax
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
@ -76,10 +74,9 @@ Confirm: "Backup created at: `{agentBackup}`"
|
|||
|
||||
For each planned edit:
|
||||
|
||||
**Type Conversion (Simple ← Expert/Module):**
|
||||
- Converting TO Simple: Remove `metadata.sidecar-folder`, remove all sidecar references
|
||||
- Set `module: stand-alone` and `hasSidecar: false`
|
||||
- Remove type-specific fields from source type
|
||||
**Type Conversion:**
|
||||
- Update `type:` field if converting
|
||||
- Add/remove type-specific fields
|
||||
|
||||
**Metadata Edits:**
|
||||
- Apply each field change from metadataEdits
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
name: 'e-08b-edit-expert'
|
||||
description: 'Apply edits to Expert agent'
|
||||
|
||||
nextStepFile: './e-09-celebrate.md'
|
||||
nextStepFile: './e-09a-validate-metadata.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentFile: '{original-agent-path}'
|
||||
agentBackup: '{original-agent-path}.backup'
|
||||
|
|
@ -48,9 +48,7 @@ Apply all planned edits to the Expert agent YAML file and manage sidecar structu
|
|||
- ✅ Validate YAML and sidecar paths
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
@ -72,10 +70,10 @@ ALWAYS backup before editing:
|
|||
|
||||
### 4. Apply Edits in Sequence
|
||||
|
||||
**Type Conversion TO Expert:**
|
||||
- Set `module: stand-alone` and `hasSidecar: true`
|
||||
**Type Conversion to Expert:**
|
||||
- Update `type: expert`
|
||||
- Add `metadata.sidecar-folder` if not present
|
||||
- Create sidecar directory next to agent.yaml: `{agent-folder}/{agent-name}-sidecar/`
|
||||
- Create sidecar directory: `mkdir -p {project-root}/_bmad/_memory/{sidecar-folder}/`
|
||||
|
||||
**Sidecar Management:**
|
||||
- If changing sidecar-folder: update all critical_actions references
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
name: 'e-08c-edit-module'
|
||||
description: 'Apply edits to Module agent'
|
||||
|
||||
nextStepFile: './e-09-celebrate.md'
|
||||
nextStepFile: './e-09a-validate-metadata.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentFile: '{original-agent-path}'
|
||||
agentBackup: '{original-agent-path}.backup'
|
||||
|
|
@ -48,9 +48,7 @@ Apply all planned edits to the Module agent YAML file and manage workflow integr
|
|||
- ✅ Validate YAML and workflow paths
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
|
@ -72,10 +70,9 @@ ALWAYS backup before editing:
|
|||
|
||||
### 4. Apply Edits in Sequence
|
||||
|
||||
**Type Conversion TO Module:**
|
||||
- Set `module` to module code (e.g., `bmm`, `cis`, `bmgd`, or custom)
|
||||
**Type Conversion to Module:**
|
||||
- Update `type: module`
|
||||
- Add workflow integration paths
|
||||
- Optionally set `hasSidecar: true` if complex multi-workflow module
|
||||
|
||||
**Workflow Path Management:**
|
||||
- Add: `skills: - workflow: {path}`
|
||||
|
|
|
|||
|
|
@ -0,0 +1,128 @@
|
|||
---
|
||||
name: 'e-09a-validate-metadata'
|
||||
description: 'Validate metadata (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09b-validate-persona.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentMetadata: ../data/agent-metadata.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9a: Validate Metadata (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate that the agent's metadata properties (id, name, title, icon, module, hasSidecar, etc.) are properly formatted, complete, and follow BMAD standards as defined in agentMetadata.md. Record findings to editPlan and auto-advance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All metadata fields must be verified
|
||||
- **ALWAYS load both reference documents** - agentMetadata.md AND the builtYaml
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the agentMetadata.md file
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the metadata validation reference from `{agentMetadata}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Read the edit plan from `{editPlan}`
|
||||
4. Extract the metadata section from the builtYaml
|
||||
5. Compare actual metadata against ALL validation rules in agentMetadata.md
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in agentMetadata.md:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] id: Present and non-empty
|
||||
- [ ] name: Present and non-empty (display name)
|
||||
- [ ] title: Present and non-empty
|
||||
- [ ] icon: Present (emoji or symbol)
|
||||
- [ ] module: Present and valid format
|
||||
- [ ] hasSidecar: Present (boolean, if applicable)
|
||||
|
||||
2. **Format Validation**
|
||||
- [ ] id: Uses kebab-case, no spaces, unique identifier
|
||||
- [ ] name: Clear display name for UI
|
||||
- [ ] title: Concise functional description
|
||||
- [ ] icon: Appropriate emoji or unicode symbol
|
||||
- [ ] module: Either a 3-4 letter module code (e.g., 'bmm', 'bmb') OR 'stand-alone'
|
||||
- [ ] hasSidecar: Boolean value, matches actual agent structure
|
||||
|
||||
3. **Content Quality**
|
||||
- [ ] id: Unique and descriptive
|
||||
- [ ] name: Clear and user-friendly
|
||||
- [ ] title: Accurately describes agent's function
|
||||
- [ ] icon: Visually representative of agent's purpose
|
||||
- [ ] module: Correctly identifies module membership
|
||||
- [ ] hasSidecar: Correctly indicates if agent uses sidecar files
|
||||
|
||||
4. **Agent Type Consistency**
|
||||
- [ ] If hasSidecar: true, sidecar folder path must be specified
|
||||
- [ ] If module is a module code, agent is a module agent
|
||||
- [ ] If module is 'stand-alone', agent is not part of a module
|
||||
- [ ] No conflicting type indicators
|
||||
|
||||
5. **Standards Compliance**
|
||||
- [ ] No prohibited characters in fields
|
||||
- [ ] No redundant or conflicting information
|
||||
- [ ] Consistent formatting with other agents
|
||||
- [ ] All required BMAD metadata fields present
|
||||
|
||||
### Protocol 3: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.metadata`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
metadata:
|
||||
status: [pass|fail|warning]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ All required fields present
|
||||
✓ id follows kebab-case convention
|
||||
✓ module value is valid
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Description is brief
|
||||
⚠ Only 2 tags provided, 3-7 recommended
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ id field is empty
|
||||
✗ module value is invalid
|
||||
✗ hasSidecar is true but no sidecar-folder specified
|
||||
```
|
||||
|
||||
### Protocol 4: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to persona validation...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All metadata checks from agentMetadata.md performed
|
||||
✅ All checks validated against the actual builtYaml
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
name: 'e-09b-validate-persona'
|
||||
description: 'Validate persona (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09c-validate-menu.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
personaProperties: ../data/persona-properties.md
|
||||
principlesCrafting: ../data/principles-crafting.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9b: Validate Persona (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate that the agent's persona (role, identity, communication_style, principles) is well-defined, consistent, and aligned with its purpose as defined in personaProperties.md and principlesCrafting.md. Record findings to editPlan and auto-advance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All persona fields must be verified
|
||||
- **ALWAYS load both reference documents** - personaProperties.md AND principlesCrafting.md
|
||||
- **ALWAYS load the builtYaml** for actual persona content validation
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the personaProperties.md file
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the persona validation reference from `{personaProperties}`
|
||||
2. Read the principles crafting guide from `{principlesCrafting}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
4. Read the edit plan from `{editPlan}`
|
||||
5. Extract the persona section from the builtYaml
|
||||
6. Compare actual persona against ALL validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in personaProperties.md:
|
||||
|
||||
1. **Required Fields Existence**
|
||||
- [ ] role: Present, clear, and specific
|
||||
- [ ] identity: Present and defines who the agent is
|
||||
- [ ] communication_style: Present and appropriate to role
|
||||
- [ ] principles: Present as array, not empty (if applicable)
|
||||
|
||||
2. **Content Quality - Role**
|
||||
- [ ] Role is specific (not generic like "assistant")
|
||||
- [ ] Role aligns with agent's purpose and menu items
|
||||
- [ ] Role is achievable within LLM capabilities
|
||||
- [ ] Role scope is appropriate (not too broad/narrow)
|
||||
|
||||
3. **Content Quality - Identity**
|
||||
- [ ] Identity clearly defines the agent's character
|
||||
- [ ] Identity is consistent with the role
|
||||
- [ ] Identity provides context for behavior
|
||||
- [ ] Identity is not generic or cliché
|
||||
|
||||
4. **Content Quality - Communication Style**
|
||||
- [ ] Communication style is clearly defined
|
||||
- [ ] Style matches the role and target users
|
||||
- [ ] Style is consistent throughout the definition
|
||||
- [ ] Style examples or guidance provided if nuanced
|
||||
- [ ] Style focuses on speech patterns only (not behavior)
|
||||
|
||||
5. **Content Quality - Principles**
|
||||
- [ ] Principles are actionable (not vague platitudes)
|
||||
- [ ] Principles guide behavior and decisions
|
||||
- [ ] Principles are consistent with role
|
||||
- [ ] 3-7 principles recommended (not overwhelming)
|
||||
- [ ] Each principle is clear and specific
|
||||
- [ ] First principle activates expert knowledge domain
|
||||
|
||||
6. **Consistency Checks**
|
||||
- [ ] Role, identity, communication_style, principles all align
|
||||
- [ ] No contradictions between principles
|
||||
- [ ] Persona supports the menu items defined
|
||||
- [ ] Language and terminology consistent
|
||||
|
||||
### Protocol 3: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.persona`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
persona:
|
||||
status: [pass|fail|warning]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Role is specific and well-defined
|
||||
✓ Identity clearly articulated and appropriate
|
||||
✓ Communication style clearly defined
|
||||
✓ Principles are actionable and clear
|
||||
✓ First principle activates expert knowledge
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Only 2 principles provided, 3-7 recommended for richer guidance
|
||||
⚠ Communication style could be more specific
|
||||
⚠ Expertise areas are broad, could be more specific
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Role is generic ("assistant") - needs specificity
|
||||
✗ Communication style undefined - creates inconsistent behavior
|
||||
✗ Principles are vague ("be helpful" - not actionable)
|
||||
✗ First principle doesn't activate expert knowledge
|
||||
```
|
||||
|
||||
### Protocol 4: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to menu validation...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All persona checks from personaProperties.md performed
|
||||
✅ All checks validated against the actual builtYaml
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -0,0 +1,163 @@
|
|||
---
|
||||
name: 'e-09c-validate-menu'
|
||||
description: 'Validate menu structure (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09d-validate-structure.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
agentMenuPatterns: ../data/agent-menu-patterns.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9c: Validate Menu (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate that the agent's menu (commands/tools) follows BMAD patterns as defined in agentMenuPatterns.md, is well-structured, properly documented, and aligns with the agent's persona and purpose. Record findings to editPlan and auto-advance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation checks** - All menu items must be verified
|
||||
- **ALWAYS load the reference document** - agentMenuPatterns.md
|
||||
- **ALWAYS load the builtYaml** for actual menu content validation
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the agentMenuPatterns.md file
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the menu patterns reference from `{agentMenuPatterns}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Read the edit plan from `{editPlan}`
|
||||
4. Extract the menu/commands section from the builtYaml
|
||||
5. Determine agent type (Simple, Expert, or Module) from metadata
|
||||
6. Compare actual menu against ALL validation rules
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in agentMenuPatterns.md:
|
||||
|
||||
1. **Menu Structure**
|
||||
- [ ] Menu section exists and is properly formatted
|
||||
- [ ] At least one menu item defined (unless intentionally tool-less)
|
||||
- [ ] Menu items follow proper YAML structure
|
||||
- [ ] Each item has required fields (name, description, pattern)
|
||||
|
||||
2. **Menu Item Requirements**
|
||||
For each menu item:
|
||||
- [ ] name: Present, unique, uses kebab-case
|
||||
- [ ] description: Clear and concise
|
||||
- [ ] pattern: Valid regex pattern or tool reference
|
||||
- [ ] scope: Appropriate scope defined (if applicable)
|
||||
|
||||
3. **Pattern Quality**
|
||||
- [ ] Patterns are valid and testable
|
||||
- [ ] Patterns are specific enough to match intended inputs
|
||||
- [ ] Patterns are not overly restrictive
|
||||
- [ ] Patterns use appropriate regex syntax
|
||||
|
||||
4. **Description Quality**
|
||||
- [ ] Each item has clear description
|
||||
- [ ] Descriptions explain what the item does
|
||||
- [ ] Descriptions are consistent in style
|
||||
- [ ] Descriptions help users understand when to use
|
||||
|
||||
5. **Alignment Checks**
|
||||
- [ ] Menu items align with agent's role/purpose
|
||||
- [ ] Menu items are supported by agent's expertise
|
||||
- [ ] Menu items fit within agent's constraints
|
||||
- [ ] Menu items are appropriate for target users
|
||||
|
||||
6. **Completeness**
|
||||
- [ ] Core capabilities for this role are covered
|
||||
- [ ] No obvious missing functionality
|
||||
- [ ] Menu scope is appropriate (not too sparse/overloaded)
|
||||
- [ ] Related functionality is grouped logically
|
||||
|
||||
7. **Standards Compliance**
|
||||
- [ ] No prohibited patterns or commands
|
||||
- [ ] No security vulnerabilities in patterns
|
||||
- [ ] No ambiguous or conflicting items
|
||||
- [ ] Consistent naming conventions
|
||||
|
||||
8. **Menu Link Validation (Agent Type Specific)**
|
||||
- [ ] Determine agent type from metadata:
|
||||
- Simple: module property is 'stand-alone' AND hasSidecar is false/absent
|
||||
- Expert: hasSidecar is true
|
||||
- Module: module property is a module code (e.g., 'bmm', 'bmb', 'bmgd', 'bmad')
|
||||
- [ ] For Expert agents (hasSidecar: true):
|
||||
- Menu handlers SHOULD reference external sidecar files (e.g., `./{agent-name}-sidecar/...`)
|
||||
- OR have inline prompts defined directly in the handler
|
||||
- [ ] For Module agents (module property is a module code):
|
||||
- Menu handlers SHOULD reference external module files under the module path
|
||||
- Exec paths must start with `{project-root}/_bmad/{module}/...`
|
||||
- Verify referenced files exist under the module directory
|
||||
- [ ] For Simple agents (stand-alone, no sidecar):
|
||||
- Menu handlers MUST NOT have external file links
|
||||
- Menu handlers SHOULD only use relative links within the same file (e.g., `#section-name`)
|
||||
- OR have inline prompts defined directly in the handler
|
||||
|
||||
### Protocol 3: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.menu`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
menu:
|
||||
status: [pass|fail|warning]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Menu structure properly formatted
|
||||
✓ 5 menu items defined, all with required fields
|
||||
✓ All patterns are valid regex
|
||||
✓ Menu items align with agent role
|
||||
✓ Agent type appropriate menu links verified
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Item "analyze-data" description is vague
|
||||
⚠ No menu item for [common capability X]
|
||||
⚠ Pattern for "custom-command" very broad, may over-match
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Duplicate menu item name: "process" appears twice
|
||||
✗ Invalid regex pattern: "[unclosed bracket"
|
||||
✗ Menu item "system-admin" violates security guidelines
|
||||
✗ No menu items defined for agent type that requires tools
|
||||
✗ Simple agent has external link in menu handler (should be relative # or inline)
|
||||
✗ Expert agent with sidecar has no external file links or inline prompts defined
|
||||
✗ Module agent exec path doesn't start with {project-root}/_bmad/{module}/...
|
||||
✗ Module agent references file that doesn't exist in module directory
|
||||
```
|
||||
|
||||
### Protocol 4: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to structure validation...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All menu checks from agentMenuPatterns.md performed
|
||||
✅ All checks validated against the actual builtYaml
|
||||
✅ Agent type-specific link validation performed
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -0,0 +1,154 @@
|
|||
---
|
||||
name: 'e-09d-validate-structure'
|
||||
description: 'Validate YAML structure (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09e-validate-sidecar.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
simpleValidation: ../data/simple-agent-validation.md
|
||||
expertValidation: ../data/expert-agent-validation.md
|
||||
agentCompilation: ../data/agent-compilation.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9d: Validate Structure (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate the built agent YAML file for structural completeness and correctness against the appropriate validation checklist (simple or expert) from agentCompilation.md. Record findings to editPlan and auto-advance.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **NEVER skip validation** - All agents must pass structural validation
|
||||
- **ALWAYS use the correct validation checklist** based on agent type (simple vs expert)
|
||||
- **ALWAYS load the builtYaml** for actual structure validation
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the agentCompilation.md file
|
||||
- **MUST check hasSidecar flag** to determine correct validation standard
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the agent compilation reference from `{agentCompilation}`
|
||||
2. Read the simple validation checklist from `{simpleValidation}`
|
||||
3. Read the expert validation checklist from `{expertValidation}`
|
||||
4. Read the built agent YAML from `{builtYaml}`
|
||||
5. Read the edit plan from `{editPlan}`
|
||||
6. Determine agent type (simple vs expert) to select correct checklist
|
||||
|
||||
### Protocol 2: Validation Checks
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in agentCompilation.md:
|
||||
|
||||
#### A. YAML Syntax Validation
|
||||
- [ ] Parse YAML without errors
|
||||
- [ ] Check indentation consistency (2-space standard)
|
||||
- [ ] Validate proper escaping of special characters
|
||||
- [ ] Verify no duplicate keys in any section
|
||||
|
||||
#### B. Frontmatter Validation
|
||||
- [ ] All required fields present (name, description, version, etc.)
|
||||
- [ ] Field values are correct type (string, boolean, array)
|
||||
- [ ] No empty required fields
|
||||
- [ ] Proper array formatting with dashes
|
||||
- [ ] Boolean fields are actual booleans (not strings)
|
||||
|
||||
#### C. Section Completeness
|
||||
- [ ] All required sections present based on agent type
|
||||
- [ ] Sections not empty unless explicitly optional
|
||||
- [ ] Proper markdown heading hierarchy (##, ###)
|
||||
- [ ] No orphaned content without section headers
|
||||
|
||||
#### D. Field-Level Validation
|
||||
- [ ] Path references exist and are valid
|
||||
- [ ] Array fields properly formatted
|
||||
- [ ] No malformed YAML structures
|
||||
- [ ] File references use correct path format
|
||||
|
||||
#### E. Agent Type Specific Checks
|
||||
|
||||
**For Simple Agents (hasSidecar is false/absent, module is 'stand-alone'):**
|
||||
- [ ] No sidecar requirements
|
||||
- [ ] No sidecar-folder path in metadata
|
||||
- [ ] Basic fields complete
|
||||
- [ ] No expert-only configuration present
|
||||
- [ ] Menu handlers use only internal references (#) or inline prompts
|
||||
|
||||
**For Expert Agents (hasSidecar is true):**
|
||||
- [ ] Sidecar flag set correctly in metadata
|
||||
- [ ] Sidecar folder path specified in metadata
|
||||
- [ ] All expert fields present
|
||||
- [ ] Advanced features properly configured
|
||||
- [ ] Menu handlers reference sidecar files or have inline prompts
|
||||
|
||||
**For Module Agents (module is a module code like 'bmm', 'bmb', etc.):**
|
||||
- [ ] Module property is valid module code
|
||||
- [ ] Exec paths for menu handlers start with `{project-root}/_bmad/{module}/...`
|
||||
- [ ] Referenced files exist under the module directory
|
||||
- [ ] If also hasSidecar: true, sidecar configuration is valid
|
||||
|
||||
### Protocol 3: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.structure`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
structure:
|
||||
agentType: [simple|expert|module]
|
||||
status: [pass|fail|warning]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed)
|
||||
```
|
||||
✓ Valid YAML syntax, no parse errors
|
||||
✓ All required frontmatter fields present
|
||||
✓ Proper 2-space indentation throughout
|
||||
✓ All required sections complete for agent type
|
||||
✓ Path references are valid
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Some optional sections are empty
|
||||
⚠ Minor formatting inconsistencies
|
||||
⚠ Some descriptions are brief
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ YAML syntax error preventing parsing
|
||||
✗ Duplicate key 'name' in metadata
|
||||
✗ Required field 'description' is empty
|
||||
✗ Invalid boolean value 'yes' (should be true/false)
|
||||
✗ Path reference points to non-existent file
|
||||
✗ Simple agent has sidecar-folder specified
|
||||
✗ Expert agent missing sidecar-folder path
|
||||
```
|
||||
|
||||
### Protocol 4: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to sidecar validation...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All structure checks from agentCompilation.md performed
|
||||
✅ Correct validation checklist used based on agent type
|
||||
✅ All checks validated against the actual builtYaml
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Agent type correctly identified and validated
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -0,0 +1,160 @@
|
|||
---
|
||||
name: 'e-09e-validate-sidecar'
|
||||
description: 'Validate sidecar structure (after edit) - no menu, auto-advance'
|
||||
|
||||
nextStepFile: './e-09f-validation-summary.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
expertValidation: ../data/expert-agent-validation.md
|
||||
criticalActions: ../data/critical-actions.md
|
||||
builtYaml: '{bmb_creations_output_folder}/{agent-name}/{agent-name}.agent.yaml'
|
||||
sidecarFolder: '{bmb_creations_output_folder}/{agent-name}/{agent-name}-sidecar/'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9e: Validate Sidecar (After Edit)
|
||||
|
||||
## STEP GOAL
|
||||
|
||||
Validate the sidecar folder structure and referenced paths for Expert agents to ensure all sidecar files exist, are properly structured, and paths in the main agent YAML correctly reference them. Record findings to editPlan and auto-advance. For Simple agents without sidecar, mark as N/A.
|
||||
|
||||
## MANDATORY EXECUTION RULES
|
||||
|
||||
- **ONLY validates for Expert agents** - Simple agents should have no sidecar
|
||||
- **MUST verify sidecar folder exists** before validating contents
|
||||
- **ALWAYS cross-reference YAML paths** with actual files
|
||||
- **ALWAYS load the builtYaml** to get sidecar configuration
|
||||
- **ALWAYS use absolute paths** when referencing files
|
||||
- **CRITICAL:** Load and validate EVERYTHING specified in the expertValidation.md file
|
||||
- **PROVIDE clear remediation steps** for any missing or malformed files
|
||||
- **🚫 NO MENU in this step** - record findings and auto-advance
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## EXECUTION PROTOCOLS
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
1. Read the expert validation reference from `{expertValidation}`
|
||||
2. Read the critical actions reference from `{criticalActions}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
4. Read the edit plan from `{editPlan}`
|
||||
5. Determine if agent has sidecar from metadata
|
||||
|
||||
### Protocol 2: Conditional Validation
|
||||
|
||||
**IF agent has hasSidecar: false OR agent is Simple:**
|
||||
- [ ] Mark sidecar validation as N/A
|
||||
- [ ] Confirm no sidecar-folder path in metadata
|
||||
- [ ] Confirm no sidecar references in menu handlers
|
||||
|
||||
**IF agent has hasSidecar: true OR agent is Expert/Module with sidecar:**
|
||||
- [ ] Proceed with full sidecar validation
|
||||
|
||||
### Protocol 3: Sidecar Validation Checks (For Expert Agents)
|
||||
|
||||
Perform these checks systematically - validate EVERY rule specified in expertValidation.md:
|
||||
|
||||
#### A. Sidecar Folder Validation
|
||||
- [ ] Sidecar folder exists at specified path
|
||||
- [ ] Sidecar folder is accessible and readable
|
||||
- [ ] Sidecar folder path in metadata matches actual location
|
||||
- [ ] Folder naming follows convention: `{agent-name}-sidecar`
|
||||
|
||||
#### B. Sidecar File Inventory
|
||||
- [ ] List all files in sidecar folder
|
||||
- [ ] Verify expected files are present
|
||||
- [ ] Check for unexpected files
|
||||
- [ ] Validate file names follow conventions
|
||||
|
||||
#### C. Path Reference Validation
|
||||
For each sidecar path reference in agent YAML:
|
||||
- [ ] Extract path from YAML reference
|
||||
- [ ] Verify file exists at referenced path
|
||||
- [ ] Check path format is correct (relative/absolute as expected)
|
||||
- [ ] Validate no broken path references
|
||||
|
||||
#### D. Critical Actions File Validation (if present)
|
||||
- [ ] critical-actions.md file exists
|
||||
- [ ] File has proper frontmatter
|
||||
- [ ] Actions section is present and not empty
|
||||
- [ ] No critical sections missing
|
||||
- [ ] File content is complete (not just placeholder)
|
||||
|
||||
#### E. Module Files Validation (if present)
|
||||
- [ ] Module files exist at referenced paths
|
||||
- [ ] Each module file has proper frontmatter
|
||||
- [ ] Module file content is complete
|
||||
- [ ] No empty or placeholder module files
|
||||
|
||||
#### F. Sidecar Structure Completeness
|
||||
- [ ] All referenced sidecar files present
|
||||
- [ ] No orphaned references (files referenced but not present)
|
||||
- [ ] No unreferenced files (files present but not referenced)
|
||||
- [ ] File structure matches expert agent requirements
|
||||
|
||||
### Protocol 4: Record Findings
|
||||
|
||||
Organize findings into three sections and append to editPlan frontmatter under `validationAfter.sidecar`:
|
||||
|
||||
```yaml
|
||||
validationAfter:
|
||||
sidecar:
|
||||
hasSidecar: [true|false]
|
||||
status: [pass|fail|warning|n/a]
|
||||
passing:
|
||||
- "{check description}"
|
||||
- "{check description}"
|
||||
warnings:
|
||||
- "{non-blocking issue}"
|
||||
failures:
|
||||
- "{blocking issue that must be fixed}"
|
||||
```
|
||||
|
||||
**PASSING CHECKS** (List what passed - for Expert agents)**
|
||||
```
|
||||
✓ Sidecar folder exists at expected path
|
||||
✓ All referenced files present
|
||||
✓ No broken path references
|
||||
✓ Critical actions file complete
|
||||
✓ Module files properly structured
|
||||
✓ File structure matches expert requirements
|
||||
```
|
||||
|
||||
**WARNINGS** (Non-blocking issues)
|
||||
```
|
||||
⚠ Additional files in sidecar not referenced
|
||||
⚠ Some module files are minimal
|
||||
⚠ Sidecar has no modules (may be intentional)
|
||||
```
|
||||
|
||||
**FAILURES** (Blocking issues that must be fixed)
|
||||
```
|
||||
✗ Sidecar folder completely missing
|
||||
✗ Sidecar folder path in metadata doesn't match actual location
|
||||
✗ Critical file missing: critical-actions.md
|
||||
✗ Broken path reference: {path} not found
|
||||
✗ Referenced file is empty or placeholder
|
||||
✗ Module file missing frontmatter
|
||||
✗ Simple agent has sidecar configuration (should not)
|
||||
```
|
||||
|
||||
**N/A FOR SIMPLE AGENTS:**
|
||||
```
|
||||
N/A - Agent is Simple type (hasSidecar: false, no sidecar required)
|
||||
```
|
||||
|
||||
### Protocol 5: Auto-Advance
|
||||
|
||||
**🚫 NO MENU PRESENTED** - After recording findings, immediately load and execute `{nextStepFile}`
|
||||
|
||||
---
|
||||
|
||||
**Auto-advancing to validation summary...**
|
||||
|
||||
## SUCCESS METRICS
|
||||
|
||||
✅ All sidecar checks from expertValidation.md performed (or N/A for Simple)
|
||||
✅ All checks validated against the actual builtYaml and file system
|
||||
✅ Findings saved to editPlan with detailed status
|
||||
✅ Agent type correctly identified (sidecar vs non-sidecar)
|
||||
✅ Auto-advanced to next step
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
---
|
||||
name: 'e-09f-validation-summary'
|
||||
description: 'Display all validation findings after edit'
|
||||
|
||||
nextStepFile: './e-10-celebrate.md'
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Edit Step 9f: Validation Summary (After Edit)
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Display all post-edit validation findings and compare with pre-edit state. Present findings and await confirmation to proceed to celebration.
|
||||
|
||||
## MANDATORY EXECUTION RULES:
|
||||
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: Read editPlan to collect all validation findings
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Display all validation findings clearly organized
|
||||
- 📊 Compare before/after states
|
||||
- 💬 Present options for handling any remaining issues
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Read editPlan to get validation findings
|
||||
- 📊 Display organized summary with before/after comparison
|
||||
- 💾 Allow user to decide how to proceed
|
||||
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Validation Findings
|
||||
|
||||
Read `{editPlan}` frontmatter to collect validationBefore and validationAfter findings.
|
||||
|
||||
### 2. Display Validation Summary
|
||||
|
||||
```markdown
|
||||
## Post-Edit Validation Report for {agent-name}
|
||||
|
||||
### Before vs After Comparison
|
||||
|
||||
| Component | Before | After | Status |
|
||||
|-----------|--------|-------|--------|
|
||||
| Metadata | {status} | {status} | {Δ} |
|
||||
| Persona | {status} | {status} | {Δ} |
|
||||
| Menu | {status} | {status} | {Δ} |
|
||||
| Structure | {status} | {status} | {Δ} |
|
||||
| Sidecar | {status} | {status} | {Δ} |
|
||||
|
||||
### Detailed Findings (After Edit)
|
||||
|
||||
**Metadata:** {summary}
|
||||
**Persona:** {summary}
|
||||
**Menu:** {summary}
|
||||
**Structure:** {summary}
|
||||
**Sidecar:** {summary}
|
||||
```
|
||||
|
||||
### 3. Present Options
|
||||
|
||||
"How do the edits look?
|
||||
|
||||
**[R]eview** - Show detailed before/after for any component
|
||||
**[F]ix** - Address any remaining issues
|
||||
**[A]ccept** - Proceed to celebration"
|
||||
|
||||
### 4. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Celebration"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF R: Show detailed before/after comparison, then redisplay menu
|
||||
- IF C: Save validation summary to {editPlan}, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [validation summary displayed], will you then load and read fully `{nextStepFile}` to execute and celebrate completion.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All validation findings displayed clearly
|
||||
- Before/after comparison shown
|
||||
- User given options for handling issues
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Findings not displayed to user
|
||||
- Proceeding without user acknowledgment
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -1,15 +1,14 @@
|
|||
---
|
||||
name: 'e-09-celebrate'
|
||||
name: 'e-10-celebrate'
|
||||
description: 'Celebrate successful agent edit completion'
|
||||
|
||||
editPlan: '{bmb_creations_output_folder}/edit-plan-{agent-name}.md'
|
||||
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
validationWorkflow: '{project-root}/src/modules/bmb/workflows/agent/steps-v/v-01-load-review.md'
|
||||
---
|
||||
|
||||
# Edit Step 9: Celebration
|
||||
# Edit Step 10: Celebration
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
|
|
@ -49,9 +48,7 @@ Celebrate the successful agent edit, provide summary of changes, and mark edit w
|
|||
- Limits: No more edits, only acknowledgment
|
||||
- Dependencies: All edits successfully applied
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.:
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Read Edit Plan
|
||||
|
||||
|
|
@ -113,26 +110,24 @@ Append to editPlan:
|
|||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: "**✅ Agent Edit Complete! Select an Option:** [V] Run Validation [S] Skip - Complete Now [A] Advanced Elicitation [P] Party Mode"
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [X] Exit Workflow"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF V: "Loading validation phase..." → Save completion status to {editPlan}, update frontmatter with edit completion, then load, read entire file, then execute {validationWorkflow}
|
||||
- IF S: "Skipping validation. Completing workflow..." → Save completion status to {editPlan} and end workflow gracefully
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF X: Save completion status to {editPlan} and end workflow gracefully
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#6-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- User can choose validation (V), skip to complete (S), or use advanced elicitation (A) or party mode (P)
|
||||
- After other menu items execution (A/P), return to this menu
|
||||
- ONLY complete workflow when user selects 'X'
|
||||
- After other menu items execution, return to this menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [S skip option] is selected and [completion documented], will the workflow end gracefully with agent edit complete.
|
||||
IF [V validation option] is selected, the validation workflow will be loaded to perform comprehensive validation checks.
|
||||
ONLY WHEN [X exit option] is selected and [completion documented], will the workflow end gracefully with agent edit complete.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -34,9 +34,7 @@ Load the existing agent file and initialize a validation report to track all fin
|
|||
- 💾 Create validation report document
|
||||
- 🚫 FORBIDDEN to proceed without user confirmation
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Agent File
|
||||
|
||||
|
|
@ -70,7 +68,7 @@ Initialize the validation report:
|
|||
```markdown
|
||||
---
|
||||
agentName: '{agent-name}'
|
||||
agentType: '{simple|expert|module}' # Derived from module + hasSidecar
|
||||
agentType: '{simple|expert|module}'
|
||||
agentFile: '{agent-file-path}'
|
||||
validationDate: '{YYYY-MM-DD}'
|
||||
stepsCompleted:
|
||||
|
|
@ -82,9 +80,8 @@ stepsCompleted:
|
|||
## Agent Overview
|
||||
|
||||
**Name:** {agent-name}
|
||||
**Type:** {simple|expert|module} # Derived from: module + hasSidecar
|
||||
**module:** {module-value}
|
||||
**hasSidecar:** {true|false}
|
||||
**Type:** {simple|expert|module}
|
||||
**Version:** {version}
|
||||
**File:** {agent-file-path}
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -36,9 +36,7 @@ Validate the agent's metadata properties against BMAD standards as defined in ag
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
|
|||
|
|
@ -37,9 +37,7 @@ Validate the agent's persona against BMAD standards as defined in personaPropert
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
|
|||
|
|
@ -36,9 +36,7 @@ Validate the agent's command menu structure against BMAD standards as defined in
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
|
|||
|
|
@ -38,9 +38,7 @@ Validate the agent's YAML structure and completeness against BMAD standards as d
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
|
|||
|
|
@ -38,9 +38,7 @@ Validate the agent's sidecar structure (if Expert type) against BMAD standards a
|
|||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to summary step
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
|
@ -48,7 +46,7 @@ Read `{expertValidation}`, `{criticalActions}`, `{validationReport}`, and `{agen
|
|||
|
||||
### 2. Conditional Validation
|
||||
|
||||
**IF (module = "stand-alone" AND hasSidecar = true) OR (module ≠ "stand-alone" AND hasSidecar = true):**
|
||||
**IF agentType == expert OR (agentType == module AND hasSidecar == true):**
|
||||
Perform these checks systematically - validate EVERY rule specified in expertValidation.md:
|
||||
|
||||
#### A. Sidecar Folder Validation
|
||||
|
|
@ -89,7 +87,7 @@ For each sidecar path reference in agent YAML:
|
|||
- [ ] No unreferenced files (files present but not referenced)
|
||||
- [ ] File structure matches expert agent requirements
|
||||
|
||||
**IF (module = "stand-alone" AND hasSidecar = false):**
|
||||
**IF agentType is Simple (no sidecar):**
|
||||
- [ ] Mark sidecar validation as N/A
|
||||
- [ ] Confirm no sidecar-folder path in metadata
|
||||
- [ ] Confirm no sidecar references in menu handlers
|
||||
|
|
@ -124,7 +122,7 @@ Append to `{validationReport}`:
|
|||
{List of blocking issues that must be fixed}
|
||||
|
||||
*N/A (for Simple agents):*
|
||||
N/A - Agent is Simple type (module = "stand-alone" + hasSidecar: false, no sidecar required)
|
||||
N/A - Agent is Simple type (hasSidecar: false, no sidecar required)
|
||||
```
|
||||
|
||||
### 4. Auto-Advance
|
||||
|
|
|
|||
|
|
@ -32,9 +32,7 @@ Display the complete validation report to the user and offer options for fixing
|
|||
- 📊 Display organized summary
|
||||
- 💾 Allow user to decide next steps
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## Sequence of Instructions:
|
||||
|
||||
### 1. Load Validation Report
|
||||
|
||||
|
|
|
|||
|
|
@ -2,11 +2,18 @@
|
|||
name: 'step-01-init'
|
||||
description: 'Initialize the nutrition plan workflow by detecting continuation state and creating output document'
|
||||
|
||||
nextStepFile: './step-02-profile.md'
|
||||
continueFile: './step-01b-continue.md'
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01-init.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-profile.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
templateFile: '../templates/nutrition-plan.md'
|
||||
templateFile: '{workflow_path}/templates/nutrition-plan.md'
|
||||
continueFile: '{workflow_path}/steps/step-01b-continue.md'
|
||||
# Template References
|
||||
# This step doesn't use content templates, only the main template
|
||||
---
|
||||
|
||||
# Step 1: Workflow Initialization
|
||||
|
|
@ -2,7 +2,15 @@
|
|||
name: 'step-01b-continue'
|
||||
description: 'Handle workflow continuation from previous session'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01b-continue.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
# Template References
|
||||
# This step doesn't use content templates, reads from existing output file
|
||||
---
|
||||
|
||||
# Step 1B: Workflow Continuation
|
||||
|
|
@ -111,15 +119,15 @@ Display: **Resuming workflow - Select an Option:** [C] Continue
|
|||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Update frontmatter with continuation info, then load, read entire file, then execute appropriate next step based on `lastStep`
|
||||
- IF lastStep = "init": load ./step-03-assessment.md
|
||||
- IF lastStep = "assessment": load ./step-04-strategy.md
|
||||
- IF lastStep = "strategy": check cooking frequency, then load load ./step-04-shopping.md
|
||||
- IF lastStep = "shopping": load ./step-06-prep-schedule.md
|
||||
- IF lastStep = "init": load {workflow_path}/step-03-assessment.md
|
||||
- IF lastStep = "assessment": load {workflow_path}/step-04-strategy.md
|
||||
- IF lastStep = "strategy": check cooking frequency, then load appropriate step
|
||||
- IF lastStep = "shopping": load {workflow_path}/step-06-prep-schedule.md
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and continuation analysis is complete, will you then update frontmatter and load, read entire file, then execute the appropriate next step file as outlined in menu handling logic.
|
||||
ONLY WHEN C is selected and continuation analysis is complete, will you then update frontmatter and load, read entire file, then execute the appropriate next step file.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -2,7 +2,13 @@
|
|||
name: 'step-02-profile'
|
||||
description: 'Gather comprehensive user profile information through collaborative conversation'
|
||||
|
||||
nextStepFile: './step-03-assessment.md'
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
|
||||
|
||||
# File References (all use {variable} format in file)
|
||||
thisStepFile: '{workflow_path}/steps/step-02-profile.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-assessment.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
|
|
@ -10,7 +16,7 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
|||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
profileTemplate: '../templates/profile-section.md'
|
||||
profileTemplate: '{workflow_path}/templates/profile-section.md'
|
||||
---
|
||||
|
||||
# Step 2: User Profile & Goals Collection
|
||||
|
|
@ -2,7 +2,13 @@
|
|||
name: 'step-03-assessment'
|
||||
description: 'Analyze nutritional requirements, identify restrictions, and calculate target macros'
|
||||
|
||||
nextStepFile: './step-04-strategy.md'\
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-03-assessment.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-strategy.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
|
|
@ -10,11 +16,11 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
|||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Data References
|
||||
dietaryRestrictionsDB: '../data/dietary-restrictions.csv'
|
||||
macroCalculatorDB: '../data/macro-calculator.csv'
|
||||
dietaryRestrictionsDB: '{workflow_path}/data/dietary-restrictions.csv'
|
||||
macroCalculatorDB: '{workflow_path}/data/macro-calculator.csv'
|
||||
|
||||
# Template References
|
||||
assessmentTemplate: '../templates/assessment-section.md'
|
||||
assessmentTemplate: '{workflow_path}/templates/assessment-section.md'
|
||||
---
|
||||
|
||||
# Step 3: Dietary Needs & Restrictions Assessment
|
||||
|
|
@ -2,8 +2,14 @@
|
|||
name: 'step-04-strategy'
|
||||
description: 'Design a personalized meal strategy that meets nutritional needs and fits lifestyle'
|
||||
|
||||
nextStepFile: './step-05-shopping.md'
|
||||
alternateNextStepFile: './step-06-prep-schedule.md'
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-strategy.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-05-shopping.md'
|
||||
alternateNextStepFile: '{workflow_path}/steps/step-06-prep-schedule.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
|
|
@ -11,10 +17,10 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
|||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Data References
|
||||
recipeDatabase: '../data/recipe-database.csv'
|
||||
recipeDatabase: '{workflow_path}/data/recipe-database.csv'
|
||||
|
||||
# Template References
|
||||
strategyTemplate: '../templates/strategy-section.md'
|
||||
strategyTemplate: '{workflow_path}/templates/strategy-section.md'
|
||||
---
|
||||
|
||||
# Step 4: Meal Strategy Creation
|
||||
|
|
@ -2,7 +2,13 @@
|
|||
name: 'step-05-shopping'
|
||||
description: 'Create a comprehensive shopping list that supports the meal strategy'
|
||||
|
||||
nextStepFile: './step-06-prep-schedule.md'
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-05-shopping.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-06-prep-schedule.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
|
|
@ -10,7 +16,7 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
|||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
shoppingTemplate: '../templates/shopping-section.md'
|
||||
shoppingTemplate: '{workflow_path}/templates/shopping-section.md'
|
||||
---
|
||||
|
||||
# Step 5: Shopping List Generation
|
||||
|
|
@ -2,6 +2,12 @@
|
|||
name: 'step-06-prep-schedule'
|
||||
description: "Create a realistic meal prep schedule that fits the user's lifestyle"
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06-prep-schedule.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
|
|
@ -9,7 +15,7 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
|||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
prepScheduleTemplate: '../templates/prep-schedule-section.md'
|
||||
prepScheduleTemplate: '{workflow_path}/templates/prep-schedule-section.md'
|
||||
---
|
||||
|
||||
# Step 6: Meal Prep Execution Schedule
|
||||
|
|
@ -55,4 +55,4 @@ Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
|
|||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Load, read the full file and then execute `./steps-c/step-01-init.md` to begin the workflow.
|
||||
Load, read the full file and then execute `{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/steps/step-01-init.md` to begin the workflow.
|
||||
|
|
@ -0,0 +1,158 @@
|
|||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize workflow creation session by gathering project information and setting up unique workflow folder'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01-init.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-gather.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
# Template References
|
||||
# No workflow plan template needed - will create plan file directly
|
||||
---
|
||||
|
||||
# Step 1: Workflow Creation Initialization
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To initialize the workflow creation process by understanding project context, determining a unique workflow name, and preparing for collaborative workflow design.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and systems designer
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring workflow design expertise, user brings their specific requirements
|
||||
- ✅ Together we will create a structured, repeatable workflow
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on initialization and project understanding
|
||||
- 🚫 FORBIDDEN to start designing workflow steps in this step
|
||||
- 💬 Ask questions conversationally to understand context
|
||||
- 🚪 ENSURE unique workflow naming to avoid conflicts
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Show analysis before taking any action
|
||||
- 💾 Initialize document and update frontmatter
|
||||
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until initialization is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Variables from workflow.md are available in memory
|
||||
- Previous context = what's in output document + frontmatter
|
||||
- Don't assume knowledge from other steps
|
||||
- Input discovery happens in this step
|
||||
|
||||
## INITIALIZATION SEQUENCE:
|
||||
|
||||
### 1. Project Discovery
|
||||
|
||||
Welcome the user and understand their needs:
|
||||
"Welcome! I'm excited to help you create a new workflow. Let's start by understanding what you want to build."
|
||||
|
||||
Ask conversationally:
|
||||
|
||||
- What type of workflow are you looking to create?
|
||||
- What problem will this workflow solve?
|
||||
- Who will use this workflow?
|
||||
- What module will it belong to (bmb, bmm, cis, custom, stand-alone)?
|
||||
|
||||
Also, Ask / suggest a workflow name / folder: (kebab-case, e.g., "user-story-generator")
|
||||
|
||||
### 2. Ensure Unique Workflow Name
|
||||
|
||||
After getting the workflow name:
|
||||
|
||||
**Check for existing workflows:**
|
||||
|
||||
- Look for folder at `{bmb_creations_output_folder}/workflows/{new_workflow_name}/`
|
||||
- If it exists, inform the user and suggest or get from them a unique name or postfix
|
||||
|
||||
**Example alternatives:**
|
||||
|
||||
- Original: "user-story-generator"
|
||||
- Alternatives: "user-story-creator", "user-story-generator-2025", "user-story-generator-enhanced"
|
||||
|
||||
**Loop until we have a unique name that doesn't conflict.**
|
||||
|
||||
### 3. Determine Target Location
|
||||
|
||||
Based on the module selection, confirm the target location:
|
||||
|
||||
- For bmb module: `{custom_workflow_location}` (defaults to `_bmad/custom/src/workflows`)
|
||||
- For other modules: Check their module.yaml for custom workflow locations
|
||||
- Confirm the exact folder path where the workflow will be created
|
||||
- Store the confirmed path as `{targetWorkflowPath}`
|
||||
|
||||
### 4. Create Workflow Plan Document
|
||||
|
||||
Create the workflow plan document at `{workflowPlanFile}` with the following initial content:
|
||||
|
||||
```markdown
|
||||
---
|
||||
stepsCompleted: [1]
|
||||
---
|
||||
|
||||
# Workflow Creation Plan: {new_workflow_name}
|
||||
|
||||
## Initial Project Context
|
||||
|
||||
- **Module:** [module from user]
|
||||
- **Target Location:** {targetWorkflowPath}
|
||||
- **Created:** [current date]
|
||||
```
|
||||
|
||||
This plan will capture all requirements and design details before building the actual workflow.
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **Proceeding to requirements gathering...**
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- This is an initialization step with no user choices
|
||||
- Proceed directly to next step after setup
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- After setup completion and the workflow folder with the workflow plan file created already, only then immediately load, read entire file, and then execute `{workflow_path}/steps/step-02-gather.md` to begin requirements gathering
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Workflow name confirmed and validated
|
||||
- Target folder location determined
|
||||
- User welcomed and project context understood
|
||||
- Ready to proceed to step 2
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding with step 2 without workflow name
|
||||
- Not checking for existing workflow folders
|
||||
- Not determining target location properly
|
||||
- Skipping welcome message
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,212 @@
|
|||
---
|
||||
name: 'step-02-gather'
|
||||
description: 'Gather comprehensive requirements for the workflow being created'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-02-gather.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-tools-configuration.md'
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
# Template References
|
||||
# No template needed - will append requirements directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 2: Requirements Gathering
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To gather comprehensive requirements through collaborative conversation that will inform the design of a structured workflow tailored to the user's needs and use case.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and systems designer
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring workflow design expertise and best practices
|
||||
- ✅ User brings their domain knowledge and specific requirements
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on collecting requirements and understanding needs
|
||||
- 🚫 FORBIDDEN to propose workflow solutions or step designs in this step
|
||||
- 💬 Ask questions conversationally, not like a form
|
||||
- 🚫 DO NOT skip any requirement area - each affects workflow design
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Engage in natural conversation to gather requirements
|
||||
- 💾 Store all requirements information for workflow design
|
||||
- 📖 Proceed to next step with 'C' selection
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Workflow name and target location from initialization
|
||||
- Focus ONLY on collecting requirements and understanding needs
|
||||
- Don't provide workflow designs in this step
|
||||
- This is about understanding, not designing
|
||||
|
||||
## REQUIREMENTS GATHERING PROCESS:
|
||||
|
||||
### 1. Workflow Purpose and Scope
|
||||
|
||||
Explore through conversation:
|
||||
|
||||
- What specific problem will this workflow solve?
|
||||
- Who is the primary user of this workflow?
|
||||
- What is the main outcome or deliverable?
|
||||
|
||||
### 2. Workflow Type Classification
|
||||
|
||||
Help determine the workflow type:
|
||||
|
||||
- **Document Workflow**: Generates documents (PRDs, specs, plans)
|
||||
- **Action Workflow**: Performs actions (refactoring, tools orchestration)
|
||||
- **Interactive Workflow**: Guided sessions (brainstorming, coaching, training, practice)
|
||||
- **Autonomous Workflow**: Runs without human input (batch processing, multi-step tasks)
|
||||
- **Meta-Workflow**: Coordinates other workflows
|
||||
|
||||
### 3. Workflow Flow and Step Structure
|
||||
|
||||
Let's load some examples to help you decide the workflow pattern:
|
||||
|
||||
Load and reference the Meal Prep & Nutrition Plan workflow as an example:
|
||||
|
||||
```
|
||||
Read: {project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/workflow.md
|
||||
```
|
||||
|
||||
This shows a linear workflow structure. Now let's explore your desired pattern:
|
||||
|
||||
- Should this be a linear workflow (step 1 → step 2 → step 3 → finish)?
|
||||
- Or should it have loops/repeats (e.g., keep generating items until user says done)?
|
||||
- Are there branching points based on user choices?
|
||||
- Should some steps be optional?
|
||||
- How many logical phases does this workflow need? (e.g., Gather → Design → Validate → Generate)
|
||||
|
||||
**Based on our reference examples:**
|
||||
|
||||
- **Linear**: Like Meal Prep Plan (Init → Profile → Assessment → Strategy → Shopping → Prep)
|
||||
- See: `{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/`
|
||||
- **Looping**: User Story Generator (Generate → Review → Refine → Generate more... until done)
|
||||
- **Branching**: Architecture Decision (Analyze → Choose pattern → Implement based on choice)
|
||||
- **Iterative**: Document Review (Load → Analyze → Suggest changes → Implement → Repeat until approved)
|
||||
|
||||
### 4. User Interaction Style
|
||||
|
||||
Understand the desired interaction level:
|
||||
|
||||
- How much user input is needed during execution?
|
||||
- Should it be highly collaborative or mostly autonomous?
|
||||
- Are there specific decision points where user must choose?
|
||||
- Should the workflow adapt to user responses?
|
||||
|
||||
### 5. Instruction Style (Intent-Based vs Prescriptive)
|
||||
|
||||
Determine how the AI should execute in this workflow:
|
||||
|
||||
**Intent-Based (Recommended for most workflows)**:
|
||||
|
||||
- Steps describe goals and principles, letting the AI adapt conversation naturally
|
||||
- More flexible, conversational, responsive to user context
|
||||
- Example: "Guide user to define their requirements through open-ended discussion"
|
||||
|
||||
**Prescriptive**:
|
||||
|
||||
- Steps provide exact instructions and specific text to use
|
||||
- More controlled, predictable, consistent across runs
|
||||
- Example: "Ask: 'What is your primary goal? Choose from: A) Growth B) Efficiency C) Quality'"
|
||||
|
||||
Which style does this workflow need, or should it be a mix of both?
|
||||
|
||||
### 6. Input Requirements
|
||||
|
||||
Identify what the workflow needs:
|
||||
|
||||
- What documents or data does the workflow need to start?
|
||||
- Are there prerequisites or dependencies?
|
||||
- Will users need to provide specific information?
|
||||
- Are there optional inputs that enhance the workflow?
|
||||
|
||||
### 7. Output Specifications
|
||||
|
||||
Define what the workflow produces:
|
||||
|
||||
- What is the primary output (document, action, decision)?
|
||||
- Are there intermediate outputs or checkpoints?
|
||||
- Should outputs be saved automatically?
|
||||
- What format should outputs be in?
|
||||
|
||||
### 8. Success Criteria
|
||||
|
||||
Define what makes the workflow successful:
|
||||
|
||||
- How will you know the workflow achieved its goal?
|
||||
- What are the quality criteria for outputs?
|
||||
- Are there measurable outcomes?
|
||||
- What would make a user satisfied with the result?
|
||||
|
||||
#### STORE REQUIREMENTS:
|
||||
|
||||
After collecting all requirements, append them to {workflowPlanFile} in a format that will be be used later to design in more detail and create the workflow structure.
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Append requirements to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and requirements are stored in the output file, will you then load, read entire file, then execute {nextStepFile} to execute and begin workflow structure design step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Requirements collected through conversation (not interrogation)
|
||||
- All workflow aspects documented
|
||||
- Requirements stored using template
|
||||
- Menu presented and user input handled correctly
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating workflow designs without requirements
|
||||
- Skipping requirement areas
|
||||
- Proceeding to next step without 'C' selection
|
||||
- Not storing requirements properly
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,251 @@
|
|||
---
|
||||
name: 'step-03-tools-configuration'
|
||||
description: 'Configure all required tools (core, memory, external) and installation requirements in one comprehensive step'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-03-tools-configuration.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-plan-review.md'
|
||||
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Documentation References
|
||||
commonToolsCsv: '{project-root}/_bmad/bmb/docs/workflows/common-workflow-tools.csv'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
# Template References
|
||||
# No template needed - will append tools configuration directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 3: Tools Configuration
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To comprehensively configure all tools needed for the workflow (core tools, memory, external tools) and determine installation requirements.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and integration specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in BMAD tools and integration patterns
|
||||
- ✅ User brings their workflow requirements and preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on configuring tools based on workflow requirements
|
||||
- 🚫 FORBIDDEN to skip tool categories - each affects workflow design
|
||||
- 💬 Present options clearly, let user make informed choices
|
||||
- 🚫 DO NOT hardcode tool descriptions - reference CSV
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load tools dynamically from CSV, not hardcoded
|
||||
- 💾 Document all tool choices in workflow plan
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Requirements from step 2 inform tool selection
|
||||
- All tool choices affect workflow design
|
||||
- This is the ONLY tools configuration step
|
||||
- Installation requirements affect implementation decisions
|
||||
|
||||
## TOOLS CONFIGURATION PROCESS:
|
||||
|
||||
### 1. Initialize Tools Configuration
|
||||
|
||||
"Configuring **Tools and Integrations**
|
||||
|
||||
Based on your workflow requirements, let's configure all the tools your workflow will need. This includes core BMAD tools, memory systems, and any external integrations."
|
||||
|
||||
### 2. Load and Present Available Tools
|
||||
|
||||
Load `{commonToolsCsv}` and present tools by category:
|
||||
|
||||
"**Available BMAD Tools and Integrations:**
|
||||
|
||||
**Core Tools (Always Available):**
|
||||
|
||||
- [List tools from CSV where propose='always', with descriptions]
|
||||
|
||||
**Optional Tools (Available When Needed):**
|
||||
|
||||
- [List tools from CSV where propose='example', with descriptions]
|
||||
|
||||
_Note: I'm loading these dynamically from our tools database to ensure you have the most current options._"
|
||||
|
||||
### 3. Configure Core BMAD Tools
|
||||
|
||||
"**Core BMAD Tools Configuration:**
|
||||
|
||||
These tools significantly enhance workflow quality and user experience:"
|
||||
|
||||
For each core tool from CSV (`propose='always'`):
|
||||
|
||||
1. **Party-Mode**
|
||||
- Use case: [description from CSV]
|
||||
- Where to integrate: [ask user for decision points, creative phases]
|
||||
|
||||
2. **Advanced Elicitation**
|
||||
- Use case: [description from CSV]
|
||||
- Where to integrate: [ask user for quality gates, review points]
|
||||
|
||||
3. **Brainstorming**
|
||||
- Use case: [description from CSV]
|
||||
- Where to integrate: [ask user for idea generation, innovation points]
|
||||
|
||||
### 4. Configure LLM Features
|
||||
|
||||
"**LLM Feature Integration:**
|
||||
|
||||
These capabilities enhance what your workflow can do:"
|
||||
|
||||
From CSV (`propose='always'` LLM features):
|
||||
|
||||
4. **Web-Browsing**
|
||||
- Capability: [description from CSV]
|
||||
- When needed: [ask user about real-time data needs]
|
||||
|
||||
5. **File I/O**
|
||||
- Capability: [description from CSV]
|
||||
- Operations: [ask user about file operations needed]
|
||||
|
||||
6. **Sub-Agents**
|
||||
- Capability: [description from CSV]
|
||||
- Use cases: [ask user about delegation needs]
|
||||
|
||||
7. **Sub-Processes**
|
||||
- Capability: [description from CSV]
|
||||
- Use cases: [ask user about parallel processing needs]
|
||||
|
||||
### 5. Configure Memory Systems
|
||||
|
||||
"**Memory and State Management:**
|
||||
|
||||
Determine if your workflow needs to maintain state between sessions:"
|
||||
|
||||
From CSV memory tools:
|
||||
|
||||
8. **Sidecar File**
|
||||
- Use case: [description from CSV]
|
||||
- Needed when: [ask about session continuity, agent initialization]
|
||||
|
||||
### 6. Configure External Tools (Optional)
|
||||
|
||||
"**External Integrations (Optional):**
|
||||
|
||||
These tools connect your workflow to external systems:"
|
||||
|
||||
From CSV (`propose='example'`):
|
||||
|
||||
- MCP integrations, database connections, APIs, etc.
|
||||
- For each relevant tool: present description and ask if needed
|
||||
- Note any installation requirements
|
||||
|
||||
### 7. Installation Requirements Assessment
|
||||
|
||||
"**Installation and Dependencies:**
|
||||
|
||||
Some tools require additional setup:"
|
||||
|
||||
Based on selected tools:
|
||||
|
||||
- Identify tools requiring installation
|
||||
- Assess user's comfort level with installations
|
||||
- Document installation requirements
|
||||
|
||||
### 8. Document Complete Tools Configuration
|
||||
|
||||
Append to {workflowPlanFile}:
|
||||
|
||||
```markdown
|
||||
## Tools Configuration
|
||||
|
||||
### Core BMAD Tools
|
||||
|
||||
- **Party-Mode**: [included/excluded] - Integration points: [specific phases]
|
||||
- **Advanced Elicitation**: [included/excluded] - Integration points: [specific phases]
|
||||
- **Brainstorming**: [included/excluded] - Integration points: [specific phases]
|
||||
|
||||
### LLM Features
|
||||
|
||||
- **Web-Browsing**: [included/excluded] - Use cases: [specific needs]
|
||||
- **File I/O**: [included/excluded] - Operations: [file management needs]
|
||||
- **Sub-Agents**: [included/excluded] - Use cases: [delegation needs]
|
||||
- **Sub-Processes**: [included/excluded] - Use cases: [parallel processing needs]
|
||||
|
||||
### Memory Systems
|
||||
|
||||
- **Sidecar File**: [included/excluded] - Purpose: [state management needs]
|
||||
|
||||
### External Integrations
|
||||
|
||||
- [List selected external tools with purposes]
|
||||
|
||||
### Installation Requirements
|
||||
|
||||
- [List tools requiring installation]
|
||||
- **User Installation Preference**: [willing/not willing]
|
||||
- **Alternative Options**: [if not installing certain tools]
|
||||
```
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save tools configuration to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#9-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and tools configuration is saved will you load {nextStepFile} to review the complete plan.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All tool categories configured based on requirements
|
||||
- User made informed choices for each tool
|
||||
- Complete configuration documented in plan
|
||||
- Installation requirements identified
|
||||
- Ready to proceed to plan review
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping tool categories
|
||||
- Hardcoding tool descriptions instead of using CSV
|
||||
- Not documenting user choices
|
||||
- Proceeding without user confirmation
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,217 @@
|
|||
---
|
||||
name: 'step-04-plan-review'
|
||||
description: 'Review complete workflow plan (requirements + tools) and get user approval before design'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-plan-review.md'
|
||||
nextStepFormDesign: '{workflow_path}/steps/step-05-output-format-design.md'
|
||||
nextStepDesign: '{workflow_path}/steps/step-06-design.md'
|
||||
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
# Template References
|
||||
# No template needed - will append review summary directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 4: Plan Review and Approval
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To present the complete workflow plan (requirements and tools configuration) for user review and approval before proceeding to design.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and systems designer
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in workflow design review and quality assurance
|
||||
- ✅ User brings their specific requirements and approval authority
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on reviewing and refining the plan
|
||||
- 🚫 FORBIDDEN to start designing workflow steps in this step
|
||||
- 💬 Present plan clearly and solicit feedback
|
||||
- 🚫 DO NOT proceed to design without user approval
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Present complete plan summary from {workflowPlanFile}
|
||||
- 💾 Capture any modifications or refinements
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user approves plan
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All requirements from step 2 are available
|
||||
- Tools configuration from step 3 is complete
|
||||
- Focus ONLY on review and approval
|
||||
- This is the final check before design phase
|
||||
|
||||
## PLAN REVIEW PROCESS:
|
||||
|
||||
### 1. Initialize Plan Review
|
||||
|
||||
"**Workflow Plan Review**
|
||||
|
||||
We've gathered all requirements and configured tools for your workflow. Let's review the complete plan to ensure it meets your needs before we start designing the workflow structure."
|
||||
|
||||
### 2. Present Complete Plan Summary
|
||||
|
||||
Load and present from {workflowPlanFile}:
|
||||
|
||||
"**Complete Workflow Plan: {new_workflow_name}**
|
||||
|
||||
**1. Project Overview:**
|
||||
|
||||
- [Present workflow purpose, user type, module from plan]
|
||||
|
||||
**2. Workflow Requirements:**
|
||||
|
||||
- [Present all gathered requirements]
|
||||
|
||||
**3. Tools Configuration:**
|
||||
|
||||
- [Present selected tools and integration points]
|
||||
|
||||
**4. Technical Specifications:**
|
||||
|
||||
- [Present technical constraints and requirements]
|
||||
|
||||
**5. Success Criteria:**
|
||||
|
||||
- [Present success metrics from requirements]"
|
||||
|
||||
### 3. Detailed Review by Category
|
||||
|
||||
"**Detailed Review:**
|
||||
|
||||
**A. Workflow Scope and Purpose**
|
||||
|
||||
- Is the workflow goal clearly defined?
|
||||
- Are the boundaries appropriate?
|
||||
- Any missing requirements?
|
||||
|
||||
**B. User Interaction Design**
|
||||
|
||||
- Does the interaction style match your needs?
|
||||
- Are collaboration points clear?
|
||||
- Any adjustments needed?
|
||||
|
||||
**C. Tools Integration**
|
||||
|
||||
- Are selected tools appropriate for your workflow?
|
||||
- Are integration points logical?
|
||||
- Any additional tools needed?
|
||||
|
||||
**D. Technical Feasibility**
|
||||
|
||||
- Are all requirements achievable?
|
||||
- Any technical constraints missing?
|
||||
- Installation requirements acceptable?"
|
||||
|
||||
### 4. Collect Feedback and Refinements
|
||||
|
||||
"**Review Feedback:**
|
||||
|
||||
Please review each section and provide feedback:
|
||||
|
||||
1. What looks good and should stay as-is?
|
||||
2. What needs modification or refinement?
|
||||
3. What's missing that should be added?
|
||||
4. Anything unclear or confusing?"
|
||||
|
||||
For each feedback item:
|
||||
|
||||
- Document the requested change
|
||||
- Discuss implications on workflow design
|
||||
- Confirm the refinement with user
|
||||
|
||||
### 5. Update Plan with Refinements
|
||||
|
||||
Update {workflowPlanFile} with any approved changes:
|
||||
|
||||
- Modify requirements section as needed
|
||||
- Update tools configuration if changed
|
||||
- Add any missing specifications
|
||||
- Ensure all changes are clearly documented
|
||||
|
||||
### 6. Output Document Check
|
||||
|
||||
"**Output Document Check:**
|
||||
|
||||
Before we proceed to design, does your workflow produce any output documents or files?
|
||||
|
||||
Based on your requirements:
|
||||
|
||||
- [Analyze if workflow produces documents/files]
|
||||
- Consider: Does it create reports, forms, stories, or any persistent output?"
|
||||
|
||||
**If NO:**
|
||||
"Great! Your workflow focuses on actions/interactions without document output. We'll proceed directly to designing the workflow steps."
|
||||
|
||||
**If YES:**
|
||||
"Perfect! Let's design your output format to ensure your workflow produces exactly what you need."
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Design
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Check if workflow produces documents:
|
||||
- If YES: Update frontmatter, then load nextStepFormDesign
|
||||
- If NO: Update frontmatter, then load nextStepDesign
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected AND the user has explicitly approved the plan and the plan document is updated as needed, then you load either {nextStepFormDesign} or {nextStepDesign}
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Complete plan presented clearly from {workflowPlanFile}
|
||||
- User feedback collected and documented
|
||||
- All refinements incorporated
|
||||
- User explicitly approves the plan
|
||||
- Plan ready for design phase
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not loading plan from {workflowPlanFile}
|
||||
- Skipping review categories
|
||||
- Proceeding without user approval
|
||||
- Not documenting refinements
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,290 @@
|
|||
---
|
||||
name: 'step-05-output-format-design'
|
||||
description: 'Design the output format for workflows that produce documents or files'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-05-output-format-design.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-06-design.md'
|
||||
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Output Format Design
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To design and document the output format for workflows that produce documents or files, determining whether they need strict templates or flexible formatting.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and output format specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in document design and template creation
|
||||
- ✅ User brings their specific output requirements and preferences
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on output format design
|
||||
- 🚫 FORBIDDEN to design workflow steps in this step
|
||||
- 💬 Help user understand the format spectrum
|
||||
- 🚫 DO NOT proceed without clear format requirements
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Guide user through format spectrum with examples
|
||||
- 💾 Document format decisions in workflow plan
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C'
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Approved plan from step 4 is available
|
||||
- Focus ONLY on output document formatting
|
||||
- Skip this step if workflow produces no documents
|
||||
- This step only runs when documents need structure
|
||||
|
||||
## OUTPUT FORMAT DESIGN PROCESS:
|
||||
|
||||
### 1. Initialize Output Format Discussion
|
||||
|
||||
"**Designing Your Output Format**
|
||||
|
||||
Based on your approved plan, your workflow will produce output documents. Let's design how these outputs should be formatted."
|
||||
|
||||
### 2. Present the Format Spectrum
|
||||
|
||||
"**Output Format Spectrum - Where does your workflow fit?**
|
||||
|
||||
**Strictly Structured Examples:**
|
||||
|
||||
- Government forms - exact fields, precise positions
|
||||
- Legal documents - must follow specific templates
|
||||
- Technical specifications - required sections, specific formats
|
||||
- Compliance reports - mandatory fields, validation rules
|
||||
|
||||
**Structured Examples:**
|
||||
|
||||
- Project reports - required sections, flexible content
|
||||
- Business proposals - consistent format, customizable sections
|
||||
- Technical documentation - standard structure, adaptable content
|
||||
- Research papers - IMRAD format, discipline-specific variations
|
||||
|
||||
**Semi-structured Examples:**
|
||||
|
||||
- Character sheets (D&D) - core stats + flexible background
|
||||
- Lesson plans - required components, flexible delivery
|
||||
- Recipes - ingredients/method format, flexible descriptions
|
||||
- Meeting minutes - agenda/attendees/actions, flexible details
|
||||
|
||||
**Free-form Examples:**
|
||||
|
||||
- Creative stories - narrative flow, minimal structure
|
||||
- Blog posts - title/body, organic organization
|
||||
- Personal journals - date/entry, free expression
|
||||
- Brainstorming outputs - ideas, flexible organization"
|
||||
|
||||
### 3. Determine Format Type
|
||||
|
||||
"**Which format type best fits your workflow?**
|
||||
|
||||
1. **Strict Template** - Must follow exact format with specific fields
|
||||
2. **Structured** - Required sections but flexible within each
|
||||
3. **Semi-structured** - Core sections plus optional additions
|
||||
4. **Free-form** - Content-driven with minimal structure
|
||||
|
||||
Please choose 1-4:"
|
||||
|
||||
### 4. Deep Dive Based on Choice
|
||||
|
||||
#### IF Strict Template (Choice 1):
|
||||
|
||||
"**Strict Template Design**
|
||||
|
||||
You need exact formatting. Let's define your requirements:
|
||||
|
||||
**Template Source Options:**
|
||||
A. Upload existing template/image to follow
|
||||
B. Create new template from scratch
|
||||
C. Use standard form (e.g., government, industry)
|
||||
D. AI proposes template based on your needs
|
||||
|
||||
**Template Requirements:**
|
||||
|
||||
- Exact field names and positions
|
||||
- Required vs optional fields
|
||||
- Validation rules
|
||||
- File format (PDF, DOCX, etc.)
|
||||
- Any legal/compliance considerations"
|
||||
|
||||
#### IF Structured (Choice 2):
|
||||
|
||||
"**Structured Document Design**
|
||||
|
||||
You need consistent sections with flexibility:
|
||||
|
||||
**Section Definition:**
|
||||
|
||||
- What sections are required?
|
||||
- Any optional sections?
|
||||
- Section ordering rules?
|
||||
- Cross-document consistency needs?
|
||||
|
||||
**Format Guidelines:**
|
||||
|
||||
- Any formatting standards (APA, MLA, corporate)?
|
||||
- Section header styles?
|
||||
- Content organization principles?"
|
||||
|
||||
#### IF Semi-structured (Choice 3):
|
||||
|
||||
"**Semi-structured Design**
|
||||
|
||||
Core sections with flexibility:
|
||||
|
||||
**Core Components:**
|
||||
|
||||
- What information must always appear?
|
||||
- Which parts can vary?
|
||||
- Any organizational preferences?
|
||||
|
||||
**Polishing Options:**
|
||||
|
||||
- Would you like automatic TOC generation?
|
||||
- Summary section at the end?
|
||||
- Consistent formatting options?"
|
||||
|
||||
#### IF Free-form (Choice 4):
|
||||
|
||||
"**Free-form Content Design**
|
||||
|
||||
Focus on content with minimal structure:
|
||||
|
||||
**Organization Needs:**
|
||||
|
||||
- Basic headers for readability?
|
||||
- Date/title information?
|
||||
- Any categorization needs?
|
||||
|
||||
**Final Polish Options:**
|
||||
|
||||
- Auto-generated summary?
|
||||
- TOC based on content?
|
||||
- Formatting for readability?"
|
||||
|
||||
### 5. Template Creation (if applicable)
|
||||
|
||||
For Strict/Structured workflows:
|
||||
|
||||
"**Template Creation Approach:**
|
||||
|
||||
A. **Design Together** - We'll create the template step by step
|
||||
B. **AI Proposes** - I'll suggest a structure based on your needs
|
||||
C. **Import Existing** - Use/upload your existing template
|
||||
|
||||
Which approach would you prefer?"
|
||||
|
||||
If A or B:
|
||||
|
||||
- Design/create template sections
|
||||
- Define placeholders
|
||||
- Specify field types and validation
|
||||
- Document template structure in plan
|
||||
|
||||
If C:
|
||||
|
||||
- Request file upload or detailed description
|
||||
- Analyze template structure
|
||||
- Document requirements
|
||||
|
||||
### 6. Document Format Decisions
|
||||
|
||||
Append to {workflowPlanFile}:
|
||||
|
||||
```markdown
|
||||
## Output Format Design
|
||||
|
||||
**Format Type**: [Strict/Structured/Semi-structured/Free-form]
|
||||
|
||||
**Output Requirements**:
|
||||
|
||||
- Document type: [report/form/story/etc]
|
||||
- File format: [PDF/MD/DOCX/etc]
|
||||
- Frequency: [single/batch/continuous]
|
||||
|
||||
**Structure Specifications**:
|
||||
[Detailed structure based on format type]
|
||||
|
||||
**Template Information**:
|
||||
|
||||
- Template source: [created/imported/standard]
|
||||
- Template file: [path if applicable]
|
||||
- Placeholders: [list if applicable]
|
||||
|
||||
**Special Considerations**:
|
||||
|
||||
- Legal/compliance requirements
|
||||
- Validation needs
|
||||
- Accessibility requirements
|
||||
```
|
||||
|
||||
### 7. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save output format design to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and output format is documented will you load {nextStepFile} to begin workflow step design.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- User understands format spectrum
|
||||
- Format type clearly identified
|
||||
- Template requirements documented (if applicable)
|
||||
- Output format saved in plan
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not showing format examples
|
||||
- Skipping format requirements
|
||||
- Not documenting decisions in plan
|
||||
- Assuming format without asking
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -2,19 +2,22 @@
|
|||
name: 'step-06-design'
|
||||
description: 'Design the workflow structure and step sequence based on gathered requirements, tools configuration, and output format'
|
||||
|
||||
nextStepFile: './step-07-foundation.md'
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06-design.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-07-build.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
stepTemplate: '../templates/step-template.md'
|
||||
stepTypePatterns: '../data/step-type-patterns.md'
|
||||
menuHandlingStandards: '../data/menu-handling-standards.md'
|
||||
frontmatterStandards: '../data/frontmatter-standards.md'
|
||||
outputFormatStandards: '../data/output-format-standards.md'
|
||||
inputDiscoveryStandards: '../data/input-discovery-standards.md'
|
||||
workflowChainingStandards: '../data/workflow-chaining-standards.md'
|
||||
trimodalWorkflowStructure: '../data/trimodal-workflow-structure.md'
|
||||
# Template References
|
||||
# No template needed - will append design details directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 6: Workflow Structure Design
|
||||
|
|
@ -52,7 +55,7 @@ To collaboratively design the workflow structure, step sequence, and interaction
|
|||
|
||||
- 🎯 Guide collaborative design process
|
||||
- 💾 After completing design, append to {workflowPlanFile}
|
||||
- 📖 Update frontmatter stepsCompleted to add this step when completed.
|
||||
- 📖 Update plan frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and design is saved
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
|
@ -66,37 +69,33 @@ To collaboratively design the workflow structure, step sequence, and interaction
|
|||
|
||||
## DESIGN REFERENCE MATERIALS:
|
||||
|
||||
When designing, you may load these data standards as needed:
|
||||
When designing, you may load these documents as needed:
|
||||
|
||||
- {stepTemplate} - Step file structure template
|
||||
- {stepTypePatterns} - Templates for different step types (init, middle, branch, validation, final)
|
||||
- {menuHandlingStandards} - Menu patterns and handler rules
|
||||
- {frontmatterStandards} - Variable definitions and path rules
|
||||
- {outputFormatStandards} - Output document patterns
|
||||
- {inputDiscoveryStandards} - How to discover documents from prior workflows
|
||||
- {workflowChainingStandards} - How workflows connect in sequences
|
||||
- {trimodalWorkflowStructure} - Tri-modal workflow patterns (if applicable)
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md` - Step file structure
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/step-01-init-continuable-template.md` - Continuable init step template
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/step-1b-template.md` - Continuation step template
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md` - Workflow configuration
|
||||
- `{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/workflow.md` - Complete example
|
||||
|
||||
Example workflow:
|
||||
- `{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/workflow.md`
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
## WORKFLOW DESIGN PROCESS:
|
||||
|
||||
### 1. Step Structure Design
|
||||
|
||||
Load {stepTypePatterns} for available step type templates:
|
||||
Let's reference our step creation documentation for best practices:
|
||||
|
||||
This shows the standard structure for all step types:
|
||||
- Init Step (Continuable)
|
||||
- Continuation Step (01b)
|
||||
- Middle Step (Standard/Simple)
|
||||
- Branch Step
|
||||
- Validation Sequence Step
|
||||
- Init Step (With Input Discovery)
|
||||
- Final Polish Step
|
||||
- Final Step
|
||||
Load and reference step-file architecture guide:
|
||||
|
||||
```
|
||||
Read: {project-root}/_bmad/bmb/docs/workflows/templates/step-template.md
|
||||
```
|
||||
|
||||
This shows the standard structure for step files. Also reference:
|
||||
|
||||
```
|
||||
Read: {project-root}/_bmad/bmb/docs/workflows/templates/step-1b-template.md
|
||||
```
|
||||
|
||||
This shows the continuation step pattern for workflows that might take multiple sessions.
|
||||
|
||||
Based on the approved plan, collaboratively design the info to answer the following for the build plan:
|
||||
|
||||
|
|
@ -127,11 +126,10 @@ If **YES** to any of these, we should include continuation support using step-01
|
|||
|
||||
### 2. Interaction Pattern Design
|
||||
|
||||
Load {menuHandlingStandards} for menu pattern options:
|
||||
|
||||
Design how users will interact with the workflow:
|
||||
|
||||
- Where should users provide input vs where the AI works autonomously?
|
||||
- What menu pattern does each step need? (Standard A/P/C, Auto-proceed, Custom, Conditional)
|
||||
- What type of menu options are needed at each step?
|
||||
- Should there be Advanced Elicitation or Party Mode options?
|
||||
- How will users know their progress?
|
||||
- What confirmation points are needed?
|
||||
|
|
@ -184,20 +182,6 @@ Identify unique requirements:
|
|||
- Should it integrate with other workflows?
|
||||
- Does it need to handle multiple scenarios?
|
||||
|
||||
**Input Discovery:**
|
||||
|
||||
If this workflow depends on documents from prior workflows, load {inputDiscoveryStandards}:
|
||||
- What prior workflow outputs does this workflow need?
|
||||
- Are these required or optional inputs?
|
||||
- How will the workflow discover these documents?
|
||||
|
||||
**Workflow Chaining:**
|
||||
|
||||
If this workflow is part of a sequence, load {workflowChainingStandards}:
|
||||
- What workflow comes before this one?
|
||||
- What workflow comes after this one?
|
||||
- What outputs does this workflow produce for the next?
|
||||
|
||||
### 8. Design Review and Refinement
|
||||
|
||||
Present the design for review:
|
||||
|
|
@ -0,0 +1,323 @@
|
|||
---
|
||||
name: 'step-07-build'
|
||||
description: 'Generate all workflow files based on the approved plan'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-07-build.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-08-review.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Template References
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
stepInitContinuableTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-01-init-continuable-template.md'
|
||||
step1bTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-1b-template.md'
|
||||
# No content templates needed - will create content as needed during build
|
||||
# No build summary template needed - will append summary directly to workflow plan
|
||||
---
|
||||
|
||||
# Step 7: Workflow File Generation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To generate all the workflow files (workflow.md, step files, templates, and supporting files) based on the approved plan from the previous design step.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and systems designer
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring implementation expertise and best practices
|
||||
- ✅ User brings their specific requirements and design approvals
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on generating files based on approved design
|
||||
- 🚫 FORBIDDEN to modify the design without user consent
|
||||
- 💬 Generate files collaboratively, getting approval at each stage
|
||||
- 🚪 CREATE files in the correct target location
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Generate files systematically from design
|
||||
- 💾 Document all generated files and their locations
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and build is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Approved plan from step 6 guides implementation
|
||||
- Generate files in target workflow location
|
||||
- Load templates and documentation as needed during build
|
||||
- Follow step-file architecture principles
|
||||
|
||||
## BUILD REFERENCE MATERIALS:
|
||||
|
||||
- When building each step file, you must follow template `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md`
|
||||
- When building continuable step-01-init.md files, use template `{project-root}/_bmad/bmb/docs/workflows/templates/step-01-init-continuable-template.md`
|
||||
- When building continuation steps, use template `{project-root}/_bmad/bmb/docs/workflows/templates/step-1b-template.md`
|
||||
- When building the main workflow.md file, you must follow template `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md`
|
||||
- Example step files from {project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/workflow.md for patterns - this is an idealized workflow so all files can give good insight into format and structure to be followed
|
||||
|
||||
## FILE GENERATION SEQUENCE:
|
||||
|
||||
### 1. Confirm Build Readiness
|
||||
|
||||
Based on the approved plan, confirm:
|
||||
"I have your approved plan and I'm ready to generate the workflow files. The plan specifies creating:
|
||||
|
||||
- Main workflow.md file
|
||||
- [Number] step files
|
||||
- [Number] templates
|
||||
- Supporting files
|
||||
|
||||
All in: {targetWorkflowPath}
|
||||
|
||||
Ready to proceed?"
|
||||
|
||||
### 2. Create Directory Structure
|
||||
|
||||
Create the workflow folder structure in the target location:
|
||||
|
||||
```
|
||||
{bmb_creations_output_folder}/workflows/{workflow_name}/
|
||||
├── workflow.md
|
||||
├── steps/
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-01b-continue.md (if continuation support needed)
|
||||
│ ├── step-02-[name].md
|
||||
│ └── ...
|
||||
├── templates/
|
||||
│ └── [as needed]
|
||||
└── data/
|
||||
└── [as needed]
|
||||
```
|
||||
|
||||
For bmb module, this will be: `_bmad/custom/src/workflows/{workflow_name}/`
|
||||
For other modules, check their module.yaml for custom_workflow_location
|
||||
|
||||
### 3. Generate workflow.md
|
||||
|
||||
Load and follow {workflowTemplate}:
|
||||
|
||||
- Create workflow.md using template structure
|
||||
- Insert workflow name and description
|
||||
- Configure all path variables ({project-root}, _bmad, {workflow_path})
|
||||
- Set web_bundle flag to true unless user has indicated otherwise
|
||||
- Define role and goal
|
||||
- Include initialization path to step-01
|
||||
|
||||
### 4. Generate Step Files
|
||||
|
||||
#### 4a. Check for Continuation Support
|
||||
|
||||
**Check the workflow plan for continuation support:**
|
||||
|
||||
- Look for "continuation support: true" or similar flag
|
||||
- Check if step-01b-continue.md was included in the design
|
||||
- If workflow generates output documents, continuation is typically needed
|
||||
|
||||
#### 4b. Generate step-01-init.md (with continuation logic)
|
||||
|
||||
If continuation support is needed:
|
||||
|
||||
- Load and follow {stepInitContinuableTemplate}
|
||||
- This template automatically includes all required continuation detection logic
|
||||
- Customize with workflow-specific information:
|
||||
- Update workflow_path references
|
||||
- Set correct outputFile and templateFile paths
|
||||
- Adjust role and persona to match workflow type
|
||||
- Customize welcome message for workflow context
|
||||
- Configure input document discovery patterns (if any)
|
||||
- Template automatically handles:
|
||||
- continueFile reference in frontmatter
|
||||
- Logic to check for existing output files with stepsCompleted
|
||||
- Routing to step-01b-continue.md for continuation
|
||||
- Fresh workflow initialization
|
||||
|
||||
#### 4c. Generate step-01b-continue.md (if needed)
|
||||
|
||||
**If continuation support is required:**
|
||||
|
||||
- Load and follow {step1bTemplate}
|
||||
- Customize with workflow-specific information:
|
||||
- Update workflow_path references
|
||||
- Set correct outputFile path
|
||||
- Adjust role and persona to match workflow type
|
||||
- Customize welcome back message for workflow context
|
||||
- Ensure proper nextStep detection logic based on step numbers
|
||||
|
||||
#### 4d. Generate Remaining Step Files
|
||||
|
||||
For each remaining step in the design:
|
||||
|
||||
- Load and follow {stepTemplate}
|
||||
- Create step file using template structure
|
||||
- Customize with step-specific content
|
||||
- Ensure proper frontmatter with path references
|
||||
- Include appropriate menu handling and universal rules
|
||||
- Follow all mandatory rules and protocols from template
|
||||
- **Critical**: Ensure each step updates `stepsCompleted` array when completing
|
||||
|
||||
### 5. Generate Templates (If Needed)
|
||||
|
||||
For document workflows:
|
||||
|
||||
- Create template.md with proper structure
|
||||
- Include all variables from design
|
||||
- Ensure variable naming consistency
|
||||
|
||||
Remember that the output format design we aligned on chose one of the following - and what it means practically when creating the workflow steps:
|
||||
1. **Strict Template** - Must follow exact format with specific fields
|
||||
1. This is similar to the example where there are multiple template fragements that are specific with all fields to be in the final output.
|
||||
2. generally there will be 1 fragment to a step to complete in the overall template.
|
||||
2. **Structured** - Required sections but flexible within each
|
||||
1. Usually there will just be one template file - and in this mode it lists out all the section headings (generally level 2 sections in the md) with a handlebars style placeholder for each section.
|
||||
2. Step files responsible for a specific section will upon user Continue of that step ensure output is written to the templates proper section
|
||||
3. **Semi-structured** - Core sections plus optional additions
|
||||
1. Similar to the prior 2, but not all sections or content are listed in the template, some steps might offer various paths or options to go to different steps (or variance within a step) that can determine what sections end up in the final document
|
||||
4. **Free-form** - Content-driven with minimal structure
|
||||
1. These are the easiest and most flexible. The single template usually only has the front matter fence with a stepsCompleted array and maybe some other fields, and outside of the front matter just the level 1 doc title
|
||||
2. With free form, any step that could produce content just appends to the end of the document, so its progressively build in the order of ste[s completed.
|
||||
3. Its good to have in this type of workflow a final polish output doc type step that cohesively can update the doc built up in this progressive manner, improving flow, reducing duplication, and ensure all information is aligned and where it belongs.
|
||||
|
||||
### 6. Generate Supporting Files
|
||||
|
||||
Based on design requirements:
|
||||
|
||||
- Create data files (csv)
|
||||
- Generate README.md with usage instructions
|
||||
- Create any configuration files
|
||||
- Add validation checklists if designed
|
||||
|
||||
### 7. Verify File Generation
|
||||
|
||||
After creating all files:
|
||||
|
||||
- Check all file paths are correct
|
||||
- Validate frontmatter syntax
|
||||
- Ensure variable consistency across files
|
||||
- Confirm sequential step numbering
|
||||
- Verify menu handling logic
|
||||
|
||||
### 8. Document Generated Files
|
||||
|
||||
Create a summary of what was generated:
|
||||
|
||||
- List all files created with full paths
|
||||
- Note any customizations from templates
|
||||
- Identify any manual steps needed
|
||||
- Provide next steps for testing
|
||||
|
||||
## QUALITY CHECKS DURING BUILD:
|
||||
|
||||
### Frontmatter Validation
|
||||
|
||||
- All YAML syntax is correct
|
||||
- Required fields are present
|
||||
- Path variables use correct format
|
||||
- No hardcoded paths exist
|
||||
|
||||
### Step File Compliance
|
||||
|
||||
- Each step follows the template structure
|
||||
- All mandatory rules are included
|
||||
- Menu handling is properly implemented
|
||||
- Step numbering is sequential
|
||||
|
||||
### Cross-File Consistency
|
||||
|
||||
- Variable names match across files
|
||||
- Path references are consistent
|
||||
- Dependencies are correctly defined
|
||||
- No orphaned references exist
|
||||
|
||||
## BUILD PRINCIPLES:
|
||||
|
||||
### Follow Design Exactly
|
||||
|
||||
- Implement the design as approved
|
||||
- Don't add or remove steps without consultation
|
||||
- Maintain the interaction patterns designed
|
||||
- Preserve the data flow architecture
|
||||
|
||||
### Maintain Best Practices
|
||||
|
||||
- Keep step files focused and reasonably sized (typically 5-10KB)
|
||||
- Use collaborative dialogue patterns
|
||||
- Include proper error handling
|
||||
- Follow naming conventions
|
||||
|
||||
### Ensure Extensibility
|
||||
|
||||
- Design for future modifications
|
||||
- Include clear documentation
|
||||
- Make code readable and maintainable
|
||||
- Provide examples where helpful
|
||||
|
||||
## CONTENT TO APPEND TO PLAN:
|
||||
|
||||
After generating all files, append to {workflowPlanFile}:
|
||||
|
||||
Create a build summary including:
|
||||
|
||||
- List of all files created with full paths
|
||||
- Any customizations from templates
|
||||
- Manual steps needed
|
||||
- Next steps for testing
|
||||
|
||||
### 9. Present MENU OPTIONS
|
||||
|
||||
Display: **Build Complete - Select an Option:** [C] Continue to Review
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- Build complete - all files generated
|
||||
- Present simple completion status
|
||||
- User selects [C] to continue to review step
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save build summary to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and content is saved to plan and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin workflow review step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All workflow files generated in correct locations
|
||||
- Files follow step-file architecture principles
|
||||
- Plan implemented exactly as approved
|
||||
- Build documented in {workflowPlanFile}
|
||||
- Frontmatter updated with step completion
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating files without user approval
|
||||
- Deviating from approved plan
|
||||
- Creating files with incorrect paths
|
||||
- Not updating plan frontmatter
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,285 @@
|
|||
---
|
||||
name: 'step-08-review'
|
||||
description: 'Review the generated workflow and provide final validation and next steps'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-08-review.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
# No review template needed - will append review summary directly to workflow plan
|
||||
# No completion template needed - will append completion details directly
|
||||
|
||||
# Next step reference
|
||||
nextStepFile: '{workflow_path}/steps/step-09-complete.md'
|
||||
---
|
||||
|
||||
# Step 8: Workflow Review and Completion
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To review the generated workflow for completeness, accuracy, and adherence to best practices, then provide next steps for deployment and usage.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: Always read the complete step file before taking any action
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and systems designer
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring quality assurance expertise and validation knowledge
|
||||
- ✅ User provides final approval and feedback
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on reviewing and validating generated workflow
|
||||
- 🚫 FORBIDDEN to make changes without user approval
|
||||
- 💬 Guide review process collaboratively
|
||||
- 🚪 COMPLETE the workflow creation process
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Conduct thorough review of generated workflow
|
||||
- 💾 Document review findings and completion status
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]` and mark complete
|
||||
- 🚫 This is the final step - no next step to load
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Generated workflow files are available for review
|
||||
- Focus on validation and quality assurance
|
||||
- This step completes the workflow creation process
|
||||
- No file modifications without explicit user approval
|
||||
|
||||
## WORKFLOW REVIEW PROCESS:
|
||||
|
||||
### 1. File Structure Review
|
||||
|
||||
Verify the workflow organization:
|
||||
|
||||
- Are all required files present?
|
||||
- Is the directory structure correct?
|
||||
- Are file names following conventions?
|
||||
- Are paths properly configured?
|
||||
|
||||
### 2. Configuration Validation
|
||||
|
||||
Check workflow.yaml:
|
||||
|
||||
- Is all metadata correctly filled?
|
||||
- Are path variables properly formatted?
|
||||
- Is the standalone property set correctly?
|
||||
- Are all dependencies declared?
|
||||
|
||||
### 3. Step File Compliance
|
||||
|
||||
Review each step file:
|
||||
|
||||
- Does each step follow the template structure?
|
||||
- Are all mandatory rules included?
|
||||
- Is menu handling properly implemented?
|
||||
- Are frontmatter variables correct?
|
||||
- Are steps properly numbered?
|
||||
|
||||
### 4. Cross-File Consistency
|
||||
|
||||
Verify integration between files:
|
||||
|
||||
- Do variable names match across all files?
|
||||
- Are path references consistent?
|
||||
- Is the step sequence logical?
|
||||
- Are there any broken references?
|
||||
|
||||
### 5. Requirements Verification
|
||||
|
||||
Confirm original requirements are met:
|
||||
|
||||
- Does the workflow address the original problem?
|
||||
- Are all user types supported?
|
||||
- Are inputs and outputs as specified?
|
||||
- Is the interaction style as designed?
|
||||
|
||||
### 6. Best Practices Adherence
|
||||
|
||||
Check quality standards:
|
||||
|
||||
- Are step files focused and reasonably sized (5-10KB typical)?
|
||||
- Is collaborative dialogue implemented?
|
||||
- Is error handling included?
|
||||
- Are naming conventions followed?
|
||||
|
||||
### 7. Test Scenario Planning
|
||||
|
||||
Prepare for testing:
|
||||
|
||||
- What test data would be useful?
|
||||
- What scenarios should be tested?
|
||||
- How can the workflow be invoked?
|
||||
- What would indicate successful execution?
|
||||
|
||||
### 8. Deployment Preparation
|
||||
|
||||
Provide next steps:
|
||||
|
||||
- Installation requirements
|
||||
- Invocation commands
|
||||
- Testing procedures
|
||||
- Documentation needs
|
||||
|
||||
## REVIEW FINDINGS DOCUMENTATION:
|
||||
|
||||
### Issues Found
|
||||
|
||||
Document any issues discovered:
|
||||
|
||||
- **Critical Issues**: Must fix before use
|
||||
- **Warnings**: Should fix for better experience
|
||||
- **Suggestions**: Nice to have improvements
|
||||
|
||||
### Validation Results
|
||||
|
||||
Record validation outcomes:
|
||||
|
||||
- Configuration validation: PASSED/FAILED
|
||||
- Step compliance: PASSED/FAILED
|
||||
- Cross-file consistency: PASSED/FAILED
|
||||
- Requirements verification: PASSED/FAILED
|
||||
|
||||
### Recommendations
|
||||
|
||||
Provide specific recommendations:
|
||||
|
||||
- Immediate actions needed
|
||||
- Future improvements
|
||||
- Training needs
|
||||
- Maintenance considerations
|
||||
|
||||
## COMPLETION CHECKLIST:
|
||||
|
||||
### Final Validations
|
||||
|
||||
- [ ] All files generated successfully
|
||||
- [ ] No syntax errors in YAML
|
||||
- [ ] All paths are correct
|
||||
- [ ] Variables are consistent
|
||||
- [ ] Design requirements met
|
||||
- [ ] Best practices followed
|
||||
|
||||
### User Acceptance
|
||||
|
||||
- [ ] User has reviewed generated workflow
|
||||
- [ ] User approves of the implementation
|
||||
- [ ] User understands next steps
|
||||
- [ ] User satisfied with the result
|
||||
|
||||
### Documentation
|
||||
|
||||
- [ ] Build summary complete
|
||||
- [ ] Review findings documented
|
||||
- [ ] Next steps provided
|
||||
- [ ] Contact information for support
|
||||
|
||||
## CONTENT TO APPEND TO PLAN:
|
||||
|
||||
After completing review, append to {workflowPlanFile}:
|
||||
|
||||
Append review findings to {workflowPlanFile}:
|
||||
|
||||
Create a review summary including:
|
||||
|
||||
- Completeness check results
|
||||
- Accuracy validation
|
||||
- Compliance with best practices
|
||||
- Any issues found
|
||||
|
||||
Then append completion details:
|
||||
|
||||
- Final approval status
|
||||
- Deployment recommendations
|
||||
- Usage guidance
|
||||
|
||||
### 10. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [C] Continue to Completion
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF C: Save review to {workflowPlanFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#10-present-menu-options)
|
||||
|
||||
## COMPLIANCE CHECK INSTRUCTIONS
|
||||
|
||||
When user selects [C], provide these instructions:
|
||||
|
||||
**🎯 Workflow Creation Complete! Your new workflow is ready at:**
|
||||
`{target_workflow_path}`
|
||||
|
||||
**⚠️ IMPORTANT - Run Compliance Check in New Context:**
|
||||
To validate your workflow meets BMAD standards:
|
||||
|
||||
1. **Start a new Claude conversation** (fresh context)
|
||||
2. **Use this command:** `/bmad:bmm:workflows:workflow-compliance-check`
|
||||
3. **Provide the path:** `{target_workflow_path}/workflow.md`
|
||||
4. **Follow the validation process** to identify and fix any violations
|
||||
|
||||
**Why New Context?**
|
||||
|
||||
- Compliance checking requires fresh analysis without workflow creation context
|
||||
- Ensures objective validation against template standards
|
||||
- Provides detailed violation reporting with specific fix recommendations
|
||||
|
||||
**Your workflow will be checked for:**
|
||||
|
||||
- Template compliance and structure
|
||||
- Step-by-step validation standards
|
||||
- File optimization and formatting
|
||||
- Meta-workflow best practices
|
||||
|
||||
Ready to validate when you are! [Start new context and run compliance check]
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Generated workflow thoroughly reviewed
|
||||
- All validations performed
|
||||
- Issues documented with solutions
|
||||
- User approves final workflow
|
||||
- Complete documentation provided
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping review steps
|
||||
- Not documenting findings
|
||||
- Ending without user approval
|
||||
- Not providing next steps
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,188 @@
|
|||
---
|
||||
name: 'step-09-complete'
|
||||
description: 'Final completion and wrap-up of workflow creation process'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/create-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-09-complete.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
# Output files for workflow creation process
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{new_workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/workflow-plan-{new_workflow_name}.md'
|
||||
completionFile: '{targetWorkflowPath}/completion-summary-{new_workflow_name}.md'
|
||||
---
|
||||
|
||||
# Step 9: Workflow Creation Complete
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To complete the workflow creation process with a final summary, confirmation, and next steps for using the new workflow.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow architect and systems designer
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in workflow deployment and usage guidance
|
||||
- ✅ User brings their specific workflow needs
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on completion and next steps
|
||||
- 🚫 FORBIDDEN to modify the generated workflow
|
||||
- 💬 Provide clear guidance on how to use the workflow
|
||||
- 🚫 This is the final step - no next step to load
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Present completion summary
|
||||
- 💾 Create final completion documentation
|
||||
- 📖 Update plan frontmatter with completion status
|
||||
- 🚫 This is the final step
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All previous steps are complete
|
||||
- Workflow has been generated and reviewed
|
||||
- Focus ONLY on completion and next steps
|
||||
- This step concludes the create-workflow process
|
||||
|
||||
## COMPLETION PROCESS:
|
||||
|
||||
### 1. Initialize Completion
|
||||
|
||||
"**Workflow Creation Complete!**
|
||||
|
||||
Congratulations! We've successfully created your new workflow. Let's finalize everything and ensure you have everything you need to start using it."
|
||||
|
||||
### 2. Final Summary
|
||||
|
||||
Present a complete summary of what was created:
|
||||
|
||||
**Workflow Created:** {new_workflow_name}
|
||||
**Location:** {targetWorkflowPath}
|
||||
**Files Generated:** [list from build step]
|
||||
|
||||
### 3. Create Completion Summary
|
||||
|
||||
Create {completionFile} with:
|
||||
|
||||
```markdown
|
||||
---
|
||||
workflowName: { new_workflow_name }
|
||||
creationDate: [current date]
|
||||
module: [module from plan]
|
||||
status: COMPLETE
|
||||
stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]
|
||||
---
|
||||
|
||||
# Workflow Creation Summary
|
||||
|
||||
## Workflow Information
|
||||
|
||||
- **Name:** {new_workflow_name}
|
||||
- **Module:** [module]
|
||||
- **Created:** [date]
|
||||
- **Location:** {targetWorkflowPath}
|
||||
|
||||
## Generated Files
|
||||
|
||||
[List all files created]
|
||||
|
||||
## Quick Start Guide
|
||||
|
||||
[How to run the new workflow]
|
||||
|
||||
## Next Steps
|
||||
|
||||
[Post-creation recommendations]
|
||||
```
|
||||
|
||||
### 4. Usage Guidance
|
||||
|
||||
Provide clear instructions on how to use the new workflow:
|
||||
|
||||
**How to Use Your New Workflow:**
|
||||
|
||||
1. **Running the Workflow:**
|
||||
- [Instructions based on workflow type]
|
||||
- [Initial setup if needed]
|
||||
|
||||
2. **Common Use Cases:**
|
||||
- [Typical scenarios for using the workflow]
|
||||
- [Expected inputs and outputs]
|
||||
|
||||
3. **Tips for Success:**
|
||||
- [Best practices for this specific workflow]
|
||||
- [Common pitfalls to avoid]
|
||||
|
||||
### 5. Post-Creation Recommendations
|
||||
|
||||
"**Next Steps:**
|
||||
|
||||
1. **Test the Workflow:** Run it with sample data to ensure it works as expected
|
||||
2. **Customize if Needed:** You can modify the workflow based on your specific needs
|
||||
3. **Share with Team:** If others will use this workflow, provide them with the location and instructions
|
||||
4. **Monitor Usage:** Keep track of how well the workflow meets your needs"
|
||||
|
||||
### 6. Final Confirmation
|
||||
|
||||
"**Is there anything else you need help with regarding your new workflow?**
|
||||
|
||||
- I can help you test it
|
||||
- We can make adjustments if needed
|
||||
- I can help you create documentation for users
|
||||
- Or any other support you need"
|
||||
|
||||
### 7. Update Final Status
|
||||
|
||||
Update {workflowPlanFile} frontmatter:
|
||||
|
||||
- Set status to COMPLETE
|
||||
- Set completion date
|
||||
- Add stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8, 9]
|
||||
|
||||
## MENU OPTIONS
|
||||
|
||||
Display: **Workflow Creation Complete!** [T] Test Workflow [M] Make Adjustments [D] Get Help
|
||||
|
||||
### Menu Handling Logic:
|
||||
|
||||
- IF T: Offer to run the newly created workflow with sample data
|
||||
- IF M: Offer to make specific adjustments to the workflow
|
||||
- IF D: Provide additional help and resources
|
||||
- IF Any other: Respond to user needs
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final step. When the user is satisfied, the workflow creation process is complete.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Workflow fully created and reviewed
|
||||
- Completion summary generated
|
||||
- User understands how to use the workflow
|
||||
- All documentation is in place
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not providing clear usage instructions
|
||||
- Not creating completion summary
|
||||
- Leaving user without next steps
|
||||
|
||||
**Master Rule:** Ensure the user has everything needed to successfully use their new workflow.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: create-workflow
|
||||
description: Create structured standalone workflows using markdown-based step architecture (tri-modal: create, validate, edit)
|
||||
description: Create structured standalone workflows using markdown-based step architecture
|
||||
web_bundle: true
|
||||
---
|
||||
|
||||
|
|
@ -10,8 +10,6 @@ web_bundle: true
|
|||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are also a workflow architect and systems designer collaborating with a workflow creator. This is a partnership, not a client-vendor relationship. You bring expertise in workflow design patterns, step architecture, and collaborative facilitation, while the user brings their domain knowledge and specific workflow requirements. Work together as equals.
|
||||
|
||||
**Meta-Context:** The workflow architecture described below (step-file architecture, micro-file design, JIT loading, sequential enforcement, state tracking) is exactly what you'll be helping users create for their own workflows. You're demonstrating the pattern while building it with them.
|
||||
|
||||
---
|
||||
|
||||
## WORKFLOW ARCHITECTURE
|
||||
|
|
@ -25,7 +23,6 @@ This uses **step-file architecture** for disciplined execution:
|
|||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
||||
- **Tri-Modal Structure**: Separate step folders for Create (steps-c/), Validate (steps-v/), and Edit (steps-e/) modes
|
||||
|
||||
### Step Processing Rules
|
||||
|
||||
|
|
@ -56,48 +53,7 @@ This uses **step-file architecture** for disciplined execution:
|
|||
Load and read full config from {project-root}/_bmad/bmb/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`, `bmb_creations_output_folder`
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### 2. Mode Determination
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
**Check if mode was specified in the command invocation:**
|
||||
|
||||
- If user invoked with "create workflow" or "new workflow" or "build workflow" → Set mode to **create**
|
||||
- If user invoked with "validate workflow" or "review workflow" or "-v" or "--validate" → Set mode to **validate**
|
||||
- If user invoked with "edit workflow" or "modify workflow" or "-e" or "--edit" → Set mode to **edit**
|
||||
|
||||
**If mode is still unclear, ask user:**
|
||||
|
||||
"Welcome to the BMAD Workflow Creator! What would you like to do?
|
||||
|
||||
**[C]reate** - Build a new workflow from scratch
|
||||
**[V]alidate** - Review an existing workflow and generate validation report
|
||||
**[E]dit** - Modify an existing workflow
|
||||
|
||||
Please select: [C]reate / [V]alidate / [E]dit"
|
||||
|
||||
### 3. Route to First Step
|
||||
|
||||
**IF mode == create:**
|
||||
|
||||
"**Creating a new workflow. How would you like to start?**
|
||||
|
||||
**[F]rom scratch** - Start with a blank slate - I'll help you discover your idea
|
||||
**[C]onvert existing** - Convert an existing workflow to BMAD compliant format
|
||||
|
||||
Please select: [F]rom scratch / [C]onvert existing"
|
||||
|
||||
#### Create Mode Routing:
|
||||
|
||||
- **IF F:** Load, read completely, then execute `steps-c/step-01-discovery.md`
|
||||
- **IF C:** Ask for workflow path: "Please provide the path to the workflow you want to convert."
|
||||
Then load, read completely, then execute `steps-c/step-00-conversion.md`
|
||||
- **IF Any other:** help user respond, then redisplay create mode menu
|
||||
|
||||
**IF mode == validate:**
|
||||
Prompt for workflow path: "Which workflow would you like to validate? Please provide the path to the workflow.md file."
|
||||
Then load, read completely, and execute `steps-v/step-01-validate.md`
|
||||
|
||||
**IF mode == edit:**
|
||||
Prompt for workflow path: "Which workflow would you like to edit? Please provide the path to the workflow.md file."
|
||||
Then load, read completely, and execute `steps-e/step-e-01-assess-workflow.md`
|
||||
Load, read the full file and then execute `{workflow_path}/steps/step-01-init.md` to begin the workflow.
|
||||
|
|
@ -0,0 +1,217 @@
|
|||
---
|
||||
name: 'step-01-analyze'
|
||||
description: 'Load and deeply understand the target workflow'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01-analyze.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-discover.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
|
||||
# Template References
|
||||
analysisTemplate: '{workflow_path}/templates/workflow-analysis.md'
|
||||
---
|
||||
|
||||
# Step 1: Workflow Analysis
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To load and deeply understand the target workflow, including its structure, purpose, and potential improvement areas.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow editor and improvement specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring workflow analysis expertise and best practices knowledge
|
||||
- ✅ User brings their workflow context and improvement needs
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on analysis and understanding, not editing yet
|
||||
- 🚫 FORBIDDEN to suggest specific changes in this step
|
||||
- 💬 Ask questions to understand the workflow path
|
||||
- 🚪 DETECT if this is a new format (standalone) or old format workflow
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Analyze workflow thoroughly and systematically
|
||||
- 💾 Document analysis findings in {outputFile}
|
||||
- 📖 Update frontmatter `stepsCompleted: [1]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and analysis is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- User provides the workflow path to analyze
|
||||
- Load all workflow documentation for reference
|
||||
- Focus on understanding current state, not improvements yet
|
||||
- This is about discovery and analysis
|
||||
|
||||
## WORKFLOW ANALYSIS PROCESS:
|
||||
|
||||
### 1. Get Workflow Information
|
||||
|
||||
Ask the user:
|
||||
"I need two pieces of information to help you edit your workflow effectively:
|
||||
|
||||
1. **What is the path to the workflow you want to edit?**
|
||||
- Path to workflow.md file (new format)
|
||||
- Path to workflow.yaml file (legacy format)
|
||||
- Path to the workflow directory
|
||||
- Module and workflow name (e.g., 'bmb/workflows/create-workflow')
|
||||
|
||||
2. **What do you want to edit or improve in this workflow?**
|
||||
- Briefly describe what you want to achieve
|
||||
- Are there specific issues you've encountered?
|
||||
- Any user feedback you've received?
|
||||
- New features you want to add?
|
||||
|
||||
This will help me focus my analysis on what matters most to you."
|
||||
|
||||
### 2. Load Workflow Files
|
||||
|
||||
Load the target workflow completely:
|
||||
|
||||
- workflow.md (or workflow.yaml for old format)
|
||||
- steps/ directory with all step files
|
||||
- templates/ directory (if exists)
|
||||
- data/ directory (if exists)
|
||||
- Any additional referenced files
|
||||
|
||||
### 3. Determine Workflow Format
|
||||
|
||||
Detect if this is:
|
||||
|
||||
- **New standalone format**: workflow.md with steps/ subdirectory
|
||||
- **Legacy XML format**: workflow.yaml with instructions.md
|
||||
- **Mixed format**: Partial migration
|
||||
|
||||
### 4. Focused Analysis
|
||||
|
||||
Analyze the workflow with attention to the user's stated goals:
|
||||
|
||||
#### Initial Goal-Focused Analysis
|
||||
|
||||
Based on what the user wants to edit:
|
||||
|
||||
- If **user experience issues**: Focus on step clarity, menu patterns, instruction style
|
||||
- If **functional problems**: Focus on broken references, missing files, logic errors
|
||||
- If **new features**: Focus on integration points, extensibility, structure
|
||||
- If **compliance issues**: Focus on best practices, standards, validation
|
||||
|
||||
#### Structure Analysis
|
||||
|
||||
- Identify workflow type (document, action, interactive, autonomous, meta)
|
||||
- Count and examine all steps
|
||||
- Map out step flow and dependencies
|
||||
- Check for proper frontmatter in all files
|
||||
|
||||
#### Content Analysis
|
||||
|
||||
- Understand purpose and user journey
|
||||
- Evaluate instruction style (intent-based vs prescriptive)
|
||||
- Review menu patterns and user interaction points
|
||||
- Check variable consistency across files
|
||||
|
||||
#### Compliance Analysis
|
||||
|
||||
Load reference documentation to understand what ideal workflow files sound be when doing the review:
|
||||
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/architecture.md`
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md`
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md`
|
||||
|
||||
Check against best practices:
|
||||
|
||||
- Step file size and structure (each step file 80-250 lines)
|
||||
- Menu handling implementation (every menu item has a handler, and continue will only proceed after writes to output if applicable have completed)
|
||||
- Frontmatter variable usage - no unused variables in the specific step front matter, and all files referenced in the file are done through a variable in the front matter
|
||||
|
||||
### 5. Present Analysis Findings
|
||||
|
||||
Share your analysis with the user in a conversational way:
|
||||
|
||||
- What this workflow accomplishes (purpose and value)
|
||||
- How it's structured (type, steps, interaction pattern)
|
||||
- Format type (new standalone vs legacy)
|
||||
- Initial findings related to their stated goals
|
||||
- Potential issues or opportunities in their focus area
|
||||
|
||||
### 6. Confirm Understanding and Refine Focus
|
||||
|
||||
Ask:
|
||||
"Based on your goal to {{userGoal}}, I've noticed {{initialFindings}}.
|
||||
Does this align with what you were expecting? Are there other areas you'd like me to focus on in my analysis?"
|
||||
|
||||
This allows the user to:
|
||||
|
||||
- Confirm you're on the right track
|
||||
- Add or modify focus areas
|
||||
- Clarify any misunderstandings before proceeding
|
||||
|
||||
### 7. Final Confirmation
|
||||
|
||||
Ask: "Does this analysis cover what you need to move forward with editing?"
|
||||
|
||||
## CONTENT TO APPEND TO DOCUMENT:
|
||||
|
||||
After analysis, append to {outputFile}:
|
||||
|
||||
Load and append the content from {analysisTemplate}
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save analysis to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and analysis is saved to document and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin improvement discovery step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Target workflow loaded completely
|
||||
- Analysis performed systematically
|
||||
- Findings documented clearly
|
||||
- User confirms understanding
|
||||
- Analysis saved to {outputFile}
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping analysis steps
|
||||
- Not loading all workflow files
|
||||
- Making suggestions without understanding
|
||||
- Not saving analysis findings
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,254 @@
|
|||
---
|
||||
name: 'step-02-discover'
|
||||
description: 'Discover improvement goals collaboratively'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-02-discover.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-improve.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
goalsTemplate: '{workflow_path}/templates/improvement-goals.md'
|
||||
---
|
||||
|
||||
# Step 2: Discover Improvement Goals
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To collaboratively discover what the user wants to improve and why, before diving into any edits.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow editor and improvement specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You guide discovery with thoughtful questions
|
||||
- ✅ User brings their context, feedback, and goals
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on understanding improvement goals
|
||||
- 🚫 FORBIDDEN to suggest specific solutions yet
|
||||
- 💬 Ask open-ended questions to understand needs
|
||||
- 🚪 ORGANIZE improvements by priority and impact
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Guide collaborative discovery conversation
|
||||
- 💾 Document goals in {outputFile}
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and goals are documented
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Analysis from step 1 is available and informs discovery
|
||||
- Focus areas identified in step 1 guide deeper exploration
|
||||
- Focus on WHAT to improve and WHY
|
||||
- Don't discuss HOW to improve yet
|
||||
- This is about detailed needs assessment, not solution design
|
||||
|
||||
## DISCOVERY PROCESS:
|
||||
|
||||
### 1. Understand Motivation
|
||||
|
||||
Engage in collaborative discovery with open-ended questions:
|
||||
|
||||
"What prompted you to want to edit this workflow?"
|
||||
|
||||
Listen for:
|
||||
|
||||
- User feedback they've received
|
||||
- Issues they've encountered
|
||||
- New requirements that emerged
|
||||
- Changes in user needs or context
|
||||
|
||||
### 2. Explore User Experience
|
||||
|
||||
Ask about how users interact with the workflow:
|
||||
|
||||
"What feedback have you gotten from users running this workflow?"
|
||||
|
||||
Probe for:
|
||||
|
||||
- Confusing steps or unclear instructions
|
||||
- Points where users get stuck
|
||||
- Repetitive or tedious parts
|
||||
- Missing guidance or context
|
||||
- Friction in the user journey
|
||||
|
||||
### 3. Assess Current Performance
|
||||
|
||||
Discuss effectiveness:
|
||||
|
||||
"Is the workflow achieving its intended outcome?"
|
||||
|
||||
Explore:
|
||||
|
||||
- Are users successful with this workflow?
|
||||
- What are the success/failure rates?
|
||||
- Where do most users drop off?
|
||||
- Are there quality issues with outputs?
|
||||
|
||||
### 4. Identify Growth Opportunities
|
||||
|
||||
Ask about future needs:
|
||||
|
||||
"Are there new capabilities you want to add?"
|
||||
|
||||
Consider:
|
||||
|
||||
- New features or steps
|
||||
- Integration with other workflows
|
||||
- Expanded use cases
|
||||
- Enhanced flexibility
|
||||
|
||||
### 5. Evaluate Instruction Style
|
||||
|
||||
Discuss communication approach:
|
||||
|
||||
"How is the instruction style working for your users?"
|
||||
|
||||
Explore:
|
||||
|
||||
- Is it too rigid or too loose?
|
||||
- Should certain steps be more adaptive?
|
||||
- Do some steps need more specificity?
|
||||
- Does the style match the workflow's purpose?
|
||||
|
||||
### 6. Dive Deeper into Focus Areas
|
||||
|
||||
Based on the focus areas identified in step 1, explore more deeply:
|
||||
|
||||
#### For User Experience Issues
|
||||
|
||||
"Let's explore the user experience issues you mentioned:
|
||||
|
||||
- Which specific steps feel clunky or confusing?
|
||||
- At what points do users get stuck?
|
||||
- What kind of guidance would help them most?"
|
||||
|
||||
#### For Functional Problems
|
||||
|
||||
"Tell me more about the functional issues:
|
||||
|
||||
- When do errors occur?
|
||||
- What specific functionality isn't working?
|
||||
- Are these consistent issues or intermittent?"
|
||||
|
||||
#### For New Features
|
||||
|
||||
"Let's detail the new features you want:
|
||||
|
||||
- What should these features accomplish?
|
||||
- How should users interact with them?
|
||||
- Are there examples of similar workflows to reference?"
|
||||
|
||||
#### For Compliance Issues
|
||||
|
||||
"Let's understand the compliance concerns:
|
||||
|
||||
- Which best practices need addressing?
|
||||
- Are there specific standards to meet?
|
||||
- What validation would be most valuable?"
|
||||
|
||||
### 7. Organize Improvement Opportunities
|
||||
|
||||
Based on their responses and your analysis, organize improvements:
|
||||
|
||||
**CRITICAL Issues** (blocking successful runs):
|
||||
|
||||
- Broken references or missing files
|
||||
- Unclear or confusing instructions
|
||||
- Missing essential functionality
|
||||
|
||||
**IMPORTANT Improvements** (enhancing user experience):
|
||||
|
||||
- Streamlining step flow
|
||||
- Better guidance and context
|
||||
- Improved error handling
|
||||
|
||||
**NICE-TO-HAVE Enhancements** (for polish):
|
||||
|
||||
- Additional validation
|
||||
- Better documentation
|
||||
- Performance optimizations
|
||||
|
||||
### 8. Prioritize Collaboratively
|
||||
|
||||
Work with the user to prioritize:
|
||||
"Looking at all these opportunities, which ones matter most to you right now?"
|
||||
|
||||
Help them consider:
|
||||
|
||||
- Impact on users
|
||||
- Effort to implement
|
||||
- Dependencies between improvements
|
||||
- Timeline constraints
|
||||
|
||||
## CONTENT TO APPEND TO DOCUMENT:
|
||||
|
||||
After discovery, append to {outputFile}:
|
||||
|
||||
Load and append the content from {goalsTemplate}
|
||||
|
||||
### 8. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save goals to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and goals are saved to document and frontmatter is updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin collaborative improvement step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- User improvement goals clearly understood
|
||||
- Issues and opportunities identified
|
||||
- Priorities established collaboratively
|
||||
- Goals documented in {outputFile}
|
||||
- User ready to proceed with improvements
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping discovery dialogue
|
||||
- Making assumptions about user needs
|
||||
- Not documenting discovered goals
|
||||
- Rushing to solutions without understanding
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,218 @@
|
|||
---
|
||||
name: 'step-03-improve'
|
||||
description: 'Facilitate collaborative improvements to the workflow'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-03-improve.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-validate.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
improvementLogTemplate: '{workflow_path}/templates/improvement-log.md'
|
||||
---
|
||||
|
||||
# Step 3: Collaborative Improvement
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To facilitate collaborative improvements to the workflow, working iteratively on each identified issue.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow editor and improvement specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You guide improvements with explanations and options
|
||||
- ✅ User makes decisions and approves changes
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Work on ONE improvement at a time
|
||||
- 🚫 FORBIDDEN to make changes without user approval
|
||||
- 💬 Explain the rationale for each proposed change
|
||||
- 🚪 ITERATE: improve, review, refine
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Facilitate improvements collaboratively and iteratively
|
||||
- 💾 Document all changes in improvement log
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and improvements are complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Analysis and goals from previous steps guide improvements
|
||||
- Load workflow creation documentation as needed
|
||||
- Focus on improvements prioritized in step 2
|
||||
- This is about collaborative implementation, not solo editing
|
||||
|
||||
## IMPROVEMENT PROCESS:
|
||||
|
||||
### 1. Load Reference Materials
|
||||
|
||||
Load documentation as needed for specific improvements:
|
||||
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md`
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md`
|
||||
- `{project-root}/_bmad/bmb/docs/workflows/architecture.md`
|
||||
|
||||
### 2. Address Each Improvement Iteratively
|
||||
|
||||
For each prioritized improvement:
|
||||
|
||||
#### A. Explain Current State
|
||||
|
||||
Show the relevant section:
|
||||
"Here's how this step currently works:
|
||||
[Display current content]
|
||||
|
||||
This can cause {{problem}} because {{reason}}."
|
||||
|
||||
#### B. Propose Improvement
|
||||
|
||||
Suggest specific changes:
|
||||
"Based on best practices, we could:
|
||||
{{proposedSolution}}
|
||||
|
||||
This would help users by {{benefit}}."
|
||||
|
||||
#### C. Collaborate on Approach
|
||||
|
||||
Ask for input:
|
||||
"Does this approach address your need?"
|
||||
"Would you like to modify this suggestion?"
|
||||
"What concerns do you have about this change?"
|
||||
|
||||
#### D. Get Explicit Approval
|
||||
|
||||
"Should I apply this change?"
|
||||
|
||||
#### E. Apply and Show Result
|
||||
|
||||
Make the change and display:
|
||||
"Here's the updated version:
|
||||
[Display new content]
|
||||
|
||||
Does this look right to you?"
|
||||
|
||||
### 3. Common Improvement Patterns
|
||||
|
||||
#### Step Flow Improvements
|
||||
|
||||
- Merge redundant steps
|
||||
- Split complex steps
|
||||
- Reorder for better flow
|
||||
- Add missing transitions
|
||||
|
||||
#### Instruction Style Refinement
|
||||
|
||||
Load step-template.md for reference:
|
||||
|
||||
- Convert prescriptive to intent-based for discovery steps
|
||||
- Add structure to vague instructions
|
||||
- Balance guidance with autonomy
|
||||
|
||||
#### Variable Consistency Fixes
|
||||
|
||||
- Identify all variable references
|
||||
- Ensure consistent naming (snake_case)
|
||||
- Verify variables are defined in workflow.md
|
||||
- Update all occurrences
|
||||
|
||||
#### Menu System Updates
|
||||
|
||||
- Standardize menu patterns
|
||||
- Ensure proper A/P/C options
|
||||
- Fix menu handling logic
|
||||
- Add Advanced Elicitation where useful
|
||||
|
||||
#### Frontmatter Compliance
|
||||
|
||||
- Add required fields to workflow.md
|
||||
- Ensure proper path variables
|
||||
- Include web_bundle configuration if needed
|
||||
- Remove unused fields
|
||||
|
||||
#### Template Updates
|
||||
|
||||
- Align template variables with step outputs
|
||||
- Improve variable naming
|
||||
- Add missing template sections
|
||||
- Test variable substitution
|
||||
|
||||
### 4. Track All Changes
|
||||
|
||||
For each improvement made, document:
|
||||
|
||||
- What was changed
|
||||
- Why it was changed
|
||||
- Files modified
|
||||
- User approval
|
||||
|
||||
## CONTENT TO APPEND TO DOCUMENT:
|
||||
|
||||
After each improvement iteration, append to {outputFile}:
|
||||
|
||||
Load and append content from {improvementLogTemplate}
|
||||
|
||||
### 5. Present MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save improvement log to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and all prioritized improvements are complete and documented, will you then load, read entire file, then execute {nextStepFile} to execute and begin validation step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All prioritized improvements addressed
|
||||
- User approved each change
|
||||
- Changes documented clearly
|
||||
- Workflow follows best practices
|
||||
- Improvement log updated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Making changes without user approval
|
||||
- Not documenting changes
|
||||
- Skipping prioritized improvements
|
||||
- Breaking workflow functionality
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
|
|
@ -0,0 +1,194 @@
|
|||
---
|
||||
name: 'step-04-validate'
|
||||
description: 'Validate improvements and prepare for completion'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-validate.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-05-compliance-check.md'
|
||||
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
validationTemplate: '{workflow_path}/templates/validation-results.md'
|
||||
completionTemplate: '{workflow_path}/templates/completion-summary.md'
|
||||
---
|
||||
|
||||
# Step 4: Validation and Completion
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate all improvements and prepare a completion summary of the workflow editing process.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: Always read the complete step file before taking any action
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow editor and improvement specialist
|
||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You ensure quality and completeness
|
||||
- ✅ User confirms final state
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus ONLY on validation and completion
|
||||
- 🚫 FORBIDDEN to make additional edits at this stage
|
||||
- 💬 Explain validation results clearly
|
||||
- 🚪 PREPARE final summary and next steps
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Validate all changes systematically
|
||||
- 💾 Document validation results
|
||||
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||
- 🚫 FORBIDDEN to load next step until user selects 'C' and validation is complete
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All improvements from step 3 should be implemented
|
||||
- Focus on validation, not additional changes
|
||||
- Reference best practices for validation criteria
|
||||
- This completes the editing process
|
||||
|
||||
## VALIDATION PROCESS:
|
||||
|
||||
### 1. Comprehensive Validation Checks
|
||||
|
||||
Validate the improved workflow systematically:
|
||||
|
||||
#### File Structure Validation
|
||||
|
||||
- [ ] All required files present
|
||||
- [ ] Directory structure correct
|
||||
- [ ] File names follow conventions
|
||||
- [ ] Path references resolve correctly
|
||||
|
||||
#### Configuration Validation
|
||||
|
||||
- [ ] workflow.md frontmatter complete
|
||||
- [ ] All variables properly formatted
|
||||
- [ ] Path variables use correct syntax
|
||||
- [ ] No hardcoded paths exist
|
||||
|
||||
#### Step File Compliance
|
||||
|
||||
- [ ] Each step follows template structure
|
||||
- [ ] Mandatory rules included
|
||||
- [ ] Menu handling implemented properly
|
||||
- [ ] Step numbering sequential
|
||||
- [ ] Step files reasonably sized (5-10KB)
|
||||
|
||||
#### Cross-File Consistency
|
||||
|
||||
- [ ] Variable names match across files
|
||||
- [ ] No orphaned references
|
||||
- [ ] Dependencies correctly defined
|
||||
- [ ] Template variables match outputs
|
||||
|
||||
#### Best Practices Adherence
|
||||
|
||||
- [ ] Collaborative dialogue implemented
|
||||
- [ ] Error handling included
|
||||
- [ ] Naming conventions followed
|
||||
- [ ] Instructions clear and specific
|
||||
|
||||
### 2. Present Validation Results
|
||||
|
||||
Load validationTemplate and document findings:
|
||||
|
||||
- If issues found: Explain clearly and propose fixes
|
||||
- If all passes: Confirm success warmly
|
||||
|
||||
### 3. Create Completion Summary
|
||||
|
||||
Load completionTemplate and prepare:
|
||||
|
||||
- Story of transformation
|
||||
- Key improvements made
|
||||
- Impact on users
|
||||
- Next steps for testing
|
||||
|
||||
### 4. Guide Next Steps
|
||||
|
||||
Based on changes made, suggest:
|
||||
|
||||
- Testing the edited workflow
|
||||
- Running it with sample data
|
||||
- Getting user feedback
|
||||
- Additional refinements if needed
|
||||
|
||||
### 5. Document Final State
|
||||
|
||||
Update {outputFile} with:
|
||||
|
||||
- Validation results
|
||||
- Completion summary
|
||||
- Change log summary
|
||||
- Recommendations
|
||||
|
||||
## CONTENT TO APPEND TO DOCUMENT:
|
||||
|
||||
After validation, append to {outputFile}:
|
||||
|
||||
Load and append content from {validationTemplate}
|
||||
|
||||
Then load and append content from {completionTemplate}
|
||||
|
||||
## FINAL MENU OPTIONS
|
||||
|
||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue
|
||||
|
||||
### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
- After other menu items execution, return to this menu
|
||||
- User can chat or ask questions - always respond and then end with display again of the menu options
|
||||
- Use menu handling logic section below
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#final-menu-options)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN C is selected and content is saved to {outputFile} with frontmatter updated, will you then load, read entire file, then execute {nextStepFile} to execute and begin compliance validation step.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All improvements validated successfully
|
||||
- No critical issues remain
|
||||
- Completion summary provided
|
||||
- Next steps clearly outlined
|
||||
- User satisfied with results
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping validation steps
|
||||
- Not documenting final state
|
||||
- Ending without user confirmation
|
||||
- Leaving issues unresolved
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue