mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-01-30 04:32:02 +00:00
trimodal viarate workflow creation
This commit is contained in:
@@ -29,13 +29,17 @@ agent:
|
||||
|
||||
menu:
|
||||
- trigger: CW or fuzzy match on create-workflow
|
||||
exec: "{project-root}/_bmad/bmb/workflows/create-workflow/workflow.md"
|
||||
exec: "{project-root}/_bmad/bmb/workflows/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/edit-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/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-compliance-check/workflow.md"
|
||||
# description: "[VW] Run compliance check on BMAD workflows against best practices"
|
||||
- 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"
|
||||
|
||||
@@ -1,220 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,206 +0,0 @@
|
||||
# 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
|
||||
@@ -1,220 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,469 +0,0 @@
|
||||
# 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**
|
||||
@@ -1,139 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,97 +0,0 @@
|
||||
# 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._
|
||||
@@ -46,7 +46,9 @@ 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
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Present Brainstorming Opportunity
|
||||
|
||||
|
||||
@@ -108,7 +108,9 @@ After documentation, present menu:
|
||||
- Clear articulation of value proposition
|
||||
- Comprehensive capability mapping
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
1. **Load Previous Context**
|
||||
- Check for brainstormContext file
|
||||
|
||||
@@ -125,7 +125,9 @@ Present structured options:
|
||||
|
||||
---
|
||||
|
||||
# INSTRUCTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
## 1. Load Documentation
|
||||
Read and internalize:
|
||||
|
||||
@@ -156,7 +156,9 @@ principles:
|
||||
- Workflow steps (belongs in orchestration)
|
||||
- Data structures (belongs in implementation)
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
1. **LOAD** personaProperties.md and principlesCrafting.md
|
||||
2. **EXPLAIN** four-field system with clear examples
|
||||
|
||||
@@ -121,7 +121,9 @@ menu:
|
||||
- **User-facing perspective** - triggers should feel natural
|
||||
- **Capability alignment** - every command maps to a capability
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
1. Load agent-menu-patterns.md to understand structure
|
||||
2. Review capabilities from agent-plan step 3
|
||||
|
||||
@@ -129,7 +129,9 @@ routing:
|
||||
- Expert agents: Sidecar + stand-alone module
|
||||
- Module agents: Sidecar + parent module integration
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
## 1. Load Reference Documents
|
||||
```bash
|
||||
|
||||
@@ -60,7 +60,9 @@ 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
|
||||
|
||||
## EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Template and Architecture Files
|
||||
|
||||
|
||||
@@ -128,7 +128,9 @@ If YOLO mode:
|
||||
- Fix option should return to step-06-build, not earlier steps
|
||||
- If plan file is ambiguous, note ambiguity but use reasonable interpretation
|
||||
|
||||
# SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
## 1. Load Required Files
|
||||
```yaml
|
||||
|
||||
@@ -80,7 +80,9 @@ Validate the built agent YAML file for structural completeness and correctness a
|
||||
- YAML syntax errors preventing file parsing
|
||||
- Path references that don't exist
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
## 1. Load Validation Context
|
||||
|
||||
|
||||
@@ -78,7 +78,9 @@ Validate the sidecar folder structure and referenced paths for Expert agents to
|
||||
- Path references pointing to non-existent files
|
||||
- Empty sidecar files that should have content
|
||||
|
||||
# EXECUTION SEQUENCE
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
## 1. Load Sidecar Context
|
||||
|
||||
|
||||
@@ -59,7 +59,9 @@ 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
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change. (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Grand Celebration
|
||||
|
||||
|
||||
@@ -59,7 +59,9 @@ 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
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Agent File
|
||||
|
||||
|
||||
@@ -54,7 +54,9 @@ 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
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Read Edit Plan Context
|
||||
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
# Placeholder - do not load this step.
|
||||
@@ -36,7 +36,9 @@ 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
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
||||
@@ -37,7 +37,9 @@ 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
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
||||
@@ -35,7 +35,9 @@ Review the agent's command menu and plan any additions, modifications, or remova
|
||||
- 💾 Document planned command changes
|
||||
- 🚫 FORBIDDEN to proceed without documenting changes
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
||||
@@ -39,7 +39,9 @@ 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]
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
||||
@@ -47,7 +47,9 @@ Apply all planned edits to the Simple agent YAML file using templates and archit
|
||||
- ✅ Validate YAML syntax
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
||||
@@ -48,7 +48,9 @@ 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
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
||||
@@ -48,7 +48,9 @@ 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
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Reference Documents
|
||||
|
||||
|
||||
@@ -26,9 +26,9 @@ Validate that the agent's metadata properties (id, name, title, icon, module, ha
|
||||
- **🚫 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
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
1. Read the metadata validation reference from `{agentMetadata}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Read the edit plan from `{editPlan}`
|
||||
|
||||
@@ -28,9 +28,9 @@ Validate that the agent's persona (role, identity, communication_style, principl
|
||||
- **🚫 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
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
1. Read the persona validation reference from `{personaProperties}`
|
||||
2. Read the principles crafting guide from `{principlesCrafting}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
|
||||
@@ -27,9 +27,9 @@ Validate that the agent's menu (commands/tools) follows BMAD patterns as defined
|
||||
- **🚫 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
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
1. Read the menu patterns reference from `{agentMenuPatterns}`
|
||||
2. Read the built agent YAML from `{builtYaml}`
|
||||
3. Read the edit plan from `{editPlan}`
|
||||
|
||||
@@ -30,9 +30,9 @@ Validate the built agent YAML file for structural completeness and correctness a
|
||||
- **🚫 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
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
1. Read the agent compilation reference from `{agentCompilation}`
|
||||
2. Read the simple validation checklist from `{simpleValidation}`
|
||||
3. Read the expert validation checklist from `{expertValidation}`
|
||||
|
||||
@@ -31,9 +31,9 @@ Validate the sidecar folder structure and referenced paths for Expert agents to
|
||||
- **🚫 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
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
### Protocol 1: Load and Compare
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
1. Read the expert validation reference from `{expertValidation}`
|
||||
2. Read the critical actions reference from `{criticalActions}`
|
||||
3. Read the built agent YAML from `{builtYaml}`
|
||||
|
||||
@@ -33,7 +33,9 @@ Display all post-edit validation findings and compare with pre-edit state. Prese
|
||||
- 📊 Display organized summary with before/after comparison
|
||||
- 💾 Allow user to decide how to proceed
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Validation Findings
|
||||
|
||||
|
||||
@@ -48,7 +48,9 @@ Celebrate the successful agent edit, provide summary of changes, and mark edit w
|
||||
- Limits: No more edits, only acknowledgment
|
||||
- Dependencies: All edits successfully applied
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.:
|
||||
|
||||
### 1. Read Edit Plan
|
||||
|
||||
|
||||
@@ -34,7 +34,9 @@ Load the existing agent file and initialize a validation report to track all fin
|
||||
- 💾 Create validation report document
|
||||
- 🚫 FORBIDDEN to proceed without user confirmation
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Agent File
|
||||
|
||||
|
||||
@@ -36,7 +36,9 @@ Validate the agent's metadata properties against BMAD standards as defined in ag
|
||||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
||||
@@ -37,7 +37,9 @@ Validate the agent's persona against BMAD standards as defined in personaPropert
|
||||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
||||
@@ -36,7 +36,9 @@ Validate the agent's command menu structure against BMAD standards as defined in
|
||||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
||||
@@ -38,7 +38,9 @@ Validate the agent's YAML structure and completeness against BMAD standards as d
|
||||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to next validation step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
||||
@@ -38,7 +38,9 @@ Validate the agent's sidecar structure (if Expert type) against BMAD standards a
|
||||
- 💾 Append findings to validation report
|
||||
- ➡️ Auto-advance to summary step
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load References
|
||||
|
||||
|
||||
@@ -32,7 +32,9 @@ Display the complete validation report to the user and offer options for fixing
|
||||
- 📊 Display organized summary
|
||||
- 💾 Allow user to decide next steps
|
||||
|
||||
## Sequence of Instructions:
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. Load Validation Report
|
||||
|
||||
|
||||
@@ -1,158 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,212 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,251 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,217 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,290 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,323 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,285 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,188 +0,0 @@
|
||||
---
|
||||
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,217 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,254 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,218 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,194 +0,0 @@
|
||||
---
|
||||
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.
|
||||
@@ -1,246 +0,0 @@
|
||||
---
|
||||
name: 'step-05-compliance-check'
|
||||
description: 'Run comprehensive compliance validation on the edited workflow'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/edit-workflow'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-05-compliance-check.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
editedWorkflowPath: '{target_workflow_path}'
|
||||
complianceCheckWorkflow: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check/workflow.md'
|
||||
outputFile: '{output_folder}/workflow-edit-{target_workflow_name}.md'
|
||||
|
||||
# Task References
|
||||
complianceCheckTask: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check/workflow.md'
|
||||
---
|
||||
|
||||
# Step 5: Compliance Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Run comprehensive compliance validation on the edited workflow using the workflow-compliance-check workflow to ensure it meets all BMAD standards before completion.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### Role Reinforcement:
|
||||
|
||||
- ✅ You are a workflow editor and quality assurance specialist
|
||||
- ✅ If you already have been given a name, communication_style, and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in BMAD standards and workflow validation
|
||||
- ✅ User brings their edited workflow and needs quality assurance
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on running compliance validation on the edited workflow
|
||||
- 🚫 FORBIDDEN to skip compliance validation or declare workflow complete without it
|
||||
- 💬 Approach: Quality-focused, thorough, and collaborative
|
||||
- 📋 Ensure user understands compliance results and next steps
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Launch workflow-compliance-check on the edited workflow
|
||||
- 💾 Review compliance report and present findings to user
|
||||
- 📖 Explain any issues found and provide fix recommendations
|
||||
- 🚫 FORBIDDEN to proceed without compliance validation completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Edited workflow files from previous improve step
|
||||
- Focus: Compliance validation using workflow-compliance-check workflow
|
||||
- Limits: Validation and reporting only, no further workflow modifications
|
||||
- Dependencies: Successful workflow improvements in previous step
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize Compliance Validation
|
||||
|
||||
"**Final Quality Check: Workflow Compliance Validation**
|
||||
|
||||
Your workflow has been edited! Now let's run a comprehensive compliance check to ensure it meets all BMAD standards and follows best practices.
|
||||
|
||||
This validation will check:
|
||||
|
||||
- Template compliance (workflow-template.md and step-template.md)
|
||||
- File size optimization and markdown formatting
|
||||
- CSV data file standards (if applicable)
|
||||
- Intent vs Prescriptive spectrum alignment
|
||||
- Web search and subprocess optimization
|
||||
- Overall workflow flow and goal alignment"
|
||||
|
||||
### 2. Launch Compliance Check Workflow
|
||||
|
||||
**A. Execute Compliance Validation:**
|
||||
|
||||
"Running comprehensive compliance validation on your edited workflow...
|
||||
Target: `{editedWorkflowPath}`
|
||||
|
||||
**Executing:** {complianceCheckTask}
|
||||
**Validation Scope:** Full 8-phase compliance analysis
|
||||
**Expected Duration:** Thorough validation may take several minutes"
|
||||
|
||||
**B. Monitor Validation Progress:**
|
||||
|
||||
Provide updates as the validation progresses:
|
||||
|
||||
- "✅ Workflow.md validation in progress..."
|
||||
- "✅ Step-by-step compliance checking..."
|
||||
- "✅ File size and formatting analysis..."
|
||||
- "✅ Intent spectrum assessment..."
|
||||
- "✅ Web search optimization analysis..."
|
||||
- "✅ Generating comprehensive compliance report..."
|
||||
|
||||
### 3. Compliance Report Analysis
|
||||
|
||||
**A. Review Validation Results:**
|
||||
|
||||
"**Compliance Validation Complete!**
|
||||
|
||||
**Overall Assessment:** [PASS/PARTIAL/FAIL - based on compliance report]
|
||||
|
||||
- **Critical Issues:** [number found]
|
||||
- **Major Issues:** [number found]
|
||||
- **Minor Issues:** [number found]
|
||||
- **Compliance Score:** [percentage]%"
|
||||
|
||||
**B. Present Key Findings:**
|
||||
|
||||
"**Key Compliance Results:**
|
||||
|
||||
- **Template Adherence:** [summary of template compliance]
|
||||
- **File Optimization:** [file size and formatting issues]
|
||||
- **Intent Spectrum:** [spectrum positioning validation]
|
||||
- **Performance Optimization:** [web search and subprocess findings]
|
||||
- **Overall Flow:** [workflow structure and completion validation]"
|
||||
|
||||
### 4. Issue Resolution Options
|
||||
|
||||
**A. Review Compliance Issues:**
|
||||
|
||||
If issues are found:
|
||||
"**Issues Requiring Attention:**
|
||||
|
||||
**Critical Issues (Must Fix):**
|
||||
[List any critical violations that prevent workflow functionality]
|
||||
|
||||
**Major Issues (Should Fix):**
|
||||
[List major issues that impact quality or maintainability]
|
||||
|
||||
**Minor Issues (Nice to Fix):**
|
||||
[List minor standards compliance issues]"
|
||||
|
||||
**B. Resolution Options:**
|
||||
|
||||
"**Resolution Options:**
|
||||
|
||||
1. **Automatic Fixes** - I can apply automated fixes where possible
|
||||
2. **Manual Guidance** - I'll guide you through manual fixes step by step
|
||||
3. **Return to Edit** - Go back to step 3 for additional improvements
|
||||
4. **Accept as Is** - Proceed with current state (if no critical issues)
|
||||
5. **Detailed Review** - Review full compliance report in detail"
|
||||
|
||||
### 5. Final Validation Confirmation
|
||||
|
||||
**A. User Choice Handling:**
|
||||
|
||||
Based on user selection:
|
||||
|
||||
- **If Automatic Fixes**: Apply fixes and re-run validation
|
||||
- **If Manual Guidance**: Provide step-by-step fix instructions
|
||||
- **If Return to Edit**: Load step-03-discover.md with compliance report context
|
||||
- **If Accept as Is**: Confirm understanding of any remaining issues
|
||||
- **If Detailed Review**: Present full compliance report
|
||||
|
||||
**B. Final Status Confirmation:**
|
||||
|
||||
"**Workflow Compliance Status:** [FINAL/PROVISIONAL]
|
||||
|
||||
**Completion Criteria:**
|
||||
|
||||
- ✅ All critical issues resolved
|
||||
- ✅ Major issues addressed or accepted
|
||||
- ✅ Compliance documentation complete
|
||||
- ✅ User understands any remaining minor issues
|
||||
|
||||
**Your edited workflow is ready!**"
|
||||
|
||||
### 6. Completion Documentation
|
||||
|
||||
**A. Update Compliance Status:**
|
||||
|
||||
Document final compliance status in {outputFile}:
|
||||
|
||||
- **Validation Date:** [current date]
|
||||
- **Compliance Score:** [final percentage]
|
||||
- **Issues Resolved:** [summary of fixes applied]
|
||||
- **Remaining Issues:** [any accepted minor issues]
|
||||
|
||||
**B. Final User Guidance:**
|
||||
|
||||
"**Next Steps for Your Edited Workflow:**
|
||||
|
||||
1. **Test the workflow** with real users to validate functionality
|
||||
2. **Monitor performance** and consider optimization opportunities
|
||||
3. **Gather feedback** for potential future improvements
|
||||
4. **Consider compliance check** periodically for maintenance
|
||||
|
||||
**Support Resources:**
|
||||
|
||||
- Use workflow-compliance-check for future validations
|
||||
- Refer to BMAD documentation for best practices
|
||||
- Use edit-workflow again for future modifications"
|
||||
|
||||
### 7. Final Menu Options
|
||||
|
||||
"**Workflow Edit and Compliance Complete!**
|
||||
|
||||
**Select an Option:**
|
||||
|
||||
- [C] Complete - Finish workflow editing with compliance validation
|
||||
- [R] Review Compliance - View detailed compliance report
|
||||
- [M] More Modifications - Return to editing for additional changes
|
||||
- [T] Test Workflow - Try a test run (if workflow supports testing)"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: End workflow editing successfully with compliance validation summary
|
||||
- IF R: Present detailed compliance report findings
|
||||
- IF M: Return to step-03-discover.md for additional improvements
|
||||
- IF T: If workflow supports testing, suggest test execution method
|
||||
- IF Any other comments or queries: respond and redisplay completion options
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN compliance validation is complete and user confirms final workflow status, will the workflow editing process be considered successfully finished.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Comprehensive compliance validation executed on edited workflow
|
||||
- All compliance issues identified and documented with severity rankings
|
||||
- User provided with clear understanding of validation results
|
||||
- Appropriate resolution options offered and implemented
|
||||
- Final edited workflow meets BMAD standards and is ready for production
|
||||
- User satisfaction with workflow quality and compliance
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping compliance validation before workflow completion
|
||||
- Not addressing critical compliance issues found during validation
|
||||
- Failing to provide clear guidance on issue resolution
|
||||
- Declaring workflow complete without ensuring standards compliance
|
||||
- Not documenting final compliance status for future reference
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,75 +0,0 @@
|
||||
## Workflow Edit Complete!
|
||||
|
||||
### Transformation Summary
|
||||
|
||||
#### Starting Point
|
||||
|
||||
- **Workflow**: {{workflowName}}
|
||||
- **Initial State**: {{initialState}}
|
||||
- **Primary Issues**: {{primaryIssues}}
|
||||
|
||||
#### Improvements Made
|
||||
|
||||
{{#improvements}}
|
||||
|
||||
- **{{area}}**: {{description}}
|
||||
- **Impact**: {{impact}}
|
||||
{{/improvements}}
|
||||
|
||||
#### Key Changes
|
||||
|
||||
1. {{change1}}
|
||||
2. {{change2}}
|
||||
3. {{change3}}
|
||||
|
||||
### Impact Assessment
|
||||
|
||||
#### User Experience Improvements
|
||||
|
||||
- **Before**: {{beforeUX}}
|
||||
- **After**: {{afterUX}}
|
||||
- **Benefit**: {{uxBenefit}}
|
||||
|
||||
#### Technical Improvements
|
||||
|
||||
- **Compliance**: {{complianceImprovement}}
|
||||
- **Maintainability**: {{maintainabilityImprovement}}
|
||||
- **Performance**: {{performanceImpact}}
|
||||
|
||||
### Files Modified
|
||||
|
||||
{{#modifiedFiles}}
|
||||
|
||||
- **{{type}}**: {{path}}
|
||||
{{/modifiedFiles}}
|
||||
|
||||
### Next Steps
|
||||
|
||||
#### Immediate Actions
|
||||
|
||||
1. {{immediateAction1}}
|
||||
2. {{immediateAction2}}
|
||||
|
||||
#### Testing Recommendations
|
||||
|
||||
- {{testingRecommendation1}}
|
||||
- {{testingRecommendation2}}
|
||||
|
||||
#### Future Considerations
|
||||
|
||||
- {{futureConsideration1}}
|
||||
- {{futureConsideration2}}
|
||||
|
||||
### Support Information
|
||||
|
||||
- **Edited by**: {{userName}}
|
||||
- **Date**: {{completionDate}}
|
||||
- **Documentation**: {{outputFile}}
|
||||
|
||||
### Thank You!
|
||||
|
||||
Thank you for collaboratively improving this workflow. Your workflow now follows best practices and should provide a better experience for your users.
|
||||
|
||||
---
|
||||
|
||||
_Edit workflow completed successfully on {{completionDate}}_
|
||||
@@ -1,68 +0,0 @@
|
||||
## Improvement Goals
|
||||
|
||||
### Motivation
|
||||
|
||||
- **Trigger**: {{editTrigger}}
|
||||
- **User Feedback**: {{userFeedback}}
|
||||
- **Success Issues**: {{successIssues}}
|
||||
|
||||
### User Experience Issues
|
||||
|
||||
{{#uxIssues}}
|
||||
|
||||
- {{.}}
|
||||
{{/uxIssues}}
|
||||
|
||||
### Performance Gaps
|
||||
|
||||
{{#performanceGaps}}
|
||||
|
||||
- {{.}}
|
||||
{{/performanceGaps}}
|
||||
|
||||
### Growth Opportunities
|
||||
|
||||
{{#growthOpportunities}}
|
||||
|
||||
- {{.}}
|
||||
{{/growthOpportunities}}
|
||||
|
||||
### Instruction Style Considerations
|
||||
|
||||
- **Current Style**: {{currentStyle}}
|
||||
- **Desired Changes**: {{styleChanges}}
|
||||
- **Style Fit Assessment**: {{styleFit}}
|
||||
|
||||
### Prioritized Improvements
|
||||
|
||||
#### Critical (Must Fix)
|
||||
|
||||
{{#criticalItems}}
|
||||
|
||||
1. {{.}}
|
||||
{{/criticalItems}}
|
||||
|
||||
#### Important (Should Fix)
|
||||
|
||||
{{#importantItems}}
|
||||
|
||||
1. {{.}}
|
||||
{{/importantItems}}
|
||||
|
||||
#### Nice-to-Have (Could Fix)
|
||||
|
||||
{{#niceItems}}
|
||||
|
||||
1. {{.}}
|
||||
{{/niceItems}}
|
||||
|
||||
### Focus Areas for Next Step
|
||||
|
||||
{{#focusAreas}}
|
||||
|
||||
- {{.}}
|
||||
{{/focusAreas}}
|
||||
|
||||
---
|
||||
|
||||
_Goals identified on {{date}}_
|
||||
@@ -1,40 +0,0 @@
|
||||
## Improvement Log
|
||||
|
||||
### Change Summary
|
||||
|
||||
- **Date**: {{date}}
|
||||
- **Improvement Area**: {{improvementArea}}
|
||||
- **User Goal**: {{userGoal}}
|
||||
|
||||
### Changes Made
|
||||
|
||||
#### Change #{{changeNumber}}
|
||||
|
||||
**Issue**: {{issueDescription}}
|
||||
**Solution**: {{solutionDescription}}
|
||||
**Rationale**: {{changeRationale}}
|
||||
|
||||
**Files Modified**:
|
||||
{{#modifiedFiles}}
|
||||
|
||||
- {{.}}
|
||||
{{/modifiedFiles}}
|
||||
|
||||
**Before**:
|
||||
|
||||
```markdown
|
||||
{{beforeContent}}
|
||||
```
|
||||
|
||||
**After**:
|
||||
|
||||
```markdown
|
||||
{{afterContent}}
|
||||
```
|
||||
|
||||
**User Approval**: {{userApproval}}
|
||||
**Impact**: {{expectedImpact}}
|
||||
|
||||
---
|
||||
|
||||
{{/improvementLog}}
|
||||
@@ -1,51 +0,0 @@
|
||||
## Validation Results
|
||||
|
||||
### Overall Status
|
||||
|
||||
**Result**: {{validationResult}}
|
||||
**Date**: {{date}}
|
||||
**Validator**: {{validator}}
|
||||
|
||||
### Validation Categories
|
||||
|
||||
#### File Structure
|
||||
|
||||
- **Status**: {{fileStructureStatus}}
|
||||
- **Details**: {{fileStructureDetails}}
|
||||
|
||||
#### Configuration
|
||||
|
||||
- **Status**: {{configurationStatus}}
|
||||
- **Details**: {{configurationDetails}}
|
||||
|
||||
#### Step Compliance
|
||||
|
||||
- **Status**: {{stepComplianceStatus}}
|
||||
- **Details**: {{stepComplianceDetails}}
|
||||
|
||||
#### Cross-File Consistency
|
||||
|
||||
- **Status**: {{consistencyStatus}}
|
||||
- **Details**: {{consistencyDetails}}
|
||||
|
||||
#### Best Practices
|
||||
|
||||
- **Status**: {{bestPracticesStatus}}
|
||||
- **Details**: {{bestPracticesDetails}}
|
||||
|
||||
### Issues Found
|
||||
|
||||
{{#validationIssues}}
|
||||
|
||||
- **{{severity}}**: {{description}}
|
||||
- **Impact**: {{impact}}
|
||||
- **Recommendation**: {{recommendation}}
|
||||
{{/validationIssues}}
|
||||
|
||||
### Validation Summary
|
||||
|
||||
{{validationSummary}}
|
||||
|
||||
---
|
||||
|
||||
_Validation completed on {{date}}_
|
||||
@@ -1,56 +0,0 @@
|
||||
## Workflow Analysis
|
||||
|
||||
### Target Workflow
|
||||
|
||||
- **Path**: {{workflowPath}}
|
||||
- **Name**: {{workflowName}}
|
||||
- **Module**: {{workflowModule}}
|
||||
- **Format**: {{workflowFormat}} (Standalone/Legacy)
|
||||
|
||||
### Structure Analysis
|
||||
|
||||
- **Type**: {{workflowType}}
|
||||
- **Total Steps**: {{stepCount}}
|
||||
- **Step Flow**: {{stepFlowPattern}}
|
||||
- **Files**: {{fileStructure}}
|
||||
|
||||
### Content Characteristics
|
||||
|
||||
- **Purpose**: {{workflowPurpose}}
|
||||
- **Instruction Style**: {{instructionStyle}}
|
||||
- **User Interaction**: {{interactionPattern}}
|
||||
- **Complexity**: {{complexityLevel}}
|
||||
|
||||
### Initial Assessment
|
||||
|
||||
#### Strengths
|
||||
|
||||
{{#strengths}}
|
||||
|
||||
- {{.}}
|
||||
{{/strengths}}
|
||||
|
||||
#### Potential Issues
|
||||
|
||||
{{#issues}}
|
||||
|
||||
- {{.}}
|
||||
{{/issues}}
|
||||
|
||||
#### Format-Specific Notes
|
||||
|
||||
{{#formatNotes}}
|
||||
|
||||
- {{.}}
|
||||
{{/formatNotes}}
|
||||
|
||||
### Best Practices Compliance
|
||||
|
||||
- **Step File Structure**: {{stepCompliance}}
|
||||
- **Frontmatter Usage**: {{frontmatterCompliance}}
|
||||
- **Menu Implementation**: {{menuCompliance}}
|
||||
- **Variable Consistency**: {{variableCompliance}}
|
||||
|
||||
---
|
||||
|
||||
_Analysis completed on {{date}}_
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
name: edit-workflow
|
||||
description: Intelligent workflow editor that helps modify existing workflows while following best practices
|
||||
web_bundle: true
|
||||
---
|
||||
|
||||
# Edit Workflow
|
||||
|
||||
**Goal:** Collaboratively edit and improve existing workflows, ensuring they follow best practices and meet user needs effectively.
|
||||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are also a workflow editor and improvement specialist collaborating with a workflow owner. This is a partnership, not a client-vendor relationship. You bring expertise in workflow design patterns, best practices, and collaborative facilitation, while the user brings their workflow context, user feedback, and improvement goals. 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/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. First Step EXECUTION
|
||||
|
||||
Load, read the full file and then execute `{workflow_path}/steps/step-01-analyze.md` to begin the workflow.
|
||||
@@ -1,153 +0,0 @@
|
||||
---
|
||||
name: 'step-01-validate-goal'
|
||||
description: 'Confirm workflow path and validation goals before proceeding'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-01-validate-goal.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-workflow-validation.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
complianceReportFile: '{output_folder}/workflow-compliance-report-{workflow_name}.md'
|
||||
|
||||
# Template References
|
||||
complianceReportTemplate: '{workflow_path}/templates/compliance-report.md'
|
||||
|
||||
# Documentation References
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
---
|
||||
|
||||
# Step 1: Goal Confirmation and Workflow Target
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Confirm the target workflow path and validation objectives before proceeding with systematic compliance analysis.
|
||||
|
||||
## 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 compliance validator and quality assurance specialist
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring compliance expertise and systematic validation skills
|
||||
- ✅ User brings their workflow and specific compliance concerns
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on confirming workflow path and validation scope
|
||||
- 🚫 FORBIDDEN to proceed without clear target confirmation
|
||||
- 💬 Approach: Systematic and thorough confirmation of validation objectives
|
||||
- 📋 Ensure user understands the compliance checking process and scope
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Confirm target workflow path exists and is accessible
|
||||
- 💾 Establish clear validation objectives and scope
|
||||
- 📖 Explain the three-phase compliance checking process
|
||||
- 🚫 FORBIDDEN to proceed without user confirmation of goals
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: User-provided workflow path and validation concerns
|
||||
- Focus: Goal confirmation and target validation setup
|
||||
- Limits: No actual compliance analysis yet, just setup and confirmation
|
||||
- Dependencies: Clear workflow path and user agreement on validation scope
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Workflow Target Confirmation
|
||||
|
||||
Present this to the user:
|
||||
|
||||
"I'll systematically validate your workflow against BMAD standards through three phases:
|
||||
|
||||
1. **Workflow.md Validation** - Against workflow-template.md standards
|
||||
2. **Step-by-Step Compliance** - Each step against step-template.md
|
||||
3. **Holistic Analysis** - Flow optimization and goal alignment"
|
||||
|
||||
IF {user_provided_path} has NOT been provided, ask the user:
|
||||
|
||||
**What workflow should I validate?** Please provide the full path to the workflow.md file."
|
||||
|
||||
### 2. Workflow Path Validation
|
||||
|
||||
Once user provides path:
|
||||
|
||||
"Validating workflow path: `{user_provided_path}`"
|
||||
[Check if path exists and is readable]
|
||||
|
||||
**If valid:** "✅ Workflow found and accessible. Ready to begin compliance analysis."
|
||||
**If invalid:** "❌ Cannot access workflow at that path. Please check the path and try again."
|
||||
|
||||
### 3. Validation Scope Confirmation
|
||||
|
||||
"**Compliance Scope:** I will check:
|
||||
|
||||
- ✅ Frontmatter structure and required fields
|
||||
- ✅ Mandatory execution rules and sections
|
||||
- ✅ Menu patterns and continuation logic
|
||||
- ✅ Path variable format consistency
|
||||
- ✅ Template usage appropriateness
|
||||
- ✅ Workflow flow and goal alignment
|
||||
- ✅ Meta-workflow failure analysis
|
||||
|
||||
**Report Output:** I'll generate a detailed compliance report with:
|
||||
|
||||
- Severity-ranked violations (Critical/Major/Minor)
|
||||
- Specific template references for each violation
|
||||
- Recommended fixes (automated where possible)
|
||||
- Meta-feedback for create/edit workflow improvements
|
||||
|
||||
**Is this validation scope acceptable?**"
|
||||
|
||||
### 4. Final Confirmation
|
||||
|
||||
"**Ready to proceed with compliance check of:**
|
||||
|
||||
- **Workflow:** `{workflow_name}`
|
||||
- **Validation:** Full systematic compliance analysis
|
||||
- **Output:** Detailed compliance report with fix recommendations
|
||||
|
||||
**Select an Option:** [C] Continue [X] Exit"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: Initialize compliance report, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF X: End workflow gracefully with guidance on running again later
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#4-final-confirmation)
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [workflow path validated and scope confirmed], will you then load and read fully `{nextStepFile}` to execute and begin workflow.md validation phase.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Workflow path successfully validated and accessible
|
||||
- User confirms validation scope and objectives
|
||||
- Compliance report initialization prepared
|
||||
- User understands the three-phase validation process
|
||||
- Clear next steps established for systematic analysis
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Proceeding without valid workflow path confirmation
|
||||
- Not ensuring user understands validation scope and process
|
||||
- Starting compliance analysis without proper setup
|
||||
- Failing to establish clear reporting objectives
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,244 +0,0 @@
|
||||
---
|
||||
name: 'step-02-workflow-validation'
|
||||
description: 'Validate workflow.md against workflow-template.md standards'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-02-workflow-validation.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-03-step-validation.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
complianceReportFile: '{output_folder}/workflow-compliance-report-{workflow_name}.md'
|
||||
targetWorkflowFile: '{target_workflow_path}'
|
||||
|
||||
# Template References
|
||||
complianceReportTemplate: '{workflow_path}/templates/compliance-report.md'
|
||||
|
||||
# Documentation References
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
---
|
||||
|
||||
# Step 2: Workflow.md Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Perform adversarial validation of the target workflow.md against workflow-template.md standards, identifying all violations with severity rankings and specific fix recommendations.
|
||||
|
||||
## 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 compliance validator and quality assurance specialist
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring adversarial validation expertise - your success is finding violations
|
||||
- ✅ User brings their workflow and needs honest, thorough validation
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on workflow.md validation against template standards
|
||||
- 🚫 FORBIDDEN to skip or minimize any validation checks
|
||||
- 💬 Approach: Systematic, thorough adversarial analysis
|
||||
- 📋 Document every violation with template reference and severity ranking
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load and compare target workflow.md against workflow-template.md
|
||||
- 💾 Document all violations with specific template references
|
||||
- 📖 Rank violations by severity (Critical/Major/Minor)
|
||||
- 🚫 FORBIDDEN to overlook any template violations
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Validated workflow path and target workflow.md
|
||||
- Focus: Systematic validation of workflow.md structure and content
|
||||
- Limits: Only workflow.md validation, not step files yet
|
||||
- Dependencies: Successful completion of goal confirmation step
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize Compliance Report
|
||||
|
||||
"Beginning **Phase 1: Workflow.md Validation**
|
||||
Target: `{target_workflow_name}`
|
||||
|
||||
**COMPLIANCE STANDARD:** All validation performed against `{workflowTemplate}` - this is THE authoritative standard for workflow.md compliance.
|
||||
|
||||
Loading workflow templates and target files for systematic analysis..."
|
||||
[Load workflowTemplate, targetWorkflowFile]
|
||||
|
||||
### 2. Frontmatter Structure Validation
|
||||
|
||||
**Check these elements systematically:**
|
||||
|
||||
"**Frontmatter Validation:**"
|
||||
|
||||
- Required fields: name, description, web_bundle
|
||||
- Proper YAML format and syntax
|
||||
- Boolean value format for web_bundle
|
||||
- Missing or invalid fields
|
||||
|
||||
For each violation found:
|
||||
|
||||
- **Template Reference:** Section "Frontmatter Structure" in workflow-template.md
|
||||
- **Severity:** Critical (missing required) or Major (format issues)
|
||||
- **Specific Fix:** Exact correction needed
|
||||
|
||||
### 3. Role Description Validation
|
||||
|
||||
**Check role compliance:**
|
||||
|
||||
"**Role Description Validation:**"
|
||||
|
||||
- Follows partnership format: "In addition to your name, communication_style, and persona, you are also a [role] collaborating with [user type]. This is a partnership, not a client-vendor relationship. You bring [your expertise], while the user brings [their expertise]. Work together as equals."
|
||||
- Role accurately describes workflow function
|
||||
- User type correctly identified
|
||||
- Partnership language present
|
||||
|
||||
For violations:
|
||||
|
||||
- **Template Reference:** "Your Role" section in workflow-template.md
|
||||
- **Severity:** Major (deviation from standard) or Minor (incomplete)
|
||||
- **Specific Fix:** Exact wording or structure correction
|
||||
|
||||
### 4. Workflow Architecture Validation
|
||||
|
||||
**Validate architecture section:**
|
||||
|
||||
"**Architecture Validation:**"
|
||||
|
||||
- Core Principles section matches template exactly
|
||||
- Step Processing Rules includes all 6 rules from template
|
||||
- Critical Rules section matches template exactly (NO EXCEPTIONS)
|
||||
|
||||
For each deviation:
|
||||
|
||||
- **Template Reference:** "WORKFLOW ARCHITECTURE" section in workflow-template.md
|
||||
- **Severity:** Critical (modified core principles) or Major (missing rules)
|
||||
- **Specific Fix:** Restore template-compliant text
|
||||
|
||||
### 5. Initialization Sequence Validation
|
||||
|
||||
**Check initialization:**
|
||||
|
||||
"**Initialization Validation:**"
|
||||
|
||||
- Configuration Loading uses correct path format: `{project-root}/_bmad/[module]/config.yaml` (variable substitution pattern)
|
||||
- First step follows pattern: `step-01-init.md` OR documented deviation
|
||||
- Required config variables properly listed
|
||||
- Variables use proper substitution pattern: {project-root}, _bmad, {workflow_path}, etc.
|
||||
|
||||
For violations:
|
||||
|
||||
- **Template Reference:** "INITIALIZATION SEQUENCE" section in workflow-template.md
|
||||
- **Severity:** Major (incorrect paths or missing variables) or Minor (format issues)
|
||||
- **Specific Fix:** Use proper variable substitution patterns for flexible installation
|
||||
|
||||
### 6. Document Workflow.md Findings
|
||||
|
||||
"**Workflow.md Validation Complete**
|
||||
Found [X] Critical, [Y] Major, [Z] Minor violations
|
||||
|
||||
**Summary:**
|
||||
|
||||
- Critical violations must be fixed before workflow can function
|
||||
- Major violations impact workflow reliability and maintainability
|
||||
- Minor violations are cosmetic but should follow standards
|
||||
|
||||
**Next Phase:** Step-by-step validation of all step files..."
|
||||
|
||||
### 7. Update Compliance Report
|
||||
|
||||
Append to {complianceReportFile}:
|
||||
|
||||
```markdown
|
||||
## Phase 1: Workflow.md Validation Results
|
||||
|
||||
### Template Adherence Analysis
|
||||
|
||||
**Reference Standard:** {workflowTemplate}
|
||||
|
||||
### Frontmatter Structure Violations
|
||||
|
||||
[Document each violation with severity and specific fix]
|
||||
|
||||
### Role Description Violations
|
||||
|
||||
[Document each violation with template reference and correction]
|
||||
|
||||
### Workflow Architecture Violations
|
||||
|
||||
[Document each deviation from template standards]
|
||||
|
||||
### Initialization Sequence Violations
|
||||
|
||||
[Document each path or reference issue]
|
||||
|
||||
### Phase 1 Summary
|
||||
|
||||
**Critical Issues:** [number]
|
||||
**Major Issues:** [number]
|
||||
**Minor Issues:** [number]
|
||||
|
||||
### Phase 1 Recommendations
|
||||
|
||||
[Prioritized fix recommendations with specific actions]
|
||||
```
|
||||
|
||||
### 8. Continuation Confirmation
|
||||
|
||||
"**Phase 1 Complete:** Workflow.md validation finished with detailed violation analysis.
|
||||
|
||||
**Ready for Phase 3:** Step-by-step validation against step-template.md
|
||||
|
||||
This will check each step file for:
|
||||
|
||||
- Frontmatter completeness and format
|
||||
- MANDATORY EXECUTION RULES compliance
|
||||
- Menu pattern and continuation logic
|
||||
- Path variable consistency
|
||||
- Template appropriateness
|
||||
|
||||
**Select an Option:** [C] Continue to Step Validation [X] Exit"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: Save workflow.md findings to report, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF X: Save current findings and end workflow with guidance for resuming
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [workflow.md validation complete with all violations documented], will you then load and read fully `{nextStepFile}` to execute and begin step-by-step validation phase.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Complete workflow.md validation against workflow-template.md
|
||||
- All violations documented with severity rankings and template references
|
||||
- Specific fix recommendations provided for each violation
|
||||
- Compliance report updated with Phase 1 findings
|
||||
- User confirms understanding before proceeding
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping any workflow.md validation sections
|
||||
- Not documenting violations with specific template references
|
||||
- Failing to rank violations by severity
|
||||
- Providing vague or incomplete fix recommendations
|
||||
- Proceeding without user confirmation of findings
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,275 +0,0 @@
|
||||
---
|
||||
name: 'step-03-step-validation'
|
||||
description: 'Validate each step file against step-template.md standards'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-03-step-validation.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-04-file-validation.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
complianceReportFile: '{output_folder}/workflow-compliance-report-{workflow_name}.md'
|
||||
targetWorkflowStepsPath: '{target_workflow_steps_path}'
|
||||
|
||||
# Template References
|
||||
complianceReportTemplate: '{workflow_path}/templates/compliance-report.md'
|
||||
|
||||
# Documentation References
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
---
|
||||
|
||||
# Step 3: Step-by-Step Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Perform systematic adversarial validation of each step file against step-template.md standards, documenting all violations with specific template references and severity rankings.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read this 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 compliance validator and quality assurance specialist
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring adversarial step-by-step validation expertise
|
||||
- ✅ User brings their workflow steps and needs thorough validation
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on step file validation against step-template.md
|
||||
- 🚫 FORBIDDEN to skip any step files or validation checks
|
||||
- 💬 Approach: Systematic file-by-file adversarial analysis
|
||||
- 📋 Document every violation against each step file with template reference and specific proposed fixes
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load and validate each step file individually against step-template.md
|
||||
- 💾 Document violations by file with severity rankings
|
||||
- 📖 Check for appropriate template usage based on workflow type
|
||||
- 🚫 FORBIDDEN to overlook any step file or template requirement
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Target workflow step files and step-template.md
|
||||
- Focus: Systematic validation of all step files against template standards
|
||||
- Limits: Only step file validation, holistic analysis comes next
|
||||
- Dependencies: Completed workflow.md validation from previous phase
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize Step Validation Phase
|
||||
|
||||
"Beginning **Phase 2: Step-by-Step Validation**
|
||||
Target: `{target_workflow_name}` - [number] step files found
|
||||
|
||||
**COMPLIANCE STANDARD:** All validation performed against `{stepTemplate}` - this is THE authoritative standard for step file compliance.
|
||||
|
||||
Loading step template and validating each step systematically..."
|
||||
[Load stepTemplate, enumerate all step files]. Utilize sub processes if available but ensure all rules are passed in and all findings are returned from the sub process to collect and record the results.
|
||||
|
||||
### 2. Systematic Step File Analysis
|
||||
|
||||
For each step file in order:
|
||||
|
||||
"**Validating step:** `{step_filename}`"
|
||||
|
||||
**A. Frontmatter Structure Validation:**
|
||||
Check each required field:
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[number]-[name]' # Single quotes, proper format
|
||||
description: '[description]' # Single quotes
|
||||
workflowFile: '{workflow_path}/workflow.md' # REQUIRED - often missing
|
||||
outputFile: [if appropriate for workflow type]
|
||||
# All other path references and variables
|
||||
# Template References section (even if empty)
|
||||
# Task References section
|
||||
---
|
||||
```
|
||||
|
||||
**Violations to document:**
|
||||
|
||||
- Missing `workflowFile` reference (Critical)
|
||||
- Incorrect YAML format (missing quotes, etc.) (Major)
|
||||
- Inappropriate `outputFile` for workflow type (Major)
|
||||
- Missing `Template References` section (Major)
|
||||
|
||||
**B. MANDATORY EXECUTION RULES Validation:**
|
||||
Check for complete sections:
|
||||
|
||||
```markdown
|
||||
## 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:
|
||||
|
||||
[Complete role reinforcement section]
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
[Step-specific rules with proper emoji usage]
|
||||
```
|
||||
|
||||
**Violations to document:**
|
||||
|
||||
- Missing Universal Rules (Critical)
|
||||
- Modified/skipped Universal Rules (Critical)
|
||||
- Missing Role Reinforcement (Major)
|
||||
- Improper emoji usage in rules (Minor)
|
||||
|
||||
**C. Task References Validation:**
|
||||
Check for proper references:
|
||||
|
||||
```yaml
|
||||
# Task References
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
```
|
||||
|
||||
**Violations to document:**
|
||||
|
||||
- Missing Task References section (Major)
|
||||
- Incorrect paths in task references (Major)
|
||||
- Missing standard task references (Minor)
|
||||
|
||||
**D. Menu Pattern Validation:**
|
||||
Check menu structure:
|
||||
|
||||
```markdown
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
- IF P: Execute {partyModeWorkflow}
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then only then load, read entire file, then execute {nextStepFile}
|
||||
```
|
||||
|
||||
**Violations to document:**
|
||||
|
||||
- Non-standard menu format (Major)
|
||||
- Missing Menu Handling Logic section (Major)
|
||||
- Incorrect "load, read entire file, then execute" pattern (Major)
|
||||
- Improper continuation logic (Critical)
|
||||
|
||||
### 3. Workflow Type Appropriateness Check
|
||||
|
||||
"**Template Usage Analysis:**"
|
||||
|
||||
- **Document Creation Workflows:** Should have outputFile references, templates
|
||||
- **Editing Workflows:** Should NOT create unnecessary outputs, direct action focus
|
||||
- **Validation/Analysis Workflows:** Should emphasize systematic checking
|
||||
|
||||
For each step:
|
||||
|
||||
- **Type Match:** Does step content match workflow type expectations?
|
||||
- **Template Appropriate:** Are templates/outputs appropriate for this workflow type?
|
||||
- **Alternative Suggestion:** What would be more appropriate?
|
||||
|
||||
### 4. Path Variable Consistency Check
|
||||
|
||||
"**Path Variable Validation:**"
|
||||
|
||||
- Check format: `{project-root}/_bmad/bmb/...` vs `{project-root}/bmb/...`
|
||||
- Ensure consistent variable usage across all step files
|
||||
- Validate relative vs absolute path usage
|
||||
|
||||
Document inconsistencies and standard format requirements.
|
||||
|
||||
### 5. Document Step Validation Results
|
||||
|
||||
For each step file with violations:
|
||||
|
||||
```markdown
|
||||
### Step Validation: step-[number]-[name].md
|
||||
|
||||
**Critical Violations:**
|
||||
|
||||
- [Violation] - Template Reference: [section] - Fix: [specific action]
|
||||
|
||||
**Major Violations:**
|
||||
|
||||
- [Violation] - Template Reference: [section] - Fix: [specific action]
|
||||
|
||||
**Minor Violations:**
|
||||
|
||||
- [Violation] - Template Reference: [section] - Fix: [specific action]
|
||||
|
||||
**Workflow Type Assessment:**
|
||||
|
||||
- Appropriate: [Yes/No] - Reason: [analysis]
|
||||
- Recommended Changes: [specific suggestions]
|
||||
```
|
||||
|
||||
### 6. Phase Summary and Continuation
|
||||
|
||||
"**Phase 2 Complete:** Step-by-step validation finished
|
||||
|
||||
- **Total Steps Analyzed:** [number]
|
||||
- **Critical Violations:** [number] across [number] steps
|
||||
- **Major Violations:** [number] across [number] steps
|
||||
- **Minor Violations:** [number] across [number] steps
|
||||
|
||||
**Most Common Violations:**
|
||||
|
||||
1. [Most frequent violation type]
|
||||
2. [Second most frequent]
|
||||
3. [Third most frequent]
|
||||
|
||||
**Ready for Phase 4:** File Validation workflow analysis
|
||||
|
||||
- Flow optimization assessment
|
||||
- Goal alignment verification
|
||||
- Meta-workflow failure analysis
|
||||
|
||||
**Select an Option:** [C] Continue to File Validation [X] Exit"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: Save step validation findings to report, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF X: Save current findings and end with guidance for resuming
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [all step files validated with violations documented], will you then load and read fully `{nextStepFile}` to execute and begin holistic analysis phase.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All step files systematically validated against step-template.md
|
||||
- Every violation documented with specific template reference and severity
|
||||
- Workflow type appropriateness assessed for each step
|
||||
- Path variable consistency checked across all files
|
||||
- Common violation patterns identified and prioritized
|
||||
- Compliance report updated with complete Phase 2 findings
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping step files or validation sections
|
||||
- Not documenting violations with specific template references
|
||||
- Failing to assess workflow type appropriateness
|
||||
- Missing path variable consistency analysis
|
||||
- Providing incomplete or vague fix recommendations
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,296 +0,0 @@
|
||||
---
|
||||
name: 'step-04-file-validation'
|
||||
description: 'Validate file sizes, markdown formatting, and CSV data files'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-04-file-validation.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-05-intent-spectrum-validation.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
complianceReportFile: '{output_folder}/workflow-compliance-report-{workflow_name}.md'
|
||||
targetWorkflowPath: '{target_workflow_path}'
|
||||
|
||||
# Template References
|
||||
complianceReportTemplate: '{workflow_path}/templates/compliance-report.md'
|
||||
|
||||
# Documentation References
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
csvStandards: '{project-root}/_bmad/bmb/docs/workflows/csv-data-file-standards.md'
|
||||
---
|
||||
|
||||
# Step 4: File Size, Formatting, and Data Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Validate file sizes, markdown formatting standards, and CSV data file compliance to ensure optimal workflow performance and maintainability.
|
||||
|
||||
## 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 compliance validator and quality assurance specialist
|
||||
- ✅ If you already have been given a name, communication_style, and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring file optimization and formatting validation expertise
|
||||
- ✅ User brings their workflow files and needs performance optimization
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on file sizes, markdown formatting, and CSV validation
|
||||
- 🚫 FORBIDDEN to skip file size analysis or CSV validation when present
|
||||
- 💬 Approach: Systematic file analysis with optimization recommendations
|
||||
- 📋 Ensure all findings include specific recommendations for improvement
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Validate file sizes against optimal ranges (≤5K best, 5-7K good, 7-10K acceptable, 10-12K concern, >15K action required)
|
||||
- 💾 Check markdown formatting standards and conventions
|
||||
- 📖 Validate CSV files against csv-data-file-standards.md when present
|
||||
- 🚫 FORBIDDEN to overlook file optimization opportunities
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Target workflow files and their sizes/formats
|
||||
- Focus: File optimization, formatting standards, and CSV data validation
|
||||
- Limits: File analysis only, holistic workflow analysis comes next
|
||||
- Dependencies: Completed step-by-step validation from previous phase
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize File Validation Phase
|
||||
|
||||
"Beginning **File Size, Formatting, and Data Validation**
|
||||
Target: `{target_workflow_name}`
|
||||
|
||||
Analyzing workflow files for:
|
||||
|
||||
- File size optimization (smaller is better for performance)
|
||||
- Markdown formatting standards compliance
|
||||
- CSV data file standards validation (if present)
|
||||
- Overall file maintainability and performance..."
|
||||
|
||||
### 2. File Size Analysis
|
||||
|
||||
**A. Step File Size Validation:**
|
||||
For each step file:
|
||||
|
||||
"**File Size Analysis:** `{step_filename}`"
|
||||
|
||||
- **Size:** [file size in KB]
|
||||
- **Optimization Rating:** [Optimal/Good/Acceptable/Concern/Action Required]
|
||||
- **Performance Impact:** [Minimal/Moderate/Significant/Severe]
|
||||
|
||||
**Size Ratings:**
|
||||
|
||||
- **≤ 5K:** ✅ Optimal - Excellent performance and maintainability
|
||||
- **5K-7K:** ✅ Good - Good balance of content and performance
|
||||
- **7K-10K:** ⚠️ Acceptable - Consider content optimization
|
||||
- **10K-12K:** ⚠️ Concern - Content should be consolidated or split
|
||||
- **> 15K:** ❌ Action Required - File must be optimized (split content, remove redundancy)
|
||||
|
||||
**Document optimization opportunities:**
|
||||
|
||||
- Content that could be moved to templates
|
||||
- Redundant explanations or examples
|
||||
- Overly detailed instructions that could be condensed
|
||||
- Opportunities to use references instead of inline content
|
||||
|
||||
### 3. Markdown Formatting Validation
|
||||
|
||||
**A. Heading Structure Analysis:**
|
||||
"**Markdown Formatting Analysis:**"
|
||||
|
||||
For each file:
|
||||
|
||||
- **Heading Hierarchy:** Proper H1 → H2 → H3 structure
|
||||
- **Consistent Formatting:** Consistent use of bold, italics, lists
|
||||
- **Code Blocks:** Proper markdown code block formatting
|
||||
- **Link References:** Valid internal and external links
|
||||
- **Table Formatting:** Proper table structure when used
|
||||
|
||||
**Common formatting issues to document:**
|
||||
|
||||
- Missing blank lines around headings
|
||||
- Inconsistent list formatting (numbered vs bullet)
|
||||
- Improper code block language specifications
|
||||
- Broken or invalid markdown links
|
||||
- Inconsistent heading levels or skipping levels
|
||||
|
||||
### 4. CSV Data File Validation (if present)
|
||||
|
||||
**A. Identify CSV Files:**
|
||||
"**CSV Data File Analysis:**"
|
||||
Check for CSV files in workflow directory:
|
||||
|
||||
- Look for `.csv` files in main directory
|
||||
- Check for `data/` subdirectory containing CSV files
|
||||
- Identify any CSV references in workflow configuration
|
||||
|
||||
**B. Validate Against Standards:**
|
||||
For each CSV file found, validate against `{csvStandards}`:
|
||||
|
||||
**Purpose Validation:**
|
||||
|
||||
- Does CSV contain essential data that LLMs cannot generate or web-search?
|
||||
- Is all CSV data referenced and used in the workflow?
|
||||
- Is data domain-specific and valuable?
|
||||
- Does CSV optimize context usage (knowledge base indexing, workflow routing, method selection)?
|
||||
- Does CSV reduce workflow complexity or step count significantly?
|
||||
- Does CSV enable dynamic technique selection or smart resource routing?
|
||||
|
||||
**Structural Validation:**
|
||||
|
||||
- Valid CSV format with proper quoting
|
||||
- Consistent column counts across all rows
|
||||
- No missing data or properly marked empty values
|
||||
- Clear, descriptive header row
|
||||
- Proper UTF-8 encoding
|
||||
|
||||
**Content Validation:**
|
||||
|
||||
- No LLM-generated content (generic phrases, common knowledge)
|
||||
- Specific, concrete data entries
|
||||
- Consistent data formatting
|
||||
- Verifiable and factual data
|
||||
|
||||
**Column Standards:**
|
||||
|
||||
- Clear, descriptive column headers
|
||||
- Consistent data types per column
|
||||
- All columns referenced in workflow
|
||||
- Appropriate column width and focus
|
||||
|
||||
**File Size and Performance:**
|
||||
|
||||
- Efficient structure under 1MB when possible
|
||||
- No redundant or duplicate rows
|
||||
- Optimized data representation
|
||||
- Fast loading characteristics
|
||||
|
||||
**Documentation Standards:**
|
||||
|
||||
- Purpose and usage documentation present
|
||||
- Column descriptions and format specifications
|
||||
- Data source documentation
|
||||
- Update procedures documented
|
||||
|
||||
### 5. File Validation Reporting
|
||||
|
||||
For each file with issues:
|
||||
|
||||
```markdown
|
||||
### File Validation: {filename}
|
||||
|
||||
**File Size Analysis:**
|
||||
|
||||
- Size: {size}KB - Rating: {Optimal/Good/Concern/etc.}
|
||||
- Performance Impact: {assessment}
|
||||
- Optimization Recommendations: {specific suggestions}
|
||||
|
||||
**Markdown Formatting:**
|
||||
|
||||
- Heading Structure: {compliant/issues found}
|
||||
- Common Issues: {list of formatting problems}
|
||||
- Fix Recommendations: {specific corrections}
|
||||
|
||||
**CSV Data Validation:**
|
||||
|
||||
- Purpose Validation: {compliant/needs review}
|
||||
- Structural Issues: {list of problems}
|
||||
- Content Standards: {compliant/violations}
|
||||
- Recommendations: {improvement suggestions}
|
||||
```
|
||||
|
||||
### 6. Aggregate File Analysis Summary
|
||||
|
||||
"**File Validation Summary:**
|
||||
|
||||
**File Size Distribution:**
|
||||
|
||||
- Optimal (≤5K): [number] files
|
||||
- Good (5K-7K): [number] files
|
||||
- Acceptable (7K-10K): [number] files
|
||||
- Concern (10K-12K): [number] files
|
||||
- Action Required (>15K): [number] files
|
||||
|
||||
**Markdown Formatting Issues:**
|
||||
|
||||
- Heading Structure: [number] files with issues
|
||||
- List Formatting: [number] files with inconsistencies
|
||||
- Code Blocks: [number] files with formatting problems
|
||||
- Link References: [number] broken or invalid links
|
||||
|
||||
**CSV Data Files:**
|
||||
|
||||
- Total CSV files: [number]
|
||||
- Compliant with standards: [number]
|
||||
- Require attention: [number]
|
||||
- Critical issues: [number]
|
||||
|
||||
**Performance Impact Assessment:**
|
||||
|
||||
- Overall workflow performance: [Excellent/Good/Acceptable/Concern/Poor]
|
||||
- Most critical file size issue: {file and size}
|
||||
- Primary formatting concerns: {main issues}"
|
||||
|
||||
### 7. Continuation Confirmation
|
||||
|
||||
"**File Validation Complete:** Size, formatting, and CSV analysis finished
|
||||
|
||||
**Key Findings:**
|
||||
|
||||
- **File Optimization:** [summary of size optimization opportunities]
|
||||
- **Formatting Standards:** [summary of markdown compliance issues]
|
||||
- **Data Validation:** [summary of CSV standards compliance]
|
||||
|
||||
**Ready for Phase 5:** Intent Spectrum Validation analysis
|
||||
|
||||
- Flow validation and goal alignment
|
||||
- Meta-workflow failure analysis
|
||||
- Strategic recommendations and improvement planning
|
||||
|
||||
**Select an Option:** [C] Continue to Intent Spectrum Validation [X] Exit"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: Save file validation findings to report, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF X: Save current findings and end with guidance for resuming
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [all file sizes analyzed, markdown formatting validated, and CSV files checked against standards], will you then load and read fully `{nextStepFile}` to execute and begin Intent Spectrum Validation phase.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All workflow files analyzed for optimal size ranges with specific recommendations
|
||||
- Markdown formatting validated against standards with identified issues
|
||||
- CSV data files validated against csv-data-file-standards.md when present
|
||||
- Performance impact assessed with optimization opportunities identified
|
||||
- File validation findings documented with specific fix recommendations
|
||||
- User ready for holistic workflow analysis
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping file size analysis or markdown formatting validation
|
||||
- Not checking CSV files against standards when present
|
||||
- Failing to provide specific optimization recommendations
|
||||
- Missing performance impact assessment
|
||||
- Overlooking critical file size violations (>15K)
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,265 +0,0 @@
|
||||
---
|
||||
name: 'step-05-intent-spectrum-validation'
|
||||
description: 'Dedicated analysis and validation of intent vs prescriptive spectrum positioning'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-05-intent-spectrum-validation.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-06-web-subprocess-validation.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
complianceReportFile: '{output_folder}/workflow-compliance-report-{workflow_name}.md'
|
||||
targetWorkflowPath: '{target_workflow_path}'
|
||||
|
||||
# Template References
|
||||
complianceReportTemplate: '{workflow_path}/templates/compliance-report.md'
|
||||
|
||||
# Documentation References
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
intentSpectrum: '{project-root}/_bmad/bmb/docs/workflows/intent-vs-prescriptive-spectrum.md'
|
||||
---
|
||||
|
||||
# Step 5: Intent vs Prescriptive Spectrum Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Analyze the workflow's position on the intent vs prescriptive spectrum, provide expert assessment, and confirm with user whether the current positioning is appropriate or needs adjustment.
|
||||
|
||||
## 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 compliance validator and design philosophy specialist
|
||||
- ✅ If you already have been given a name, communication_style, and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in intent vs prescriptive design principles
|
||||
- ✅ User brings their workflow and needs guidance on spectrum positioning
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on spectrum analysis and user confirmation
|
||||
- 🚫 FORBIDDEN to make spectrum decisions without user input
|
||||
- 💬 Approach: Educational, analytical, and collaborative
|
||||
- 📋 Ensure user understands spectrum implications before confirming
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Analyze workflow's current spectrum position based on all previous findings
|
||||
- 💾 Provide expert assessment with specific examples and reasoning
|
||||
- 📖 Educate user on spectrum implications for their workflow type
|
||||
- 🚫 FORBIDDEN to proceed without user confirmation of spectrum position
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Complete analysis from workflow, step, and file validation phases
|
||||
- Focus: Intent vs prescriptive spectrum analysis and user confirmation
|
||||
- Limits: Spectrum analysis only, holistic workflow analysis comes next
|
||||
- Dependencies: Successful completion of file size and formatting validation
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize Spectrum Analysis
|
||||
|
||||
"Beginning **Intent vs Prescriptive Spectrum Validation**
|
||||
Target: `{target_workflow_name}`
|
||||
|
||||
**Reference Standard:** Analysis based on `{intentSpectrum}`
|
||||
|
||||
This step will help ensure your workflow's approach to LLM guidance is intentional and appropriate for its purpose..."
|
||||
|
||||
### 2. Spectrum Position Analysis
|
||||
|
||||
**A. Current Position Assessment:**
|
||||
Based on analysis of workflow.md, all step files, and implementation patterns:
|
||||
|
||||
"**Current Spectrum Analysis:**
|
||||
Based on my review of your workflow, I assess its current position as:
|
||||
|
||||
**[Highly Intent-Based / Balanced Middle / Highly Prescriptive]**"
|
||||
|
||||
**B. Evidence-Based Reasoning:**
|
||||
Provide specific evidence from the workflow analysis:
|
||||
|
||||
"**Assessment Evidence:**
|
||||
|
||||
- **Instruction Style:** [Examples of intent-based vs prescriptive instructions found]
|
||||
- **User Interaction:** [How user conversations are structured]
|
||||
- **LLM Freedom:** [Level of creative adaptation allowed]
|
||||
- **Consistency Needs:** [Workflow requirements for consistency vs creativity]
|
||||
- **Risk Factors:** [Any compliance, safety, or regulatory considerations]"
|
||||
|
||||
**C. Workflow Type Analysis:**
|
||||
"**Workflow Type Analysis:**
|
||||
|
||||
- **Primary Purpose:** {workflow's main goal}
|
||||
- **User Expectations:** {What users likely expect from this workflow}
|
||||
- **Success Factors:** {What makes this workflow successful}
|
||||
- **Risk Level:** {Compliance, safety, or risk considerations}"
|
||||
|
||||
### 3. Recommended Spectrum Position
|
||||
|
||||
**A. Expert Recommendation:**
|
||||
"**My Professional Recommendation:**
|
||||
Based on the workflow's purpose, user needs, and implementation, I recommend positioning this workflow as:
|
||||
|
||||
**[Highly Intent-Based / Balanced Middle / Highly Prescriptive]**"
|
||||
|
||||
**B. Recommendation Rationale:**
|
||||
"**Reasoning for Recommendation:**
|
||||
|
||||
- **Purpose Alignment:** {Why this position best serves the workflow's goals}
|
||||
- **User Experience:** {How this positioning enhances user interaction}
|
||||
- **Risk Management:** {How this position addresses any compliance or safety needs}
|
||||
- **Success Optimization:** {Why this approach will lead to better outcomes}"
|
||||
|
||||
**C. Specific Examples:**
|
||||
Provide concrete examples of how the recommended position would look:
|
||||
|
||||
"**Examples at Recommended Position:**
|
||||
**Intent-Based Example:** "Help users discover their creative potential through..."
|
||||
**Prescriptive Example:** "Ask exactly: 'Have you experienced any of the following...'"
|
||||
|
||||
**Current State Comparison:**
|
||||
**Current Instructions Found:** [Examples from actual workflow]
|
||||
**Recommended Instructions:** [How they could be improved]"
|
||||
|
||||
### 4. Spectrum Education and Implications
|
||||
|
||||
**A. Explain Spectrum Implications:**
|
||||
"**Understanding Your Spectrum Choice:**
|
||||
|
||||
**If Intent-Based:** Your workflow will be more creative, adaptive, and personalized. Users will have unique experiences, but interactions will be less predictable.
|
||||
|
||||
**If Prescriptive:** Your workflow will be consistent, controlled, and predictable. Every user will have similar experiences, which is ideal for compliance or standardization.
|
||||
|
||||
**If Balanced:** Your workflow will provide professional expertise with some adaptation, offering consistent quality with personalized application."
|
||||
|
||||
**B. Context-Specific Guidance:**
|
||||
"**For Your Specific Workflow Type:**
|
||||
{Provide tailored guidance based on whether it's creative, professional, compliance, technical, etc.}"
|
||||
|
||||
### 5. User Confirmation and Decision
|
||||
|
||||
**A. Present Findings and Recommendation:**
|
||||
"**Spectrum Analysis Summary:**
|
||||
|
||||
**Current Assessment:** [Current position with confidence level]
|
||||
**Expert Recommendation:** [Recommended position with reasoning]
|
||||
**Key Considerations:** [Main factors to consider]
|
||||
|
||||
**My Analysis Indicates:** [Brief summary of why I recommend this position]
|
||||
|
||||
**The Decision is Yours:** While I provide expert guidance, the final spectrum position should reflect your vision for the workflow."
|
||||
|
||||
**B. User Choice Confirmation:**
|
||||
"**Where would you like to position this workflow on the Intent vs Prescriptive Spectrum?**
|
||||
|
||||
**Options:**
|
||||
|
||||
1. **Keep Current Position** - [Current position] - Stay with current approach
|
||||
2. **Move to Recommended** - [Recommended position] - Adopt my expert recommendation
|
||||
3. **Move Toward Intent-Based** - Increase creative freedom and adaptation
|
||||
4. **Move Toward Prescriptive** - Increase consistency and control
|
||||
5. **Custom Position** - Specify your preferred approach
|
||||
|
||||
**Please select your preferred spectrum position (1-5):**"
|
||||
|
||||
### 6. Document Spectrum Decision
|
||||
|
||||
**A. Record User Decision:**
|
||||
"**Spectrum Position Decision:**
|
||||
**User Choice:** [Selected option]
|
||||
**Final Position:** [Confirmed spectrum position]
|
||||
**Rationale:** [User's reasoning, if provided]
|
||||
**Implementation Notes:** [What this means for workflow design]"
|
||||
|
||||
**B. Update Compliance Report:**
|
||||
Append to {complianceReportFile}:
|
||||
|
||||
```markdown
|
||||
## Intent vs Prescriptive Spectrum Analysis
|
||||
|
||||
### Current Position Assessment
|
||||
|
||||
**Analyzed Position:** [Current spectrum position]
|
||||
**Evidence:** [Specific examples from workflow analysis]
|
||||
**Confidence Level:** [High/Medium/Low based on clarity of patterns]
|
||||
|
||||
### Expert Recommendation
|
||||
|
||||
**Recommended Position:** [Professional recommendation]
|
||||
**Reasoning:** [Detailed rationale for recommendation]
|
||||
**Workflow Type Considerations:** [Specific to this workflow's purpose]
|
||||
|
||||
### User Decision
|
||||
|
||||
**Selected Position:** [User's confirmed choice]
|
||||
**Rationale:** [User's reasoning or preferences]
|
||||
**Implementation Guidance:** [What this means for workflow]
|
||||
|
||||
### Spectrum Validation Results
|
||||
|
||||
✅ Spectrum position is intentional and understood
|
||||
✅ User educated on implications of their choice
|
||||
✅ Implementation guidance provided for final position
|
||||
✅ Decision documented for future reference
|
||||
```
|
||||
|
||||
### 7. Continuation Confirmation
|
||||
|
||||
"**Spectrum Validation Complete:**
|
||||
|
||||
- **Final Position:** [Confirmed spectrum position]
|
||||
- **User Understanding:** Confirmed implications and benefits
|
||||
- **Implementation Ready:** Guidance provided for maintaining position
|
||||
|
||||
**Ready for Phase 6:** Web Subprocess Validation analysis
|
||||
|
||||
- Flow validation and completion paths
|
||||
- Goal alignment and optimization assessment
|
||||
- Meta-workflow failure analysis and improvement recommendations
|
||||
|
||||
**Select an Option:** [C] Continue to Web Subprocess Validation [X] Exit"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: Save spectrum decision to report, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF X: Save current spectrum findings and end with guidance for resuming
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [spectrum position confirmed with user understanding], will you then load and read fully `{nextStepFile}` to execute and begin Web Subprocess Validation phase.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Comprehensive spectrum position analysis with evidence-based reasoning
|
||||
- Expert recommendation provided with specific rationale and examples
|
||||
- User educated on spectrum implications for their workflow type
|
||||
- User makes informed decision about spectrum positioning
|
||||
- Spectrum decision documented with implementation guidance
|
||||
- User understands benefits and trade-offs of their choice
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Making spectrum recommendations without analyzing actual workflow content
|
||||
- Not providing evidence-based reasoning for assessment
|
||||
- Failing to educate user on spectrum implications
|
||||
- Proceeding without user confirmation of spectrum position
|
||||
- Not documenting user decision for future reference
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,361 +0,0 @@
|
||||
---
|
||||
name: 'step-06-web-subprocess-validation'
|
||||
description: 'Analyze web search utilization and subprocess optimization opportunities across workflow steps'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-06-web-subprocess-validation.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-07-holistic-analysis.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
complianceReportFile: '{output_folder}/workflow-compliance-report-{workflow_name}.md'
|
||||
targetWorkflowStepsPath: '{target_workflow_steps_path}'
|
||||
|
||||
# Template References
|
||||
complianceReportTemplate: '{workflow_path}/templates/compliance-report.md'
|
||||
|
||||
# Documentation References
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
intentSpectrum: '{project-root}/_bmad/bmb/docs/workflows/intent-vs-prescriptive-spectrum.md'
|
||||
---
|
||||
|
||||
# Step 6: Web Search & Subprocess Optimization Analysis
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Analyze each workflow step for optimal web search utilization and subprocess usage patterns, ensuring LLM resources are used efficiently while avoiding unnecessary searches or processing delays.
|
||||
|
||||
## 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 performance optimization specialist and resource efficiency analyst
|
||||
- ✅ If you already have been given a name, communication_style, and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring expertise in LLM optimization, web search strategy, and subprocess utilization
|
||||
- ✅ User brings their workflow and needs efficiency recommendations
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on web search necessity and subprocess optimization opportunities
|
||||
- 🚫 FORBIDDEN to recommend web searches when LLM knowledge is sufficient
|
||||
- 💬 Approach: Analytical and optimization-focused with clear efficiency rationale
|
||||
- 📋 Use subprocesses when analyzing multiple steps to improve efficiency
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Analyze each step for web search appropriateness vs. LLM knowledge sufficiency
|
||||
- 💾 Identify subprocess optimization opportunities for parallel processing
|
||||
- 📖 Use subprocesses/subagents when analyzing multiple steps for efficiency
|
||||
- 🚫 FORBIDDEN to overlook inefficiencies or recommend unnecessary searches
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: All workflow step files and subprocess availability
|
||||
- Focus: Web search optimization and subprocess utilization analysis
|
||||
- Limits: Resource optimization analysis only, holistic workflow analysis comes next
|
||||
- Dependencies: Completed Intent Spectrum validation from previous phase
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize Web Search & Subprocess Analysis
|
||||
|
||||
"Beginning **Phase 5: Web Search & Subprocess Optimization Analysis**
|
||||
Target: `{target_workflow_name}`
|
||||
|
||||
Analyzing each workflow step for:
|
||||
|
||||
- Appropriate web search utilization vs. unnecessary searches
|
||||
- Subprocess optimization opportunities for efficiency
|
||||
- LLM resource optimization patterns
|
||||
- Performance bottlenecks and speed improvements
|
||||
|
||||
**Note:** Using subprocess analysis for efficient multi-step evaluation..."
|
||||
|
||||
### 2. Web Search Necessity Analysis
|
||||
|
||||
**A. Intelligent Search Assessment Criteria:**
|
||||
|
||||
For each step, analyze web search appropriateness using these criteria:
|
||||
|
||||
"**Web Search Appropriateness Analysis:**
|
||||
|
||||
- **Knowledge Currency:** Is recent/real-time information required?
|
||||
- **Specific Data Needs:** Are there specific facts/data not in LLM training?
|
||||
- **Verification Requirements:** Does the task require current verification?
|
||||
- **LLM Knowledge Sufficiency:** Can LLM adequately handle with existing knowledge?
|
||||
- **Search Cost vs. Benefit:** Is search time worth the information gain?"
|
||||
|
||||
**B. Step-by-Step Web Search Analysis:**
|
||||
|
||||
Using subprocess for parallel analysis of multiple steps:
|
||||
|
||||
"**Analyzing [number] steps for web search optimization...**"
|
||||
|
||||
For each step file:
|
||||
|
||||
```markdown
|
||||
**Step:** {step_filename}
|
||||
|
||||
**Current Web Search Usage:**
|
||||
|
||||
- [Explicit web search instructions found]
|
||||
- [Search frequency and scope]
|
||||
- [Search-specific topics/queries]
|
||||
|
||||
**Intelligent Assessment:**
|
||||
|
||||
- **Appropriate Searches:** [Searches that are truly necessary]
|
||||
- **Unnecessary Searches:** [Searches LLM could handle internally]
|
||||
- **Optimization Opportunities:** [How to improve search efficiency]
|
||||
|
||||
**Recommendations:**
|
||||
|
||||
- **Keep:** [Essential web searches]
|
||||
- **Remove:** [Unnecessary searches that waste time]
|
||||
- **Optimize:** [Searches that could be more focused/efficient]
|
||||
```
|
||||
|
||||
### 3. Subprocess & Parallel Processing Analysis
|
||||
|
||||
**A. Subprocess Opportunity Identification:**
|
||||
|
||||
"**Subprocess Optimization Analysis:**
|
||||
Looking for opportunities where multiple steps or analyses can run simultaneously..."
|
||||
|
||||
**Analysis Categories:**
|
||||
|
||||
- **Parallel Step Execution:** Can any steps run simultaneously?
|
||||
- **Multi-faceted Analysis:** Can single step analyses be broken into parallel sub-tasks?
|
||||
- **Batch Processing:** Can similar operations be grouped for efficiency?
|
||||
- **Background Processing:** Can any analyses run while user interacts?
|
||||
|
||||
**B. Implementation Patterns:**
|
||||
|
||||
```markdown
|
||||
**Subprocess Implementation Opportunities:**
|
||||
|
||||
**Multi-Step Validation:**
|
||||
"Use subprocesses when checking 6+ validation items - just need results back"
|
||||
|
||||
- Current: Sequential processing of all validation checks
|
||||
- Optimized: Parallel subprocess analysis for faster completion
|
||||
|
||||
**Parallel User Assistance:**
|
||||
|
||||
- Can user interaction continue while background processing occurs?
|
||||
- Can multiple analyses run simultaneously during user wait times?
|
||||
|
||||
**Batch Operations:**
|
||||
|
||||
- Can similar file operations be grouped?
|
||||
- Can multiple data sources be processed in parallel?
|
||||
```
|
||||
|
||||
### 4. LLM Resource Optimization Analysis
|
||||
|
||||
**A. Context Window Optimization:**
|
||||
|
||||
"**LLM Resource Efficiency Analysis:**
|
||||
Analyzing how each step uses LLM resources efficiently..."
|
||||
|
||||
**Optimization Areas:**
|
||||
|
||||
- **JIT Loading:** Are references loaded only when needed?
|
||||
- **Context Management:** Is context used efficiently vs. wasted?
|
||||
- **Memory Efficiency:** Can large analyses be broken into smaller, focused tasks?
|
||||
- **Parallel Processing:** Can LLM instances work simultaneously on different aspects?
|
||||
|
||||
**B. Speed vs. Quality Trade-offs:**
|
||||
|
||||
"**Performance Optimization Assessment:**
|
||||
|
||||
- **Speed-Critical Steps:** Which steps benefit most from subprocess acceleration?
|
||||
- **Quality-Critical Steps:** Which steps need focused LLM attention?
|
||||
- **Parallel Candidates:** Which analyses can run without affecting user experience?
|
||||
- **Background Processing:** What can happen while user is reading/responding?"
|
||||
|
||||
### 5. Step-by-Step Optimization Recommendations
|
||||
|
||||
**A. Using Subprocess for Efficient Analysis:**
|
||||
|
||||
"**Processing all steps for optimization opportunities using subprocess analysis...**"
|
||||
|
||||
**For each workflow step, analyze:**
|
||||
|
||||
**1. Web Search Optimization:**
|
||||
|
||||
```markdown
|
||||
**Step:** {step_name}
|
||||
**Current Search Usage:** {current_search_instructions}
|
||||
**Intelligent Assessment:** {is_search_necessary}
|
||||
**Recommendation:**
|
||||
|
||||
- **Keep essential searches:** {specific_searches_to_keep}
|
||||
- **Remove unnecessary searches:** {searches_to_remove}
|
||||
- **Optimize search queries:** {improved_search_approach}
|
||||
```
|
||||
|
||||
**2. Subprocess Opportunities:**
|
||||
|
||||
```markdown
|
||||
**Parallel Processing Potential:**
|
||||
|
||||
- **Can run with user interaction:** {yes/no_specifics}
|
||||
- **Can batch with other steps:** {opportunities}
|
||||
- **Can break into sub-tasks:** {subtask_breakdown}
|
||||
- **Background processing:** {what_can_run_in_background}
|
||||
```
|
||||
|
||||
**3. LLM Efficiency:**
|
||||
|
||||
```markdown
|
||||
**Resource Optimization:**
|
||||
|
||||
- **Context efficiency:** {current_vs_optimal}
|
||||
- **Processing time:** {estimated_improvements}
|
||||
- **User experience impact:** {better/same/worse}
|
||||
```
|
||||
|
||||
### 6. Aggregate Optimization Analysis
|
||||
|
||||
**A. Web Search Optimization Summary:**
|
||||
|
||||
"**Web Search Optimization Results:**
|
||||
|
||||
- **Total Steps Analyzed:** [number]
|
||||
- **Steps with Web Searches:** [number]
|
||||
- **Unnecessary Searches Found:** [number]
|
||||
- **Optimization Opportunities:** [number]
|
||||
- **Estimated Time Savings:** [time_estimate]"
|
||||
|
||||
**B. Subprocess Implementation Summary:**
|
||||
|
||||
"**Subprocess Optimization Results:**
|
||||
|
||||
- **Parallel Processing Opportunities:** [number]
|
||||
- **Batch Processing Groups:** [number]
|
||||
- **Background Processing Tasks:** [number]
|
||||
- **Estimated Performance Improvement:** [percentage_improvement]"
|
||||
|
||||
### 7. User-Facing Optimization Report
|
||||
|
||||
**A. Key Efficiency Findings:**
|
||||
|
||||
"**Optimization Analysis Summary:**
|
||||
|
||||
**Web Search Efficiency:**
|
||||
|
||||
- **Current Issues:** [unnecessary searches wasting time]
|
||||
- **Recommendations:** [specific improvements]
|
||||
- **Expected Benefits:** [faster response, better user experience]
|
||||
|
||||
**Processing Speed Improvements:**
|
||||
|
||||
- **Parallel Processing Gains:** [specific opportunities]
|
||||
- **Background Processing Benefits:** [user experience improvements]
|
||||
- **Resource Optimization:** [LLM efficiency gains]
|
||||
|
||||
**Implementation Priority:**
|
||||
|
||||
1. **High Impact, Low Effort:** [Quick wins]
|
||||
2. **High Impact, High Effort:** [Major improvements]
|
||||
3. **Low Impact, Low Effort:** [Fine-tuning]
|
||||
4. **Future Considerations:** [Advanced optimizations]"
|
||||
|
||||
### 8. Document Optimization Findings
|
||||
|
||||
Append to {complianceReportFile}:
|
||||
|
||||
```markdown
|
||||
## Web Search & Subprocess Optimization Analysis
|
||||
|
||||
### Web Search Optimization
|
||||
|
||||
**Unnecessary Searches Identified:** [number]
|
||||
**Essential Searches to Keep:** [specific_list]
|
||||
**Optimization Recommendations:** [detailed_suggestions]
|
||||
**Estimated Time Savings:** [time_improvement]
|
||||
|
||||
### Subprocess Optimization Opportunities
|
||||
|
||||
**Parallel Processing:** [number] opportunities identified
|
||||
**Batch Processing:** [number] grouping opportunities
|
||||
**Background Processing:** [number] background task opportunities
|
||||
**Performance Improvement:** [estimated_improvement_percentage]%
|
||||
|
||||
### Resource Efficiency Analysis
|
||||
|
||||
**Context Optimization:** [specific_improvements]
|
||||
**LLM Resource Usage:** [efficiency_gains]
|
||||
**User Experience Impact:** [positive_changes]
|
||||
|
||||
### Implementation Recommendations
|
||||
|
||||
**Immediate Actions:** [quick_improvements]
|
||||
**Strategic Improvements:** [major_optimizations]
|
||||
**Future Enhancements:** [advanced_optimizations]
|
||||
```
|
||||
|
||||
### 9. Continuation Confirmation
|
||||
|
||||
"**Web Search & Subprocess Analysis Complete:**
|
||||
|
||||
- **Web Search Optimization:** [summary of improvements]
|
||||
- **Subprocess Opportunities:** [number of optimization areas]
|
||||
- **Performance Impact:** [expected efficiency gains]
|
||||
- **User Experience Benefits:** [specific improvements]
|
||||
|
||||
**Ready for Phase 7:** Holistic workflow analysis
|
||||
|
||||
- Flow validation and completion paths
|
||||
- Goal alignment with optimized resources
|
||||
- Meta-workflow failure analysis
|
||||
- Strategic recommendations with efficiency considerations
|
||||
|
||||
**Select an Option:** [C] Continue to Holistic Analysis [X] Exit"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: Save optimization findings to report, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF X: Save current findings and end with guidance for resuming
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [web search and subprocess analysis complete with optimization recommendations documented], will you then load and read fully `{nextStepFile}` to execute and begin holistic analysis phase.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Intelligent assessment of web search necessity vs. LLM knowledge sufficiency
|
||||
- Identification of unnecessary web searches that waste user time
|
||||
- Discovery of subprocess optimization opportunities for parallel processing
|
||||
- Analysis of LLM resource efficiency patterns
|
||||
- Specific, actionable optimization recommendations provided
|
||||
- Performance impact assessment with estimated improvements
|
||||
- User experience benefits clearly articulated
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Recommending web searches when LLM knowledge is sufficient
|
||||
- Missing subprocess optimization opportunities
|
||||
- Not using subprocess analysis when evaluating multiple steps
|
||||
- Overlooking LLM resource inefficiencies
|
||||
- Providing vague or non-actionable optimization recommendations
|
||||
- Failing to assess impact on user experience
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,259 +0,0 @@
|
||||
---
|
||||
name: 'step-07-holistic-analysis'
|
||||
description: 'Analyze workflow flow, goal alignment, and meta-workflow failures'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-07-holistic-analysis.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-08-generate-report.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
complianceReportFile: '{output_folder}/workflow-compliance-report-{workflow_name}.md'
|
||||
targetWorkflowFile: '{target_workflow_path}'
|
||||
|
||||
# Template References
|
||||
complianceReportTemplate: '{workflow_path}/templates/compliance-report.md'
|
||||
|
||||
# Documentation References
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
intentSpectrum: '{project-root}/_bmad/bmb/docs/workflows/intent-vs-prescriptive-spectrum.md'
|
||||
---
|
||||
|
||||
# Step 7: Holistic Workflow Analysis
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Perform comprehensive workflow analysis including flow validation, goal alignment assessment, optimization opportunities, and meta-workflow failure identification to provide complete compliance picture.
|
||||
|
||||
## 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 compliance validator and quality assurance specialist
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring holistic workflow analysis and optimization expertise
|
||||
- ✅ User brings their workflow and needs comprehensive assessment
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus on holistic analysis beyond template compliance
|
||||
- 🚫 FORBIDDEN to skip flow validation or optimization assessment
|
||||
- 💬 Approach: Systematic end-to-end workflow analysis
|
||||
- 📋 Identify meta-workflow failures and improvement opportunities
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Analyze complete workflow flow from start to finish
|
||||
- 💾 Validate goal alignment and optimization opportunities
|
||||
- 📖 Identify what meta-workflows (create/edit) should have caught
|
||||
- 🚫 FORBIDDEN to provide superficial analysis without specific recommendations
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Complete workflow analysis from previous phases
|
||||
- Focus: Holistic workflow optimization and meta-process improvement
|
||||
- Limits: Analysis phase only, report generation comes next
|
||||
- Dependencies: Completed workflow.md and step validation phases
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize Holistic Analysis
|
||||
|
||||
"Beginning **Phase 3: Holistic Workflow Analysis**
|
||||
Target: `{target_workflow_name}`
|
||||
|
||||
Analyzing workflow from multiple perspectives:
|
||||
|
||||
- Flow and completion validation
|
||||
- Goal alignment assessment
|
||||
- Optimization opportunities
|
||||
- Meta-workflow failure analysis..."
|
||||
|
||||
### 2. Workflow Flow Validation
|
||||
|
||||
**A. Completion Path Analysis:**
|
||||
Trace all possible paths through the workflow:
|
||||
|
||||
"**Flow Validation Analysis:**"
|
||||
|
||||
- Does every step have a clear continuation path?
|
||||
- Do all menu options have valid destinations?
|
||||
- Are there any orphaned steps or dead ends?
|
||||
- Can the workflow always reach a successful completion?
|
||||
|
||||
**Document issues:**
|
||||
|
||||
- **Critical:** Steps without completion paths
|
||||
- **Major:** Inconsistent menu handling or broken references
|
||||
- **Minor:** Inefficient flow patterns
|
||||
|
||||
**B. Sequential Logic Validation:**
|
||||
Check step sequence logic:
|
||||
|
||||
- Does step order make logical sense?
|
||||
- Are dependencies properly structured?
|
||||
- Is information flow between steps optimal?
|
||||
- Are there unnecessary steps or missing functionality?
|
||||
|
||||
### 3. Goal Alignment Assessment
|
||||
|
||||
**A. Stated Goal Analysis:**
|
||||
Compare workflow.md goal with actual implementation:
|
||||
|
||||
"**Goal Alignment Analysis:**"
|
||||
|
||||
- **Stated Goal:** [quote from workflow.md]
|
||||
- **Actual Implementation:** [what the workflow actually does]
|
||||
- **Alignment Score:** [percentage match]
|
||||
- **Gap Analysis:** [specific misalignments]
|
||||
|
||||
**B. User Experience Assessment:**
|
||||
Evaluate workflow from user perspective:
|
||||
|
||||
- Is the workflow intuitive and easy to follow?
|
||||
- Are user inputs appropriately requested?
|
||||
- Is feedback clear and timely?
|
||||
- Is the workflow efficient for the stated purpose?
|
||||
|
||||
### 4. Optimization Opportunities
|
||||
|
||||
**A. Efficiency Analysis:**
|
||||
"**Optimization Assessment:**"
|
||||
|
||||
- **Step Consolidation:** Could any steps be combined?
|
||||
- **Parallel Processing:** Could any operations run simultaneously?
|
||||
- **JIT Loading:** Are references loaded optimally?
|
||||
- **User Experience:** Where could user experience be improved?
|
||||
|
||||
**B. Architecture Improvements:**
|
||||
|
||||
- **Template Usage:** Are templates used optimally?
|
||||
- **Output Management:** Are outputs appropriate and necessary?
|
||||
- **Error Handling:** Is error handling comprehensive?
|
||||
- **Extensibility:** Can the workflow be easily extended?
|
||||
|
||||
### 5. Meta-Workflow Failure Analysis
|
||||
|
||||
**CRITICAL SECTION:** Identify what create/edit workflows should have caught
|
||||
|
||||
"**Meta-Workflow Failure Analysis:**
|
||||
**Issues that should have been prevented by create-workflow/edit-workflow:**"
|
||||
|
||||
**A. Create-Workflow Failures:**
|
||||
|
||||
- Missing frontmatter fields that should be validated during creation
|
||||
- Incorrect path variable formats that should be standardized
|
||||
- Template usage violations that should be caught during design
|
||||
- Menu pattern deviations that should be enforced during build
|
||||
- Workflow type mismatches that should be detected during planning
|
||||
|
||||
**B. Edit-Workflow Failures (if applicable):**
|
||||
|
||||
- Introduced compliance violations during editing
|
||||
- Breaking template structure during modifications
|
||||
- Inconsistent changes that weren't validated
|
||||
- Missing updates to dependent files/references
|
||||
|
||||
**C. Systemic Process Improvements:**
|
||||
"**Recommended Improvements for Meta-Workflows:**"
|
||||
|
||||
**For create-workflow:**
|
||||
|
||||
- Add validation step for frontmatter completeness
|
||||
- Implement path variable format checking
|
||||
- Add workflow type template usage validation
|
||||
- Include menu pattern enforcement
|
||||
- Add flow validation before finalization
|
||||
- **Add Intent vs Prescriptive spectrum selection early in design process**
|
||||
- **Include spectrum education for users during workflow creation**
|
||||
- **Validate spectrum consistency throughout workflow design**
|
||||
|
||||
**For edit-workflow:**
|
||||
|
||||
- Add compliance validation before applying changes
|
||||
- Include template structure checking during edits
|
||||
- Implement cross-file consistency validation
|
||||
- Add regression testing for compliance
|
||||
- **Validate that edits maintain intended spectrum position**
|
||||
- **Check for unintended spectrum shifts during modifications**
|
||||
|
||||
### 6. Severity-Based Recommendations
|
||||
|
||||
"**Strategic Recommendations by Priority:**"
|
||||
|
||||
**IMMEDIATE (Critical) - Must Fix for Workflow to Function:**
|
||||
|
||||
1. [Most critical issue with specific fix]
|
||||
2. [Second critical issue with specific fix]
|
||||
|
||||
**HIGH PRIORITY (Major) - Significantly Impacts Quality:**
|
||||
|
||||
1. [Major issue affecting maintainability]
|
||||
2. [Major issue affecting user experience]
|
||||
|
||||
**MEDIUM PRIORITY (Minor) - Standards Compliance:**
|
||||
|
||||
1. [Minor template compliance issue]
|
||||
2. [Cosmetic or consistency improvements]
|
||||
|
||||
### 7. Continuation Confirmation
|
||||
|
||||
"**Phase 5 Complete:** Holistic analysis finished
|
||||
|
||||
- **Flow Validation:** [summary findings]
|
||||
- **Goal Alignment:** [alignment percentage and key gaps]
|
||||
- **Optimization Opportunities:** [number key improvements identified]
|
||||
- **Meta-Workflow Failures:** [number issues that should have been prevented]
|
||||
|
||||
**Ready for Phase 8:** Comprehensive compliance report generation
|
||||
|
||||
- All findings compiled into structured report
|
||||
- Severity-ranked violation list
|
||||
- Specific fix recommendations
|
||||
- Meta-workflow improvement suggestions
|
||||
|
||||
**Select an Option:** [C] Continue to Report Generation [X] Exit"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF C: Save holistic analysis findings to report, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF X: Save current findings and end with guidance for resuming
|
||||
- IF Any other comments or queries: respond and redisplay menu
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
ONLY WHEN [C continue option] is selected and [holistic analysis complete with meta-workflow failures identified], will you then load and read fully `{nextStepFile}` to execute and begin comprehensive report generation.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Complete workflow flow validation with all paths traced
|
||||
- Goal alignment assessment with specific gap analysis
|
||||
- Optimization opportunities identified with prioritized recommendations
|
||||
- Meta-workflow failures documented with improvement suggestions
|
||||
- Strategic recommendations provided by severity priority
|
||||
- User ready for comprehensive report generation
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Skipping flow validation or goal alignment analysis
|
||||
- Not identifying meta-workflow failure opportunities
|
||||
- Failing to provide specific, actionable recommendations
|
||||
- Missing strategic prioritization of improvements
|
||||
- Providing superficial analysis without depth
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,302 +0,0 @@
|
||||
---
|
||||
name: 'step-08-generate-report'
|
||||
description: 'Generate comprehensive compliance report with fix recommendations'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/workflows/workflow-compliance-check'
|
||||
|
||||
# File References
|
||||
thisStepFile: '{workflow_path}/steps/step-08-generate-report.md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
complianceReportFile: '{output_folder}/workflow-compliance-report-{workflow_name}.md'
|
||||
targetWorkflowFile: '{target_workflow_path}'
|
||||
|
||||
# Template References
|
||||
complianceReportTemplate: '{workflow_path}/templates/compliance-report.md'
|
||||
|
||||
# Documentation References
|
||||
stepTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/step-template.md'
|
||||
workflowTemplate: '{project-root}/_bmad/bmb/docs/workflows/templates/workflow-template.md'
|
||||
---
|
||||
|
||||
# Step 8: Comprehensive Compliance Report Generation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
Generate comprehensive compliance report compiling all validation findings, provide severity-ranked fix recommendations, and offer concrete next steps for achieving full compliance.
|
||||
|
||||
## 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 compliance validator and quality assurance specialist
|
||||
- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring report generation and strategic recommendation expertise
|
||||
- ✅ User brings their validated workflow and needs actionable improvement plan
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Focus only on compiling comprehensive compliance report
|
||||
- 🚫 FORBIDDEN to generate report without including all findings from previous phases
|
||||
- 💬 Approach: Systematic compilation with clear, actionable recommendations
|
||||
- 📋 Ensure report is complete, accurate, and immediately useful
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Compile all findings from previous validation phases
|
||||
- 💾 Generate structured compliance report with clear sections
|
||||
- 📖 Provide severity-ranked recommendations with specific fixes
|
||||
- 🚫 FORBIDDEN to overlook any validation findings or recommendations
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Available context: Complete validation findings from all previous phases
|
||||
- Focus: Comprehensive report generation and strategic recommendations
|
||||
- Limits: Report generation only, no additional validation
|
||||
- Dependencies: Successful completion of all previous validation phases
|
||||
|
||||
## Sequence of Instructions (Do not deviate, skip, or optimize)
|
||||
|
||||
### 1. Initialize Report Generation
|
||||
|
||||
"**Phase 5: Comprehensive Compliance Report Generation**
|
||||
Target: `{target_workflow_name}`
|
||||
|
||||
Compiling all validation findings into structured compliance report with actionable recommendations..."
|
||||
|
||||
### 2. Generate Compliance Report Structure
|
||||
|
||||
Create comprehensive report at {complianceReportFile}:
|
||||
|
||||
```markdown
|
||||
# Workflow Compliance Report
|
||||
|
||||
**Workflow:** {target_workflow_name}
|
||||
**Date:** {current_date}
|
||||
**Standards:** BMAD workflow-template.md and step-template.md
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
**Overall Compliance Status:** [PASS/FAIL/PARTIAL]
|
||||
**Critical Issues:** [number] - Must be fixed immediately
|
||||
**Major Issues:** [number] - Significantly impacts quality/maintainability
|
||||
**Minor Issues:** [number] - Standards compliance improvements
|
||||
|
||||
**Compliance Score:** [percentage]% based on template adherence
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Workflow.md Validation Results
|
||||
|
||||
### Critical Violations
|
||||
|
||||
[Critical issues with template references and specific fixes]
|
||||
|
||||
### Major Violations
|
||||
|
||||
[Major issues with template references and specific fixes]
|
||||
|
||||
### Minor Violations
|
||||
|
||||
[Minor issues with template references and specific fixes]
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Step-by-Step Validation Results
|
||||
|
||||
### Summary by Step
|
||||
|
||||
[Each step file with its violation summary]
|
||||
|
||||
### Most Common Violations
|
||||
|
||||
1. [Most frequent violation type with count]
|
||||
2. [Second most frequent with count]
|
||||
3. [Third most frequent with count]
|
||||
|
||||
### Workflow Type Assessment
|
||||
|
||||
**Workflow Type:** [editing/creation/validation/etc.]
|
||||
**Template Appropriateness:** [appropriate/needs improvement]
|
||||
**Recommendations:** [specific suggestions]
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Holistic Analysis Results
|
||||
|
||||
### Flow Validation
|
||||
|
||||
[Flow analysis findings with specific issues]
|
||||
|
||||
### Goal Alignment
|
||||
|
||||
**Alignment Score:** [percentage]%
|
||||
**Stated vs. Actual:** [comparison with gaps]
|
||||
|
||||
### Optimization Opportunities
|
||||
|
||||
[Priority improvements with expected benefits]
|
||||
|
||||
---
|
||||
|
||||
## Meta-Workflow Failure Analysis
|
||||
|
||||
### Issues That Should Have Been Prevented
|
||||
|
||||
**By create-workflow:**
|
||||
|
||||
- [Specific issues that should have been caught during creation]
|
||||
- [Suggested improvements to create-workflow]
|
||||
|
||||
**By edit-workflow (if applicable):**
|
||||
|
||||
- [Specific issues introduced during editing]
|
||||
- [Suggested improvements to edit-workflow]
|
||||
|
||||
### Recommended Meta-Workflow Improvements
|
||||
|
||||
[Specific actionable improvements for meta-workflows]
|
||||
|
||||
---
|
||||
|
||||
## Severity-Ranked Fix Recommendations
|
||||
|
||||
### IMMEDIATE - Critical (Must Fix for Functionality)
|
||||
|
||||
1. **[Issue Title]** - [File: filename.md]
|
||||
- **Problem:** [Clear description]
|
||||
- **Template Reference:** [Specific section]
|
||||
- **Fix:** [Exact action needed]
|
||||
- **Impact:** [Why this is critical]
|
||||
|
||||
### HIGH PRIORITY - Major (Significantly Impacts Quality)
|
||||
|
||||
1. **[Issue Title]** - [File: filename.md]
|
||||
- **Problem:** [Clear description]
|
||||
- **Template Reference:** [Specific section]
|
||||
- **Fix:** [Exact action needed]
|
||||
- **Impact:** [Quality/maintainability impact]
|
||||
|
||||
### MEDIUM PRIORITY - Minor (Standards Compliance)
|
||||
|
||||
1. **[Issue Title]** - [File: filename.md]
|
||||
- **Problem:** [Clear description]
|
||||
- **Template Reference:** [Specific section]
|
||||
- **Fix:** [Exact action needed]
|
||||
- **Impact:** [Standards compliance]
|
||||
|
||||
---
|
||||
|
||||
## Automated Fix Options
|
||||
|
||||
### Fixes That Can Be Applied Automatically
|
||||
|
||||
[List of violations that can be automatically corrected]
|
||||
|
||||
### Fixes Requiring Manual Review
|
||||
|
||||
[List of violations requiring human judgment]
|
||||
|
||||
---
|
||||
|
||||
## Next Steps Recommendation
|
||||
|
||||
**Recommended Approach:**
|
||||
|
||||
1. Fix all Critical issues immediately (workflow may not function)
|
||||
2. Address Major issues for reliability and maintainability
|
||||
3. Implement Minor issues for full standards compliance
|
||||
4. Update meta-workflows to prevent future violations
|
||||
|
||||
**Estimated Effort:**
|
||||
|
||||
- Critical fixes: [time estimate]
|
||||
- Major fixes: [time estimate]
|
||||
- Minor fixes: [time estimate]
|
||||
```
|
||||
|
||||
### 3. Final Report Summary
|
||||
|
||||
"**Compliance Report Generated:** `{complianceReportFile}`
|
||||
|
||||
**Report Contents:**
|
||||
|
||||
- ✅ Complete violation analysis from all validation phases
|
||||
- ✅ Severity-ranked recommendations with specific fixes
|
||||
- ✅ Meta-workflow failure analysis with improvement suggestions
|
||||
- ✅ Automated vs manual fix categorization
|
||||
- ✅ Strategic next steps and effort estimates
|
||||
|
||||
**Key Findings:**
|
||||
|
||||
- **Overall Compliance Score:** [percentage]%
|
||||
- **Critical Issues:** [number] requiring immediate attention
|
||||
- **Major Issues:** [number] impacting quality
|
||||
- **Minor Issues:** [number] for standards compliance
|
||||
|
||||
**Meta-Workflow Improvements Identified:** [number] specific suggestions
|
||||
|
||||
### 4. Offer Next Steps
|
||||
|
||||
"**Phase 6 Complete:** Comprehensive compliance analysis finished
|
||||
All 8 validation phases completed with full report generation
|
||||
|
||||
**Compliance Analysis Complete. What would you like to do next?**"
|
||||
|
||||
**Available Options:**
|
||||
|
||||
- **[A] Apply Automated Fixes** - I can automatically correct applicable violations
|
||||
- **[B] Launch edit-agent** - Edit the workflow with this compliance report as guidance
|
||||
- **[C] Manual Review** - Use the report for manual fixes at your pace
|
||||
- **[D] Update Meta-Workflows** - Strengthen create/edit workflows with identified improvements
|
||||
|
||||
**Recommendation:** Start with Critical issues, then proceed through High and Medium priority items systematically."
|
||||
|
||||
### 5. Report Completion Options
|
||||
|
||||
Display: "**Select an Option:** [A] Apply Automated Fixes [B] Launch Edit-Agent [C] Manual Review [D] Update Meta-Workflows [X] Exit"
|
||||
|
||||
## Menu Handling Logic:
|
||||
|
||||
- IF A: Begin applying automated fixes from the report
|
||||
- IF B: Launch edit-agent workflow with this compliance report as context
|
||||
- IF C: End workflow with guidance for manual review using the report
|
||||
- IF D: Provide specific recommendations for meta-workflow improvements
|
||||
- IF X: Save report and end workflow gracefully
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
The workflow is complete when the comprehensive compliance report has been generated and the user has selected their preferred next step. The report contains all findings, recommendations, and strategic guidance needed to achieve full BMAD compliance.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Comprehensive compliance report generated with all validation findings
|
||||
- Severity-ranked fix recommendations provided with specific actions
|
||||
- Meta-workflow failure analysis completed with improvement suggestions
|
||||
- Clear next steps offered based on user preferences
|
||||
- Report saved and accessible for future reference
|
||||
- User has actionable plan for achieving full compliance
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Generating incomplete report without all validation findings
|
||||
- Missing severity rankings or specific fix recommendations
|
||||
- Not providing clear next steps or options
|
||||
- Failing to include meta-workflow improvement suggestions
|
||||
- Creating report that is not immediately actionable
|
||||
|
||||
**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.
|
||||
@@ -1,140 +0,0 @@
|
||||
# Workflow Compliance Report Template
|
||||
|
||||
**Workflow:** {workflow_name}
|
||||
**Date:** {validation_date}
|
||||
**Standards:** BMAD workflow-template.md and step-template.md
|
||||
**Report Type:** Comprehensive Compliance Validation
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
**Overall Compliance Status:** {compliance_status}
|
||||
**Critical Issues:** {critical_count} - Must be fixed immediately
|
||||
**Major Issues:** {major_count} - Significantly impacts quality/maintainability
|
||||
**Minor Issues:** {minor_count} - Standards compliance improvements
|
||||
|
||||
**Compliance Score:** {compliance_score}% based on template adherence
|
||||
|
||||
**Workflow Type Assessment:** {workflow_type} - {type_appropriateness}
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Workflow.md Validation Results
|
||||
|
||||
### Template Adherence Analysis
|
||||
|
||||
**Reference Standard:** {workflow_template_path}
|
||||
|
||||
### Critical Violations
|
||||
|
||||
{critical_violations}
|
||||
|
||||
### Major Violations
|
||||
|
||||
{major_violations}
|
||||
|
||||
### Minor Violations
|
||||
|
||||
{minor_violations}
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Step-by-Step Validation Results
|
||||
|
||||
### Summary by Step
|
||||
|
||||
{step_validation_summary}
|
||||
|
||||
### Most Common Violations
|
||||
|
||||
1. {most_common_violation_1}
|
||||
2. {most_common_violation_2}
|
||||
3. {most_common_violation_3}
|
||||
|
||||
### Workflow Type Appropriateness
|
||||
|
||||
**Analysis:** {workflow_type_analysis}
|
||||
**Recommendations:** {type_recommendations}
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: Holistic Analysis Results
|
||||
|
||||
### Flow Validation
|
||||
|
||||
{flow_validation_results}
|
||||
|
||||
### Goal Alignment
|
||||
|
||||
**Stated Goal:** {stated_goal}
|
||||
**Actual Implementation:** {actual_implementation}
|
||||
**Alignment Score:** {alignment_score}%
|
||||
**Gap Analysis:** {gap_analysis}
|
||||
|
||||
### Optimization Opportunities
|
||||
|
||||
{optimization_opportunities}
|
||||
|
||||
---
|
||||
|
||||
## Meta-Workflow Failure Analysis
|
||||
|
||||
### Issues That Should Have Been Prevented
|
||||
|
||||
**By create-workflow:**
|
||||
{create_workflow_failures}
|
||||
|
||||
**By edit-workflow:**
|
||||
{edit_workflow_failures}
|
||||
|
||||
### Recommended Meta-Workflow Improvements
|
||||
|
||||
{meta_workflow_improvements}
|
||||
|
||||
---
|
||||
|
||||
## Severity-Ranked Fix Recommendations
|
||||
|
||||
### IMMEDIATE - Critical (Must Fix for Functionality)
|
||||
|
||||
{critical_recommendations}
|
||||
|
||||
### HIGH PRIORITY - Major (Significantly Impacts Quality)
|
||||
|
||||
{major_recommendations}
|
||||
|
||||
### MEDIUM PRIORITY - Minor (Standards Compliance)
|
||||
|
||||
{minor_recommendations}
|
||||
|
||||
---
|
||||
|
||||
## Automated Fix Options
|
||||
|
||||
### Fixes That Can Be Applied Automatically
|
||||
|
||||
{automated_fixes}
|
||||
|
||||
### Fixes Requiring Manual Review
|
||||
|
||||
{manual_fixes}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps Recommendation
|
||||
|
||||
**Recommended Approach:**
|
||||
{recommended_approach}
|
||||
|
||||
**Estimated Effort:**
|
||||
|
||||
- Critical fixes: {critical_effort}
|
||||
- Major fixes: {major_effort}
|
||||
- Minor fixes: {minor_effort}
|
||||
|
||||
---
|
||||
|
||||
**Report Generated:** {timestamp}
|
||||
**Validation Engine:** BMAD Workflow Compliance Checker
|
||||
**Next Review Date:** {next_review_date}
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
name: workflow-compliance-check
|
||||
description: Systematic validation of workflows against BMAD standards with adversarial analysis and detailed reporting
|
||||
web_bundle: false
|
||||
---
|
||||
|
||||
# Workflow Compliance Check
|
||||
|
||||
**Goal:** Systematically validate workflows against BMAD standards through adversarial analysis, generating detailed compliance reports with severity-ranked violations and improvement recommendations.
|
||||
|
||||
**Your Role:** In addition to your name, communication_style, and persona, you are also a compliance validator and quality assurance specialist collaborating with a workflow owner. This is a partnership, not a client-vendor relationship. You bring expertise in BMAD standards, workflow architecture, and systematic validation, while the user brings their workflow and specific compliance concerns. 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 context for compliance checking (no output file frontmatter needed)
|
||||
- **Append-Only Building**: Build compliance reports 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/bmb/config.yaml and resolve:
|
||||
|
||||
- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
### 2. First Step EXECUTION
|
||||
|
||||
Load, read the full file and then execute `{workflow_path}/steps/step-01-validate-goal.md` to begin the workflow. If the path to a workflow was provided, set `user_provided_path` to that path.
|
||||
152
src/modules/bmb/workflows/workflow/data/architecture.md
Normal file
152
src/modules/bmb/workflows/workflow/data/architecture.md
Normal file
@@ -0,0 +1,152 @@
|
||||
# Workflow Architecture
|
||||
|
||||
**Purpose:** Core structural patterns for BMAD workflows.
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
```
|
||||
workflow-folder/
|
||||
├── workflow.md # Entry point, configuration
|
||||
├── steps-c/ # Create flow steps
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-02-[name].md
|
||||
│ └── step-N-[name].md
|
||||
├── steps-e/ # Edit flow (if needed)
|
||||
├── steps-v/ # Validate flow (if needed)
|
||||
├── data/ # Shared reference files
|
||||
└── templates/ # Output templates (if needed)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## workflow.md File Standards
|
||||
|
||||
**CRITICAL:** The workflow.md file MUST be lean. It is the entry point and should NOT contain:
|
||||
|
||||
- ❌ **Listing of all steps** - This defeats progressive disclosure
|
||||
- ❌ **Detailed descriptions of what each step does** - Steps are self-documenting
|
||||
- ❌ **Validation checklists** - These belong in steps-v/, not workflow.md
|
||||
- ❌ **Implementation details** - These belong in step files
|
||||
|
||||
**The workflow.md SHOULD contain:**
|
||||
- ✅ Frontmatter: name, description, web_bundle
|
||||
- ✅ Goal: What the workflow accomplishes
|
||||
- ✅ Role: Who the AI embodies when running this workflow
|
||||
- ✅ Meta-context: Background about the architecture (if demonstrating a pattern)
|
||||
- ✅ Core architecture principles (step-file design, JIT loading, etc.)
|
||||
- ✅ Initialization/routing: How to start and which step to load first
|
||||
|
||||
**Progressive Disclosure Rule:**
|
||||
Users should ONLY know about the current step they're executing. The workflow.md routes to the first step, and each step routes to the next. No step lists in workflow.md!
|
||||
|
||||
---
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. Micro-File Design
|
||||
- Each step is a focused file (~80-200 lines)
|
||||
- One concept per step
|
||||
- Self-contained instructions
|
||||
|
||||
### 2. Just-In-Time Loading
|
||||
- Only current step file is in memory
|
||||
- Never load future steps until user selects 'C'
|
||||
- Progressive disclosure - LLM stays focused
|
||||
|
||||
### 3. Sequential Enforcement
|
||||
- Steps execute in order
|
||||
- No skipping, no optimization
|
||||
- Each step completes before next loads
|
||||
|
||||
### 4. State Tracking
|
||||
For continuable workflows:
|
||||
```yaml
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather', 'step-03-design']
|
||||
lastStep: 'step-03-design'
|
||||
lastContinued: '2025-01-02'
|
||||
```
|
||||
|
||||
Each step appends its name to `stepsCompleted` before loading next.
|
||||
|
||||
---
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### Fresh Start
|
||||
```
|
||||
workflow.md → step-01-init.md → step-02-[name].md → ... → step-N-final.md
|
||||
```
|
||||
|
||||
### Continuation (Resumed)
|
||||
```
|
||||
workflow.md → step-01-init.md (detects existing) → step-01b-continue.md → [appropriate next step]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Variables
|
||||
|
||||
### Standard (All Workflows)
|
||||
```yaml
|
||||
workflow_path: '{project-root}/_bmad/[module]/workflows/[name]'
|
||||
thisStepFile: '{workflow_path}/steps/step-[N]-[name].md'
|
||||
nextStepFile: '{workflow_path}/steps/step-[N+1]-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
```
|
||||
|
||||
### Module-Specific
|
||||
```yaml
|
||||
# BMB example:
|
||||
bmb_creations_output_folder: '{project-root}/_bmad/bmb-creations'
|
||||
```
|
||||
|
||||
### Critical Rules
|
||||
- ONLY variables used in step body go in frontmatter
|
||||
- All file references use `{variable}` format
|
||||
- Paths within workflow folder are relative
|
||||
|
||||
---
|
||||
|
||||
## Menu Pattern
|
||||
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [action] [P] [action] [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {task}, then redisplay menu
|
||||
- IF P: Execute {task}, then redisplay menu
|
||||
- IF C: Save to {outputFile}, update frontmatter, then load {nextStepFile}
|
||||
- IF Any other: help user, then redisplay menu
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
```
|
||||
|
||||
**A/P not needed in:** Step 1 (init), validation sequences, simple data gathering
|
||||
|
||||
---
|
||||
|
||||
## Output Pattern
|
||||
|
||||
Every step writes to a document BEFORE loading next step:
|
||||
|
||||
1. **Plan-then-build:** Steps append to plan.md → build step consumes plan
|
||||
2. **Direct-to-final:** Steps append directly to final document
|
||||
|
||||
See: `output-format-standards.md`
|
||||
|
||||
---
|
||||
|
||||
## Critical Rules
|
||||
|
||||
- 🛑 NEVER load multiple step files simultaneously
|
||||
- 📖 ALWAYS read entire step file before execution
|
||||
- 🚫 NEVER skip steps or optimize the sequence
|
||||
- 💾 ALWAYS update frontmatter when step completes
|
||||
- ⏸️ ALWAYS halt at menus and wait for input
|
||||
- 📋 NEVER create mental todos from future steps
|
||||
@@ -0,0 +1,81 @@
|
||||
# CSV Data File Standards
|
||||
|
||||
**Purpose:** When workflows need structured data that LLMs cannot generate.
|
||||
|
||||
---
|
||||
|
||||
## When to Use CSV
|
||||
|
||||
Use CSV for data that is:
|
||||
- Domain-specific and not in training data
|
||||
- Too large for prompt context
|
||||
- Needs structured lookup/reference
|
||||
- Must be consistent across sessions
|
||||
|
||||
**Don't use for:**
|
||||
- Web-searchable information
|
||||
- Common programming syntax
|
||||
- General knowledge
|
||||
- Things LLMs can generate
|
||||
|
||||
---
|
||||
|
||||
## CSV Structure
|
||||
|
||||
```csv
|
||||
category,name,pattern,description
|
||||
"collaboration","Think Aloud Protocol","user speaks thoughts → facilitator captures","Make thinking visible during work"
|
||||
"creative","SCAMPER","substitute→combine→adapt→modify→put→eliminate→reverse","Systematic creative thinking"
|
||||
```
|
||||
|
||||
**Rules:**
|
||||
- Header row required, descriptive column names
|
||||
- Consistent data types per column
|
||||
- UTF-8 encoding
|
||||
- All columns must be used in workflow
|
||||
|
||||
---
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### 1. Method Registry
|
||||
Advanced Elicitation uses CSV to select techniques dynamically:
|
||||
```csv
|
||||
category,name,pattern
|
||||
collaboration,Think Aloud,user speaks thoughts → facilitator captures
|
||||
advanced,Six Thinking Hats,view problem from 6 perspectives
|
||||
```
|
||||
|
||||
### 2. Knowledge Base Index
|
||||
Map keywords to document locations for surgical lookup:
|
||||
```csv
|
||||
keywords,document_path,section
|
||||
"nutrition,macros",data/nutrition-reference.md,## Daily Targets
|
||||
```
|
||||
|
||||
### 3. Configuration Lookup
|
||||
Map scenarios to parameters:
|
||||
```csv
|
||||
scenario,required_steps,output_sections
|
||||
"2D Platformer",step-01,step-03,step-07,movement,physics,collision
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Keep files small (<1MB if possible)
|
||||
- No unused columns
|
||||
- Document each CSV's purpose
|
||||
- Validate data quality
|
||||
- Use efficient encoding (codes vs full descriptions)
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For each CSV file:
|
||||
- [ ] Purpose is essential (can't be generated by LLM)
|
||||
- [ ] All columns are used somewhere
|
||||
- [ ] Properly formatted (consistent, UTF-8)
|
||||
- [ ] Documented with examples
|
||||
@@ -2,18 +2,11 @@
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize the nutrition plan workflow by detecting continuation state and creating output document'
|
||||
|
||||
# Path Definitions
|
||||
workflow_path: '{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition'
|
||||
nextStepFile: './step-02-profile.md'
|
||||
continueFile: './step-01b-continue.md'
|
||||
|
||||
# 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: '{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
|
||||
templateFile: '../templates/nutrition-plan.md'
|
||||
---
|
||||
|
||||
# Step 1: Workflow Initialization
|
||||
@@ -2,15 +2,7 @@
|
||||
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
|
||||
@@ -119,15 +111,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 {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 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 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.
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
@@ -2,13 +2,7 @@
|
||||
name: 'step-02-profile'
|
||||
description: 'Gather comprehensive user profile information through collaborative conversation'
|
||||
|
||||
# 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'
|
||||
nextStepFile: './step-03-assessment.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
@@ -16,7 +10,7 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
profileTemplate: '{workflow_path}/templates/profile-section.md'
|
||||
profileTemplate: '../templates/profile-section.md'
|
||||
---
|
||||
|
||||
# Step 2: User Profile & Goals Collection
|
||||
@@ -2,13 +2,7 @@
|
||||
name: 'step-03-assessment'
|
||||
description: 'Analyze nutritional requirements, identify restrictions, and calculate target macros'
|
||||
|
||||
# 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'
|
||||
nextStepFile: './step-04-strategy.md'\
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
@@ -16,11 +10,11 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Data References
|
||||
dietaryRestrictionsDB: '{workflow_path}/data/dietary-restrictions.csv'
|
||||
macroCalculatorDB: '{workflow_path}/data/macro-calculator.csv'
|
||||
dietaryRestrictionsDB: '../data/dietary-restrictions.csv'
|
||||
macroCalculatorDB: '../data/macro-calculator.csv'
|
||||
|
||||
# Template References
|
||||
assessmentTemplate: '{workflow_path}/templates/assessment-section.md'
|
||||
assessmentTemplate: '../templates/assessment-section.md'
|
||||
---
|
||||
|
||||
# Step 3: Dietary Needs & Restrictions Assessment
|
||||
@@ -2,14 +2,8 @@
|
||||
name: 'step-04-strategy'
|
||||
description: 'Design a personalized meal strategy that meets nutritional needs and fits lifestyle'
|
||||
|
||||
# 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'
|
||||
nextStepFile: './step-05-shopping.md'
|
||||
alternateNextStepFile: './step-06-prep-schedule.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
@@ -17,10 +11,10 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Data References
|
||||
recipeDatabase: '{workflow_path}/data/recipe-database.csv'
|
||||
recipeDatabase: '../data/recipe-database.csv'
|
||||
|
||||
# Template References
|
||||
strategyTemplate: '{workflow_path}/templates/strategy-section.md'
|
||||
strategyTemplate: '../templates/strategy-section.md'
|
||||
---
|
||||
|
||||
# Step 4: Meal Strategy Creation
|
||||
@@ -2,13 +2,7 @@
|
||||
name: 'step-05-shopping'
|
||||
description: 'Create a comprehensive shopping list that supports the meal strategy'
|
||||
|
||||
# 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'
|
||||
nextStepFile: './step-06-prep-schedule.md'
|
||||
outputFile: '{output_folder}/nutrition-plan-{project_name}.md'
|
||||
|
||||
# Task References
|
||||
@@ -16,7 +10,7 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
shoppingTemplate: '{workflow_path}/templates/shopping-section.md'
|
||||
shoppingTemplate: '../templates/shopping-section.md'
|
||||
---
|
||||
|
||||
# Step 5: Shopping List Generation
|
||||
@@ -2,12 +2,6 @@
|
||||
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
|
||||
@@ -15,7 +9,7 @@ advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitati
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References
|
||||
prepScheduleTemplate: '{workflow_path}/templates/prep-schedule-section.md'
|
||||
prepScheduleTemplate: '../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 `{project-root}/_bmad/bmb/reference/workflows/meal-prep-nutrition/steps/step-01-init.md` to begin the workflow.
|
||||
Load, read the full file and then execute `./steps-c/step-01-init.md` to begin the workflow.
|
||||
179
src/modules/bmb/workflows/workflow/data/frontmatter-standards.md
Normal file
179
src/modules/bmb/workflows/workflow/data/frontmatter-standards.md
Normal file
@@ -0,0 +1,179 @@
|
||||
# Frontmatter Standards
|
||||
|
||||
**Purpose:** Variables, paths, and frontmatter rules for workflow steps.
|
||||
|
||||
---
|
||||
|
||||
## Golden Rules
|
||||
|
||||
1. **Only variables USED in the step** may be in frontmatter
|
||||
2. **All file references MUST use `{variable}` format** - no hardcoded paths
|
||||
3. **Paths within workflow folder MUST be relative**
|
||||
|
||||
---
|
||||
|
||||
## Standard Variables (Always Available)
|
||||
|
||||
| Variable | Example Value |
|
||||
| ----------------- | -------------------------------------- |
|
||||
| `{project-root}` | `/Users/user/dev/BMAD-METHOD` |
|
||||
| `{project_name}` | `my-project` |
|
||||
| `{output_folder}` | `/Users/user/dev/BMAD-METHOD/output` |
|
||||
| `{user_name}` | `Brian` |
|
||||
| `{communication_language}` | `english` |
|
||||
| `{document_output_language}` | `english` |
|
||||
|
||||
---
|
||||
|
||||
## Module-Specific Variables
|
||||
|
||||
Workflows in a MODULE can access additional variables from its `module.yaml`.
|
||||
|
||||
**BMB Module example:**
|
||||
```yaml
|
||||
bmb_creations_output_folder: '{project-root}/_bmad/bmb-creations'
|
||||
```
|
||||
|
||||
**Standalone workflows:** Only have access to standard variables.
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Structure
|
||||
|
||||
### Required Fields
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[what this step does]'
|
||||
---
|
||||
```
|
||||
|
||||
### File References (ONLY if used in this step)
|
||||
```yaml
|
||||
---
|
||||
# File References
|
||||
workflow_path: '{project-root}/_bmad/[module]/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].md'
|
||||
|
||||
# Task References (IF USED)
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
|
||||
|
||||
# Template References (IF USED)
|
||||
someTemplate: '{workflow_path}/templates/[template].md'
|
||||
|
||||
# Data References (IF USED)
|
||||
someData: '{workflow_path}/data/[data].csv'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Rule: Unused Variables Forbidden
|
||||
|
||||
### ❌ VIOLATION
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{output_folder}/output.md'
|
||||
partyModeWorkflow: '{project-root}/.../party-mode/workflow.md' # ❌ NOT USED!
|
||||
---
|
||||
# Step body never mentions {partyModeWorkflow}
|
||||
```
|
||||
|
||||
### ✅ CORRECT
|
||||
```yaml
|
||||
---
|
||||
outputFile: '{output_folder}/output.md'
|
||||
---
|
||||
# Step body uses {outputFile}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Path Rules
|
||||
|
||||
### 1. Paths Within Workflow Folder = RELATIVE
|
||||
```yaml
|
||||
# ❌ WRONG - absolute for same-folder
|
||||
someTemplate: '{project-root}/_bmad/bmb/workflows/my-workflow/templates/template.md'
|
||||
|
||||
# ✅ CORRECT - relative or via workflow_path
|
||||
someTemplate: '{workflow_path}/templates/template.md'
|
||||
```
|
||||
|
||||
### 2. External References = Full Variable Paths
|
||||
```yaml
|
||||
# ✅ CORRECT
|
||||
advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
|
||||
```
|
||||
|
||||
### 3. Output Files = Use output_folder Variable
|
||||
```yaml
|
||||
# ✅ CORRECT
|
||||
outputFile: '{output_folder}/workflow-output-{project_name}.md'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Defining New Variables
|
||||
|
||||
Steps can define NEW variables that future steps will use.
|
||||
|
||||
**Step 01 defines:**
|
||||
```yaml
|
||||
---
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
|
||||
---
|
||||
```
|
||||
|
||||
**Step 02 uses:**
|
||||
```yaml
|
||||
---
|
||||
targetWorkflowPath: '{bmb_creations_output_folder}/workflows/{workflow_name}'
|
||||
workflowPlanFile: '{targetWorkflowPath}/plan.md'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Continuable Workflow Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather', 'step-03-design']
|
||||
lastStep: 'step-03-design'
|
||||
lastContinued: '2025-01-02'
|
||||
date: '2025-01-01'
|
||||
---
|
||||
```
|
||||
|
||||
**Step tracking:** Each step appends its NAME to `stepsCompleted`.
|
||||
|
||||
---
|
||||
|
||||
## Variable Naming
|
||||
|
||||
Use `snake_case` with descriptive prefixes:
|
||||
|
||||
| Pattern | Usage | Example |
|
||||
| --------- | ---------------------- | -------------------------- |
|
||||
| `{*_path}` | Folder paths | `workflow_path`, `data_path` |
|
||||
| `{*_file}` | Files | `outputFile`, `planFile` |
|
||||
| `{*_template}` | Templates | `profileTemplate` |
|
||||
| `{*_data}` | Data files | `dietaryData` |
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For every step frontmatter:
|
||||
- [ ] `name` present, kebab-case
|
||||
- [ ] `description` present
|
||||
- [ ] All variables in frontmatter ARE used in step body
|
||||
- [ ] All file references use `{variable}` format
|
||||
- [ ] Paths within workflow folder are relative
|
||||
- [ ] External paths use `{project-root}` variable
|
||||
- [ ] Module variables only if workflow belongs to that module
|
||||
@@ -0,0 +1,269 @@
|
||||
# Input Document Discovery Standards
|
||||
|
||||
**Purpose:** How workflows discover, validate, and select input documents from prior workflows or external sources.
|
||||
|
||||
---
|
||||
|
||||
## Discovery Patterns
|
||||
|
||||
### Pattern 1: Prior Workflow Output
|
||||
**Use when:** Workflow is part of a sequence (e.g., PRD → Architecture → Epics)
|
||||
|
||||
**Example:** BMM module pipeline - each of these are a workflow with many steps:
|
||||
```
|
||||
brainstorming → research → brief → PRD → UX → architecture → epics → sprint-planning
|
||||
```
|
||||
|
||||
Each workflow checks for output from prior workflow(s).
|
||||
|
||||
### Pattern 2: Module Folder Search
|
||||
**Use when:** Documents stored in known project location
|
||||
|
||||
**Example:** Manager review workflow searches `{project_folder}/employee-notes/`
|
||||
|
||||
### Pattern 3: User-Specified Paths
|
||||
**Use when:** User provides document locations
|
||||
|
||||
**Example:** Tax workflow asks for financial statement paths
|
||||
|
||||
### Pattern 4: Pattern-Based Discovery
|
||||
**Use when:** Search by file naming pattern
|
||||
|
||||
**Example:** Find all `*-brief.md` files in `{planning_artifacts}/`
|
||||
|
||||
---
|
||||
|
||||
## Discovery Step Pattern
|
||||
|
||||
**When:** Step 1 (init) or Step 2 (discovery)
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
# Input discovery variables
|
||||
inputDocuments: [] # Populated with discovered docs
|
||||
requiredInputCount: 1 # Minimum required to proceed
|
||||
optionalInputCount: 0 # Additional docs user may provide
|
||||
moduleInputFolder: '{planning_artifacts}' # Where to search
|
||||
inputFilePatterns: # File patterns to match
|
||||
- '*-prd.md'
|
||||
- '*-ux.md'
|
||||
---
|
||||
```
|
||||
|
||||
**Discovery Logic:**
|
||||
```markdown
|
||||
## 1. Check for Known Prior Workflow Outputs
|
||||
|
||||
Search in order:
|
||||
1. {module_output_folder}/[known-prior-workflow-output].md
|
||||
2. {project_folder}/[standard-locations]/
|
||||
3. {planning_artifacts}/
|
||||
4. User-provided paths
|
||||
|
||||
## 2. Pattern-Based Search
|
||||
|
||||
If no known prior workflow, search by patterns:
|
||||
- Look for files matching {inputFilePatterns}
|
||||
- Search in {moduleInputFolder}
|
||||
- Search in {project_folder}/docs/
|
||||
|
||||
## 3. Present Findings to User
|
||||
|
||||
"Found these documents that may be relevant:
|
||||
- [1] prd-my-project.md (created 3 days ago)
|
||||
- [2] ux-research.md (created 1 week ago)
|
||||
- [3] competitor-analysis.md
|
||||
|
||||
Which would you like to use? You can select multiple, or provide additional paths."
|
||||
|
||||
## 4. Confirm and Load
|
||||
|
||||
User confirms selection → Load selected documents
|
||||
Add to {inputDocuments} array in output frontmatter
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Required vs Optional Inputs
|
||||
|
||||
### Required Inputs
|
||||
Workflow cannot proceed without these.
|
||||
|
||||
**Example:** Architecture workflow requires PRD
|
||||
|
||||
```markdown
|
||||
## INPUT REQUIREMENT:
|
||||
|
||||
This workflow requires a Product Requirements Document to proceed.
|
||||
|
||||
Searching for PRD in:
|
||||
- {bmm_creations_output_folder}/prd-*.md
|
||||
- {planning_artifacts}/*-prd.md
|
||||
- {project_folder}/docs/*-prd.md
|
||||
|
||||
[If found:]
|
||||
"Found PRD: prd-my-project.md. Use this?"
|
||||
[If not found:]
|
||||
"No PRD found. This workflow requires a PRD to continue.
|
||||
Please provide the path to your PRD, or run the PRD workflow first."
|
||||
```
|
||||
|
||||
### Optional Inputs
|
||||
Workflow can proceed without these, but user may include.
|
||||
|
||||
**Example:** UX workflow can use research docs if available
|
||||
|
||||
```markdown
|
||||
## OPTIONAL INPUTS:
|
||||
|
||||
This workflow can incorporate research documents if available.
|
||||
|
||||
Searching for research in:
|
||||
- {bmm_creations_output_folder}/research-*.md
|
||||
- {project_folder}/research/
|
||||
|
||||
[If found:]
|
||||
"Found these research documents:
|
||||
- [1] user-interviews.md
|
||||
- [2] competitive-analysis.md
|
||||
Include any? (None required to proceed)"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Module Workflow Chaining
|
||||
|
||||
**For modules with sequential workflows:**
|
||||
|
||||
**Frontmatter in workflow.md:**
|
||||
```yaml
|
||||
---
|
||||
## INPUT FROM PRIOR WORKFLOFS
|
||||
|
||||
### Required Inputs:
|
||||
- {module_output_folder}/prd-{project_name}.md
|
||||
|
||||
### Optional Inputs:
|
||||
- {module_output_folder}/ux-research-{project_name}.md
|
||||
- {project_folder}/docs/competitor-analysis.md
|
||||
---
|
||||
```
|
||||
|
||||
**Step 1 discovery:**
|
||||
```markdown
|
||||
## 1. Discover Prior Workflow Outputs
|
||||
|
||||
Check for required inputs:
|
||||
1. Look for {module_output_folder}/prd-{project_name}.md
|
||||
2. If missing → Error: "Please run PRD workflow first"
|
||||
3. If found → Confirm with user
|
||||
|
||||
Check for optional inputs:
|
||||
1. Search {module_output_folder}/ for research-*.md
|
||||
2. Search {project_folder}/docs/ for *-analysis.md
|
||||
3. Present findings to user
|
||||
4. Add selections to {inputDocuments}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Input Validation
|
||||
|
||||
After discovery, validate inputs:
|
||||
|
||||
```markdown
|
||||
## INPUT VALIDATION:
|
||||
|
||||
For each discovered document:
|
||||
1. Load and read frontmatter
|
||||
2. Check workflowType field (should match expected)
|
||||
3. Check completeness (stepsCompleted should be complete)
|
||||
4. Check date (warn if document is very old)
|
||||
|
||||
[If validation fails:]
|
||||
"Document prd-my-project.md appears incomplete.
|
||||
Last step: step-06 (of 11)
|
||||
Recommend completing PRD workflow before proceeding.
|
||||
Proceed anyway? [Y]es [N]o"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Multiple Input Selection
|
||||
|
||||
**When user can select multiple documents:**
|
||||
|
||||
```markdown
|
||||
## Document Selection
|
||||
|
||||
"Found these relevant documents:
|
||||
[1] prd-my-project.md (3 days ago) ✓ Recommended
|
||||
[2] prd-v1.md (2 months ago) ⚠ Older version
|
||||
[3] ux-research.md (1 week ago)
|
||||
|
||||
Enter numbers to include (comma-separated), or 'none' to skip:
|
||||
> 1, 3
|
||||
|
||||
Selected: prd-my-project.md, ux-research.md"
|
||||
```
|
||||
|
||||
**Track in frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
inputDocuments:
|
||||
- path: '{output_folder}/prd-my-project.md'
|
||||
type: 'prd'
|
||||
source: 'prior-workflow'
|
||||
selected: true
|
||||
- path: '{output_folder}/ux-research.md'
|
||||
type: 'research'
|
||||
source: 'prior-workflow'
|
||||
selected: true
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Search Path Variables
|
||||
|
||||
Common module variables for input discovery:
|
||||
|
||||
| Variable | Purpose |
|
||||
| ------------------------ | -------------------------- |
|
||||
| `{module_output_folder}` | Prior workflow outputs |
|
||||
| `{planning_artifacts}` | General planning docs |
|
||||
| `{project_folder}/docs` | Project documentation |
|
||||
| `{product_knowledge}` | Product-specific knowledge |
|
||||
| `{user_documents}` | User-provided location |
|
||||
|
||||
---
|
||||
|
||||
## Discovery Step Template
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize and discover input documents'
|
||||
|
||||
# Input Discovery
|
||||
inputDocuments: []
|
||||
requiredInputCount: 1
|
||||
moduleInputFolder: '{module_output_folder}'
|
||||
inputFilePatterns:
|
||||
- '*-prd.md'
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For input discovery:
|
||||
- [ ] Required inputs defined in step frontmatter
|
||||
- [ ] Search paths defined (module variables or patterns)
|
||||
- [ ] User confirmation before using documents
|
||||
- [ ] Validation of document completeness
|
||||
- [ ] Clear error messages when required inputs missing
|
||||
- [ ] Support for multiple document selection
|
||||
- [ ] Optional inputs clearly marked as optional
|
||||
@@ -0,0 +1,50 @@
|
||||
# Intent vs Prescriptive Spectrum
|
||||
|
||||
**Principle:** Workflows lean toward **intent** (goals) not **prescription** (exact wording). The more intent-based, the more adaptive and creative the LLM can be.
|
||||
|
||||
---
|
||||
|
||||
## When to Use Each
|
||||
|
||||
### Intent-Based (Default)
|
||||
**Use for:** Most workflows - creative, exploratory, collaborative
|
||||
**Step instruction:** "Help the user understand X using multi-turn conversation. Probe to get good answers. Ask 1-2 questions at a time, not a laundry list."
|
||||
**LLM figures out:** Exact wording, question order, how to respond
|
||||
|
||||
### Prescriptive (Exception)
|
||||
**Use for:** Compliance, safety, legal, medical, regulated industries
|
||||
**Step instruction:** "Say exactly: 'Do you currently experience fever, cough, or fatigue?' Wait for response. Then ask exactly: 'When did symptoms begin?'"
|
||||
**LLM follows:** Exact script, specific order, no deviation
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Intent-Based (Good for most)
|
||||
```
|
||||
"Guide the user through discovering their ideal nutrition plan.
|
||||
Use multi-turn conversation. Ask 1-2 questions at a time.
|
||||
Think about their responses before asking follow-ups.
|
||||
Probe to understand preferences, restrictions, goals."
|
||||
```
|
||||
|
||||
### Prescriptive (Only when required)
|
||||
```
|
||||
"Medical intake - ask exactly:
|
||||
1. 'Do you have any of these symptoms: fever, cough, fatigue?'
|
||||
2. 'When did symptoms begin?'
|
||||
3. 'Have you traveled recently in the last 14 days?'
|
||||
Follow sequence precisely. Do not deviate."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step Writing Tips
|
||||
|
||||
- **Default to intent** - give goals, not scripts
|
||||
- **Use "think"** - "Think about their response before..."
|
||||
- **Multi-turn** - "Use conversation, not interrogation"
|
||||
- **Progressive** - "Ask 1-2 questions at a time"
|
||||
- **Probe** - "Ask follow-ups to understand deeper"
|
||||
|
||||
Only use prescriptive when compliance/regulation requires it.
|
||||
@@ -0,0 +1,167 @@
|
||||
# Menu Handling Standards
|
||||
|
||||
**CRITICAL:** Every menu MUST have a handler section. No exceptions.
|
||||
|
||||
---
|
||||
|
||||
## Reserved Letters
|
||||
|
||||
| Letter | Purpose | After Execution |
|
||||
| ------ | -------------------- | ------------------------------ |
|
||||
| **A** | Advanced Elicitation | Redisplay menu |
|
||||
| **P** | Party Mode | Redisplay menu |
|
||||
| **C** | Continue/Accept | Save → update → load next step |
|
||||
| **X** | Exit/Cancel | End workflow |
|
||||
|
||||
**Custom letters** allowed (L/R/F/etc.) but don't conflict with reserved.
|
||||
|
||||
---
|
||||
|
||||
## Required Structure
|
||||
|
||||
### Section 1: Display
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [action] [P] [action] [C] Continue"
|
||||
```
|
||||
|
||||
### Section 2: Handler (MANDATORY)
|
||||
```markdown
|
||||
#### 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: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
```
|
||||
|
||||
### Section 3: Execution Rules
|
||||
```markdown
|
||||
#### 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
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## When To Include A/P
|
||||
|
||||
### DON'T Include A/P:
|
||||
- Step 1 (init) - no content to refine yet
|
||||
- Step 2 if only loading documents
|
||||
- Validation sequences - auto-flow instead
|
||||
- Simple data gathering
|
||||
|
||||
### DO Include A/P:
|
||||
- Collaborative content creation
|
||||
- User might want alternatives
|
||||
- Quality gate before proceeding
|
||||
- Creative exploration valuable
|
||||
|
||||
---
|
||||
|
||||
## Menu Patterns
|
||||
|
||||
### Pattern 1: Standard A/P/C
|
||||
```markdown
|
||||
Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
|
||||
- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-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
|
||||
```
|
||||
|
||||
### Pattern 2: C Only (No A/P)
|
||||
```markdown
|
||||
Display: "**Select:** [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
```
|
||||
|
||||
**Use for:** Step 1, document discovery, simple progression
|
||||
|
||||
### Pattern 3: Auto-Proceed (No Menu)
|
||||
```markdown
|
||||
Display: "**Proceeding to [next step]...**"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- After [completion condition], immediately load, read entire file, then execute {nextStepFile}
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- This is an [auto-proceed reason] step with no user choices
|
||||
- Proceed directly to next step after setup
|
||||
```
|
||||
|
||||
**Use for:** Init steps, validation sequences
|
||||
|
||||
### Pattern 4: Branching
|
||||
```markdown
|
||||
Display: "**Select:** [L] Load Existing [N] Create New [C] Continue"
|
||||
|
||||
#### Menu Handling Logic:
|
||||
- IF L: Load existing document, then load, read entire file, then execute {stepForExisting}
|
||||
- IF N: Create new document, then load, read entire file, then execute {stepForNew}
|
||||
- IF C: Save content to {outputFile}, update frontmatter, check {condition}, then load appropriate step
|
||||
- IF Any other: help user, then [Redisplay Menu Options](#n-present-menu-options)
|
||||
|
||||
#### EXECUTION RULES:
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- Branching options load different steps based on user choice
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Violations
|
||||
|
||||
### ❌ DON'T:
|
||||
```markdown
|
||||
# Missing Handler Section
|
||||
Display: "**Select:** [C] Continue"
|
||||
[NO HANDLER - CRITICAL ERROR!]
|
||||
|
||||
# A/P in Step 1 (doesn't make sense)
|
||||
Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
|
||||
|
||||
# Forgetting redisplay
|
||||
- IF A: Execute {advancedElicitationTask}
|
||||
# Should end with: ", and when finished redisplay the menu"
|
||||
|
||||
# Missing halt instruction
|
||||
#### EXECUTION RULES:
|
||||
- ONLY proceed to next step when user selects 'C'
|
||||
# MISSING: "ALWAYS halt and wait for user input after presenting menu"
|
||||
```
|
||||
|
||||
### ✅ DO:
|
||||
- Handler section immediately follows Display
|
||||
- "Halt and wait" in EXECUTION RULES
|
||||
- Non-C options specify "redisplay menu"
|
||||
- A/P only when appropriate for step type
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For every menu:
|
||||
- [ ] Display section present
|
||||
- [ ] Handler section immediately follows
|
||||
- [ ] EXECUTION RULES section present
|
||||
- [ ] "Halt and wait" instruction included
|
||||
- [ ] A/P options appropriate for step type
|
||||
- [ ] Non-C options redisplay menu
|
||||
- [ ] C option: save → update → load next
|
||||
- [ ] All file references use variables
|
||||
@@ -0,0 +1,188 @@
|
||||
# Output Format Standards
|
||||
|
||||
**Purpose:** How workflows produce documents and handle step output.
|
||||
|
||||
---
|
||||
|
||||
## Golden Rule
|
||||
|
||||
**Every step MUST output to a document BEFORE loading the next step.**
|
||||
|
||||
Two patterns:
|
||||
1. **Direct-to-Final:** Steps append to final document
|
||||
2. **Plan-then-Build:** Steps append to plan → build step consumes plan
|
||||
|
||||
---
|
||||
|
||||
## Menu C Option Sequence
|
||||
|
||||
When user selects **C (Continue)**:
|
||||
1. **Append/Write** to document (plan or final)
|
||||
2. **Update frontmatter** (append this step to `stepsCompleted`)
|
||||
3. **THEN** load next step
|
||||
|
||||
```markdown
|
||||
- IF C: Save content to {outputFile}, update frontmatter, then load, read entire file, then execute {nextStepFile}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Patterns
|
||||
|
||||
### Pattern 1: Plan-then-Build
|
||||
|
||||
**Use when:** Design/plan before building/creating
|
||||
|
||||
```
|
||||
Step 1 (init) → Creates plan.md from template
|
||||
Step 2 (gather) → Appends requirements to plan.md
|
||||
Step 3 (design) → Appends design decisions to plan.md
|
||||
Step 4 (review) → Appends review/approval to plan.md
|
||||
Step 5 (build) → READS plan.md, CREATES final artifacts
|
||||
```
|
||||
|
||||
**Plan frontmatter:**
|
||||
```yaml
|
||||
workflowName: [name]
|
||||
creationDate: [date]
|
||||
stepsCompleted: ['step-01-init', 'step-02-gather']
|
||||
status: PLANNING_COMPLETE
|
||||
```
|
||||
|
||||
**Example:** Workflow creation - steps append to plan, build step generates files
|
||||
|
||||
### Pattern 2: Direct-to-Final
|
||||
|
||||
**Use when:** Each step contributes to final deliverable
|
||||
|
||||
```
|
||||
Step 1 (init) → Creates final-doc.md from minimal template
|
||||
Step 2 (section) → Appends Section 1
|
||||
Step 3 (section) → Appends Section 2
|
||||
Step 4 (section) → Appends Section 3
|
||||
Step 5 (polish) → Optimizes entire document
|
||||
```
|
||||
|
||||
**Example:** Meal prep nutrition plan - each step adds a section
|
||||
|
||||
---
|
||||
|
||||
## Four Template Types
|
||||
|
||||
### 1. Free-Form (RECOMMENDED)
|
||||
|
||||
**Characteristics:** Minimal template, progressive append, final polish
|
||||
|
||||
**Template:**
|
||||
```yaml
|
||||
---
|
||||
stepsCompleted: []
|
||||
lastStep: ''
|
||||
date: ''
|
||||
user_name: ''
|
||||
---
|
||||
|
||||
# {{document_title}}
|
||||
|
||||
[Content appended progressively by workflow steps]
|
||||
```
|
||||
|
||||
**Use when:** Most workflows - flexible, collaborative
|
||||
|
||||
### 2. Structured
|
||||
|
||||
**Characteristics:** Single template with placeholders, clear sections
|
||||
|
||||
**Template:**
|
||||
```markdown
|
||||
# {{title}}
|
||||
|
||||
## {{section_1}}
|
||||
[Content to be filled]
|
||||
|
||||
## {{section_2}}
|
||||
[Content to be filled]
|
||||
```
|
||||
|
||||
**Use when:** Reports, proposals, documentation
|
||||
|
||||
### 3. Semi-Structured
|
||||
|
||||
**Characteristics:** Core required sections + optional additions
|
||||
|
||||
**Use when:** Forms, checklists, meeting minutes
|
||||
|
||||
### 4. Strict
|
||||
|
||||
**Characteristics:** Multiple templates, exact field definitions
|
||||
|
||||
**Use when:** Rarely - compliance, legal, regulated
|
||||
|
||||
---
|
||||
|
||||
## Template Syntax
|
||||
|
||||
```markdown
|
||||
{{variable}} # Handlebars style (preferred)
|
||||
[variable] # Bracket style (also supported)
|
||||
```
|
||||
|
||||
**Keep templates lean** - structure only, not content.
|
||||
|
||||
---
|
||||
|
||||
## Step-to-Output Mapping
|
||||
|
||||
Steps should be in ORDER of document appearance:
|
||||
|
||||
```
|
||||
Step 1: Init (creates doc)
|
||||
Step 2: → ## Section 1
|
||||
Step 3: → ## Section 2
|
||||
Step 4: → ## Section 3
|
||||
Step 5: → ## Section 4
|
||||
Step 6: Polish (optimizes entire doc)
|
||||
```
|
||||
|
||||
**Critical:** Use ## Level 2 headers for main sections - allows document splitting if needed.
|
||||
|
||||
---
|
||||
|
||||
## Final Polish Step
|
||||
|
||||
For free-form workflows, include a polish step that:
|
||||
1. Loads entire document
|
||||
2. Reviews for flow and coherence
|
||||
3. Reduces duplication
|
||||
4. Ensures proper ## Level 2 headers
|
||||
5. Improves transitions
|
||||
6. Keeps general order but optimizes readability
|
||||
|
||||
---
|
||||
|
||||
## Output File Patterns
|
||||
|
||||
```yaml
|
||||
# Single output
|
||||
outputFile: '{output_folder}/document-{project_name}.md'
|
||||
|
||||
# Time-stamped
|
||||
outputFile: '{output_folder}/document-{project_name}-{timestamp}.md'
|
||||
|
||||
# User-specific
|
||||
outputFile: '{output_folder}/document-{user_name}-{project_name}.md'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For workflow output design:
|
||||
- [ ] Output format type selected
|
||||
- [ ] Template created if needed
|
||||
- [ ] Steps ordered to match document structure
|
||||
- [ ] Each step outputs to document (except init/final)
|
||||
- [ ] Level 2 headers for main sections
|
||||
- [ ] Final polish step for free-form workflows
|
||||
- [ ] Frontmatter tracking for continuable workflows
|
||||
- [ ] Templates use consistent placeholder syntax
|
||||
235
src/modules/bmb/workflows/workflow/data/step-file-rules.md
Normal file
235
src/modules/bmb/workflows/workflow/data/step-file-rules.md
Normal file
@@ -0,0 +1,235 @@
|
||||
# Step File Rules
|
||||
|
||||
**Purpose:** Quick reference for step file structure and compliance. See linked data files for detailed standards.
|
||||
|
||||
---
|
||||
|
||||
## File Size Limits
|
||||
|
||||
| Metric | Value |
|
||||
| ----------- | -------- |
|
||||
| Recommended | < 200 lines |
|
||||
| Absolute Maximum | 250 lines |
|
||||
|
||||
**If exceeded:** Split into multiple steps or extract content to `/data/` files.
|
||||
|
||||
---
|
||||
|
||||
## Required Step Structure
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[what this step does]'
|
||||
|
||||
# File References (ONLY variables used in this step!)
|
||||
[file references in {variable} format]
|
||||
---
|
||||
|
||||
# Step [N]: [Name]
|
||||
|
||||
## STEP GOAL:
|
||||
[Single sentence: what this step accomplishes]
|
||||
|
||||
## 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 [specific role]
|
||||
- ✅ We engage in collaborative dialogue, not command-response
|
||||
- ✅ You bring [expertise], user brings [theirs]
|
||||
- ✅ Together we produce something better
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Focus only on [specific task]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
- 💬 Approach: [how to engage]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
- 🎯 [Protocol 1]
|
||||
- 💾 [Protocol 2 - save/update]
|
||||
- 📖 [Protocol 3 - tracking]
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
- Available context: [what's available]
|
||||
- Focus: [what to focus on]
|
||||
- Limits: [boundaries]
|
||||
- Dependencies: [what this depends on]
|
||||
|
||||
## Sequence of Instructions:
|
||||
### 1. [Action]
|
||||
[Instructions]
|
||||
|
||||
### N. Present MENU OPTIONS
|
||||
[Menu section - see menu-handling-standards.md]
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
||||
### ✅ SUCCESS:
|
||||
[Success criteria]
|
||||
### ❌ SYSTEM FAILURE:
|
||||
[Failure criteria]
|
||||
**Master Rule:** Skipping steps is FORBIDDEN.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Critical Rules (Quick Reference)
|
||||
|
||||
### Frontmatter
|
||||
- ✅ Only variables USED in the step body
|
||||
- ✅ All file references use `{variable}` format
|
||||
- ✅ Relative paths within workflow folder
|
||||
- See: `frontmatter-standards.md`
|
||||
|
||||
### Menus
|
||||
- ✅ Handler section MUST follow display
|
||||
- ✅ "Halt and wait" in execution rules
|
||||
- ✅ A/P options only when appropriate
|
||||
- ✅ Non-C options redisplay menu
|
||||
- See: `menu-handling-standards.md`
|
||||
|
||||
### Progressive Disclosure
|
||||
- ✅ Only load next step when user selects 'C'
|
||||
- ✅ Read entire step file before execution
|
||||
- ✅ Don't create mental todos from future steps
|
||||
|
||||
### Continuable Workflows
|
||||
- ✅ Append step number to `stepsCompleted`
|
||||
- ✅ Don't hardcode full array
|
||||
- See: `workflow-type-criteria.md`
|
||||
|
||||
---
|
||||
|
||||
## Data Files Reference
|
||||
|
||||
| File | Purpose |
|
||||
| ----------------------- | --------------------------------------------- |
|
||||
| `frontmatter-standards.md` | Variables, paths, frontmatter rules |
|
||||
| `menu-handling-standards.md` | Menu patterns, handler requirements |
|
||||
| `output-format-standards.md` | Document output, template types |
|
||||
| `workflow-type-criteria.md` | Continuable, module, tri-modal decisions |
|
||||
| `step-type-patterns.md` | Templates for init/middle/final/branch steps |
|
||||
| `trimodal-workflow-structure.md` | Create/Edit/Validate folder structure |
|
||||
|
||||
---
|
||||
|
||||
## Step Type Reference
|
||||
|
||||
| Step Type | Template/Reference |
|
||||
| ------------------- | ------------------------------------------- |
|
||||
| Init (non-continuable) | Auto-proceed, no continuation logic |
|
||||
| Init (continuable) | `step-01-init-continuable-template.md` |
|
||||
| Continuation (01b) | `step-1b-template.md` |
|
||||
| Middle (standard) | A/P/C menu, collaborative content |
|
||||
| Middle (simple) | C only menu, no A/P |
|
||||
| Branch/Conditional | Custom menu options, routing to different steps |
|
||||
| Validation sequence | Auto-proceed through checks |
|
||||
| Final | No next step, completion message |
|
||||
|
||||
See: `step-type-patterns.md`
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Variables
|
||||
|
||||
### Standard (Always Available)
|
||||
- `{project-root}`
|
||||
- `{project_name}`
|
||||
- `{output_folder}`
|
||||
- `{user_name}`
|
||||
- `{communication_language}`
|
||||
- `{document_output_language}`
|
||||
|
||||
### Module-Specific (e.g., BMB)
|
||||
- `{bmb_creations_output_folder}`
|
||||
|
||||
### User-Defined
|
||||
- New variables can be defined in steps for future steps
|
||||
|
||||
See: `frontmatter-standards.md`
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For every step file:
|
||||
|
||||
- [ ] File < 200 lines (250 max)
|
||||
- [ ] `name` and `description` in frontmatter
|
||||
- [ ] All frontmatter variables are used
|
||||
- [ ] File references use `{variable}` format
|
||||
- [ ] Relative paths within workflow folder
|
||||
- [ ] Handler section follows menu display
|
||||
- [ ] "Halt and wait" in execution rules
|
||||
- [ ] A/P options appropriate for step type
|
||||
- [ ] C option saves and loads next step
|
||||
- [ ] Non-C options redisplay menu
|
||||
- [ ] StepsCompleted appended (if continuable)
|
||||
- [ ] Success/failure metrics present
|
||||
|
||||
---
|
||||
|
||||
## Quick Menu Reference
|
||||
|
||||
```markdown
|
||||
### N. Present MENU OPTIONS
|
||||
|
||||
Display: "**Select:** [A] [action A] [P] [action P] [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](#n-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
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Violations
|
||||
|
||||
| ❌ Violation | ✅ Fix |
|
||||
| ------------------------------------- | ---------------------------------------------- |
|
||||
| Unused variable in frontmatter | Remove unused variables |
|
||||
| Hardcoded file path | Use `{variable}` format |
|
||||
| A/P menu in step 1 | Remove A/P (inappropriate for init) |
|
||||
| Missing handler section | Add handler after menu display |
|
||||
| No "halt and wait" instruction | Add to EXECUTION RULES |
|
||||
| Hardcoded `stepsCompleted: [1,2,3]` | Append: "update stepsCompleted to add this step" |
|
||||
| File > 250 lines | Split into multiple steps or extract to /data/ |
|
||||
| Absolute path for same-folder ref | Use relative path or `{workflow_path}` |
|
||||
|
||||
---
|
||||
|
||||
## When to Extract to Data Files
|
||||
|
||||
Extract step content to `/data/` when:
|
||||
- Step file exceeds 200 lines
|
||||
- Content is reference material
|
||||
- Content is reused across steps
|
||||
- Content is domain-specific (examples, patterns)
|
||||
|
||||
**Data file types:**
|
||||
- `.md` - Reference documentation
|
||||
- `.csv` - Structured data for lookup
|
||||
- `examples/` - Reference implementations
|
||||
|
||||
---
|
||||
|
||||
## Tri-Modal Workflow Note
|
||||
|
||||
For Create/Edit/Validate workflows:
|
||||
- Each mode has its own `steps-c/`, `steps-e/`, `steps-v/` folder
|
||||
- NO shared step files (`s-*.md`) between modes
|
||||
- All modes share `/data/` folder
|
||||
- This prevents confusion and routing errors
|
||||
|
||||
See: `trimodal-workflow-structure.md`
|
||||
312
src/modules/bmb/workflows/workflow/data/step-type-patterns.md
Normal file
312
src/modules/bmb/workflows/workflow/data/step-type-patterns.md
Normal file
@@ -0,0 +1,312 @@
|
||||
# Step Type Patterns
|
||||
|
||||
**Purpose:** Templates for different step types.
|
||||
|
||||
---
|
||||
|
||||
## Core Step Structure
|
||||
|
||||
All steps share this skeleton:
|
||||
```markdown
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
description: '[what it does]'
|
||||
[file references - ONLY used variables]
|
||||
---
|
||||
|
||||
# Step [N]: [Name]
|
||||
|
||||
## STEP GOAL:
|
||||
[Single sentence goal]
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
### Universal Rules:
|
||||
- 🛑 NEVER generate content without user input
|
||||
- 📖 CRITICAL: Read complete step file before action
|
||||
- 🔄 CRITICAL: When loading next with 'C', read entire file
|
||||
- 📋 YOU ARE A FACILITATOR, not content generator
|
||||
|
||||
### Role Reinforcement:
|
||||
- ✅ You are [specific role]
|
||||
- ✅ Collaborative dialogue, not command-response
|
||||
- ✅ You bring [expertise], user brings [theirs]
|
||||
|
||||
### Step-Specific Rules:
|
||||
- 🎯 Focus only on [specific task]
|
||||
- 🚫 FORBIDDEN to [prohibited action]
|
||||
- 💬 Approach: [how to engage]
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
||||
- 💾 [Additional protocol]
|
||||
- 📖 [Additional protocol]
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
- Available context: [what's available]
|
||||
- Focus: [what to focus on]
|
||||
- Limits: [boundaries]
|
||||
- Dependencies: [what this depends on]
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
||||
|
||||
### 1. [First action]
|
||||
[Instructions]
|
||||
|
||||
### N. Present MENU OPTIONS
|
||||
[Menu section - see menu-handling-standards.md]
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
||||
### ✅ SUCCESS: [criteria]
|
||||
### ❌ SYSTEM FAILURE: [criteria]
|
||||
**Master Rule:** Skipping steps is FORBIDDEN.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step Types
|
||||
|
||||
### 1. Init Step (Non-Continuable)
|
||||
|
||||
**Use:** Single-session workflow
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize [workflow]'
|
||||
thisStepFile: '{workflow_path}/steps/step-01-init.md'
|
||||
nextStepFile: '{workflow_path}/steps/step-02-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
templateFile: '{workflow_path}/templates/[template].md'
|
||||
---
|
||||
```
|
||||
|
||||
**Characteristics:**
|
||||
- No continuation detection
|
||||
- Auto-proceeds to step 2
|
||||
- No A/P menu
|
||||
- Creates output from template
|
||||
|
||||
**Menu:** Auto-proceed (no user choice)
|
||||
|
||||
### 2. Init Step (Continuable)
|
||||
|
||||
**Use:** Multi-session workflow
|
||||
|
||||
**Frontmatter:** Add `continueFile` reference
|
||||
```yaml
|
||||
continueFile: '{workflow_path}/steps/step-01b-continue.md'
|
||||
```
|
||||
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Check for Existing Workflow
|
||||
- Look for {outputFile}
|
||||
- If exists AND has stepsCompleted → STOP, load {continueFile}
|
||||
- If not exists → continue to setup
|
||||
```
|
||||
|
||||
**Reference:** `step-01-init-continuable-template.md`
|
||||
|
||||
### 3. Continuation Step (01b)
|
||||
|
||||
**Use:** Paired with continuable init
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01b-continue'
|
||||
description: 'Handle workflow continuation'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
workflowFile: '{workflow_path}/workflow.md'
|
||||
---
|
||||
```
|
||||
|
||||
**Logic:**
|
||||
1. Read `stepsCompleted` array from output
|
||||
2. Read last completed step file to find nextStep
|
||||
3. Welcome user back
|
||||
4. Route to appropriate step
|
||||
|
||||
**Reference:** `step-1b-template.md`
|
||||
|
||||
### 4. Middle Step (Standard)
|
||||
|
||||
**Use:** Collaborative content generation
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-[name]'
|
||||
nextStepFile: '{workflow_path}/steps/step-[N+1]-[name].md'
|
||||
outputFile: '{output_folder}/[output].md'
|
||||
advancedElicitationTask: '{project-root}/.../advanced-elicitation/workflow.xml'
|
||||
partyModeWorkflow: '{project-root}/.../party-mode/workflow.md'
|
||||
---
|
||||
```
|
||||
|
||||
**Menu:** A/P/C pattern
|
||||
|
||||
### 5. Middle Step (Simple)
|
||||
|
||||
**Use:** Data gathering, no refinement needed
|
||||
|
||||
**Menu:** C only (no A/P)
|
||||
|
||||
### 6. Branch Step
|
||||
|
||||
**Use:** User choice determines next path
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
nextStepFile: '{workflow_path}/steps/step-[default].md'
|
||||
altStepFile: '{workflow_path}/steps/step-[alternate].md'
|
||||
```
|
||||
|
||||
**Menu:** Custom letters (L/R/etc.) with branching logic
|
||||
|
||||
### 7. Validation Sequence Step
|
||||
|
||||
**Use:** Multiple checks without user interruption
|
||||
|
||||
**Menu:** Auto-proceed to next validation
|
||||
|
||||
**Pattern:**
|
||||
```markdown
|
||||
## 1. Perform validation check
|
||||
[Check logic]
|
||||
|
||||
## 2. Write results to {outputFile}
|
||||
Append findings
|
||||
|
||||
## 3. Proceed to next validation
|
||||
Display: "**Proceeding to next check...**"
|
||||
→ Immediately load {nextValidationStep}
|
||||
```
|
||||
|
||||
### 8. Init Step (With Input Discovery)
|
||||
|
||||
**Use:** Workflow that requires documents from prior workflows or external sources
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-01-init'
|
||||
description: 'Initialize and discover input documents'
|
||||
inputDocuments: []
|
||||
requiredInputCount: 1
|
||||
moduleInputFolder: '{module_output_folder}'
|
||||
inputFilePatterns:
|
||||
- '*-prd.md'
|
||||
- '*-ux.md'
|
||||
---
|
||||
```
|
||||
|
||||
**Characteristics:**
|
||||
- Discovers documents from prior workflows
|
||||
- Searches by folder, pattern, or user-provided paths
|
||||
- Validates inputs are complete
|
||||
- User confirms which documents to use
|
||||
- Auto-proceeds when required inputs found
|
||||
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Discover Required Inputs
|
||||
Search {moduleInputFolder} for {inputFilePatterns}
|
||||
Search {project_folder}/docs/ for {inputFilePatterns}
|
||||
|
||||
## 2. Present Findings
|
||||
"Found these documents:
|
||||
[1] prd-my-project.md (3 days ago) ✓
|
||||
[2] ux-research.md (1 week ago)
|
||||
Which would you like to use?"
|
||||
|
||||
## 3. Validate and Load
|
||||
Check workflowType, stepsCompleted, date
|
||||
Load selected documents
|
||||
Add to {inputDocuments} array
|
||||
|
||||
## 4. Auto-Proceed
|
||||
If all required inputs found → proceed to step 2
|
||||
If missing → Error with guidance
|
||||
```
|
||||
|
||||
**Reference:** `input-discovery-standards.md`
|
||||
|
||||
### 9. Final Polish Step
|
||||
|
||||
**Use:** Optimizes document built section-by-section
|
||||
|
||||
**Frontmatter:**
|
||||
```yaml
|
||||
---
|
||||
name: 'step-[N]-polish'
|
||||
description: 'Optimize and finalize document'
|
||||
outputFile: '{output_folder}/[document].md'
|
||||
---
|
||||
```
|
||||
|
||||
**Characteristics:**
|
||||
- Loads entire document
|
||||
- Reviews for flow and coherence
|
||||
- Reduces duplication
|
||||
- Ensures proper ## Level 2 headers
|
||||
- Improves transitions
|
||||
- Keeps general order but optimizes readability
|
||||
|
||||
**Logic:**
|
||||
```markdown
|
||||
## 1. Load Complete Document
|
||||
Read {outputFile} entirely
|
||||
|
||||
## 2. Document Optimization
|
||||
Review entire document for:
|
||||
1. Flow and coherence
|
||||
2. Duplication (remove while preserving essential info)
|
||||
3. Proper ## Level 2 section headers
|
||||
4. Smooth transitions between sections
|
||||
5. Overall readability
|
||||
|
||||
## 3. Optimize
|
||||
Make improvements while maintaining:
|
||||
- General order of sections
|
||||
- Essential information
|
||||
- User's voice and intent
|
||||
|
||||
## 4. Final Output
|
||||
Save optimized document
|
||||
Mark workflow complete
|
||||
```
|
||||
|
||||
**Use for:** Free-form output workflows (most document-producing workflows)
|
||||
|
||||
### 10. Final Step
|
||||
|
||||
**Use:** Last step, completion
|
||||
|
||||
**Frontmatter:** No `nextStepFile`
|
||||
|
||||
**Logic:**
|
||||
- Update frontmatter to mark workflow complete
|
||||
- Provide final summary
|
||||
- No next step
|
||||
|
||||
---
|
||||
|
||||
## Step Size Guidelines
|
||||
|
||||
| Type | Recommended | Maximum |
|
||||
| ------------------------ | ----------- | ------- |
|
||||
| Init | < 100 | 150 |
|
||||
| Init (with discovery) | < 150 | 200 |
|
||||
| Continuation | < 150 | 200 |
|
||||
| Middle (simple) | < 150 | 200 |
|
||||
| Middle (complex) | < 200 | 250 |
|
||||
| Branch | < 150 | 200 |
|
||||
| Validation sequence | < 100 | 150 |
|
||||
| Final polish | < 150 | 200 |
|
||||
| Final | < 150 | 200 |
|
||||
|
||||
**If exceeded:** Split into multiple steps or extract to `/data/` files.
|
||||
@@ -0,0 +1,209 @@
|
||||
# Tri-Modal Workflow Structure
|
||||
|
||||
**Purpose:** The golden rule standard for complex critical workflows that require create, validate, and edit capabilities.
|
||||
|
||||
---
|
||||
|
||||
## The Golden Rule
|
||||
|
||||
**For complex critical workflows: Implement tri-modal structure (create/validate/edit) with cross-mode integration.**
|
||||
|
||||
This pattern ensures:
|
||||
- Quality through standalone validation
|
||||
- Maintainability through dedicated edit mode
|
||||
- Flexibility through conversion paths for non-compliant input
|
||||
|
||||
**Cross-mode integration patterns:**
|
||||
- Create → Validation (handoff after build)
|
||||
- Edit → Validation (verify changes)
|
||||
- Edit → Create/conversion (for non-compliant input)
|
||||
- Validation → Edit (fix issues found)
|
||||
- All modes run standalone via workflow.md routing
|
||||
|
||||
---
|
||||
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
workflow-name/
|
||||
├── workflow.md # Entry point with mode routing
|
||||
├── data/ # SHARED standards and reference
|
||||
│ ├── [domain]-standards.md
|
||||
│ └── [domain]-patterns.md
|
||||
├── steps-c/ # Create (self-contained)
|
||||
│ ├── step-00-conversion.md # Entry for non-compliant input
|
||||
│ ├── step-01-init.md
|
||||
│ └── step-N-complete.md
|
||||
├── steps-e/ # Edit (self-contained)
|
||||
│ ├── step-01-assess.md # Checks compliance, routes if needed
|
||||
│ └── step-N-complete.md
|
||||
└── steps-v/ # Validate (self-contained, runs standalone)
|
||||
└── step-01-validate.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Mode Responsibilities
|
||||
|
||||
### Create Mode (steps-c/)
|
||||
|
||||
**Primary:** Build new entities from scratch
|
||||
**Secondary:** Convert non-compliant input via step-00-conversion
|
||||
|
||||
**Key patterns:**
|
||||
- step-00-conversion: Loads non-compliant input, extracts essence, creates plan with `conversionFrom` metadata
|
||||
- Final step routes to validation (optional but recommended)
|
||||
- Confirmation step checks `conversionFrom` to verify coverage vs new workflow
|
||||
|
||||
### Edit Mode (steps-e/)
|
||||
|
||||
**Primary:** Modify existing compliant entities
|
||||
**Secondary:** Detect non-compliance and route to conversion
|
||||
|
||||
**Key patterns:**
|
||||
- step-01-assess: Checks compliance first
|
||||
- Non-compliant → Offer route to step-00-conversion (not step-01-discovery)
|
||||
- Post-edit → Offer validation (reuse validation workflow)
|
||||
- During edits → Check standards, offer to fix non-compliance
|
||||
|
||||
### Validate Mode (steps-v/)
|
||||
|
||||
**Primary:** Standalone validation against standards
|
||||
**Secondary:** Generates actionable reports
|
||||
|
||||
**Key patterns:**
|
||||
- Runs standalone (invoked via -v flag or direct call)
|
||||
- Auto-proceeds through all checks
|
||||
- Generates report with issue severity
|
||||
- Report consumed by edit mode for fixes
|
||||
|
||||
---
|
||||
|
||||
## workflow.md Routing Pattern
|
||||
|
||||
```yaml
|
||||
## INITIALIZATION SEQUENCE
|
||||
|
||||
### 1. Mode Determination
|
||||
|
||||
**Check invocation:**
|
||||
- "create" / -c → mode = create
|
||||
- "validate" / -v → mode = validate
|
||||
- "edit" / -e → mode = edit
|
||||
|
||||
**If create mode:** Ask "From scratch or convert existing?"
|
||||
- From scratch → steps-c/step-01-init.md
|
||||
- Convert → steps-c/step-00-conversion.md
|
||||
|
||||
**If unclear:** Ask user to select mode
|
||||
|
||||
### 2. Route to First Step
|
||||
|
||||
**IF mode == create:**
|
||||
Route to appropriate create entry (init or conversion)
|
||||
|
||||
**IF mode == validate:**
|
||||
Prompt for path → load steps-v/step-01-validate.md
|
||||
|
||||
**IF mode == edit:**
|
||||
Prompt for path → load steps-e/step-01-assess.md
|
||||
```
|
||||
|
||||
**Critical:** workflow.md is lean. No step listings. Only routing logic.
|
||||
|
||||
---
|
||||
|
||||
## Cross-Mode Integration Points
|
||||
|
||||
### 1. Edit → Create (Non-Compliant Detection)
|
||||
|
||||
**In edit step-01-assess:**
|
||||
```yaml
|
||||
Check workflow compliance:
|
||||
- Compliant → Continue to edit steps
|
||||
- Non-compliant → Offer conversion
|
||||
- IF user accepts: Load steps-c/step-00-conversion.md with sourceWorkflowPath
|
||||
```
|
||||
|
||||
### 2. Create/Edit → Validation
|
||||
|
||||
**Both create and edit can invoke validation:**
|
||||
```yaml
|
||||
# In create final step or edit post-edit step
|
||||
Offer: "Run validation?"
|
||||
- IF yes: Load ../steps-v/step-01-validate.md
|
||||
- Validation runs standalone, returns report
|
||||
- Resume create/edit with validation results
|
||||
```
|
||||
|
||||
### 3. Validation → Edit
|
||||
|
||||
**After validation generates report:**
|
||||
```yaml
|
||||
# User can invoke edit mode with report as input
|
||||
"Fix issues found?"
|
||||
- IF yes: Load steps-e/step-01-assess.md with validationReport path
|
||||
```
|
||||
|
||||
### 4. Conversion Coverage Tracking
|
||||
|
||||
**In create step-10-confirmation:**
|
||||
```yaml
|
||||
Check workflowPlan metadata:
|
||||
- IF conversionFrom exists:
|
||||
- Load original workflow
|
||||
- Compare each step/instruction
|
||||
- Report coverage percentage
|
||||
- ELSE (new workflow):
|
||||
- Validate all plan requirements implemented
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## When to Use Tri-Modal
|
||||
|
||||
**Use Tri-Modal for:**
|
||||
- Complex workflows requiring quality assurance
|
||||
- Workflows that will be maintained over time
|
||||
- Workflows where non-compliant input may be offered
|
||||
- Critical workflows where standards compliance matters
|
||||
|
||||
**Use Create-Only for:**
|
||||
- Simple one-off workflows
|
||||
- Experimental workflows
|
||||
- Workflows unlikely to need editing or validation
|
||||
|
||||
---
|
||||
|
||||
## Frontmatter Standards for Cross-Mode References
|
||||
|
||||
**Never inline file paths. Always use frontmatter variables:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
# Create mode step calling validation
|
||||
validationWorkflow: '../steps-v/step-01-validate.md'
|
||||
---
|
||||
|
||||
# Edit mode step routing to conversion
|
||||
conversionStep: '../steps-c/step-00-conversion.md'
|
||||
---
|
||||
|
||||
# Create conversion step receiving from edit
|
||||
sourceWorkflowPath: '{targetWorkflowPath}' # Passed from edit
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For tri-modal workflow design:
|
||||
- [ ] Each mode has self-contained steps folder
|
||||
- [ ] No shared step files (shared data in /data/ only)
|
||||
- [ ] workflow.md has lean routing (no step listings)
|
||||
- [ ] Edit mode checks compliance, routes to conversion if needed
|
||||
- [ ] Create mode has step-00-conversion for non-compliant input
|
||||
- [ ] Create/Edit can invoke validation workflow
|
||||
- [ ] Validation runs standalone and generates reports
|
||||
- [ ] Confirmation step checks `conversionFrom` metadata
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user