systematic-debugging

Follow the four phases: reproduce the failure consistently and read error messages completely, compare against working examples, form one specific hypothesis and test it minimally, then create a failing test case before implementing a single fix. Never change multiple things at once.

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

The skill mandates root cause investigation even under time pressure, arguing that systematic debugging is faster than guess-and-check thrashing. Quick symptom fixes mask the real issue and typically cause the incident to recur.

Flaky tests usually rely on arbitrary setTimeout delays that guess at timing. Replace them with condition-based waiting that polls for the actual expected state or event, which eliminates race conditions and typically speeds up execution.

Stop attempting more fixes and question the architecture instead. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, which should be discussed before further patching.

Never, according to the skill. Simple bugs have root causes too, and skipping investigation for seemingly easy issues is listed as a rationalization that leads to rework and new bugs.