Use when an answer arrives too fast on a high-stakes or unfamiliar task. Force one explicit verification pass before committing instead of shipping the first plausible answer.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-dual-process
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when an answer arrives too fast on a high-stakes or unfamiliar task. Force one explicit verification pass before committing instead of shipping the first plausible answer.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-dual-process.SKILL.md
---name: thinking-dual-process
description: Use when an answer arrives too fast on a high-stakes or unfamiliar task. Force one explicit verification pass before committing instead of shipping the first plausible answer.
---# Dual-Process Thinking
## Overview
A language model produces a first answer by fast pattern-completion: the most statistically likely continuation given the prompt. That fast path is excellent for routine, well-trodden tasks and dangerous for high-stakes or unfamiliar ones, where the most *plausible-sounding* answer and the *correct* answer diverge. This skill is the deliberate counterweight: when an answer arrives too easily on a task that matters, force one explicit verification pass before committing.
The framing comes from Kahneman's fast/slow distinction, but the operative idea here is mechanical, not psychological: **fast generation** (the immediate completion) vs. a **deliberate check** (re-deriving, testing, or sourcing the answer).
**Core Principle:** Fluency is not correctness. When the answer came easily *and* the cost of being wrong is high, that combination is the trigger to slow down and verify — not a signal you're done.
## Trigger Card
When an answer arrives instantly on a high-stakes or unfamiliar task, run one verification pass before committing:
1. **Notice:** Did the answer form immediately, with no intermediate steps? High confidence but nothing checked?
2. **Check triggers:** Is the task high-stakes/irreversible OR the domain unfamiliar? If neither, ship the fast answer.
3. **Verify:** Re-state the claim → re-derive or test it a second, independent way → check against ground truth (code, docs, data) → reconcile any disagreement → commit.
The trigger is **easy answer + real cost of error.** If the answer was hard-won, you already deliberated. If the task is trivial and reversible, don't over-verify.
## When to Use
- The task is high-stakes or irreversible (data migration, security, deletion, public commitment) and the answer felt obvious.
- The domain is unfamiliar or the task is novel — no well-worn pattern to rely on.
- The answer requires statistical or quantitative reasoning (where fast completion is reliably miscalibrated).
- You're reviewing work and it "looks fine" on a quick pass.
- A claim is plausible and convenient but you haven't actually checked it against the code/docs/data.
Decision flow:
```
Answer arrived fast? → High stakes OR unfamiliar? → yes → RUN A VERIFICATION PASS
↘ no → fast answer is fine, ship it
↘ no (had to work for it) → you already deliberated
```
## When NOT to Use
- **Routine, reversible, low-stakes tasks.** Renaming a variable, a trivial edit, an obvious lookup — re-verifying everything is wasted budget and invites analysis paralysis.
- **You already worked through it deliberately.** If the answer was hard-won, a second pass is redundant; the trigger is *easy answer + high stakes*, not every answer.
- **The verification pass would cost more than the error it prevents.** Match the depth of the check to the cost of being wrong.
- **You can just run it.** If a test or a quick execution would settle it, do that instead of more reasoning.
## The Two Modes
### Fast generation (the default)
| Characteristic | Description |
|----------------|-------------|
| **Speed** | Immediate — the answer is just the first plausible completion |
| **Basis** | Pattern-matching to similar prompts seen in training |
| **Confidence** | Often high *regardless* of correctness — fluency masquerades as certainty |
Fast generation is reliable for:
- Well-trodden, conventional tasks with a clear standard answer
- Reformatting, summarizing, and other low-ambiguity transforms
- Recall of common, stable facts
- Routine code in a familiar language/framework
Fast generation is unreliable for:
- Arithmetic and multi-step quantitative reasoning
- Statistical reasoning and base-rate problems
- Novel or unfamiliar problems with no template to match
- Anything where a plausible-sounding answer can be subtly wrong (APIs, version-specific behavior, edge cases)
### Deliberate verification (the override)
| Characteristic | Description |
|----------------|-------------|
| **Speed** | Slower — re-derive, test, or source the answer |
| **Basis** | Explicit steps, checks against ground truth |
| **Confidence** | Earned — tied to what was actually verified |
Deliberate verification is worth its cost when:
- Re-deriving a result a second, independent way
- Running or tracing the code instead of predicting its output
- Checking a claim against the actual file/doc/data rather than memory
- Enumerating edge cases the fast answer glossed over
Its only failure mode is over-use: applying it to trivial, reversible work where the check costs more than the error.
## The Process
### Step 1: Notice the fast answer
A fast answer announces itself: it's the response forming immediately, before any explicit work. That's normal and usually fine. The thing to notice is *how* you got it.
- Answer formed immediately, no intermediate steps
- It "obviously" follows from the prompt
- Confidence is high but nothing was actually checked
```
Example: "Does this regex match leading zeros?"
A confident yes/no forms instantly → fast generation.
Before answering: is this high-stakes or am I sure? If either is shaky, test the regex.
```
### Step 2: Check the two trigger conditions
A verification pass is warranted only when BOTH are true enough:
**The answer came easily** (Step 1), AND **the cost of being wrong is real:**
- Stakes are high or the action is irreversible
- The domain is unfamiliar or the problem novel
- It requires arithmetic / statistical reasoning
- A wrong-but-plausible answer would slip through review
If the answer was hard-won, you already deliberated — stop. If stakes are trivial and reversible, the fast answer is fine — stop.
### Step 3: Run the verification pass
When both conditions hold, do exactly one disciplined check:
```
1. RE-STATE - Write the claim/answer explicitly
2. RE-DERIVE - Reach it a second, independent way (or test/run it)
3. CHECK - Against ground truth: the code, the docs, the data, the math
4. RECONCILE - If the two paths disagree, the fast answer was wrong — find out why
5. COMMIT - Ship the verified answer
```
Watch for these fast-answer red flags specifically:
- It's the most common/canonical answer but the prompt has an unusual twist
- It depends on a version, config, or edge case you didn't actually confirm
- It's the convenient answer that lets you stop early
- It restates the user's assumption back to them without testing it
| Fast answer + high stakes | Run the verification pass above |
| Already deliberated | Done — no second pass needed |
## Fast-Generation Failure Modes
### Question substitution
Fast generation answers an easier nearby question instead of the one asked:
```
Asked: "Is this O(n) or O(n log n)?"
Answered: "Does this look like efficient code?" (vibe, not analysis)
Asked: "Does this migration preserve all rows?"
Answered: "Does this migration look correct?" (plausibility, not verification)
```
The fix is to re-state the *exact* question (Step 3) so the substitution becomes visible.
### Pattern-matched errors
| Pattern | What it does | When it fails |
|-----------|--------------|---------------|
| Canonical-answer pull | Returns the textbook answer | The prompt has a non-standard twist |
| Base-rate neglect | Reasons from the salient detail | Ignores how common the outcome actually is |
| Anchoring | Builds on a number in the prompt | The anchor was arbitrary or wrong |
| Confirmation | Surfaces support for the framing given | Misses evidence the framing is wrong |
| Sycophantic agreement | Echoes the user's stated assumption | The assumption was the bug |
### WYSIATI (What You See Is All There Is)
Fast generation builds the most coherent answer from *only* what's in the prompt, and does not flag what's missing:
```
Given: "the function returns the user"
Concludes: "so the happy path works"
Missing: the 404 path, the timeout, the null case — none mentioned, so none considered
```
Coherence of the answer is not coverage of the territory. Explicitly ask "what would I need to look at that isn't in front of me?"
## Fluency Is Not Correctness
A smooth, confident, well-formatted answer *feels* more trustworthy — to the reader and in the generation itself. That fluency signal is independent of whether the answer is right.
| Fluent answer | Verified answer |
|---|---|
| Reads cleanly, high apparent confidence | Confidence tied to a specific check that passed |
| Risk: accepted without scrutiny | Risk: only over-use on trivial tasks |
**The trap:** the more polished the fast answer, the *less* it gets challenged — exactly backwards from what stakes should dictate. On a high-stakes task, treat a too-clean answer as a reason to run the verification pass, not a reason to ship.
## Application Examples
### Code Review
```
Fast answer: "This looks fine" (matches familiar-looking code)
Verification pass (high-stakes change):
- Trace the actual logic line by line, don't pattern-match the shape
- Enumerate the edge/error paths the diff doesn't mention
- Check the change against the contract it must uphold (callers, tests)
```
### Reporting a Fact or API Behavior
```
Fast answer: "Use method X, it takes these args" (canonical recall)
Verification pass (unfamiliar/version-sensitive):
- Confirm the method exists in the version in this repo
- Check the signature in the actual source/docs, not from memory
- If unsure, say so or look it up rather than assert
```
### Architecture / Tech Choice
```
Fast answer: "Use [the obvious default]" (most-common completion)
Verification pass (high-stakes):
- State the actual requirements, then check the default against them
- Name one alternative and why it loses, so the choice is reasoned not reflexive
```
### Debugging
```
Fast answer: "It's probably X" (first plausible hypothesis)
Verification pass:
- List the candidate causes, not just the first
- Find the evidence that would distinguish them, and look at it
- Resist committing to X until the logs/repro actually point there
```
## Integration with Other Thinking Skills
### With Debiasing
Fast generation is where most bias-shaped errors enter; the verification pass is where you catch them. Run the debiasing checklist as the content of Step 3 on high-stakes calls.
### With Bayesian Reasoning
Fast answers neglect base rates; the verification pass restores them:
```
Fast: "Positive test result = probably has the condition"
Verified: state the base rate first, then update (see thinking-bayesian)
```
### With First Principles
The fast answer reasons by analogy ("everyone does X"); the verification pass asks whether the constraint is real:
```
Fast: "Competitors do X, so we should too"
Verified: "What's the fundamental requirement? Does X actually meet it?"
```
### With Pre-Mortem
The fast answer is optimistic by default; the verification pass adds the failure view:
```
Fast: "This plan will work"
Verified: "Assume it failed — what's the most likely reason?"
```
### With OODA Loop
Under genuine time pressure (an incident), act on the fast answer at ~70% confidence and re-observe — don't stall on verification. Reserve the full pass for after, or for the irreversible step within the incident.
## When the Fast Answer Is Trustworthy
The fast path is not the enemy — it's correct most of the time, and over-verifying is its own failure. Lean on the fast answer when:
1. **The task is conventional** — a standard transform or a common, stable fact
2. **The pattern fits cleanly** — no unusual twist in the prompt
3. **It's cheaply reversible** — a wrong answer is caught and fixed at near-zero cost
4. **You can confirm it trivially if challenged** — the check is one step away
```
Fine to ship fast:
- "Convert this JSON to YAML"
- "What HTTP status means 'not found'?"
- A rename or a comment fix
Verify first:
- "Will this SQL touch every shard?"
- "Is this auth check actually enforced on the server?"
- Anything version-, edge-case-, or money-sensitive
```
Ask: "If this is wrong, how and when do I find out — and how much does it cost?"
## Verification Checklist
- [ ] Noticed whether the answer arrived fast or was worked through
- [ ] Checked BOTH triggers: easy answer AND real cost of error
- [ ] If both true, ran one disciplined verification pass against ground truth
- [ ] Re-derived or tested the result a second, independent way
- [ ] Did NOT over-verify a trivial, reversible task
- [ ] Confirmed version/edge-case-sensitive claims rather than asserting from memory
- [ ] Matched the depth of the check to the cost of being wrong
## Key Questions
- "Did this answer come too easily — and does that matter here?"
- "Is this a conventional task or one with an unusual twist?"
- "What would a second, independent derivation show?"
- "Is my confidence tied to an actual check, or just to how clean the answer reads?"
- "What's missing that isn't in front of me (WYSIATI)?"
- "If this is wrong, how and when do I find out?"
## The Core Warning
A fluent, confident answer reflects the coherence of the completion, not the quality of the evidence behind it. The most polished answers get challenged the least — which is exactly backwards when the stakes are high. When an answer comes easily on something that matters, that ease is the trigger to verify, not the signal you're done.
