Generate non-obvious hypotheses by decomposing a problem to its mechanism and raiding distant fields for transferable patterns. Use when the user asks "what are we missing", wants to go deeper, needs cross-domain ideas, is stuck in a local optimum, or wants brainstorming that goes beyond standard advice.
name lateral-thinking description Generate non-obvious hypotheses by decomposing a problem to its mechanism and raiding distant fields for transferable patterns. Use when the user asks "what are we missing", wants to go deeper, needs cross-domain ideas, is stuck in a local optimum, or wants brainstorming that goes beyond standard advice. license MIT metadata {"author":"Andy Pai","version":"1.0","upstream_skill":"https://github.com/ogiberstein/lateral-thinking-skill"} Lateral Thinking Generate novel, testable ideas by finding mechanisms that transfer across fields. Adapted from ogiberstein/lateral-thinking-skill , with a repo-native rewrite for portability and clearer boundaries with nearby skills. Use this skill when ordinary analysis is already exhausted and the user needs a good second or third lens, not a recap of the obvious first one. When To Use It Trigger on requests like: "What are we missing?" "Go deeper" "Think laterally" "Think cross-domain" "We keep trying the obvious fixes and nothing changes" "Give me non-obvious ideas" Typical fit: product and strategy dead ends system design problems with repeated failure patterns research ideation policy, operations, growth, or process problems that feel trapped in local optimization When Not To Use It If the user first needs a clean explanation of what a system is , use distill If the task is ordinary brainstorming with no need for mechanism-level transfer, a normal ideation pass is often enough If the user needs a literature review or a standard best-practices answer, do that directly Relationship To distill distill compresses a system to its essential primitives lateral-thinking uses those primitives to generate non-obvious hypotheses When both apply: Distill the problem first if the mechanism is still muddy Then use lateral thinking on the clarified skeleton Ring Model Start beyond the obvious. Ring 0-1: standard advice, baseline literature, first-order domain answers Ring 2: component decomposition and overlooked regulators Ring 3: cross-domain transfer of mechanisms from distant fields Do not waste most of the response on Ring 0-1. A brief baseline is fine only if it helps make the lateral leap understandable. Workflow
[Working problem skeleton]
...
Estimated impact:
...
[Hypothesis]: SURVIVES / DOWNRANKED / KILLED
...
... 2. ... 3. ... Guardrails Favor mechanism transfer over decorative analogy Every surviving idea must imply a concrete test or next step Do not turn this into a standard literature review Do not spend the answer rehashing Ring 0-1 advice Novelty is useful only if it survives the adversarial pass Iteration If the best hypothesis changes the way the problem should be framed, run one more cycle with the updated skeleton. Stop when: the skeleton stabilizes a second pass adds little the user has enough to test Update Check On first use in a session, silently check for a newer version: Fetch https://raw.githubusercontent.com/abpai/skills/main/versions.json Compare the version for lateral-thinking against this file's metadata.version If the remote version is newer, pause before the main task and ask: lateral-thinking update available (local {X.Y} → remote {A.B}). Would you like me to update it for you first? I can run npx skills update lateral-thinking for you. If the user says yes, run the update before continuing If the user says no, continue with the current local version If the fetch fails or web access is unavailable, skip silently