systematic-debugging

Start by reading the full error message and stack trace, then build a tight feedback loop such as a single failing pytest command that reproduces the exact symptom. Only after isolating the root cause should you form hypotheses and implement a fix verified by a regression test.

Root cause analysis means tracing a bug to its origin in the code or data flow rather than patching the visible symptom. This Skill enforces it through a four-phase process: investigation, pattern analysis, hypothesis testing, and implementation.

Raise the reproduction rate by running the trigger repeatedly, parallelizing executions, adding stress, narrowing timing windows, or injecting sleeps. A 50% flake is debuggable, while a 1% flake usually requires more instrumentation first.

Stop after three failed fix attempts. If each fix reveals new shared state or coupling in a different place, or fixes create new symptoms elsewhere, the pattern indicates an architectural problem that needs discussion before more patching.

Yes. For systems spanning APIs, services, and databases, it directs you to add diagnostic logging at each component boundary, run once to gather evidence showing where data breaks, then investigate only the failing component.