Аудит скилов на противоречия: чинить стоит то, что агент реально выполнит, и зависит это от модели

ШАГ 1: Прочитать весь скил целиком (SKILL.md + скрипты + конфиги) → карта: что в нём есть и что на что ссылается
ШАГ 2: Искать противоречия по трём границам → список находок
        • Среда ↔ скил (версии, зависимости, пути, права)
        • Документ ↔ документ (две части описания говорят разное)
        • Документ ↔ код (обещано одно, сделано другое)
ШАГ 3: Отсеять мелочи (код умеет больше, чем описано — обычно безвредно) → подтверждённые находки
ШАГ 4: Ранжировать по достижимости: попадёт ли это место в обычный запуск? → приоритет
ШАГ 5: Минимально исправить одно место (не переписывать скил) → «чинёный» скил
ШАГ 6: Сравнить результат задачи: без скила / оригинал / исправленный → решить, стоила ли правка усилий

Шаги 1–4 можно сделать в одном чате или в одной сессии агента. Шаг 6 требует нескольких запусков.

Задача: Вы руководите небольшим интернет-магазином на Wildberries и Ozon. Вы скачали из открытого репозитория скил для Claude Code «еженедельный отчёт по выручке из выгрузок маркетплейсов». Дешёвая модель на нём то и дело выдаёт отчёт с неправильным порядком недель и ломается на установке pandas. Перед тем как винить модель, вы проверяете сам скил.

Промпт:

Ты аудитор скилов для агентов. Ниже папка скила «weekly-revenue-report»: 
SKILL.md, README.md, scripts/build_report.py, requirements.txt.

Найди противоречия по трём границам:
1. Среда ↔ скил: версии Python/библиотек, пути, права, внешние сервисы.
2. Документ ↔ документ: SKILL.md, README и комментарии говорят о разном.
3. Документ ↔ код: документация обещает то, чего код не делает 
   (over-promised), или код делает противоположное написанному.
   Если код умеет больше, чем описано — пропусти, это безвредно.

Для каждой находки: тип, цитата из каждого файла с номерами строк, 
почему это конфликт, попадёт ли это место в обычный запуск 
(да / нет / не уверен), как минимально исправить.
В конце — топ-3 находки по вероятности сломать результат.

[вставить содержимое файлов]

Результат: Модель выдаст структурированный список находок. У каждой будет тип (среда, документ-документ, документ-код), две цитаты рядом, оценка «попадёт ли в запуск» и вариант минимальной правки. В конце будет короткий приоритетный топ-3. Ожидайте в нём конфликты версий и места, где в тексте обещана сортировка или проверка, а в скрипте её нет. Часть находок придётся отбросить вручную как ложные.

Слабость: Агент читает скил как инструкцию, а не как спор. Если в тексте написано «сортируй по дате», слабая модель так и сделает, даже когда рядом лежит скрипт, который этого не умеет. Она не сверяет обещания с реальностью, а исполняет текст. Поэтому ошибка в скиле становится ошибкой в результате.

Сильная сторона: LLM хорошо находит расхождения между двумя фрагментами текста, если положить их рядом и прямо спросить. Сопоставить цитату из README с кодом ей проще, чем ловить ошибку «на лету» при выполнении. Поэтому аудит до запуска работает лучше, чем надежда, что агент сам разберётся.

Как метод это использует: Вы переносите проверку из момента выполнения в момент подготовки. Три границы дают модели чёткую рамку вместо расплывчатого «найди ошибки». Фильтр «попадёт ли в запуск» не даёт утонуть в сотне безобидных замечаний. Статья показывает, что именно ранжирование по достижимости важнее, чем число находок.

Рычаги управления: - Модель агента. Слабая или дешёвая модель: чини скил обязательно. Сильная: можно сначала проверить без правок. - Фильтр «безвредных». В оригинале «код умеет больше, чем описано» отбрасывают. Для скилов, которые потом читают люди, этот фильтр можно убрать. - Режим правки. «Минимальная правка» держит скил стабильным. «Перепиши целиком» — риск внести новые расхождения. - Глубина проверки. Попросите «не уверен» вместо вердикта, и модель не станет выдумывать конфликты.

В статье нет готового текста промпта: аудитор SkillAudit — это код с несколькими LLM-проверками. Шаблон ниже собран по его описанию и таксономии из статьи, то есть это реконструкция.

Ты аудитор скилов для LLM-агентов. Твоя задача — найти места, где части 
скила противоречат друг другу, и оценить, сломают ли они выполнение.



Скил: {название_скила}
Файлы:
{содержимое_файлов_с_именами_и_номерами_строк}



Шаг 1. Карта скила. Перечисли файлы, что каждый делает, на что ссылается.
Шаг 2. Поиск по трём границам:
  A. Environment: скил ↔ среда ({среда_запуска}). Версии, зависимости, пути, права.
  B. Inter-Document: документ ↔ документ. Разные версии, шаги, ограничения 
     в SKILL.md, README, комментариях.
  C. Document-Code: документ ↔ код. Отмечай два вида:
     • Over-promised: документация обещает, код не делает
     • Semantically-conflicting: оба описывают поведение, но по-разному
     Under-promised (код умеет больше, чем описано) — не включай.
Шаг 3. Проверка каждой находки: убедись, что обе цитаты есть и действительно 
  конфликтуют. Сомнительное помечай «не уверен», не выдумывай.
Шаг 4. Достижимость: для каждой находки ответь, попадёт ли это место 
  в обычный запуск по задаче «{типовая_задача}»: да / нет / не уверен.



Для каждой находки:
- Тип (A / B / C-over / C-conflict)
- Цитата 1 (файл:строка) и цитата 2 (файл:строка)
- Почему это конфликт
- Достижимость: да / нет / не уверен
- Минимальная правка: что изменить в ОДНОМ месте. Не переписывай остальное.
В конце: топ-3 находки по вероятности сломать результат.

Что подставлять: - {название_скила} — имя папки или навыка. - {содержимое_файлов_с_именами_и_номерами_строк} — тексты файлов. Номера строк нужны, чтобы цитаты можно было проверить. - {среда_запуска} — например, «Python 3.11, Linux, без интернета». - {типовая_задача} — что обычно просит пользователь от этого скила.

🚀 Быстрый старт — вставь в чат:

Вот шаблон аудита скилов. Адаптируй под мой скил: [опиши, что делает скил и в какой среде запускается].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит про среду запуска, типовую задачу и состав файлов. Достижимость нельзя оценить без знания, что именно будет запускаться. Она возьмёт структуру из шаблона (три границы, фильтр «безвредных», достижимость, минимальная правка) и соберёт готовый промпт под ваш скил.

⚠️ Масштаб экспериментов: Влияние исправлений измеряли на 49 задачах и трёх небольших моделях. Там по одному целевому дефекту на задачу. Реальные скилы содержат много дефектов одновременно, и их взаимодействие не изучали.

⚠️ Нет флагманов: Проверяли Claude Haiku 4.5, Qwen3.6-35B (с 4-битным сжатием) и DeepSeek-V4-Flash без режима рассуждений. На самых сильных моделях картина, возможно, ещё мягче, но этого статья не показала. Абсолютные сравнения моделей между собой авторы просят делать осторожно.

⚠️ Эффект не одинаков: Для одной модели правка дала заметный прирост, для другой почти нулевой. Универсального «починил скил — стало лучше на X%» нет.

⚠️ Аудит сам делает LLM: Автоматический поиск противоречий давал ложные срабатывания, поэтому авторы подтверждали находки вручную. Результат промпта-аудитора надо проверять глазами.

⚠️ Нет готового промпта: Статья даёт таксономию и описание конвейера, но не текст промптов. Шаблон выше — реконструкция. Проверять его эффективность вам придётся самим.

⚠️ Текст обрезан: В полученной версии нет части метрик (затраты токенов, шаги). Выводы об эффективности выполнения здесь не разобраны.

Идея была простая: если в скиле есть противоречие, это плохо? Исследователи собрали 575 скилов: 488 из популярных GitHub-репозиториев и 87 из тестового набора SkillBench. Сначала сделали таксономию противоречий: среда, документ-документ, документ-код. Затем автоматический инструмент нашёл кандидатов, а двое авторов вручную подтвердили 1182 реальных несостыковки. Они встречаются у 67% скилов с GitHub и у 64% скилов SkillBench. Даже вручную написанные образцовые скилы не чище. В SkillBench больше всего случаев «документ обещает, код не делает» (45,6% всех находок).

Потом пришёл главный эксперимент. Из 49 находок сделали выполняемые задачи в Docker, с проверкой результата программой, без LLM-судьи. Для каждой создали пару: исходный скил и минимально исправленный. Каждую задачу прогнали в трёх режимах (без скила, исходный, исправленный) на трёх моделях, по три повторения. Всего получилось 441 пара траекторий для разбора.

Удивило вот что. Казалось бы, у моделей разный прирост, потому что одни читают скил, а другие нет. Но скил читали в 97% запусков. Разница возникает после контакта с ошибкой. Haiku шёл за ошибкой в провал в 30% запусков, Qwen в 24%, DeepSeek в 12%. При этом DeepSeek восстанавливался в 56% случаев, когда ошибку заметил. Вывод для практики: считать дефекты в скиле бесполезно. Нужно смотреть, на какой модели скил работает и попадает ли дефект на реальный путь выполнения.

Таксономия противоречий (определения слоёв дословно):

We first classify inconsistencies by the participants of the violated contract:
• Environmental layer: Skill vs. runtime environment.
• Inter-document layer: conflicts among descriptive documents.
• Document-code layer: documentation vs. implementation.

Within the Document-code layer, we further classify inconsistencies by the direction of deviation:
• Over-promised (Doc > Code). The documentation promises functionality, constraints, or behavior that the implementation does not provide.
• Semantically-conflicting (Doc ≠ Code). The documentation and implementation both specify the relevant behavior but contradict each other semantically.
• Under-promised (Doc < Code). The implementation provides capabilities that are not documented.

Контекст: Это основа, по которой инструмент SkillAudit искал находки. Under-promised случаи авторы по умолчанию отбрасывали как безвредные.

💡 Адаптация: минимальная правка противоречия

Статья описывает правило ремонта: правка точечная, решение не «подсказывает» ответ задачи. Для чата это превращается в отдельный промпт на второй проход:

Вот находка из аудита: {находка}.
Определи, какой из двух фрагментов авторитетнее (ориентируйся на то, что 
реально работает в {среда_запуска}). Исправь ТОЛЬКО это место: 
согласуй описание или код. Если обещание нельзя выполнить в нашей среде, 
сузь документацию, а не пиши новый код. Не меняй ничего другого.
Покажи diff.

🔧 Техника: добавить «стоп-правило» в файл инструкций → меньше слепого следования (экстраполяция, в статье не проверялась)

Статья показала, что слабые модели слепо идут за ошибочной инструкцией. Логично попробовать добавить в CLAUDE.md или AGENTS.md:

Если в инструкциях скила и в реальном поведении скриптов, ошибках или 
выводе команды есть расхождение — не продолжай по инструкции. 
Назови расхождение одной строкой и выбери вариант, который подтверждён 
реальным выводом.

Это гипотеза по мотивам вывода «сильные модели сами замечают и обходят ошибки». Эффективность этой фразы нужно проверить на ваших задачах.

• Название работы: Why Static Skill Inconsistencies Do Not Equate to Runtime Risks: A Behavioral Analysis of LLM Agent Execution
• Авторы: Fengrui Fan, Huahao Wang, Jingyi Fang, Yutao Hu, Yueming Wu, Deqing Zou
• Организация: Huazhong University of Science and Technology, China
• Упоминаемые в работе: SkillBench (набор скилов с эталонными задачами), SkillAudit (инструмент статического аудита), WildSkills (набор из 49 проверяемых задач)
• Проверяемые модели: Claude Haiku 4.5, Qwen3.6-35B-A3B, DeepSeek-V4-Flash