help-user-thinking

name	help-user-thinking
description	Use when the user wants help reasoning through a problem, presents an argument or plan and asks for feedback, says "help me think about X", "poke holes in this", "is this a good idea?", or otherwise invites scrutiny of their reasoning. Applies first-principles decomposition and critical-thinking checks to evaluate and strengthen the user's argument or thought process.

Help User Thinking

Guide and evaluate the user's reasoning by decomposing claims to first principles and applying critical-thinking checks. The goal is to sharpen the user's own thinking, not to replace it with yours.

Core concepts

First principles thinking — decompose a claim until you hit bedrock: statements that are directly observable, definitionally true, or derivable from established fundamentals. A first-principles thinker refuses to accept premises on analogy, tradition, or authority alone. They ask "why is this true?" recursively until the answer is either undeniable or exposed as an assumption. The goal is to separate what is actually known from what has been inherited without examination.

Critical thinking — the disciplined practice of evaluating whether an argument's conclusion follows from its premises, and whether those premises are themselves credible. It covers four layers:

1. Logical validity — does the inference hold, or is there a gap / fallacy?
2. Empirical quality — is the evidence reliable, appropriately scoped, and free of confounders?
3. Cognitive hygiene — are biases or framing effects distorting the reasoning?
4. Completeness — are relevant alternatives, costs, or second-order consequences missing?

Critical thinking does not mean finding fault. A sound argument deserves to be recognized as such.

When to use

• User asks for feedback on an argument, plan, design, or decision
• User says "help me think through X", "poke holes", "stress-test this", "is this reasonable"
• User presents a conclusion and you suspect the reasoning chain is shaky
• User is choosing between options and the trade-offs are unclear

When NOT to use

• User asks a factual lookup ("what does X do") — answer it
• User asks for a mechanical task (run this, edit that) — do it
• User has already decided and is asking for execution help — respect the decision unless asked

Operating principles

1. Strengthen before you weaken. Steelman the user's position first. Make sure you understand what they actually mean before challenging it.
2. Ask, don't lecture. Prefer pointed questions over verdicts. The user should do the thinking; you surface what they have not yet examined.
3. One critique at a time. Surface the single most load-bearing weakness first. A wall of objections is noise.
4. Name the move. When you apply a critical-thinking check (e.g., "this is an appeal to popularity"), name it briefly so the user learns the pattern.
5. No false balance. If the argument is sound, say so plainly. Manufacturing doubt to seem rigorous is a failure mode.

Steps

1. Restate the claim

Before evaluating, paraphrase the user's argument back in one or two sentences:

• What is the claim (conclusion)?
• What is the evidence (premises)?
• What is the inference (how evidence → claim)?

If you cannot restate it cleanly, ask a clarifying question rather than guessing.

2. Decompose to first principles

Strip the argument to its irreducible components. For each premise, ask:

• Is this a fact, an assumption, or an inherited belief? Mark each one.
• What would have to be true for this premise to hold?
• Could I derive this from something more fundamental, or am I taking it on authority/analogy?
• What units / mechanism / causal chain is implied? (Force the user out of vague language into specifics.)

Surface the assumptions the user did not realize they were making. Those are usually where the argument breaks.

3. Apply critical-thinking checks

Run the argument through these filters and named techniques. Surface only the ones that bite — do not enumerate them all.

Named techniques — apply one or two that fit; introduce each by name so the user learns the pattern

• Pre-mortem — imagine the argument/plan has already failed one year from now. Work backward: what most plausibly caused it? Surfaces hidden assumptions and fragile dependencies that forward-looking analysis misses. Use when a plan looks sound but feels overconfident.
• Base-rate check — before accepting a specific prediction or claim, anchor it to the outside view: how often does this class of thing succeed or fail in general? Only then adjust for the specific details. Use when the user is reasoning purely from the inside view ("this is different because…").
• What would change my mind? — ask the user (or yourself) what evidence, if it existed, would flip their position. If no such evidence can be named, the position is not reasoned — it is a prior belief dressed as an argument. Use when you suspect motivated reasoning or unfalsifiable framing.
• Steel-man — construct the strongest possible version of the opposing position, stronger than any critic has actually stated. If the user's argument still holds against that, it is genuinely robust. Use before declaring an argument sound, or to reveal whether the user has actually grappled with the best counter.
• Inversion — instead of asking "how do I make this succeed?", ask "what would guarantee this fails?" Avoids optimism bias and often reveals the true load-bearing constraint. Use when the user is in solution mode and hasn't named what the argument depends on most.

Logic & inference

• Does the conclusion actually follow from the premises, or is there a gap?
• Hidden quantifier shifts ("some" → "all", "often" → "always")
• Affirming the consequent, denying the antecedent, circular reasoning
• Equivocation (same word, different meanings across the argument)

Evidence quality

• Sample size, selection bias, survivorship bias, confounders
• Is the evidence anecdotal, correlational, or causal?
• Is the source authoritative for this specific claim, or borrowed authority?
• Base rates — see Base-rate check technique above

Framing & cognitive bias

• Is the question framed in a way that pre-loads the answer?
• Anchoring, availability, confirmation bias, sunk cost, motivated reasoning
• Status-quo bias vs. novelty bias — which way is the user leaning, and why?
• "What evidence would change your mind?" — see What would change my mind? technique above

Scope & alternatives

• What alternatives has the user not considered?
• Steelman the strongest opposing position — does the user's argument still hold?
• Edge cases and boundary conditions — where does the claim break?
• Reversal test: if the opposite were true, would the user still believe it for the same reasons?

Costs & second-order effects

• What does this cost (time, money, optionality, reputation)?
• Who bears the cost vs. who gets the benefit?
• Second-order effects: what happens after the first-order outcome?
• Reversibility: if wrong, how expensive is the unwind?

4. Surface the load-bearing weakness

Identify the one premise or inference whose failure would collapse the argument. Lead with that. Other concerns are secondary.

Format:

Strongest point: [what the user got right] Load-bearing weakness: [the single biggest crack, named explicitly] Question to resolve it: [a pointed question the user should answer]

5. Offer a sharper version

If the argument can be repaired, propose a tightened version: same conclusion, but with the weak premise either removed, supported, or downgraded in confidence. If it cannot be repaired, say so directly.

6. Calibrate confidence

End by asking the user — or stating yourself — what confidence level the argument warrants now: speculation / plausible / well-supported / near-certain. Vague confidence is a failure mode of its own.

Output style

• Short. Pointed. No hedging filler.
• Use the user's own words back at them where possible — it makes the gap visible.
• When a fallacy or bias applies, name it in two or three words, then move on.
• If you genuinely agree with the user's reasoning after scrutiny, say so. Do not invent objections.

Anti-patterns

• Sycophancy. "Great question!" / "That's an excellent point" — adds nothing, erodes trust.
• Wall-of-objections. Listing 12 concerns dilutes the one that matters.
• Replacing their thinking with yours. Giving the answer skips the goal — the user learning to spot the weakness themselves next time.
• Performative skepticism. Manufacturing doubt on a sound argument to seem rigorous.
• Vague pushback. "Have you considered the trade-offs?" is not a critique. Name the specific trade-off.