Thinking Model Router

Model Router

Core rule: Prefer NONE or one primary skill. Route by mechanism fit, not habit. Combine only when roles are distinct and necessary.

When to Use

• The right thinking skill is unclear and you would otherwise guess or stack tools.
• Several catalog skills seem plausible and you need a single primary (or explicit NONE).
• High-stakes work where a wrong frame is costly and a quick domain×type match helps.

When NOT to Use

• The match is already known or obvious ("where's the bottleneck?" → theory-of-constraints) — invoke that skill directly; do not route for show.
• The task is routine implementation with no analytical unknown — reason directly (NONE).
• You are mid-execution of an agreed plan and only need the next concrete step.
• The ask is outside this catalog (pure coding syntax, tool ops with no judgment call) — NONE.

Invoking a Model (Skill IDs)

The router outputs bare slugs (e.g. id: five-whys-plus). Invoke a routed skill with the Skill tool using the exact ID thinking-skills:thinking-<slug> — never invent a slug not cited in Procedure. NONE means no invocation.

Procedure

• Short-circuit. If one skill clearly fits by mechanism, return that skill alone. If no skill clearly improves the work, return NONE and reason directly. Stop.
• Characterize. Record domain (coding, architecture, product, strategy, personal, abstract, risk, innovation) and problem type (diagnose, decide, understand, create, evaluate, predict, optimize). Note constraints: time, information, stakes, reversibility, complexity.
• Candidate by type defaults (override when constraints demand). Keep only active catalog skills:
• Diagnose → five-whys-plus or scientific-method (kepner-tregoe if IS/IS-NOT matrix needed)
• Decide → reversibility first; then opportunity-cost or probabilistic
• Understand → systems (map-territory if model-vs-reality gap; cynefin if approach domain unclear)
• Create → first-principles (triz for contradictions; effectuation for means-driven; via-negativa for remove-first)
• Evaluate → steel-manning (socratic if assumptions/definitions are the unknown)
• Predict → probabilistic
• Optimize → theory-of-constraints (ooda under time pressure; bounded-rationality for search stop)
• Risk / "what fails?" → pre-mortem or red-team; margin-of-safety for buffers
• Product "what to build?" → jobs-to-be-done
• Competence / durability → circle-of-competence, lindy-effect
• Controlled hypothetical → thought-experiment
• Multi-lens only after one primary fails a blind-spot check → model-combination
• Select with criteria (satisficing). Score only if 2+ candidates remain or stakes make a forced default unsafe. Rate each criterion 1–5 (1 = absent/wrong fit; 3 = usable with gaps; 5 = direct fit): problem fit (30%), available inputs (20%), time to apply (15%), stakeholder usability (15%), competence to apply correctly (20%). A route must score problem fit ≥4 and weighted total ≥3.5; otherwise return NONE. For totals within 0.25, prefer fewer inputs and shorter execution; if still tied, choose NONE unless the skills answer distinct complementary questions.
• Multi-skill only as exception. Add a second or third skill only when each has a distinct complementary role the primary leaves open. Cap at three. Prefer sequential over parallel. Near-neighbors and synonyms do not stack. For composition patterns, hand off to model-combination after naming the primary.
• Exit. State abandon signals (forced fit, ignored factors, no insight ~15 minutes). On mismatch, re-route once or fall back to NONE — never force a frame.

Domain cheat-map (primary first; still default to one or NONE):

| Domain signal | Prefer |

|---------------|--------|

| Bug / root cause / flaky | five-whys-plus, scientific-method, systems |

| Architecture / tech choice | reversibility, systems, lindy-effect, opportunity-cost |

| Feature / roadmap / engagement | jobs-to-be-done, opportunity-cost, theory-of-constraints |

| Strategy / competition / growth | cynefin, systems, red-team, second-order |

| Personal / career commitment | opportunity-cost, reversibility, circle-of-competence, pre-mortem |

| Argument / belief update | steel-manning, probabilistic, socratic, first-principles |

| Security / disaster / ruin | pre-mortem, red-team, margin-of-safety, via-negativa |

| Innovation / contradiction / simplify | first-principles, triz, effectuation, via-negativa |

Output

outcome: NONE | one | multi
routes:
  - id: <primary skill id or NONE>
    role: <job this skill performs>
    unique_question: <question only this route answers>
  - id: <secondary skill id, only for multi>
    role: <distinct complementary job>
    unique_question: <distinct open question>
  - id: <tertiary skill id, only for multi>
    role: <distinct complementary job>
    unique_question: <distinct open question>
domain: <domain>
problem_type: <type>
constraints: <time/info/stakes/reversibility>
rationale: <mechanism fit in one sentence>
blind_spots: <what primary still ignores, if any>
exit: <when to abandon or re-route>

Default fill: outcome: NONE with one id: NONE route, or outcome: one with one route. Use multi only when every listed skill has a distinct role and unique question.

Verification

• Falsify / stop: If the route is habit or familiarity rather than mechanism fit, discard and re-score or return NONE. If multi-skill entries lack distinct roles, collapse to the single best primary. If no candidate clearly helps, NONE is correct — do not invent a route.
• Over-application guard: Do not route when the skill is already obvious. Do not return more than three skills. Do not cite deleted or non-catalog names. Do not treat the router as a prerequisite for leaf skills invoked directly.