TL;DR
Мета-скил — это один файл инструкций, в который слиты правила двух скилов (файлов SKILL.md, которые учат агента одной работе). В конце файла стоит один пример, соблюдающий правила обоих скилов. Так модель получает не два конкурирующих образца, а один правильный. Файл лучше писать самой сильной моделью.
Главная находка: когда в контексте лежат два скила для одной работы, модель не смешивает их. Она выбирает один и выполняет его правила целиком, а правила второго бросает, даже те, что ничему не противоречат. Одиночный скил выполняется почти идеально, а при втором скиле «для того же» теряется около трети правил. Причина — примеры внутри скилов. Каждый показывает результат только по правилам своего скила, и модель копирует формат образца. Фраза «при конфликте главный скил А» не помогает ни на одной модели. Большая модель теряет столько же, сколько маленькая.
Лечение: слить оба файла в один и дописать в конец один пример, который следует обоим скилам. Если сливать не хочется, можно оставить два файла и закончить каждый одним и тем же примером, соблюдающим оба скила. Перехват при этом почти исчезает.
Схема метода
ШАГ 1: Выписать правила обоих скилов → два списка
ШАГ 2: Пометить пары правил → противоречат / совпадают / переплетены (остальные независимы)
ШАГ 3: Собрать один файл → независимые слово в слово, совпадающие в одно,
противоречия решает «главный» скил, переплетённые в одно общее правило
ШАГ 4: Написать ОДИН пример, соблюдающий все правила обоих скилов
(старые примеры выбросить)
ШАГ 5: Заменить два файла одним
Всё делается в одном чате, одним промптом, лучше на самой сильной модели из доступных.
Запасной вариант без слияния: оставить два файла и в конец каждого вставить один и тот же пример, соблюдающий оба скила.
Пример применения
Задача: В команде интернет-магазина два скила для коммитов. Личный conventional-commits разработчик Андрей поставил себе сам. Командный tracker-first принят в очереди SHOP в Яндекс Трекере. Агент в Claude Code пишет коммиты то по одному стилю, то по другому. Второй скил он игнорирует целиком, включая правила, которые не спорят с первым.
Промпт:
Ты — редактор инструкций для агента. Слей два скила для одной работы
(«написать сообщение коммита») в один файл SKILL.md.
1. Первая строка: type(scope): описание.
2. Первая строка до 72 символов, глагол в повелительном наклонении.
3. После первой строки — пустая строка и тело: зачем сделано изменение.
4. В теле нет слов «исправил», «поправил» без уточнения.
5. Последняя строка сообщения: Co-authored-by: {имя}.
6. Тип только из списка: feat, fix, docs, refactor, test, chore.
Пример: (пример скила A)
1. Первая строка начинается с номера тикета в квадратных скобках: [SHOP-123].
2. Первая строка до 72 символов.
3. После первой строки — пустая строка и тело: зачем сделано изменение.
4. Тело содержит строку «Компонент: {название}».
5. Последняя строка сообщения: Reviewed-by: pending.
6. Строка «Автор: {имя}» стоит перед последней строкой.
Пример: (пример скила B)
tracker-first
(при прямом конфликте побеждает командный скил)
Шаг 1. Выпиши правила каждого скила списком.
Шаг 2. Найди пары правил, которые взаимодействуют, и пометь:
- противоречат: оба выполнить нельзя;
- совпадают: оба просят одно и то же;
- переплетены: оба выполнить можно, но только при аккуратной
компоновке (например, оба хотят быть последней строкой).
Остальные правила — независимые. Не выдумывай пар, которых нет.
Шаг 3. Напиши итоговый SKILL.md:
- независимые правила — слово в слово;
- совпадающие — одним правилом;
- противоречащие — выигрывает Primary, одна строка об этом;
- переплетённые — одно общее правило, которое прямо говорит,
как расположить строки.
Шаг 4. В конец файла добавь ОДИН пример сообщения коммита,
который соблюдает все правила обоих скилов, кроме проигравшей
стороны противоречия. Примеры из исходных файлов не копируй.
Шаг 5. Выведи сначала таблицу меток, затем готовый файл.
Результат: Модель сначала покажет таблицу: какие правила совпали, какие спорят, какие переплетены. Затем выдаст один SKILL.md с единым списком правил, строкой про приоритет командного скила и одним сквозным примером коммита. Этот файл заменяет два исходных. Агент после этого должен выполнять правила обоих скилов, а не одного.
Почему это работает
Слабость. Модель копирует образец сильнее, чем читает правила. Пример внутри скила показывает вывод по правилам только этого скила. Когда в контексте два таких образца, модель выбирает один и повторяет его формат. Остальные правила второго скила теряются, хотя им ничто не мешало. Приказ «главный скил А» не отменяет притяжения образца: модель не следует приоритету так, как мы ждём.
Сильная сторона. Если образец один и правильный, модель хорошо его воспроизводит. Один пример, соблюдающий оба набора правил, показывает, как они живут вместе. Это особенно важно для переплетённых правил: например, две строки, которым обеим нужно стоять последней. Списком такие правила не объяснишь, а на примере видно сразу.
Рычаги управления: - Кто пишет слияние. Чем сильнее модель-автор, тем лучше файл. Слабая модель-автор путает метки и портит результат. - Пример. Это главный рычаг. Без него эффект сильно падает, а неправильный пример почти ничего не даёт. Пример надо проверять по каждому правилу. - Строка про приоритет. Нужна только для настоящих противоречий. Одна строка в списке, на остальное она не влияет. - Метки пар. Не обязательны. У самой сильной модели простое «слей в один файл с одним общим примером» работало почти так же, как разбор по шагам. Шаги помогают, только когда метки поставлены верно.
Шаблон промпта
Ты — редактор инструкций для агента. Слей два скила для одной работы
({название_работы}) в один файл SKILL.md.
{текст_скила_A}
{текст_скила_B}
{главный_скил}
(при прямом конфликте побеждает этот скил)
Шаг 1. Выпиши правила каждого скила списком.
Шаг 2. Найди пары правил, которые взаимодействуют, и пометь:
- противоречат: оба выполнить нельзя;
- совпадают: оба просят одно и то же;
- переплетены: оба выполнить можно, но только при аккуратной компоновке.
Остальные правила — независимые. Не выдумывай пар, которых нет.
Шаг 3. Напиши итоговый SKILL.md:
- независимые правила — слово в слово;
- совпадающие — одним правилом;
- противоречащие — выигрывает Primary, одна строка об этом;
- переплетённые — одно общее правило, которое прямо говорит, как их совместить.
Шаг 4. В конец файла добавь ОДИН пример результата, который соблюдает
все правила обоих скилов (кроме проигравшей стороны противоречия).
Примеры из исходных файлов не копируй.
Шаг 5. Выведи сначала таблицу меток, затем готовый файл.
Что подставлять: {название_работы} — одна работа, на которую претендуют оба скила. {текст_скила_A/B} — полный текст файлов. {главный_скил} — тот, чья сторона выигрывает при прямом противоречии.
Простой вариант: убери
Вариант без слияния: оставь два файла как есть. Удали из каждого родной пример и добавь в конец обоих один и тот же пример, соблюдающий оба скила.
🚀 Быстрый старт — вставь в чат:
Вот шаблон слияния двух скилов в один. Адаптируй под мою задачу:
{моя задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какую работу делают скилы, какой из них главный и дашь ли ты тексты обоих файлов. Это нужно, чтобы метод работал: слияние держится на точных метках пар правил и на одном верном примере. Всё остальное она возьмёт из шаблона.
Ограничения
⚠️ Скилы искусственные: авторы написали их сами, по шесть правил на скил, с проверкой кодом. Реальные скилы длиннее и размытее. Цифры стоит читать как направление, а не как гарантию.
⚠️ Слабая модель-автор вредит: если слияние пишет маленькая модель, файл получается хуже, чем у сильной. Она часто путает метки и выдумывает несуществующие связи правил.
⚠️ Неправильный пример бесполезен: пример, который не выполняет все правила, почти ничего не даёт. Проверяй его вручную или отдельным запросом.
⚠️ Приоритет не работает: строка «при конфликте побеждает А» не возвращает потерянный скил ни на одной модели. Не рассчитывай на неё как на защиту.
⚠️ «Применяй оба» помогает частично: сильные модели с ним возвращают второй скил, но переплетённые правила остаются сломанными. Полностью верных ответов получается лишь около пятой части.
⚠️ Порядок загрузки решает, но непредсказуемо: какой скил победит, зависит от пары, порядка и модели. Если порядок не контролируешь, предсказать результат нельзя.
⚠️ Условия теста: оба файла лежали прямо в контексте. В реальных агентах скилы открываются по требованию, и там есть дополнительные потери из-за невыбранного скила.
⚠️ Не для всех задач: в SQL-запросах перехват почти не возникал: правила касались разных частей одного запроса, и модели их смешивали.
Как исследовали
Исследователи сделали 16 пар скилов для одной работы: сообщение коммита, описание пул-реквеста, SQL-запрос, баг-репорт и так далее. В каждом скиле шесть правил и один пример. Правила разделили на четыре типа: противоречащие, совпадающие, переплетённые и независимые. Каждое правило проверяла программа, а для каждой пары был эталонный ответ, соблюдающий все 10 достижимых правил. Правила обоих скилов выполнить нельзя: противоречия делают это невозможным.
Прогнали семь моделей: от маленьких открытых на 4–8 млрд параметров до Qwen3-235B и GPT-4.1. Сравнивали три варианта: один скил, скил плюс скил для другой работы, скил плюс скил для той же работы. Одиночный скил выполнялся на 93–99%. Скил для другой работы ничего не менял. Скил для той же работы снижал результат до 61–62% на всех семи моделях. Модель в 60 раз больше теряла столько же, сколько 4B.
Затем разбирали причину. Убрали примеры, и перехват резко упал. Оставили пример только у одного скила, и он выигрывал почти всегда. Дали обоим скилам один и тот же пример, соблюдающий оба, и перехват снизился до 1–15% даже без слияния файлов. Для сравнения проверили три способа слияния: правила копирует код, правила переписывает сама модель, правила сливает Claude Opus 5.5. Файлы от Opus позволили всем семи моделям выполнять 96–99% достижимых правил. Дальше выяснилось, что основная часть выигрыша — один пример. Добавили тот же пример к простому списку правил, и результат почти догнал файл Claude. Но пример помогал только корректный.
Неожиданностей две. Ожидали, что разбор по шагам с метками превзойдёт простое слияние, а это выполнялось только для сильнейшей модели. У остальных ошибочные метки портили результат. Второе: «применяй оба» на малых моделях почти ничего не дал, а на сильных вернул скил, но оставил сломанными переплетённые правила. Для практики вывод такой: пиши слияние сильной моделью, делай один верный пример и не рассчитывай на строки про приоритет.
Адаптации и экстраполяции
💡 Адаптация для кастомного GPT или системного промпта: у тебя две инструкции для одной задачи, например редполитика компании и личный стиль автора. Каждая заканчивается своим образцом текста, и модель идёт за одним из них. Слей их так же: общий список правил и один образец, соблюдающий оба.
Вот две инструкции по написанию {тип_текста}: редполитика компании
и мой личный стиль. Слей их в один системный промпт.
Правила — списком, при конфликте побеждает {что_главнее}.
В конец добавь ОДИН образец текста на тему «{тема}»,
соблюдающий все правила обеих инструкций. Старые образцы убери.
[редполитика]
[личный стиль]
🔧 Техника: добавить проверку примера → не пропустить неверный образец. Статья показывает, что неверный пример бесполезен, но шага проверки в методе нет. Его легко добавить вторым запросом:
Проверь пример из файла по каждому правилу отдельно:
правило → выполнено / нарушено → где именно.
Если есть нарушения, исправь пример и покажи итоговую версию.
Ресурсы
- Работа: One Skill Takes Over: Clashing Agent Skills and a One-File Fix (SKILLCLASH)
- Авторы: Parsa Razmara, Seyedarmin Azizi, Ardalan Aryashad — University of Southern California, Los Angeles
- Код и данные: https://github.com/prazmara/skillclash
- Близкие работы из статьи: Yan et al. (конфликты скилов в Claude Code, блокирующий хук); SkillFusion (метки пар ограничений); GEPA и SkillOpt (автодоработка промптов через разбор ошибок); IFEval (проверка правил кодом)