systematic-debugging

Follow the four-phase process: investigate the root cause by reading errors and reproducing the issue, analyze patterns against working examples, form and test a single hypothesis, then implement one fix verified by a failing test. Never propose fixes before completing Phase 1.

Replace setTimeout or sleep calls 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 clear timeout error, and only use arbitrary delays when testing actual timing behavior with documented justification.

Use root cause tracing: find the immediate cause, then trace backward through each caller to find where the bad value originated. Add stack trace instrumentation with console.error before the failing operation, fix at the source, and add defense-in-depth validation at each layer.

Stop after three failed fix attempts. If each fix reveals new problems in different places or requires massive refactoring, the pattern indicates an architectural problem. Discuss fundamentals with your team before attempting a fourth fix.

No. The skill explicitly states simple bugs have root causes too, and systematic debugging is faster than guess-and-check thrashing even under time pressure. Skipping the process is listed as a rationalization that leads to rework.