RootCauseAnalysis

What this skill does

## Customization

**Before executing, check for user customizations at:**
`~/.claude/PAI/USER/SKILLCUSTOMIZATIONS/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:**
   ```bash
   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

Structured investigation of *why* something failed — beyond the proximate cause, down to the contributing factors and latent conditions that actually made the failure possible. Grounded in Toyota Production System (Sakichi Toyoda), Kaoru Ishikawa, James Reason's Swiss Cheese model, Dean Gano's Apollo method, and Google SRE / Etsy blameless-postmortem culture.

The goal is not to find "the" root cause — that framing is almost always wrong. The goal is to identify **contributing factors** that are **actionable**. A good RCA ends with changes that prevent a class of failure, not just the specific incident.

## 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 safety-critical and complex multi-path failures.
- **Kepner-Tregoe IS/IS-NOT:** Identify distinctions between where the problem occurred and where it did not. Best for subtle, hard-to-reproduce defects.

**Context files (loaded on demand):**
- `Foundation.md` — Toyoda, Ishikawa, Reason, Gano, Google SRE; canonical methods
- `MethodSelection.md` — decision flow for which workflow to use

## Method Selection Guide

| Situation | Preferred workflow |
|-----------|---------------------|
| Single-thread incident, one clear failure point | **FiveWhys** |
| Multiple suspected categories (people, process, tools) | **Fishbone** |
| Production outage or security incident, needs formal review | **Postmortem** |
| Complex multi-path failure, safety-critical, need Boolean logic | **FaultTree** |
| Subtle defect, hard to reproduce, "why here and not there?" | **KepnerTregoe** |

For non-trivial incidents: **Postmortem wraps the others.** Start with a Postmortem structure, use 5 Whys / Fishbone / FTA inside it as investigation tools.

## Integration

**Depends on:** nothing — standalone analytical skill.

**Works well with:**
- **SystemsThinking** — RCA stops at contributing factors; SystemsThinking continues down to structure and mental models. Pair them when patterns repeat across incidents.
- **FirstPrinciples** — decompose a contributing factor to its fundamental truths before fixing.
- **RedTeam** — "how would we cause this again?" is adversarial RCA. Use RedTeam to stress-test remediations.
- **Science** — RCA *is* the scientific method applied to failures. Use Science for hypothesis generation during investigation.

## Examples

**Example 1: Production outage**
```
User: "the payments service went down for 14 minutes last night"
→ Postmortem workflow
→ Timeline: deploy at 23:47 → health check passed → traffic shift 23:49 → p99 latency spike 23:51 → auto-rollback 00:01
→ 5 Whys inside: Why did p99 spike? Cold cache. Why cold? New pod group. Why no warm? No warm-up in deploy script. Why? Not in checklist. Why? Template predates the caching layer.
→ Contributing factors: deploy template stale (latent); no warm-up step (active); no cache-cold canary (latent)
→ Remediation: update deploy template, add warm-up step, add cold-cache canary gate
```

**Example 2: Recurring defect**
```
User: "users keep reporting the same kind of auth failure, we've fixed it 3 times"
→ Fishbone workflow
→ 6 M's expansion: People (ops auth rotates keys without notifying infra), Method (no key-rotation runbook), Machine (secret cache TTL exceeds rotation window), Material (shared key instead of per-service), Measurement (no key-expiry dashboard), Mother-Nature (none)
→ Root causes (multiple): Method + Material + Measurement all contribute. Single