systematic-debugging

Follow the four phases: first investigate the root cause by reading errors and reproducing consistently, then analyze patterns against working examples, form a single testable hypothesis, and finally implement one verified fix with a failing test case.

Root cause analysis traces a bug backward through the call stack to find the original trigger rather than fixing where the error appears. The skill provides instrumentation techniques like stack trace logging to locate the source of bad data.

Replace arbitrary setTimeout or sleep delays with condition-based waiting that polls for the actual expected state, such as an event appearing or a count being reached. This eliminates race conditions and typically speeds up test execution.

No. The skill explicitly states that simple bugs have root causes too and that systematic investigation is faster than guess-and-check thrashing, even during production emergencies with revenue at stake.

After three failed fixes, stop and question the architecture rather than attempting a fourth fix. Repeated failures revealing new problems in different places indicate a fundamental design issue requiring discussion, not another patch.

Use the included find-polluter.sh bisection script, which runs test files one by one and checks whether unwanted files or directories appear after each run, stopping at the first polluting test.