root-cause-debugginglisted

# Root Cause Debugging ## Purpose The failure mode this skill exists to prevent is *symptom suppression*: adding a null check where the crash happens, wrapping the call in try/catch, adding a frame of delay, reordering initialisation until it works. The symptom goes away, the cause remains, and the bug returns later wearing a different mask -- usually in a build that ships. This skill enforces a rule: **no fix without a stated cause.** The cause must explain every observed symptom, including the ones that seem incidental. ## When to use - Any crash, exception, assertion, hang, or corrupted state. - Wrong output, wrong values, wrong visuals, wrong ordering. - "It works on my machine", or works in the editor but not in a build. - Intermittent or timing-dependent failures. - A regression: something that used to work. - Reviewing a fix whose description does not name a cause. ## When NOT to use - The behaviour is correct but too slow. Use `performance-profiling-method`. - The code is correct but badly structured. Use `refactoring-safely`. - The requirement itself is wrong or ambiguous. That is a specification problem; resolve what the behaviour *should* be before debugging what it *is*. - You are hunting for defects that have not been reported. Use `code-review-method`. ## Required context | Fact | Why it matters | Where to find it | |---|---|---| | Exact symptom | "Broken" is not a symptom | Reporter, screenshot, video | | Exact error text and stack trace | Names the