/fix-workflow

name: fix-workflow
description: Retrospective analysis and improvement of workflow components with self-evolving patterns
usage: /fix-workflow [--scope sanctum|repo] [--dry-run] [--focus skills|agents|commands|hooks|all] [--difficulty auto|simple|complex]

Fix Workflow

Run a lightweight retrospective on the **most recent command or session slice** visible in the current context window, then implement targeted improvements to the workflow components involved (skills, agents, commands, hooks).

When To Use

Use this command when you need to:

• Workflow execution felt inefficient or needs optimization
• Post-session improvement of skills/agents/commands/hooks

When NOT To Use

• Simple changes that don't need the full workflow
• Work already completed through another sanctum command

Self-Improvement Architecture

This command implements research-backed self-improvement patterns:

| Pattern | Purpose | When Applied | |---------|---------|--------------| | **Reflexion** | Self-critique before applying fixes | Phase 1.5 (after analysis) | | **PDCA Loops** | Plan-Do-Check-Act validation | Each phase transition | | **Difficulty-Aware** | Adjust depth based on complexity | Phase 0 (auto-detected) | | **Outcome Feedback** | Learn from validation results | Phase 2 (close loop) |

Usage

/fix-workflow [--scope sanctum|repo] [--dry-run] [--focus skills|agents|commands|hooks|all] [--difficulty auto|simple|complex]

• `--scope sanctum|repo`: Default `sanctum`. If `repo`, improvements may touch non-plugin code and project docs/tests as needed.
• `--dry-run`: Produce an improvement plan without making changes.
• `--focus`: Default `all`. Limit to a component type to keep the change set small.
• `--difficulty auto|simple|complex`: Default `auto`. Controls orchestration depth:
• `simple`: Single-pass improvement (1-2 files, clear fix)
• `complex`: Full PDCA cycle with reflexion (multi-file, architectural)
• `auto`: Detect from workflow complexity score

Workflow

Phase 0: Gather Improvement Context (Automatic)

Before starting retrospective analysis, automatically gather existing improvement data:

Step 0.1: Check Skill Execution Metrics

Identify performance issues in workflow components:

# Get recent skill executions (last 7 days)
/skill-logs --last 7d --format json > /tmp/recent-skills.json

# Check for failures in workflow components
/skill-logs --failures-only --last 7d

**Extract:**

• Skills that failed during the workflow slice
• Skills with high stability_gap (> 0.3) indicating instability
• Common error patterns
• Performance degradation signals

Step 0.2: Query Memory Palace for Lessons

Check if similar workflow issues have been captured:

# Search review-chamber for workflow-related lessons
# (If memory-palace commands are available)
/review-room search "workflow" --room lessons --limit 5
/review-room search "efficiency" --room patterns --limit 5

**Look for:**

• Previously identified workflow inefficiencies
• Patterns from past PR reviews
• Architectural decisions affecting workflows

Step 0.3: Check Recent Git History

Look for recent fixes to workflow components:

# Find recent improvements to the workflow components
git log --oneline --grep="improve\|fix\|optimize\|refactor" --since="30 days ago" \
  -- plugins/sanctum/skills/ plugins/sanctum/commands/ plugins/sanctum/agents/

# Check if similar workflows were fixed recently
git log -p --since="30 days ago" --grep="workflow" -- plugins/sanctum/

**Identify:**

• Recurring issues that keep getting fixed
• Components with frequent changes (instability signals)
• Patterns in fix commit messages

Phase 1: Retrospective Analysis

Stages 2 to 4 below are three agents in a fixed order with structured handoffs, which is a script's shape. `/sanctum:fix-workflow-analysis` (`workflows/fix-workflow-analysis.js`) runs them as one pipeline and returns a plan. Use it when the slice is already captured and the roster does not need to adapt; use the agents directly otherwise. It only runs when asked for: a workflow never starts unasked.

It deliberately stops before step 5. A workflow's subagents run in `acceptEdits` whatever the session's permission mode, so an implementer stage there would apply edits nobody saw proposed. The script also has no shell, so it cannot run one acceptance criterion it writes. Implementation and validation stay in the session, where the diff is visible and a command can actually be run.

1. **Capture the target slice and key evidence:**

• Load workflow-improvement skill: `Skill(sanctum:workflow-improvement)` or read `plugins/sanctum/skills/workflow-improvement/SKILL.md`
• **Include Phase 0 findings** as additional context

2. **Recreate the workflow and surface inefficiencies:**

• Use `workflow-recreate-agent` to restate the steps, identify friction, and list involved components
• **Cross-reference with Phase 0 data** to identify recurring patterns

3. **Analyze improvement options:**

• Use `workflow-improvement-analysis-agent` to generate candidate improvements with trade-offs and expected impact
• **Prioritize fixes** for components with high failure rates or stability gaps

4. **Plan collaboratively (converge on a small, high-use patch):**

• Use `workflow-improvement-planner-agent` to choose the best approach, define acceptance criteria, and assign work
• **Create TodoWrite items** referencing Phase 0 metrics

Phase 1.5: Reflexion (Self-Critique Loop)

Before implementing, the agent evaluates its own improvement plan:

Reflexion Checklist

## Self-Critique Questions

1. **Root Cause**: Does this fix address the root cause or just symptoms?
   - [ ] Verified root cause in Phase 0 data
   - [ ] Fix targets cause, not effect

2. **Unintended Consequences**: Could this improvement break something else?
   - [ ] Checked dependent workflows
   - [ ] Reviewed similar past fixes for side