Trellis first-principles-thinking
git clone https://github.com/mindfold-ai/Trellis
T=$(mktemp -d) && git clone --depth=1 https://github.com/mindfold-ai/Trellis "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/first-principles-thinking" ~/.claude/skills/mindfold-ai-trellis-first-principles-thinking && rm -rf "$T"
.claude/skills/first-principles-thinking/SKILL.mdFirst 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.
- State the problem clearly — What exactly needs to be solved?
- Separate symptoms from causes — Is this the real problem or a manifestation?
- 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.
- List explicit assumptions — What are we taking as given?
- Surface implicit assumptions — What conventions are we following without questioning?
- 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:
§ "Identify and Challenge Assumptions"references/axiom-based-reasoning.md
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 defended)
- Start minimal — What's the simplest thing that satisfies all ground truths?
- Add only what's necessary — Each addition must reference a ground truth or axiom.
- Challenge each layer — Does this layer earn its complexity?
Gate: Must produce a reasoning chain where every step traces to a ground truth.
### Reasoning Chain GT#1 (latency < 200ms) + GT#3 (3-person team) → Eliminate distributed architecture GT#2 (read-heavy 95%) + GT#1 → Add read cache with 30s TTL → Conclusion: Monolith + in-memory cache
Phase 5: Validate and Stress-Test
Ensure the reasoning is sound before acting.
Three validation questions (Completion Gate):
| # | Question | What Failure Means |
|---|---|---|
| 1 | Can every conclusion trace back to a ground truth? (Traceability) | You've introduced unjustified assumptions in Phase 4 |
| 2 | Is every ground truth covered by at least one conclusion? (Completeness) | Your solution ignores a constraint — it will fail there |
| 3 | Were any phases skipped or done shallowly? (Honesty) | Go back and finish them |
Stress-test with complementary models:
| Model | Question to Ask | When It Adds Value |
|---|---|---|
| Pre-Mortem | "It's 12 months later and this failed. Why?" | When you're excited about the solution |
| Second-Order | "If this works, what happens next? And after that?" | When solution has systemic effects |
| Inversion | "What would guarantee failure? Are we doing any of that?" | When you need to find blind spots |
| OODA Act | "What's the smallest test we can run right now?" | When analysis paralysis sets in |
Full model toolkit:
references/thinking-models-toolkit.md
Gate: All 3 validation questions answered "yes". At least one stress-test model applied.
Reasoning Discipline Protocol
Problem: AI tends to skip steps, get distracted mid-analysis, or do each step shallowly.
Phase Gates (Mandatory Artifacts)
| Phase | Must Produce | Min Depth |
|---|---|---|
| 0: Frame | ≥3 axioms with justifications | Each axiom: 1 sentence + why irreducible |
| 1: Essence | Problem statement + success criteria | Specific and measurable |
| 2: Assumptions | Assumption table ≥5 rows | Each row: challenge + axiom reference + verdict |
| 3: Ground Truths | ≥3 ground truths | Each: specific, falsifiable, not a truism |
| 4: Reason Up | Reasoning chain with GT references | Every step traces to a GT |
| 5: Validate | 3 validation answers + 1 stress test | All answers = "yes" |
No artifact → no next phase. If a gate is not met, stop and complete it.
Progress Tracker (Anti-Drift)
Maintain a running checklist throughout the analysis. After each phase completion, output:
## 🧭 FP Progress - [x] Phase 0: Frame — ✅ 3 axioms - [x] Phase 1: Essence — ✅ "..." - [→] Phase 2: Assumptions — 3/6 checked - [ ] Phase 3: Ground Truths - [ ] Phase 4: Reason Upward - [ ] Phase 5: Validate
If conversation drifts (user asks a tangent, discussion expands on a side topic), after addressing it, immediately output:
📍 Returning to FP analysis: Phase N has M items remaining. Continuing.
Depth Standards (Anti-Shallow)
| Phase | Shallow (Fail) | Deep (Pass) |
|---|---|---|
| Assumptions | "Maybe we don't need this" | Table row with challenge reason + axiom reference + verdict |
| Ground Truths | "Users want fast" | "P99 < 200ms per SLA §3.2" |
| Reasoning | "So we should use X" | "GT#2 + GT#3 → eliminates Y → X is minimal solution" |
Trellis Integration
When used within a Trellis-managed project, the analysis artifacts integrate with the task system.
File Placement
.trellis/tasks/{MM-DD-slug}/ ├── task.json # Existing ├── prd.md # Existing — FP feeds into this ├── fp-analysis.md # ← FP analysis output (Phases 0-5) ├── fp-progress.md # ← Phase progress tracker (anti-drift) ├── implement.jsonl # Existing — fp-analysis.md auto-added ├── check.jsonl # Existing — fp-analysis.md auto-added └── ...
Brainstorm Integration
During
/trellis:brainstorm, when the task is classified as "Complex":
- Trigger: User says "从第一性原理分析" or AI detects the problem has ≥3 unvalidated assumptions
- Execute: Run Phases 0-3, saving output to
in task directoryfp-analysis.md - Feed into PRD:
- Ground Truths → PRD Requirements and Constraints
- Assumption Table → PRD Technical Notes / Trade-offs
- Reasoning Chain → PRD Technical Design or
info.md
- Continue: Phases 4-5 inform implementation decisions
Context Injection
After FP analysis completes, add to context files:
python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "fp-analysis.md" "Ground truths and reasoning chain" python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "fp-analysis.md" "Verify implementation traces to ground truths"
Completion Recording
After Phase 5, update
task.json:
{ "fp_analysis": { "completed": true, "axioms_count": 3, "assumptions_challenged": 6, "ground_truths_count": 5, "validation_passed": true } }
Output Format
When applying first principles thinking, structure the final output as:
## First Principles Analysis: [Topic] ### Axioms 1. [Axiom 1] — [Why irreducible] 2. [Axiom 2] — [Why irreducible] 3. [Axiom 3] — [Why irreducible] ### Problem Essence **Core problem:** [One sentence] **Success criteria:** [Measurable outcomes] ### Assumptions Challenged | Assumption | Challenge | Axiom(s) | Verdict | |------------|-----------|----------|---------| | ... | ... | A1, A2 | Keep/Discard/Modify | ### Ground Truths 1. [Specific, falsifiable fact] 2. [Specific, falsifiable fact] 3. [Specific, falsifiable fact] ### Reasoning Chain GT#1 + GT#3 → [Inference] → [Step] → [Conclusion] ### Conclusion **Recommended approach:** [Description] **Key insight:** [What FP analysis revealed that convention missed] **Trade-offs acknowledged:** [What we accept and why] ### Validation - [x] Every conclusion traces to a ground truth - [x] Every ground truth is covered - [x] No phases skipped - [x] Stress-tested with: [model name]
Common Traps
The Complexity Trap
Symptom: Solution is more complex than the problem warrants. FP Check: Remove one component — does it still solve the core problem? If yes, that component wasn't essential. Repeat.
The Analogy Trap
Symptom: "Company X does it this way, so we should too." FP Check: What problem was Company X solving? Is ours identical in all relevant dimensions? What constraints differ?
The Legacy Trap
Symptom: Maintaining compatibility with decisions that no longer serve us. FP Check: What was the original reason? Do those conditions still exist? What's the true cost of change vs. cost of maintaining?
More patterns and case studies:
references/case-studies.md
Complementary Tools Quick Reference
| Tool | Key Question | Best Combined With Phase |
|---|---|---|
| Inversion | "What guarantees failure?" | Phase 2 (find hidden assumptions) |
| Second-Order | "Then what? And then?" | Phase 5 (stress-test conclusions) |
| 5 Whys | "Why? Why? Why? Why? Why?" | Phase 1 (find real problem) |
| Pre-Mortem | "It failed. Why?" | Phase 5 (stress-test) |
| OODA Loop | "What's the smallest test?" | Phase 5 (move to action) |
| Via Negativa | "What should we remove?" | Phase 4 (simplify solution) |
| Bayesian Update | "What new evidence changes this?" | Phase 3 (validate ground truths) |
| Reversibility Filter | "One-way or two-way door?" | Phase 4 (calibrate decision depth) |
Full toolkit with examples:
references/thinking-models-toolkit.md
Bias Awareness
The 5 most dangerous biases for first-principles analysis:
| Bias | How It Corrupts FP | Quick Debias |
|---|---|---|
| Confirmation | You "find" ground truths that confirm your preferred solution | Seek disconfirming evidence first |
| Anchoring | Conventional approach becomes mental anchor even when thinking "fresh" | Generate 3 alternatives before evaluating |
| Sunk Cost | Legacy decisions feel like ground truths | "If starting from zero today, would we choose this?" |
| Status Quo | "How it works now" feels like a constraint when it's a choice | Separate true constraints from current choices |
| Overconfidence | Treat assumptions as ground truths without testing | Assign confidence % to each assumption |
Full 12-bias catalog with debiasing:
references/bias-and-debiasing.md
Problem Decomposition
Before applying FP to a complex problem, you may need to decompose it first. Quick selection:
| Problem Type | Best Framework |
|---|---|
| Diagnostic (why is X happening?) | Issue Tree or Fishbone |
| Financial (revenue/cost) | Profitability Tree |
| Strategic (what should we do?) | Hypothesis Tree |
| Operational (what's broken?) | Process Flow + 5 Whys |
| Complex adaptive system | Systems Map |
Full 15-framework catalog:
references/decomposition-frameworks.md
Reference Files
| File | Content | When to Read |
|---|---|---|
| Deep methodology for establishing axioms, challenging assumptions, and deriving conclusions | When you need rigorous derivation, not just analysis |
| 4-quadrant framework + 12 mental models + model selection guide + 5 Whys deep dive | When you need complementary thinking tools |
| 5 software engineering cases + 2 SpaceX/Tesla cases + templates | When you want concrete examples of FP in action |
| 12 cognitive biases that corrupt FP thinking + debiasing strategies | When validating your analysis for blind spots |
| 15 problem decomposition methods (MECE, Issue Tree, etc.) | When the problem is too big to analyze directly |