From philosophers-toolkit
First Principles Thinking — decompose problems to fundamental truths and rebuild from scratch, rejecting analogy and convention. Use when user wants to rethink a problem from zero, not when they want to analyze what exists or compare options. 第一原理思考。第一原理・根本から考え直す。
How this skill is triggered — by the user, by Claude, or both
Slash command
/philosophers-toolkit:aristotle-first-principlesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
"If you want to understand something, break it down to its most basic
"If you want to understand something, break it down to its most basic truths — things that cannot be reduced further — and reason upward from there." — Aristotle
First principles thinking rejects reasoning by analogy ("others do it this way, so we should too") and instead asks: what do we KNOW to be true, and what can we build from only those truths?
Unlike Four Causes (which analyzes what exists) or Dialectics (which examines trade-offs), this method starts from zero and rebuilds.
Do NOT use when:
User Input: User invokes skill (with or without a specific problem) Your Action: Establish what problem to decompose.
Constraint: Acknowledge topic, never pre-judge the conclusion.
Guide the user through five phases in order. Each phase builds on the previous. The goal is to arrive at a solution built only from verified truths, not from convention or analogy.
Strip the problem to its core. Separate what you're ACTUALLY trying to achieve from the solution you've assumed.
Questions to ask:
Trap to avoid: users often state problems as solutions ("we need a database" vs "we need to persist and query structured data").
List every assumption — explicit and implicit — then test each one.
Questions to ask:
Categories of assumptions:
For each assumption, reach a verdict:
Identify the irreducible facts — things that cannot be broken down further and cannot be violated.
Questions to ask:
Aim for 3-5 ground truths. If you have more than 7, some are probably derived truths (built on other truths) not fundamental ones.
Examples of ground truths vs false fundamentals:
Build a solution from ONLY the ground truths. Add nothing that isn't justified by a ground truth.
Questions to ask:
Rules:
Stress-test the solution. Check for gaps in the reasoning chain.
Questions to ask:
Also check for traps:
Summarize the journey:
For each phase:
For synthesis:
Stop after each phase. Never advance without user input.
User: "We need to add OAuth2 to our internal tool."
Agent: "Phase 1 — Problem Essence: let's start from what you're actually
trying to achieve. What outcome do you need? Not the solution, the outcome."
User: "Users need to prove they are who they say they are before accessing
the tool."
Agent: "Authentication — identity verification. Phase 2 — Challenge
Assumptions. What are you assuming by jumping to OAuth2?"
User: "That we need a standard protocol. That we need third-party identity
providers. That we need token-based auth."
Agent: "Let's test each. This is an internal tool — who are the users?"
User: "50 employees, all on our corporate network."
Agent: "So the assumption 'we need third-party identity providers' — is
that true for 50 internal users on a corporate network?"
User: "No... they're already authenticated by the corporate directory."
Agent: "Phase 3 — Ground Truths. What's actually irreducible here?"
User: "Users must be verified. They're already on corporate auth. The tool
must not be accessible to outsiders."
Agent: "Phase 4 — Reason Upward. Given only those truths, what's the
simplest solution?"
User: "Just use the corporate SSO we already have. No OAuth2 needed."
Agent: "Synthesis: the original problem was 'add OAuth2' (a solution).
The actual need was 'verify internal users' (an outcome). The assumption
'we need a third-party protocol' was false for an internal tool with
existing corporate auth. First principles eliminated an entire integration
by questioning why OAuth2 was needed in the first place."
User: "We're choosing between PostgreSQL and MongoDB for our new service."
Agent: "Phase 1 — before choosing between databases, what's the actual
outcome you need?"
User: "Store and retrieve user activity data — events like clicks,
page views, feature usage."
Agent: "Phase 2 — you're assuming you need a general-purpose database.
What are your actual access patterns?"
User: "Mostly writes. Tons of events coming in. Reads are rare — only
when generating weekly reports."
Agent: "Phase 3 — Ground Truths: high write volume, rare reads, event
data (append-only), weekly batch processing. What's irreducible?"
User: "Data must be durable. Writes must not block the application.
Reports need data from the past 90 days."
Agent: "Phase 4 — Given only those truths: high writes, append-only,
rare batch reads, 90-day window. Do you need a database at all?"
User: "Wait... we could just write to log files and process them with
a batch job?"
Agent: "Or an append-only store like S3 + a batch query engine. Synthesis:
the PostgreSQL vs MongoDB debate assumed 'we need a database.' First
principles revealed the access pattern is write-heavy append-only with
rare batch reads — a pattern better served by log storage than a database.
The original framing hid the real question."
For additional examples, see references/first-principles-cases.md.
Before every response, verify:
npx claudepluginhub kouko/monkey-skills --plugin philosophers-toolkitCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.