tjboudreaux/cc-thinking-skills

# Bounded Rationality

Under finite tool, context, and time budgets, stop at the first option that meets a predeclared aspiration level. Optimize only when the good-to-best gap is worth the remaining budget.

## When to Use

- Search or option comparison has no natural endpoint and could consume the turn budget.
- Multiple options would clear the requirement and further comparison has diminishing returns.
- The decision is reversible or low-stakes relative to more search.
- You are gathering context beyond what the decision needs to ship.

## When NOT to Use

- Irreversible or high-stakes choices (data loss, security, migrations, public commitments) where the good-to-best gap is material.

# Circle of Competence

Treat competence as an evidence boundary, not self-image. Answer only when grounded; otherwise fetch, mark uncertainty, or abstain. The failure mode is a fluent fabrication treated as fact.

## When to Use

- About to assert a specific fact (API, path, number, config, version behavior) without a citable source from this session.
- The claim is about this codebase or system and you have not read or run the relevant artifact.
- Pattern reconstruction would sound complete but is unconfirmed.
- Cost of a wrong confident answer is material (security, data, irreversible action, trust).

## When NOT to Use

- Claim is grounded in something you read, ran, or can cite this session, or is stable universal knowledge — answer without false humility.

# Cynefin Classification

Classify by cause-effect, then use only the matching response mode. Wrong-domain method is the failure mode.

## When to Use

- Unsure whether to run a playbook, analyze, probe, or stabilize.
- A method keeps failing and domain mismatch is plausible.
- A novel or mixed problem needs approach selection before solution work.

## When NOT to Use

- Domain and method are already agreed—execute.
- Task is finding a specific cause, not choosing an approach.

# Effectuation

Under Knightian uncertainty, start from available means and affordable loss—not a fixed goal and predicted return. Create the path through controllable action and real commitments.

## When to Use

- The market, technology, or problem is novel enough that outcome probabilities are not trustworthy.
- Means are clearer than the goal: identity, skills, assets, and network exist before a fixed target does.
- A small action can buy information or a partner commitment without risking ruin.
- Plans keep breaking because the environment shifts faster than forecasts.

## When NOT to Use

- The path is predictable: known market, knowable unit economics, established playbook → use causal planning.

# First Principles

Strip assumed constraints to independently supported primitives, then rebuild. Escape analogy when convention fails or looks artificially expensive.

## When to Use

- A constraint is treated as fixed ("too expensive," "impossible," "always done this way") without independent support.
- Convention or analogy has failed, stalled, or only yields weak incremental variants.
- Greenfield design where industry defaults may smuggle false requirements.
- Cost or feasibility claims rest on pricing, precedent, or authority rather than physics, math, or measured need.

## When NOT to Use

- The constraint is verified physics, hard regulation, or measured capacity → accept it and optimize within it.

# Five Whys Plus

Build an evidence-linked causal chain from a known proximate fault to an actionable systemic root, then prescribe a countermeasure that would have blocked it.

## When to Use

- A fault is already localized to a component, path, or subsystem.
- The proximate cause is known, but recurrence or systemic root is not.
- Prior symptom-only fixes failed and the failure returned.
- You need prevention that addresses why the proximate cause was possible.

## When NOT to Use

- Fault is not localized or multiple candidate causes remain — discriminate first.

# Jobs to Be Done

Core rule: users hire solutions for progress in a situation. Prioritize the job, forces, outcome, and competing workaround—not the feature list.

## When to Use

- Choosing what to build, cut, or prioritize when user need is unclear
- Explaining low adoption of a shipped feature
- Mapping competition beyond same-category products (email, spreadsheets, manual work, non-consumption)
- Positioning or research when the progress sought is contested

Requires at least one evidence source: PRD/spec, tickets, support/sales notes, analytics/logs, or current product behavior. If none exist, name the research gap; do not invent quotes.

## When NOT to Use

# Kepner-Tregoe Analysis

**Core rule:** Diagnose deviations by testing causes against both IS and IS-NOT. Compare consequential choices by screening MUSTs, weighting WANTs, and exposing adverse consequences before selecting.

## When to Use

- A defect affects some objects, places, times, or cohorts but not comparable others.
- Several candidate causes remain and the contrast boundary can discriminate them.
- A consequential option choice has explicit non-negotiables, competing objectives, and risks that should be compared consistently.

## When NOT to Use

- A uniform failure has no meaningful IS-NOT contrast, or the cause is already confirmed.
- One cheap observation settles the cause or one option plainly dominates every requirement.

# Lindy Effect

For non-perishable ideas, technologies, and practices, expected remaining life scales with current survival age. Prefer proven survivors unless the new option clears a burden of proof or the domain has drifted.

## When to Use

- Choosing languages, frameworks, databases, protocols, patterns, or dependencies where long-term survival matters.
- Skill or architecture bets whose value depends on lasting relevance.
- Ranking options when ages differ materially and the choice outlives a short experiment.

## When NOT to Use

- Perishable targets: specific SaaS vendors, hardware, fashion, or products that can shut down regardless of concept age.
- Active paradigm discontinuity where age in the old regime is weak evidence.

# Map Territory

Docs, tests, diagrams, metrics, comments, and mental models are maps. Running code and actual data are the territory. When they disagree, verify territory and update the model — never force reality to match the description.

## When to Use

- Observed behavior contradicts a doc, test expectation, diagram, comment, dashboard, or prior assumption.
- A claim about the system rests on a secondary source rather than current code or data.
- Tests pass but production or manual behavior is wrong.
- You are about to theorize why something happens before inspecting what happens.
- A decision depends on whether a model, schema, or metric is still current.

## When NOT to Use

# Margin of Safety

Core rule: commit a buffered number when residual uncertainty plus breach cost can cause ruin or costly failure. Margin covers estimation error; it is not free slack for laziness.

## When to Use

- Capacity, timeouts, pool sizes, queue depths, storage, or SLA numbers under load uncertainty
- Timeline or budget commitments where underestimation is costly
- Architecture headroom when scaling or recovery is slow
- Any public or production commitment where being wrong has asymmetric downside

## When NOT to Use

- Breach is detected immediately and fixed near-zero cost (fast auto-scale, live-tunable limit)—static fat buffers waste resources

# Model Combination

**Core rule:** Combine only when each model answers a different named question. Cap at three, name the conflict rule before applying, then synthesize once.

## When to Use

- One model already applied (or clearly primary) still leaves a material blind spot that another mechanism covers.
- Problem spans domains (e.g. risk + choice + system structure) and stakes justify multi-lens work.
- You need independent checks, not confirmation of the same conclusion.
- You can name a distinct role per model before running them.

## When NOT to Use

- A single catalog skill fully answers the unknown — apply that skill alone.

# 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).

# OODA Loop

**Core rule:** For reversible moves under time pressure, act on ~70% confidence, then immediately re-observe. Cycle faster than the situation compounds; a late perfect plan loses to a fast loop.

## When to Use

- Incident response, outage, or ongoing degradation where state is still moving.
- Debugging a moving target (intermittent failure, live traffic shift).
- Any time-bounded decision where waiting for full certainty costs more than a reversible action.

## When NOT to Use

- The situation is static and you have time — deliberate analysis or a hypothesis differential wins.
- The next action is irreversible or high blast-radius — raise the evidence bar; 70% is not enough.

# Opportunity Cost

Core rule: every commitment displaces its best alternative. Report both that forgone value and the net value delta; decide on the delta, not the chosen path alone.

## When to Use

- Allocating scarce time, headcount, budget, or attention across competing options
- Feature prioritization, build-vs-buy, tech-debt vs product work
- Saying yes to a large commitment that displaces other work
- Comparing a bold path against polishing the status quo when windows may close

## When NOT to Use

- Trivial or cheaply reversible choices where analysis costs more than the resource

# Pre-Mortem Analysis

**Core rule:** Prospective hindsight beats "what could go wrong?" Assume the plan has already failed (past tense), generate concrete failure paths, reverse them into prevention requirements, and bind each top path to a verifiable plan change.

## When to Use

- Before kickoff, major technical commitment, high-risk sprint work, launch, or release.
- After a plan looks solid but before execution, especially when optimism or overconfidence is likely.
- When a decision is costly to reverse and risks are still implicit rather than enforced.

## When NOT to Use

- Work is small, local, and cheaply reversible — skip the ceremony.
- You are mid-incident under time pressure — act now (OODA / scientific method); pre-mortem is pre-execution.

# Probabilistic Thinking

**Core rule:** State beliefs as numbers and ranges, not vibes. Anchor on a base rate, update with an explicit likelihood, and bound unknowns by factoring them — never invent false precision.

## When to Use

- Timeline, effort, or outcome forecasts where the true value is uncertain.
- Risk sizing for a change, migration, deploy, or launch.
- Any moment you are about to state a confident single number you cannot actually know.
- New evidence arrives and a prior estimate should move.

## When NOT to Use

- The quantity is measurable or look-up-able — measure or look it up.

# Red Team

Adversarial security review of systems you are authorized to assess. Attack before an outsider does, but report only what you can actually break: every finding needs a concrete exploit path and a check that the proposed fix closes it.

## When to Use

- Security review of code, authentication, authorization, APIs, data handling, or infrastructure you control and are permitted to probe.
- Pre-launch hardening of systems that handle auth, money, personal data, or privileged actions.
- Checking whether a specific vulnerability class (injection, XSS, IDOR, auth bypass, SSRF, secret exposure, etc.) is present with a real path.
- Validating that a claimed control actually blocks the attack, not only that a scanner is quiet.

## When NOT to Use

- No authorization to attack the target — stop; do not probe systems you do not own or have written leave to test.

# Reversibility

Core rule: match process depth to undo cost. Most decisions are cheaper to reverse than they look; irreversible ones deserve deliberation and staged commitment.

## When to Use

- Uncertain how much analysis a decision deserves (tech, process, product, org)
- Tempted to committee a low-blast-radius choice, or to rush a high-lock-in one
- Can redesign the move (pilot, flag, abstraction, time-box) to lower undo cost
- High-stakes choice where acting vs waiting have asymmetric recovery profiles

## When NOT to Use

- Already classified this session—decide at matched depth; do not re-label forever

# Scientific Method (Hypothesis Differential)

When a symptom could come from several places, enumerate competing falsifiable hypotheses and spend the cheapest observation on the one that best discriminates among them. After each observation, keep only hypotheses that still fit, then prefer the survivor with the fewest unsupported assumptions as the working explanation.

## When to Use

- A bug, incident, or anomaly has more than one plausible cause.
- You can observe code, logs, diffs, traces, tests, configs, or data now.
- You must localize the faulty file, function, branch, config, or invariant before fixing.
- Competing explanations fit the same surface facts and you need a discriminating check.

## When NOT to Use

- Cause is already obvious from a single stack, failing test, or recent diff — fix directly.

# Second-Order Consequence Chains

Do not stop at the intended first effect. Trace what happens next across actors, time, and feedback until the chain stops changing the decision.

## When to Use

- Strategic, policy, incentive, or architecture choices with lasting coupling.
- The obvious fix feels too easy or has known backfire patterns.
- Success or scale would create new problems (load, gaming, debt).
- Need to compare options by delayed effects, not only day-one benefit.

## When NOT to Use

- Local reversible edit with no incentive or cross-component coupling—just ship and observe.

# Socratic Questioning

**Core rule:** Surface the load-bearing assumption or undefined term before you build. Ask only what you cannot resolve yourself; stop when the next action is decision-ready.

## When to Use

- Request is underspecified ("make it fast", "add a dashboard", "fix the bug") and a guess would misbuild.
- Claim rests on an unstated assumption that may be the real problem.
- Someone treats a premise as "obvious" or jumps to a solution before the problem is defined.
- Debugging a vague symptom that needs a checkable specific before investigation.

## When NOT to Use

- Spec is already clear and actionable — do the work; do not interrogate for theater.

# Steel-Manning

**Core rule:** Engage the best form of the opposing case, not a weak one. If your position survives that, reaffirm; if not, update.

## When to Use

- About to reject a proposal, design, or alternative approach.
- Inclined to agree with the user/plan and risk sycophancy — construct the best case *against* first.
- Design review, architecture debate, or conflict where trade-offs are real.
- Validating your own preferred decision before locking it (strongest-countercase check).

## When NOT to Use

- Settled fact, security anti-pattern, or violated hard requirement — correct it; do not invent a defense of what is wrong.

# Systems Mapping and Leverage

Treat the problem as structure and interaction, not isolated parts. Map boundary, stocks/flows, loops/delays, and recurring patterns; intervene at the highest feasible leverage after a side-effect check.

## When to Use

- Symptom spans services/components; single-stack fixes fail or bounce.
- A change in one place breaks another; behavior is emergent.
- Problem recurs despite local fixes (structure, not only symptom).
- Need to rank interventions when parameter/buffer tweaks do not stick.

## When NOT to Use

- Single-component linear bug with clear stack/diff—trace and fix.

# Theory of Constraints

A throughput-limited system has one binding constraint. Improve only that constraint; local optimization of non-constraints wastes effort and often grows WIP.

## When to Use

- Latency or throughput goal where one stage dominates time or rate.
- Work piles up before one stage; downstream idles.
- Adding capacity/workers elsewhere does not raise end-to-end output.
- Need ordered plan: exploit cheaply before spending to elevate.

## When NOT to Use

- Load is spread; no stage dominates—use systems for interactions.

# Thought Experiment

When empiricism is out of reach, run a disciplined counterfactual: one isolated change, fixed conditions, step-by-step mechanism, and a hard bound on implications.

## When to Use

- You need behavior under failure, scale, or policy you cannot cheaply trigger or measure (region outage, 100x load, one-way architecture).
- A decision is expensive or irreversible and a mental trace can surface break points before commit.
- Edge cases are too costly to stage, but a mechanistic chain can still expose missing controls.

## When NOT to Use

- A cheap real test exists (load test, flag, query, spike) → run the test; do not substitute imagination.
- Adversarial security attack-path work → use red-team structure, not free-form scenarios.

# TRIZ

Resolve technical design contradictions without midpoint compromise. Name the conflict, separate the opposing states, and transform the system so both benefits hold.

## When to Use

- Architecture, API, or system parameters pull in opposite directions (stable vs evolving, fresh vs cached, strict vs frictionless).
- You are about to accept a trade-off because "you can't have both."
- Every candidate solution shares the same structural weakness—the conflict is in the requirements, not the options list.

## When NOT to Use

- One option is simply better under stated constraints → pick it; do not manufacture a contradiction.
- A cheap measurement shows which side actually matters → measure instead of inventing a separation.

# Via Negativa

Improve by subtraction before addition. Prefer removing harm, waste, and nonessential complexity; add only when a demonstrated need remains after removal candidates are exhausted.

## When to Use

- About to add a feature, abstraction, dependency, process, or control to fix a problem.
- Simplifying a system or workflow where complexity is the tax.
- Prioritizing by deciding what not to keep, build, or maintain.
- Performance or reliability work where eliminating a bad path beats bolting on mitigation.

## When NOT to Use

- Load-bearing controls: auth, validation, tests, rate limits, retries, safety checks — presume necessary until proven dead.