TL;DR
A meta-skill is a single instruction file that merges the rules of two skills (the SKILL.md files that teach an agent one job). At the end of the file sits one example that follows the rules of both skills. That way the model gets one correct template instead of two competing ones. Have the strongest model you can get write the file.
The headline finding: when two skills for the same job sit in context, the model doesn't blend them. It picks one, follows its rules to the letter, and drops the other one's rules, even the ones that conflict with nothing. A lone skill gets followed almost perfectly, but add a second skill "for the same thing" and roughly a third of the rules vanish. The culprit is the examples inside the skills. Each one shows output that follows only its own skill's rules, and the model copies the format of the template. Saying "on conflict, skill A wins" doesn't help on any model. A big model loses just as much as a small one.
The fix: merge both files into one and add a single example at the end that follows both skills. If you'd rather not merge, you can keep two files and end each with the same example that satisfies both skills. The takeover almost disappears.
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: List the rules of both skills → two lists
STEP 2: Label rule pairs → contradict / duplicate / intertwined (the rest are independent)
STEP 3: Build one file → independent rules verbatim, duplicates merged into one,
contradictions settled by the "primary" skill, intertwined ones fused into one shared rule
STEP 4: Write ONE example that follows every rule of both skills
(throw out the old examples)
STEP 5: Replace the two files with one
It all happens in one chat with one prompt, ideally on the strongest model you have access to.
Fallback without merging: keep both files and paste the same example, one that satisfies both skills, at the end of each.
Example in Action
Task: An online store's dev team has two skills for commit messages. Developer Jake set up a personal conventional-commits skill for himself. The team-wide tracker-first skill is the standard for the SHOP project in Jira. The agent in Claude Code writes commits in one style one day and the other style the next. It ignores the second skill entirely, including the rules that don't clash with the first.
Prompt:
You are an editor of agent instructions. Merge two skills for the same job
("write a commit message") into a single SKILL.md file.
<Skill_A name="conventional-commits">
1. First line: type(scope): description.
2. First line under 72 characters, verb in the imperative mood.
3. After the first line: a blank line, then the body explaining why the change was made.
4. The body never says "fixed" or "tweaked" without specifics.
5. Last line of the message: Co-authored-by: {name}.
6. Type only from this list: feat, fix, docs, refactor, test, chore.
Example: (skill A example)
</Skill_A>
<Skill_B name="tracker-first">
1. First line starts with the ticket number in square brackets: [SHOP-123].
2. First line under 72 characters.
3. After the first line: a blank line, then the body explaining why the change was made.
4. The body contains the line "Component: {name}".
5. Last line of the message: Reviewed-by: pending.
6. The line "Author: {name}" goes right before the last line.
Example: (skill B example)
</Skill_B>
<Primary>tracker-first</Primary>
(on a direct conflict, the team skill wins)
<Process>
Step 1. List each skill's rules.
Step 2. Find the rule pairs that interact and label them:
- contradict: you can't satisfy both;
- duplicate: both ask for the same thing;
- intertwined: both can be satisfied, but only with careful
layout (for example, both want to be the last line).
All other rules are independent. Don't invent pairs that aren't there.
Step 3. Write the final SKILL.md:
- independent rules: verbatim;
- duplicates: as a single rule;
- contradictions: Primary wins, one line saying so;
- intertwined: one shared rule that spells out
how to arrange the lines.
Step 4. At the end of the file add ONE example commit message
that follows every rule of both skills, except the losing
side of a contradiction. Don't copy the examples from the source files.
Step 5. Output the label table first, then the finished file.
</Process>
Result: The model first shows a table: which rules overlap, which clash, which are intertwined. Then it hands you one SKILL.md with a unified rule list, a line about the team skill taking priority, and one end-to-end example commit. That file replaces the two originals. From then on the agent should follow the rules of both skills, not just one.
Why It Works
The weakness. A model copies a template harder than it reads rules. The example inside a skill shows output that follows only that skill's rules. With two such templates in context, the model picks one and mirrors its format. The second skill's remaining rules get lost, even though nothing stood in their way. An order like "skill A is primary" doesn't cancel the pull of the template: the model doesn't honor priority the way we expect.
The strength. When there's one correct template, the model reproduces it well. A single example that satisfies both rule sets shows how they coexist. This matters most for intertwined rules: say, two lines that both need to be last. You can't explain that with a list, but an example makes it obvious at a glance.
Control knobs: - Who writes the merge. The stronger the author model, the better the file. A weak author model mixes up the labels and wrecks the result. - The example. This is the main lever. Without it the effect drops sharply, and a wrong example gives you almost nothing. Check the example against every rule. - The priority line. Only needed for genuine contradictions. One line in the list; it doesn't affect anything else. - Pair labels. Optional. On the strongest model, a plain "merge into one file with one shared example" worked almost as well as the step-by-step breakdown. The steps help only when the labels are right.
Prompt Template
You are an editor of agent instructions. Merge two skills for the same job
({job_name}) into a single SKILL.md file.
<Skill_A name="{name_A}">
{skill_A_text}
</Skill_A>
<Skill_B name="{name_B}">
{skill_B_text}
</Skill_B>
<Primary>{primary_skill}</Primary>
(on a direct conflict, this skill wins)
<Process>
Step 1. List each skill's rules.
Step 2. Find the rule pairs that interact and label them:
- contradict: you can't satisfy both;
- duplicate: both ask for the same thing;
- intertwined: both can be satisfied, but only with careful layout.
All other rules are independent. Don't invent pairs that aren't there.
Step 3. Write the final SKILL.md:
- independent rules: verbatim;
- duplicates: as a single rule;
- contradictions: Primary wins, one line saying so;
- intertwined: one shared rule that spells out how to combine them.
Step 4. At the end of the file add ONE example output that follows
every rule of both skills (except the losing side of a contradiction).
Don't copy the examples from the source files.
Step 5. Output the label table first, then the finished file.
</Process>
What to fill in: {job_name} is the one job both skills claim. {skill_A/B_text} is the full text of each file. {primary_skill} is the one whose side wins in a direct contradiction.
Simple version: drop the <Process> block and just say "merge into one file, keep every rule, end with one example that follows both skills." On the strongest model the result was nearly identical.
No-merge version: leave both files as they are. Delete each file's own example and add the same example, one that satisfies both skills, to the end of both.
🚀 Quick start: paste this into the chat:
Here's a template for merging two skills into one. Adapt it to my task:
{my task}. Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what job the skills do, which one is primary, and whether you'll share the text of both files. That's what makes the method work: the merge rests on accurate rule-pair labels and one correct example. It'll take everything else from the template.
Limitations
⚠️ The skills were synthetic: the authors wrote them themselves, six rules per skill, each checked by code. Real skills are longer and fuzzier. Read the numbers as a direction, not a guarantee.
⚠️ A weak author model hurts: if a small model writes the merge, the file comes out worse than a strong model's. It often mixes up labels and invents rule relationships that don't exist.
⚠️ A wrong example is useless: an example that doesn't satisfy every rule gives you almost nothing. Check it by hand or with a separate request.
⚠️ Priority doesn't work: a line saying "on conflict, A wins" doesn't bring back the lost skill on any model. Don't count on it as a safeguard.
⚠️ "Apply both" only helps partly: strong models do bring the second skill back with it, but intertwined rules stay broken. Only about a fifth of responses come out fully correct.
⚠️ Load order decides, but unpredictably: which skill wins depends on the pair, the order, and the model. If you don't control the order, you can't predict the outcome.
⚠️ Test conditions: both files sat directly in context. In real agents, skills load on demand, which adds extra losses when a skill doesn't get picked.
⚠️ Not for every task: in SQL queries the takeover barely happened: the rules touched different parts of the same query, and the models blended them fine.
How They Tested It
The researchers built 16 skill pairs for a single job each: commit message, pull request description, SQL query, bug report, and so on. Every skill had six rules and one example. The rules fell into four types: contradicting, duplicate, intertwined, and independent. A program checked every rule, and each pair had a reference answer satisfying all 10 achievable rules. Satisfying every rule of both skills is impossible: the contradictions rule that out.
They ran seven models, from small open models with 4–8B parameters up to Qwen3-235B and GPT-4.1. They compared three setups: one skill alone, a skill plus a skill for a different job, and a skill plus a skill for the same job. A lone skill was followed 93–99% of the time. A skill for a different job changed nothing. A skill for the same job dragged results down to 61–62% on all seven models. A model 60 times bigger lost just as much as the 4B one.
Then they dug into the cause. Remove the examples, and the takeover dropped sharply. Keep an example in only one skill, and that skill won almost every time. Give both skills the same example satisfying both, and the takeover fell to 1–15% even without merging the files. For comparison, they tested three merge methods: code copies the rules, the model itself rewrites the rules, and Claude Opus 5.5 merges the rules. Files written by Opus let all seven models follow 96–99% of achievable rules. It then turned out that most of the gain comes from the single example. Add the same example to a plain rule list, and the result nearly caught up with Claude's file. But only a correct example helped.
There were two surprises. They expected the step-by-step labeled breakdown to beat a simple merge, but that held only for the strongest model. For the rest, wrong labels hurt the result. Second, "apply both" did almost nothing on small models, while on strong ones it brought the skill back but left intertwined rules broken. The practical takeaway: have a strong model write the merge, make one correct example, and don't rely on priority lines.
Adaptations and Extrapolations
💡 Adaptation for a custom GPT or system prompt: you have two instructions for the same task, say your company's style guide and an author's personal voice. Each ends with its own sample text, and the model follows one of them. Merge them the same way: one shared rule list and one sample that satisfies both.
Here are two sets of instructions for writing {text_type}: my company's style guide
and my personal voice. Merge them into one system prompt.
Rules as a list; on conflict, {what_takes_priority} wins.
At the end add ONE sample text on the topic "{topic}"
that follows every rule from both sets. Remove the old samples.
[style guide]
[personal voice]
🔧 Technique: add an example check → don't let a wrong template slip through. The paper shows a wrong example is useless, but the method has no verification step. It's easy to add as a second request:
Check the example in the file against each rule separately:
rule → satisfied / violated → where exactly.
If there are violations, fix the example and show the final version.
Resources
- Paper: One Skill Takes Over: Clashing Agent Skills and a One-File Fix (SKILLCLASH)
- Authors: Parsa Razmara, Seyedarmin Azizi, Ardalan Aryashad (University of Southern California, Los Angeles)
- Code and data: https://github.com/prazmara/skillclash
- Related work cited in the paper: Yan et al. (skill conflicts in Claude Code, a blocking hook); SkillFusion (constraint pair labels); GEPA and SkillOpt (automatic prompt refinement via error analysis); IFEval (rule checking by code)