systematic-debugging

name	systematic-debugging
description	Use for ANY bug, test failure, crash, or unexpected behavior. Forces reproduce-then-isolate before proposing a fix. Stops the agent from guessing.
when_to_use	a test fails, a crash, wrong output, "it worked yesterday", a flaky failure

Systematic Debugging

The single most expensive agent failure: seeing an error and immediately generating a "fix" based on the error type, without reading what actually happened. Don't.

The loop

1. Read the whole error. The entire message and stack trace. A TypeError can mean a hundred different things — the trace tells you which one. Quote the exact line that throws.

2. Reproduce it first. If you can't reproduce it, you can't verify a fix. Write the smallest input that triggers it. "I think this fixes it" is gambling, not debugging.

3. Form one hypothesis, name it. "I think the value is null because the upstream call returns 204 with no body." State it before you touch anything.

4. Change one thing. Test. Repeat. If you change three things and it works, you don't know which one fixed it — and the other two may have added new bugs.

5. Fix the root cause, not the symptom. A null check that hides a null is not a fix. Find why it's null. The underlying bug will resurface differently if you only patch the crash.

Stop conditions

• If 3 hypotheses fail, STOP and report: what you tried, what you saw, what you suspect. "I've tried X and Y, here's the output, I think it's Z but I'm not sure" beats 20 silent random attempts.
• Never add a workaround you don't understand.

Output

End with: the root cause (one sentence), the minimal fix, and the test that now proves it.