Assumption Inversion — list the assumptions behind the current approach and flip each one, then ask where the flipped version could actually be true. Use when requirements encode beliefs nobody has questioned, when a design feels inevitable, or when incumbents all share one blind spot. Triggers include "invert", "flip it", "flip the assumption", "reverse the premise", "what if the opposite were true", "challenge the assumption". Do NOT use for analytical work like debugging, code review, or implementation tasks.
npx skills add https://github.com/danium/lateral-thinking --skill inversion
Every approach rests on a stack of unstated beliefs — about who the user is, what they value, how the thing gets delivered, in what order, at what price. List those beliefs, flip each one into its opposite, then ask the sharp question: where is the flipped version *already true*? Most flips are dead ends, and naming them dead is part of the work. The two or three flips that turn out to be true somewhere are where a non-obvious direction hides — the incumbents never looked there because the original belief felt like a law of nature.
Source: the classical dialectic method of arguing a position by its negation; popularized for business by "invert, always invert" (Carl Jacobi, via Charlie Munger) and by Edward de Bono's reversal method in *Lateral Thinking* (1970).
A valid target is a design, plan, or approach whose assumptions you can list: a product strategy, a go-to-market plan, a pricing model, a workflow you are about to build, an onboarding sequence. If the target is unclear, ask one focused question — "What's the current approach, and what feels locked-in about it?"
Refuse requests to *perform* analytical work — debugging, reviewing code, implementing a change — and suggest an analytical approach instead. Redesigning or ideating about such a process is a valid creative target: "reinvent our code-review ritual" is in scope; "review this PR" is not.
List 5–8 assumptions behind the current approach. Aim for the load-bearing ones, not decorations. These prompt categories help you cover the space rather than list five versions of the same belief:
Turn each assumption into its strongest *plausible opposite* — not a strawman. "Users want it fast" flips to "users want it slow and deliberate," not "users want it broken." A good flip is one a reasonable person could defend. If the flip is obviously stupid, you flipped it lazily; find the version a competitor could actually build a business on.
For each flip, ask the load-bearing question: "In what market, segment, or era is this flip TRUE? Who profits from it today?" Name a real place it holds — a customer type, an industry, a historical moment, an existing product. If you cannot name one honestly, the flip is dead. Say so and move on. Do not manufacture a fake "where."
Take the 2–3 flips that had a live answer in Step 4 and develop them into concrete directions. What would the approach look like if you built it around the flipped belief? Where the flip already works for someone else, borrow the mechanism.
Scan across the flips that survived. Is there a structural insight — one belief that several assumptions all secretly depended on, one axis where the whole approach is fragile? State it explicitly. This cross-flip observation is often the real finding, larger than any single flipped assumption.
Rank the surviving directions, weakest called out as weak and why. Mark the dead flips as dead so the user sees the whole map. Then offer the next move — extract more assumptions, go deeper on one direction, switch technique, or stop — and never push the user to commit. The technique is divergent; convergence belongs to the user.
Dead flips stay visible. A flip with no honest answer to "where is this true?" is marked dead explicitly, not quietly dropped. The dead flips are evidence the exercise was genuine.
Something usually survives inversion unscathed. At least one assumption, when flipped, has no live answer anywhere — the original belief really is close to a law for this problem. Say so. That is a finding too: it tells you where *not* to waste effort.
Every flip working is a red flag. An inversion session where every flip "turns out to be true somewhere" is a sign the flips were strawmen or the "wheres" were manufactured. Expect one or two flips to die.
provocation's territory). Inversion flips into *plausible opposites* a competitor could defend.references/worked-example.md — a real session showing the full shape, dead flips includedTake danium/inversion from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.