Solve problems by thinking backwards. Use when forward thinking is stuck, you need to identify risks, or find non-obvious solutions. Not for straightforward implementation tasks or simple bug fixes.
Solve problems by working backwards - think about what guarantees failure, then avoid those things.
Apply inversion by:
Key Innovation: Finding non-obvious solutions by approaching from the opposite direction. Often easier to agree on what causes failure than what causes success.
Use this approach when:
Recognition test: "Is forward thinking stuck?" If solutions aren't emerging, invert the problem.
Original Goal: [What you want to achieve]
Inverted Problem: How do I guarantee FAILURE?
Failure Modes:
1. [What would definitely cause failure]
2. [Another guaranteed way to fail]
3. [Third way to ensure failure]
Success Strategies:
1. [Avoid failure mode 1] → [Success strategy]
2. [Avoid failure mode 2] → [Success strategy]
3. [Avoid failure mode 3] → [Success strategy]
Instead of trying to be brilliant, avoid being stupid:
Think about the opposite of what you want:
Original Goal: How do we create a great user onboarding experience?
Inverted: How do we make users hate our onboarding?
Failure Modes:
Success Strategies (Inverted):
Original Goal: How do we deliver projects on time?
Inverted: How do we guarantee late delivery?
Failure Modes:
Success Strategies (Inverted):
Original Goal: How do we make our system reliable?
Inverted: How do we guarantee system failures?
Failure Modes:
Success Strategies (Inverted):
Original Goal: How do we build a great team culture?
Inverted: How do we make talented people quit?
Failure Modes:
Success Strategies (Inverted):
After analysis, produce structured output:
# Inversion Analysis: [Goal]
## Original Goal
[What you want to achieve]
## Inverted Problem
[How to guarantee the opposite - failure]
## Guaranteed Failure Strategies
1. [Strategy that would cause failure]
2. [Another way to ensure failure]
3. [Third way to guarantee failure]
## Success Strategies (Inverted)
1. **Avoid [failure 1]**
→ [Success strategy derived from avoiding failure]
2. **Avoid [failure 2]**
→ [Success strategy derived from avoiding failure]
3. **Avoid [failure 3]**
→ [Success strategy derived from avoiding failure]
## Key Insights
- [Non-obvious insight from backward thinking]
- [Another insight]
## Immediate Actions
1. [First action based on inverted strategy]
2. [Second action]
Before inversion:
During inversion:
After inversion:
❌ Wrong: Inversion that's just the opposite of good ideas (not genuine failure modes) ✅ Correct: Think about genuine, realistic ways to fail
❌ Wrong: Inverting failures that don't actually happen ✅ Correct: Focus on realistic failure modes from experience
❌ Wrong: Using inversion alone without forward thinking ✅ Correct: Combine inversion with forward thinking for complete picture
Easier to agree on failure: People often disagree on "best" approach but agree on "worst" approach
Uncovers hidden assumptions: Thinking about failures reveals risks that forward thinking misses
Less cognitive bias: Forward thinking is prone to optimism bias; inversion is naturally skeptical
Complete perspective: Combining forward and backward thinking gives fuller picture
"Invert, always invert." - Carl Jacobi (mathematician)
"Tell me where I'm going to die so I never go there." - Charlie Munger
"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." - Charlie Munger
Trust intelligence - Inversion is powerful because failure is often more obvious than success. Start with what you know doesn't work.
<critical_constraint> MANDATORY: Identify genuine failure modes (not just opposites of good ideas) MANDATORY: Focus on realistic, actionable failure modes from experience MANDATORY: Combine inversion with forward thinking for complete analysis MANDATORY: Derive actionable strategies from avoiding each failure No exceptions. Inversion without genuine failure modes is wasted effort. </critical_constraint>
This component carries essential Seed System principles for context: fork isolation:
<critical_constraint> MANDATORY: All components MUST be self-contained (zero .claude/rules dependency) MANDATORY: Achieve 80-95% autonomy (0-5 AskUserQuestion rounds per session) MANDATORY: Description MUST use What-When-Not format in third person MANDATORY: No component references another component by name in description MANDATORY: Progressive disclosure - references/ for detailed content MANDATORY: Use XML for control (mission_control, critical_constraint), Markdown for data No exceptions. Portability invariant must be maintained. </critical_constraint>
Delta Standard: Good Component = Expert Knowledge − What Claude Already Knows
Recognition Questions: