thinking-dual-process

What this skill does

# 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

### Step 4: Match effort to stakes

| Situation | Process |
|--------|---------|
| Fast answer + low stakes | Ship it; don't manufacture doubt |
| 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"