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 the investigation phase.

Trace backward through the call chain from the error point to the original trigger, asking what called each function and what value was passed. Add stack trace instrumentation with console.error before the failing operation if manual tracing is not possible.

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

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.

Stop attempting fixes and question the architecture. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, so discuss architectural refactoring with your team before trying another fix.

Never. The skill explicitly rejects skipping for simple bugs, time pressure, or manager demands, since simple issues still have root causes and rushing guarantees rework. The process is fast for simple bugs.