systematic-debugging

Start by reading the full error message and stack trace, then build a tight loop command that reproduces the exact symptom. Trace the data flow to the root cause, form ranked hypotheses, and test one variable at a time before implementing a single verified fix.

Root cause analysis means understanding why a bug happens before fixing it, rather than patching symptoms. This Skill enforces it through Phase 1 investigation: reading errors, reproducing the issue, checking recent changes, and tracing bad values to their source.

Raise the reproduction rate by running the trigger 100 times, parallelizing, adding stress, narrowing timing windows, or injecting sleeps. A 50% flake is debuggable; a 1% flake usually is not, so prioritize loop reliability over immediate fixes.

After three failed fix attempts, stop and question the architecture. Signals include each fix revealing new shared state in different places, fixes requiring massive refactoring, or each fix creating new symptoms elsewhere.

Yes. For systems spanning APIs, services, and databases, add diagnostic instrumentation at each component boundary first. Log data entering and exiting each layer, run once to gather evidence, then isolate and investigate the failing component.