systematic-debugging

Start by reading the full error message and stack trace, then reproduce the failure consistently with a command like pytest -v. Check recent git changes, trace the data flow to the source of the bad value, and only then form a hypothesis and test it with a minimal change.

Root cause analysis means identifying why a bug happens before fixing it, rather than patching symptoms. This Skill enforces it through Phase 1: read errors, reproduce the issue, review recent changes, gather evidence at component boundaries, and trace data flow upstream.

Stop after three failed fix attempts. If each fix reveals new coupling or creates symptoms elsewhere, the pattern indicates an architectural problem. Discuss refactoring the design with the team instead of attempting a fourth fix.

Yes, the process is designed especially for emergencies, since guessing under pressure causes thrashing and rework. A systematic investigation typically resolves issues in 15-30 minutes versus hours of random fix attempts.

Quick patches address symptoms rather than root causes, so the underlying issue persists and resurfaces elsewhere. Bundling multiple changes also makes it impossible to isolate what worked, and untested fixes lack regression protection.