/first-principles-thinking

name: first-principles-thinking
description: >
  Systematic first principles thinking for any problem domain. Use when the user says
  "analyze from first principles", "第一性原理", "从根本分析", "从零开始思考",
  "think from scratch", "question this design", "is this the right approach",
  "challenge assumptions", "挑战假设", "为什么要这样做", "有没有更好的方案",
  "why are we doing it this way", or needs to evaluate decisions, designs, or strategies
  without relying on analogies, conventions, or "best practices". Also triggers on
  "这个设计合理吗", "从本质上看", "回到基本面", "what's really true here",
  "what are we assuming", or any request to decompose a problem to its fundamentals.
license: MIT
metadata:
  author: oh-my-openclaw
  version: "1.0"
  composed_from:
    - "awesome-skills/first-principles-skill (GitHub, 11 stars)"
    - "HoangTheQuyen/think-better (GitHub, 41 stars)"
    - "鹅厂架构师 davidycwei — 从第一性原理思考 Agentic Engineering (Zhihu)"
    - "Reddit r/PromptEngineering — 4 Thinking Models Master Prompt (112 upvotes)"
  sources:
    - https://github.com/tt-a1i/first-principles-skill
    - https://github.com/HoangTheQuyen/think-better
    - https://zhuanlan.zhihu.com/p/2010365825916359006
    - https://www.reddit.com/r/PromptEngineering/comments/1ma7f00/

First Principles Thinking

A systematic approach to decomposing complex problems into irreducible truths and reasoning upward from there — avoiding the trap of reasoning by analogy, convention, or "best practice".

When to Use

• Evaluating whether an architecture, design, or strategy is truly optimal
• Questioning "best practices" that may not fit the current context
• Breaking through when conventional solutions feel inadequate
• Making foundational decisions with long-term impact
• Challenging inherited assumptions in legacy systems or legacy thinking
• Any moment where "we've always done it this way" is the primary justification

When NOT to Use

• Trivial decisions (use Occam's Razor instead — just pick the simplest)
• Time-critical emergencies (act first, analyze later)
• Well-validated problems with proven solutions (don't reinvent the wheel)
• When you lack domain expertise AND can't acquire it (first principles without knowledge = naive solutions)

---

Core Methodology: 6 Phases

Phase 0: Frame the Question — Establish Axioms

Before analyzing anything, define the irreducible truths that constrain this domain.

**Axioms** = facts that are independently verifiable, cannot be further decomposed, and violating them definitely causes failure.

**How to identify axioms:**

• Ask: "Can this be further decomposed?" — If yes, it's not an axiom yet.
• Ask: "Is this provably true, not just commonly believed?" — If uncertain, it's an assumption.
• Ask: "Would violating this definitely cause failure?" — If maybe, it's a preference.

**Gate**: Must produce ≥3 axioms before proceeding. Each axiom stated in one sentence with a "why irreducible" justification.

### Axioms
1. [Axiom] — [Why this cannot be further decomposed]
2. [Axiom] — [Why this is provably true]
3. [Axiom] — [Why violating this causes failure]

> Deep methodology: `references/axiom-based-reasoning.md`

Phase 1: Identify the Problem's Essence

Strip away implementation details to find the core problem.

1. **State the problem clearly** — What exactly needs to be solved? 2. **Separate symptoms from causes** — Is this the real problem or a manifestation? 3. **Define success criteria** — What would a perfect solution achieve? (Measurable.)

**Key questions:**

• What is the fundamental job to be done here?
• If this system/process didn't exist, what would we actually need?
• What outcome matters, independent of how we get there?

**Gate**: Must produce a one-sentence problem statement + measurable success criteria.

Phase 2: Surface and Challenge All Assumptions

This is the highest-leverage phase. Most "best practices" are assumptions disguised as facts.

1. **List explicit assumptions** — What are we taking as given? 2. **Surface implicit assumptions** — What conventions are we following without questioning? 3. **Test each against axioms** — Is this actually a constraint (traces to axiom), or just how it's always been done?

**Minimum**: Produce an assumption table with ≥5 rows.

| Assumption | Why Question It | Axiom(s) Used | Verdict | |------------|----------------|---------------|---------| | "We need X" | [Challenge] | A1, A2 | Keep / Discard / Modify |

**Red flags (likely false assumptions):**

• "We've always done it this way"
• "Industry standard says..."
• "Everyone uses X for this"
• "That's too simple to work"

**Depth standard**: Each row must include *why* you're questioning it and *which axiom* informs the verdict. "Maybe not needed" without reasoning = not deep enough.

**Gate**: ≥5 assumptions challenged with verdicts. Each verdict must reference at least one axiom.

> Deep methodology: `references/axiom-based-reasoning.md` § "Identify and Challenge Assumptions"

Phase 3: Establish Ground Truths

From the wreckage of challenged assumptions, identify what IS irreducibly true for this specific problem.

**Ground Truth test:**

• Can this be further decomposed? → If yes, decompose it.
• Is this provably true, not just commonly believed? → If unsure, it's still an assumption.
• Would violating this definitely cause failure? → If not, it's a preference.

**Gate**: Must produce ≥3 ground truths. Each must be specific and falsifiable — not generic truisms.

❌ "Users need fast response times" (too vague)
✅ "P99 latency must be < 200ms per SLA contract §3.2" (specific, verifiable)

❌ "The team is small" (relative)
✅ "Team is 3 engineers, no new hires possible before Q3" (concrete constraint)

Phase 4: Reason Upward

Build solutions from ground truths only. Each layer must justify its existence.

Ground Truth → Minimal Solution → Justified Additions → Final Design
     ↑              ↑                    ↑
  (proven)     (sufficient)        (each