/fixit

name: fixit
description: Fix broken functionality from pasted error output, stack traces, or
  failing-behavior descriptions using research, TDD, and proof-of-work evidence.
usage: /fixit <pasted-error-or-description> [--file <path>] [--scope auto|minor|medium|major]
  [--from <step>] [--to <step>] [--research|--no-research] [--strict|--quick]
  [--commit] [--dry-run]
extends: "imbue:proof-of-work"

Fix It

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

| # | Step | Purpose | Skill invoked | Skip when | |---|------|---------|---------------|-----------| | 1 | Triage | Parse input, classify failure type, extract artifacts | inline classifier (see below) | `--from` overrides | | 2 | Reproduce | Capture failing state as evidence `[E1]` | `Skill(imbue:proof-of-work)` | failure already running | | 3 | Research | Find prior art for novel errors | `Skill(tome:code-search)` or `Skill(tome:research)` | scope=minor or `--no-research` | | 4 | Hypothesize | Build hypothesis ladder, pick most-likely cause | `Skill(superpowers:systematic-debugging)` | cause is obvious from triage | | 5 | Test (RED) | Write the failing test that captures the bug | `Skill(superpowers:test-driven-development)` and `Skill(imbue:proof-of-work)` iron-law-red | never (Iron Law) | | 6 | Fix (GREEN) | Smallest change to make the test pass | `Skill(imbue:karpathy-principles)` (surgical-edits) | never | | 7 | Verify | Run tests and capture evidence `[E2]`; confirm regression-free | `Skill(superpowers:verification-before-completion)` and `Skill(imbue:proof-of-work)` iron-law-green | never | | 8 | Report | Summarize fix with evidence; optional commit | `Skill(sanctum:commit-messages)` and `/sanctum:acp` (with `--commit`) | default no-commit |

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 <path>`. 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)

1.2 Classify scope

Score the failure on three dimensions, then pick the scope:

| Signal | Minor | Medium | Major | |--------|-------|--------|-------| | Files touched (estimate) | 1 | 1 to 3 | 4 or more | | Familiar error code? | yes | yes | no or rare | | Library or platform involved? | std-lib only | known dep | unfamiliar