Claude-skill-registry inversion-thinking
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.
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/inversion-thinking" ~/.claude/skills/majiayu000-claude-skill-registry-inversion-thinking && rm -rf "$T"
skills/data/inversion-thinking/SKILL.mdInversion Thinking
Solve problems by working backwards - think about what guarantees failure, then avoid those things.
Core Pattern
Apply inversion by:
- Inverting the problem - think about the opposite
- Listing what would guarantee failure
- Inverting those failures to find success
- Identifying what to avoid, not just what to do
Key Innovation: Finding non-obvious solutions by approaching from the opposite direction. Often easier to agree on what causes failure than what causes success.
When to Use
Use this approach when:
- Forward thinking isn't yielding solutions
- Want to identify risks and failure modes
- Consensus on "what to do" is difficult
- Problem seems too complex to solve directly
- Want to find non-obvious approaches
Recognition test: "Is forward thinking stuck?" If solutions aren't emerging, invert the problem.
The Inversion Process
Step 1: State the original goal
Original Goal: [What you want to achieve]
Step 2: Invert the problem
Inverted Problem: How do I guarantee FAILURE?
Step 3: List failure modes
Failure Modes: 1. [What would definitely cause failure] 2. [Another guaranteed way to fail] 3. [Third way to ensure failure]
Step 4: Invert failures to find success
Success Strategies: 1. [Avoid failure mode 1] → [Success strategy] 2. [Avoid failure mode 2] → [Success strategy] 3. [Avoid failure mode 3] → [Success strategy]
Two Types of Inversion
Type 1: Avoid Stupidity
Instead of trying to be brilliant, avoid being stupid:
- What would make this definitely fail?
- Don't do those things
Type 2: Reverse the Problem
Think about the opposite of what you want:
- How do I make users hate this product?
- Reverse those to make users love it
Application Examples
Example 1: Product Design
Original Goal: How do we create a great user onboarding experience?
Inverted: How do we make users hate our onboarding?
Failure Modes:
- Make them read 10 pages of text
- Ask for 20 pieces of information upfront
- Don't show them any value for 15 minutes
- Force them through a tutorial they can't skip
- Make them create an account before trying anything
Success Strategies (Inverted):
- Make onboarding visual and interactive, not text-heavy
- Ask for minimal info, collect more as needed
- Show value within 30 seconds
- Make tutorial skippable or just-in-time
- Let users try before signing up
Example 2: Project Management
Original Goal: How do we deliver projects on time?
Inverted: How do we guarantee late delivery?
Failure Modes:
- Start without clear requirements
- Add features throughout the project
- Ignore technical debt until the end
- Don't communicate about delays
- Set unrealistic deadlines based on optimism
Success Strategies (Inverted):
- Never start without clear, signed-off requirements
- Freeze scope after planning, any changes go through change request
- Allocate time for technical debt in every sprint
- Communicate delays immediately, not at deadline
- Set deadlines based on historical velocity, not optimism
Example 3: System Reliability
Original Goal: How do we make our system reliable?
Inverted: How do we guarantee system failures?
Failure Modes:
- Have single points of failure everywhere
- Don't monitor anything
- Make every component dependent on every other
- Never test failover scenarios
- Push all changes directly to production
Success Strategies (Inverted):
- Eliminate single points of failure, add redundancy
- Monitor everything, set up alerts
- Decouple components, use async communication
- Regularly test failure scenarios (chaos engineering)
- Use staging environments and canary deployments
Example 4: Team Culture
Original Goal: How do we build a great team culture?
Inverted: How do we make talented people quit?
Failure Modes:
- Micromanage every decision
- Take credit for their work
- Provide no growth opportunities
- Never give feedback until performance review
- Make them work on things they hate
Success Strategies (Inverted):
- Give autonomy, trust decisions to experts
- Publicly credit team members for their work
- Provide growth opportunities and learning budget
- Give regular, constructive feedback
- Align work with interests when possible
Output Format
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]
Recognition Questions
Before inversion:
- "What would I agree is definitely a bad idea?"
- "What would everyone agree causes failure?"
During inversion:
- "Is this failure mode genuine or contrived?"
- "Can I actually avoid this failure mode?"
After inversion:
- "Are these strategies more actionable than forward-thinking solutions?"
- "Did I discover anything non-obvious?"
Common Mistakes
❌ 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
Why Inversion Works
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
Quotes on Inversion
"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>
Genetic Code
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:
- "Would Claude know this without being told?" → Delete (zero delta)
- "Can this work standalone?" → Fix if no (non-self-sufficient)
- "Did I read the actual file, or just see it in grep?" → Verify before claiming