Fixit

A progressive workflow for fixing broken functionality from a pasted body of output: error codes, stack traces, failing test logs, incorrect program output, or a freeform description of "this is wrong, here's what I expected." Follows the sanctum pattern:

triage → reproduce → research → hypothesize → test (RED) → fix (GREEN) → verify → report

When To Use

Use this command when you need to:

• Take a pasted block of error output, stack trace, or broken behavior and drive it to a verified fix
• Reproduce a defect, write a failing test, then fix it under the Iron Law
• Fix something where you do not yet know the root cause and need a stepwise diagnostic path

When NOT To Use

• The fix is in a PR review thread: use /sanctum:fix-pr instead
• The work is tracked in a GitHub or GitLab issue: use /sanctum:do-issue
• The retrospective is about a slow or fragile workflow itself, not a code defect: use /sanctum:fix-workflow
• You are exploring code without a known failure: use /feature-dev:feature-dev or read the code directly

Quick Reference

/fixit "TypeError: 'NoneType' object is not subscriptable at parser.py:88"
/fixit --file /tmp/build.log              # Read input from a file
/fixit --scope minor --quick              # Skip research, allow direct fix
/fixit --from hypothesize                 # Already reproduced, jump to ladder
/fixit --to test                          # Stop after RED test (dry-run-ish)
/fixit --strict                           # Force Iron Law even with --quick
/fixit --research                         # Force tome:research even on minor
/fixit --commit                           # Auto-commit via sanctum:acp on green
/fixit --dry-run                          # Plan only, no edits or commands

Workflow Steps Overview

The Iron Law (non-negotiable)

NO IMPLEMENTATION WITHOUT A FAILING TEST FIRST

This command always enforces Iron Law. The only flag that softens it is --quick, and even that requires the RED test. --quick only skips Research and lets Triage feed Hypothesize directly; it does not skip the test.

If you find yourself wanting to skip the test, consult Skill(imbue:proof-of-work) module iron-law-enforcement.md and Skill(imbue:rigorous-reasoning) to check whether you are rationalizing.

Intelligent Step-Skipping

Auto-detected scope shapes which phases run. Override with --scope.

Minor scope (typo, single-character fix, obvious signature mismatch, trivial off-by-one):

• Skip: Research
• Run: Triage to Reproduce to Hypothesize to Test (RED) to Fix to Verify

Medium scope (logic bug with clear repro, single-file scope, known library behavior):

• Skip: nothing by default
• Run: all phases

Major scope (novel error, unfamiliar library, multi-file blast radius, concurrency or platform issue):

• Skip: nothing
• Run: all phases with extra emphasis on Research and Hypothesize

/fixit "..." --scope auto         # Detect from triage signals
/fixit "..." --scope minor        # Force minor
/fixit "..." --scope medium
/fixit "..." --scope major

Step 1: Triage

Purpose: Parse the pasted input and classify it into a failure shape that points the RED test at a specific assertion.

1.1 Parse the input

The input is $ARGUMENTS (a paste) or the contents of --file . Strip ANSI color codes and trim trailing whitespace. Identify and record:

• Failure type: compile error, type error, test failure, runtime crash, wrong output, hang or timeout, resource error, behavior mismatch
• Language and framework signals: file extensions, error message patterns, toolchain names (rustc, pytest, tsc, cargo, go, mypy, etc.)
• Artifacts: file paths, line numbers, error codes (E0382, TS2345, EPERM), stack frames, function or symbol names
• Reproduction surface: command that produced the output (if visible), inputs that triggered it (if visible)