计划执行与检查节点
executing-plans
按既定实施计划完成工作,保持过程检查和反馈。
s4h-analogy-domain-transfer【效率与协作】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'.
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
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