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 symptom 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 where the error appears.

No. The skill mandates root cause investigation first because systematic debugging is faster than guess-and-check thrashing. Quick symptom fixes set a bad pattern, mask the real issue, and typically cause rework and new bugs.

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 the included waitForEvent helpers with a timeout and 10ms polling interval.

Stop attempting more fixes and question the architecture. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, so discuss architectural refactoring with your team before trying fix number four.

Run the included find-polluter.sh bisection script with the polluted file path and test pattern. It runs each test file individually and stops at the first one that creates the unwanted file or directory.