better-thinking

Better Thinking

Classify an incoming task by its shape and stakes, and select which skills to deploy at what depth — the dispatcher that decides how much thinking machinery a task deserves.

Why

Applying full machinery to a trivial task wastes effort; applying none to a consequential one is negligent. A fast, explicit classification step routes effort proportionally before substantive work begins.

Use when / Don't use when

• Use when: at first contact with any nontrivial task — the entry point other skills dispatch from.
• Don't use when: never skip it; scale depth down instead — triage on a small task takes seconds.

Inputs → Outputs

• Inputs: an incoming task, question, or request.
• Outputs: a task classification (shape + stakes + reversibility) and a selected set of skills and depth.

Principles

• Classify by shape first — decision, diagnosis, research question, creative generation, communication, learning, negotiation, or a combination. Shape determines which skill family is even relevant.
• Classify by stakes and reversibility second. This determines depth, independent of shape.
• A task can be routine in domain but high-stakes in consequence — don't classify by surface topic or tone alone.
• Resolve vague or underspecified language before routing — routing a fuzzy restatement of the request just picks the wrong tool with more confidence.
• Re-triage if the task's real shape differs once underway; the initial classification is a hypothesis, not a commitment.

Procedure

1. Identify the task's shape: decision, diagnosis, research question, creative generation, communication, learning, negotiation, or a combination.
2. Identify stakes and reversibility — a gut check, or run [[reversibility-classification]] if unclear.
3. Check for a missing or ambiguous objective, success criteria, or binding constraint — vague verbs ("improve," "handle"), an unstated audience/format, an open scope boundary. If found: ask when guessing wrong would waste real work, otherwise state the inferred assumption and proceed. Skip when the request is already concrete.
4. Run python3 scripts/route.py "<task>" for a lexical top-8 shortlist. If it prints a stderr warning about zero/no signal, discard its output and rely on step 4b alone. 4b. Always — even when step 4 looks confident — skim every name+category+one_line in skills/INDEX.json for the task's shape, judging by concept, not shared words. Mandatory, not just a fallback: route.py is lexical and structurally blind to a same-concept, different-vocabulary match (e.g. "why does checkout conversion keep dropping" shares zero tokens with differential-diagnosis's own description, yet is a strong fit). Merge both lists, narrow by triggers, use disambiguates_from to break ties. Neither method is an oracle: verify picks, don't guess from memory.
5. Match candidates to depth: a quick, reversible decision needs a lightweight atomic; a high-stakes, hard-to-reverse one needs a full composite pipeline.
6. Note cross-cutting needs — most nontrivial tasks benefit from at least [[epistemic-tagging]] and [[bias-audit]] regardless of shape.
7. On a nontrivial task (multi-skill or non-obvious depth), open with a one-line **🧠 Classifying...** marker before proceeding — cheap signal that triage is happening, not a report in itself. Skip it on trivial/quick answers.
8. Proceed with the selected skills at the selected depth. Label each procedure step inline as you produce it, so the response body itself reads as visibly distinct from unstructured prose: bold the step's name tagged with its category emoji, e.g. **🎯 Framing:**, **🧩 Options:**, drawn from that step's own procedure line, not copied verbatim. Keep labels short and reserved for that role — don't bold anything else. Keep each block to 2–3 sentences, or a lead sentence plus a bulleted list for enumerable content; blank-line-separate every block. Use a GFM table when comparing 2+ items on 2+ shared dimensions. On 4+-step answers, an optional ### (not ##) header may group related steps. Skip inline labels on trivial/quick answers, like the bookend markers.
9. Re-triage explicitly if the actual shape turns out different mid-work — mark the pivot with **🔄 Re-triaging...** and say what changed, rather than adjusting silently. Report remaining ambiguity in shape or stakes as residual uncertainty.
10. Always close with a one-line footer, prefixed 🧠, naming the skill(s) applied — each tagged with its category emoji below — and the stakes/depth call, e.g. **🧠 Applied:** 🎯 premortem → 📐 red-teaming → 🎯 decision-analysis (high stakes, hard to reverse) or **🧠 Applied:** 🔍 fermi-estimation (low stakes, reversible). One line even for a single skill — the emoji mark it as a recognizable signature, not a badge to escalate.
11. On multi-skill or non-obvious-depth tasks only (the same bar as step 7), follow the Applied footer with one more line, **✨ Caught:**, naming the specific thing this task's structure surfaced that a fast, unstructured answer would have missed — a risk, an assumption, a wrong default, a hidden dependency. It must name the concrete finding from this exact task, not a generic claim like "a more thorough analysis" or "extra confidence." If nothing structure-dependent was actually surfaced (the process confirmed the obvious answer), omit the line rather than inventing one — a false "Caught" line is worse than none.