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 case. Never propose fixes before completing Phase 1.

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

No. The skill mandates root cause investigation even under time pressure, because systematic debugging is faster than guess-and-check thrashing. Quick symptom fixes set bad patterns, mask underlying issues, and typically create new bugs requiring rework.

Replace arbitrary setTimeout or sleep delays with condition-based waiting that polls for the actual condition you need, such as an event appearing or state changing. Use a waitFor helper with 10ms polling intervals and a timeout with a clear error message.

Stop attempting more fixes and question the architecture. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, not a failed hypothesis. Discuss architectural refactoring with your team before continuing.

Use the find-polluter.sh bisection script with the polluted path and test pattern as arguments. It runs test files one by one, checks whether the pollution appears after each run, and stops at the first offending test.