npm - @delorenj/pjangler - Versions diffs - 1.2.25 → 1.2.33 - Mend

@delorenj/pjangler 1.2.25 → 1.2.33

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (834) hide show

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

@@ -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/templates/commonproject/_bmad/bmb/workflows/workflow/steps-v/step-06-validation-design-check.md DELETED Viewed

@@ -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/templates/commonproject/_bmad/bmb/workflows/workflow/steps-v/step-07-instruction-style-check.md DELETED Viewed

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