First Principles Thinking

First Principles Thinking

Break problems down to fundamental truths, then rebuild solutions from the ground up. Do not import conclusions from other contexts; derive them from what is actually, verifiably true in this one.

This skill is a reasoning guide only: Markdown instructions plus reference files, with no helper program, installer, network endpoint, or automatic state mechanism. Keep claim ledgers in the active conversation; use external tools only when the runtime already provides them and the task requires evidence, calculation, or source inspection.

1. The problem has been restated in terms of outcomes (not solutions). If context is sufficient, proceed on stated working assumptions instead of asking for confirmation.
2. The primary task mode has been classified (decision / diagnosis / planning / critique / explanation / synthesis / exploration).
3. The Claim Ledger has been populated: verified facts, reported claims, assumptions, constraints, and unknowns each explicitly listed.
4. Ground truths have been explicitly separated from inherited conventions.
5. The core mechanism has been mapped: variables, causal links, constraints, feedback loops, bottlenecks.
6. At least one failure-oriented check has run: inversion, falsifier, backward check, or red-team objection.

The cost of skipping this gate is solving the wrong problem efficiently -- the most expensive failure mode in engineering, strategy, and research.

Activation

Activate on complexity markers: architecture/design questions; "should I use X or Y"; hard debugging ("intermittent", "root cause", "happens sometimes"); performance and scaling; integration/migration; strategy, product, or research framing; brainstorming and ideation; convention language ("best practice", "industry standard", "everyone uses", "we've always"); or explicit invocation ("first principles", "FP mode", "from scratch", "challenge my assumptions").

Stay dormant for trivial edits, boilerplate, direct implementation of an already-decided design, or user override ("just do it", "skip the analysis"). When in doubt, do not add process overhead: run Quick depth silently, or ask one sentence -- "Should I challenge the assumptions first or go straight to implementation?"

Depth Levels

State the detected depth at the start; the user can override.

Proportional effort is a rule, not a preference. At Quick depth the artifact may be compact prose with tagged ledger lines; tables are optional. Never let the process feel like overhead when the answer is obvious.

Task Modes

Classify every non-trivial problem into one primary mode (at most one secondary), state it aloud, and let it shape the phases. Mode-specific phase guidance lives in references/mode-playbooks.md -- load it after Phase 1 fixes the mode.

Reasoning Budget and Tool Router

Use the smallest reasoning stack that can safely answer the problem. Activate heavier tools only when the problem is ambiguous, irreversible, high-stakes, data-dependent, or explicitly brainstorming-oriented. Detailed prompts and templates for every row: references/advanced-reasoning-tools.md.

State the chosen tools in a short Tool Plan before the analysis (one line at Quick depth). If a tool will not change the answer, do not use it.

The Phases

Phases run in order. Earlier phases may be abbreviated at Quick depth, never skipped entirely. Full technique write-ups (Socratic catalog, 5 Whys, inversion playbook, Chesterton's Fence, falsifiability, ToT, Occam's Razor, mechanism mapping, Fermi, verification chains): references/techniques.md.

Phase 1 -- Intake (always)

Restate the problem in outcome terms, not solution terms. Classify mode and depth. If enough context exists, proceed with explicit working assumptions.

"I read the outcome as: [one sentence]. Current approach or framing: [current solution idea, if any]. Mode: [mode] (secondary: [mode | none]). Depth: [level]. Working assumption if not corrected: [...]."

If you cannot state the problem as an outcome independent of the proposed solution, ask one targeted question or state the safest working assumption and continue with caveats. If you cannot pick one primary mode, it is two stacked problems -- name both, resolve the first one first. Treat the user's framing as a [CLAIM], not ground truth, until it passes the Ground-Truth Test or is explicitly stipulated.

Phase 2 -- Socratic Questioning (always)

Probe with the 3-5 most relevant question families: clarification, assumption probing, evidence, alternative viewpoints, implications, meta ("are we solving the right problem?"). Asking all six robotically is worse than three well-chosen ones. Full catalog with probes per family: references/techniques.md.

Red-flag phrases that almost always hide an assumption -- drop into assumption-probing when you hear them:

• "We've always done it this way"
• "Industry standard / best practice says"
• "Everyone uses X for this"
• "That's too simple to work"
• "We can't change that" (without verifying why not)
• "The client / PM said so" (without tracing the underlying need)

Cadence: Quick = 2-3 questions in one message; Standard = 1-2 per turn; Deep = one per turn, following threads wherever they lead.

Phase 3 -- Decomposition & Claim Ledger (Standard + Deep)

File every atomic component of the problem into the Claim Ledger -- the canonical record of what you know, were told, are guessing, what binds you, and what is missing. Nothing downstream may cite a fact that is not in the ledger.

Ground-Truth Test -- before tagging anything [TRUTH]:

1. Can it be decomposed further into something more fundamental?
2. Is it provably true in this context, not just commonly believed?
3. Would violating it definitely cause failure (not just inconvenience)?

Any "no" or "not sure" routes it to another lane. User-supplied statements start as [CLAIM]. If the user pastes a prior ledger or notes, import items as [CLAIM] -- never directly as [TRUTH] -- and log the import (rules: references/session-ledger-template.md).

Lane discipline:

• Each [ASSUMPTION] gets category (technical / business / resource / historical / behavioral / data), evidence, confidence, fragility, failure mode, and fastest test. Assumptions whose falsehood would flip the conclusion are elevated to User Checkpoints.
• Each [CONSTRAINT] must name its source, numeric threshold where applicable, and cost of violation. Unsourced "constraints" are [ASSUMPTION]s in disguise.
• Each [UNKNOWN] must state how it would be resolved and whether the recommendation changes across its plausible range. If the recommendation is stable across the range, the unknown is not blocking.

Then build a compact Mechanism Map (actors, variables, inputs/outputs, causal links, confounders, feedback loops, bottlenecks, boundary conditions; for business work add incentives, adoption friction, switching costs) and run least-to-most decomposition: 3-7 smallest solvable subproblems, each yielding one variable, constraint, mechanism claim, risk, or testable unknown.

Recursion rule: if a component reveals its own hidden assumptions ("we need a message queue" contains "we need async processing"), say so and run Phases 2-3 on it. Maximum depth 2; anything deeper becomes an [UNKNOWN].

Phase 4 -- Inversion (Deep; optional at Standard)

Ask: "What would guarantee this fails? What must I avoid at all costs?" List 3-5 failure modes; for each, identify which truth or design choice prevents it. Unprevented failure modes are risks that must be addressed or explicitly accepted. Inversion is cheap and catches gaps forward analysis misses.

Phase 5 -- Reconstruction (Standard + Deep)

Build 2-3 candidate paths (3-5 for exploration) using only verified ground truths. For each path state: the [TRUTH]s and [CONSTRAINT]s it is built on, its design choices, its core mechanism, trade-offs against the other paths (cost, reversibility, complexity, novelty), remaining [UNKNOWN]s, and the cheapest falsifying test. If magnitudes matter, add a Fermi / dimensional check before ranking. The conventional path may win -- but because the analysis led there, not because it was the default.

Chesterton's Fence: before recommending removal of any existing structure, state why it was built and whether those conditions still hold. If you can't, you don't yet have the right to remove it.

Phase 6 -- Verification (Deep; optional at Standard)

Stress-test before handing over:

1. Strongest alternative view -- the best objection or competing option, attributed to the smartest possible critic, not a strawman.
2. Self-consistency -- 2-3 independent reasoning paths when uncertain.
3. Chain-of-verification -- ask at minimum: which claim is most likely false? which fact needs external evidence? which assumption would flip the conclusion? Answer independently, then revise.
4. Backward check -- if the conclusion is true, what else must be true? Check against the ledger.
5. Falsifier -- what observation would prove this wrong? If nothing would, it is not rigorous enough.
6. 5 Whys on the chosen path -- must bottom out in a [TRUTH] or [CONSTRAINT], not another [ASSUMPTION].
7. Sensitivity -- the 1-3 variables most likely to change the answer; if a +/-20% change flips it, lower confidence and make the test explicit.
8. Reversibility -- cheap-to-reverse decisions need less certainty.
9. Confidence -- low / medium / high, grounded in which [UNKNOWN]s remain open.

Phase 7 -- Artifact (always)

Emit a structured First Principles Analysis block; it stays in context and guides subsequent work. Full Quick and Standard/Deep templates plus the carry-forward summary format: references/artifact-templates.md.

Every artifact, at any depth, must contain: problem-as-outcome, mode, depth, tool plan, claim ledger, mechanism sketch or map, assumptions challenged with verdicts (Keep / Modify / Discard / Investigate), the recommendation with each major choice citing a [TRUTH] or [CONSTRAINT], at least one verification check (falsifier / backward check / sensitivity), and User Checkpoints -- the top 1-3 assumptions the user should confirm, reject, or supply next. Exploration artifacts additionally include: best practical option, most novel option, fastest experiment, biggest risk, and what would make each option wrong.

Brainstorming (Exploration depth)

Diverge first, converge second. Diverge with at least two of: Tree of Thoughts (3-5 genuinely different paths, expand top 2, keep the runner-up), Graph of Thoughts (ideas as nodes/edges, synthesize non-obvious intersections), morphological matrix, contradiction analysis ("more X without more Y"), or multi-perspective debate (mechanist, operator, red team, creative strategist -- each critiques another before synthesis). Converge with red-team critique, fastest experiment, and sensitivity to the dominant assumption. Templates: references/advanced-reasoning-tools.md.

Key Principles

• Opinionated on process, neutral on solution. Enforce deconstruction ruthlessly; then present options and let the user choose.
• Separate IS from ASSUMED. Distinguishing irreducible constraints from inherited conventions is the core skill; everything else follows.
• Recursive, not linear. Sub-problems have their own assumptions.
• Proportional effort. Trivial problems get trivial analysis.
• Build from bedrock upward. When the bedrock-derived answer matches the industry standard, fine -- the analysis converged; the convention was not imported.
• Invert, always invert. Forward analysis finds what to do; inversion finds what must be avoided. Both are required.
• Development time is a ground truth too. When an existing solution is within 2x of optimal and the team already knows it, that is usually the right answer. First principles pays off where convention is 10x wrong, not 10% suboptimal.

Common Traps

Reasoning by analogy creeping back in:

Supporting Files

• references/techniques.md -- full toolbox: Socratic catalog, 5 Whys, inversion, Chesterton's Fence, falsifiability, ToT, Occam's Razor, mechanism mapping, Fermi, verification chains. Load when picking the right tool for a phase.
• references/advanced-reasoning-tools.md -- templates for every Tool Router row: mechanism map, assumption ledger v2, least-to-most, Fermi, evidence grounding, CoVe, self-consistency, sensitivity, brainstorming pack, solver trigger. Load at Deep or Exploration depth.
• references/mode-playbooks.md -- per-mode phase emphasis for all seven modes. Load after Phase 1.
• references/artifact-templates.md -- Quick and Standard/Deep artifact formats plus the carry-forward ledger summary. Load at Phase 7.
• references/session-ledger-template.md -- ledger lanes, import rules for pasted prior context, carry-forward block.
• references/examples.md -- four worked engineering examples end to end. Load to see what good output looks like.
• references/review-notes.md -- human-review note: this package is text-only, with no executable helper or automatic state mechanism.

Boundaries

This skill challenges assumptions visibly, tags truths / assumptions / unknowns distinctly, builds reasoning traceable to fundamentals, and surfaces inversion risks and falsifiers. It does not dismiss conventional solutions reflexively, expand trivial decisions into philosophy, override domain expertise with naive re-derivation, promise the "best" solution (it produces better reasoning), or keep running once the user says "skip the analysis".

Quick Reference Checklist

Before emitting a recommendation, confirm:

• Problem stated as an outcome, not a solution; mode and depth announced
• Tool Plan names only the tools the problem warrants
• Claim Ledger populated across all five lanes; user statements routed to the right lane via the Ground-Truth Test
• Mechanism map built when causality, strategy, systems, or debugging matter
• Assumptions given verdicts; constraints carry source + threshold + cost; unknowns carry resolution plan + sensitivity
• At least one inversion failure mode answered (Deep)
• Each design choice traces to a [TRUTH] or [CONSTRAINT]
• Strongest alternative view stated and addressed (Standard + Deep)
• Falsifier named; sensitivity and residual confidence stated
• Mode playbook followed; artifact emitted with User Checkpoints