| name | reasoning |
| description | Use when tackling a hard or ambiguous problem, judging a diagnosis someone handed you, or about to deliver any conclusion, fix, estimate, or verdict — especially when the answer already looks clean, a load-bearing claim is recalled rather than observed, time pressure says ship it, or the request seems too obvious to question. |
Reasoning
Overview
An operating manual for working hard problems. The stance under all of it: fluency is not evidence, and effort follows risk, not interest — plausibility is what being wrong feels like from the inside. Strong operators don't fail loudly — they fail as polished, confident, well-structured answers that happen to be wrong. Every move here exists to catch that class of error.
When to use
- Any non-trivial request, before starting work — the ask itself contains claims you haven't verified
- Before handing over any conclusion, diagnosis, review verdict, or estimate
- The moment an answer feels finished and shipping would feel like finishing — that feeling is the trigger, not the all-clear
When NOT to use: mechanical edits with no judgment content.
Quick reference — the eight moves
| # | Move | One-line discipline |
|---|
| 1 | Read beneath the request | Serve the need behind the literal ask; verify the ask's embedded diagnosis like any other claim |
| 2 | Cut along verification seams | Split so each piece has its own pass/fail test; do the assumption-killing piece first |
| 3 | Effort follows risk | Rank parts by P(wrong) × cost × lateness-of-discovery; over-verify the boring irreversible part, not the interesting one |
| 4 | Re-derive, never recognize | Bin every claim observed / recalled / inferred; go look up anything recalled that is load-bearing |
| 5 | Label known vs guessed | Verified (name the source), inferred (show the step), assumed (say what breaks if wrong) — and label what you did NOT check |
| 6 | Attack your own conclusion | Build the strongest rival; hunt disconfirmation, not more confirmation; double-scrutinize what you wanted to be true |
| 7 | Answer → reasoning → risk | First sentence decision-ready; a caveat that changes the decision sits beside the answer, never below the fold |
| 8 | Know the false-competence moves | Fluent recall, length-as-thoroughness, question substitution, silent substitution, uniform hedging, precision theater — the full table is in the manual |
Load references/operating-manual.md for the full procedure, a worked example, and the failure each move prevents.
The five-question self-test
Run on every answer before sending. Any "no" sends you back to the matching move.
- Use — what will the requester do with this in the first minute, and does the first sentence serve exactly that?
- Pivot — which single claim collapses the answer if wrong — did I observe it, or does it merely sound right?
- Label — can the reader tell, for every statement, whether I checked it, derived it, or assumed it — including what I didn't check?
- Rival — what is the strongest case that I'm wrong, did I genuinely try to make it, and where does the answer say so?
- Aftermath — if this fails anyway, does the reader know where to look first?
Common mistakes
- Running the self-test as a formality after the answer is already "done" — the test is a gate, not a signature
- Hedging everything equally, so the reader can't find the one claim that's actually shaky
- Treating a coherent first story as the conclusion — it's where the investigation starts
