← ClaudeAtlas

root-causelisted

Find the mechanism behind a failure instead of patching its symptom. Reproduce first, change one variable per experiment with the prediction written before the run, bisect rather than re-read, and exit by naming the mechanism and pinning it with a failing test. Use for a bug, an unexplained red test, or a failure that will not reproduce.
jjanczur/tyran · ★ 79 · AI & Automation · score 78
Install: claude install-skill jjanczur/tyran
# Root cause — working a failure down to its mechanism > This is the situation the conductor is told to spend its most expensive > reasoning on: a diagnosis, a failure nobody can reproduce, two agents who > disagree. Spending more thinking on an undisciplined search just produces a > more confident wrong answer, so here is the discipline. ## Reproduce first. Everything else is downstream of this **A fix for a bug you cannot reproduce is a guess with a diff attached.** You cannot tell whether it worked, and neither can the reviewer — the bug's absence after the change is indistinguishable from the bug's absence before it. Get to the smallest reliable reproduction you can, and write down the exact command, input and environment. If it reproduces only sometimes, capture the rate — "3 of 20 runs" is a fact you can measure against later, "it is flaky" is not. If it will not reproduce at all, that is now the task: what does the failing environment have that yours does not — version, data, timezone, concurrency, permissions, a warm cache? ## Read the whole error The first line names where it surfaced, not where it went wrong. Read the full stack, the frames from your own code in particular, and everything logged in the seconds before. The answer is stated outright more often than anyone expects, which is why "I read the error" and "I read the first line of the error" have to be different sentences. ## One variable, and write the prediction first Change ONE thing per experime