Help us improve
Share bugs, ideas, or general feedback.
From thinking-skills
Challenges assumed constraints by reducing problems to fundamental truths and rebuilding solutions from scratch. Useful when conventional approaches fail or something is dismissed as impossible.
npx claudepluginhub tjboudreaux/cc-thinking-skills --plugin thinking-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/thinking-skills:thinking-first-principlesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
First principles thinking strips away assumptions and conventions to reveal fundamental truths, then reconstructs solutions from those basics. This approach, championed by Elon Musk and rooted in Aristotle's philosophy, enables breakthrough solutions by escaping the trap of reasoning by analogy.
Decomposes problems to bedrock truths and rebuilds solutions unconstrained by inherited assumptions. Use when stuck on conventional thinking.
Surfaces hidden assumptions in decisions and problems, finds foundational truths, and identifies high-leverage moves. Invoked via /deconstruct or auto on high-stakes decisions.
Decomposes claims into necessities vs conventions via recursive 'why' questioning, then reconstructs alternatives. Supports brief, tetralemma, and polarity modes for engineering inquiries.
Share bugs, ideas, or general feedback.
First principles thinking strips away assumptions and conventions to reveal fundamental truths, then reconstructs solutions from those basics. This approach, championed by Elon Musk and rooted in Aristotle's philosophy, enables breakthrough solutions by escaping the trap of reasoning by analogy.
Core Principle: Don't accept "that's how it's always done." Reduce to fundamentals, then rebuild.
Decision flow:
Problem intractable? → yes → Are you reasoning from analogy? → yes → APPLY FIRST PRINCIPLES
↘ no → Already at fundamentals
↘ no → Standard problem-solving may suffice
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"):
Skip if the "why" is settled (standard library, known-good pattern). In an incident, act on the most likely cause first; reserve this for post-incident redesign.
List everything you "know" or assume about the problem:
Example: "Rocket launches cost $65M because that's what aerospace companies charge"
Assumptions: Must buy from existing suppliers, existing designs are optimal,
materials must be aerospace-grade, vertical integration is too hard
Ask repeatedly: "What are we absolutely certain is true?"
Decomposition questions:
Example: Rocket raw materials (aluminum, titanium, copper, carbon fiber)
= ~2% of typical rocket price
Fundamental truth: Materials aren't the cost driver;
manufacturing/overhead/margins are
For each assumption, ask:
Use the "5 Whys" to drill deeper:
Why is it expensive? → Suppliers charge high margins
Why? → Limited competition
Why? → High barriers to entry
Why? → Assumption that you must use existing supply chain
Why? → Nobody questioned it
Starting ONLY from verified truths:
Example: Build rockets in-house using commodity materials
= SpaceX reduced launch costs by 10x
| Trap | Description | Antidote |
|---|---|---|
| Reasoning by Analogy | "Others do it this way" | Ask "but is it optimal?" |
| Appeal to Authority | "Experts say it's impossible" | "What specifically makes it impossible?" |
| Sunk Cost | "We've always done it this way" | "What if we started fresh today?" |
| Complexity Bias | Assuming complex = better | "What's the simplest version?" |
| False Constraints | Accepting artificial limits | "Is this a law of physics or convention?" |
Assumption: "We need a microservices architecture"
First Principles:
- What problem are we solving? (scalability, team independence, deployment)
- What's the minimum that achieves this?
- A modular monolith might suffice for current scale
Assumption: "This service costs $50k/month, that's just cloud pricing"
First Principles:
- What compute/storage do we actually need?
- What are we paying for that we don't use?
- Could we reduce by 80% with right-sizing?
Assumption: "Users need feature X (because competitor has it)"
First Principles:
- What job is the user trying to accomplish?
- What's the simplest way to enable that job?
- Maybe a different approach solves it better