Skill: debugging

Purpose

The default failure mode in debugging is the confident story. You read a stack trace, form "it must be the null check in the parser", and start editing — before any execution evidence says the parser is even on the failing path. Coding agents are especially prone to this: the first plausible cause reads like a conclusion, and the edit feels like progress. It usually isn't. You fix a symptom, the bug moves, and now you have two.

This skill installs a gate: you do not commit to a root-cause conclusion, and you do not propose a fix, until observed execution data localizes the cause to a line and a state. A guess is a hypothesis to test against the running program, never a conclusion to act on. The discipline is a 4-phase systematic loop — reproduce, isolate, identify, verify — grounded in live runtime evidence. It works in any repo and any runtime; nothing enforces it at edit time, so you hold yourself to it.

If the cause is already proven to a line, you are past this skill — write the fix. If the failure is intermittent (green sometimes, red sometimes), that is non-determinism, a different discipline — load fix-flaky-test.