create-byan-agent 2.1.0 → 2.1.1

package/_bmad/bmb/workflows/workflow/steps-v/step-05-output-format-validation.md

@@ -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.

package/_bmad/bmb/workflows/workflow/steps-v/step-06-validation-design-check.md

@@ -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.

package/_bmad/bmb/workflows/workflow/steps-v/step-07-instruction-style-check.md

@@ -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.