systematic-debugging

Follow the four phases: investigate the root cause by reading errors and reproducing the issue, analyze patterns against working examples, form one hypothesis and test it minimally, then implement a single fix with a failing test first. Never stack multiple fixes at once.

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 first, arguing systematic debugging is faster than guess-and-check thrashing. Quick symptom fixes set a bad pattern, mask the real issue, and frequently introduce new bugs.

Replace arbitrary setTimeout or sleep delays with condition-based waiting that polls for the actual condition you care about, such as an event appearing or state changing. Poll every 10ms with a timeout, and only use fixed delays for documented timing behavior.

Stop attempting more fixes and question the architecture. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, so discuss refactoring the architecture with your team instead of attempting a fourth fix.

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.