| name | root-cause-before-fixing |
| description | Diagnose the underlying cause with evidence before proposing or applying any fix. Use this whenever anything is broken, failing, or degraded — bugs, errors, metric drops, missed deadlines, quality problems, process breakdowns, confusing behavior, or any "why is X happening", "X stopped working", "X got worse", "fix this" request. Trigger even when the cause looks obvious or the user has already named a suspect: a symptom that pattern-matches a known failure often has a different cause, and this skill exists precisely for those cases. |
Root Cause Before Fixing
The most salient symptom is rarely the cause, and a signal that pattern-matches a
familiar failure may have a different origin this time — evidence has to support the
specific fix chosen, not just resemble a case where that fix once worked. Fixes aimed
at symptoms make the problem quietly recur, now with less trust and a misleading
"already fixed" label on it. The diagnosis happens first; the fix is its output.
Process
- Pin down the actual failure. State what is observably wrong — the concrete
error, number, or behavior — separate from interpretations already attached to it.
If the report and the evidence disagree, the evidence wins.
- Trace backward until the chain stops. Ask why the symptom occurs, then why
that occurs, until you reach a cause which, if changed, prevents recurrence
(Five Whys). Stopping at the first plausible "why" is how symptom-fixes happen.
- Name the competing explanations. List the other causes that could produce this
same symptom, and identify what evidence would distinguish them.
- Checkpoint — before any fix is proposed: confirm the evidence in hand supports
your specific cause and rules out (or at least disfavors) the alternatives. If it
can't distinguish them, say so and either gather what would, or present the fix as
conditional on the open question — not as settled.
- Aim the fix at the demonstrated cause, and note what observation would confirm
it actually worked, so a wrong diagnosis surfaces quickly instead of silently.
What this looks like
- Communications: Newsletter opens dropped — before rewriting subject lines, check
whether the send list, send time, or deliverability changed that week; the fix differs
entirely depending on which one did.
- Operations: A team keeps missing deadlines — before adding an approval step, trace
which specific handoff slips and why; more process on the wrong step makes it worse.
- Code: A test fails with a timeout — before raising the timeout, check whether the
operation genuinely got slower or is deadlocking; a bigger timeout hides the second.
Output rules
- Never narrate your own diligence ("I carefully verified...", "having ruled out...",
"as instructed, I..."). The discipline shows in the work product — a fix that names
its cause and why alternatives don't fit — not in self-description.
- Keep output proportionate to the task: a small problem gets a short diagnosis and
fix, not a formal report.
- The tracing and ruling-out happen before or while producing the answer; only their
results appear in the output, and only where they help the reader trust the fix.
Grounding: Anthropic, Prompting Claude Fable 5 (check evidence supports the specific action; pattern-matched signals may have different causes); Ohno 1988, Toyota Production System (Five Whys); Google SRE Book, Postmortem Culture.
