When planning work where optimism may be hiding risks, ask "how would I guarantee this fails?" — enumerate failure paths, then turn the top ones into explicit requirements to avoid.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/thinking-inversion
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
When planning work where optimism may be hiding risks, ask "how would I guarantee this fails?" — enumerate failure paths, then turn the top ones into explicit requirements to avoid.
📊 Stats
Stars863
Forks126
LanguageJavaScript
LicenseMIT
📦 Ships with thinking-skills
</> SKILL.md
thinking-inversion.SKILL.md
---name: thinking-inversion
description: When planning work where optimism may be hiding risks, ask "how would I guarantee this fails?" — enumerate failure paths, then turn the top ones into explicit requirements to avoid.
---# Inversion Thinking
> **Redirect:** For most risk-anticipation work, prefer `thinking-pre-mortem` — it produces a narrative prospective-hindsight pass that surfaces richer, more specific failure causes than a generic checklist. Use inversion only as a quick failure-mode enumeration on a scoped feature/design; for full plans, launches, or strategic decisions, pre-mortem is the stronger tool.
## Trigger Card
When planning a scoped feature or design where optimism may be hiding risks:
1. **State the goal clearly.**
2. **Ask: "How would I guarantee this fails?"** — list 10+ concrete failure paths.
3. **Convert the top 3-5 into explicit avoidance requirements.** (e.g., "No plaintext passwords" → "Use bcrypt with work factor ≥ 12")
4. **Verify the plan addresses each.**
Skip if the task is small/reversible or if failure modes are already well-covered by existing checks. For full plans or launches, use `thinking-pre-mortem` instead.
## Overview
Inversion thinking, championed by Charlie Munger and rooted in mathematician Carl Jacobi's principle "Invert, always invert," approaches problems by considering their opposite. Instead of asking "How do I succeed?", ask "How would I guarantee failure?" then avoid those paths.
**Core Principle:** "All I want to know is where I'm going to die, so I'll never go there." — Charlie Munger
- Identifying risks that optimistic thinking obscures
- Stuck on how to achieve a positive outcome
- Need to challenge assumptions in a plan
- Writing requirements or acceptance criteria
Decision flow:
```
Have a goal? → yes → Can you list ways to achieve it? → maybe → INVERT FIRST
↘ no → Definitely invert
↘ no → Define goal, then invert
```
## When NOT to Use
- **You're planning a full launch, project, or strategic decision.** Use `thinking-pre-mortem` instead — it produces a narrative prospective-hindsight pass that surfaces richer, more specific failure causes than a checklist enumeration. Inversion is the lighter, faster tool; pre-mortem is the deeper one.
- The task is small/reversible and failure is cheap — just do it and fix forward.
- You'd only produce generic boilerplate failure modes ("no tests", "poor naming") that don't apply here; skip if nothing specific surfaces.
- The failure modes are already well-covered by existing checks (CI, lint, type system); don't re-enumerate what's enforced.
## The Process
### Step 1: Define the Goal Clearly
State what success looks like:
```
Goal: "Ship a reliable authentication system by Q2"
Goal: "Build a high-performing engineering team"
Goal: "Launch product with strong user retention"
```
### Step 2: Invert — Ask "How Would I Fail?"
List all ways to guarantee failure, ruin, or the opposite of your goal:
```
Goal: Ship reliable auth system
Inversions (How to guarantee failure):
- Skip security review and pen testing
- No rate limiting or brute force protection
- Store passwords in plaintext
- No monitoring or alerting
- Skip edge cases in testing
- No documentation for on-call
- Single point of failure, no redundancy
- Ignore compliance requirements
- No rollback plan
- Deploy on Friday before vacation
```
### Step 3: Categorize the Failure Modes
Group by type and severity:
| Category | Failure Mode | Severity |
|----------|--------------|----------|
| Security | Plaintext passwords | Critical |
| Security | No rate limiting | High |
| Operations | No monitoring | High |
| Operations | No rollback plan | High |
| Process | Skip security review | Critical |
| Process | No documentation | Medium |
| Reliability | Single point of failure | High |
### Step 4: Convert to Avoidance Checklist
Transform each failure mode into a requirement:
```
Anti-goal: Store passwords in plaintext
→ Requirement: Use bcrypt/argon2 with appropriate work factor
Anti-goal: No rate limiting
→ Requirement: Implement rate limiting with exponential backoff
Anti-goal: Deploy Friday before vacation
→ Requirement: No deploys within 48h of team unavailability
```
### Step 5: Prioritize by Impact
Focus on avoiding the failures that would be:
- Most damaging if they occurred
- Most likely to occur without explicit prevention
- Hardest to recover from
## Application Patterns
### For Technical Design
```
Goal: Build scalable API
Invert: How to make it fail under load?
- No caching → Add caching layer
- Synchronous everything → Add async where appropriate
- No connection pooling → Implement pooling
- N+1 queries → Eager loading, query optimization
- No circuit breakers → Add circuit breakers
```
### For Code Review
```
Goal: Merge high-quality code
Invert: What would make this PR problematic?
- Introduces security vulnerability
- Breaks existing functionality
- No tests for new behavior
- Unclear intent/poor naming
- Performance regression
- Missing error handling
```
### For Career/Team Building
```
Goal: Build successful engineering career
Invert (Munger's list of what to avoid):
- Be unreliable
- Learn only from your own mistakes (ignore others')
- Give up after first failure
- Be resentful and envious
- Stay within comfort zone
- Avoid difficult conversations
- Don't learn continuously
```
### For Project Planning
```
Goal: Successful product launch
Invert: How to guarantee launch failure?
- No user research → Validate with users
- No load testing → Load test before launch
- No rollback capability → Build rollback
- No success metrics defined → Define metrics upfront
- Team burnout → Sustainable pace
- No communication plan → Prepare stakeholder comms
| Team | High performance | Poor communication, no psychological safety, unclear goals |
## Verification Checklist
- [ ] Goal clearly defined
- [ ] Listed 10+ ways to fail/achieve opposite
- [ ] Categorized failures by type and severity
- [ ] Converted top failures to explicit requirements
- [ ] Verified plan addresses the most critical inversions
- [ ] Re-checked the top inversions against the actual design for blind spots
## Key Questions
- "What would guarantee failure here?"
- "What mistakes do others commonly make?"
- "What am I most likely to overlook?"
- "If this fails spectacularly, what will the postmortem say?"
- "What would I tell someone else to avoid?"
- "What would the opposite of success look like, specifically?"
## Munger's Warning
"It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent."
The power of inversion is in avoiding obvious errors that optimism blinds us to. Simple avoidance often beats clever optimization.
