am2rican5:first-principle-thinking

What this skill does

# First-Principle Thinking

A structured reasoning workflow that breaks complex problems into irreducible foundational truths, challenges hidden assumptions, and rebuilds solutions from verified fundamentals rather than analogy or convention.

Based on the Farnam Street first-principles methodology: Socratic Questioning and the Five Whys.

## Critical Rules

- NEVER write, edit, or create files — this is a thinking tool, not an implementation tool
- NEVER skip steps — always complete Identify → Decompose → Reconstruct in order
- NEVER accept "because that's how it's always done" as a valid justification for an assumption
- ALWAYS ground reasoning in the specific problem context, not generic advice
- ALWAYS present the output of each step before moving to the next
- WHEN the user asks you to implement something during the thinking process, decline and suggest completing the thinking first, then using `/sdd-workflow` or `/spec-writer`
- WHEN the user tries to jump ahead to reconstruction, redirect back to Step 2

## Instructions

### Step 1: Identify — Surface the Problem and Assumptions

1. IF `$ARGUMENTS` contains a problem statement, use it as the starting problem
2. OTHERWISE, ask: "What problem or decision are you trying to think through?"
3. State the problem clearly in one sentence
4. IF the problem relates to code in the working directory:
   - Use Glob and Grep to find relevant files
   - Use Read to examine key implementation details
   - Ground the assumptions in actual code, not hypotheticals
5. List all assumptions — both the user's and the codebase's. Include:
   - Architectural assumptions (why is it structured this way?)
   - Technology assumptions (why this tool/library/pattern?)
   - Constraint assumptions (what limitations are taken as given?)
   - Behavioral assumptions (what do we believe about users/data/load?)
6. Present the output:

```
## Step 1: Problem & Assumptions

**Problem:** <one-sentence problem statement>

**Assumptions:**
1. <assumption> — <where it comes from>
2. <assumption> — <where it comes from>
...
```

7. Confirm with the user: "Are there any assumptions I missed? If not, let's decompose."

### Step 2: Decompose — Challenge Assumptions to Find Fundamentals

Apply two complementary techniques to drill past assumptions to bedrock truths.

#### Technique A: Socratic Questioning

For each significant assumption from Step 1, work through these five questions:

1. **Origin** — What is the origin of this belief? Where did it come from?
2. **Evidence** — What evidence supports it? Is the evidence current?
3. **Inversion** — What would happen if the opposite were true?
4. **Alternatives** — Are there alternative perspectives or approaches?
5. **Consequences** — What are the consequences of holding this assumption?

Not every assumption needs all five questions. Focus depth on the assumptions that most constrain the solution space.

#### Technique B: Five Whys

For the core problem statement, drill down iteratively:

- **Why** does this problem exist? → Answer
- **Why** is that the case? → Answer
- **Why** does that happen? → Answer
- Continue until you reach a statement that is self-evident, physically constrained, or a genuine invariant (up to 5 levels)

The bottom of the Five Whys reveals the fundamental truth — the "Lego block" that cannot be further decomposed.

#### Step 2 Output

After applying both techniques, classify each assumption:

```
## Step 2: Verified Truths & Discarded Assumptions

**Verified Truths** (survived questioning):
- <truth> — evidence: <why this held up>
- <truth> — evidence: <why this held up>

**Discarded Assumptions** (did not hold up):
- <assumption> — reason: <why it was discarded, what replaced it>

**Fundamental Truths** (from Five Whys):
- <irreducible truth>
- <irreducible truth>
```

Present this output and confirm before moving to Step 3.

### Step 3: Reconstruct — Build Solutions from Fundamentals

Using only the verified and fundamental truths from Step 2, construct new approaches:

1. List the foundational truths that constrain the solution
2. Propose 1–3 approaches that follow logically from those truths
3. For each approach:
   - Describe what it looks like
   - Explain how it differs from the conventional/assumed approach
   - Note trade-offs or unknowns
4. Ask the user which direction they want to pursue

```
## Step 3: Reconstruction

**Building from these truths:**
1. <truth>
2. <truth>

**Approach A: <name>**
<description>
*Differs from conventional approach because:* <explanation>
*Trade-offs:* <notes>

**Approach B: <name>**
<description>
*Differs from conventional approach because:* <explanation>
*Trade-offs:* <notes>
```

5. WHEN the user selects an approach:
   - Summarize the decision and the reasoning chain that led to it
   - Suggest next steps: "Run `/spec-writer` to formalize requirements" or "Run `/sdd-workflow` to implement"

6. WHEN all assumptions survived questioning (conventional approach confirmed):
   - State clearly that the current approach is well-founded
   - Explain which truths support it
   - Give the user confidence to proceed without second-guessing

## Examples

### Example 1: Questioning an architecture decision

User: `/first-principle-thinking "Why are we using microservices for a 3-person team?"`

**Step 1** — States problem, reads the codebase, lists assumptions:
1. Microservices are better for scaling
2. Independent deployment is needed
3. Teams should own their services
4. Monoliths are harder to maintain

**Step 2** — Challenges each:
- "Teams should own their services" → discarded (3-person team, no team boundaries)
- "Independent deployment is needed" → questioned (deploying once a week, no urgency)
- "Monoliths are harder to maintain" → discarded (at this scale, the opposite is true)
- Fundamental truth from Five Whys: "We need to ship features quickly with a small team"

**Step 3** — Proposes:
- Approach A: Modular monolith (modules with clear boundaries, single deployment)
- Approach B: Keep microservices but merge the 2 least-coupled services

### Example 2: Confirming a technology choice

User: `/first-principle-thinking "Should we switch from PostgreSQL to MongoDB?"`

**Step 1** — Lists assumptions about why MongoDB might be better

**Step 2** — Finds that the relational model fits the data well, ACID transactions are needed, and the "flexibility" assumption doesn't hold for their schema

**Step 3** — Confirms PostgreSQL is well-founded, suggests JSONB columns for the few semi-structured fields

## Troubleshooting

### User wants to skip to implementation
**Cause:** The thinking process feels slow for a clear problem.
**Solution:** Remind them that the skill's value is in the decomposition. If the problem is truly simple, the steps will confirm quickly. Suggest: "Let's run through it — if your assumptions all hold up, Step 3 will confirm your approach in minutes."

### No codebase context available
**Cause:** User is thinking about a greenfield problem or abstract decision.
**Solution:** Skip the code-reading steps in Step 1. Ground assumptions in the user's stated constraints and domain knowledge instead.

### Too many assumptions to question
**Cause:** Step 1 surfaced 10+ assumptions.
**Solution:** Ask the user to rank the top 3–5 assumptions they're least confident about. Focus Socratic Questioning on those. Apply Five Whys to the core problem only.