inversion-engine

name

inversion-engine

description

Structured inversion analysis for strategic decisions, plans, and initiatives. Systematically maps every path to failure so the path to success becomes obvious by elimination. Produces scored risk registers, countermeasure plans, and decision briefs -- not just narrative brainstorming. Use this skill whenever the user asks to stress test a plan, run a pre-mortem, do failure analysis, red team a strategy, audit assumptions, map risks, run inversion on a decision, identify what could go wrong, pressure test an idea, do a Munger-style analysis, or any variation of "help me figure out how this fails before I commit." Also trigger when the user asks to compare two competing strategies by risk profile, update a prior risk assessment with new information, or generate a decision brief from a risk analysis.

Inversion Engine

A structured analytical framework that maps failure paths to derive success conditions by elimination. Based on Charlie Munger's inversion method, extended with quantitative risk scoring (FMEA), cumulative phase chaining, adversarial red-teaming, and deliverable generation.

This is not a prompt library. Each phase produces structured output that feeds forward into subsequent phases, building a compounding risk model. The final output is an actionable artifact, not a conversation.

How to read this skill

The core methodology lives in references/inversion-framework.md. Read it before running any analysis. It contains the full 5-phase pipeline, output schemas, scoring methodology, and operational modes.

This top-level file covers workflow orchestration, user interaction patterns, and output format decisions.

Workflow

1. Intake

When the user triggers this skill, gather three things:

• The subject: a plan, strategy, decision, initiative, or proposal. Accept it as pasted text, an uploaded file, or a conversational description. If the user gives a brief description, ask one clarifying question to establish scope and time horizon. Do not over-interview -- one question maximum, then proceed.
• Domain context (optional): the user may volunteer domain-specific failure patterns, industry knowledge, regulatory constraints, or prior experience. Incorporate these as seeded failure modes in Phases 1 and 2. If the user does not volunteer domain context, do not ask for it -- run the analysis with general reasoning and let them inject domain knowledge in subsequent iterations.
• Mode selection: default is Full Analysis (all 5 phases). The user may request a single phase, a subset, or Comparative Mode (two strategies side by side). If they do not specify, run Full Analysis.

2. Execution

Read references/inversion-framework.md and execute the requested phases. Each phase receives the cumulative output of all prior phases as input context. Do not treat phases as independent.

Between phases, provide a brief (2-3 sentence) transition summary so the user can see the analysis building. Do not ask for permission to continue between phases unless the user has explicitly requested phase-by-phase approval.

3. Output

After the final phase, produce two things:

A. The Risk Register -- a structured table with these columns:

• ID (sequential)
• Failure Mode (concise label)
• Phase Identified (which phase surfaced it)
• Severity (1-10)
• Probability (1-10)
• Detectability (1-10, where 10 = hardest to detect)
• RPN (Severity x Probability x Detectability)
• Earliest Signal (observable indicator)
• Countermeasure (specific behavior or system)
• Status (Open / Mitigated / Accepted)

Sort by RPN descending.

B. The Decision Brief -- a concise summary containing:

• Top 3 failure paths by RPN
• The 3 protective behaviors from Phase 5
• Go / No-Go / Conditional-Go recommendation with stated conditions
• Open questions that could not be resolved by analysis alone

If the user requests a downloadable artifact (document, PDF, markdown file), generate it. Otherwise, present inline.

4. Iteration

The analysis is designed to be updated, not re-run from scratch. Support these iteration patterns:

• New information: user provides updated assumptions or new data. Re-run Phase 3 (Assumption Stress Test) with the update, then propagate changes through Phases 4 and 5. Preserve prior findings and mark what changed.
• Domain injection: user adds domain-specific failure modes after seeing initial results. Insert them into the risk register, score them, and re-run Phase 5 to update the protective behaviors.
• Comparative pivot: user wants to compare the analyzed plan against an alternative. Run Phases 1-5 on the alternative, then produce a side-by-side comparison of risk registers and protective behaviors.

5. Comparative Mode

When comparing two or more strategies:

• Run the full pipeline on each independently.
• Produce a comparison table: total failure paths identified, average RPN, number of unmitigable risks, earliest average detection point.
• Identify failure paths unique to each strategy and failure paths shared across both.
• State which strategy has the more favorable risk profile and why, without editorializing. Present the data and let the user decide.

Tone and approach

• Analytical, not dramatic. This is structured risk analysis, not creative writing about doom scenarios.
• Specific, not vague. Every failure mode must name a concrete mechanism, not a feeling ("team loses motivation" is too vague; "key technical hire leaves in month 3 because equity vesting is backloaded and a competitor offers immediate liquidity" is specific enough).
• Honest about uncertainty. If a failure mode depends on information the user has not provided, flag it as "unscored -- requires domain input" rather than guessing at probability.
• No false precision. The FMEA scores are ordinal rankings to aid prioritization, not statistical probabilities. Do not present them as exact measurements.