A long machined plate on a falling diagonal carrying a sheared pin at its high end and a row of meshed gears of decreasing size down to a mounting bracket with a loose bolt; the diagonal cut ghosts the last gear and the bracket in bone-grey outline, and one electric-blue line runs from the pin's broken face through every gear hub into the bracket.
Other

RootCauseAnalysis

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

05
Workflows
00
Tools
02
References
10
Triggers

The Problem

When something breaks, the natural move is to fix the most visible thing and move on. A chatbot asked to help will name the proximate cause — the thing that crashed, the config that was wrong, the person who made the mistake — and stop there. That's not root cause analysis; it's triage with a longer answer. The same failure happens again in three months because the conditions that made it possible are still in place. 'Human error' gets written in the postmortem and nothing structurally changes.

How This Skill Approaches It

Five workflows cover different failure shapes. FiveWhys builds a linear or branching causal chain, forcing you past the proximate cause until you reach something you can actually fix. Fishbone maps the 6 M's (Manpower, Machine, Method, Material, Measurement, Mother-Nature) or 4 P's when multiple cause categories are suspected. Postmortem structures a blameless timeline with contributing factors and action items — the format teams can actually be honest in. FaultTree uses AND/OR gate logic for safety-critical failures where multiple independent paths could each trigger the outcome. KepnerTregoe IS/IS-NOT builds a distinction table for the subtle defect that only appears in CI, only on Tuesdays, only with parallel workers — the kind of bug that defeats guesswork. For non-trivial incidents, Postmortem wraps the others: start with the blameless timeline, pull in FiveWhys or Fishbone as investigation tools inside it. The skill operates on five axioms: proximate cause is where analysis starts; incidents have multiple contributing factors, not one; humans are never root causes; you stop at a cause you can act on; and RCA is a bias-fight.

Not for systemic loops (use SystemsThinking)

In Action

What you say to your DA, and what the RootCauseAnalysis skill actually does.

  • You say "the payments service went down for 14 minutes last night, help me write the postmortem"
    Runs Postmortem workflow: reconstructs the blameless timeline from deploy to rollback, runs FiveWhys inside to trace the latency spike to its contributing factors, identifies both active failures and latent conditions, and produces action items that prevent the failure class — not just the specific incident.
  • You say "we've fixed this auth bug three times and it keeps coming back, what's actually wrong"
    Runs Fishbone workflow: expands across all 6 M categories to find why no single fix has held, surfaces the latent conditions (likely Method + Measurement) that let the bug regenerate, and identifies the structural change that would actually close the loop.
  • You say "this test only fails in CI, never locally — what's the actual cause"
    Runs KepnerTregoe workflow: builds an IS/IS-NOT distinction table across environment, timing, concurrency, and filesystem axes to isolate the specific combination triggering the failure — rather than guessing at environment differences.

Inside the Skill

The thinking, frameworks, and architecture that distinguish this skill from a generic version of the same task.

Ideal State

  • The method fits the failure class, as the situation table under Intent Routing maps it, and a non-trivial incident is written as a Postmortem with the other methods as its investigation tools.
  • Every diagnosis is evidence-backed and blameless, with 3+ actionable systemic contributing factors rather than a single blame target. It ends at causes that are both systemic and within authority to change, never at a person to blame, and each corrective action prevents a class of recurrence rather than the latest trigger.
  • Every conclusion that rests on a fact the request supplied cites that fact, checked at its source, and a caller's hypothesis is never taken as fact.
  • Decisions are judged using the information available at the time.
  • What the evidence cannot support is disclosed as a gap or a hypothesis, never filled with invented causes, probabilities or comparisons, and never padded with invented factors to meet the 3+ target.
  • The analysis delivered is finished; no sub-work is still running when it is handed over.

Intent Routing

Intent Trigger File
FiveWhys "5 whys", "five whys", quick causal chain, ask why until root Intents/FiveWhys.md
Fishbone "fishbone", "ishikawa", categorized cause map, 6 M's / 4 P's / 8 M's Intents/Fishbone.md
Postmortem "postmortem", "incident review", "blameless postmortem", production incident Intents/Postmortem.md
FaultTree "fault tree", "fta", top-down deductive, safety-critical, AND/OR logic Intents/FaultTree.md
KepnerTregoe "kepner tregoe", "is/is-not", "what changed", distinction analysis, subtle defects Intents/KepnerTregoe.md
Situation Preferred intent
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
File Read when
MethodSelection.md choosing, combining or switching methods: decision flow, method comparison, domain map, speed-versus-thoroughness
Foundation.md evidence crosses service boundaries, or the work uses Apollo evidence graphs or FMEA prioritization

Standalone; no required skill dependency. Use SystemsThinking (Iceberg, FindArchetype) for recurring structural causes, FirstPrinciples to decompose a contributing factor, RedTeam to stress-test remediations, and Science for investigation hypotheses.

Data & Config

User customizations live at <configRoot>/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/RootCauseAnalysis/ (configRoot is $CLAUDE_CONFIG_DIR when set, else ~/.claude). When that directory exists, its PREFERENCES.md, configurations and resources apply and override the defaults here; when it is absent, the defaults stand.

Gotchas

  • Start from the facts and paths the request supplies and read those paths; do not search for them again. Any search names the paths it covers, never the whole home tree or ~/Projects. This scopes where to look, never what may be investigated.

Examples

Example 1: Production outage

User: "Payments threw 500s for ten minutes after last night's deploy. Write the postmortem."
→ Postmortem intent, with FiveWhys or Fishbone on each contributing thread
→ A blameless record with a UTC timeline, defensive-layer map and strength-rated owned actions

Example 2: Works here, not there

User: "The export job fails only on the EU cluster and only on Mondays. Why?"
→ KepnerTregoe intent
→ An IS/IS-NOT matrix, the change that explains every IS without predicting the IS-NOTs, and a test to confirm it

Example 3: Quick causal chain

User: "5 whys on why the nightly backup keeps missing its window"
→ FiveWhys intent
→ An evidenced chain to systemic causes, read forward with no gaps, and owned corrective actions

Workflows & Routing · 5

Each workflow is one job the skill runs. The trigger phrases route your request to the right one — this is the skill's routing table.

  1. 01
    FiveWhys Intents/FiveWhys.md

    5 whys, five whys, quick causal chain, ask why until root

  2. 02
    Fishbone Intents/Fishbone.md

    fishbone, ishikawa, categorized cause map, 6 Ms / 4 Ps / 8 Ms

  3. 03
    Postmortem Intents/Postmortem.md

    postmortem, incident review, blameless postmortem, production incident

  4. 04
    FaultTree Intents/FaultTree.md

    fault tree, fta, top-down deductive, safety-critical, AND/OR logic

  5. 05
    KepnerTregoe Intents/KepnerTregoe.md

    kepner tregoe, is/is-not, what changed, distinction analysis, subtle defects

How to Invoke

Say any of these to your DA and LifeOS activates the RootCauseAnalysis skill automatically:

  • "root cause"
  • "RCA"
  • "5 whys"
  • "fishbone"
  • "postmortem"
  • "incident analysis"
  • "fault tree"
  • "why does this keep failing"
  • "blameless"
  • "recurring bug"

Or invoke explicitly:

Skill("RootCauseAnalysis")

References · 2

Auxiliary files the skill loads at runtime — frameworks, guides, configs.

  • Foundation
  • MethodSelection

Want LifeOS to do this for you?

Install LifeOS on your machine — your DA gets the RootCauseAnalysis skill plus 96 others, all hooked into one Life OS.