Root Cause Analysis

Stop guessing, start diagnosing.

Why This Exists

The default debugging behavior is shotgun debugging: see an error, pattern-match to the most common cause from training data, suggest a fix, and if it doesn't work, suggest another fix. This creates a frustrating loop where the user tries fix after fix while the actual root cause remains undiagnosed.

This skill enforces systematic diagnosis. The goal is to identify the ACTUAL root cause on the first pass, not to iterate through possible causes hoping one sticks. Every debugging session should narrow the problem space with each step, not randomly sample it.

The fundamental discipline: understand before you fix. A fix applied without understanding why it works is not a fix — it's a coincidence that will break again.

The Anti-Patterns to Avoid

Before the methodology, internalize what NOT to do — these are the specific failure modes that make LLM debugging frustrating:

<anti_patterns> Premature diagnosis. Reading an error message and immediately jumping to "the problem is X, try Y." The error message is a symptom, not a diagnosis. Multiple different root causes can produce identical error messages. Never diagnose from the error message alone — diagnose from the error message + the code path + the execution context + what changed.