One Skill Takes Over: Same-Function Agent Skill Conflicts and a Single-File Fix

When both same-task skill files are in context, does the model merge compatible rules, or follow one and drop the other.

• Scenario: an Agent Skill is a small folder with a SKILL.md that tells a coding agent how to do a kind of thing, such as writing a commit message, reviewing code, or writing API documentation. Skills come from multiple authors and are installed side by side, and no mechanism prevents two same-task skills from taking effect at the same time. The authors state that some rules conflict, but most can be followed together.
• Gap in existing measurements: Yan et al. installed public same-task skill pairs in Claude Code, and the second skill took over about one in five runs from the first; the fix was to use a hook to block the competing skill. The authors state that in that setting the agent opens files on demand, most of the loss comes from runs that never opened the first skill, and only the first skill is scored.
• The remaining question: what the model does when both files are already in context; whether a fix can keep both sides' rules rather than block one of them. The authors call one kind of output takeover: rules belonging only to one skill are all followed, and rules belonging only to the other skill are all dropped.
• What this paper provides: the benchmark SKILLCLASH, 16 same-task skill pairs built for this benchmark, code checking each rule, and reference outputs marking the best achievable result. In Figure 1, Qwen3-4B with both skills loaded follows B's six rules, and of A only the shared rule remains; with a merged file substituted, that output follows all ten achievable rules.

How Agent Skills fail

• Gains from multiple skills: in SkillsBench by Li et al. (2026), curated skills raise task pass rates, and tasks using four or more skills gain less; conflicting guidance is proposed as one possible cause.
• Public skills and choosing the wrong skill: the paper writes that Han et al. (2026) saw little or no gain from most public skills on real software engineering tasks; Dong et al. (2026) write that a single loaded skill can make the agent miss or fill in the wrong part of the requirements; Song and Wei (2026) write that most of the harm in large skill libraries comes from choosing the wrong skill or not choosing a skill.
• Same-task conflict: Yan et al. (2026) measure, rule by rule as required, what side-by-side same-task skills cost the installed skill, and the fix is to block the competing skill. The authors state three differences from that work: both files are in context, both sides are scored against a known best output, and the fixes tested keep both skills.

Conflicting instructions

• Higher-privilege instructions: Wallace et al. (2024) use instruction hierarchy to train models to follow the higher-privilege of two conflicting instructions.
• Declared priority: Geng et al. (2026) write that models often do not enforce declared priority, even among simple formatting rules. The authors state that this paper's priority instruction fails in the same way.
• Earlier patterns: Camassa and Shiller (2026) write that a pattern given earlier in the conversation can override explicit instructions. The authors state that in this paper the worked example in each skill plays this role. The authors also state that these works compare one instruction against another; this paper compares two complete skill files of equal status, and most of what is dropped does not conflict with any rule.

Merging and rewriting skills

• By task score: SkillOps (Pu et al., 2026) merges skills with identical bodies. SkillSmith (Wei et al., 2026) uses task scores to estimate whether two retrieved skills help or hurt each other, and those skills do different things. SkillComposer (Zhang et al., 2026) rewrites two similar skills into one more general skill, judged by task pass rate.
• Constraint compilation: SkillFusion (Huang et al., 2026) maps constraints in simultaneously loaded skills to hard conflicts, soft conflicts, or redundancy, compiles them into one file, and beats concatenation and one rewrite on task success. The authors state that this is the closest work to this paper's fix.
• Reflective rewriting: GEPA (Agrawal et al., 2026) rewrites prompts based on failed runs and their feedback. SkillOpt (Yang et al., 2026) edits a skill document under a validation gate. Kozyrev et al. (2026) write that on repository skills the gains of the two cannot be separated from run-to-run noise.

Baselines and benchmarks

• Control conditions: both skills loaded, priority instruction, "apply both", a code-written rule union, a feedback loop in the above style, and the model's own plain merge and step-by-step merge. Evaluation uses the self-built SKILLCLASH, not a public skill library.

The authors state that the merging work above scores by task success or the merged file itself; this paper scores each output against the two source skills' rules and against a known best output, so it can see what each fix keeps and what it drops. The authors state that merging works because of correct rule-pair labeling and a correct example that follows both skills.

The overall approach is to build the benchmark SKILLCLASH, put both skill files in context and score both sides, then compare adding instructions with synthesizing a meta-skill.

Tasks, skills, and four kinds of rules

• 16 tasks: commit message, pull request, SQL, incident report, Python function, support reply, changelog, JSON error body, code review, test case description, standup, bug report, Dockerfile, API documentation, on-call alert, user story (Appendix A).
• A pair of skills: each task has two SKILL.md files, A and B, each with six rules plus one example that follows only that skill. The skills were built for the benchmark, not collected from public repositories, so that how the rules interact can be controlled.
• Four kinds of relations (relative to the other skill, Figure 1): contradictory, cannot both be satisfied, one rule on each side; shared, require the same thing, one rule on each side; entangled, can both be satisfied but require careful arrangement, one rule on each side; exclusive, the other side does not touch it, three rules on each side. As with IFEval, each rule is checked with a small program.
• Label review: a collaborator who did not write the skills and did not see the labels labeled all 16 contradictory pairs and all 16 shared pairs, and did not over-label. Entangled is harder to see: of 16 pairs, 8 pairs were labeled entangled, 4 pairs were labeled contradictory, and 4 pairs were not listed. The authors state that among the pairs labeled contradictory, one rule requires an exact position and the other only a nearby position, so they can both hold once arranged; the unlisted ones are length and format constraints.

What counts as following

• The twelve rules cannot all be satisfied, because contradictory rules cannot both hold. Each pair designates a primary, whose contradictory side is the correct side; each pair is run once in each direction. The authors state that this is the only place where it should lose.
• A correct output follows ten distinct rules: the primary's six, plus the other skill's three exclusive rules and one entangled rule. Shared rules require the same thing as the primary and are not counted twice.
• Each primary has a reference output, and the same code confirms that it follows all ten rules. The two reference outputs for the pair in Figure 1 differ only in the first line. Before running the models there is also a self-test: each example follows its own rules, and the contradictory and entangled pairs hold on the examples (Appendix A).
• takeover differs from primary: it also drops the other skill's exclusive rules, which do not conflict with any rule.

Metrics and how the files are put into context

• rules followed: the proportion of a skill's six rules that are followed. takeover: all three exclusive rules on one side are followed and all on the other side are dropped. achievable rules followed: the proportion of the ten rules that are followed; following only the primary is 60%. fully correct: all ten rules are followed. The authors state that the latter metric is stricter: on average most achievable rules may be followed while few outputs get all ten.
• Both files are placed in the system prompt, and the prompt asks the model to follow every rule in each loaded skill that applies to the request, thereby removing "whether to open which file". Placing both files in the user message was also tested. The user turn only asks for that kind of text.

How the two kinds of fixes are built

• Adding instructions: priority says that on conflict the primary wins, and otherwise all loaded rules are still followed. "apply both" says the two skills are complementary, every rule on both sides must go into the same output, and only when they cannot both hold do the primary's rules win.
• rule union: code copies both sides' rules into one file, split under two headings, without examples, and adds a line stating which side wins on conflict, without going through a model.
• feedback loop: GEPA and SkillOpt style. Six rounds; each round runs on three practice requests, lists the broken rules, has the model rewrite the file, and keeps it only if more rules are followed. Qwen3-4B both answers the practice requests and rewrites the file. The model proposes 16 practice requests per task, keeps 12, six for feedback and six for selecting the final file (Appendix A).
• Model merging: plain merge has the model write a single SKILL.md replacing both, with the primary's rules winning on conflict, and with one example. step-by-step first lists the rules, annotates the interacting pairs, writes one merged rule for each entangled pair, and copies the remaining rules verbatim. Seven models each merge for themselves. Claude Opus 5.5 sees only the skill files, and its file is given to all seven models.

Directions in activations

• On Qwen3-4B, Qwen2.5-7B, and Llama-3.1-8B, take the activation at the last prompt token, before the model starts writing, and train a linear probe to predict whether the skill listed first or the skill listed second will win.
• steering adds a fixed vector to the output of a layer while the model reads the prompt and generates, in the direction of the skill that loses without steering. The general direction uses "listed first wins" minus "listed second wins" on the other 15 tasks. Layer and strength are selected on four requests per task and reported on another four (Appendix E). The authors state that this is a mechanism check, not a fix.

Experimental setup

• Models tested: Qwen3-4B, Qwen2.5-7B, Mistral-7B (Appendix A writes Mistral-7B-v0.3), Llama-3.1-8B, Phi-4-mini, Qwen3-235B (qwen/qwen3-235b-a22b-2507), GPT-4.1 (openai/gpt-4.1). The authors state they come from five families. Claude Opus 5.5 only writes the merged file.
• Data: SKILLCLASH, 16 self-built tasks, 8 requests per task, two loading orders, two primaries. GPT-4.1 runs 4 of them per task.
• Decoding: greedy for open models; the two API models via OpenRouter, temperature 0.
• Conditions: single skill, unrelated skill, two same-task skills, priority, "apply both", rule union, feedback loop, each model's plain / step-by-step merge, Claude's merged file.
• Metrics: code checks; the paper reports no LLM judging. rules followed is the proportion of six rules; takeover is all three exclusive rules present versus all absent; achievable rules followed is the proportion of ten rules, with primary only at 60%; fully correct is all ten.
• Statistics: the unit is 16 tasks. 95% bootstrap intervals are by task, and comparisons are paired by task.

Main results

The table below shows achievable rule following proportions (%). The two-skills, apply both, rule union, and Claude columns correspond to Both skills loaded, the "Apply both" instruction, Rule union + priority line (the main text's rule union), and Step-by-step merge by Claude Opus 5.5 in Tables 1–3. GPT-4.1 has 4 requests per task.

Swipe horizontally to read the table

Model	Two skills	apply both	rule union	Claude step-by-step
Qwen3-4B	58.1%	69.5%	78.6%	98.4%
Qwen2.5-7B	58.6%	73.1%	73.2%	96.7%
Mistral-7B	60.3%	78.1%	74.6%	96.8%
Llama-3.1-8B	59.1%	72.0%	79.4%	98.6%
Phi-4-mini	59.9%	69.3%	65.9%	95.9%
Qwen3-235B	59.6%	87.6%	85.7%	99.0%
GPT-4.1	58.9%	88.6%	89.7%	99.4%

• Rule following is not the denominator of the table above: in Figure 2a, with same-task skills side by side, the six-rule following proportions are 61%, 61%, 62%, 61%, 62%, 62%, 61% (same order as the figure: Qwen3-4B to GPT-4.1). The abstract writes 93% to 99% for single loading. The authors state that an unrelated skill does not change the results. On the five rules that can always hold, the drop is still 28 to 35 percentage points (Section 4).
• All or nothing: the authors state that outputs are rarely mixed. In Tables 1–3, takeover with both skills loaded is 45% (Mistral-7B) to 78% (Qwen3-4B). The dropped exclusive rules do not conflict with the other skill.
• Instructions and the merged file: the authors state that the priority instruction recovered the dropped skill on no model (Tables 1–3: achievable rules 61.5% to 70.6%, takeover 36% to 82%; the main text writes 62% to 71%). "apply both" gives takeover 0 on the two strong models in Table 2, but both entangled rules are followed together 38% and 32% of the time, and fully correct is 22% and 21%; the authors state that the primary keeps the contradictory side 59% and 73% of the time (Section 5, alongside that sentence). The authors state that only Claude's file is near the ceiling on every model; under that condition takeover is 0 in Tables 1–3. The main text summarizes achievable rules as 96% to 99%; the lowest point in the table is Phi-4-mini at 95.9%.

How examples drive takeover

• Removing examples: on the five open models plus Qwen3-235B, takeover is 45% to 78% with examples and 7% to 41% after removing both sides' examples (Section 4, Appendix C). On six models, with both complete files put into one file and examples kept, takeover is still 34% to 73%. When only one skill's example is kept, that skill wins 67% to 93% of takeovers; the authors state that the only exception is Phi-4-mini, which almost always follows the skill listed second.
• The same dual-skill example: on the six models tested, when each file ends with the example from Claude's merged file that follows both skills, takeover drops to 1% to 15%, achievable rules are 90% to 96%, and the files are not merged into one. On the two strong models, fully correct outputs rise from 1% to 76% and 60%, versus 22% and 21% for "apply both" (Section 4; Table 2 gives 76 and 60, takeover 1 and 15).
• They interfere even without conflict: the authors state that even with all interaction rules removed, the proportion of Qwen3-4B, Qwen2.5-7B, Phi-4-mini, and Qwen3-235B fully following both sides' exclusive rules is still 24 to 33 percentage points below the prediction from single-skill runs, and the interval excludes 0 (Appendix C). On SQL, takeover is at most 19% for each model (Section 4; the highest in Table 7 is Phi-4-mini at 19%). The number of tasks with at least 75% takeover is 5 to 12 (out of 16). The proportion of takeovers won by the skill listed first: Llama-3.1-8B 74%, GPT-4.1 77%, Qwen2.5-7B 24%, Phi-4-mini 3%.

What works in the merged file

• The example accounts for most of the gain: the authors state that removing the example from Claude's file costs the four open models that have that run 9 to 25 percentage points of achievable rules, and the two strong models about 2; on six models, fully correct outputs drop by 14 to 52 percentage points (Section 5, Figure 3c). Adding that example to the code-written rule union raises the six models by 9 to 24 percentage points, all within 8 percentage points of Claude's complete file. On GPT-4.1, rule union's fully correct outputs go from 30% to 89% (Table 2). Adding back the source skills' own examples does the opposite: the authors state a drop of 0 to 14 percentage points, with takeover back at 32% to 55%.
• The example must be correct: Figure 5 orders mergers by the proportion of "examples that satisfy all achievable rules", which below the figure are 0%, 9%, 12%, 16%, 31%, 53%, 94% (Mistral-7B to Claude Opus 5.5). The scores in Table 4 are 0/32, 3/32, 4/32, 5/32, 2/32, 10/32, 17/32, 30/32 (including Phi-4-mini's 2/32). The authors state that correct examples add 12 to 17 percentage points, and incorrect ones add little or nothing. The authors state that under the same task and primary, a correct example written by another merger helps within 1 percentage point of Claude's (three readers).
• With wrong labels, step-by-step is not better: Claude Opus 5.5 labeled all 48 interacting rule pairs correctly, with no over-reporting, and handled every rule correctly in 32/32 files (Table 4). The seven self-merging models correctly labeled 2 to 39 pairs and reported 8 to 61 rule pairs that do not interact, with at most 14/32 files fully correct. With no such errors, the authors give step-by-step versus plain as 96% versus 96% (Qwen3-235B) and 94% versus 96% (GPT-4.1); with one error, 84% versus 94% and 88% versus 94%, without stating which two mergers the latter two groups belong to. With correct labels substituted, Qwen3-4B's step-by-step merging gains 8 to 10 percentage points across the seven models (Table 5 gives +8.1 to +9.6).

Activation directions and the public transcript

• Probe: on seen skill pairs, guessing that pair's usual winner is already correct on 96% to 99% of takeover outputs; Table 8's baseline on new requests is 96.5%, 98.9%, 97.1%. On unseen pairs, the authors state they could not show on the three models that the probe beats always guessing the skill listed first, and state that 16 held-out pairs make this test weak.
• steering: the authors state that the general direction flips 38% to 49% of takeovers, while a random direction at the same layer and strength flips 0% to 3%. In Table 9, the flips for best for flipping are 48.8%, 48.1%, 37.7%, against random controls of 2.9%, 0%, 0% (Qwen3-4B, Qwen2.5-7B, Llama-3.1-8B). The authors state that both sides being followed is at most 13% on any model; the highest cell in Table 9 is 13, and one random control for Llama-3.1-8B is also 13. Stronger steering breaks the text on Qwen3-4B. Figure 6's held-out requests are 89 to 100 per model, and all are takeover without steering.
• Public transcript: the authors reanalyze the public run transcript of Yan et al.; in Claude Code runs that use two skills at once, compared with paired runs that install only skill A, requirements raised only by A are satisfied about 8 percentage points less often (Section 7, Appendix F). The authors state that this is observational and the effect is smaller than this paper's benchmark, but the direction is consistent. Figure 7 notes that which skills were used was not randomized.

Other ablations and analyses

• Both files in the user message rather than the system prompt: on six models, rule following drops by 32 to 37 percentage points (excluding Mistral-7B; Section 4).
• Without examples, one file versus two files: Table 5 gives +12.5, +9.6, +6.9, +17.9, +5.6, +14.8 percentage points; Phi-4-mini's interval [−1.2, 11.4] includes negative values.
• feedback loop: Table 5, on Qwen3-4B, rule union after the loop versus before is +13.8 percentage points, and Llama-3.1-8B reading the same batch of files is +9.7; practice requests that provoke conflict versus ordinary requests are −0.2 and −0.9, with intervals including 0. That row in Figure 4 is 92 / 89, and the strong models are marked not run.
• With Qwen3-4B as reader, plain merge's achievable rules are 79.3%, 87.0%, 93.9%, 92.5%, 97.7% (writers in order: Qwen3-4B, Llama-3.1-8B, Qwen3-235B, GPT-4.1, Claude; Table 1). The main text writes 79, 87, 94, 92, and 98.
• Keeping only rules that are "followed with the skill and not followed without it" (162 to 174 / 192), the seven models' takeover is 52.1% to 84.4% (Appendix A).
• For models doing plain merge for themselves, the authors write achievable rules of 71% to 95%; in Table 5, Claude's file is 4.7 to 24.8 percentage points above each model's own plain merge, and the main text writes 5 to 25.

Limitations and future directions noted by the authors

• Annotation determines step-by-step merge (Section 7): step-by-step merge depends on annotating rule pairs, and only one merger annotated well enough.
• Pre-save checking not yet tested (Section 7): check each merged rule and example against the source rules before saving. The authors say this looks cheap but remains untested.
• Fallback to plain merge when annotation is doubtful not yet tested (Section 7): use plain merge when annotation is doubtful. The authors say this is likewise untested.
• Real skills have no rule checker (Section 7): checking a merge once on real skills requires a reviewer model or hand-written checks, because real skills do not come with a rule checker.

Scope of the experiments

• The readers tested are Qwen3-4B, Qwen2.5-7B, Mistral-7B, Llama-3.1-8B, Phi-4-mini, Qwen3-235B, and GPT-4.1, which the authors say come from five families; open-source models use greedy decoding, and API models use temperature 0. GPT-4.1 uses 4 of the 8 requests per task (Appendix A).
• SKILLCLASH consists of 16 self-built tasks, 8 requests per task, two loading orders, and two primaries; each rule is checked by code. A collaborator who had not seen the labels reviewed the 16 rule relationships (Section 3).
• Repair conditions include priority instructions, "apply both", code rule union, a feedback loop run by Qwen3-4B and read by it and Llama-3.1-8B, plain and step-by-step merge for each of the seven models, and Claude Opus 5.5 seeing only the skill file (Section 5, Figure 4).
• Linear probes and activation steering are run on Qwen3-4B, Qwen2.5-7B, and Llama-3.1-8B; layers and strengths are selected on 4 requests per task and reported on the other 4. The held-out requests in Figure 6 number 89 to 100 per model, and all end in takeover without steering (Appendix E).
• Intervals are 95% bootstrap over the 16 tasks, and comparisons are paired by task. Figure 4 marks the feedback loop on strong models as not run. Some conditions in Table 2 and Table 3 appear as "–" with no number. The main metric is decided by code; the paper does not report separately using an LLM to score these outputs, nor repeated sampling beyond temperature 0. Appendix F is a reanalysis of the public run summary of Yan et al.

SKILLCLASH is used to see whether a coding agent merges rules or drops one side when two same-task skills both enter context.

• When skills are installed side by side, most rules can be followed together, but no mechanism prevents two same-task skills from taking effect at the same time. Yan et al. have already measured same-task skills displacing each other, but their agent opens files on demand and only one side is scored.
• The 16 skill pairs were built for this benchmark. Each side has six rules, with relations classified as contradictory, shared, entangled, exclusive. After designating a primary, ten rules are achievable; code checks the output, and reference outputs confirm that these ten can be reached together. takeover means all of one side's exclusive rules are followed and all of the other side's are dropped.
• On the seven models, rule following is 93% to 99% when loaded alone, 61% to 62% with same-task skills side by side, and 45% to 78% of outputs are takeover. The authors state that the worked example in the skill drives most of this; on six models, when each file is changed to the same dual-skill example, takeover drops to 1% to 15%.
• The priority instruction did not recover the dropped skill. "apply both" makes takeover 0 only on Qwen3-235B and GPT-4.1, with fully correct outputs of 22% and 21% (Table 2). Claude Opus 5.5's step-by-step merged file gives takeover 0 on the seven models; the main text writes achievable rules of 96% to 99%, and Phi-4-mini is 95.9% in Table 3.
• The authors state that most of that file's gain over a list of both sides' rules comes from the correct example at the end that follows both skills; if the example is incorrect, it adds little or nothing. The authors state that who writes the merge matters more than the step-by-step procedure itself, because whether step-by-step merging is good depends on whether the labels are right.
• The authors state that takeover happens after both files are already loaded, so improving skill selection cannot solve it; blocking one skill would give up its rules. The authors state that the higher results on each model come from merging once with the strongest model at hand: the file ends with a correct dual-skill example, and the source skills' own examples are not copied.