@complexthings/superpowers-agent 8.1.0

package/skills/meta/writing-prompts/skill.json

@@ -0,0 +1,9 @@
+{
+    "version": "1.0.0",
+    "name": "superpowers:meta/writing-prompts",
+    "title": "writing-prompts",
+    "aliases": [
+        "writing-prompts",
+        "meta/writing-prompts"
+    ]
+}

package/skills/problem-solving/ABOUT.md

@@ -0,0 +1,40 @@
+# Problem-Solving Skills - Attribution
+
+These skills were derived from agent patterns in the [Amplifier](https://github.com/microsoft/amplifier) project.
+
+**Source Repository:**
+- Name: Amplifier
+- URL: https://github.com/microsoft/amplifier
+- Commit: 2adb63f858e7d760e188197c8e8d4c1ef721e2a6
+- Date: 2025-10-10
+
+## Skills Derived from Amplifier Agents
+
+**From insight-synthesizer agent:**
+- simplification-cascades - Finding insights that eliminate multiple components
+- collision-zone-thinking - Forcing unrelated concepts together for breakthroughs
+- meta-pattern-recognition - Spotting patterns across 3+ domains
+- inversion-exercise - Flipping assumptions to reveal alternatives
+- scale-game - Testing at extremes to expose fundamental truths
+
+**From ambiguity-guardian agent:**
+- (architecture) preserving-productive-tensions - Preserving multiple valid approaches
+
+**From knowledge-archaeologist agent:**
+- (research) tracing-knowledge-lineages - Understanding how ideas evolved
+
+**Dispatch pattern:**
+- when-stuck - Maps stuck-symptoms to appropriate technique
+
+## What Was Adapted
+
+The amplifier agents are specialized long-lived agents with structured JSON output. These skills extract the core problem-solving techniques and adapt them as:
+
+- Scannable quick-reference guides (~60 lines each)
+- Symptom-based discovery via when_to_use
+- Immediate application without special tooling
+- Composable through dispatch pattern
+
+## Core Insight
+
+Agent capabilities are domain-agnostic patterns. Whether packaged as "amplifier agent" or "superpowers skill", the underlying technique is the same. We extracted the techniques and made them portable.

package/skills/problem-solving/collision-zone-thinking/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: collision-zone-thinking
+description: Force unrelated concepts together to discover emergent properties — "What if we treated X like Y?" Use this skill whenever someone says they're stuck, need a breakthrough idea, want to think outside the box, feel like they've exhausted options in their domain, or need innovation rather than optimization. Also use it when a user asks how a well-known software pattern (circuit breakers, MapReduce, reactive programming, event sourcing) was originally invented — these are all cross-domain collisions. Trigger any time someone needs a novel angle on a hard problem.
+---
+
+# Collision-Zone Thinking
+
+## Overview
+
+Revolutionary insights come from forcing unrelated concepts to collide. The cognitive science behind this is real: **bisociation** (Koestler), **conceptual blending** (Fauconnier & Turner), and TRIZ's cross-domain patent analysis all confirm the same mechanism — breakthrough thinking requires connecting two previously separate frames of thought, not finding better answers within a single frame.
+
+**Core principle:** Import the *mechanism*, not the metaphor. You're not renaming things. You're borrowing how a different system solves the same structural problem.
+
+> For historical evidence that this technique produces real results — Bloom filters, MapReduce, the Actor model, circuit breakers, consistent hashing, event sourcing — see `references/historical-examples.md`.
+
+---
+
+## Quick Reference: High-Yield Domain Pairs
+
+| Problem Type | Source Domain | Key Mechanisms to Import |
+|-------------|---------------|--------------------------|
+| Distributed failures | Electrical circuits | Circuit breakers, grounding, load balancing |
+| Service discovery | Ant colonies | Stigmergy, pheromone trails, positive feedback |
+| Caching / memory | Immune system | Memory cells, tolerance, autoimmunity as bugs |
+| Load shedding | Emergency triage | Priority queues, do-not-resuscitate patterns |
+| Code evolution | Natural selection | Fitness landscape, punctuated equilibrium, drift |
+| API design | Linguistics | Syntax vs. semantics, pragmatics, ambiguity |
+| Security / access | Epidemiology | Vectors, quarantine, herd immunity, patient zero |
+| Team structure | Ecology / niches | Keystone species, competitive exclusion, succession |
+| Rate limiting | Fluid dynamics | Backpressure, throttle valves, laminar vs. turbulent |
+| Technical debt | Financial debt | Compound interest, default, debt restructuring |
+| Observability | Neuroscience | Proprioception, signal vs. noise, nociception |
+| Consensus | Democracy / voting | Quorum, veto power, majority vs. supermajority |
+| Data pipelines | Manufacturing | Bottlenecks, WIP limits, buffer overflow, just-in-time |
+| Optimization | Evolution / genetics | Fitness function, mutation, selection pressure |
+
+---
+
+## Process
+
+### 1. Escape the Problem's Frame
+- State the problem in plain language
+- Identify its structural type: optimization? coordination? failure prevention? scaling? discovery?
+- Strip domain-specific vocabulary — find the structural bones
+- Ask: *"What is this problem really about?"*
+
+### 2. Select and Enter the Source Domain
+- Choose a domain that solves the same **structural problem type** (not the same surface domain)
+- Go deep enough to articulate **at least 5 mechanisms** — don't just name the domain, explain how it works
+- Ask: *"How does this system solve this type of problem?"*
+
+**Good source domains:** biology, ecology, electrical engineering, fluid dynamics, economics, military strategy, immunology, linguistics, thermodynamics, accounting.
+
+**Avoid:** adjacent tech domains (too similar), domains you barely understand (too shallow).
+
+### 3. Collide
+- Force the combination: *"What if we treated [A] like [B]?"*
+- Run it as a simulation — elaborate it forward, don't just state it
+- For each mechanism you listed, ask: *"What would the equivalent be in my domain?"*
+- Note **emergent properties** — things the blend implies that weren't in either input
+
+### 4. Test the Breakdown
+- Find where the metaphor breaks — it always does
+- Ask: *"What does the source domain have that my domain lacks?"* (potential to add)
+- Ask: *"What does my domain have that the source domain lacks?"* (constraints to respect)
+- **Treat the breakdown as signal, not failure.** Where the metaphor stops fitting reveals what's genuinely unique about your domain — and often points to the most important design decision.
+
+### 5. Extract
+- Name the concrete mechanisms you're borrowing
+- Generate at least one testable hypothesis or design change
+- Document breakdown points — they define the insight's scope
+
+---
+
+## Evaluating the Collision
+
+| Question | What It Checks |
+|----------|---------------|
+| **Does the structural relationship map, or only the surface?** | Borrowing names is decoration; borrowing mechanisms is insight |
+| **Does the source domain reveal *why*, not just *what*?** | Causal mechanisms are what you're actually importing |
+| **Does the breakdown point reveal something useful?** | Productive breaks expose hidden constraints or design decisions |
+
+**Signs a collision is productive:** Emergent properties appear. You discover constraints you hadn't named. The source suggests experiments you wouldn't have thought of. The breakdown reveals a gap worth engineering around.
+
+**Signs a collision is superficial:** You're borrowing vocabulary, not mechanisms. You could have had the same insight without the analogy. No emergent structure appears — the blend is flat.
+
+---
+
+## Worked Example 1: Circuit Breakers
+
+**Problem:** Complex distributed system with cascading failures
+
+**Escape:** This is a *failure propagation* problem — how to prevent one failing component from overloading others.
+
+**Source domain activated:** Electrical circuits
+- Mechanism 1: Circuit breakers disconnect on overload
+- Mechanism 2: Fuses provide one-time, non-recoverable protection
+- Mechanism 3: Grounding routes dangerous current safely away
+- Mechanism 4: Load balancing distributes current across paths
+- Mechanism 5: Isolation prevents short-circuit propagation between components
+
+**Collision:** *"What if we treated services like electrical circuits?"*
+
+**Emergent properties:**
+- Circuit breakers → automatic service disconnection when error rates spike
+- Grounding → dedicated error-sink services that absorb failures
+- Load balancing → traffic redistribution under stress
+- Series vs. parallel circuits → synchronous vs. async dependency graphs
+
+**Where it breaks:** Circuits don't have retry logic, state, or dynamic reconfiguration.
+
+**What the breakdown reveals:** Distributed systems have *memory* and *intent* that circuits lack — that's why retry logic, exponential backoff, and health checks exist. The breakdown is the specification for the Half-Open state that Michael Nygard invented — an entirely software-native concept with no electrical equivalent.
+
+**Insight extracted:** Borrow the three-state model (closed/open/half-open); add retry and health-check logic exactly where the analogy breaks.
+
+---
+
+## Worked Example 2: Event Sourcing
+
+**Problem:** Distributed write-heavy systems need audit trails, temporal queries, and consistency — but mutable state makes all three hard.
+
+**Escape:** This is a *state history* problem — how to track what happened, when, and be able to reconstruct any past state.
+
+**Source domain activated:** Double-entry bookkeeping (accounting, ~1494)
+- Mechanism 1: Transactions are never modified, only appended to the ledger
+- Mechanism 2: Account balance is *derived* from history, not stored directly
+- Mechanism 3: Every change is recorded from two perspectives (debit and credit)
+- Mechanism 4: The complete ledger is the source of truth — summaries are projections
+- Mechanism 5: Audit trail is the data, not a separate system bolted on
+
+**Collision:** *"What if we treated our database like a ledger?"*
+
+**Emergent properties:**
+- Event store → complete replay of any past state (time travel)
+- Derived projections → different read models from the same event stream
+- Immutable log → audit trail for free, debugging by replay
+- Append-only writes → no write contention on past records
+
+**Where it breaks:** Schema evolution is hard (old events must be readable with new schemas), and replaying years of events to reconstruct current state is slow.
+
+**What the breakdown reveals:** Bookkeepers solved schema evolution via versioned document formats and transition rules — software systems need the same: event versioning and migration scripts. The "slow replay" breakdown is the specification for snapshot strategies. Both breakdowns have direct solutions.
+
+**Insight extracted:** Immutable event logs as primary data; projections as derived views; snapshots for performance; versioned schemas for evolution. This is the event sourcing pattern that underlies Kafka, CQRS, and git.
+
+---
+
+## Common Pitfalls
+
+**Surface analogy trap:** Borrowing vocabulary but not mechanisms. "Let's call modules 'genes'" is renaming, not insight. Insight is: *"What would selection pressure mean for code? What would mutation rate mean? What would epistasis mean?"*
+
+**Stopping too early:** Generating the collision but not running it. Commit to 5–7 mechanisms before claiming the collision is complete.
+
+**Adjacent-domain trap:** Choosing source domains that are too similar — produces incremental thinking, not breakthrough. Physics, biology, and economics produce more insight than other tech systems.
+
+**Discarding breakdowns:** Treating metaphor failures as dead ends. Every breakdown is a signal about what's genuinely different in your domain — and that's where the deepest insight lives.
+
+---
+
+## When to Reach for This
+
+- "I've tried everything in this domain"
+- Solutions feel incremental, not breakthrough
+- Need innovation, not optimization
+- The problem feels structurally familiar but solutions in this domain have stalled
+- You're asked how a well-known pattern (circuit breakers, MapReduce, event sourcing) was invented
+
+---
+
+## Source Domain Selection Rubric
+
+Use this to assess if a domain is worth entering deeply:
+
+1. **Structural richness:** Does it have well-developed causal mechanisms, or just patterns?
+2. **Surface dissimilarity:** Is it genuinely alien to your problem domain? (More different = more novel)
+3. **Your familiarity:** Can you articulate 5+ mechanisms, or are you guessing?
+4. **Validated solutions:** Has this domain solved its problems under real pressure (evolution, markets, physics)?
+
+If you can't articulate 5 mechanisms from the source domain, go deeper before colliding.
+
+---
+
+## Reference
+
+For 11 historical examples of real cross-domain collisions that became software foundations — with full collision-zone analysis for each — see:
+
+`references/historical-examples.md`
+
+Use them as templates, as evidence this technique produces real results, or as a starting inventory when you're selecting source domains.

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

@@ -0,0 +1,393 @@
+# 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

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