systematic-debugging

Follow the four phases: investigate the root cause by reading errors and reproducing consistently, analyze patterns against working examples, form and test a single hypothesis, then implement one fix with a failing test. Never propose fixes before completing the investigation phase.

Trace backward through the call chain from the immediate cause to the original trigger, asking what called each function and what value was passed. Add stack trace instrumentation with console.error before the failing operation, then fix at the source rather than where the error appears.

No. The skill mandates root cause investigation first because systematic debugging is faster than guess-and-check thrashing. Quick patches mask underlying issues and create new bugs, and the first fix sets the pattern for everything after.

Replace setTimeout and sleep calls with condition-based waiting that polls for the actual condition you care about, such as an event appearing or state changing. Use a 10ms polling interval with a timeout, and only keep arbitrary delays when testing actual timing behavior with documented justification.

Stop and question the architecture rather than attempting a fourth fix. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, so discuss refactoring the architecture with your team before continuing.

Use the included find-polluter.sh bisection script, which runs test files one by one and checks whether the unwanted file or directory appears after each run. It stops at the first polluting test and reports the file for investigation.