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 verified fix. Never propose fixes before completing the investigation phase.

Replace setTimeout and 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, which eliminated flakiness and ran 40% faster in real sessions.

Stop and return to Phase 1 to re-analyze with the new information rather than stacking more fixes. If three or more fixes have failed, stop entirely and question whether the underlying architecture is wrong, discussing it with your team before attempting another fix.

No. Systematic investigation is faster than guess-and-check thrashing, which typically causes hours of rework and new bugs. The skill explicitly addresses time pressure rationalizations and mandates root cause investigation even when a quick fix seems obvious.

Trace backward from the immediate cause by asking what called each function and what values were passed, until you find the original trigger. Add stack trace instrumentation with console.error before the failing operation, and fix at the source rather than where the error appears.

Single-point validation can be bypassed by other code paths, refactoring, or mocks. Apply defense-in-depth by validating at every layer data passes through: entry points, business logic, environment guards, and debug instrumentation, making the bug structurally impossible.