Skill Fusion

Real tasks ignore taxonomy: the investor update that's half postmortem, the launch plan that's half legal review. Running two skills sequentially produces a stapled document. Fusion produces a hybrid — one structure that inherits deliberately from both parents, with explicit rules for their disagreements.

Required Inputs

• The two parent skills — by name if known; otherwise describe the task and identify the two best parents first (say which and why).
• The task itself — what's being produced, for whom. The audience decides which parent leads.
• The actual input material, if the fused skill should run immediately after being forged.

The Fusion Method

1. Declare the dominant parent — the audience's primary job determines it (a board reads the postmortem-update as an update first). The dominant parent contributes the skeleton; the recessive parent contributes organs.
2. Merge structures section by section — for each parent section: keep / merge / drop, with one-line reasons. A fused doc is SHORTER than the parents combined or the fusion failed.
3. Resolve conflicts explicitly — where parents disagree (a PRD wants exhaustive edge cases; a pitch wants momentum), write the precedence rule ("edge cases compress to the risk table; the narrative keeps pitch pacing").
4. Merge the quality bars — union of both parents' Quality Checks, minus those the fusion made irrelevant, plus 1-2 new checks that only the hybrid needs ("the metrics section satisfies both the update reader who skims and the postmortem reader who audits").
5. Inherit both anti-pattern sets — hybrids fail in both parents' ways, plus one new way: the staple (sections that alternate voices). Check for the staple explicitly.

Output Format

1. The fusion header — parents, dominant parent + why, the task it's forged for.
2. The hybrid structure — the fused outline with per-section parentage marked (📘 parent A / 📗 parent B / ⚗️ new).
3. The merged quality bar and anti-patterns — deduplicated, with the new hybrid-only entries flagged ⚗️.