playbooks

home / skills / mamba-mental / agent-skill-manager / inversion-exercise

inversion-exercise skill

/skills/problem-solving/inversion-exercise

This skill helps you reveal hidden constraints by inverting core assumptions, enabling new strategies and resilient design decisions.

npx playbooks add skill mamba-mental/agent-skill-manager --skill inversion-exercise

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.0 KB
---
name: Inversion Exercise
description: Flip core assumptions to reveal hidden constraints and alternative approaches - "what if the opposite were true?"
when_to_use: when stuck on unquestioned assumptions or feeling forced into "the only way" to do something
version: 1.1.0
---

# Inversion Exercise

## Overview

Flip every assumption and see what still works. Sometimes the opposite reveals the truth.

**Core principle:** Inversion exposes hidden assumptions and alternative approaches.

## Quick Reference

| Normal Assumption | Inverted | What It Reveals |
|-------------------|----------|-----------------|
| Cache to reduce latency | Add latency to enable caching | Debouncing patterns |
| Pull data when needed | Push data before needed | Prefetching, eager loading |
| Handle errors when occur | Make errors impossible | Type systems, contracts |
| Build features users want | Remove features users don't need | Simplicity >> addition |
| Optimize for common case | Optimize for worst case | Resilience patterns |

## Process

1. **List core assumptions** - What "must" be true?
2. **Invert each systematically** - "What if opposite were true?"
3. **Explore implications** - What would we do differently?
4. **Find valid inversions** - Which actually work somewhere?

## Example

**Problem:** Users complain app is slow

**Normal approach:** Make everything faster (caching, optimization, CDN)

**Inverted:** Make things intentionally slower in some places
- Debounce search (add latency → enable better results)
- Rate limit requests (add friction → prevent abuse)
- Lazy load content (delay → reduce initial load)

**Insight:** Strategic slowness can improve UX

## Red Flags You Need This

- "There's only one way to do this"
- Forcing solution that feels wrong
- Can't articulate why approach is necessary
- "This is just how it's done"

## Remember

- Not all inversions work (test boundaries)
- Valid inversions reveal context-dependence
- Sometimes opposite is the answer
- Question "must be" statements

Overview

This skill trains you to flip core assumptions and inspect what still holds when the opposite is true. It helps teams reveal hidden constraints, discover alternate strategies, and test whether accepted practices are actually necessary. Use it to break mental ruts and surface context-dependent solutions.

How this skill works

You list the core "must be" assumptions for a problem, then invert each one and systematically explore the consequences. For each inversion you sketch actions, risks, and where the inverted approach might actually succeed. Finally you test or prototype promising inversions to validate whether they solve the original problem in a new way.

When to use it

  • When a single accepted solution dominates decision discussions
  • When an approach feels arbitrary or unexplained
  • During design reviews or postmortems to find root causes
  • When product or system trade-offs are unclear
  • When you need creative, low-cost experiments

Best practices

  • Start by naming explicit assumptions before proposing inversions
  • Keep inversions simple and specific (one assumption at a time)
  • Sketch concrete experiments or prototypes for promising inversions
  • Assess trade-offs: failure modes, costs, and contexts where inversion fits
  • Use inversions to generate a shortlist, then validate with lightweight tests
  • Document failures as well as successes to map context boundaries

Example use cases

  • Performance troubleshooting: invert "make everything faster" to add strategic latency (debounce, rate-limit, lazy load)
  • Feature design: invert "we must add X" to removing or simplifying features to improve clarity
  • Error handling: invert "handle errors after they occur" to design systems that prevent classes of errors via contracts or types
  • Data flow: invert pull-to-request into push/prefetch patterns for better UX
  • Resilience: invert optimizing for common case into optimizing for worst case to harden systems

FAQ

Will every inversion be useful?

No. Many inversions expose impractical trade-offs. The goal is to reveal alternatives and test the few that show promise.

How do I avoid wasting time on unrealistic inversions?

Filter inversions by concrete impact and feasibility, then run lightweight experiments rather than full builds.