Decompose to axioms, challenge inherited assumptions, reconstruct from verified truths. USE WHEN first principles, fundamental, root cause, decompose, challenge assumptions, rebuild from scratch, physics-based reasoning, why does this work this way.
Decompose problems to fundamental truths, challenge inherited assumptions, and reconstruct optimal solutions from verified axioms. Based on physics-based reasoning methodology.
Check for user customizations at:
~/.augment/USER/SKILLCUSTOMIZATIONS/FirstPrinciples/PREFERENCES.md
If this file exists, load and apply preferences found there. They override defaults below.
Reasoning by Analogy (default human behavior, often wrong):
Reasoning from First Principles (this skill):
STEP 1: DECONSTRUCT
"What is this really made of?"
Break down to constituent parts and fundamental truths.
|
v
STEP 2: CHALLENGE
"Is this a real constraint or an assumption?"
Classify each element as hard/soft constraint or assumption.
|
v
STEP 3: RECONSTRUCT
"Given only the truths, what's optimal?"
Build new solution from fundamentals, ignoring inherited form.
Break the subject into its actual constituents.
Key Questions:
Process:
Fundamental truths ARE: Laws of physics, mathematical certainties, empirically verified facts, irreducible requirements.
Fundamental truths are NOT: Industry best practices, "how it's always been done," market prices, conventional wisdom.
For every stated constraint, ask: "Is this a law of physics, or is it a choice someone made?"
| Type | Definition | Example | Can Change? |
|---|---|---|---|
| Hard | Physics/reality | "Data can't travel faster than light" | No |
| Soft | Policy/choice | "We always use REST APIs" | Yes |
| Assumption | Unvalidated belief | "Users won't accept that UX" | Maybe false |
Rule: Only hard constraints are truly immutable. Everything else should be challenged.
For SOFT constraints, ask:
For ASSUMPTIONS, ask:
The "Remove It" Test: If we removed this constraint entirely, what would become possible? If the answer is significant, challenge it.
Hidden Assumptions: The most dangerous constraints are those so assumed they are never stated. "Of course we need a database" -- do we?
| Domain | Questions |
|---|---|
| Technical | Is this a language limitation or a fundamental one? Could different tech remove this constraint? |
| Business | Is this budget fixed or just "budget for the obvious solution"? Is the timeline real or arbitrary? |
| Security | Is this preventing a real or theoretical attack? Is this security or security theater? |
| UX | Have we tested with actual users? Are we confusing user needs with user habits? |
| Architecture | Is this pattern required or just familiar? What if we had never seen the current solution? |
Build an optimal solution from scratch using only fundamental truths and hard constraints.
Core Principle: "If we knew nothing about how this is currently done, and only knew the fundamental truths, what would we build?"
Process:
Common Reconstruction Patterns:
## First Principles Analysis: [Topic]
### Deconstruction
- **Constituent Parts**: [List fundamental elements]
- **Actual Values**: [Real costs/metrics, not market prices]
### Constraint Classification
| Constraint | Type | Evidence | If Removed? |
|------------|------|----------|-------------|
| [X] | Hard/Soft/Assumption | [Why] | [What becomes possible] |
### Reconstruction
- **Hard Constraints Only**: [The immutable facts]
- **Function to Optimize**: [Outcome, not method]
- **Optimal Solution**: [Built from fundamentals]
- **Cross-Domain Insight**: [What other field solved this differently?]
### Key Insight
[One sentence: what assumption was limiting us?]
Problem: "We need microservices because that's how modern apps are built"
Problem: "The firewall protects the internal network"
Problem: "Cloud hosting costs $10,000/month -- that's just what it costs"
Attribution: Framework derived from Elon Musk's first principles methodology as documented by James Clear, Mayo Oshin, and public interviews.