← ClaudeAtlas

root-causelisted

Establish why something actually happened by iterating why until the answer stops changing, with each link citing an observation - and know the two ways the method lies. Use before filing a bead off a failure, before proposing a rule or a gate to prevent a recurrence, when a fix addresses a symptom, or when a retro asks for a cause.
niksavis/basicly · ★ 0 · AI & Automation · score 72
Install: claude install-skill niksavis/basicly
<!-- Generated by `basicly skills-build` from skill.yaml. Do not edit; edit the source. --> # Root Cause ## First: is this one occurrence? **A single failure inside the normal range is common cause, and acting on it makes things worse.** Deming's funnel experiment: adjusting a stable process in response to ordinary variation "invariably increases variation in the results". Run this analysis on a *signal*, not on an incident. A signal is a point beyond 3σ, or a non-random pattern — a run, a trend — inside the limits (NIST/SEMATECH e-Handbook §pmc31). In this repo the practical test is cheaper: **has this shape happened before?** Query the ledger before you analyse. ```sh jq -r 'select(.kind=="created")|.payload.title // empty' .basicly/ledger/events-*.jsonl \ | rg -i '<the shape>' rg -c '<the marker>' .basicly/usage/run-records.json ``` A record's title is on its `created` event and nowhere else, so a query over every event returns nothing — and nothing reads as "no prior", which is the answer that ends the analysis. Confirm the pipeline's first stage prints titles before believing a zero. One occurrence with no prior: record it and stop. Filing a bead off a single event is how twelve records came to name one truncation while none asked why the trigger fired. ## The method Iterate *why* until the answer stops changing. Two rules make it worth doing: 1. **Every link cites an observation, not an inference.** A `file:line`, a command and its output, a ledger row, a