@complexthings/superpowers-agent 9.2.1 → 10.0.1

package/skills/problem-solving/collision-zone-thinking/references/historical-examples.md

@@ -1,393 +0,0 @@
-# Historical Examples: Cross-Domain Collisions That Became Software Foundations
-
-These are real, documented cases where borrowing a mechanism from an unrelated domain produced a breakthrough in software or computer science. Each entry follows the collision-zone format: source domain → target problem → mechanisms imported → emergent properties → where it breaks.
-
-Use these as evidence when selecting source domains, as templates for how to run a collision, or as existence proofs that this technique actually works at scale.
-
----
-
-## Biology & Probabilistic Mathematics
-
-### Bloom Filter (1970, Burton Howard Bloom)
-
-**Source domain:** Probabilistic mathematics — asymmetric certainty  
-**Target problem:** How to test dictionary membership (500,000 words) without disk access  
-**Structural type:** Membership testing with constrained memory
-
-**Mechanism imported:**  
-The asymmetry of certainty: "definitely not in the set" is provable; "possibly in the set" is not. A bit array with multiple hash functions can eliminate false negatives while tolerating false positives at a controlled rate.
-
-**Emergent properties:**
-- Sub-linear space usage: O(n) storage, not O(n × word_length)
-- Tunable false-positive rate: add more bits to lower it
-- Composable: merge two Bloom filters by OR-ing their bit arrays
-- Write-optimized: insertion is O(k) hash operations
-
-**Real-world validation:** Cassandra, HBase, Bigtable (false-positive tolerant for SSTable checks), Chrome malicious URL detection, Bitcoin SPV nodes, Medium ("have you read this?" feature)
-
-**Where it breaks:**
-- Cannot remove elements (deletion destroys the probabilistic guarantee)
-- False positive rate grows as fill factor increases — requires capacity planning
-- Not suitable for exact membership — introduces error by design
-- Counting variants (counting Bloom filters) exist but are more complex
-
-**What the breakdown reveals:** The tradeoff is between certainty and space efficiency. Where you can tolerate "probably yes / definitely no" — and where false positives have low cost — Bloom filters are strictly dominant.
-
----
-
-### Genetic Algorithms (1970s, John Holland, University of Michigan)
-
-**Source domain:** Darwinian evolution — natural selection, genetic inheritance  
-**Target problem:** Search and optimization over large, irregular parameter spaces  
-**Structural type:** Optimization in unknown fitness landscapes
-
-**Mechanisms imported:**
-- Selection pressure: fitter individuals reproduce more
-- Chromosome encoding: candidate solutions as bit strings
-- Crossover (recombination): combine parts of two parent solutions
-- Mutation: random perturbation to prevent local optima
-- Fitness function: the objective being optimized plays the role of the environment
-
-**Emergent properties:**
-- Parallelism: population explores multiple search directions simultaneously
-- Implicit parallelism: short, high-fitness bit patterns ("schemata") propagate quickly
-- No gradient required: works on non-differentiable, discontinuous landscapes
-- Self-adaptation: populations can evolve their own mutation rates (evolution strategies)
-
-**Real-world validation:** NASA ST5 spacecraft antenna (evolved, not designed), circuit board routing, neural architecture search, drug molecule optimization
-
-**Where it breaks:**
-- Fitness function must be hand-crafted — and can be gamed
-- Slower than domain-specific algorithms when those exist
-- Convergence to local optima still happens (premature convergence)
-- No interpretability: you get a solution but not an explanation
-- Epistasis (gene interactions) makes analysis difficult
-
-**What the breakdown reveals:** Evolution is a process without a goal — genetic algorithms must supply the goal externally via the fitness function. This is the critical engineering interface: defining what "fit" means is where the domain knowledge lives, not in the algorithm itself.
-
----
-
-### Artificial Immune Systems (mid-1980s–1990s)
-
-**Source domain:** Vertebrate adaptive immune system  
-**Target problem:** Anomaly detection and adaptive defense  
-**Structural type:** Self/non-self discrimination with memory
-
-**Mechanisms imported:**
-- Negative selection: T-cells that react to self are deleted; only non-self-reactive cells survive
-- Clonal selection: cells that successfully detect a threat multiply rapidly
-- Memory cells: successful past detections persist for faster future response
-- Danger theory (Matzinger): the immune system responds to danger signals, not just non-self
-
-**Emergent properties:**
-- Self-adapting detection: no pre-enumerated threat list required
-- Distributed: no central detector, detection emerges from population behavior
-- Memory: past exposures improve future detection speed
-
-**Real-world validation:** Network intrusion detection (LISYS system), anomaly detection in industrial systems
-
-**Where it breaks:**
-- Computational cost: maintaining and cycling a detector population is expensive
-- Self-definition problem: defining "self" in software is non-trivial
-- Largely supplanted by deep learning for anomaly detection after ~2005
-- Danger theory is still controversial in immunology itself
-
-**What the breakdown reveals:** The immune system succeeds partly because the body's "self" is stable and well-defined. In software systems, "normal behavior" is a moving target — which is exactly why deep learning approaches (that continuously update) eventually won.
-
----
-
-## Physics & Thermodynamics
-
-### Simulated Annealing (1983, Kirkpatrick, Gelatt & Vecchi, IBM)
-
-**Source domain:** Metallurgical physics — the annealing process for crystallizing metals  
-**Target problem:** Combinatorial optimization (circuit placement, traveling salesman)  
-**Structural type:** Optimization with many local optima
-
-**Mechanisms imported:**
-- Annealing in metallurgy: slowly cooling a heated material allows atoms to find low-energy configurations
-- Temperature controls randomness: at high temperature, the system accepts worse solutions (explores); as temperature drops, it becomes more selective (exploits)
-- Boltzmann acceptance probability: the probability of accepting a worse solution is exp(-ΔE/kT)
-
-**Emergent properties:**
-- Escapes local optima: unlike greedy search, accepts worse moves probabilistically
-- Temperature schedule controls the exploration/exploitation tradeoff
-- Parameter-free in principle (though cooling schedule is problem-specific in practice)
-
-**Real-world validation:** Chip placement (VLSI), protein folding, schedule optimization; it built on the Metropolis-Hastings algorithm (1953) which used the same physics for Monte Carlo simulation
-
-**Where it breaks:**
-- Cooling schedule is highly problem-specific — getting it wrong wastes most of the value
-- No guarantee of finding the global optimum
-- Slow for large problem spaces
-- Has largely been displaced by gradient-based methods where those are applicable
-
-**What the breakdown reveals:** Temperature is a proxy for exploration willingness. This generalizes to any algorithm that needs to balance exploration vs. exploitation — the "temperature" concept recurs in modern reinforcement learning (entropy regularization, softmax temperature).
-
----
-
-## Electrical Engineering
-
-### Circuit Breaker Pattern (2007, Michael Nygard, "Release It!")
-
-**Source domain:** Electrical engineering — physical circuit breakers  
-**Target problem:** Cascading failures in distributed microservices  
-**Structural type:** Failure isolation and propagation prevention
-
-**Mechanisms imported:**
-- Three-state model: Closed (normal), Open (tripped), Half-Open (testing recovery)
-- Automatic disconnection on overload (trips when error rate exceeds threshold)
-- Reset by testing: re-attempts at low volume to determine if system recovered
-
-**Emergent properties:**
-- Fail-fast: callers get immediate errors instead of waiting for timeout cascades
-- Self-healing: Half-Open state enables automatic recovery detection
-- Observable state: circuit state is a meaningful system health signal
-- Composable: circuit breakers chain — upstream circuits observe downstream trips
-
-**Real-world validation:** Netflix Hystrix (2011), Resilience4j, Envoy proxy, AWS SDK
-
-**Where it breaks:**
-- Software needs heuristics for "overload" (error rate %, latency p99); electricity has simple physics
-- Half-Open state has no electrical equivalent — Nygard invented it for the software context
-- In sharded systems, a circuit may be open for some shards but closed for others — the pattern doesn't handle partial failures natively
-- Doesn't address the root cause — only prevents spread
-
-**What the breakdown reveals:** The Half-Open state is a purely software invention with no electrical counterpart. It exists because software systems have intent and retry semantics that circuits don't — the recovery test is a design decision the electrical world never needed to make.
-
----
-
-### Reactive Programming
-
-**Source domain:** Electrical engineering — analog signal propagation, hardware description languages (Verilog, VHDL)  
-**Target problem:** Managing asynchronous data flow and event propagation in software  
-**Structural type:** Dataflow computation with time-varying values
-
-**Mechanisms imported:**
-- Signals: values that change over time
-- Propagation: when a source changes, downstream computations update automatically
-- Circuit topology: the graph structure of dependencies determines update order
-- Backpressure: when a consumer can't keep up, signal pressure builds up
-
-**Emergent properties:**
-- Declarative composition: describe what, not when
-- Automatic propagation: no manual cache invalidation
-- Time as a first-class citizen: streams can be buffered, debounced, throttled
-
-**Real-world validation:** ReactiveX/RxJS (the dominant paradigm for async JS), React/SolidJS (UI reactive model), Kafka Streams, spreadsheets (the original reactive computation)
-
-**Where it breaks:**
-- Glitches: if two signals feed a computation and both update, intermediate inconsistent states can propagate — requires topological sorting to prevent
-- Memory consumption: infinite streams must be explicitly windowed
-- Cyclic dependencies: most reactive systems forbid cycles, but real systems often have feedback loops
-- Learning curve: thinking in streams is alien to imperative programmers
-
-**What the breakdown reveals:** Hardware description languages solved glitches via compile-time topological sort and clock domains. Software reactive systems that skip this analysis (most of them) leave glitch prevention to the developer — which is why `combineLatest` and `zip` exist as workarounds.
-
----
-
-## Functional Programming / Mathematics
-
-### MapReduce (Google, 2004, Dean & Ghemawat)
-
-**Source domain:** Functional programming — Lisp's `map` and `reduce` primitives + assembly-line manufacturing  
-**Target problem:** Distributed computation over petabytes of data with commodity hardware  
-**Structural type:** Parallelizable batch data processing
-
-**Mechanisms imported from FP:**
-- `map`: apply a function to each element independently (parallelizable)
-- `reduce`/`fold`: combine results (aggregatable after independent processing)
-- Referential transparency: pure map functions have no side effects, making distribution safe
-
-**Mechanisms imported from manufacturing:**
-- Assembly line: work is divided into stages
-- WIP limits: intermediate results (shuffled key-value pairs) bounded in memory
-- Worker redundancy: failed workers are replaced; work is redistributed
-
-**Emergent properties:**
-- Fault tolerance by design: idempotent map tasks can be retried on any worker
-- Data locality: moving computation to data is faster than moving data to computation
-- Linear scalability: adding workers reduces wall-clock time proportionally (for the map stage)
-
-**Real-world validation:** Google's internal infrastructure, Apache Hadoop, later Apache Spark
-
-**Where it breaks:**
-- Only acyclic dataflow: no loops, no iterative algorithms (PageRank took 30 MapReduce jobs)
-- Disk-heavy: intermediate results are written to disk between stages
-- Batch-only: not suitable for streaming data
-- Google abandoned it internally ~2014 in favor of Flume/Dataflow
-
-**What the breakdown reveals:** Map and reduce are mathematically powerful but structurally flat. Real-world analytics requires iteration (machine learning) and stream processing (real-time) — which led directly to Spark (in-memory iteration) and Kafka (streaming). MapReduce's limitations were the exact specification for its successors.
-
----
-
-## Accounting & Finance
-
-### Event Sourcing / CQRS
-
-**Source domain:** Double-entry bookkeeping (~1300s; formalized by Luca Pacioli, 1494)  
-**Target problem:** Audit trails, temporal queries, and consistency in distributed write-heavy systems  
-**Structural type:** Immutable state history with derived projections
-
-**Mechanisms imported:**
-- Immutable ledger entries: transactions are never modified, only appended
-- Balance as a derivation: account balance is computed from history, not stored as mutable state
-- Double-entry: every change is recorded from two perspectives (debit and credit)
-- Audit trail: the complete history is the source of truth
-
-**Emergent properties:**
-- Time travel: reconstruct system state at any past point
-- Audit log for free: the event store is the audit trail
-- Projection flexibility: derive different read models from the same event stream
-- Debugging by replay: reproduce bugs by replaying the event sequence
-
-**Real-world validation:** Apache Kafka (event log as primary data store), event-driven microservices, CQRS pattern, financial trading systems, git (commit log is an event store)
-
-**Where it breaks:**
-- Schema evolution is hard: old events must be interpretable with new schemas
-- Eventual consistency between write model (event store) and read models (projections)
-- Snapshot strategy needed: replaying 10 years of events is slow
-- Storage grows unbounded without archiving strategy
-
-**What the breakdown reveals:** Bookkeepers solved the "derived state" problem by never modifying entries — only appending. The insight is that mutability is a choice, not a necessity. The breakdown (schema evolution) is the software equivalent of a legal document format change — and the same solution applies: versioning and migration scripts.
-
----
-
-## Topology / Pure Mathematics
-
-### Consistent Hashing (1997, Karger et al., MIT / Akamai)
-
-**Source domain:** Geometric topology — unit circle, continuous proximity  
-**Target problem:** Distributing keys across a cluster of nodes that can join or leave  
-**Structural type:** Dynamic load distribution with minimal reshuffling
-
-**Mechanisms imported:**
-- Unit circle: map both keys and nodes to positions on a ring (0 to 2^32)
-- Proximity: a key is owned by the nearest node clockwise on the ring
-- Continuity: when a node leaves, only its immediate neighbors are affected
-
-**Emergent properties:**
-- O(1/N) key remapping when a node joins/leaves (vs. O(N) for naive modular hashing)
-- Load balancing with virtual nodes: multiple ring positions per physical node
-- Predictable ownership: any node can independently determine key ownership
-
-**Real-world validation:** Amazon Dynamo (2007), Apache Cassandra, Riak, Discord's message routing, Akamai CDN (the original application)
-
-**Where it breaks:**
-- Non-uniform hash distribution: requires virtual nodes for real load balance
-- Doesn't account for heterogeneous node capacity out of the box
-- Hotspot risk: adjacent keys all route to the same node
-- Consistent hashing is consistent in ownership assignment, not in data consistency (confusing naming)
-
-**What the breakdown reveals:** The ring topology treats the address space as a geometric object rather than an arithmetic one. Virtual nodes are the engineering workaround for what is fundamentally a statistical distribution problem — you need enough random points on the ring to approximate uniform coverage.
-
----
-
-## Architecture & Urban Planning
-
-### Software Design Patterns (GoF, 1994)
-
-**Source domain:** Christopher Alexander's architectural pattern language ("A Pattern Language," 1977)  
-**Target problem:** Cataloging reusable solutions to recurring object-oriented design problems  
-**Structural type:** Knowledge transfer and vocabulary for design decisions
-
-**Mechanisms imported:**
-- Pattern as a named, reusable solution to a recurring problem in context
-- Pattern language: patterns connect and reference each other, forming a vocabulary
-- Generative grammar: patterns are rules for generating good designs
-- Context/problem/solution structure: each pattern has a specific applicability domain
-
-**Transfer path:** Kent Beck & Ward Cunningham applied Alexander's patterns to Smalltalk OOP at OOPSLA 1987 → Gang of Four (GoF) systematized 23 OO patterns in 1994
-
-**Emergent properties:**
-- Shared vocabulary: "use a Factory here" communicates more than the code would
-- Pattern composition: patterns reference and complement each other
-- Codified judgment: captures design wisdom that was previously tacit
-- Documentation standard: the pattern format became the template for communicating design decisions
-
-**Real-world validation:** GoF "Design Patterns" is one of the best-selling programming books ever; patterns permeate code review vocabulary across all languages
-
-**Where it breaks:**
-- Peter Norvig showed 16 of 23 GoF patterns are invisible or simplified in Lisp — patterns are workarounds for language limitations
-- Patterns are overused: applied where they don't fit, adding complexity without solving a real problem
-- The analogy to architecture is limited: software patterns don't generate buildings, they provide vocabulary
-- Alexander himself was ambivalent about the application to software
-
-**What the breakdown reveals:** Patterns expose language weaknesses. In languages with first-class functions, higher-order types, and macros, many GoF patterns collapse into idioms. The "pattern" is often a workaround for a missing abstraction, not a fundamental design principle.
-
----
-
-## Actor Model (1973, Carl Hewitt, MIT)
-
-**Source domain:** General relativity and quantum mechanics — locality, no global state, message-passing as sole interaction  
-**Target problem:** Modeling concurrent computation without shared mutable state  
-**Structural type:** Distributed, asynchronous, message-based concurrency
-
-**Mechanisms imported:**
-- Locality: no action can have instantaneous non-local effects (from relativity)
-- Message-passing: all interaction is via message, no shared memory (from QM)
-- Independent state: each actor encapsulates its own state exclusively
-- Asynchronous: messages are sent without waiting for a response
-
-**Emergent properties:**
-- No deadlocks from shared state (though livelock and starvation still possible)
-- Location transparency: actors can move between machines without changing message semantics
-- Supervision hierarchies: actors can supervise child actors and restart them on failure
-- Natural fit for distributed systems: local and remote actors look identical
-
-**Real-world validation:** Erlang/OTP (designed for Ericsson telecom systems with 9-nines uptime), Akka (JVM), Orleans (.NET), Twitter's infrastructure
-
-**Where it breaks:**
-- No guaranteed message ordering between actors
-- Debugging is difficult: non-deterministic message interleaving
-- A global scheduler still exists — the system isn't truly distributed in the physics sense
-- Actor granularity is a design challenge: too fine = overhead, too coarse = contention
-
-**What the breakdown reveals:** Hewitt imported the constraint from physics (no global state, no instantaneous action at a distance) because that constraint is what forces distributed systems to work correctly. The breakdown — that a real scheduler exists — reveals that pure actor systems are an idealization, and real implementations must decide where to allow controlled synchrony.
-
----
-
-## Summary: What Makes These Transfers Work
-
-Looking across all these examples, the successful cross-domain transfers share four properties:
-
-| Property | What It Looks Like |
-|----------|-------------------|
-| **Structural isomorphism** | The relational structure of the source domain maps to the target — not just surface labels |
-| **Mechanism import** | A specific causal mechanism (not just a pattern name) is borrowed whole |
-| **Productive breakdown** | The places where the analogy fails reveal genuine design decisions that need to be made |
-| **Emergent properties** | The collision produces capabilities that neither domain had alone |
-
-And the common failure mode: importing vocabulary without mechanisms. "Let's treat our services like microorganisms" is not a collision until you ask: what is the immune response? What is horizontal gene transfer? What is a biofilm?
-
----
-
-## Best Source Domains by Problem Type (Validated)
-
-| Problem Type | Best Source Domain | Proof |
-|-------------|-------------------|-------|
-| Optimization over unknown landscape | Evolution / genetics | Genetic algorithms, neural architecture search |
-| Failure isolation | Electrical engineering | Circuit breaker pattern |
-| Membership testing under memory constraints | Probabilistic mathematics | Bloom filters |
-| Distributed computation | Functional programming + manufacturing | MapReduce |
-| Concurrent state management | Physics (relativity/QM) | Actor model |
-| Audit trails and state history | Accounting / double-entry bookkeeping | Event sourcing |
-| Dynamic load distribution | Geometric topology | Consistent hashing |
-| Design vocabulary | Architecture / urban planning | Design patterns |
-| Anomaly / intrusion detection | Immunology | Artificial immune systems |
-| Async data flow | Electronics / signal processing | Reactive programming |
-
----
-
-## Underexplored Source Domains (High Potential)
-
-These have strong structural richness but are underused in software:
-
-| Domain | Mechanisms Available | Example Application |
-|--------|---------------------|---------------------|
-| **Epidemiology** | R0, herd immunity, quarantine, vectors, super-spreaders | Viral feature adoption modeling, bug propagation in large codebases |
-| **Ecology / food webs** | Trophic cascades, keystone species, carrying capacity | Dependency graph analysis, team organization |
-| **Fluid dynamics** | Reynolds number, turbulence, boundary layers, viscosity | Network congestion modeling, API throughput |
-| **Game theory** | Nash equilibria, dominant strategies, mechanism design | Incentive-compatible API design, distributed consensus |
-| **Traffic engineering** | Braess's paradox, induced demand, signal timing | Load balancing, CDN routing, microservice mesh design |
-| **Materials science** | Fatigue, creep, brittleness, toughness | Software reliability under sustained load |

package/skills/problem-solving/collision-zone-thinking/skill.json

@@ -1,9 +0,0 @@
-{
-    "version": "2.0.0",
-    "name": "superpowers:problem-solving/collision-zone-thinking",
-    "title": "Collision-Zone Thinking",
-    "aliases": [
-        "collision-zone-thinking",
-        "problem-solving/collision-zone-thinking"
-    ]
-}

package/skills/problem-solving/inversion-exercise/SKILL.md

@@ -1,174 +0,0 @@
----
-name: inversion-exercise
-description: Flip core assumptions to reveal hidden constraints and alternative approaches. Use this when stuck on "the only way" to solve a problem, during architecture or design decisions, at code review or project pre-mortems, when a solution feels forced, or anytime assumptions need stress-testing. Inversion bypasses confirmation bias by asking "how would this fail?" instead of "how do we succeed?" — a mental move that surfaces what forward thinking misses. Apply it proactively before major decisions, not just when stuck.
-metadata:
-  when_to_use: when stuck on unquestioned assumptions or feeling forced into "the only way" to do something; also proactively before architecture decisions, API design, or project kickoffs
-  version: 2.0.0
----
-
-# Inversion Exercise
-
-## Why This Works
-
-Carl Jacobi (the mathematician) discovered that many hard problems are easier when restated in inverse form. Charlie Munger applied this principle everywhere: "Invert, always invert."
-
-> "All I want to know is where I'm going to die, so I'll never go there." — Charlie Munger
-
-The cognitive mechanism: your brain cannot easily generate failure modes when it is focused on success. But it is surprisingly good at generating them when you ask for them directly. Inversion is an *access method* for a different cognitive pathway — one that bypasses optimism bias and confirmation bias.
-
-**The practical upshot:** avoiding obvious stupidity is more tractable than seeking brilliance. Most production outages are not caused by missing brilliant features — they're caused by unexamined failure modes.
-
----
-
-## The Four Forms of Inversion
-
-### 1. Goal Inversion (Pre-Mortem)
-
-Instead of "how do we succeed?", ask "how would we fail?"
-
-```
-FORWARD:  "How do we make this deployment succeed?"
-INVERTED: "Assume it's 6 months from now and this deployment failed badly.
-           What happened?"
-
-Typical answers: no rollback plan, untested migration, no monitoring alerts,
-                 deployed on Friday, insufficient load testing
-
-These aren't hypotheticals — they're your checklist.
-```
-
-Gary Klein (HBR 2007) formalized this as the **Failure Pre-mortem**. The grammatical shift from "might fail" to "did fail" grants permission to voice concerns in an environment where optimism is rewarded. It makes it safe to be pessimistic.
-
-**Use this at:** project kickoffs, architecture decisions, release planning, code review.
-
-### 2. Assumption Inversion (Flip Core Beliefs)
-
-Challenge what you believe about how the system works.
-
-```
-ASSUMPTION:  "Clients must poll for updates"
-INVERTED:    "What if the server pushes updates?"
-REVEALS:     WebSockets, Server-Sent Events, webhooks
-
-ASSUMPTION:  "Data must be normalized in tables with strict schemas"
-INVERTED:    "What if data were denormalized with flexible schemas?"
-REVEALS:     Document stores, key-value stores — each optimized for different patterns
-
-ASSUMPTION:  "We must make this faster"
-INVERTED:    "What if we made this intentionally slower in places?"
-REVEALS:     Debounce search (add latency → better results), rate limiting,
-             lazy loading (delay → reduce initial load)
-```
-
-### 3. Perspective Inversion (Opposite Stakeholder)
-
-View from the opposing party.
-
-```
-API DESIGNER:  "What do we want to expose?"
-INVERTED:      "What does the caller actually need to call?" 
-REVEALS:       Consumer-driven contracts; Amazon's "write the press release first"
-
-CODE AUTHOR:   "Does this code work?"
-INVERTED:      "Under what conditions would this code fail?"
-REVEALS:       Edge cases, race conditions, input assumptions
-
-DEFENDER:      "How do we secure this system?"
-INVERTED:      "If I were an attacker, how would I break in?"
-REVEALS:       Threat modeling, red team exercises, STRIDE analysis
-```
-
-### 4. Process Inversion (Reverse the Sequence)
-
-Reverse the order of steps.
-
-```
-NORMAL:   Write code → write tests to verify it
-INVERTED: Write tests (specification) → write code to satisfy them (TDD)
-REVEALS:  Forces you to think about the contract before implementation;
-          surfaces design problems earlier; ensures tests test behavior
-
-NORMAL:   Big batch releases, high-ceremony
-INVERTED: Ship every commit; make deployment boring; test in production
-REVEALS:  The pain of releases was caused by their infrequency (CI/CD)
-
-NORMAL:   A class creates its own dependencies
-INVERTED: A framework provides dependencies to the class (IoC/DI)
-REVEALS:  Testable, loosely coupled code; each class only knows interfaces
-```
-
----
-
-## The Process
-
-**Step 1: State the goal clearly**
-Write it as a single sentence: "I want X."
-
-**Step 2: Flip it**
-"What would *guarantee* NOT-X?" or "What would *make* this fail?"
-
-**Step 3: Generate freely on the inverted question**
-Don't filter. List everything. The items that feel uncomfortable to acknowledge are often the most important.
-
-**Step 4: Translate back**
-Each item on the inverted list is a design constraint, checklist item, or thing to stop doing. Ask: "If this would cause failure, what does that tell me about what success requires?" The inverted list is often your real answer in disguise.
-
-**Step 5: Combine with forward thinking**
-Inversion shows you what to *avoid* and what *constraints* you're operating under. Forward thinking shows you what to *build*. Use both.
-
----
-
-## Software Patterns That *Are* Inversion
-
-Recognizing these helps you understand *why* they work — and when to reach for them:
-
-| Pattern | The Inversion | What It Unlocks |
-|---------|--------------|-----------------|
-| **TDD** | Write proof before code | Tests actually test behavior; design problems surface early |
-| **Dependency Inversion (SOLID)** | High-level doesn't depend on low-level | Abstractions own interfaces; implementations are plugins |
-| **IoC / DI** | Framework calls your code, not vice versa | Testable, loosely coupled, swappable implementations |
-| **Immutability** | State never changes; new values replace old | No shared mutable state bugs; trivially thread-safe |
-| **Result types** | Functions return error-or-value instead of throwing | Errors are explicit in the type system; no surprise exceptions |
-| **Consumer-driven contracts** | Provider doesn't define API shape; consumer does | API always matches real consumer needs |
-| **Pre-mortem** | Assume failure, ask what happened | Surfaces what optimism hides |
-| **Threat modeling** | "How would I attack this?" before building | Catch vulnerabilities at design time, not after breach |
-
----
-
-## When Inversion Is Especially Powerful
-
-- **"There's only one way to do this"** — almost always wrong; inversion finds the alternatives
-- **Solution feels forced or fights the system** — you're working against an inverted constraint
-- **Can't articulate *why* the current approach is necessary** — the assumption may not hold
-- **About to make an irreversible decision** — pre-mortem first, always
-- **Building something that "should" be secure, fast, or correct** — invert to find where those properties break
-- **Starting a new project or architecture** — "how would this fail in 12 months?" before a single line of code
-
----
-
-## Failure Modes of Inversion
-
-**False dichotomies:** Not every problem has a clean opposite. "How do we make users happy?" doesn't cleanly invert. Inversion works best when the domain is genuinely bipolar.
-
-**Mistaking the inverted list for a complete solution:** The pre-mortem identifies failure modes, not solutions. "Here's how we'd fail" → "here's our mitigation plan" is additional work.
-
-**Over-correcting on the inverted insight:** "Ship less frequently caused problems" doesn't mean "ship every 5 minutes without review." The inversion reveals the direction of improvement, not the optimal point.
-
-**Stopping at the inversion:** Inversion gives you the floor (don't do these things). It doesn't give you the ceiling (what excellent looks like). Combine with forward thinking.
-
----
-
-## Quick Reference
-
-| Want to... | Inversion move |
-|-----------|---------------|
-| Stress-test an architecture | Pre-mortem: "It failed in 12 months — why?" |
-| Design a better API | "What would make this API impossible to use?" |
-| Find security holes | "How would an attacker break this?" |
-| Improve code quality | "Under what conditions does this code fail?" |
-| Improve a process | "What would we do to guarantee this process fails?" |
-| Escape a local maximum | "What assumption am I making that isn't necessarily true?" |
-
----
-
-> "Spend less time trying to be brilliant and more time trying to avoid obvious stupidity." — Shane Parrish

package/skills/problem-solving/inversion-exercise/skill.json

@@ -1,9 +0,0 @@
-{
-    "version": "1.1.0",
-    "name": "superpowers:problem-solving/inversion-exercise",
-    "title": "Inversion Exercise",
-    "aliases": [
-        "inversion-exercise",
-        "problem-solving/inversion-exercise"
-    ]
-}