Two-Strike Debug

Triggers automatically when relevant; invoke directly with /two-strike-debug or ask, e.g. "diagnose this failure".

A fix without a confirmed diagnosis is a guess. Two failed guesses of the same kind mean the diagnosis is wrong — not the implementation.

Protocol — in order, no skipping

1. REPRODUCE   deterministically. Can't reproduce → THAT is the task now,
               not fixing blind.
2. READ        the actual, full error output. Not your memory of a similar
               error — most of the time the answer is already in the output.
3. LOCALIZE    to the smallest failing unit: bisect commits, halve inputs,
               instrument boundaries. Instrument BEFORE speculating.
4. HYPOTHESIZE in one sentence: "It fails because X."
               Can't write that sentence → return to 3.
5. EXPERIMENT  with the smallest change that tests ONLY the hypothesis.
               One variable at a time.
6. FIX         — and first capture the failing case as a test where
               possible: red→green proves the test tests the right thing.
7. RE-VERIFY   with the exact check that originally failed, then the full
               gate (build + tests), not just the local one.

The two-strike rule

Two fixes of the same class have failed → STOP. The bug is in your diagnosis, not your implementation. Return to step 3 assuming "my hypothesis was wrong." A third attempt at the same idea is forbidden — looping on a wrong theory is the most expensive failure mode there is.

Anti-patterns

• ✗ Pattern-match fixes — "I've seen this, it's probably X" — without reading the real output. A similar symptom is not the same cause.
• ✗ Shotgun fixes: changing several things at once. Even if it passes, you won't know why.
• ✗ Suppressing the error to get green: catch-and-ignore, loosening an assertion. Allowed only with an explicit statement of why the CHECK was wrong, not the code.
• ✗ Labeling a failure "flaky" without running it 5 times. Instability is data, not an excuse.
• ✗ Restarting / clearing / reinstalling as step 1. A state reset can mask the bug and destroy the evidence.

Relationship to other skills

• Runs inside universal-loop Step 5 (Loop): the loop counts iterations; this protocol makes each iteration count.
• After the fix, verification-before-completion gates the "done" claim.
• When even re-diagnosis has failed and the user reports failure again, escalate per compounding-engineering §5: fresh context, carrying evidence, not hypotheses.