From thinking-frameworks-skills
Guides designing heuristics for fast decisions and checklists for error prevention. Use when making decisions under time pressure, preventing errors in complex procedures, or when users mention cognitive biases or satisficing.
How this skill is triggered — by the user, by Claude, or both
Slash command
/thinking-frameworks-skills:heuristics-and-checklistsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
- [Workflow](#workflow)
Copy this checklist and track your progress:
Heuristics & Checklists Progress:
- [ ] Step 1: Identify decision or procedure
- [ ] Step 2: Choose approach (heuristic vs. checklist)
- [ ] Step 3: Design heuristic or checklist
- [ ] Step 4: Test and validate
- [ ] Step 5: Apply and monitor
- [ ] Step 6: Refine based on outcomes
Step 1: Identify decision or procedure
What decision or procedure needs simplification? Is it repetitive? Time-sensitive? Error-prone? See resources/template.md.
Step 2: Choose approach (heuristic vs. checklist)
Heuristic for decisions (choose option). Checklist for procedures (sequence of steps). See resources/methodology.md.
Step 3: Design heuristic or checklist
Heuristic: Define simple rule (recognition, take-the-best, satisficing threshold). Checklist: List critical steps, add READ-DO or DO-CONFIRM format. See resources/template.md and resources/template.md.
Step 4: Test and validate
Pilot test with sample cases. Check: Does heuristic produce good enough decisions? Does checklist catch errors? See resources/methodology.md.
Step 5: Apply and monitor
Use in real scenarios. Track outcomes: decision quality, error rate, time saved. See resources/template.md.
Step 6: Refine based on outcomes
Adjust rules based on data. If heuristic fails in specific contexts, add exception. If checklist too long, prioritize critical items. See resources/methodology.md.
Validate using resources/evaluators/rubric_heuristics_and_checklists.json. Minimum standard: Average score ≥ 3.5.
Pattern 1: Recognition Heuristic
Pattern 2: Take-the-Best Heuristic
Pattern 3: Satisficing (Good Enough Threshold)
Pattern 4: Aviation Checklist (DO-CONFIRM)
Pattern 5: Surgical Checklist (READ-DO)
Pattern 6: Fast & Frugal Decision Tree
Key requirements:
Know when heuristics work vs. fail: Heuristics excel in stable, familiar environments with time pressure. They fail in novel, deceptive contexts (adversarial, misleading information). Don't use recognition heuristic when advertising creates false signals.
Satisficing ≠ low standards: "Good enough" threshold must be calibrated. Set based on cost of continued search vs. value of better option. Too low → poor decisions. Too high → analysis paralysis.
Checklists for critical steps only: Don't list every trivial action. Focus on steps that (1) are skipped often, (2) have serious consequences if missed, (3) not immediately obvious. Short checklists used > long checklists ignored.
READ-DO for novices, DO-CONFIRM for experts: Match format to user expertise. Forcing experts into READ-DO creates resistance and abandonment. Let experts flow, confirm after.
Test heuristics empirically: Don't assume rule works. Test on historical cases. Compare heuristic decisions to optimal decisions. If accuracy <80%, refine or abandon.
Bias awareness is not bias elimination: Knowing availability bias exists doesn't prevent it. Heuristics are unconscious. Need external checks (checklists, peer review, base rates) to counteract biases.
Update heuristics when environment changes: Rules optimized for past may fail in new context. Market shifts, technology changes, competitor strategies evolve. Re-validate quarterly.
Forcing functions beat reminders: "Don't forget X" fails. "Can't proceed until X done" works. Build constraints (e.g., deployment script requires all tests pass) rather than relying on memory.
Common pitfalls:
Common heuristics:
| Heuristic | Rule | Example | Best For |
|---|---|---|---|
| Recognition | Choose what you recognize | Detroit > Milwaukee (size) | Stable correlations between recognition and quality |
| Take-the-best | Use single most important criterion | Hire based on track record alone | One dominant factor predicts outcome |
| Satisficing | First option meeting threshold | Candidate meets 80% requirements → hire | Time pressure, search costs high |
| Availability | Judge frequency by ease of recall | Plane crashes seem common (vivid) | Recent, vivid events (WARNING: bias) |
| Representativeness | Judge by similarity to prototype | "Looks like successful startup founder" | Stereotypes exist (WARNING: bias) |
| Anchoring | Adjust from initial value | First price shapes negotiation | Numerical estimates (WARNING: bias) |
Checklist formats:
| Format | When to Use | Process | Example |
|---|---|---|---|
| READ-DO | Novices, unfamiliar, high-stakes | Read step → Do step → Repeat | Surgery (WHO checklist) |
| DO-CONFIRM | Experts, routine, familiar | Do from memory → Confirm with checklist | Aviation pre-flight |
| Challenge-Response | Two-person verification | One reads, other confirms | Nuclear launch procedures |
Checklist design principles:
When to use heuristics vs. checklists:
| Decision Type | Use Heuristic | Use Checklist |
|---|---|---|
| Choose between options | ✓ Recognition, take-the-best, satisficing | ✗ Not applicable |
| Sequential procedure | ✗ Not applicable | ✓ Pre-flight, deployment, surgery |
| Complex multi-step | ✗ Too simplified | ✓ Ensures nothing skipped |
| Routine decision | ✓ Fast rule (satisficing) | ✗ Overkill |
| Error-prone procedure | ✗ Doesn't prevent errors | ✓ Catches mistakes |
Cognitive biases (when heuristics fail):
| Bias | Heuristic | Failure Mode | Mitigation |
|---|---|---|---|
| Availability | Recent/vivid events judged as frequent | Overestimate plane crashes (vivid), underestimate heart disease | Use base rates, statistical data |
| Representativeness | Judge by stereotype similarity | "Looks like successful founder" ignores base rate of success | Check against actual base rates |
| Anchoring | First number shapes estimate | Initial salary offer anchors negotiation | Set own anchor first, adjust deliberately |
| Confirmation | Seek supporting evidence | Only notice confirming data | Actively seek disconfirming evidence |
| Sunk cost | Continue due to past investment | "Already spent $100k, can't stop now" | Evaluate based on future value only |
Inputs required:
Outputs produced:
heuristic-rule.md: Defined heuristic with conditions and exceptionschecklist.md: Structured checklist with critical stepsvalidation-results.md: Test results on historical casesrefinement-log.md: Iterations based on real-world performancenpx claudepluginhub lyndonkl/claude --plugin thinking-frameworks-skillsRoutes decision-making requests to the appropriate structured thinking tool: option-mapping, criteria-weighting, premortem-analysis, or reversibility-analysis.
Applies structured reasoning to complex coding problems using 19 analytical frameworks, 12 bias detectors, 10 decomposition methods, 10 mental models, Cynefin classification, ethical checks, and communication patterns.
Routes coding, architecture, product, and strategy problems to the right mental model (e.g. 5 Whys, Systems Thinking, Theory of Constraints). Use when unsure which framework fits.