{"kind":"Skill","metadata":{"namespace":"community","name":"thinking-inversion","version":"0.1.0"},"spec":{"description":"Approach problems backward by identifying paths to failure, then systematically avoiding them. Use for risk identification, planning, and avoiding obvious mistakes.","files":{"SKILL.md":"---\nname: thinking-inversion\ndescription: Approach problems backward by identifying paths to failure, then systematically avoiding them. Use for risk identification, planning, and avoiding obvious mistakes.\n---\n\n# Inversion Thinking\n\n## Overview\nInversion 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.\n\n**Core Principle:** \"All I want to know is where I'm going to die, so I'll never go there.\" — Charlie Munger\n\n## When to Use\n- Planning a new project, feature, or initiative\n- Evaluating a decision before committing\n- Identifying risks that optimistic thinking obscures\n- Stuck on how to achieve a positive outcome\n- Need to challenge assumptions in a plan\n- Writing requirements or acceptance criteria\n\nDecision flow:\n```\nHave a goal? → yes → Can you list ways to achieve it? → maybe → INVERT FIRST\n                                                      ↘ no → Definitely invert\n           ↘ no → Define goal, then invert\n```\n\n## The Process\n\n### Step 1: Define the Goal Clearly\nState what success looks like:\n```\nGoal: \"Ship a reliable authentication system by Q2\"\nGoal: \"Build a high-performing engineering team\"\nGoal: \"Launch product with strong user retention\"\n```\n\n### Step 2: Invert — Ask \"How Would I Fail?\"\nList all ways to guarantee failure, ruin, or the opposite of your goal:\n\n```\nGoal: Ship reliable auth system\nInversions (How to guarantee failure):\n- Skip security review and pen testing\n- No rate limiting or brute force protection  \n- Store passwords in plaintext\n- No monitoring or alerting\n- Skip edge cases in testing\n- No documentation for on-call\n- Single point of failure, no redundancy\n- Ignore compliance requirements\n- No rollback plan\n- Deploy on Friday before vacation\n```\n\n### Step 3: Categorize the Failure Modes\nGroup by type and severity:\n\n| Category | Failure Mode | Severity |\n|----------|--------------|----------|\n| Security | Plaintext passwords | Critical |\n| Security | No rate limiting | High |\n| Operations | No monitoring | High |\n| Operations | No rollback plan | High |\n| Process | Skip security review | Critical |\n| Process | No documentation | Medium |\n| Reliability | Single point of failure | High |\n\n### Step 4: Convert to Avoidance Checklist\nTransform each failure mode into a requirement:\n\n```\nAnti-goal: Store passwords in plaintext\n→ Requirement: Use bcrypt/argon2 with appropriate work factor\n\nAnti-goal: No rate limiting\n→ Requirement: Implement rate limiting with exponential backoff\n\nAnti-goal: Deploy Friday before vacation\n→ Requirement: No deploys within 48h of team unavailability\n```\n\n### Step 5: Prioritize by Impact\nFocus on avoiding the failures that would be:\n- Most damaging if they occurred\n- Most likely to occur without explicit prevention\n- Hardest to recover from\n\n## Application Patterns\n\n### For Technical Design\n```\nGoal: Build scalable API\nInvert: How to make it fail under load?\n- No caching → Add caching layer\n- Synchronous everything → Add async where appropriate  \n- No connection pooling → Implement pooling\n- N+1 queries → Eager loading, query optimization\n- No circuit breakers → Add circuit breakers\n```\n\n### For Code Review\n```\nGoal: Merge high-quality code\nInvert: What would make this PR problematic?\n- Introduces security vulnerability\n- Breaks existing functionality\n- No tests for new behavior\n- Unclear intent/poor naming\n- Performance regression\n- Missing error handling\n```\n\n### For Career/Team Building\n```\nGoal: Build successful engineering career\nInvert (Munger's list of what to avoid):\n- Be unreliable\n- Learn only from your own mistakes (ignore others')\n- Give up after first failure\n- Be resentful and envious\n- Stay within comfort zone\n- Avoid difficult conversations\n- Don't learn continuously\n```\n\n### For Project Planning\n```\nGoal: Successful product launch\nInvert: How to guarantee launch failure?\n- No user research → Validate with users\n- No load testing → Load test before launch\n- No rollback capability → Build rollback\n- No success metrics defined → Define metrics upfront\n- Team burnout → Sustainable pace\n- No communication plan → Prepare stakeholder comms\n```\n\n## Combining with Pre-Mortem\nInversion + Pre-Mortem creates powerful risk identification:\n\n1. **Inversion**: List ways the project could fail (theoretical)\n2. **Pre-Mortem**: Imagine it DID fail, explain why (narrative)\n3. **Synthesize**: Combine both lists, prioritize, mitigate\n\n## Common Inversions for Software\n\n| Domain | Goal | Key Inversions to Avoid |\n|--------|------|------------------------|\n| Security | Secure system | Trusting user input, weak auth, exposed secrets |\n| Performance | Fast system | No caching, blocking calls, no indexes |\n| Reliability | Stable system | No monitoring, no redundancy, no graceful degradation |\n| Maintainability | Clean code | No tests, cryptic names, tight coupling |\n| Team | High performance | Poor communication, no psychological safety, unclear goals |\n\n## Verification Checklist\n- [ ] Goal clearly defined\n- [ ] Listed 10+ ways to fail/achieve opposite\n- [ ] Categorized failures by type and severity\n- [ ] Converted top failures to explicit requirements\n- [ ] Verified plan addresses the most critical inversions\n- [ ] Shared inversions with team for blind spot check\n\n## Key Questions\n- \"What would guarantee failure here?\"\n- \"What mistakes do others commonly make?\"\n- \"What am I most likely to overlook?\"\n- \"If this fails spectacularly, what will the postmortem say?\"\n- \"What would I tell someone else to avoid?\"\n- \"What would the opposite of success look like, specifically?\"\n\n## Munger's Warning\n\"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.\"\n\nThe power of inversion is in avoiding obvious errors that optimism blinds us to. Simple avoidance often beats clever optimization.\n"},"import":{"commit_sha":"a31e22d4445ad8fef7cd771d32af537aebb68c49","imported_at":"2026-05-22T21:14:39Z","license_text":"MIT License\n\nCopyright (c) 2025 TJ Boudreaux\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","owner":"tjboudreaux","repo":"tjboudreaux/cc-thinking-skills","source_url":"https://github.com/tjboudreaux/cc-thinking-skills/tree/a31e22d4445ad8fef7cd771d32af537aebb68c49/skills/thinking-inversion"}},"content_hash":[88,136,163,18,251,227,159,136,13,218,162,138,195,234,125,241,86,3,72,152,113,25,229,151,246,74,253,99,33,181,154,170],"trust_level":"unsigned","yanked":false}