| 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
-
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.
-
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.
-
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.
-
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.
-
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.
