메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
Start with means, not goals; co-create with partners; leverage contingencies. Use for startup strategy, innovation projects, and uncertain/novel domains where planning is unreliable.
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true.
Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
| 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. |
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.
When an answer arrives instantly on a high-stakes or unfamiliar task, run one verification pass before committing:
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.
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
| 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:
Fast generation is unreliable for:
| 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:
Its only failure mode is over-use: applying it to trivial, reversible work where the check costs more than the error.
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.
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.
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:
If the answer was hard-won, you already deliberated — stop. If stakes are trivial and reversible, the fast answer is fine — stop.
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:
| 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 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 | 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 |
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?"
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.
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)
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
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
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
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.
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)
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?"
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?"
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.
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:
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?"
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.