Think First: Stop Reacting, Start Reasoning

Chapter 5: Think First — Stop Reacting, Start Reasoning

Claude’s default behaviour when you ask “should I use Redis or PostgreSQL for this?” is to answer immediately. It’s responsive, it’s fast, it often sounds convincing. It’s also skipping most of the work that makes the answer correct.

The think-first skill intercepts that pattern. It detects when a message contains a decision moment — an architectural choice, a trade-off analysis, a “which option is better?” — and requires applying at least one structured mental model before any implementation begins.

The Skill File

---
name: think-first
description: Enforce mental model application before major decisions. Use when facing architecture choices, business decisions, feature prioritisation, trade-off analysis, or any task where the user asks "should I...?" or "which is better?".
use_when: User faces a decision with trade-offs, compares options, asks "should I", weighs pros/cons, describes competing constraints, or needs to preserve specific requirements through implementation.
user-invocable: true
---

The use_when field is unusually detailed here — because the whole point of the skill is triggering on the right signals. “Should I”, “which option”, “how should we approach” — those are the phrases that need interception.

The Detection Logic

The skill defines decision moments as:

Architectural choices (“should we use X or Y?”)
Business model decisions (pricing, positioning, target market)
Feature prioritisation (what to build first?)
Trade-off analysis (speed vs quality, scope vs time)
Strategy questions (how should we approach this?)
Pivots or direction changes (should we change course?)

When Claude detects one of these, the process is: stop, identify, select, apply, proceed. That sequence is the entire value of the skill.

The Mental Models

The skill gives Claude access to twelve mental models, mapped to problem types:

"What should we build?" → first-principles, inversion, one-thing
"How should we prioritise?" → eisenhower-matrix, pareto, opportunity-cost
"Is this the right direction?" → inversion, second-order, 10-10-10
"What are we missing?" → 5-whys, via-negativa, swot
"Which option is best?" → opportunity-cost, first-principles, occams-razor

Each model is invoked via a slash command in a companion resource: /taches-cc-resources:consider:first-principles, /taches-cc-resources:consider:inversion, and so on. The skill tells Claude which models to reach for and in what order.

The Randomness Audit

One of the more interesting sections of the skill file is a pre-analysis check for randomness contamination — based on Nassim Taleb’s work. Before evaluating any options, Claude is instructed to ask whether the evidence itself is trustworthy:

Check	Question
Survivorship bias	Am I only seeing the winners?
Narrative fallacy	Am I constructing a tidy story to explain an outcome randomness explains equally well?
Attribution bias	Am I attributing this to skill when it could be luck?
Sample path overfitting	Is this strategy successful only because the specific sequence of events happened to be benign?

That check runs before any model gets applied. The point is that even structured analysis produces bad results if the input data is noise masquerading as signal.

Constraint Extraction

The skill has a second major function beyond mental model application: constraint extraction. This addresses a failure mode called the “abstraction gap”:

Source says:     "Maximum 3 retries with 30s timeout"
You internalize: "reasonable retry behaviour"
You build:       5 retries with 60s timeout
Verification:    "PASS — retry behaviour looks reasonable"
User gets:       a spec violation

The skill runs a four-scan protocol on any task with specific requirements:

Scan 1 — Quantitative: numbers, thresholds, limits, ranges
Scan 2 — Prohibitions: things that must NOT happen
Scan 3 — Requirements: things that MUST happen
Scan 4 — Implicit: conventions not stated but assumed

The key rule: “NEVER paraphrase numbers, thresholds, or specific values. Copy them verbatim.” A constraint that reads “maximum 15 damage on turn 1” must stay exactly that — not “don’t do too much damage.”

When Not to Use It

The skill is explicit about scope. The detection check asks four questions:

Is this a significant choice with trade-offs?
Will this decision be hard to reverse?
Are there multiple valid approaches?
Does this affect architecture, business model, or strategy?

If no to all four, it’s routine implementation. Proceed without the model.

This matters because applying structured analysis to every small decision creates friction without value. The skill is calibrated to fire on decisions that are worth slowing down for.

How to Customise It

Mental models — the twelve models in the skill map to a companion resource (taches-cc-resources). If you don’t have that resource, you can rewrite the model invocations as inline instructions instead of slash commands.

Detection triggers — the use_when field and the decision type definitions can be narrowed or broadened. If you find the skill firing on things that don’t warrant it, tighten the detection criteria.

Constraint extraction scope — if you only care about the decision-forcing function and not the constraint extraction, you can remove Phase 4 of the process. The two functions are independent.

Premortem threshold — the skill includes an optional premortem step for high-stakes, hard-to-reverse decisions. You can make this mandatory for all decisions or remove it if it’s too slow for your workflow.

Installing It

mkdir -p ~/.claude/skills/think-first
# Copy the SKILL.md from github.com/aplaceforallmystuff

Invoke with /think-first when you’re about to make a significant decision. Or add the skill’s trigger phrase to your project CLAUDE.md so it fires automatically:

## Decision Protocol
Before implementing significant decisions, invoke the think-first skill:
- Architectural choices
- Business model decisions
- Feature prioritisation
- Trade-off analysis

The final chapter covers lessons-learned — the skill that closes the loop when something goes wrong.