skills/kahneman-klein-expertise/SKILL.md
Integration of Kahneman's heuristics research with Klein's expertise studies on intuitive decision-making
npx skillsauth add curiositech/windags-skills kahneman-klein-expertiseInstall 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.
license: Apache-2.0
name: kahneman-klein-expertise
version: 1.0
description: >
A unified framework for diagnosing when intuitive or expert judgment can be
trusted versus when it produces confident noise — and how to architect
decision systems accordingly. Based on Kahneman & Klein's synthesis of
Naturalistic Decision Making and Heuristics & Biases traditions.
activation_triggers:
- questions about when to trust agent confidence scores or outputs
- designing orchestration logic for multi-agent systems
- evaluating whether a domain warrants algorithmic vs. judgment-based approaches
- debugging overconfident agent behavior in low-signal environments
- task decomposition architecture decisions
- building feedback loops for agent learning and validation
- assessing whether expertise claimed by a system or human is genuine
- calibration, uncertainty quantification, or epistemic humility requirements
- post-mortem or pre-mortem failure analysis of agent decisions
Load this skill when facing questions like:
This skill is not needed for pure implementation tasks with clear right answers, standard debugging of code syntax, or well-specified problems with deterministic solutions.
Simon's definition: "The situation has provided a cue; this cue has given the expert access to information stored in memory, and the information provides the answer."
Intuition is compressed pattern matching across many prior encounters — the same process as recognizing a familiar face, scaled to thousands of domain-specific examples. This means:
Practical implication: When an agent produces a fluent, coherent output, ask what cues triggered this pattern match — not how confident does this feel.
Both must be present for expertise to be real:
| Condition | What it means | What happens when absent | |-----------|---------------|--------------------------| | Environment Validity | Domain contains stable, learnable regularities — cues reliably predict outcomes | Practice produces confident noise, not skill | | Learning Opportunity | Adequate feedback loops: timely, accurate, uncorrupted | No skill develops even in high-validity domains |
This is the master diagnostic. Before trusting any expert judgment (human or agent), classify the environment first.
Valid environments: Chess, fire behavior, medical diagnosis from imaging, mechanical fault detection
Low-validity environments: Long-term political forecasting, stock selection, many "soft" predictions about complex social systems
This is the most operationally dangerous finding in the paper.
Subjective confidence tracks how coherent the available information feels — not whether the judgment is correct. A compelling, internally consistent answer from an agent (or human expert) can be precisely wrong, with no internal marker distinguishing the correct intuition from the heuristic-generated error.
Corollary: Systems that use their own confidence scores to gate output quality are replicating this exact failure mode. High confidence in a low-validity environment is a warning sign, not reassurance.
Genuine skill in one sub-task does not transfer to structurally adjacent sub-tasks. A professional skilled at evaluating commercial prospects of firms (valid, trackable, feedback-rich) has no demonstrated skill at predicting whether a stock is underpriced (low-validity, confounded feedback).
For agent systems: Invoking a skill for a task adjacent but structurally different from the task that built the skill replicates this fractionation error at scale. The agent has no internal alarm for this boundary crossing — the patterns feel similar.
Key question: Does this agent's training distribution actually include this specific task structure — or just tasks that feel similar?
| Environment | Best approach | |-------------|--------------| | High-validity, rich tacit cues, pattern-rich | Expert judgment / trained pattern recognizer | | Low-validity, noisy, sparse feedback history | Algorithm / ensemble / structured rule | | Medium-validity, time pressure, incomplete info | RPD model (recognize → simulate → validate) | | Unknown validity | Default to algorithmic with human review |
Algorithms outperform humans specifically in low-validity noisy environments. Humans (and trained agents) outperform algorithms specifically when tacit cues exist that formal models cannot capture. Neither is universally superior.
Is the domain one where regularities exist AND feedback is available?
├── YES → High-validity environment
│ └── Expert judgment / pattern recognition appropriate
│ └── Load: references/validity-environment-and-agent-trust.md
├── PARTIAL → Degraded-validity environment
│ └── Hybrid: algorithm for base rate, judgment for anomaly detection
│ └── Suppress raw confidence scores; require justification
└── NO → Low-validity environment
└── Algorithm or structured ensemble; suppress confidence signals
└── Load: references/overconfidence-and-the-illusion-of-validity.md
IF environment is low-validity AND outcomes are high-stakes
→ Use actuarial/algorithmic approach; resist "clinical override"
IF environment has tacit cues that resist formalization (e.g., expert detects
something "off" with no articulable reason)
→ Trust expert anomaly detection; investigate before proceeding
IF expert confidence is HIGH but feedback loops are known to be corrupted
→ Treat confidence as contraindicated; flag for review
IF the task is adjacent to a high-skill domain but structurally different
→ Apply fractionation check; do not inherit confidence from adjacent domain
→ Load references/algorithms-vs-intuition-routing-framework.md for full matrix
Before trusting a confident output:
1. What environment type is this? (validity classification)
2. What cues triggered this confidence? (articulable or tacit?)
3. Are feedback loops for this domain known to be clean?
4. Is this task within the demonstrated competence boundary?
5. Does confidence feel driven by coherence or by evidence?
IF any answer is unfavorable → downgrade trust; require validation
→ Load references/overconfidence-and-the-illusion-of-validity.md
IF the task structure is novel relative to training distribution
→ Flag; do not proceed with full autonomy
IF the agent cannot articulate the cues driving its judgment
AND the environment is not demonstrably high-validity
→ Escalate or apply System 2 validation
IF the agent has been consistently right in similar contexts
→ Check for automation bias in human supervisors; do not suppress oversight
→ Load references/the-boundary-problem-knowing-when-not-to-trust-yourself.md
When environment is medium-validity and time pressure is real:
1. RECOGNIZE: Does this situation match a known pattern?
└── NO → Slow down; do not simulate; gather more information
└── YES → Proceed to step 2
2. SIMULATE: Run mental simulation of the recognized action
└── Does it work? → Execute
└── Problem detected? → Modify and re-simulate (not: search for optimal)
└── Cannot resolve? → Escalate or switch to deliberate analysis
Key: Satisficing (first workable option) is correct when delay cost > marginal
optimization benefit. Optimizing when satisficing is warranted wastes
resources and can introduce second-guessing errors.
→ Load references/recognition-primed-decision-making-for-agents.md
| File | Description | Load when... |
|------|-------------|--------------|
| references/validity-environment-and-agent-trust.md | Environment validity as the master variable — how to classify domains and what confidence levels are warranted | Classifying a new domain; deciding baseline trust for agent outputs |
| references/recognition-primed-decision-making-for-agents.md | The RPD model: how skilled agents make decisions without comparing options; satisficing vs. optimizing | Designing decision logic for time-pressured or medium-validity contexts |
| references/fractured-expertise-and-domain-boundary-detection.md | Why competence in one sub-task doesn't transfer; how to detect fractionation errors in agent skill invocation | Decomposing tasks; evaluating whether a skill applies to an adjacent task |
| references/algorithms-vs-intuition-routing-framework.md | Full routing matrix for when to use algorithmic vs. judgment-based approaches; the Meehl findings | Building orchestrator routing logic; deciding between structured and flexible approaches |
| references/system1-system2-and-dual-mode-agent-architecture.md | Dual-process architecture: fast pattern matching vs. slow deliberate reasoning; when to switch modes | Architecting agent reasoning pipelines; debugging speed/accuracy tradeoffs |
| references/overconfidence-and-the-illusion-of-validity.md | Why confidence and accuracy diverge; the internal consistency trap; how to detect and correct | Any context where high-confidence outputs need scrutiny; calibration work |
| references/learning-from-tacit-knowledge-and-cognitive-task-analysis.md | How to elicit and encode expert knowledge that cannot be articulated; cognitive task analysis methods | Building training data from expert behavior; capturing judgment that resists specification |
| references/the-boundary-problem-knowing-when-not-to-trust-yourself.md | How intelligent systems should recognize their own competence limits; asymmetry between overreach and underreach | Designing escalation logic; building self-monitoring into agents |
| references/environment-types-and-decision-quality-reference.md | Quick-reference card synthesizing environment typology and decision quality implications | Fast lookup during system design or review; summary card for the full framework |
These are the specific errors Kahneman and Klein document — and the ones most likely to recur in agent systems:
1. Trusting confidence as accuracy
Using an agent's (or model's) expressed confidence as a proxy for correctness. Confidence measures internal coherence, not validity. High confidence in low-validity domains is the failure mode, not the exception.
2. Wicked learning environments
Designing (or tolerating) feedback loops that are delayed, corrupted, or systematically misleading. This is worse than having no feedback — it produces confident, systematic errors rather than random ones. Auditing feedback loops is not optional.
3. Fractionation by proximity
Invoking a skill for a task because it feels similar to tasks the skill was built on, without checking whether the underlying task structure is actually the same. Financial analysis ≠ stock prediction. Code review ≠ architecture evaluation.
4. Automation bias in oversight
Human supervisors (or orchestrating agents) disengaging from review because the agent is usually right. The cases where usually-right agents fail are precisely the novel, high-stakes cases that most need oversight. Reliability breeds misplaced trust.
5. The clinical override trap
Experts (or agents) overriding algorithmic outputs in low-validity domains based on "judgment." In environments where algorithms reliably outperform humans, the override degrades performance — regardless of how compelling the expert's reasoning feels.
6. Treating expertise as global
Assuming that an agent or expert who is excellent at Task A has commensurate skill at adjacent Task B. Expertise is domain-specific down to the sub-task level. Prestige and track record in one area do not transfer.
7. Skipping environment classification
Jumping directly to "should I trust this output?" without first asking "what kind of environment is this?" Environment type determines what trust is even possible — everything else is downstream of this.
How to tell if someone has actually internalized this framework vs. just read the summary:
They get it if they say things like:
They're still at the summary level if they say things like:
The deepest tell: Someone who has internalized this framework treats environment classification as a prerequisite to any confidence assessment — not as an afterthought. They ask "what kind of domain is this?" before "is this output right?" The question of mechanism (algorithm vs. judgment) is always downstream of the question of ecology (what kind of environment are we in?).
Load references/environment-types-and-decision-quality-reference.md as a quick-reference companion to this skill for most practical applications.
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.