// Imports solutions from unrelated domains by finding structural similarities between your problem and solved problems elsewhere. Triggers: 'cross-domain analogy', 'what solves this elsewhere', 'find a parallel problem', 'look outside this field', 'borrow a solution'.
Master orchestration skill. Takes any situation in plain English, identifies the underlying goal, designs a multi-skill reasoning workflow, and executes it sequentially — feeding each skill's output into the next. Use when you say 'help me think through this', 'I need to figure out what to do', 'where do I start', or any time you want structured thinking applied end-to-end rather than routed to a single tool.
Tests whether the parts of something form a unified whole — finding the jarring inconsistencies that accumulate when different contributors work without a shared vision. TRIGGERS: 'coherence check', 'does this feel unified', 'something feels off', 'inconsistent', 'check the whole', 'does this hang together'.
Tests whether a solution is more complex than it needs to be — distinguishing necessary complexity from accidental complexity that accreted over time. TRIGGERS: 'elegance test', 'is this too complex', 'over-engineered', 'is there a simpler way', 'does this feel right'.
Identifies the underlying formal pattern at work — because most successful designs, arguments, and solutions share deep structural patterns, and naming the pattern unlocks the playbook. TRIGGERS: 'what pattern is this', 'pattern recognition', 'why does this work', 'identify the form', 'what structure is at play', 'what archetype is this'.
Finds the simpler version while preserving what matters — not arbitrary reduction, but finding the core and discarding what is not it. TRIGGERS: 'find the simple version', 'simplify this', 'what's the essence', 'less but better', 'strip it back', 'what could we remove'.
Entry point for the aesthetic toolkit. Routes to the right aesthetic skill based on your situation. Use when you say 'aesthetic', 'check the design', 'does this feel right', 'is this elegant', 'is this too complex', 'what pattern is this', 'find the simpler version', or want an aesthetic lens applied without knowing which specific tool fits.
| name | s4h-analogy-domain-transfer |
| description | Imports solutions from unrelated domains by finding structural similarities between your problem and solved problems elsewhere. Triggers: 'cross-domain analogy', 'what solves this elsewhere', 'find a parallel problem', 'look outside this field', 'borrow a solution'. |
Your field has blind spots that your field created. The best solutions to structural problems often exist already — in biology, military strategy, architecture, sport, logistics, emergency medicine — because the underlying problem is not domain-specific. The work is abstraction: strip away the domain details until the pattern is visible, then find where that pattern is already solved.
Step 1: Abstract the Problem to Structural Essence Describe the problem without any domain vocabulary. What is actually happening? What are the actors, their relationships, the failure mode, the goal? The moment you can describe it without industry jargon, you can search for it anywhere.
Framing check: Confirm the specific problem being transferred before continuing. State what you've identified — the actual challenge, its actors, and the failure mode or goal — in one sentence, then use AskUserQuestion:
Step 2: Search Candidate Domains Consider where this structural pattern appears: biology (systems, adaptation, immunity), military (logistics, command, deception), architecture (load, flow, resilience), sport (coordination, pressure, strategy), gaming (rules, incentives, escalation), logistics (sequencing, bottlenecks, routing), medicine (diagnosis, triage, recovery).
Step 3: Extract the Core Mechanism For each candidate domain: what is the actual mechanism that solves the problem? Not the surface story — the operational logic. How does it work, step by step?
Step 4: Map Mechanism Back Translate the mechanism into your problem. What plays what role? What would be the equivalent of each element? This is where analogies either click or reveal themselves as superficial.
Step 5: Test Where the Analogy Holds and Breaks Every analogy breaks somewhere. Where does the mechanism still work when mapped? Where does it stop working? The break points tell you where to be careful and where the insight ends.
Before proceeding, use the AskUserQuestion tool. State your interpretation of the situation in 1–2 sentences — what is being analyzed and what the core question is — then ask:
Proceed based on their selection. If the user reframes, incorporate the correction before running any analysis.
Problem (abstracted — no domain vocabulary):
[Structural description]
Candidate domains and mechanisms:
| Domain | Analogous problem | Core mechanism | Strength of match |
|---|---|---|---|
Best mapping:
Where the analogy holds:
[Specific aspects]
Where the analogy breaks:
[Specific aspects — don't skip this]
Insight to import:
[The actionable mechanism translated back into your problem]
A weak abstraction in Step 1 produces weak domain matches. If the domains found feel obvious or already-familiar, the abstraction still contains domain assumptions — strip further.
After delivering this output, use AskUserQuestion to offer the next move:
/s4h-logic-check — Validate that the transfer holds and conclusions follow/s4h-analogy-boundary-testing — Test where the analogy breaks down/s4h-creativity-alternatives — Use the transferred ideas to generate new alternatives