TL;DR
A skill is a folder with a SKILL.md file that explains to an agent (Claude Code, Codex, and others) when and how to do a task. If a project ends up with two skills that do the same job, the model chooses between them based only on the name and a short description. It reads the skill body with the rules only after it has chosen. The researchers measured what gets lost along the way. They also tested a simple safeguard: intercept the moment the agent first opens the "wrong" skill.
The main finding: a skill conflict doesn't break the task, it breaks the rules. The agent completes the job, but follows the wrong skill's instructions. Your skill forbids touching git, but the agent invokes a similar skill from a copied collection, makes a commit, and doesn't say whose skill it used. The tests pass, everything looks fine. In its response, the agent names the skill it used in roughly one case out of a hundred. The order of skills in the list barely matters. What matters is where it's installed: a personal skill with the same name overrides the project one, and plugin skills are almost never invoked.
The safeguard is simple: the decision gets made at the moment the skill is first read, almost always before any file edits. A pre-tool hook blocks that first read of the "extra" skill. The agent switches to the right one in the overwhelming majority of cases, and rule compliance returns to the level of a "clean" run. The second takeaway: evaluate a skill not by "task completed" but by whether its exclusive requirements were met.
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
DUPLICATE AUDIT (in chat, one request or one pair at a time):
STEP 1: Find pairs of skills doing the same job → list of pairs (by name + description)
STEP 2: For your skill A, write out the key functions → 3 requirements the
model wouldn't meet on its own; a quote from the text; verifiable in the output
STEP 3: Mark the "exclusive" ones → functions that skill B doesn't require
STEP 4: Decision → delete the duplicate / rename / separate the descriptions / add a hook
AGENT-SIDE SAFEGUARD (tool configuration):
Pre-tool hook → blocks the first read of skill B
→ the agent switches to A
RUN CHECK:
Look in the tool-call log for which skill was opened first, not in the agent's answer
Example in Practice
Task: You're the tech lead at a small dev shop in Austin. A client's repository contains your project skill checkpoint: it saves a handoff note and strictly forbids any git commits, because the client's branches are protected. Recently you copied a whole skill collection from GitHub into the project, and it includes checkpoint-2, which commits the work. The tests are green, but commits keep unexpectedly showing up in the history. You need to find the duplicates and figure out exactly what's being lost.
Prompt:
You are a skill auditor for a coding agent. Below are two SKILL.md files.
Skill A is the one we installed for its rules. Skill B is a similar skill from someone else's collection.
TASK 1. Based on name and description alone: could a request meant for A be routed to B? Answer yes/no and explain in one sentence.
TASK 2. Read the bodies. Verdict: "same job" / "near-duplicate" / "related but different" / "unrelated".
TASK 3. List up to three key functions of skill A. A key function is a requirement that a competent model would NOT meet without this skill. Each one: (a) with a quote from A's text, (b) verifiable from the agent's output.
TASK 4. For each key function of A: does skill B ask for it? If not, mark it "exclusive."
TASK 5. What happens if the agent picks B instead of A? Which exclusive functions get lost even though the task is formally completed?
TASK 6. Recommendation: delete B / rename / rewrite the description so they don't overlap / leave as is.
=== SKILL A (checkpoint) ===
{SKILL_md_text_A}
=== SKILL B (checkpoint-2) ===
{SKILL_md_text_B}
Result: The model will answer in blocks for the six tasks. First it'll say whether the descriptions overlap and whether the job is the same. Then it'll list up to three key functions of A with quotes, such as the ban on commits, and flag which of them B doesn't require. Next it'll describe the loss scenario: task done, rule broken. Finally it'll give a recommendation: delete the duplicate, rename it, or separate the descriptions. Double-check the verdict yourself: in the study, "similar words" often didn't mean "the same job."
Why It Works
The weakness: skill selection happens based on a short description, while the rules live in the skill body, which is read only after selection. The model has no way of knowing in advance how two similar skills differ. If both fit, either one will finish the task, so the conflict is hidden: the more likely it is, the less noticeable it gets. The only trace is missing behavior that's unique to your skill.
The strength: you can derive verifiable requirements from a skill's text in advance. The authors used a judge model exactly this way: for each skill it writes out key functions with quotes. The trick is easy to replicate by hand or in chat, and it turns a fuzzy "I think these skills conflict" into a short checklist.
How the method gets around the weakness: the check isn't "did the task pass" but the functions that only your skill has. The safeguard sits at the single point where the conflict gets decided: the first read of the skill. After that, rolling back edits usually isn't needed, because the agent hasn't changed anything yet.
Control levers: - Install location. Decides which skill wins. A personal skill with the same name overrides the project one; plugin skills are rarely invoked. If you want the project skill to run, don't duplicate its name in your personal folder. - Number of key functions. Three, as in the study. For an important skill (security, releases) you can check more. - The "exclusive" condition. Check first what the neighbor doesn't have: that's what gets lost unnoticed. - Skill order in the list. Pointless to change: the effect is minimal.
Prompt Template
You are a skill auditor for a coding agent.
Given: skill A (installed for its rules) and skill B (similar).
<Task>
1. Routing: based on name+description, could a request for A go to B? (yes/no + one sentence)
2. Verdict on the bodies: "same job" / "near-duplicate" / "related but different" / "unrelated"
3. Key functions of A (up to {function_count}): requirements a
competent model wouldn't meet without A. Each with a quote from A and verifiable from the output.
4. For each function: does B ask for it? No → "exclusive"
5. Losses: what gets lost if B is chosen instead of A, even if the task gets done
6. Recommendation: delete / rename / separate descriptions / leave as is
</Task>
<SkillA>{text_A}</SkillA>
<SkillB>{text_B}</SkillB>
Don't invent requirements that aren't in the text. If you're not sure, write "not sure" and why.
What to fill in: {text_A} and {text_B} — the full contents of SKILL.md. {function_count} — 3 by default.
🚀 Quick start — paste into a chat:
Here's a template for auditing skill conflicts. Adapt it to my task: {describe which skills you have installed and where they came from}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask which skill is the main one for you, where the second one came from, and which rules are critical (bans, formats, checklists). That's needed to choose which key functions to check first. It takes the pattern from the template.
Limitations
⚠️ One main platform: nearly all experiments ran on Claude Code. On Codex only the main effects were checked; other agents weren't studied. Skill override rules differ between tools.
⚠️ A judge model did part of the work: which skill pairs "do the same job" was decided by a model, with humans spot-checking. For your own skill, reread the auditor's verdict yourself.
⚠️ The effect on rules is modest: the loss in rule compliance is measured in single-digit percentages, and it's more noticeable in runs where the "wrong" skill was opened first. But it's invisible without a dedicated check.
⚠️ A hook is tool configuration, not a prompt: the safeguard requires a small script in the agent's config. The available part of the text doesn't show ready-made hook code. You'll have to build it yourself, for example with an LLM's help.
⚠️ Normative skills suffer the most: skills with rules and formats lose silently. Capability skills (without which the task goes badly) show the loss in the task itself.
⚠️ Public repositories only: personal skills and plugins are barely visible in them, so the prevalence of duplicates is most likely underestimated.
How They Studied It
The researchers took snapshots of 20,947 public repositories with Claude Code skills and reconstructed which skills the agent would actually load in each project. Then they found 822 thousand candidate "similar pairs" based on description text. A judge model checked a sample of 3,754 pairs: do they really do the same job? It turned out that nearly one in four installed skills sits next to a duplicate, and in copied collections the figure is 37% versus 19% in other projects.
Then came the experiment. 312 confirmed pairs were run on three models: 6,368 runs, 169 thousand tool calls, 542 hours of agent work. Each pair ran in different configurations: A only, B only, both together, A with an unrelated skill. They varied the order in the list and where B was installed. The key design idea: measure not task completion but key functions, three verifiable requirements from skill A's text. That yardstick catches what a binary "pass / fail" misses.
The results went against expectations. The task didn't suffer, even though the "wrong" skill stole roughly one in five runs from the installed one. Skill order in the list barely mattered; install location was decisive. Models read even overridden skills in a noticeable share of runs. In its answer, the agent named the substitute skill in roughly one percent of cases. The most practical takeaway: the conflict gets decided at the first read, almost always before file edits. In a new experiment, a hook blocking that read brought the agent back to the right skill in the overwhelming majority of cases and restored compliance with the exclusive rules.
Adaptations and Extrapolations
💡 Context adaptation: audit skills from someone else's collection before installing
Before copying a "skill pack" from GitHub into your project, run every "your skill vs. closest skill from the pack" pair through the template. Don't check the quality of the other skill; check the overlap in the job. If there's overlap, rename it, delete it, or keep the duplicate only in your personal folder.
🔧 Technique: add a "whose skill fired" check → transparency
The authors showed that the agent almost never reports which skill it used. Add a line to the instructions file (CLAUDE.md / AGENTS.md): "At the end of your answer, list which skills you read and applied." This is our guess; the paper didn't test such an instruction. Test it on your own project by comparing the answer against the tool-call log.
🔧 Technique: separate the descriptions → fewer wrong picks
Selection is based on the short description. In each skill's
description, add boundaries: "Use only for X. Don't use for Y (skill Z handles that)." This is also an extrapolation: the paper didn't rewrite descriptions. But it follows from the "selection by description" mechanics.
Extrapolation: a key-function checklist for any of your skills. For each important skill, ask the model to write out up to three verifiable key functions and keep them alongside it. After an agent run, check the outcome against those three points, not just "tests are green."
Resources
- Title: One Skill Too Many: How Co-Installed Skills Conflict in Coding Agents
- Authors: Chaoliang Yan, Zihao Xu, Yuekang Li, Shangzhi Xu (UNSW, Australia), Yi Liu (Griffith University), Gelei Deng (Nanyang Technological University), Siqi Ma (University of Wollongong)
- The authors state they will release the cases, the testbed, and the run logs.
- The Claude Code skills documentation the work builds on.
- Related work mentioned in the paper: SkillsBench, SWE-Skills-Bench.