| name | explore-cross-domain |
| description | Explore a problem by borrowing mechanisms from other domains and turning them into concrete product or engineering directions. Use this skill when the user is in an early discovery, strategy, architecture, or proposal phase, especially if the problem has multiple plausible solutions, important trade-offs, coordination or incentive issues, feedback loops, scale concerns, or the user explicitly wants ideas from other domains instead of the obvious conventional answer. |
Skill: explore-cross-domain
Purpose
Enhance the OpenSpec explore/propose phase with structured cross-domain exploration.
Use it to uncover stronger product or engineering directions by identifying mechanisms from other domains and converting them into concrete proposal and design inputs.
When to Use
Use this skill during exploration when:
- the problem is non-trivial
- there are multiple plausible solution paths
- the obvious solution may be too narrow or conventional
- the user asks for adjacent-domain analogies, mechanism borrowing, or outside-the-box exploration
- trade-offs are important
- resilience, coordination, adoption, incentives, scale, or feedback loops matter
Use lightly or skip when:
- the task is routine
- the solution is obvious and low-risk
- the user wants a standard implementation only
Role
You are assisting with OpenSpec exploration.
Your role is to improve early-stage thinking without derailing convergence.
You should use cross-domain exploration only to improve practical proposal/design quality.
Process
-
Begin with normal exploration:
- clarify goal
- identify users/stakeholders
- identify success criteria
- identify constraints
- identify unknowns
-
Decide whether cross-domain exploration is warranted.
If not, say so and continue with standard exploration.
-
If warranted, abstract the problem:
- objective
- bottlenecks
- actors
- coordination patterns
- feedback loops
- failure modes
- timing / scale / reversibility
-
Identify 3-4 relevant external domains with structural similarity.
-
For each domain, extract:
- analogous problem
- transferable mechanism
- required conditions
- non-transferable elements
-
Synthesize the findings into:
- possible solution directions
- useful design principles
- risks and caveats
- assumptions worth validating early
-
End by returning to OpenSpec exploration:
- if the user is ready to capture the idea, recommend
/opsx:propose or /opsx:new
- do not manually create files in
openspec/changes/
- make sure the transition preserves the context from exploration into proposal/design
- recommend what should influence proposal.md
- recommend what should influence specs/
- recommend what should influence design.md
Output Format
Explore Summary
1. Clarified Problem
- Goal:
- Users / stakeholders:
- Success criteria:
- Constraints:
- Unknowns:
2. Should We Use Cross-Domain Exploration?
3. Abstract Problem Structure
- Objective:
- Bottlenecks:
- Actors:
- Feedback loops:
- Failure modes:
- Scale / timing constraints:
4. Cross-Domain Insights
Domain A:
- Analogous problem:
- Transferable mechanism:
- Conditions required:
- What does not transfer:
Domain B:
- Analogous problem:
- Transferable mechanism:
- Conditions required:
- What does not transfer:
Domain C:
- Analogous problem:
- Transferable mechanism:
- Conditions required:
- What does not transfer:
5. Candidate Directions
- Direction 1:
- Based on:
- Why it may help:
- Trade-offs:
- Direction 2:
- Based on:
- Why it may help:
- Trade-offs:
- Direction 3:
- Based on:
- Why it may help:
- Trade-offs:
6. OpenSpec Implications
- proposal.md should capture:
- specs/ should clarify:
- design.md should evaluate:
- assumptions to test first:
- next OpenSpec action:
Constraints
- Keep exploration bounded and relevant.
- Prefer mechanisms over metaphors.
- Do not force cross-domain ideas when ordinary reasoning is enough.
- Return to practical software/product decisions quickly.
- Make assumptions explicit when context is incomplete.
