Root Cause Analysis

Find the real cause of an incident, a recurring failure, or a process problem — the kind with no failing test to reproduce — and drive it to a durable countermeasure. Blame-free by design: the goal is a systemic fix, not a person to fault.

When to use vs awesome-bug-fix and awesome-performance-audit

• This skill — an outage retro, a "this keeps breaking", a data-quality or handoff or deploy-process problem, a near-miss. The failure lives in process, environment, or coordination, and you can't just run it and watch it fail.
• awesome-bug-fix — a specific code bug with a reproduction. If you can write a failing test, use that skill; come here when there's nothing to run.
• awesome-performance-audit — a service or page that is slow, leaks memory or spikes in latency, even on a recurring schedule; measurement comes before asking why.

If the problem is a mix (a code bug that a broken process let ship), fix the bug in awesome-bug-fix and use this skill on the process that allowed it.

Workflow

1. Frame the problem

State it as an observable gap, not a solution or a culprit: current condition vs expected condition, when it started, how often, blast radius, and how you know (the evidence — logs, tickets, timeline). If you can't state the gap concretely, gather more before analyzing.

Build the timeline from records (logs, tickets, deploy history, chat), not from memory, with four separate marks: onset, detection, mitigation, resolution. Time-to-detect (onset to detection) is a finding in its own right. Signals lag: an alarm fires after its evaluation window, a metric datapoint is stamped at one edge of its aggregation period (often the start), not when the event happened, logs flush late, audit events arrive after the action. So onset is the earliest anomaly in the raw data, not the time the alarm fired. A gap in the timeline that the records cannot explain is a question for the team, not a blank to fill with a guess.