Judgement XX — The Root Cause. Catches when success or failure is attributed to the wrong cause. Breaks the LLM default of attribution error — misidentifying WHY things succeed or fail, confusing correlation with causation, crediting the wrong factor, or blaming the most visible actor rather than the actual mechanism. Use this skill when post-mortems feel wrong, when success stories credit the wrong thing, when the 'lesson learned' doesn't match the events, or when the team keeps applying fixes that don't fix. Trigger on: 'judgement this', 'root cause check', 'is that really why', 'attribution audit', 'why did this actually happen', 'wrong lesson', or when the same fix keeps being applied to the same problem without result.
Breaks: Attribution error — the default of misidentifying why things succeed or fail, confusing correlation with causation, crediting the wrong factor, or blaming the most visible actor rather than the actual mechanism.
The trumpet sounds and the dead rise for judgment — not punishment, but reckoning. True reckoning means understanding what actually happened, not what's convenient to believe happened. The deploy failed — was it really the code change, or was it the infrastructure change that happened an hour earlier? The project succeeded — was it really the new methodology, or was it that you hired 3 excellent engineers at the same time? Wrong attribution leads to wrong lessons, which leads to repeating failures and failing to repeat successes.
You find the actual cause. You don't assign blame.
Attributed: yes — a case where the team correctly identified the cause. Not every attribution is wrong.Before analyzing, read the position of your target:
VALUES.md at the repo root if it exists. Values create attribution bias — a team that values "accountability" attributes failures to people. A team that values "engineering excellence" attributes successes to technical decisions. The value shapes which causes are visible and which are hidden.Five arcana. Each catches a different type of attribution error. Use a different arcana for each finding.
Find where the proximate cause is being treated as the root cause. The proximate cause is what triggered the event. The root cause is what made the system vulnerable to that trigger. "The server crashed because of a memory leak" — proximate cause. "The server crashed because there's no memory limit enforcement, no alerting on memory growth, and the service hasn't been restarted in 47 days" — root cause. The fix for the proximate cause patches one leak. The fix for the root cause prevents all leaks.
Find the causal factor that nobody credited (or blamed). Success often has an invisible contributor — the QA engineer who caught a critical bug, the ops person who tuned the infrastructure, the market timing that made the product relevant. Failure often has an invisible contributor — the organizational change that distracted the team, the dependency update that introduced a subtle regression, the on-call rotation that put a junior on a senior-level incident.
Find where correlation is being treated as causation. "We adopted X and metrics improved" — did X cause the improvement? "We hired Y and the project shipped" — did Y cause the ship? Test with the counterfactual: would the outcome have been the same without the attributed cause? If probably yes, the attribution is correlational, not causal.
Find where the attribution is at the wrong level of abstraction. "The bug was caused by a typo" — that's the code level. "The bug was caused by no type checking in the build pipeline" — that's the process level. "The bug was caused by a culture that ships without review under deadline pressure" — that's the organizational level. The level of attribution determines the level of fix. Code-level attribution gets code-level fixes (patch the typo). Org-level attribution gets org-level fixes (change the culture). Wrong level = wrong fix.
Find where the same problem keeps recurring despite being "fixed." This is the strongest signal of attribution error — if the attributed cause was correct and the fix addressed it, the problem wouldn't recur. Repeated failures mean one of: the attributed cause was wrong, the fix was incomplete, or there are multiple causes and only one was addressed. Trace the recurrence pattern to find the actual cause.
Produce exactly 5 findings — one per arcana. This count ensures coverage across all attribution error types: depth of cause (The Proximate vs. Root), hidden factors (The Invisible Contributor), false causation (The Correlation Trap), abstraction level (The Wrong Level), and verification by recurrence (The Repeated Failure).
# XX Judgement — Attribution Check
## Finding 1
**Arcana:** [arcana name]
**Target:** [the specific attribution, explanation, or lesson being examined]
**Attributed:** [yes/no]
### The Reckoning
[Trace the causal chain. Show the attributed cause, the actual mechanism, and whether removing the attributed cause would have changed the outcome.]
### Verdict
[Is the attribution correct? If Attributed: yes, state how the causal chain traces cleanly from cause to outcome. If Attributed: no, state what the actual cause is — or what additional causes the attribution is missing.]
### Reversed
[The counter-perspective. If mis-attributed — what partial truth does the wrong attribution contain? If correctly attributed — what adjacent causes might contribute to a future recurrence even though the primary cause was identified?]
## Finding 2
...
The Attributed field: Attributed: yes means the team correctly identified the cause — the causal chain traces cleanly and removing the cause would have changed the outcome. Attributed: no means the attribution is wrong — the credited/blamed factor is not the actual cause, or is only a partial cause with significant invisible contributors.