cross-domain-function-transfer

Files (1)

• SKILL.md

SKILL.md (first lines)

# Cross-domain Function Transfer

## Inputs

- Accepted InnovationOpportunityMap and traceable evidence source refs.
- CategoryProfile, hard constraints, and available manufacturing/compliance boundaries.

## Procedure

1. For every inspiration source, create a `FunctionTransferCard`: source ref, source category, observed function, transferable principle, target job, boundary mismatch, transfer risk, and IP caution.
2. Generate directions through defect elimination, compatible-function combination, and cross-domain transfer. Cosmetic, color-only, branding, or wording variations do not count.
3. For each direction record the mechanism, pain refs, inspiration refs, parameter assumptions, materials/process hypotheses, user-value gain, trade-offs, likely failure modes, and validation tasks.
4. Record questions that must be answered by Supply, Economics, and Compliance; never answer them on those roles' behalf.
5. Converge to three materially different direction families: low-risk baseline, balanced recommendation, and high-differentiation exploration.
6. Add a visual brief for Prototype Designer without generating an image or inventing features outside the direction.
7. Output `ConceptDirectionSet` with every direction marked `DESIGN_HYPOTHESIS`.

## Failure Path

- Missing source ref -> discard the transfer card rather than cite an untraceable idea.
- Boundary unknown -> retain the direction as provisional with a named validation owner.
- Direction differs only in styling -> reject and regenerate a mechanism-level alternative.
- Patentability or freedom-to-operate requested -> flag specialist review; do not make a legal conclusion.

From Orionxu6/gap2sku, Apache-2.0.

More from Orionxu6/gap2sku