/RootCauseAnalysis

name: RootCauseAnalysis
version: 1.0.7
description: "Structured incident investigation using Five Whys, Fishbone, blameless Postmortem, Fault Tree, Kepner-Tregoe, and FMEA — traces failures to systemic root causes rather than blaming humans. USE WHEN root cause, RCA, 5 whys, fishbone, postmortem, incident analysis, fault tree, why does this keep failing, blameless, recurring bug. NOT FOR systemic loops (use SystemsThinking)."
context: fork
background: false

Customization

**Before executing, check for user customizations at:** `~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/RootCauseAnalysis/`

If this directory exists, load and apply any `PREFERENCES.md`, configurations, or resources found there. These override default behavior. If the directory does not exist, proceed with skill defaults.

MANDATORY: Voice Notification (REQUIRED BEFORE ANY ACTION)

**You MUST send this notification BEFORE doing anything else when this skill is invoked.**

1. **Send voice notification:**

   curl -s -X POST http://localhost:31337/notify \
     -H "Content-Type: application/json" \
     -d '{"message": "Running the WORKFLOWNAME workflow in the RootCauseAnalysis skill to ACTION"}' \
     > /dev/null 2>&1 &

2. **Output text notification:**

   Running the **WorkflowName** workflow in the **RootCauseAnalysis** skill to ACTION...

**This is not optional. Execute this curl command immediately upon skill invocation.**

---

RootCauseAnalysis Skill

What It Does

Investigates why something failed — past the proximate cause, down to the contributing factors and latent conditions that actually made the failure possible. It offers five structured methods (5 Whys, Fishbone, Postmortem, Fault Tree, Kepner-Tregoe) and ends with actionable changes that prevent a whole class of failure, not just the one incident. Grounded in Toyota Production System, Ishikawa, Reason's Swiss Cheese model, Gano's Apollo method, and Google SRE / Etsy blameless culture.

How It Works

The goal is not "the" root cause — that framing is almost always wrong. **A good RCA ends with 3+ actionable, systemic contributing factors, named blamelessly, that prevent a class of failure — not a single blame target.** Everything below is structure that pushes the analysis past the first plausible answer, past blame, and stops only at causes you can actually change.

Core Concept

Five axioms this skill operates on:

1. **Proximate cause ≠ root cause.** "The deploy failed because X crashed" is usually where real analysis *starts*, not where it ends. 2. **There is rarely one cause.** Incidents typically have multiple contributing factors — active failures (what a human did) and latent conditions (what the system allowed). James Reason's Swiss Cheese model. 3. **Humans are not root causes.** "Operator error" is a stop sign for analysis, not a conclusion. If a human could make the mistake, the system allowed it. Go deeper. 4. **Actionability is the stop condition.** A cause is "root enough" when it points to a change you can actually make. Go too shallow and you miss the fix; go too deep ("physics") and you can't act on it. 5. **RCA is a bias-fight.** Hindsight bias, confirmation bias, single-cause bias, and outcome bias all actively corrupt investigations. Structure exists to resist them.

Use / Win

**When to use:**

• **Any incident or outage** — production failure, security event, deploy gone bad.
• **Recurring defects** — bugs of the same shape keep appearing despite fixes.
• **Quality problems** — metrics drifting, users reporting the same class of issue.
• **Postmortems** — structured, blameless review of an incident's causal chain.
• **Pre-launch risk analysis** — inverting RCA with FMEA to catch failure modes before they happen.
• **Security investigations** — chain of events, contributing controls, latent conditions.
• **Process failures** — a person or team consistently missing a mark. Structure is probably the cause.

**What you win:**

• **Actionable contributing factors** (plural) rather than a single blame target.
• **Latent conditions surfaced** — the Swiss cheese holes lining up that nobody knew were there.
• **Durable fixes** — structural changes, not patches to the specific failure.
• **Blame-free analysis** — the team can be honest about what happened without self-protective omissions.
• **Cross-incident pattern recognition** — after a few RCAs, the repeated latent conditions become visible.
• **Discipline against bias** — structured methods force you past the first plausible story.

**Default mental model:** If the same failure class could happen again tomorrow, you haven't done RCA — you've done triage.

Workflow Routing

Route to the appropriate workflow based on the request.

| Workflow | Trigger | File | |----------|---------|------| | **FiveWhys** | "5 whys", "five whys", quick causal chain, ask why until root | `Workflows/FiveWhys.md` | | **Fishbone** | "fishbone", "ishikawa", categorized cause map, 6 M's / 4 P's / 8 M's | `Workflows/Fishbone.md` | | **Postmortem** | "postmortem", "incident review", "blameless postmortem", production incident | `Workflows/Postmortem.md` | | **FaultTree** | "fault tree", "fta", top-down deductive, safety-critical, AND/OR logic | `Workflows/FaultTree.md` | | **KepnerTregoe** | "kepner tregoe", "is/is-not", "what changed", distinction analysis, subtle defects | `Workflows/KepnerTregoe.md` |

Quick Reference

• **5 workflows** — FiveWhys, Fishbone, Postmortem, FaultTree, KepnerTregoe
• **5 Whys:** Linear/branching causal chain. Best for simple, single-thread incidents.
• **Fishbone:** 6 M's (Manpower, Machine, Method, Material, Measurement, Mother-Nature) for manufacturing; 4 P's (People, Process, Policies, Procedures) for service. Use when multiple category causes are suspected.
• **Postmortem:** Timeline + contributing factors + action items. Blameless framing mandatory.
• **Fault Tree:** AND/OR gate logic, deductive, top-down. Best for