Help us improve
Share bugs, ideas, or general feedback.
From thinking-skills
Enumerates failure modes by inverting goals to uncover hidden risks during planning. Useful when optimism may obscure failure paths.
npx claudepluginhub tjboudreaux/cc-thinking-skills --plugin thinking-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/thinking-skills:thinking-inversionThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **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.
Solves problems by reasoning backward from failure — enumerates causes of failure, scores them, then eliminates them. Useful for stress-testing plans and surfacing hidden risks.
Performs pre-mortem analysis imagining catastrophic failures for uncommitted plans or existing systems via parallel lenses, yielding prioritized risk registers with early warnings.
Runs a pre-mortem analysis: assumes a plan has already failed and reasons backward to surface concrete risks. Use before committing to major decisions or launches.
Share bugs, ideas, or general feedback.
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.
When planning a scoped feature or design where optimism may be hiding risks:
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.
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
Decision flow:
Have a goal? → yes → Can you list ways to achieve it? → maybe → INVERT FIRST
↘ no → Definitely invert
↘ no → Define goal, then invert
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.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"
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
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 |
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
Focus on avoiding the failures that would be:
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
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
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
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
Inversion + Pre-Mortem creates powerful risk identification:
| Domain | Goal | Key Inversions to Avoid |
|---|---|---|
| Security | Secure system | Trusting user input, weak auth, exposed secrets |
| Performance | Fast system | No caching, blocking calls, no indexes |
| Reliability | Stable system | No monitoring, no redundancy, no graceful degradation |
| Maintainability | Clean code | No tests, cryptic names, tight coupling |
| Team | High performance | Poor communication, no psychological safety, unclear goals |
"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.