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 case. 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 if manual tracing is not possible.

No. The skill mandates root cause investigation even under time pressure, because systematic debugging is faster than guess-and-check thrashing. Quick symptom fixes mask the real issue and typically create 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 clear error message.

Stop after three failed fixes and question the architecture rather than attempting a fourth. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, which should be discussed before continuing.

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.