TL;DR
SkillFusion is a skill "compiler." It takes several SKILL.md files written by different people and builds one out of them. First, each file is broken down into individual rules, and each rule gets a type and an activation condition ("when it applies"). Then the model looks for pairs of rules that conflict with or duplicate each other. Each kind of pair gets its own operation.
The key finding: if you just concatenate the skills one after another, the agent has to sort out the contradictions on the fly. It does this badly and silently. One rule says "edit formulas with openpyxl," another says "standard library only." The agent does something in between or picks at random. On one benchmark, concatenation turned out worse than having no skills at all. And the more rules there are, the bigger the gap over concatenation: on large sets, merging delivers more than a 2.5x gain in success rate.
The method works in three stages. First, parsing: rule, type, condition, source reference. Then pair detection with a verdict of "hard conflict / soft conflict / duplicate / compatible." A skeptical second judge rechecks low-confidence verdicts. Finally, three different operations: a hard conflict is resolved by routing on the condition or an explicit priority, a soft one by a shared wording, a duplicate by keeping the more specific rule.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1. PARSING (Parser): each skill → a list of rules
→ {type, rule text, activation condition, source}
Types: FORMAT / BEHAVIOR / TOOL / PRIORITY / STYLE
STEP 2. PAIR DETECTION (Classifier + Verifier)
2a. Take pairs: same type + overlapping conditions
2b. Safety net: add pairs where the type/condition is unclear,
the condition is "always," or the rules are very similar in meaning
2c. Verdict per pair: ⊕ hard conflict / ⊖ soft /
≡ duplicate / ⊥ compatible + confidence + reason
2d. If confidence < 0.65 → a second judge
(skeptic) → final call by confidence
STEP 3. RESOLUTION (Resolver) by pair type
⊕ → "if {condition} — rule A, otherwise — B"
or an explicit priority + a fallback
⊖ → one shared wording that violates neither rule
(check: contradicts neither A nor B)
≡ → keep the more specific one, drop the weaker
→ compress repetition, check the result against the sources
→ build a new description (name/desc) so the skill gets found
In the original these are separate model calls (4 roles).
In a chat you can do the same sequentially, in one conversation.
Example
Task: An automation studio running Claude Code serves Amazon sellers. Two skills from different authors are enabled in the project.
- Skill A "Editing Excel reports": "Edit formulas and formatting only via openpyxl. Always add detailed comments to every code block."
- Skill B "Auditing exports": "Check file integrity using only the Python standard library, no external dependencies. Write code as concisely as possible."
- Duplicate: both skills require "don't overwrite existing formulas."
The agent either drags openpyxl into the audit or breaks conciseness with comments. You need one consistent skill.
Prompt:
You are an instruction compiler for an agent. Merge two skills into one without losing any requirements.
SKILL A "Editing Excel reports":
- Edit formulas and formatting only via openpyxl.
- Always add detailed comments to every code block.
- Don't overwrite existing formulas.
SKILL B "Auditing exports":
- Check file integrity using only the Python standard library, no external dependencies.
- Write code as concisely as possible.
- Don't overwrite existing formulas.
Work step by step:
STEP 1. Parse each rule: type (FORMAT/BEHAVIOR/TOOL/PRIORITY/STYLE), activation condition (when it applies: work phase, file type, tool), source (A or B).
STEP 2. For each pair of rules with the same type or an overlapping condition, give a verdict: ⊕ hard conflict / ⊖ soft conflict / ≡ duplicate / ⊥ compatible. Give a confidence of 0–1 and a reason. If confidence is below 0.65, recheck the pair skeptically: try to prove the opposite.
STEP 3. Resolve by type: ⊕ — a conditional "if…, then…" rule or an explicit priority; ⊖ — a shared wording that violates neither rule; ≡ — keep the more specific one.
STEP 4. Output the final SKILL.md and a table "merged skill rule → which source rules it came from."
Result: The model produces a table of rules with types, conditions and sources, then a list of pairs with verdicts and confidence. You'll see that "openpyxl" versus "standard library only" is a hard conflict, resolved by splitting by phase (editing — openpyxl, auditing — standard library). "Detailed comments" versus "concise" is a soft conflict with a shared wording. "Don't overwrite formulas" is a duplicate, and one rule remains. At the end you get a ready SKILL.md with source references for every rule.
Why It Works
Weakness. When several skills sit in context one after another, the model resolves contradictions "on the fly" and doesn't tell you. The more rules there are, the more often it follows only part of them or compromises. The research the authors cite shows the same thing: as the number of requirements grows, quality drops and conflicts get swept under the rug.
Strength. The model is good at narrow, local tasks: breaking text into rules, comparing two wordings, coming up with an "if… then…" condition. When it looks at one pair of rules rather than 50 at once, it makes fewer mistakes.
How the method exploits this. It turns a sweeping "reconcile everything" into a series of small questions, each with a clear operation as output. The activation condition (scope) removes some conflicts: "openpyxl" and "standard library" don't clash if they're about different phases. The link to the source lets you check that a merged rule didn't lose the original. The skeptical second pass guards against overcaution: it keeps compatible rules from being declared a conflict.
Control knobs: - Confidence threshold (0.65) → raise it and the skeptic checks more pairs, but you spend more tokens. - List of rule types → add your own (for example, TONE, SAFETY) if you have specialized instructions. - Safety-net pairs (global "always," similar in meaning) → don't turn them off: the authors showed that without them, real conflicts get lost. - Compression → if the merged skill is too long, ask for heavier compression. But the authors chose preserving requirements over maximum text reduction.
Prompt Template
The study's verbatim prompts are in appendices E and F, which aren't in the available text. The template below was assembled from the method description: the same roles, types, thresholds and three resolution operations.
<Role>
You are an instruction compiler. Task: merge several skills
into one SKILL.md, keeping every requirement and explicitly resolving conflicts.
Don't silently drop anything. Link every merged rule to its source.
</Role>
<Skills>
SKILL_1 "{name_1}":
{skill_text_1}
SKILL_2 "{name_2}":
{skill_text_2}
{SKILL_3_if_needed}
</Skills>
<Stage1_Parse>
Break each skill into minimal rules. For each one:
- id (for example, 1.3)
- type: FORMAT | BEHAVIOR | TOOL | PRIORITY | STYLE
- directive: one rule, one idea
- scope: when it applies (task type, work phase, file type,
tool) or GLOBAL if unconditional
- source: which skill and which line
If a rule is hidden in a script, pull it out too.
</Stage1_Parse>
<Stage2_Detect>
Build pairs of rules from DIFFERENT skills:
1. Main pairs: same type AND overlapping scope.
2. Safety-net pairs: type or scope is unclear; one of the rules is GLOBAL;
the rules are very similar in meaning.
For each pair output:
- label: ⊕ (hard conflict: incompatible actions at the same decision point)
⊖ (soft conflict: competing priorities, but no contradiction)
≡ (duplicate)
⊥ (compatible)
- confidence: 0..1
- rationale: one sentence
If confidence < 0.65 — run Adversarial_Verifier:
reread the pair skeptically and try to prove the verdict wrong
(especially: was the contradiction made up?). The final call is the verdict with higher
confidence; on a tie, choose the more cautious one.
</Stage2_Detect>
<Stage3_Resolve>
By pair type:
- ⊕ → if the scopes can be separated: "IF {condition} → rule A, OTHERWISE → rule B".
If there's no reliable condition: a block "Priority: A over B;
fallback: …".
- ⊖ → write one shared rule that covers both
(no narrower than either, violates neither).
Check: does it violate A? does it violate B?
If either check fails — go down the ⊕ branch.
- ≡ → keep the more specific wording, drop the weaker one.
- ⊥ → keep both as is.
After resolving: group shared rules, merge by topic,
bring the structure to a single format. Check every merged rule
against the sources: was anything lost?
</Stage3_Resolve>
<Output>
1. Rule table (id, type, scope, source)
2. Pair table (pair, label, confidence, resolution)
3. Final SKILL.md
4. Metadata: name and description written to cover both source skills
5. Traceability table: merged skill rule → source ids
</Output>
What to fill in: {name_N} — the skill's name; {skill_text_N} — the full contents of SKILL.md. If a skill has scripts, paste their key checks as a separate block, because some requirements are baked into the code.
🚀 Quick start — paste into the chat:
Here is the SkillFusion template. Adapt it to my task: I want to merge {how many} skills/agent instruction files into one.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask which skills or instruction files you're merging, where they're used (which tasks and work phases) and whether there are scripts. It needs this to fill in scope — the activation conditions — correctly. Those decide which "conflicts" turn out to be imaginary. It will take the rest from the template's pattern.
Limitations
⚠️ The method is implemented as code: the authors built an offline pipeline of separate model calls with a pair graph and thresholds. The code hasn't been published yet. The "all in one chat" version follows the idea of the method but hasn't been tested in that form.
⚠️ The prompts aren't in the text: the verbatim instructions for the parser, the judges and the resolver are in the appendices. The template above was reconstructed from the description, not copied.
⚠️ Merging isn't always stronger than choosing: on software engineering tasks (SWE-bench), the best single skill, chosen after the fact, stayed stronger than the merged one. So sometimes it's simpler to pick one suitable skill.
⚠️ Saves less text: the method deliberately compresses less than rewrite-with-critique. It preserves requirements rather than fighting for length.
⚠️ One set of models: merging was done with one model and tested on three executors. The pools are small, five skills per benchmark. The gain over a strong baseline is a few percentage points.
⚠️ Needs human review: the classifier model makes mistakes too. Without spot-checking the pairs, you can end up with a merged skill containing an imaginary or missed conflict.
How They Tested It
The researchers collected five independent public skills for each of three benchmarks: spreadsheet editing (400 tasks), browser work (812 tasks) and fixing bugs in code (500 tasks). They compared different ways of combining: no skills, simple concatenation, loading all skills at once, a one-shot rewrite, skill routing, a "rewrite — critique — revise" loop (3 calls) and SkillFusion. For reference they added an "oracle": the best single skill for each task, chosen after the fact.
Merging was done by DeepSeek-V3.2. The finished skill was then run on three executors, including GLM-4.7 and MiniMax-M2.5, and every measurement was repeated three times. Against a strong baseline (RCR), SkillFusion gave plus 4.8, 4.0 and 3.8 percentage points, and the confidence intervals of the difference don't include zero. On spreadsheets, simple concatenation scored below the no-skills variant, while SkillFusion beat even the "oracle."
A human audit showed where the method breaks. The strict "same type and overlapping conditions" filter missed real conflicts. The safety-net check recovered 14 of 24 missed incompatible pairs, and F1 rose from 0.713 to 0.840. The takeaway: get the type or condition wrong once and the system will never reach the conflict. That's why you need a "second look."
For the mechanisms, the authors used HumanEval+ (164 tasks) and 12 synthetic code-style directives. Performance dropped with every kind of interaction — hard, soft and duplicate. The combination hit hardest. As the count grew to 140 constraints, merging's advantage over raw loading kept growing: in the largest configurations the success rate was 2.5 times higher.
Original From the Paper
The structure of a typed constraint, the pair filter and the hard-conflict resolution formula are verbatim from the paper.
Definition 2 (Typed Constraint)
A typed constraint c = (τ, δ, σ) consists of a behavioral type τ,
directive text δ, and activation scope σ, with
τ ∈ {FORMAT, BEHAVIOR, TOOL, PRIORITY, STYLE}.
E_strict = {(c_i, c_j) : τ_i = τ_j ∧ σ_i ∩ σ_j ≠ ∅}.
Classifier labels: ⊕ (hard conflict), ⊖ (soft conflict),
≡ (redundancy), ⊥ (compatibility).
Verifier re-evaluates low-confidence verdicts (γ < 0.65)
under a skeptical counter-prompt.
δ_ij^merge(t) = δ_i, if φ_ij(t); δ_j, otherwise.
If no reliable discriminator exists, SkillFusion falls back to
an explicit disambiguation block that specifies a priority and fallback.
Context: The formulas describe an offline compiler. The authors put the full prompt texts for the roles in appendices E and F; they aren't in the excerpt provided.
Adaptations and Extrapolations
💡 Adaptation for CLAUDE.md / a system prompt: the method applies to more than skills. Any long instructions file has contradictions: "be brief" in one paragraph and "explain in detail" in another. The authors didn't test this idea, but the mechanics are the same.
Here is my agent instructions file: {text}.
Break it into individual rules (type, activation condition).
Find pairs that: (a) demand incompatible things in the same situation,
(b) compete on priority, (c) repeat each other.
For each pair — a verdict and confidence. Where confidence is below 0.65,
recheck skeptically. Then propose a corrected version:
conditional "if… then…" for hard conflicts, a shared wording
for soft ones, one rule instead of duplicates. Don't delete anything without flagging it.
🔧 Technique: add a scope to every rule you write → fewer "false" conflicts. Write rules with a condition: "When editing formulas — openpyxl. When auditing — standard library only." The condition turns half the contradictions into compatible rules. This follows from the method's logic: the authors show that without distinguishing phases, a useful separation of responsibilities looks like a conflict.
Resources
- SkillFusion: Towards Reliable Multi-Skill Composition for LLM Agents
- Authors: Enhao Huang, Xinye Zhao, Yiming Li, Bingrun Yang, Nanjun Zhou, Chunshu Xia, Hongwei Yao, Zhan Qin
- Universities: Zhejiang University, Nanjing University, Nanyang Technological University, City University of Hong Kong
- Benchmarks: SpreadsheetBench Verified, WebArena-Verified, SWE-bench Verified, HumanEval+
- Related work cited in the paper: ComplexBench, RECAST, ConInstruct (on how models lose requirements and silently compromise compliance under conflicts); SkillRouter (skill routing)
- Code: promised after peer review