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 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, and fix at the source rather than the symptom.

No. The skill mandates root cause investigation first because systematic debugging is faster than guess-and-check thrashing, and symptom fixes mask underlying issues. Quick patches set a bad pattern and typically cause rework.

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. Arbitrary timeouts are only acceptable for documented timing behavior like debounce intervals.

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, which requires architectural discussion before more fixes.

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 it for investigation.