analogy-transfer

name	analogy-transfer
description	Solve a problem by systematically importing solutions from other domains: abstract the problem's deep structure, find 3–5 domains that share that structure, study how each solved it, and translate the mechanisms back — with an explicit disanalogy check. Use for 'how do other fields handle this?' and stuck problems that feel like they must have been solved somewhere before.
compatibility	Created for Zo Computer
metadata	{"author":"rob.zo.computer"}

Analogy Transfer

Use this skill to solve a problem by finding where else its deep structure appears and importing the mechanisms that worked there. Most hard problems have already been solved — in a different domain, under a different name.

Purpose

Analogy is the engine of invention (immunology → spam filtering, biological evolution → genetic algorithms, just-in-time manufacturing → lean software). But casual analogy fails by matching surface features instead of structure, and by ignoring where the analogy breaks. This skill makes the mapping explicit in both directions: what transfers, and what doesn't.

Procedure

1. State the problem concretely.
2. Abstract to structure: strip domain nouns and restate the problem in structural terms — flows, constraints, incentives, feedback loops, adversaries, scarcity. ("How do we onboard users?" → "How does a system get a newcomer to competence before frustration exceeds motivation?")
3. Search for structural twins: find 3–5 domains sharing that structure. Deliberately search far — biology, military, cities, games, religion, logistics, law, sports. Nearby domains give weak analogies.
4. For each twin domain:
   • How does it solve the structural problem?
   • What named mechanism does the work?
5. Translate back: for the 2–3 strongest mechanisms, state what the equivalent move would be in the original domain.
6. Disanalogy check: for each candidate transfer, name where the domains differ and whether the difference breaks the mechanism. This step is mandatory — it is what separates insight from vibes.
7. Recommend the strongest transfer(s) and the cheapest way to pilot them.

Output format

Use this concise structure unless the user asks otherwise:

## Problem
...

## Structural form
...

## Structural twins
| Domain | Their version of the problem | Their mechanism |
|---|---|---|

## Candidate transfers
1. **Mechanism → translated move**: ...

## Disanalogy check
| Transfer | Where the analogy breaks | Survives? |
|---|---|---|

## Recommendation
...

Guardrails

• Match structure, not vocabulary. Two domains that share buzzwords rarely share mechanisms.
• At least one twin must come from a domain far from the user's field.
• The disanalogy check is not optional; an analogy without a stated breaking point is decoration.
• Prefer mechanisms with a track record over poetic parallels.

Canonical questions

• "How should we handle content moderation at scale?" (immune systems, courts, city policing)
• "How do we keep our best engineers from leaving?" (sports free agency, academic tenure, guilds)
• "How should our API handle abusive clients?" (traffic engineering, antibody response, bouncer economics)
• "How do we onboard new users faster?" (military basic training, video game tutorials, apprenticeships)
• "How do we price this new product?" (airline yield management, theater tickets, wine)

Poor fits: problems already well-solved in-domain (just use the standard solution), and problems so novel or so simple that structural twins add noise.