awesome-root-cause

# 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 - **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. 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. ### 2. Widen the candidates (fishbone) Before drilling, sweep six cause categories so you don't fixate on the obvious one — **People, Process, Technology, Environment, Methods, Materials**. List candidate contributors under each. Root causes sit in **Process** or **Methods** far more often than in Technology; a purely technical cause is the exception,...