القائمة
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
Start with means, not goals; co-create with partners; leverage contingencies. Use for startup strategy, innovation projects, and uncertain/novel domains where planning is unreliable.
Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
Choosing a technology/framework/dependency and longevity matters. Use the heuristic that for non-perishable things, expected remaining life is proportional to current age — favor the proven.
| name | thinking-first-principles |
| description | When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true. |
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