skills/thinking-debiasing/SKILL.md
In a long trajectory where you're defending a path you committed to early, run a quick self-check for sunk-cost and confirmation bias before continuing — only when evidence is being explained away.
npx skillsauth add tjboudreaux/cc-thinking-skills thinking-debiasingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Usually unnecessary. Current models already avoid the textbook cognitive biases on standard framings, so do not run this checklist by default — it adds friction without lift. It earns its keep in one narrow case: a long trajectory where you've committed to an approach early and are now rationalizing past it (sunk-cost) or only collecting evidence that confirms it (confirmation). For everything else, skip it.
Only use this skill when you notice one of these patterns in a long trajectory where you've committed to a path early:
| Pattern you notice | Self-check | |---|---| | "We've already built/spent a lot, so we should continue" | Sunk cost: Would I choose this path starting fresh today, ignoring work already done? If no, change course. | | You keep finding support for your current hypothesis and discounting counter-evidence | Confirmation: What single piece of evidence would prove me wrong? Have I actively looked for it? | | Unusually high confidence with thin evidence | Overconfidence: Widen the estimate; state what I'd expect to see if I'm wrong. |
If the check doesn't change the decision, you're done. Don't name biases without acting on them. For risk anticipation, use thinking-pre-mortem; for trade-off analysis, use thinking-opportunity-cost; for decision speed, use thinking-reversibility.
Based on Daniel Kahneman, Dan Lovallo, and Olivier Sibony's research on cognitive biases. The sections below are a fuller checklist; for an autonomous agent, treat them as a reference for the narrow case above, applied as self-checks (not as roles assigned to a team).
Before approving any significant recommendation, evaluate:
1. Is there self-interest at play?
2. Is there emotional attachment (affect heuristic)?
3. Did I genuinely explore alternatives, or anchor on the first one?
4. Did I anchor on the first framing of the problem?
5. Are we over-relying on a single analogy (saliency bias)?
6. Are we anchored on an initial number?
7. Were credible alternatives seriously considered?
8. Are we seeking confirming evidence only?
9. Is the base case realistic?
10. Is the worst case bad enough?
11. Are we discounting sunk costs appropriately?
12. Are we assuming success transfers?
# Decision Quality Audit: [Decision Name]
## Recommendation Summary
[Brief description]
## Bias Checklist
### Self-Interest & Emotion
- [ ] Self-interest checked: [Notes]
- [ ] Emotional attachment assessed: [Notes]
### Single-Path Lock-In
- [ ] Opposing position argued in good faith: [Notes]
- [ ] First framing/anchor questioned: [Notes]
### Pattern Recognition
- [ ] Multiple analogies considered: [Notes]
- [ ] Anchoring effects checked: [Notes]
### Confirmation Bias
- [ ] Alternatives genuinely evaluated: [Notes]
- [ ] Disconfirming evidence sought: [Notes]
### Planning Realism
- [ ] Base case reality-checked: [Notes]
- [ ] Worst case severe enough: [Notes]
- [ ] Sunk costs ignored: [Notes]
### Halo Effects
- [ ] Success transfer questioned: [Notes]
## Red Flags Identified
[List any concerns from checklist]
## Mitigations
[How will identified biases be addressed?]
## Decision
- [ ] Proceed as recommended
- [ ] Proceed with modifications
- [ ] Requires more analysis
- [ ] Reject recommendation
"We can be blind to the obvious, and we are also blind to our blindness."
You cannot debias through willpower alone. Use checklists, processes, and outside perspectives to catch what your intuition misses.
tools
About to add a feature/layer/process to fix a problem. First ask what to remove instead — subtraction is often more robust than addition. Use for simplification and complexity reduction.
development
Use when stuck between two architecture or API requirements that seem mutually exclusive — name the contradiction precisely, then separate the conflicting states in time, space, or condition.
testing
You need to trace how a system would fail or behave at a scale you can't cheaply test or measure. Use to imagine the scenario and walk the consequence chain step by step.
devops
Use when optimizing latency or throughput in a pipeline and one stage dominates—focus all effort on that single bottleneck, since speeding up the others changes nothing until it's fixed.