\r \r

Inversion Protocol\r

\r

"All I want to know is where I'm going to die, so I'll never go there."\r — Charlie Munger\r \r

What This Skill Does\r

\r The Inversion Protocol is a meta-cognitive reasoning layer that improves the\r quality of every decision an AI agent makes. It works by inserting a rapid\r backwards-thinking checkpoint before significant actions.\r \r Most skills give bots new capabilities. This skill makes all existing\r capabilities work better by catching errors, hallucinations, wrong assumptions,\r and overengineered solutions before they happen.\r \r This skill has zero dependencies and zero runtime cost. It is pure reasoning\r enhancement — no APIs, no binaries, no environment variables, no external\r services.\r \r

When to Activate\r

\r Apply the Inversion Protocol before any action where being wrong matters:\r \r

• Writing or modifying code\r
• Running destructive or irreversible commands\r
• Debugging a problem (especially when stuck)\r
• Making architectural or design decisions\r
• Answering questions where accuracy is critical\r
• Performing multi-step workflows\r
• Any situation where the user has corrected you before\r \r Do NOT apply to trivial actions like reading files, listing directories, or\r responding to greetings. The protocol is for moments of consequence.\r \r

The Three Lenses\r

\r When the protocol activates, apply these three lenses in order. Each takes\r only seconds but catches entirely different classes of errors.\r \r

Lens 1: Inversion (The Reverse Engineer)\r

\r Ask: "How would I deliberately CREATE this problem?"\r \r Instead of asking "how do I fix this?", ask "how would I break this on\r purpose?" The answers reveal root causes that forward-thinking misses entirely.\r \r Mechanics:\r

1. State the problem or goal clearly in one sentence\r
2. Invert it: describe 3 specific ways you would cause this exact failure\r
3. Check: are any of those failure patterns present in the current situation?\r
4. If yes — you've found your root cause. Address it directly.\r \r Example — Debugging slow code:\r

• Forward thinking: "Let me profile and optimize hot paths"\r
• Inversion: "How would I make code slow on purpose?"\r
  • Add unnecessary nested loops over large datasets\r
  • Make redundant database/API calls inside loops\r
  • Block the main thread with synchronous operations\r
  • Skip caching and recompute everything every time\r
• Check the codebase for these exact anti-patterns\r
• Result: finds the N+1 query problem in 30 seconds instead of 30 minutes\r \r Example — Writing an API endpoint:\r
• Forward thinking: "Let me implement the happy path"\r
• Inversion: "How would I make this API as insecure as possible?"\r
  • Accept unsanitized input directly into queries\r
  • Return full error stack traces to the client\r
  • Skip authentication and rate limiting\r
  • Log sensitive data in plaintext\r
• Check: am I accidentally doing any of these?\r
• Result: catches security issues during development, not in production\r \r

Lens 2: Premortem (The Time Traveler)\r

\r Ask: "It's tomorrow and this completely failed. What went wrong?"\r \r The premortem technique (created by psychologist Gary Klein) exploits a cognitive\r bias: people are better at explaining past events than predicting future ones.\r By framing the failure as already having happened, you unlock failure modes your\r brain would otherwise suppress.\r \r Mechanics:\r

1. Assume your planned action has already been executed and it failed\r
2. Generate the 3 most likely reasons for the failure\r
3. For each reason, determine: can I verify this won't happen BEFORE acting?\r
4. If verifiable — verify it. If not — add a safeguard.\r \r Example — Refactoring a function:\r

• Planned action: Extract shared logic into a helper function\r
• Premortem: "The refactor shipped and broke production. Why?"\r
  • The function had hidden side effects I didn't notice (most likely)\r
  • Other code depended on the exact return shape, not just the value\r
  • The test suite doesn't cover the edge case this function handles\r
• Verify: Read all callers. Run the tests. Check for side effects.\r
• Result: Discovers the function mutates a global config object — would have\r caused a subtle production bug\r \r Example — Answering a technical question:\r
• Planned action: Provide a solution using library X\r
• Premortem: "The user tried my solution and it didn't work. Why?"\r
  • Library X's API changed in a recent version I'm not aware of\r
  • The user's environment has constraints I didn't ask about\r
  • My solution works in isolation but conflicts with their existing code\r
• Verify: Acknowledge version uncertainty. Ask about constraints. Caveat the\r answer.\r
• Result: Provides a robust answer instead of a confident-but-wrong one\r \r

Lens 3: Via Negativa (The Razor)\r

\r Ask: "What is the ONE thing I absolutely must NOT do here?"\r \r Inspired by Nassim Taleb's principle that removing harm is more powerful than\r adding good. In complex systems, avoiding the worst mistake matters more than\r finding the best solution. This lens prevents catastrophic errors.\r \r Mechanics:\r

1. Identify the single most damaging mistake possible in this situation\r
2. Explicitly confirm you are not about to make that mistake\r
3. If you are — stop and reconsider your entire approach\r \r Example — Database migration:\r

• Via Negativa: "The ONE thing I must NOT do?"\r
  • Drop or alter a column that other services depend on without coordination\r
• Check: Am I about to do this? → Yes, the users.email column is referenced\r by the auth service\r
• Result: Prevents a cascading multi-service outage\r \r Example — Responding to a frustrated user:\r
• Via Negativa: "The ONE thing I must NOT do?"\r
  • Give the same answer they've already rejected, reworded\r
• Check: Is my new response materially different? → No, it's basically the same\r approach with different syntax\r
• Result: Forces a genuinely new approach instead of rephrasing failure\r \r

Integration Patterns\r

\r

Pattern A: Full Protocol (Complex Decisions)\r

\r For architectural choices, multi-file refactors, debugging sessions where you're\r stuck, or high-stakes operations:\r \r

[INVERSION PROTOCOL — FULL]\r
Goal: {one-sentence description of what I'm about to do}\r
\r
INVERT: How would I cause this problem?\r
1. {failure pattern 1}\r
2. {failure pattern 2}\r
3. {failure pattern 3}\r
Present in current situation? {yes/no + details}\r
\r
PREMORTEM: It failed. Why?\r
1. {most likely cause}\r
2. {second most likely}\r
3. {third most likely}\r
Verifiable before acting? {verification steps}\r
\r
VIA NEGATIVA: The ONE thing I must NOT do?\r
→ {the catastrophic mistake to avoid}\r
Am I about to do it? {yes/no}\r
\r
DECISION: {proceed / adjust approach / stop and rethink}\r
```\r
\r
### Pattern B: Quick Check (Routine Actions)\r
\r
For writing functions, running commands, or standard responses — a 5-second\r
mental check:\r
\r
```\r
[INVERSION — QUICK]\r
Inverse: {one way I'd cause this to fail}\r
Premortem: {one reason this could go wrong}\r
Razor: {the one thing NOT to do}\r
→ {proceed / adjust}\r
```\r
\r
### Pattern C: Stuck Mode (When Progress Has Stalled)\r
\r
When the agent has tried multiple approaches and none work, or the user has\r
corrected the same type of mistake more than once:\r
\r
```\r
[INVERSION PROTOCOL — STUCK MODE]\r
I've been trying to: {description}\r
My approaches so far: {list what's been tried}\r
\r
FULL INVERSION: How would I guarantee this NEVER works?\r
1. {anti-approach 1}\r
2. {anti-approach 2}\r
3. {anti-approach 3}\r
\r
Am I accidentally doing any of these? {analysis}\r
\r
REFRAME: What if the problem isn't {what I think it is}\r
but actually {inverted framing}?\r
```\r
\r
## What This Skill Does NOT Do\r
\r
- It does not add tools or API integrations\r
- It does not require any environment variables, config, or dependencies\r
- It does not slow down the agent perceptibly (seconds per check)\r
- It does not override the user's instructions\r
- It does not apply to trivial actions\r
- It is not a safety filter or content policy — it improves decision QUALITY\r
\r
## Why This Works (The Cognitive Science)\r
\r
1. **Confirmation bias countermeasure**: Humans and LLMs naturally seek evidence\r
   that confirms their first instinct. Inversion forces consideration of\r
   disconfirming evidence.\r
\r
2. **Prospective hindsight**: Klein's research showed that premortems increase\r
   the ability to identify failure reasons by 30% compared to standard\r
   "what could go wrong?" thinking.\r
\r
3. **Subtraction over addition**: Taleb's Via Negativa recognizes that in\r
   complex systems, avoiding the worst outcome (robustness) is more valuable\r
   than optimizing for the best outcome.\r
\r
4. **Second-order thinking**: The protocol naturally produces second-order\r
   consequences that first-pass reasoning misses.\r
\r
## Composability\r
\r
The Inversion Protocol enhances every other skill in the ecosystem:\r
\r
- **Code skills** → catch bugs before they're written\r
- **DevOps skills** → prevent misconfigured deployments\r
- **Research skills** → avoid confirmation-biased searches\r
- **Communication skills** → prevent tone-deaf responses\r
- **Financial skills** → catch risky trades before execution\r
- **Automation skills** → prevent runaway processes\r
\r
It is a **force multiplier**, not a replacement for any existing capability.\r