Ignore and untrack BMad directories
This commit is contained in:
Max
@@ -1,109 +0,0 @@
|
||||
---
|
||||
name: 'step-01-validate'
|
||||
description: 'Initialize validation: create report and check file structure & size'
|
||||
|
||||
parallel-steps: ['./step-01b-structure.md', './step-02-frontmatter-validation.md', './step-02b-path-violations.md', './step-03-menu-validation.md' './step-04-step-type-validation.md', './step-05-output-format-validation.md', './step-06-validation-design-check.md', './step-07-instruction-style-check.md', './step-08-collaborative-experience-check.md', './step-08b-subprocess-optimization.md', './step-09-cohesive-review.md']
|
||||
nextStep: './step-10-report-complete.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
partialValidationFragmentFile: '{workflow_folder_path}/validation-report-{step-name}.md'
|
||||
stepFileRules: '../data/step-file-rules.md'
|
||||
---
|
||||
|
||||
# Validation Step 1: File Structure & Size
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To create the validation report that all parallel tasks that this will kick off will be able to report to.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Create validation report with header structure using subprocess optimization when available
|
||||
- 🚫 DO NOT skip checking any file - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load and check EVERY file in the workflow using subprocess optimization when available - single subprocess for bash/grep operations, separate subprocess per file for size analysis
|
||||
- 💾 Subprocesses must either update validation report OR return findings for parent aggregation
|
||||
- 📖 Save report before loading next validation step
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut. IF there is no subprocess type tool available that can achieve running a process in a subprocess and handle starting multiple - let the user know they need to restart validation specifically NOT using max-parallel mode and HALT and end this workflow!
|
||||
|
||||
### 1. Create Validation Report
|
||||
|
||||
Create {validationReportFile} with header structure:
|
||||
|
||||
```markdown
|
||||
---
|
||||
validationDate: [current date]
|
||||
workflowName: {new_workflow_name}
|
||||
workflowPath: {workflow_folder_path}
|
||||
validationStatus: IN_PROGRESS
|
||||
---
|
||||
|
||||
# Validation Report: {new_workflow_name}
|
||||
|
||||
**Validation Started:** [current date]
|
||||
**Validator:** BMAD Workflow Validation System
|
||||
**Standards Version:** BMAD Workflow Standards
|
||||
|
||||
{{TOC}}
|
||||
|
||||
{{#each parallel-steps}}
|
||||
## {{title}}
|
||||
|
||||
{{results}}
|
||||
|
||||
{{/each}}
|
||||
|
||||
```
|
||||
|
||||
Save the file (without the handlebars output of course) before proceeding.
|
||||
|
||||
### 2. Launch Mass Parallelization and consolidate results!
|
||||
|
||||
Utilizing a subprocess for each step file in {parallel-steps} - complete all of these - with the caveat indication to the subprocess that at the end of the specific step it will not on its own proceed to the nextStep file!
|
||||
|
||||
Critically - instruct that instructions to write out or return results within each subprocess for a step file in the array MUST ensure that it writes it to {partialValidationFragmentFile} file name even though the step file it loads might indicate otherwise!
|
||||
|
||||
Once every process has completed - there should be a separate validation file for each given step. Also - each step should return JUST its results and recommendations to you also.
|
||||
|
||||
### 3. CRITICAL WRITES to the report.
|
||||
|
||||
You MUST now ensure that all results are added to the final cohesive {validationReportFile} following the indicated handlebars sequence - and then after appending each subprocess report to a level 2 section - and the TOC to accurately reflect the documents state using proper markdown linking conventions to the actual heading names you created.
|
||||
|
||||
IF a file is missing or empty from a given subprocess - but it did return to you results - you will append those results - ONLY do this if you cannot access the specific steps file produced or it is empty though. IE File from subprocess is primary, results returned from step complete are backup insurance.
|
||||
|
||||
### 4. Proceed to Completion Step
|
||||
|
||||
ONLY after ensuring all has been written to the final report, let the user know about the final report that is a consolidation - and they can ignore or remove the smaller files or use them as they like to focus on a specific validation (but its all in the master doc), and then proceed to {nextStep}, ensuring that in the {nextStep} it is focused on the {validationReportFile}
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Validation report created with header structure
|
||||
- EVERY section of the template is filled in with content from a subprocess that added the results of its area of expertise
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Output Report does not exist with content all filled in
|
||||
- EVERY step listed in {parallel-steps} was not executed in a subprocess and completed with its results captured in output
|
||||
@@ -1,221 +0,0 @@
|
||||
---
|
||||
name: 'step-01-validate'
|
||||
description: 'Initialize validation: create report and check file structure & size'
|
||||
|
||||
nextStepFile: './step-02-frontmatter-validation.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
stepFileRules: '../data/step-file-rules.md'
|
||||
---
|
||||
|
||||
# Validation Step 1: File Structure & Size
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To create the validation report and check that the workflow has correct file structure and all step files are within size limits.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Create validation report with header structure using subprocess optimization when available
|
||||
- 🚫 DO NOT skip checking any file - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load and check EVERY file in the workflow using subprocess optimization when available - single subprocess for bash/grep operations, separate subprocess per file for size analysis
|
||||
- 💾 Subprocesses must either update validation report OR return findings for parent aggregation
|
||||
- 📖 Save report before loading next validation step
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Create Validation Report
|
||||
|
||||
Create {validationReportFile} with header structure:
|
||||
|
||||
```markdown
|
||||
---
|
||||
validationDate: [current date]
|
||||
workflowName: {new_workflow_name}
|
||||
workflowPath: {workflow_folder_path}
|
||||
validationStatus: IN_PROGRESS
|
||||
---
|
||||
|
||||
# Validation Report: {new_workflow_name}
|
||||
|
||||
**Validation Started:** [current date]
|
||||
**Validator:** BMAD Workflow Validation System
|
||||
**Standards Version:** BMAD Workflow Standards
|
||||
|
||||
---
|
||||
|
||||
## File Structure & Size
|
||||
|
||||
*Validation in progress...*
|
||||
|
||||
## Frontmatter Validation
|
||||
*Pending...*
|
||||
|
||||
## Critical Path Violations
|
||||
*Pending...*
|
||||
|
||||
## Menu Handling Validation
|
||||
*Pending...*
|
||||
|
||||
## Step Type Validation
|
||||
*Pending...*
|
||||
|
||||
## Output Format Validation
|
||||
*Pending...*
|
||||
|
||||
## Validation Design Check
|
||||
*Pending...*
|
||||
|
||||
## Instruction Style Check
|
||||
*Pending...*
|
||||
|
||||
## Collaborative Experience Check
|
||||
*Pending...*
|
||||
|
||||
## Subprocess Optimization Opportunities
|
||||
*Pending...*
|
||||
|
||||
## Cohesive Review
|
||||
*Pending...*
|
||||
|
||||
## Plan Quality Validation
|
||||
*Pending...*
|
||||
|
||||
## Summary
|
||||
*Pending...*
|
||||
```
|
||||
|
||||
### 2. Load File Structure Standards
|
||||
|
||||
Load {stepFileRules} to understand:
|
||||
- File size limits (<200 recommended, 250 max)
|
||||
- Required folder structure
|
||||
- Required files
|
||||
|
||||
### 3. Check Folder Structure
|
||||
|
||||
**Launch a single subprocess that:**
|
||||
|
||||
1. Lists the entire folder structure using bash commands
|
||||
2. Verifies all required folders and files exist
|
||||
3. Returns structured findings to parent for aggregation
|
||||
|
||||
```bash
|
||||
# List folder structure
|
||||
find {targetWorkflowPath} -type f -name "*.md" | sort
|
||||
```
|
||||
|
||||
**Expected structure:**
|
||||
```
|
||||
{targetWorkflowPath}/
|
||||
├── workflow.md
|
||||
├── steps*/ potentially more than one folder like this (such as steps-v, steps-c - the folder name is not critical but should make sense)
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-01b-continue.md (if continuable)
|
||||
│ ├── step-02-*.md
|
||||
│ └── ...
|
||||
├── */ # any other random files - critical will be later ensure its all used - aside from potential documentation for user later.
|
||||
├── data/
|
||||
│ └── [as needed]
|
||||
└── templates/
|
||||
└── [as needed]
|
||||
```
|
||||
|
||||
**Check:**
|
||||
- ✅ workflow.md exists
|
||||
- ✅ step files are in a well organized folder
|
||||
- ✅ non step reference files are organized in other folders such as data, templates, or others that make sense for the workflow
|
||||
- ✅ Folder names make sense
|
||||
|
||||
### 4. Check File Sizes
|
||||
|
||||
**DO NOT BE LAZY - For EACH step file in steps-c/, launch a subprocess that:**
|
||||
|
||||
1. Loads that step file
|
||||
2. Counts lines and checks against size limits
|
||||
3. Returns structured findings to parent for aggregation
|
||||
|
||||
**Limits:**
|
||||
- < 200 lines: ✅ Good
|
||||
- 200-250 lines: ⚠️ Approaching limit
|
||||
- > 250 lines: ❌ Exceeds limit
|
||||
|
||||
**Subprocess returns:** File name, line count, status (Good/Approaching limit/Exceeds limit), and any issues found.
|
||||
|
||||
**Subprocess must either:**
|
||||
- Update validation report directly with findings, OR
|
||||
- Return structured findings to parent for aggregation into report
|
||||
|
||||
**Document findings in validation report:**
|
||||
- List all step files checked with their line counts
|
||||
- Note any files approaching or exceeding size limits (<200 recommended, 250 max)
|
||||
- Check data and reference files for size issues (large files should be sharded or indexed)
|
||||
- Identify specific size violations and recommendations
|
||||
|
||||
### 5. Verify File Presence
|
||||
|
||||
From the design in {workflowPlanFile}, verify:
|
||||
- Every step from design has a corresponding file
|
||||
- Step files are numbered sequentially
|
||||
- No gaps in numbering
|
||||
- Final step exists
|
||||
|
||||
### 6. Append Findings to Report
|
||||
|
||||
Replace the "## File Structure & Size" section in {validationReportFile} with actual findings:
|
||||
|
||||
**Document the following:**
|
||||
- Folder structure assessment
|
||||
- Required files presence check
|
||||
- File size analysis results
|
||||
- List of any issues found (missing files, extra files, size violations, naming issues)
|
||||
- Overall validation status (PASS/FAIL/WARNINGS)
|
||||
|
||||
### 7. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**File Structure & Size validation complete.** Proceeding to Frontmatter Validation..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Validation report created with header structure
|
||||
- EVERY file checked for structure and size
|
||||
- Findings appended to report
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking every file
|
||||
- Skipping size checks
|
||||
- Not saving report before proceeding
|
||||
- Halting for user input
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY file. Auto-proceed through all validation steps.
|
||||
@@ -1,152 +0,0 @@
|
||||
---
|
||||
name: 'step-01-validate'
|
||||
description: 'Initialize validation: create report and check file structure & size'
|
||||
|
||||
nextStepFile: './step-02-frontmatter-validation.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
stepFileRules: '../data/step-file-rules.md'
|
||||
---
|
||||
|
||||
# Validation Step 1: File Structure & Size
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To create the validation report and check that the workflow has correct file structure and all step files are within size limits.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Create validation report with header structure using subprocess optimization when available
|
||||
- 🚫 DO NOT skip checking any file - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load and check EVERY file in the workflow using subprocess optimization when available - single subprocess for bash/grep operations, separate subprocess per file for size analysis
|
||||
- 💾 Subprocesses must either update validation report OR return findings for parent aggregation
|
||||
- 📖 Save report before loading next validation step
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Check Folder Structure
|
||||
|
||||
**Launch a single subprocess that will do all of the following for items:**
|
||||
|
||||
1. Load {stepFileRules} to understand:
|
||||
- File size limits (<200 recommended, 250 max)
|
||||
- Required folder structure
|
||||
- Required files
|
||||
2. Lists the entire folder structure using bash commands
|
||||
3. Verifies all required folders and files exist
|
||||
4. Returns structured findings to parent for aggregation
|
||||
|
||||
```bash
|
||||
# List folder structure
|
||||
find {targetWorkflowPath} -type f -name "*.md" | sort
|
||||
```
|
||||
|
||||
**Expected structure:**
|
||||
```
|
||||
{targetWorkflowPath}/
|
||||
├── workflow.md
|
||||
├── steps*/ potentially more than one folder like this (such as steps-v, steps-c - the folder name is not critical but should make sense)
|
||||
│ ├── step-01-init.md
|
||||
│ ├── step-01b-continue.md (if continuable)
|
||||
│ ├── step-02-*.md
|
||||
│ └── ...
|
||||
├── */ # any other random files - critical will be later ensure its all used - aside from potential documentation for user later.
|
||||
├── data/
|
||||
│ └── [as needed]
|
||||
└── templates/
|
||||
└── [as needed]
|
||||
```
|
||||
|
||||
**Check:**
|
||||
- ✅ workflow.md exists
|
||||
- ✅ step files are in a well organized folder
|
||||
- ✅ non step reference files are organized in other folders such as data, templates, or others that make sense for the workflow
|
||||
- ✅ Folder names make sense
|
||||
|
||||
### 4. Check File Sizes
|
||||
|
||||
**DO NOT BE LAZY - For EACH step file in steps-c/, launch a subprocess that:**
|
||||
|
||||
1. Loads that step file
|
||||
2. Counts lines and checks against size limits
|
||||
3. Returns structured findings to parent for aggregation
|
||||
|
||||
**Limits:**
|
||||
- < 200 lines: ✅ Good
|
||||
- 200-300 lines: ⚠️ Approaching limit
|
||||
- > 300 lines: ❌ Exceeds limit
|
||||
|
||||
**Subprocess returns:** File name, line count, status (Good/Approaching limit/Exceeds limit), and any issues found.
|
||||
|
||||
**Subprocess must either:**
|
||||
- Update validation report directly with findings, OR
|
||||
- Return structured findings to parent for aggregation into report
|
||||
|
||||
**Document findings in validation report:**
|
||||
- List all step files checked with their line counts
|
||||
- Note any files approaching or exceeding size limits (<200 recommended, 250 max)
|
||||
- Check data and reference files for size issues (large files should be sharded or indexed)
|
||||
- Identify specific size violations and recommendations
|
||||
|
||||
### 5. Verify File Presence
|
||||
|
||||
From the design in {workflowPlanFile}, verify:
|
||||
- Every step from design has a corresponding file
|
||||
- Step files are numbered sequentially
|
||||
- No gaps in numbering
|
||||
- Final step exists
|
||||
|
||||
### 6. Document all findings in a report
|
||||
|
||||
**Document the following:**
|
||||
- Folder structure assessment
|
||||
- Required files presence check
|
||||
- File size analysis results
|
||||
- List of any issues found (missing files, extra files, size violations, naming issues)
|
||||
- Overall validation status (PASS/FAIL/WARNINGS)
|
||||
|
||||
### 7. Save Report
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE COMPLETING THIS STEP
|
||||
|
||||
**Display:** "**File Structure & Size validation complete.**"
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Validation report created with header structure
|
||||
- EVERY file checked for structure and size
|
||||
- Findings appended to report
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking every file
|
||||
- Skipping size checks
|
||||
- Not saving report before proceeding
|
||||
- Halting for user input
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY file. Auto-proceed through all validation steps.
|
||||
@@ -1,199 +0,0 @@
|
||||
---
|
||||
name: 'step-02-frontmatter-validation'
|
||||
description: 'Validate frontmatter compliance across all step files'
|
||||
|
||||
nextStepFile: './step-02b-path-violations.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
frontmatterStandards: '../data/frontmatter-standards.md'
|
||||
---
|
||||
|
||||
# Validation Step 2: Frontmatter Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate that EVERY step file's frontmatter follows the frontmatter standards - correct variables, proper relative paths, NO unused variables.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - VALIDATE EVERY FILE'S FRONTMATTER
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Validate EVERY step file's frontmatter using subprocess optimization - each file in its own subprocess
|
||||
- 🚫 DO NOT skip any files or checks - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough using per-file deep analysis (Pattern 2)
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load frontmatter standards first, then validate each file in its own subprocess for deep analysis
|
||||
- 💾 Subprocesses must either update validation report OR return findings for parent aggregation
|
||||
- 📖 Aggregate all findings into validation report before loading next step
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All step files in the workflow must be validated
|
||||
- Load {frontmatterStandards} for validation criteria
|
||||
- Check for: unused variables, non-relative paths, missing required fields, forbidden patterns
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Load Frontmatter Standards
|
||||
|
||||
Load {frontmatterStandards} to understand validation criteria.
|
||||
|
||||
**Key Rules:**
|
||||
1. Only variables USED in the step may be in frontmatter
|
||||
2. All file references MUST use `{variable}` format
|
||||
3. Paths within workflow folder MUST be relative - NO `workflow_path` allowed
|
||||
|
||||
**Forbidden Patterns:**
|
||||
- `workflow_path: '...'` - use relative paths instead
|
||||
- `thisStepFile: '...'` - remove unless actually referenced in body
|
||||
- `workflowFile: '...'` - remove unless actually referenced in body
|
||||
- `./...` - use `./step-XX.md`
|
||||
- `{workflow_path}/templates/...` - use `../template.md`
|
||||
|
||||
### 2. Validate EVERY Step File - Systematic Algorithm with Subprocess Optimization
|
||||
|
||||
**DO NOT BE LAZY - For EACH step file, launch a subprocess that:**
|
||||
|
||||
1. Loads that file
|
||||
2. Loads {frontmatterStandards} to understand validation criteria
|
||||
3. Performs all frontmatter validation checks on that file (extract variables, check usage, validate paths)
|
||||
4. **EITHER** updates the validation report directly with its findings
|
||||
5. **OR** returns structured findings to parent for aggregation
|
||||
|
||||
**SUBPROCESS ANALYSIS PATTERN:**
|
||||
|
||||
For each file, the subprocess performs the following deep analysis:
|
||||
|
||||
#### Step 2.1: Extract Frontmatter Variables
|
||||
|
||||
```python
|
||||
# Algorithm to extract variables from frontmatter:
|
||||
1. Find content between first `---` and second `---`
|
||||
2. For each line, extract key before `:`
|
||||
3. Skip `name`, `description`, and comment lines starting with `#`
|
||||
4. Collect all variable names
|
||||
```
|
||||
|
||||
Example frontmatter:
|
||||
```yaml
|
||||
---
|
||||
# File References
|
||||
nextStepFile: './step-02-vision.md'
|
||||
outputFile: '{planning_artifacts}/product-brief-{{project_name}}.md'
|
||||
workflow_path: '{project-root}/...' # ❌ FORBIDDEN
|
||||
thisStepFile: './step-01-init.md' # ❌ Likely unused
|
||||
---
|
||||
```
|
||||
|
||||
Variables extracted: `nextStepFile`, `outputFile`, `workflow_path`, `thisStepFile`
|
||||
|
||||
#### Step 2.2: Check Each Variable Is Used
|
||||
|
||||
```python
|
||||
# Algorithm to check variable usage:
|
||||
for each variable in extracted_variables:
|
||||
search_body = "{variableName}" # with curly braces
|
||||
if search_body NOT found in step body (after frontmatter):
|
||||
MARK_AS_UNUSED(variable)
|
||||
```
|
||||
|
||||
**Example:**
|
||||
- Variable `nextStepFile`: Search body for `{nextStepFile}` → Found in line 166 ✅
|
||||
- Variable `thisStepFile`: Search body for `{thisStepFile}` → Not found ❌ VIOLATION
|
||||
|
||||
#### Step 2.3: Check Path Formats
|
||||
|
||||
For each variable containing a file path:
|
||||
|
||||
```python
|
||||
# Algorithm to validate paths:
|
||||
if path contains "{workflow_path}":
|
||||
MARK_AS_VIOLATION("workflow_path is forbidden - use relative paths")
|
||||
|
||||
if path is to another step file:
|
||||
if not path.startswith("./step-"):
|
||||
MARK_AS_VIOLATION("Step-to-step paths must be ./filename.md")
|
||||
|
||||
if path is to parent folder template:
|
||||
if not path.startswith("../"):
|
||||
MARK_AS_VIOLATION("Parent folder paths must be ../filename.md")
|
||||
|
||||
if path contains "{project-root}" and is internal workflow reference:
|
||||
MARK_AS_VIOLATION("Internal paths must be relative, not project-root")
|
||||
```
|
||||
|
||||
**RETURN FORMAT:**
|
||||
|
||||
Subprocess returns file name, frontmatter compliance status, unused variables found, path violations, and overall status (PASS/FAIL). Include specific variable names and violation details for documentation.
|
||||
|
||||
Check ALL files systematically. Return findings for compilation and appendage to validation report.
|
||||
|
||||
### 3. Aggregate Findings and Document Results
|
||||
|
||||
Document frontmatter validation results in the validation report showing:
|
||||
- Which files were checked
|
||||
- Frontmatter compliance status for each file
|
||||
- Unused variables found in each file
|
||||
- Path violations detected
|
||||
- Overall pass/fail status for each file
|
||||
|
||||
### 4. List All Violations
|
||||
|
||||
Document all violations found in the validation report, including:
|
||||
- Specific files with violations
|
||||
- Unused variable names and why they're unused
|
||||
- Forbidden patterns detected with explanation
|
||||
- Path format violations with details
|
||||
- Files that passed all checks
|
||||
|
||||
### 5. Append to Report
|
||||
|
||||
Update {validationReportFile} - replace "## Frontmatter Validation *Pending...*" with actual findings.
|
||||
|
||||
### 6. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**Frontmatter validation complete.** Proceeding to Menu Handling Validation..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- EVERY step file validated using subprocess optimization (Pattern 2: per-file deep analysis)
|
||||
- Each subprocess validates frontmatter, checks variable usage, validates paths
|
||||
- Structured findings returned to parent OR report updated directly by subprocesses
|
||||
- All violations documented with specific variable names
|
||||
- Findings aggregated into validation report
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not validating every file using subprocess optimization
|
||||
- Not systematically checking each variable for usage in subprocess
|
||||
- Missing forbidden pattern detection
|
||||
- Not documenting violations with specific details
|
||||
- Not returning structured findings OR updating report from subprocess
|
||||
- Not saving report before proceeding
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough using subprocess optimization. DO NOT BE LAZY. For EACH file, launch a subprocess that validates frontmatter, checks variable usage, validates paths, and returns findings. Auto-proceed through all validation steps.
|
||||
@@ -1,265 +0,0 @@
|
||||
---
|
||||
name: 'step-02b-path-violations'
|
||||
description: 'CRITICAL: Catch path violations step-02 misses - hardcoded paths, dead links, module awareness'
|
||||
|
||||
nextStepFile: './step-03-menu-validation.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
---
|
||||
|
||||
# Validation Step 2b: Critical Path Violations
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
CRITICAL path checks that step-02's frontmatter validation MISSES. This catches violations in CONTENT (not frontmatter), dead links, and module path unawareness using grep/bash (ideally in a subprocess that can update the report or return all results to parent).
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - CHECK EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction in this file references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the instructed outcome in your main context thread and available toolset
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Perform systematic bash/grep checks using subprocess optimization - single subprocess for grep/regex across many files
|
||||
- 🚫 DO NOT skip any file or violation type - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
|
||||
- 🚪 This catches what step-02 misses - CONTENT violations, dead links, module awareness, links in code and not in front matter
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Perform systematic checks using subprocess optimization when available - single subprocess for grep/regex across many files, separate subprocess per file for deep analysis, subprocess for data file operations
|
||||
- 💾 Subprocesses must either update validation report OR return findings for parent aggregation
|
||||
- 📖 Save report before continuing to {nextStepFile}
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Step-02 validated frontmatter (variables, relative paths)
|
||||
- This step validates CONTENT and file existence with a Focus on: hardcoded paths in body, dead links, module awareness in every file found under {targetWorkflowPath}
|
||||
- **CRITICAL:** Output files the workflow itself being validated produces won't exist during validation - <example> a contract document creation workflow might have a reference to said output - but it of course will not yet exist during workflow validation</example>
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Perform Critical Path Violation Detection
|
||||
|
||||
**Perform systematic path violation checks on EVERY workflow file using subprocess optimization when available - each file in its own subprocess:**
|
||||
|
||||
**SUBPROCESS EXECUTION PATTERN:**
|
||||
|
||||
For EACH file in the workflow being validated, launch a subprocess that:
|
||||
1. Loads any reference files it needs (to avoid bloating parent context)
|
||||
2. Performs all required checks on that file
|
||||
3. **EITHER** updates the validation report directly with its findings
|
||||
4. **OR** returns structured findings to parent for aggregation
|
||||
|
||||
**DO NOT BE LAZY - Use appropriate subprocess pattern for each check:**
|
||||
- **Single subprocess for grep/regex**: Run one command across many files, return matches
|
||||
- **Separate subprocess per file**: When deep analysis of each file's content is required
|
||||
- **Subprocess for data operations**: Load reference data, find matches, summarize key findings
|
||||
|
||||
**PHASE 1: Identify Config Variables (EXCEPTIONS to path checks):**
|
||||
|
||||
Read {targetWorkflowPath}/workflow.md to extract known config variables from the Configuration Loading section:
|
||||
|
||||
```bash
|
||||
# Extract config variables from workflow.md
|
||||
grep -A 20 "Configuration Loading" {targetWorkflowPath}/workflow.md | grep -E "^\s+-\s+`\{[^}]+\}`" | sed "s/.*//;s/[`']//g"
|
||||
```
|
||||
|
||||
**Store these as KNOWN_CONFIG_VARIABLES for reference in later checks.**
|
||||
|
||||
These are EXCEPTIONS - paths using these variables are VALID even if not relative:
|
||||
- Example: `{output_folder}/doc.md` - VALID (uses config variable)
|
||||
- Example: `{planning_artifacts}/prd.md` - VALID (uses config variable)
|
||||
- These paths won't exist during validation (workflow not running yet)
|
||||
|
||||
---
|
||||
|
||||
**PHASE 2: Hardcoded paths in CONTENT (CRITICAL):**
|
||||
|
||||
Step-02 checks frontmatter - this checks CONTENT (body text after frontmatter).
|
||||
|
||||
**Launch a single subprocess that:**
|
||||
|
||||
1. Runs grep across all step files to find hardcoded {project-root}/ paths in content
|
||||
2. Extracts content after frontmatter from each file
|
||||
3. Returns all findings to parent for aggregation
|
||||
|
||||
```bash
|
||||
# Extract content after frontmatter from all files, search for {project-root}/
|
||||
for file in steps-c/*.md; do
|
||||
awk '/^---$/,0 {if (p) print; p=1} /^---$/{p=1}' "$file" | grep -n "{project-root}/" && echo "Found in: $file"
|
||||
done
|
||||
```
|
||||
|
||||
**What we're catching:**
|
||||
- Content like: `Load {project-root}/_bmad/foo/workflows/.../file.csv`
|
||||
- Should be: `Load {dataFile}` (frontmatter variable with a relative path like ../data/file.csv)
|
||||
|
||||
**SKIP:** Paths using KNOWN_CONFIG_VARIABLES (these are valid exceptions)
|
||||
|
||||
---
|
||||
|
||||
**PHASE 3: Dead or bad links - referenced files don't exist (CRITICAL):**
|
||||
|
||||
**Launch a single subprocess that:**
|
||||
|
||||
1. Extracts all frontmatter path references from all files
|
||||
2. Tests file existence for each reference (skipping output files that use config variables)
|
||||
3. Returns all dead link findings to parent for aggregation
|
||||
|
||||
**CRITICAL DISTINCTION:**
|
||||
- **Output files using config variables:** Skip (won't exist yet - workflow not installed/running)
|
||||
- Example: `{output_folder}/my-doc.md` - SKIP
|
||||
- Example: `{planning_artifacts}/prd.md` - SKIP
|
||||
- Example: `{bmb_creations_output_folder}/file.md` - SKIP
|
||||
|
||||
- **Data files, step files, other workflows:** MUST EXIST - flag if missing
|
||||
- Example: `{dataFile}` where value is `../data/config.csv` - MUST EXIST
|
||||
- Example: `{nextStepFile}` where value is `./step-02.md` - MUST EXIST
|
||||
- Example: `{advancedElicitationTask}` - MUST EXIST
|
||||
- Example: `{partyModeWorkflow}` - MUST EXIST
|
||||
|
||||
**Bash execution pattern:**
|
||||
```bash
|
||||
# Extract all frontmatter path references from all files
|
||||
for file in steps-c/*.md; do
|
||||
# Extract file reference variables from frontmatter
|
||||
grep "^\w*File:" "$file" | sed "s/.*: //"
|
||||
|
||||
# Resolve path (handle relative paths)
|
||||
resolved_path=$(resolve_relative_path "$file" "$value")
|
||||
|
||||
# Check file existence - BUT SKIP output files using config variables
|
||||
if ! path_uses_known_config_variable "$value"; then
|
||||
if ! test -f "$resolved_path"; then
|
||||
echo "DEAD LINK: $file references $resolved_path (not found)"
|
||||
fi
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
**What we're catching:**
|
||||
- Dead links to any files that don't exist that the workflow needs during execution
|
||||
|
||||
---
|
||||
|
||||
**PHASE 4: Module path awareness:**
|
||||
|
||||
**Launch a single subprocess that:**
|
||||
|
||||
1. Determines if current workflow is in a non-bmb module
|
||||
2. If yes, runs grep across all files to find bmb-specific path assumptions
|
||||
3. Returns all module awareness issues to parent for aggregation
|
||||
|
||||
```bash
|
||||
# Check if in non-bmb module, then search for bmb-specific paths
|
||||
if pwd | grep -q "/modules/[^/]\+/" && ! pwd | grep -q "/bmb/"; then
|
||||
grep -rn "{project-root}/_bmad/bmb/" steps-c/ steps-e/ steps-v/ 2>/dev/null || echo "No bmb-specific paths found"
|
||||
fi
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**RETURN FORMAT:**
|
||||
|
||||
```json
|
||||
{
|
||||
"known_config_variables": ["output_folder", "planning_artifacts", "bmb_creations_output_folder", ...],
|
||||
"content_violations": [
|
||||
{"file": "step-v-01-discovery.md", "line": 63, "violation": "hardcoded path in content", "details": "{project-root}/src/modules/.../prd-purpose.md"}
|
||||
],
|
||||
"dead_links": [
|
||||
{"file": "step-06-innovation.md", "line": 215, "violation": "dead link", "details": "nextStepFile './step-07-project-type.md' should be './step-07-project-type.md'"}
|
||||
],
|
||||
"module_awareness_issues": [
|
||||
{"file": "step-XX.md", "issue": "using bmb-specific path in non-bmb module"}
|
||||
],
|
||||
"summary": {"critical": N, "high": N, "medium": N}
|
||||
}
|
||||
```
|
||||
|
||||
Check ALL files systematically. Return structured report for compilation and appendage to validation report.
|
||||
|
||||
### 2. Process Findings and Update Report
|
||||
|
||||
**Create/Update "Critical Path Violations" section in {validationReportFile}:**
|
||||
|
||||
If ANY violations found:
|
||||
|
||||
```markdown
|
||||
## Critical Path Violations
|
||||
|
||||
### Config Variables (Exceptions)
|
||||
|
||||
The following config variables were identified from workflow.md Configuration Loading section.
|
||||
Paths using these variables are valid even if not relative (they reference post-install output locations):
|
||||
|
||||
{list of known_config_variables found}
|
||||
|
||||
### Content Path Violations
|
||||
|
||||
| File | Line | Issue | Details |
|
||||
| ---- | ---- | ----- | ------- |
|
||||
{table from content_violations}
|
||||
|
||||
### Dead Links
|
||||
|
||||
| File | Line | Issue | Details |
|
||||
| ---- | ---- | ----- | ------- |
|
||||
{table from dead_links}
|
||||
|
||||
**Note:** Output files using config variables were correctly skipped during existence checks.
|
||||
|
||||
### Module Awareness
|
||||
|
||||
{module_awareness_issues}
|
||||
|
||||
### Summary
|
||||
|
||||
- **CRITICAL:** {critical_count} violations (must fix - workflow will break)
|
||||
- **HIGH:** {high_count} violations (should fix)
|
||||
- **MEDIUM:** {medium_count} violations (review)
|
||||
|
||||
**Status:** {"❌ FAIL - Critical violations detected" or "⚠️ WARNINGS - Review recommended" or "✅ PASS - No violations"}
|
||||
```
|
||||
|
||||
### 3. Handle Critical Violations
|
||||
|
||||
**If CRITICAL violations found (content violations OR dead links):**
|
||||
|
||||
Halt process once all files have been checked and aggregated - and share the severity of the issue with the user and ask them if they want to stop and you can try to fix these now, or else go to the next item in this list. If not proceeding - its still critical all findings thus far are documented in the report output.
|
||||
|
||||
### 4. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report to {validationReportFile} BEFORE loading and executing {nextStepFile}.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Config variables identified from workflow.md FIRST
|
||||
- Known config variables used as exceptions in later checks
|
||||
- ALL step files checked for content path violations
|
||||
- Dead links detected via file existence tests (skipping output files)
|
||||
- Module awareness issues flagged
|
||||
- Findings appended to validation report
|
||||
- CRITICAL violations halt validation
|
||||
- Clean workflows proceed to step-03
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not identifying config variables first
|
||||
- Not skipping output files during existence checks
|
||||
- Not checking content (only frontmatter)
|
||||
- Missing dead link detection
|
||||
- Not detecting module-specific assumptions
|
||||
- Proceeding despite critical violations
|
||||
@@ -1,164 +0,0 @@
|
||||
---
|
||||
name: 'step-03-menu-validation'
|
||||
description: 'Validate menu handling compliance across all step files'
|
||||
|
||||
nextStepFile: './step-04-step-type-validation.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
menuHandlingStandards: '../data/menu-handling-standards.md'
|
||||
---
|
||||
|
||||
# Validation Step 3: Menu Handling Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate that EVERY step file's menus follow the menu handling standards - proper handlers, execution rules, appropriate menu types.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Validate EVERY step file's menus using subprocess optimization - per-file deep analysis pattern (Pattern 2)
|
||||
- 🚫 DO NOT skip any files or checks - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough, leveraging per-file subprocess for menu structure analysis
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load menu standards first
|
||||
- 💾 Check EVERY file's menu structure using subprocess optimization when available - per-file deep analysis for menu structure validation
|
||||
- 📖 Append findings to validation report (subprocesses either update report OR return findings for parent aggregation)
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All step files in steps-c/ must be validated
|
||||
- Load {menuHandlingStandards} for validation criteria
|
||||
- Check for: handler section, execution rules, reserved letters, inappropriate A/P
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Load Menu Standards
|
||||
|
||||
Load {menuHandlingStandards} to understand validation criteria:
|
||||
|
||||
**Reserved Letters:** A (Advanced Elicitation), P (Party Mode), C (Continue/Accept), X (Exit/Cancel)
|
||||
|
||||
**Required Structure:**
|
||||
1. Display section
|
||||
2. Handler section (MANDATORY)
|
||||
3. Execution Rules section
|
||||
|
||||
**When To Include A/P:**
|
||||
- DON'T: Step 1 (init), validation sequences, simple data gathering
|
||||
- DO: Collaborative content creation, user might want alternatives, quality gates
|
||||
|
||||
### 2. Check EVERY Step File
|
||||
|
||||
**DO NOT BE LAZY - For EVERY file in steps-c/, launch a subprocess that:**
|
||||
|
||||
1. Loads that step file
|
||||
2. Loads {menuHandlingStandards} to understand validation criteria
|
||||
3. Validates menu structure deeply (handler section, execution rules, A/P appropriateness, reserved letter compliance)
|
||||
4. **EITHER** updates validation report directly with findings
|
||||
5. **OR** returns structured validation findings to parent for aggregation
|
||||
|
||||
**SUBPROCESS VALIDATION PATTERN - Each subprocess checks for:**
|
||||
|
||||
**Check 1: Handler Section Exists**
|
||||
- ✅ Handler section immediately follows Display
|
||||
- ❌ If missing: mark as violation
|
||||
|
||||
**Check 2: Execution Rules Section Exists**
|
||||
- ✅ "EXECUTION RULES" section present
|
||||
- ✅ Contains "halt and wait" instruction
|
||||
- ❌ If missing: mark as violation
|
||||
|
||||
**Check 3: Non-C Options Redisplay Menu**
|
||||
- ✅ A/P options specify "redisplay menu"
|
||||
- ❌ If missing: mark as violation
|
||||
|
||||
**Check 4: C Option Sequence**
|
||||
- ✅ C option: save → update frontmatter → load next step
|
||||
- ❌ If sequence wrong: mark as violation
|
||||
|
||||
**Check 5: A/P Only Where Appropriate**
|
||||
- Step 01 should NOT have A/P (inappropriate for init)
|
||||
- Validation sequences should auto-proceed, not have menus
|
||||
- ❌ If A/P in wrong place: mark as violation
|
||||
|
||||
**RETURN FORMAT:**
|
||||
Each subprocess should return validation findings for its assigned file including:
|
||||
- File name
|
||||
- Whether a menu is present
|
||||
- Results of all 5 checks (handler section, execution rules, redisplay menu, C sequence, A/P appropriateness)
|
||||
- List of any violations found
|
||||
- Overall status (PASS/FAIL/WARN)
|
||||
|
||||
**Context savings estimate:** Each subprocess returns structured findings vs full file content. Parent aggregates all findings into final report table.
|
||||
|
||||
### 3. Aggregate Findings and Document Results
|
||||
|
||||
After ALL files have been validated (either via subprocess or main context), document the menu handling validation results in the validation report, including:
|
||||
|
||||
- Overall assessment of menu handling compliance across all step files
|
||||
- Summary of files checked and their menu status
|
||||
- Files that passed all menu validation checks
|
||||
- Files with warnings or issues that need attention
|
||||
- Files that failed validation with specific violations
|
||||
|
||||
### 4. List Violations
|
||||
|
||||
Compile and document all violations found during validation, organizing them by file and providing clear descriptions of each issue, such as:
|
||||
|
||||
- Missing handler sections
|
||||
- Incomplete execution rules
|
||||
- Improper A/P usage
|
||||
- Missing redisplay menu instructions
|
||||
- Any other menu handling standard violations
|
||||
|
||||
### 5. Append to Report
|
||||
|
||||
Update {validationReportFile} - replace "## Menu Handling Validation *Pending...*" with actual findings.
|
||||
|
||||
### 6. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**Menu Handling validation complete.** Proceeding to Step Type Validation..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Menu standards loaded and understood
|
||||
- EVERY step file's menus validated via subprocess (per-file deep analysis) OR main context
|
||||
- All violations documented across handler sections, execution rules, A/P appropriateness
|
||||
- Findings aggregated into validation report (subprocesses either updated report OR returned findings)
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking every file's menus
|
||||
- Skipping menu structure checks
|
||||
- Not documenting violations
|
||||
- Not saving report before proceeding
|
||||
- Loading full file contents into parent context instead of using subprocess analysis
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Use subprocess optimization (Pattern 2) - each file in its own subprocess for deep menu structure analysis. Subprocess returns only findings to parent. Auto-proceed through all validation steps.
|
||||
@@ -1,211 +0,0 @@
|
||||
---
|
||||
name: 'step-04-step-type-validation'
|
||||
description: 'Validate that each step follows its correct step type pattern'
|
||||
|
||||
nextStepFile: './step-05-output-format-validation.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
stepTypePatterns: '../data/step-type-patterns.md'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
---
|
||||
|
||||
# Validation Step 4: Step Type Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate that each step file follows the correct pattern for its step type - init, continuation, middle, branch, validation, final polish, or final.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Load and validate EVERY step against its type pattern - use subprocess optimization (Pattern 2: per-file deep analysis) when available
|
||||
- 🚫 DO NOT skip any files or checks - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load step type patterns first (use subprocess for data operations when available)
|
||||
- 💾 Check EACH file follows its designated type pattern - use per-file subprocesses for deep analysis when available
|
||||
- 📖 Append findings to validation report (subprocess updates report OR returns findings to parent)
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All step files in steps-c/ must be validated
|
||||
- Load {stepTypePatterns} for pattern definitions
|
||||
- The design in {workflowPlanFile} specifies what each step should be
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Load Step Type Patterns
|
||||
|
||||
**Load {stepTypePatterns} to understand the pattern for each type:**
|
||||
|
||||
**If subprocess capability available:**
|
||||
```markdown
|
||||
Launch a subprocess that:
|
||||
1. Loads {stepTypePatterns}
|
||||
2. Extracts all pattern definitions deeply
|
||||
3. Returns summary of patterns to parent (not full file - saves context)
|
||||
```
|
||||
|
||||
**If subprocess unavailable:**
|
||||
```markdown
|
||||
Load {stepTypePatterns} in main context
|
||||
# Larger context but still functional - demonstrates graceful fallback
|
||||
```
|
||||
|
||||
**Step Types:**
|
||||
1. **Init (Non-Continuable)** - Auto-proceed, no continuation logic
|
||||
2. **Init (Continuable)** - Has continueFile reference, continuation detection
|
||||
3. **Continuation (01b)** - Paired with continuable init, routes based on stepsCompleted
|
||||
4. **Middle (Standard)** - A/P/C menu, collaborative content
|
||||
5. **Middle (Simple)** - C only menu, no A/P
|
||||
6. **Branch** - Custom menu with routing to different steps
|
||||
7. **Validation Sequence** - Auto-proceed through checks, no menu
|
||||
8. **Init (With Input Discovery)** - Has inputDocuments array, discovery logic
|
||||
9. **Final Polish** - Loads entire doc, optimizes flow
|
||||
10. **Final** - No next step, completion message
|
||||
|
||||
### 2. Check EACH Step Against Its Type
|
||||
|
||||
**DO NOT BE LAZY - For EACH file in steps-c/, launch a subprocess that:**
|
||||
|
||||
1. Determines what type this step SHOULD be from:
|
||||
- Step number (01 = init, 01b = continuation, last = final)
|
||||
- Design in {workflowPlanFile}
|
||||
- Step name pattern
|
||||
|
||||
2. Loads the step file
|
||||
|
||||
3. Validates it follows the pattern for its type
|
||||
|
||||
4. **EITHER** updates the validation report directly with its findings
|
||||
5. **OR** returns structured findings to parent for aggregation
|
||||
|
||||
**SUBPROCESS ANALYSIS PATTERN - Validate each step file for:**
|
||||
|
||||
**For Init Steps:**
|
||||
- ✅ Creates output from template (if document-producing)
|
||||
- ✅ No A/P menu (or C-only)
|
||||
- ✅ If continuable: has continueFile reference
|
||||
|
||||
**For Continuation (01b):**
|
||||
- ✅ Has nextStepOptions in frontmatter
|
||||
- ✅ Reads stepsCompleted from output
|
||||
- ✅ Routes to appropriate step
|
||||
|
||||
**For Middle (Standard):**
|
||||
- ✅ Has A/P/C menu
|
||||
- ✅ Outputs to document (if applicable)
|
||||
- ✅ Has mandatory execution rules
|
||||
|
||||
**For Middle (Simple):**
|
||||
- ✅ Has C-only menu
|
||||
- ✅ No A/P options
|
||||
|
||||
**For Branch:**
|
||||
- ✅ Has custom menu letters
|
||||
- ✅ Handler routes to different steps
|
||||
|
||||
**For Validation Sequence:**
|
||||
- ✅ Auto-proceeds (no user choice)
|
||||
- ✅ Proceeds to next validation
|
||||
|
||||
**For Final Polish:**
|
||||
- ✅ Loads entire document
|
||||
- ✅ Optimizes flow, removes duplication
|
||||
- ✅ Uses ## Level 2 headers
|
||||
|
||||
**For Final:**
|
||||
- ✅ No nextStepFile in frontmatter
|
||||
- ✅ Completion message
|
||||
- ✅ No next step to load
|
||||
|
||||
**RETURN FORMAT:**
|
||||
Return a concise summary containing:
|
||||
- File name analyzed
|
||||
- What type the step should be
|
||||
- What type it actually is
|
||||
- Whether it follows the correct pattern
|
||||
- List of any violations found
|
||||
- Overall pass/fail status
|
||||
|
||||
**Context savings:** Each subprocess returns only validation findings, not full file contents. Parent receives structured analysis objects instead of 10+ full step files.
|
||||
|
||||
### 3. Aggregate Findings and Document
|
||||
|
||||
**After ALL files analyzed, aggregate findings from subprocesses and document results:**
|
||||
|
||||
**Document the following in the validation report:**
|
||||
|
||||
- Overall summary of step type validation (how many steps checked, pass/fail counts)
|
||||
- For each step file:
|
||||
- File name
|
||||
- What type the step should be (based on design, step number, naming)
|
||||
- What type it actually is
|
||||
- Whether it follows the correct pattern for its type
|
||||
- Any violations or issues found
|
||||
- Pass/fail/warning status
|
||||
|
||||
**Format:** Create a clear, readable section in the validation report that shows the validation results for each step file.
|
||||
|
||||
### 4. List Violations
|
||||
|
||||
**Compile and document all violations found:**
|
||||
|
||||
**Document the following for any violations:**
|
||||
|
||||
- File name with violation
|
||||
- What the violation is (specifically what doesn't match the expected pattern)
|
||||
- What should be changed to fix it
|
||||
- Severity level (error/warning)
|
||||
|
||||
**For files that pass validation:** Briefly note they follow their type patterns correctly.
|
||||
|
||||
### 5. Append to Report
|
||||
|
||||
Update {validationReportFile} - replace "## Step Type Validation *Pending...*" with actual findings.
|
||||
|
||||
### 6. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**Step Type validation complete.** Proceeding to Output Format Validation..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- EVERY step validated against its type pattern (ideally using per-file subprocess optimization)
|
||||
- All violations documented with structured findings
|
||||
- Findings aggregated from subprocesses into report
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
- Context saved: parent receives only findings, not full file contents
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking every file's type pattern
|
||||
- Skipping type-specific checks
|
||||
- Not documenting violations
|
||||
- Not saving report before proceeding
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY file's type pattern. Auto-proceed through all validation steps.
|
||||
@@ -1,200 +0,0 @@
|
||||
---
|
||||
name: 'step-05-output-format-validation'
|
||||
description: 'Validate output format compliance - template type, final polish, step-to-output mapping'
|
||||
|
||||
nextStepFile: './step-06-validation-design-check.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
outputFormatStandards: '../data/output-format-standards.md'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
---
|
||||
|
||||
# Validation Step 5: Output Format Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate that the workflow's output format matches the design - correct template type, proper final polish step if needed, and step-to-output mapping is correct.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Validate output format using subprocess optimization - per-file subprocess for step-to-output validation
|
||||
- 🚫 DO NOT skip any checks - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report OR return findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load output format standards first
|
||||
- 💾 Check template type matches design
|
||||
- 📖 Check for final polish step if needed
|
||||
- 🔍 Use subprocess optimization for step-to-output mapping validation - per-file subprocess for deep analysis
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Check template file in templates/ folder
|
||||
- Review design in {workflowPlanFile} for output format specification
|
||||
- Validate step-to-output mapping
|
||||
- Check if final polish step is present (if needed)
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Load Output Format Standards
|
||||
|
||||
Load {outputFormatStandards} to understand:
|
||||
|
||||
**Golden Rule:** Every step MUST output to document BEFORE loading next step.
|
||||
|
||||
**Four Template Types:**
|
||||
1. **Free-form** (Recommended) - Minimal structure, progressive append
|
||||
2. **Structured** - Required sections, flexible within each
|
||||
3. **Semi-structured** - Core sections plus optional additions
|
||||
4. **Strict** - Exact format, specific fields (rare)
|
||||
|
||||
**Final Polish Step:**
|
||||
- For free-form workflows, include a polish step that optimizes the entire document
|
||||
- Loads entire document, reviews for flow, removes duplication
|
||||
|
||||
### 2. Check Design Specification
|
||||
|
||||
From {workflowPlanFile}, identify:
|
||||
- Does this workflow produce a document?
|
||||
- If yes, what template type was designed?
|
||||
- Is a final polish step needed?
|
||||
|
||||
### 3. Validate Template File
|
||||
|
||||
**If workflow produces documents:**
|
||||
|
||||
1. Load the template file from `templates/` folder
|
||||
2. Check it matches the designed type:
|
||||
|
||||
**For Free-form (most common):**
|
||||
- ✅ Has frontmatter with `stepsCompleted: []`
|
||||
- ✅ Has `lastStep: ''`
|
||||
- ✅ Has `date: ''`
|
||||
- ✅ Has `user_name: ''`
|
||||
- ✅ Document title header
|
||||
- ✅ No rigid section structure (progressive append)
|
||||
|
||||
**For Structured:**
|
||||
- ✅ Has clear section headers
|
||||
- ✅ Section placeholders with {{variable}} syntax
|
||||
- ✅ Consistent structure
|
||||
|
||||
**For Semi-structured:**
|
||||
- ✅ Has core required sections
|
||||
- ✅ Has optional section placeholders
|
||||
|
||||
**For Strict:**
|
||||
- ✅ Has exact field definitions
|
||||
- ✅ Validation rules specified
|
||||
|
||||
### 4. Check for Final Polish Step
|
||||
|
||||
**If free-form template:**
|
||||
- ✅ A final polish step should exist in the design
|
||||
- ✅ The step loads entire document
|
||||
- ✅ The step optimizes flow and coherence
|
||||
- ✅ The step removes duplication
|
||||
- ✅ The step ensures ## Level 2 headers
|
||||
|
||||
**If no final polish step for free-form:**
|
||||
- ⚠️ WARNING - Free-form workflows typically need final polish
|
||||
|
||||
### 5. Validate Step-to-Output Mapping
|
||||
|
||||
**DO NOT BE LAZY - For EACH step that outputs to document, launch a subprocess that:**
|
||||
|
||||
1. Loads that step file
|
||||
2. Analyzes frontmatter for `outputFile` variable
|
||||
3. Analyzes step body to verify output is written before loading next step
|
||||
4. Checks menu C option saves to output before proceeding
|
||||
5. Returns structured findings to parent for aggregation
|
||||
|
||||
**SUBPROCESS EXECUTION PATTERN:**
|
||||
|
||||
**For EACH step file, launch a subprocess that:**
|
||||
1. Loads the step file
|
||||
2. Performs deep analysis of output operations (frontmatter, body, menu options)
|
||||
3. Returns findings to parent for aggregation
|
||||
|
||||
**RETURN FORMAT:**
|
||||
Each subprocess should return:
|
||||
- Step filename
|
||||
- Whether output variable exists in frontmatter
|
||||
- Whether output is saved before loading next step
|
||||
- Whether menu option C saves to output before proceeding
|
||||
- Output order number (if applicable)
|
||||
- Any issues found
|
||||
- Overall status (PASS/FAIL/WARNING)
|
||||
|
||||
**Parent aggregates findings into:**
|
||||
|
||||
**Steps should be in ORDER of document appearance:**
|
||||
- Step 1 creates doc
|
||||
- Step 2 → ## Section 1
|
||||
- Step 3 → ## Section 2
|
||||
- Step N → Polish step
|
||||
|
||||
### 6. Document Findings
|
||||
|
||||
Document your output format validation findings in the validation report. Include:
|
||||
|
||||
- **Document Production**: Whether the workflow produces documents and what template type it uses
|
||||
- **Template Assessment**: Template file existence, whether it matches the designed type, and frontmatter correctness
|
||||
- **Final Polish Evaluation**: Whether a final polish step is required (for free-form workflows) and if present, whether it properly loads the entire document and optimizes flow
|
||||
- **Step-to-Output Mapping**: For each step that outputs to the document, document whether it has the output variable in frontmatter, saves output before loading the next step, and properly saves in menu option C
|
||||
- **Subprocess Analysis Summary**: Count of total steps analyzed, steps with output, steps saving correctly, and steps with issues
|
||||
- **Issues Identified**: List any problems found with template structure, polish step, or output mapping
|
||||
- **Overall Status**: Pass, fail, or warning designation
|
||||
|
||||
### 7. Append to Report
|
||||
|
||||
Update {validationReportFile} - replace "## Output Format Validation *Pending...*" with actual findings.
|
||||
|
||||
### 8. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**Output Format validation complete.** Proceeding to Validation Design Check..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Template type matches design
|
||||
- Final polish step present if needed
|
||||
- Step-to-output mapping validated via subprocess optimization
|
||||
- All findings documented
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
- Subprocess pattern applied correctly (per-file analysis for step-to-output validation)
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking template file
|
||||
- Missing final polish step for free-form
|
||||
- Not documenting mapping issues
|
||||
- Not saving report before proceeding
|
||||
- Not using subprocess optimization for step-to-output validation
|
||||
- Loading all step files into parent context instead of per-file subprocess
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check template, polish step, and mapping. Use subprocess optimization for step-to-output validation - per-file subprocess returns analysis, not full content. Auto-proceed through all validation steps.
|
||||
@@ -1,195 +0,0 @@
|
||||
---
|
||||
name: 'step-06-validation-design-check'
|
||||
description: 'Check if workflow has proper validation steps that load validation data (if validation is critical)'
|
||||
|
||||
nextStepFile: './step-07-instruction-style-check.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
trimodalWorkflowStructure: '../data/trimodal-workflow-structure.md'
|
||||
---
|
||||
|
||||
# Validation Step 6: Validation Design Check
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To check if the workflow has proper validation steps when validation is critical - validation steps should load from validation data and perform systematic checks.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Check if workflow needs validation steps - use subprocess optimization (per-file deep analysis for Pattern 2)
|
||||
- 🚫 DO NOT skip any validation step reviews - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Determine if validation is critical for this workflow - use subprocess optimization when available
|
||||
- 💾 Check validation steps exist and are well-designed - launch subprocess for per-file deep analysis (Pattern 2)
|
||||
- 💬 Subprocesses must either update validation report OR return findings for parent aggregation
|
||||
- 📖 Append findings to validation report
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Some workflows need validation (compliance, safety, quality gates)
|
||||
- Others don't (creative, exploratory)
|
||||
- Check the design to determine if validation steps are needed
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Determine If Validation Is Critical
|
||||
|
||||
From {workflowPlanFile}, check:
|
||||
|
||||
**Does this workflow NEED validation?**
|
||||
|
||||
**YES - Validation Critical If:**
|
||||
- Compliance/regulatory requirements (tax, legal, medical)
|
||||
- Safety-critical outputs
|
||||
- Quality gates required
|
||||
- User explicitly requested validation steps
|
||||
|
||||
**NO - Validation Not Critical If:**
|
||||
- Creative/exploratory workflow
|
||||
- User-driven without formal requirements
|
||||
- Output is user's responsibility to validate
|
||||
|
||||
### 2. If Validation Is Critical, Check Validation Steps
|
||||
|
||||
**DO NOT BE LAZY - For EVERY validation step file, launch a subprocess that:**
|
||||
|
||||
1. Loads that validation step file
|
||||
2. Reads and analyzes the step's content deeply (prose, logic, quality, flow, anti-lazy language)
|
||||
3. Returns structured analysis findings to parent for aggregation
|
||||
|
||||
**SUBPROCESS ANALYSIS PATTERN - Check each validation step file for:**
|
||||
|
||||
**Proper Validation Step Design:**
|
||||
- ✅ Loads validation data/standards from `data/` folder
|
||||
- ✅ Has systematic check sequence (not hand-wavy)
|
||||
- ✅ Auto-proceeds through checks (not stopping for each)
|
||||
- ✅ Clear pass/fail criteria
|
||||
- ✅ Reports findings to user
|
||||
|
||||
**"DO NOT BE LAZY" Language Check:**
|
||||
- ✅ Step includes "DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE" or similar mandate
|
||||
- ✅ Step instructs to "Load and review EVERY file" not "sample files"
|
||||
- ✅ Step has "DO NOT SKIP" or "DO NOT SHORTCUT" language
|
||||
- ⚠️ WARNING if validation step lacks anti-lazy language
|
||||
|
||||
**Critical Flow Check:**
|
||||
- ✅ For critical flows (compliance, safety, quality gates): validation steps are in steps-v/ folder (tri-modal)
|
||||
- ✅ Validation steps are segregated from create flow
|
||||
- ✅ Validation can be run independently
|
||||
- ⚠️ For non-critical flows (entertainment, therapy, casual): validation may be inline
|
||||
- ❌ ERROR if critical validation is mixed into create steps
|
||||
|
||||
**RETURN FORMAT:**
|
||||
Return a structured analysis containing:
|
||||
- Step file name
|
||||
- Proper design checklist (loads data, systematic checks, auto-proceeds, clear criteria, reports findings)
|
||||
- Anti-lazy language check (has mandate, mandate text, comprehensive coverage)
|
||||
- Critical flow check (location, segregation, independence)
|
||||
- Any issues found
|
||||
- Overall status (PASS/FAIL/WARN)
|
||||
|
||||
**Context savings:** Each subprocess returns analysis (~30 lines), not full step file (~200 lines). Parent gets structured findings, not file contents.
|
||||
|
||||
### 3. Aggregate Findings from All Subprocesses
|
||||
|
||||
After all validation step files have been analyzed in subprocesses, aggregate findings:
|
||||
|
||||
**Process subprocess results:**
|
||||
- Compile all structured analysis findings
|
||||
- Identify patterns across validation steps
|
||||
- Note any critical issues or warnings
|
||||
|
||||
### 4. Check Validation Data Files
|
||||
|
||||
**If workflow has validation steps:**
|
||||
|
||||
1. Check `data/` folder for validation data
|
||||
2. Verify data files exist and are properly structured:
|
||||
- CSV files have headers
|
||||
- Markdown files have clear criteria
|
||||
- Data is referenced in step frontmatter
|
||||
|
||||
### 5. Document Findings
|
||||
|
||||
**Create/Update "Validation Design Check" section in {validationReportFile} using aggregated subprocess findings:**
|
||||
|
||||
Document the following information:
|
||||
|
||||
**Whether validation is required:** Indicate if this workflow needs validation steps based on its domain type (critical/compliance/safety workflows vs. creative/exploratory ones)
|
||||
|
||||
**List of validation steps found:** Provide the names/paths of all validation step files in the workflow
|
||||
|
||||
**Validation step quality assessment:** For each validation step, document:
|
||||
- Whether it loads validation data/standards from the data/ folder
|
||||
- Whether it has a systematic check sequence
|
||||
- Whether it auto-proceeds through checks (vs. stopping for user input)
|
||||
- Whether it includes "DO NOT BE LAZY" or similar anti-lazy language mandates
|
||||
- Whether it has clear pass/fail criteria
|
||||
- Overall status (PASS/FAIL/WARN)
|
||||
|
||||
**"DO NOT BE LAZY" language presence:** For each validation step, note whether anti-lazy language is present and what it says
|
||||
|
||||
**Critical flow segregation:** For workflows requiring validation, document:
|
||||
- The workflow domain type
|
||||
- Whether validation steps are in the steps-v/ folder (tri-modal structure) or inline with create steps
|
||||
- Whether this segregation is appropriate for the workflow type
|
||||
|
||||
**Validation data files:** List any validation data files found in the data/ folder, or note if they are missing
|
||||
|
||||
**Issues identified:** List any problems found with the validation design, missing data files, or quality concerns
|
||||
|
||||
**Overall status:** Provide final assessment (PASS/FAIL/WARN/N/A) with reasoning
|
||||
|
||||
### 6. Append to Report
|
||||
|
||||
Update {validationReportFile} - replace "## Validation Design Check *Pending...*" with actual findings from subprocess aggregation.
|
||||
|
||||
### 7. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**Validation Design check complete.** Proceeding to Instruction Style Check..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Determined if validation is critical
|
||||
- If critical: checked all validation steps
|
||||
- Validated validation step quality
|
||||
- Checked validation data files
|
||||
- Findings documented
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking validation steps when critical
|
||||
- Missing validation data files
|
||||
- Not documenting validation design issues
|
||||
- Not saving report before proceeding
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check validation steps thoroughly. Auto-proceed through all validation steps.
|
||||
@@ -1,209 +0,0 @@
|
||||
---
|
||||
name: 'step-07-instruction-style-check'
|
||||
description: 'Check instruction style - intent-based vs prescriptive, appropriate for domain'
|
||||
|
||||
nextStepFile: './step-08-collaborative-experience-check.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
intentVsPrescriptive: '../data/intent-vs-prescriptive-spectrum.md'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
---
|
||||
|
||||
# Validation Step 7: Instruction Style Check
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate that workflow instructions use appropriate style - intent-based for creative/facilitative workflows, prescriptive only where absolutely required (compliance, legal).
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Review EVERY step's instruction style using subprocess optimization - separate subprocess per file for deep analysis
|
||||
- 🚫 DO NOT skip any files or style checks - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report OR return structured findings to parent for aggregation
|
||||
- 🚪 This is validation - systematic and thorough
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load intent vs prescriptive standards
|
||||
- 💾 Check EACH step's instruction style using subprocess optimization - each file in its own subprocess
|
||||
- 📖 Validate style is appropriate for domain
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
- 💬 Subprocesses must either update validation report OR return findings for parent aggregation
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Instruction style should match domain
|
||||
- Creative/facilitative → Intent-based (default)
|
||||
- Compliance/legal → Prescriptive (exception)
|
||||
- Check EVERY step for style consistency
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Load Instruction Style Standards
|
||||
|
||||
Load {intentVsPrescriptive} to understand:
|
||||
|
||||
**Intent-Based (Default):**
|
||||
- Use for: Most workflows - creative, exploratory, collaborative
|
||||
- Step instruction describes goals and principles
|
||||
- AI adapts conversation naturally
|
||||
- More flexible and responsive
|
||||
- Example: "Guide user to define requirements through open-ended discussion"
|
||||
|
||||
**Prescriptive (Exception):**
|
||||
- Use for: Compliance, safety, legal, medical, regulated industries
|
||||
- Step provides exact instructions
|
||||
- More controlled and predictable
|
||||
- Example: "Ask exactly: 'Do you currently experience fever, cough, or fatigue?'"
|
||||
|
||||
### 2. Determine Domain Type
|
||||
|
||||
From {workflowPlanFile}, identify the workflow domain:
|
||||
|
||||
**Intent-Based Domains (Default):**
|
||||
- Creative work (writing, design, brainstorming)
|
||||
- Personal development (planning, goals, reflection)
|
||||
- Exploration (research, discovery)
|
||||
- Collaboration (facilitation, coaching)
|
||||
|
||||
**Prescriptive Domains (Exception):**
|
||||
- Legal/Compliance (contracts, regulations)
|
||||
- Medical (health assessments, triage)
|
||||
- Financial (tax, regulatory compliance)
|
||||
- Safety (risk assessments, safety checks)
|
||||
|
||||
### 3. Check EACH Step's Instruction Style
|
||||
|
||||
**DO NOT BE LAZY - For EACH step file, launch a subprocess that:**
|
||||
|
||||
1. Loads that step file
|
||||
2. Reads the instruction sections (MANDATORY SEQUENCE)
|
||||
3. Analyzes and classifies instruction style deeply
|
||||
4. **EITHER** updates validation report directly with findings
|
||||
5. **OR** returns structured analysis findings to parent for aggregation
|
||||
|
||||
**SUBPROCESS ANALYSIS PATTERN:**
|
||||
|
||||
Each subprocess performs deep analysis of instruction prose to classify style:
|
||||
|
||||
**Intent-Based Indicators:**
|
||||
- ✅ Describes goals/outcomes, not exact wording
|
||||
- ✅ Uses "think about" language
|
||||
- ✅ Multi-turn conversation encouraged
|
||||
- ✅ "Ask 1-2 questions at a time, not a laundry list"
|
||||
- ✅ "Probe to understand deeper"
|
||||
- ✅ Flexible: "guide user through..." not "say exactly..."
|
||||
|
||||
**Prescriptive Indicators:**
|
||||
- Exact questions specified
|
||||
- Specific wording required
|
||||
- Sequence that must be followed precisely
|
||||
- "Say exactly:" or "Ask precisely:"
|
||||
|
||||
**Mixed Style:**
|
||||
- Some steps prescriptive (critical/required)
|
||||
- Others intent-based (creative/facilitative)
|
||||
|
||||
**RETURN FORMAT:**
|
||||
Each subprocess should return findings including:
|
||||
- Step file identifier
|
||||
- Instruction style classification (Intent-based/Prescriptive/Mixed)
|
||||
- Style indicators observed
|
||||
- Appropriateness assessment (PASS/WARN/FAIL)
|
||||
- Specific notes and observations
|
||||
- Examples of good and concerning instruction patterns
|
||||
|
||||
**Parent aggregates all subprocess findings into unified report section.**
|
||||
|
||||
### 4. Validate Appropriateness
|
||||
|
||||
**For Intent-Based Domains:**
|
||||
- ✅ Instructions should be intent-based
|
||||
- ❌ Prescriptive instructions inappropriate (unless specific section requires it)
|
||||
|
||||
**For Prescriptive Domains:**
|
||||
- ✅ Instructions should be prescriptive where compliance matters
|
||||
- ⚠️ May have intent-based sections for creative elements
|
||||
|
||||
### 5. Aggregate Findings and Document
|
||||
|
||||
After ALL subprocesses have analyzed their respective step files, aggregate findings and create/update section in {validationReportFile}.
|
||||
|
||||
Document the following:
|
||||
|
||||
**Workflow Domain Assessment:**
|
||||
- Document the domain type (creative/interactive vs compliance/legal)
|
||||
- State the appropriate instruction style for this domain
|
||||
|
||||
**Instruction Style Findings:**
|
||||
- List each step and its instruction style classification (intent-based/prescriptive/mixed)
|
||||
- Note whether the style is appropriate for the domain
|
||||
- Document specific examples of instruction language that demonstrate the style
|
||||
- Identify any steps with inappropriate style (e.g., prescriptive in creative domain)
|
||||
|
||||
**Issues Identified:**
|
||||
- List any steps that are overly prescriptive for their domain
|
||||
- List any steps that should be more prescriptive (for compliance domains)
|
||||
- Note any style inconsistencies across steps
|
||||
|
||||
**Positive Findings:**
|
||||
- Highlight steps with excellent instruction style
|
||||
- Note effective use of intent-based facilitation language
|
||||
- Identify appropriate use of prescriptive instructions (if applicable)
|
||||
|
||||
**Overall Status:**
|
||||
- Provide final assessment (PASS/FAIL/WARN)
|
||||
- Summarize key findings
|
||||
|
||||
**Context Savings Note:** Using subprocess pattern (Pattern 2: per-file deep analysis), parent context receives only structured analysis findings (~50-100 lines per file) instead of full file contents (~200+ lines per file). For 10 steps: ~500-1000 lines received vs ~2000+ lines if loading all files in parent.
|
||||
|
||||
### 6. Update Report with Aggregated Findings
|
||||
|
||||
Update {validationReportFile} - replace "## Instruction Style Check *Pending...*" with actual aggregated findings from all subprocesses.
|
||||
|
||||
### 7. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**Instruction Style check complete.** Proceeding to Collaborative Experience Check..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- EVERY step's instruction style reviewed via subprocess optimization (Pattern 2: per-file deep analysis)
|
||||
- Each step analyzed in its own subprocess for style classification
|
||||
- Style validated against domain appropriateness
|
||||
- Issues documented with specific examples
|
||||
- Subprocess findings aggregated into unified report section
|
||||
- Context savings achieved (~500-1000 lines received vs ~2000+ if loading all files)
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking every step's style via subprocess
|
||||
- Not analyzing each file in its own subprocess
|
||||
- Not validating against domain
|
||||
- Not documenting style issues
|
||||
- Not aggregating subprocess findings
|
||||
- Not saving report before proceeding
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. For EACH step file, launch a subprocess to analyze instruction style deeply. Aggregate findings. Auto-proceed through all validation steps. Use graceful fallback if subprocess unavailable.
|
||||
@@ -1,199 +0,0 @@
|
||||
---
|
||||
name: 'step-08-collaborative-experience-check'
|
||||
description: 'Check collaborative quality - does this workflow facilitate well or just interrogate?'
|
||||
|
||||
nextStepFile: './step-08b-subprocess-optimization.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
---
|
||||
|
||||
# Validation Step 8: Collaborative Experience Check
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate that the workflow actually facilitates well - natural conversation, not interrogation. Questions asked progressively, not in laundry lists.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Review EVERY step for collaborative quality
|
||||
- 🚫 DO NOT skip any files or experience checks
|
||||
- 💬 Append findings to report, then auto-load next step
|
||||
- 🚪 This is validation - systematic and thorough
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Walk through the workflow as a user would
|
||||
- 💾 Check conversation flow in each step
|
||||
- 📖 Validate facilitation quality
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Good workflows facilitate, don't interrogate
|
||||
- Questions should be 1-2 at a time
|
||||
- Conversation should feel natural
|
||||
- Check EVERY step for collaborative patterns
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Load the Workflow Design
|
||||
|
||||
From {workflowPlanFile}, understand:
|
||||
- What is the workflow's goal?
|
||||
- Who is the user?
|
||||
- What interaction style was designed?
|
||||
|
||||
### 2. Review EACH Step for Collaborative Quality
|
||||
|
||||
**DO NOT BE LAZY - For EACH step file:**
|
||||
|
||||
1. Load the step
|
||||
2. Read the MANDATORY SEQUENCE section
|
||||
3. Evaluate against collaborative quality criteria:
|
||||
|
||||
**Good Facilitation Indicators:**
|
||||
- ✅ "Ask 1-2 questions at a time"
|
||||
- ✅ "Think about their response before continuing"
|
||||
- ✅ "Use conversation, not interrogation"
|
||||
- ✅ "Probe to understand deeper"
|
||||
- ✅ Natural language in instructions
|
||||
- ✅ Allows for back-and-forth
|
||||
|
||||
**Bad Interrogation Indicators:**
|
||||
- ❌ Laundry lists of questions
|
||||
- ❌ "Ask the following: 1, 2, 3, 4, 5, 6..."
|
||||
- ❌ Form-filling approach
|
||||
- ❌ No space for conversation
|
||||
- ❌ Rigid sequences without flexibility
|
||||
|
||||
**Role Reinforcement Check:**
|
||||
- ✅ "You are a [role], we engage in collaborative dialogue"
|
||||
- ✅ "Together we produce something better"
|
||||
- ❌ "You are a form filler" (obviously bad, but check for patterns)
|
||||
|
||||
### 3. Check Progression and Arc
|
||||
|
||||
**Does the workflow have:**
|
||||
- ✅ Clear progression from step to step?
|
||||
- ✅ Each step builds on previous work?
|
||||
- ✅ User knows where they are in the process?
|
||||
- ✅ Satisfying completion at the end?
|
||||
|
||||
**Or does it:**
|
||||
- ❌ Feel disjointed?
|
||||
- ❌ Lack clear progression?
|
||||
- ❌ Leave user unsure of status?
|
||||
|
||||
### 4. Check Error Handling
|
||||
|
||||
**Do steps handle:**
|
||||
- ✅ Invalid input gracefully?
|
||||
- ✅ User uncertainty with guidance?
|
||||
- ✅ Off-track conversation with redirection?
|
||||
- ✅ Edge cases with helpful messages?
|
||||
|
||||
### 5. Document Findings
|
||||
|
||||
```markdown
|
||||
### Collaborative Experience Check Results
|
||||
|
||||
**Overall Facilitation Quality:** [Excellent/Good/Fair/Poor]
|
||||
|
||||
**Step-by-Step Analysis:**
|
||||
|
||||
**step-01-init.md:**
|
||||
- Question style: [Progressive/Laundry list]
|
||||
- Conversation flow: [Natural/Rigid]
|
||||
- Role clarity: ✅/❌
|
||||
- Status: ✅ PASS / ❌ FAIL
|
||||
|
||||
**step-02-*.md:**
|
||||
- Question style: [Progressive/laundry list - "Ask 1-2 at a time" / Lists 5+ questions]
|
||||
- Allows conversation: ✅/❌
|
||||
- Thinks before continuing: ✅/❌
|
||||
- Status: ✅ PASS / ❌ FAIL
|
||||
|
||||
[Continue for ALL steps...]
|
||||
|
||||
**Collaborative Strengths Found:**
|
||||
- [List examples of good facilitation]
|
||||
- [Highlight steps that excel at collaboration]
|
||||
|
||||
**Collaborative Issues Found:**
|
||||
|
||||
**Laundry List Questions:**
|
||||
- [List steps with question dumps]
|
||||
- Example: "step-03-*.md asks 7 questions at once"
|
||||
|
||||
**Rigid Sequences:**
|
||||
- [List steps that don't allow conversation]
|
||||
- Example: "step-04-*.md has no space for back-and-forth"
|
||||
|
||||
**Form-Filling Patterns:**
|
||||
- [List steps that feel like form filling]
|
||||
- Example: "step-05-*.md collects data without facilitation"
|
||||
|
||||
**Progression Issues:**
|
||||
- [List problems with flow/arc]
|
||||
- Example: "step-06-*.md doesn't connect to previous step"
|
||||
|
||||
**User Experience Assessment:**
|
||||
|
||||
**Would this workflow feel like:**
|
||||
- [ ] A collaborative partner working WITH the user
|
||||
- [ ] A form collecting data FROM the user
|
||||
- [ ] An interrogation extracting information
|
||||
- [ ] A mix - depends on step
|
||||
|
||||
**Overall Collaborative Rating:** ⭐⭐⭐⭐⭐ [1-5 stars]
|
||||
|
||||
**Status:** ✅ EXCELLENT / ✅ GOOD / ⚠️ NEEDS IMPROVEMENT / ❌ POOR
|
||||
```
|
||||
|
||||
### 6. Append to Report
|
||||
|
||||
Update {validationReportFile} - replace "## Collaborative Experience Check *Pending...*" with actual findings.
|
||||
|
||||
### 7. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**Collaborative Experience check complete.** Proceeding to Cohesive Review..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- EVERY step reviewed for collaborative quality
|
||||
- Question patterns analyzed (progressive vs laundry list)
|
||||
- Conversation flow validated
|
||||
- Issues documented with specific examples
|
||||
- Findings appended to report
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not checking every step's collaborative quality
|
||||
- Missing question pattern analysis
|
||||
- Not documenting experience issues
|
||||
- Not saving report before proceeding
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY step's collaborative quality. Auto-proceed through all validation steps.
|
||||
@@ -1,179 +0,0 @@
|
||||
---
|
||||
name: 'step-08b-subprocess-optimization'
|
||||
description: 'Identify subprocess optimization opportunities - reduce context load, improve performance'
|
||||
|
||||
nextStepFile: './step-09-cohesive-review.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
subprocessPatterns: '../data/subprocess-optimization-patterns.md'
|
||||
---
|
||||
|
||||
# Validation Step 8b: Subprocess Optimization Analysis
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To identify opportunities for subprocess optimization throughout the workflow - reducing context load, improving performance, and enabling massive operations that would otherwise exceed context limits.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - ANALYZE EVERY FILE IN ITS OWN SUBPROCESS
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess/subagent/tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Analyze EVERY step file for subprocess optimization - each file in its own subprocess
|
||||
- 🚫 DO NOT skip any file - DO NOT BE LAZY
|
||||
- 💬 Load {subprocessPatterns} in subprocess performing some action required to understand patterns deeply with examples (if subprocess available), else load in main context
|
||||
- 🚪 This identifies context-saving and performance-optimizing opportunities
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Analyze each step file in its own subprocess - deep analysis of subprocess potential
|
||||
- 💾 Subprocesses must identify optimization patterns and return findings to parent for aggregation
|
||||
- 📖 Aggregate findings into validation report before loading next step
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- Three patterns: grep/regex across files, per-file deep analysis, data file operations, parallel execution
|
||||
- **Context-saving goal**: Return ONLY key findings to parent, not full file contents
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Load Subprocess Pattern Reference (Context Optimization!)
|
||||
|
||||
**First, understand the subprocess optimization patterns by loading {subprocessPatterns}:**
|
||||
|
||||
**If subprocess capability available:**
|
||||
```markdown
|
||||
Launch a subprocess that:
|
||||
1. Loads {subprocessPatterns}
|
||||
2. Studies all patterns and examples deeply (Pattern 3: data operations!)
|
||||
3. Returns summary of key patterns to parent (not full file - saves context)
|
||||
```
|
||||
|
||||
**If subprocess unavailable:**
|
||||
```markdown
|
||||
Load {subprocessPatterns} in main context
|
||||
# Larger context but still functional - demonstrates graceful fallback
|
||||
```
|
||||
|
||||
**This step itself demonstrates Pattern 3 from the reference!**
|
||||
|
||||
---
|
||||
|
||||
### 2. Perform Subprocess Optimization Analysis
|
||||
|
||||
**DO NOT BE LAZY - For EVERY step file, launch a subprocess that:**
|
||||
|
||||
1. Loads that step file
|
||||
2. ALSO loads {subprocessPatterns} to understand all patterns deeply (subprocess needs full context!)
|
||||
3. Analyzes the step against each pattern looking for optimization opportunities
|
||||
4. Returns specific, actionable suggestions to parent
|
||||
|
||||
**Subprocess gets full context:**
|
||||
- The step file being analyzed
|
||||
- The subprocess-optimization-patterns.md reference (all examples and patterns)
|
||||
- Returns only findings to parent (context savings!)
|
||||
|
||||
**SUBPROCESS ANALYSIS PATTERN - Check each step file for:**
|
||||
|
||||
**Pattern 1: Single subprocess for grep/regex** - Operations that check/search multiple files for patterns (frontmatter validation, menu checks, path searches). Suggest: "Use single grep subprocess, return only matches"
|
||||
|
||||
**Pattern 2: Separate subprocess per file** - Operations requiring deep analysis of prose/logic/quality/style/flow per file (instruction review, collaborative quality assessment, step type compliance). Suggest: "Each file in own subprocess, return analysis findings"
|
||||
|
||||
**Pattern 3: Subprocess for data operations** - Operations loading large data files to find matches, extract key details, or summarize findings. Suggest: "Subprocess loads data, returns ONLY relevant rows/findings"
|
||||
|
||||
**Pattern 4: Parallel execution** - Independent operations that could run simultaneously. Suggest: "Run in parallel subprocesses to reduce execution time"
|
||||
|
||||
**RETURN FORMAT (example structure, adapt as needed):**
|
||||
```json
|
||||
{
|
||||
"step_file": "step-02-*.md",
|
||||
"opportunities": [
|
||||
{
|
||||
"pattern": "grep/regex|per-file|data-ops|parallel",
|
||||
"location": "Line XX: [quote relevant instruction]",
|
||||
"issue": "Loads all files into parent context",
|
||||
"suggestion": "Use single grep subprocess, return only failures",
|
||||
"impact": "Saves ~N lines per file, faster execution",
|
||||
"priority": "HIGH|MEDIUM|LOW"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Aggregate Findings and Create Report Section
|
||||
|
||||
After ALL files analyzed, create/update section in {validationReportFile}:
|
||||
|
||||
```markdown
|
||||
## Subprocess Optimization Opportunities
|
||||
|
||||
**Total Opportunities:** {count} | **High Priority:** {count} | **Estimated Context Savings:** {description}
|
||||
|
||||
### High-Priority Opportunities
|
||||
|
||||
**{Step Name}** - {Pattern Type}
|
||||
- **Current:** {brief description of current approach}
|
||||
- **Suggested:** {specific optimization suggestion}
|
||||
- **Impact:** {context savings, performance gain}
|
||||
- **Example:** `{brief code/pseudocode}`
|
||||
|
||||
[Repeat for each high-priority opportunity...]
|
||||
|
||||
### Moderate/Low-Priority Opportunities
|
||||
|
||||
{List with brief descriptions}
|
||||
|
||||
### Summary by Pattern
|
||||
|
||||
- **Pattern 1 (grep/regex):** {count} opportunities - {total savings}
|
||||
- **Pattern 2 (per-file):** {count} opportunities - {total savings}
|
||||
- **Pattern 3 (data ops):** {count} opportunities - {total savings}
|
||||
- **Pattern 4 (parallel):** {count} opportunities - {performance gain}
|
||||
|
||||
### Implementation Recommendations
|
||||
|
||||
**Quick Wins:** {easy implementations with big savings}
|
||||
**Strategic:** {higher effort but big payoff}
|
||||
**Future:** {moderate impact, consider later}
|
||||
|
||||
**Status:** ✅ Complete / ⚠️ Review recommended
|
||||
```
|
||||
|
||||
### 3. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save report BEFORE loading next step.
|
||||
|
||||
Then load, read entire file, execute {nextStepFile}.
|
||||
|
||||
**Display:** "**Subprocess optimization analysis complete.** Identified {count} opportunities with potential context savings. Proceeding to Cohesive Review..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- EVERY step file analyzed in its own subprocess
|
||||
- ALL optimization opportunities identified
|
||||
- Findings aggregated into report
|
||||
- Prioritized recommendations with context savings
|
||||
- Report saved, next step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not analyzing every file
|
||||
- Skipping opportunity identification
|
||||
- Not providing specific suggestions
|
||||
- Not estimating savings
|
||||
- Not aggregating findings
|
||||
|
||||
**Master Rule:** DO NOT BE LAZY. Analyze EVERY file in its own subprocess. Identify ALL optimization opportunities across 4 patterns. Provide specific, actionable recommendations with context savings. Return findings to parent. Auto-proceed.
|
||||
@@ -1,186 +0,0 @@
|
||||
---
|
||||
name: 'step-09-cohesive-review'
|
||||
description: 'Cohesive ultra-think review - overall quality, does this workflow actually facilitate well?'
|
||||
|
||||
nextStepFile: './step-10-report-complete.md'
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
---
|
||||
|
||||
# Validation Step 9: Cohesive Review
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To perform a cohesive "ultra-think" review of the entire workflow - walk through it as a whole, assess overall quality, does it actually facilitate well?
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- 🔄 CRITICAL: When loading next step, ensure entire file is read
|
||||
- ✅ Validation does NOT stop for user input - auto-proceed through all validation steps
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Review the workflow as a cohesive whole - **NOTE: This step loads ENTIRE workflow for holistic review (different pattern from other validation steps)**
|
||||
- 🚫 DO NOT skip any aspect of the review - DO NOT BE LAZY
|
||||
- 💬 Subprocess optimization: When available, can use subprocesses to load individual step files and return structured summaries to parent for aggregation
|
||||
- 💬 However, since cohesive review requires understanding the COMPLETE workflow as one unit, parent may need full context for proper holistic assessment
|
||||
- 🚪 This is the meta-review - overall assessment
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Walk through the ENTIRE workflow end-to-end using subprocess optimization when available
|
||||
- 💬 When using subprocesses: Each subprocess loads one step file, performs deep analysis, returns structured findings to parent for aggregation
|
||||
- 💬 Subprocess must either update validation report directly OR return findings to parent for compilation
|
||||
- 💾 Assess overall quality, not just individual components
|
||||
- 📖 Think deeply: would this actually work well?
|
||||
- 🚫 DO NOT halt for user input - validation runs to completion
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- This is the cohesive review - look at the workflow as a whole
|
||||
- Consider user experience from start to finish
|
||||
- Assess whether the workflow achieves its goal
|
||||
- Be thorough and thoughtful
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Load the Entire Workflow
|
||||
|
||||
**DO NOT BE LAZY - Load EVERY step file using subprocess optimization when available:**
|
||||
|
||||
**SUBPROCESS APPROACH (when available):**
|
||||
|
||||
For EACH workflow file (workflow.md + all step files in order), launch a subprocess that:
|
||||
1. Loads that single file
|
||||
2. Performs deep analysis of content, flow, quality, and connection points
|
||||
3. Returns structured findings to parent for holistic aggregation
|
||||
|
||||
**Subprocess should return:**
|
||||
- File name analyzed
|
||||
- Purpose and flow position within the workflow
|
||||
- How it connects to previous and next steps
|
||||
- Quality indicators and any issues found
|
||||
- Voice and tone consistency assessment
|
||||
|
||||
**FALLBACK APPROACH (if subprocess unavailable):**
|
||||
|
||||
Load workflow.md and EVERY step file in steps-c/ sequentially in main context:
|
||||
1. Load workflow.md
|
||||
2. Load EVERY step file in steps-c/ in order
|
||||
3. Read through each step
|
||||
4. Understand the complete flow
|
||||
|
||||
**CRITICAL:** Whether using subprocess or main context, you must understand the COMPLETE workflow as one cohesive unit before proceeding to assessment.
|
||||
|
||||
### 2. Walk Through the Workflow Mentally
|
||||
|
||||
**Imagine you are a user running this workflow:**
|
||||
|
||||
- Starting from workflow.md
|
||||
- Going through step-01
|
||||
- Progressing through each step
|
||||
- Experiencing the interactions
|
||||
- Reaching the end
|
||||
|
||||
**Ask yourself:**
|
||||
- Does this make sense?
|
||||
- Is the flow logical?
|
||||
- Would I feel guided or confused?
|
||||
- Does it achieve its goal?
|
||||
|
||||
### 3. Assess Cohesiveness
|
||||
|
||||
**Check for:**
|
||||
|
||||
**✅ Cohesive Indicators:**
|
||||
- Each step builds on previous work
|
||||
- Clear progression toward goal
|
||||
- Consistent voice and approach throughout
|
||||
- User always knows where they are
|
||||
- Satisfying completion
|
||||
|
||||
**❌ Incohesive Indicators:**
|
||||
- Steps feel disconnected
|
||||
- Jumps in logic or flow
|
||||
- Inconsistent patterns
|
||||
- User might be confused
|
||||
- Abrupt or unclear ending
|
||||
|
||||
### 4. Assess Overall Quality
|
||||
|
||||
**Evaluate the workflow across key dimensions:**
|
||||
|
||||
Consider goal clarity, logical flow, facilitation quality, user experience, and goal achievement. Provide an overall quality assessment based on these dimensions.
|
||||
|
||||
### 5. Identify Strengths and Weaknesses
|
||||
|
||||
**Strengths:**
|
||||
- What does this workflow do well?
|
||||
- What makes it excellent?
|
||||
- What should other workflows emulate?
|
||||
|
||||
**Weaknesses:**
|
||||
- What could be improved?
|
||||
- What doesn't work well?
|
||||
- What would confuse users?
|
||||
|
||||
**Critical Issues:**
|
||||
- Are there any show-stopper problems?
|
||||
- Would this workflow fail in practice?
|
||||
|
||||
### 6. Provide Recommendation
|
||||
|
||||
**Assess overall workflow readiness:**
|
||||
|
||||
Determine if the workflow is excellent (ready to use, exemplifies best practices), good (solid with minor improvements possible), needs work (has issues to address), or problematic (major issues requiring significant revision). Provide a clear recommendation on readiness for use.
|
||||
|
||||
### 7. Document Findings
|
||||
|
||||
**Document your cohesive review findings in the validation report:**
|
||||
|
||||
Include your overall assessment (excellent/good/needs work/problematic), quality evaluation across key dimensions, cohesiveness analysis (flow, progression, voice and tone), identified strengths and weaknesses, any critical issues, what makes the workflow work well, what could be improved, user experience forecast, and your recommendation on readiness for use.
|
||||
|
||||
### 8. Append to Report
|
||||
|
||||
Update {validationReportFile} - replace "## Cohesive Review *Pending...*" with actual findings.
|
||||
|
||||
### 9. Save Report and Auto-Proceed
|
||||
|
||||
**CRITICAL:** Save the validation report BEFORE loading next step.
|
||||
|
||||
Then immediately load, read entire file, then execute {nextStepFile}.
|
||||
|
||||
**Display:**
|
||||
"**Cohesive Review complete.** Proceeding to finalize validation report..."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- ENTIRE workflow reviewed end-to-end
|
||||
- Quality assessed across multiple dimensions
|
||||
- Strengths and weaknesses documented
|
||||
- Thoughtful recommendation provided
|
||||
- Findings appended to report
|
||||
- Report saved before proceeding
|
||||
- Next validation step loaded
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not reviewing the entire workflow
|
||||
- Superficial or lazy assessment
|
||||
- Not documenting strengths/weaknesses
|
||||
- Not providing clear recommendation
|
||||
- Not saving report before proceeding
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Review the ENTIRE workflow cohesively. Think deeply about quality. Auto-proceed through all validation steps.
|
||||
@@ -1,154 +0,0 @@
|
||||
---
|
||||
name: 'step-10-report-complete'
|
||||
description: 'Finalize validation report - check for plan file, summarize all findings, present to user'
|
||||
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
planValidationStep: './step-11-plan-validation.md'
|
||||
---
|
||||
|
||||
# Validation Step 10: Report Complete
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To check if a plan file exists (and run plan validation if it does), then summarize all validation findings and present to the user.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 📖 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}`
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 This is the final validation step - present findings
|
||||
- 🚫 DO NOT modify the workflow without user request
|
||||
- 💬 Present summary and ask what changes are needed
|
||||
- 🚪 This ends validation - user decides next steps
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load the complete validation report
|
||||
- 💾 Summarize ALL findings
|
||||
- 📖 Update report status to COMPLETE
|
||||
- 🚫 DO NOT proceed without user review
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- All 10 previous validation steps have completed
|
||||
- Report contains findings from all checks
|
||||
- User needs to see summary and decide on changes
|
||||
- This step DOES NOT auto-proceed
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Follow this sequence exactly. Do not skip or shortcut.
|
||||
|
||||
### 1. Check for Plan File
|
||||
|
||||
Before finalizing the report, check if a plan file exists:
|
||||
|
||||
**Check if {workflowPlanFile} exists:**
|
||||
- **IF YES:** Run plan validation first
|
||||
- Load, read entire file, then execute {planValidationStep}
|
||||
- The plan validation will append its findings to the report
|
||||
- Then return to this step to finalize the report
|
||||
- **IF NO:** Proceed to finalize the report (no plan to validate)
|
||||
|
||||
### 2. Load Complete Validation Report
|
||||
|
||||
After plan validation (if applicable), load {validationReportFile} and read ALL findings from every validation step.
|
||||
|
||||
### 3. Create Summary Section
|
||||
|
||||
At the end of {validationReportFile}, replace "## Summary *Pending...*" with a comprehensive summary that includes:
|
||||
|
||||
- Validation completion date
|
||||
- Overall status assessment (based on all validation steps)
|
||||
- List of all validation steps completed with their individual results
|
||||
- Summary of critical issues that must be fixed (or note if none found)
|
||||
- Summary of warnings that should be addressed (or note if none found)
|
||||
- Key strengths identified during validation
|
||||
- Overall assessment of workflow quality
|
||||
- Recommendation on readiness (ready to use / needs tweaks / needs revision / major rework needed)
|
||||
- Suggested next steps for the user
|
||||
|
||||
Present this information in a clear, readable format - the exact structure is flexible as long as it covers all these points.
|
||||
|
||||
### 4. Update Report Status
|
||||
|
||||
Update the frontmatter of {validationReportFile} to set validationStatus to COMPLETE and add the completionDate. Keep existing fields like validationDate, workflowName, and workflowPath unchanged.
|
||||
|
||||
### 5. Present Summary to User
|
||||
|
||||
Present a clear summary to the user that includes:
|
||||
|
||||
- Confirmation that validation is complete
|
||||
- Overall status of the workflow
|
||||
- Quick results overview showing each validation step and its result
|
||||
- Count of critical issues and warnings (or note if none found)
|
||||
- Recommendation on workflow readiness
|
||||
- Path to the full validation report
|
||||
- Options for next steps (review detailed findings, make changes, explain results, or other actions)
|
||||
|
||||
Present this information in a natural, conversational way - the exact format doesn't matter as long as all this information is clearly communicated.
|
||||
|
||||
### 6. Present MENU OPTIONS
|
||||
|
||||
Display: **Validation Complete! Select an Option:** [R] Review Detailed Findings [F] Fix Issues [X] Exit Validation
|
||||
|
||||
#### EXECUTION RULES:
|
||||
|
||||
- ALWAYS halt and wait for user input after presenting menu
|
||||
- User chooses their next action
|
||||
|
||||
#### Menu Handling Logic:
|
||||
|
||||
- IF R: Walk through the validation report section by section, explaining findings, then redisplay menu
|
||||
- IF F: "What issues would you like to fix?" → Discuss specific changes needed → User can make edits manually OR you can help edit files
|
||||
- IF X: "Validation complete. Your workflow is at: {targetWorkflowPath}. You can make changes and re-run validation anytime."
|
||||
- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#5-present-menu-options)
|
||||
|
||||
### 7. If User Wants to Fix Issues
|
||||
|
||||
Explain the available options for fixing issues:
|
||||
|
||||
- Manual edits: User edits files directly, then re-runs validation
|
||||
- Guided edits: User specifies what to fix, help create specific edits for user approval
|
||||
- Edit workflow: If the workflow has steps-e/, use the edit workflow to make systematic changes
|
||||
|
||||
The exact format doesn't matter - just ensure the user understands their options for addressing issues.
|
||||
|
||||
### 8. Update Plan with Validation Status
|
||||
|
||||
If a plan file exists at {workflowPlanFile}, update its frontmatter to include the validation status (COMPLETE), the current validation date, and a reference to the validation report file.
|
||||
|
||||
## CRITICAL STEP COMPLETION NOTE
|
||||
|
||||
This is the final validation step. User reviews findings and decides whether to make changes. Validation workflow ends here.
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- All validation findings summarized
|
||||
- Complete report presented to user
|
||||
- Summary section added to report
|
||||
- Report status updated to COMPLETE
|
||||
- User can review findings and decide on changes
|
||||
- Plan updated with validation status
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not summarizing all findings
|
||||
- Not presenting complete report to user
|
||||
- Not updating report status
|
||||
- Not giving user clear options for next steps
|
||||
|
||||
**Master Rule:** Validation is complete. User reviews findings and decides what changes to make. Provide clear summary and options.
|
||||
@@ -1,237 +0,0 @@
|
||||
---
|
||||
name: 'step-11-plan-validation'
|
||||
description: 'Validate plan quality - ensure all user intent and requirements are implemented'
|
||||
|
||||
targetWorkflowPath: '{workflow_folder_path}'
|
||||
validationReportFile: '{workflow_folder_path}/validation-report-{datetime}.md'
|
||||
workflowPlanFile: '{workflow_folder_path}/workflow-plan.md'
|
||||
---
|
||||
|
||||
# Validation Step 11: Plan Quality Validation
|
||||
|
||||
## STEP GOAL:
|
||||
|
||||
To validate that a workflow plan (if it exists) has been fully implemented - all user intent captured, all requirements met with high quality.
|
||||
|
||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||
|
||||
### Universal Rules:
|
||||
|
||||
- 🛑 DO NOT BE LAZY - LOAD AND REVIEW EVERY FILE
|
||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
||||
- ✅ This validation step only runs if a plan file exists
|
||||
- ⚙️ If any instruction references a subprocess, subagent, or tool you do not have access to, you MUST still achieve the outcome in your main context thread
|
||||
|
||||
### Step-Specific Rules:
|
||||
|
||||
- 🎯 Validate plan requirements using subprocess optimization - separate subprocess per requirement area for deep analysis
|
||||
- 🚫 DO NOT skip checking any requirement from the plan - DO NOT BE LAZY
|
||||
- 💬 Subprocess must either update validation report directly OR return structured findings to parent for aggregation
|
||||
- 🚪 This ensures the build actually delivered what was planned
|
||||
|
||||
## EXECUTION PROTOCOLS:
|
||||
|
||||
- 🎯 Load plan and extract all requirements/intent using subprocess optimization when available - separate subprocess per requirement area for deep analysis
|
||||
- 💾 Subprocesses validate implementation against plan requirements and return findings for aggregation
|
||||
- 📖 Document gaps and quality issues
|
||||
- 🚫 Only run this step if workflowPlanFile exists
|
||||
|
||||
## CONTEXT BOUNDARIES:
|
||||
|
||||
- This step runs AFTER the workflow is built
|
||||
- Compares what was planned vs what was implemented
|
||||
- Checks for: missing features, quality gaps, unmet user intent
|
||||
|
||||
## MANDATORY SEQUENCE
|
||||
|
||||
**CRITICAL:** Only run this step if {workflowPlanFile} exists. If it doesn't exist, skip to final summary.
|
||||
|
||||
### 1. Check if Plan Exists
|
||||
|
||||
First, check if {workflowPlanFile} exists:
|
||||
|
||||
**IF plan file does NOT exist:**
|
||||
- Skip this validation step
|
||||
- Proceed to summary with note: "No plan file found - workflow may have been built without BMAD create-workflow process"
|
||||
|
||||
**IF plan file exists:**
|
||||
- Load the complete plan file
|
||||
- Proceed with validation
|
||||
|
||||
### 2. Extract Plan Requirements
|
||||
|
||||
**DO NOT BE LAZY - Extract EVERY requirement from the plan:**
|
||||
|
||||
**SUBPROCESS EXECUTION PATTERN:**
|
||||
|
||||
Launch a subprocess that:
|
||||
1. Loads {workflowPlanFile}
|
||||
2. Extracts all requirements from each section (Discovery, Classification, Requirements, Design, Tools)
|
||||
3. Returns structured requirements list to parent
|
||||
|
||||
**SUBPROCESS RETURNS:**
|
||||
Structured requirements list organized by section (discovery, classification, requirements, design, tools) with all extracted items and a count of total requirements.
|
||||
|
||||
**If subprocess unavailable:** Load {workflowPlanFile} in main context and extract requirements (larger context but still functional - demonstrates graceful fallback).
|
||||
|
||||
---
|
||||
|
||||
### 3. Validate Each Requirement Against Built Workflow
|
||||
|
||||
**DO NOT BE LAZY - For EACH requirement area, launch a subprocess that:**
|
||||
|
||||
1. Loads relevant workflow files (workflow.md, step files, etc.)
|
||||
2. Validates that specific requirement area is implemented correctly
|
||||
3. Assesses quality of implementation
|
||||
4. **EITHER** updates validation report directly with findings
|
||||
5. **OR** returns structured validation results to parent for aggregation
|
||||
|
||||
**PATTERN 2: Separate subprocess per requirement area for deep analysis**
|
||||
|
||||
Each subprocess gets full context to deeply understand that requirement area and validate implementation quality:
|
||||
|
||||
---
|
||||
|
||||
**SUBPROCESS 1: Discovery Validation**
|
||||
|
||||
**Subprocess analyzes:**
|
||||
- ✅ Built workflow addresses the original problem?
|
||||
- ✅ Vision from discovery is reflected in final workflow?
|
||||
|
||||
**Subprocess returns:**
|
||||
Discovery validation results indicating whether the original problem and vision from the plan are addressed in the built workflow, with quality assessment, status (✅/❌), and any gaps identified.
|
||||
|
||||
---
|
||||
|
||||
**SUBPROCESS 2: Classification Validation**
|
||||
|
||||
**Subprocess analyzes:**
|
||||
- ✅ Document output matches plan (yes/no)?
|
||||
- ✅ Module affiliation correct?
|
||||
- ✅ Continuable support as specified?
|
||||
- ✅ Tri-modal structure as specified?
|
||||
|
||||
**Subprocess returns:**
|
||||
Classification validation results for each classification attribute (document output, module, continuable, tri-modal) comparing what was specified vs what was implemented, with overall quality assessment, status (✅/❌), and any gaps.
|
||||
|
||||
---
|
||||
|
||||
**SUBPROCESS 3: Requirements Validation**
|
||||
|
||||
**Subprocess analyzes:**
|
||||
- ✅ Flow structure matches plan?
|
||||
- ✅ User interaction style as specified?
|
||||
- ✅ All required inputs configured?
|
||||
- ✅ Output format matches specification?
|
||||
- ✅ Success criteria achievable?
|
||||
|
||||
**Subprocess returns:**
|
||||
Requirements validation results for flow structure, interaction style, inputs, outputs, and success criteria comparing what was specified vs what was implemented, with overall quality assessment, status (✅/❌), and any gaps.
|
||||
|
||||
---
|
||||
|
||||
**SUBPROCESS 4: Design Validation**
|
||||
|
||||
**Subprocess analyzes:**
|
||||
- ✅ All steps from design present in workflow?
|
||||
- ✅ Step purposes match design?
|
||||
- ✅ Flow follows design diagram?
|
||||
- ✅ Interaction patterns as specified?
|
||||
|
||||
**Subprocess returns:**
|
||||
Design validation results for each step from the plan checking if it exists in the workflow and if the purpose matches, along with whether the flow follows the design diagram and interaction patterns match, with overall quality assessment, status (✅/❌), and any gaps.
|
||||
|
||||
---
|
||||
|
||||
**SUBPROCESS 5: Tools Validation**
|
||||
|
||||
**Subprocess analyzes:**
|
||||
- ✅ Specified tools configured in workflow?
|
||||
- ✅ Data files created as specified?
|
||||
|
||||
**Subprocess returns:**
|
||||
Tools validation results checking which specified tools are configured and which data files were created, with overall quality assessment, status (✅/❌), and any gaps.
|
||||
|
||||
---
|
||||
|
||||
**If subprocess unavailable:** Validate each requirement area sequentially in main context (larger context but still functional - demonstrates graceful fallback).
|
||||
|
||||
---
|
||||
|
||||
### 4. Aggregate Findings and Update Report
|
||||
|
||||
After ALL requirement area subprocesses complete, aggregate findings into validation report.
|
||||
|
||||
Document the following information:
|
||||
|
||||
**Plan Information:**
|
||||
- Plan file location
|
||||
- Whether a plan was found
|
||||
- Total number of requirements extracted from the plan
|
||||
|
||||
**Implementation Coverage:**
|
||||
For each requirement area from the plan (Discovery/Vision, Classification attributes, Requirements specifications, Design elements, Tools):
|
||||
- What was specified in the plan
|
||||
- Whether it was implemented in the workflow
|
||||
- Quality assessment (High/Medium/Low)
|
||||
- Implementation status
|
||||
|
||||
**Implementation Gaps:**
|
||||
List any requirements from the plan that are NOT present in the built workflow
|
||||
|
||||
**Quality Issues:**
|
||||
List any requirements that are implemented but with quality concerns
|
||||
|
||||
**Plan-Reality Alignment:**
|
||||
Describe where the built workflow doesn't match what was planned
|
||||
|
||||
**Overall Assessment:**
|
||||
- Plan implementation score (percentage)
|
||||
- Overall status (Fully Implemented/Partially Implemented/Poorly Implemented/Missing Critical Items)
|
||||
|
||||
**Quality Assessment Framework:**
|
||||
For each implemented requirement, assess quality:
|
||||
- **High Quality**: Implementation follows best practices, would facilitate effectively
|
||||
- **Medium Quality**: Functional but has issues or gaps
|
||||
- **Low Quality**: Minimal/barely working, would not facilitate well
|
||||
|
||||
Examples:
|
||||
- Plan specifies "Highly collaborative, intent-based facilitation" and implementation has A/P menus with intent-based language = High Quality
|
||||
- Plan specifies "Continuable workflow with session resume" and implementation has step-01b-continue.md tracking stepsCompleted = High Quality
|
||||
|
||||
### 5. Append to Report
|
||||
|
||||
Append the aggregated findings to {validationReportFile} after the "## Cohesive Review" section.
|
||||
|
||||
### 6. Save and Complete
|
||||
|
||||
Save the validation report. This is the final validation step.
|
||||
|
||||
**Display:**
|
||||
"**Plan Quality validation complete.** Validation report finalized."
|
||||
|
||||
---
|
||||
|
||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
||||
|
||||
### ✅ SUCCESS:
|
||||
|
||||
- Plan file loaded completely (in subprocess or main context)
|
||||
- Every requirement extracted and validated using subprocess optimization when available
|
||||
- Each requirement area analyzed in separate subprocess (or main context with graceful fallback)
|
||||
- Implementation gaps documented with structured findings
|
||||
- Quality assessed for each requirement
|
||||
- Findings aggregated and appended to report
|
||||
- Context saved via subprocess pattern (return only findings, not full file contents)
|
||||
|
||||
### ❌ SYSTEM FAILURE:
|
||||
|
||||
- Not loading complete plan
|
||||
- Skipping requirement checks
|
||||
- Not validating each requirement area deeply
|
||||
- Not using subprocess optimization when available
|
||||
- Not documenting implementation gaps
|
||||
- Not assessing quality
|
||||
- Loading full file contents into parent instead of returning only findings
|
||||
|
||||
**Master Rule:** Validation is systematic and thorough. DO NOT BE LAZY. Check EVERY requirement from the plan. Use subprocess optimization (Pattern 2: per-requirement deep analysis) when available. Document all gaps. Return only findings to parent, not full file contents.
|
||||
Reference in New Issue
Block a user