agentsclimarketplace

Root cause before fixing

Skill kalshamsi/fable-discipline-skills/skills/root-cause-before-fixing

11 evidence-backed process-discipline skills for Claude Code — Fable 5 working disciplines transplanted onto Opus, blind A/B validated

Install
npx -y skills add kalshamsi/fable-discipline-skills --skill root-cause-before-fixing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.5 KB, as published. Nobody here has run it

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

  1. 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.
  2. 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.
  3. Name the competing explanations. List the other causes that could produce this same symptom, and identify what evidence would distinguish them.
  4. 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.
  5. 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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.