TL;DR
Скил (skill) — это файл SKILL.md с пошаговой процедурой для агента вроде Claude Code. Исследователи прогнали 37 публичных скилов для поиска уязвимостей на сотне реальных багов ядра Linux. Вывод: скилы помогают, но слабо. Агент чаще всего не доходит до настоящей причины бага. Лучшие скилы строят процесс в два этапа: широкий поиск кандидатов, затем отдельная стадия рассуждения и проверки. Поверх этого авторы построили SKILL-SIF — цикл, в котором скил дорабатывается по разбору своих же промахов.
Типичная боль: агент выдаёт правдоподобный отчёт, но указывает не ту функцию, не ту строку или не тот класс уязвимости. По разбору запусков причины такие: агент не добирает доказательства, не прослеживает связи между состояниями (кто освободил объект, кто держит блокировку), неверно читает код и бракует кандидатов без проверки. Он не обходит весь код и плохо оформляет находку. Простые баги вроде выхода за границы массива находятся заметно лучше. Баги про время жизни объектов, синхронизацию и ресурсы — хуже.
SKILL-SIF работает как «работа над ошибками» для скила: прогоняешь скил на случаях с известным ответом, находишь пропущенные, диагностируешь, почему агент промахнулся, и переписываешь скил под эти причины. Лучшие скилы после этого на новых, не виденных при доработке уязвимостях стали точнее почти вдвое в среднем. У отдельного скила рост достигал восьми раз, но с очень низкой стартовой точки.
Схема метода
В доступном тексте детали SKILL-SIF не раскрыты, есть только общая логика из аннотации:
ШАГ 1: Прогнать скил на наборе случаев с известным ответом → список пропущенных
ШАГ 2: Для каждого пропуска разобрать трассу агента → паттерн отказа
(не собрал доказательства / не связал состояния / отбросил кандидата без проверки / ...)
ШАГ 3: Переписать скил так, чтобы закрыть эти паттерны → новая версия SKILL.md
ШАГ 4: Повторить цикл (итеративно)
ШАГ 5: Проверить на НОВЫХ случаях, не участвовавших в доработке
Каждый шаг — отдельный запрос или прогон агента. Разбор и переписывание делает сама LLM.
Пример применения
Метод сильнее всего там, где у агента есть чёткий эталон правильного ответа и повторяющийся тип задач. Поэтому берём не ядро Linux, а ревью кода на безопасность в обычном бэкенде.
Задача: Вы техдиректор сервиса доставки еды в Казани. Перед подключением оплаты через СБП нужно проверить модуль payments/ в Claude Code. Ищем двойное списание, гонки при применении промокода и утечку данных карт в логах. Общее «найди уязвимости» агент закончит быстро и поверхностно, поэтому вы задаёте процедуру с обязательными стадиями.
Промпт:
Проведи аудит безопасности каталога payments/ (Python, Django, оплата через СБП).
Работай строго по стадиям и не переходи дальше, пока не закончил текущую.
СТАДИЯ 1. ШИРОКИЙ ПОИСК КАНДИДАТОВ
Просмотри ВСЕ файлы каталога. Составь список подозрительных мест:
файл, функция, строка, подозрение (двойное списание, гонка при промокоде,
чувствительные данные в логах). Ничего не отбрасывай на этой стадии.
СТАДИЯ 2. СБОР ДОКАЗАТЕЛЬСТВ
Для каждого кандидата открой связанный код: кто вызывает функцию,
где меняется состояние заказа и баланса, где берутся и снимаются блокировки
или транзакции. Выпиши, что именно ты прочитал.
СТАДИЯ 3. ПРОВЕРКА
По каждому кандидату напиши цепочку: как нарушитель доходит до ошибки
шаг за шагом. Если цепочку не удалось построить — пиши «отброшен»
и называй конкретную причину со ссылкой на код. Отбрасывать без причины нельзя.
СТАДИЯ 4. ОТЧЁТ
Для каждого подтверждённого кандидата: класс проблемы, файл, функция,
точная строка, цепочка воспроизведения, предложение по исправлению.
В конце — список отброшенных кандидатов с причинами.
Результат: Агент выдаст четыре отдельных блока. Сначала широкий список подозрительных мест, затем выписки о прочитанном коде. Потом разбор каждого кандидата с цепочкой или с обоснованным отказом, а в конце итоговый отчёт с функцией, строкой и классом проблемы. Отброшенные кандидаты будут видны, и вы сможете перепроверить спорные. Отчёт нужно проверить глазами: по исследованию, даже с хорошим скилом агент находит далеко не всё.
Почему это работает
Слабость. Агент склонен завершать работу, как только нашёл что-то правдоподобное. Он не доказывает находку и не проверяет, что отбросил зря. Запрос «найди уязвимости» не заставляет его собирать доказательства и прослеживать связи между состояниями. Баги, которые зависят от порядка событий, времени жизни объектов и блокировок, он видит хуже.
Сильная сторона. Модель хорошо читает код и следует явной процедуре. Если процедура требует «выпиши, что прочитал» или «назови причину отказа», она это делает.
Как метод это использует. Стадии превращают скрытые провалы в обязательные шаги: покрытие, доказательства, проверка, отчёт. SKILL-SIF добавляет к этому обратную связь. Скил дописывается именно там, где агент реально ошибался, а не там, где автору скила казалось, что надо.
Рычаги управления: - Стадия 1 «ничего не отбрасывай» → шире покрытие, больше шума. Для небольшого модуля можно оставить, для большого репозитория сузьте область. - Требование причины при отказе → меньше преждевременных отбраковок. Это ответ на найденный провал «кандидат отброшен без проверки». - Цепочка воспроизведения → отсекает правдоподобные, но пустые находки. - Категории подозрений → подставьте свои. Для сложных классов (гонки, жизненный цикл) добавьте отдельный шаг «кто и когда меняет это состояние».
Шаблон промпта
В тексте статьи нет готового промпта SKILL-SIF и нет текста скилов. Ниже реконструкция по найденным провалам и по описанию цикла. Это не дословный оригинал.
Шаблон 1. Каркас скила (SKILL.md) с закрытием шести слабых мест из таксономии:
# Скил: аудит безопасности {область_кода}
## Когда применять
Когда нужно найти уязвимости класса {классы_проблем} в {путь_к_коду}.
## Процедура
1. ПОКРЫТИЕ. Перечисли все файлы в {путь_к_коду}. Отметь, какие просмотрены.
Не заканчивай, пока не просмотрены все или не указана причина пропуска.
2. КАНДИДАТЫ. Составь широкий список подозрительных мест (файл, функция, строка).
Ничего не отбрасывай на этом шаге.
3. ДОКАЗАТЕЛЬСТВА. По каждому кандидату прочитай вызывающий код и связанные
структуры. Выпиши, что прочитано.
4. СВЯЗИ СОСТОЯНИЙ. Для {сложные_случаи: время жизни объектов / блокировки /
порядок операций} выпиши, кто создаёт, меняет и освобождает объект и в каком порядке.
5. ПРОВЕРКА. Построй цепочку «вход → ошибка». Нет цепочки — «отброшен» + причина
со ссылкой на код.
6. ОТЧЁТ. Класс проблемы, файл, функция, строка, цепочка, исправление.
Отдельно — список отброшенных с причинами.
## Чего не делать
- Не принимать находку без цепочки.
- Не отбрасывать кандидата без причины.
- Не сообщать о проблеме без точной строки.
Шаблон 2. Цикл доработки скила (реконструкция идеи SKILL-SIF):
Вот скил:
{текст_скила}
Вот случай, который скил ПРОПУСТИЛ.
Правильный ответ: {эталон: файл, функция, строка, класс}.
Трасса работы агента: {трасса_или_пересказ}
Ответ агента: {что_агент_выдал}
Задача:
1. Определи, на каком шаге агент ушёл не туда. Выбери причину из списка:
не собрал доказательства / не связал состояния / неверно прочитал код /
отбросил кандидата без проверки / не покрыл все файлы / плохо оформил отчёт.
2. Объясни, какое правило в скиле отсутствовало или было слишком слабым.
3. Предложи минимальные правки скила, закрывающие эту причину. Не раздувай скил
и не вписывай правила, привязанные к этому конкретному случаю.
4. Выведи полную новую версию скила.
Подставляйте: {область_кода} — ваш модуль или сервис, {классы_проблем} — что ищете, {эталон} — известный правильный ответ из прошлых случаев.
🚀 Быстрый старт — вставь в чат:
Вот шаблон скила для аудита и шаблон цикла его доработки. Адаптируй под мою
задачу: [твоя задача — что проверяем и в каком коде].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой код проверяем, какие классы проблем важны и есть ли у вас случаи с известным ответом. Это нужно, потому что скил и цикл доработки опираются на конкретные категории подозрений и эталонные примеры. Она возьмёт структуру из шаблона и соберёт рабочий скил под вашу задачу.
Ограничения
⚠️ Низкий абсолютный результат: даже лучшие скилы полностью правильно находят уязвимость в небольшой доле запусков. После доработки показатель вырос, но всё равно остался низким. Агент не заменяет специалиста по безопасности.
⚠️ Узкая область: проверяли только код ядра Linux на C и только десять классов уязвимостей. Перенос выводов на веб-бэкенд или другие языки логичен, но в статье не проверялся.
⚠️ Агенту дали подсказку: он получал пути к целевым файлам. Реальный аудит «найди всё в репозитории» сложнее, и результаты там будут ниже.
⚠️ Один агент: все запуски шли через Claude Code. Как ведут себя другие агентные среды, неизвестно.
⚠️ Метод в тексте не раскрыт: в доступном фрагменте нет подробностей SKILL-SIF: как именно формулировались правки и как устроен отбор версий. Мои шаблоны — реконструкция.
⚠️ Шум малой выборки: прирост «с 2% до 16%» посчитан на сотне случаев. Это значит, что речь о единицах и десятках находок, поэтому восьмикратный рост на отдельном скиле стоит читать осторожно. Надёжнее ориентироваться на средний прирост.
⚠️ Корреляция, не причинность: вывод «лучшие скилы сочетают широкий поиск и проверку» сделан по сравнению существующих скилов. Отдельно, одним переключателем, это не проверяли.
Как исследовали
Команда собрала с трёх публичных площадок 12 402 скила и отфильтровала их до 37 представительных, по одному на каждый тип процедуры. Для этого модель отсеяла нерелевантные скилы, второй моделью их перепроверили, а спорные случаи разобрали вручную. Затем скилы сгруппировали по тому, как они ищут подозрительный код, собирают контекст, проверяют кандидатов и оформляют находку. Из каждой группы взяли самый популярный.
Тестовый набор: 100 реальных уязвимостей ядра Linux за один месяц, по десять на каждый из десяти классов. Месячная выборка снижает шанс, что модель просто помнит эти баги. Агенту давали код до исправления и пути к файлам, интернет и история изменений были закрыты. Ответ считался полностью верным, только если совпали функция, строка и класс уязвимости. Это жёсткий критерий: правдоподобный отчёт «где-то рядом» не засчитывается. В сумме вышло 14 800 запусков (37 скилов × 100 случаев × 4 модели).
Результат оказался скромным: функцию находили примерно в четверти запусков, а все три критерия вместе сходились примерно в одном из девяти. Простые баги (границы массивов) шли лучше, сложные (время жизни, синхронизация) хуже. Разбор траекторий показал, что агент чаще всего ломается не на «понимании уязвимости», а на дисциплине процесса: не собрал доказательства, не проверил, бросил раньше времени.
Затем доработали пять лучших скилов с помощью SKILL-SIF на исходном наборе и проверили на 100 новых уязвимостях. Результат: полностью верные находки в среднем выросли в 1,85 раза (с 6,05% до 11,20%), на отдельном скиле до 8 раз. Для практики главное, что улучшение переносится на новые случаи, а не заучивается.
Адаптации и экстраполяции
🔧 Техника: обязательная причина отказа → меньше преждевременных отбраковок
Добавьте в любой аудит или ревью: «Если отбрасываешь кандидата, процитируй строки кода, которые доказывают, что проблемы нет». Это прямой ответ на найденный провал «кандидат отброшен без достаточных доказательств».
Экстраполяция: цикл доработки для скилов вне безопасности. В статье не проверялось, но логика переносится на скил для ревью договоров, проверки резюме или разбора обращений в поддержку. Соберите 5–10 случаев, где скил ошибся и где вы знаете правильный ответ. Прогоните через Шаблон 2, получите новую версию скила. Затем проверьте её на 5–10 других случаях, которые не использовались при доработке. Без отдельной проверки вы рискуете переобучить скил на собственные примеры.
Ресурсы
- Работа: How Effectively Do Security Skills Guide Coding Agents in Vulnerability Detection in Linux Kernel?
- Авторы: Haoran Xue, Nikta Akbarpour, Gias Uddin, Song Wang — York University, Канада.
- Площадки скилов из исследования: Claude Marketplace, SkillsMP, ClaudeSkills.info.
- Родственные работы, упомянутые в статье: SkillsBench (влияние скилов на агентов), SkillRevise, EvoSkills, Trace2skill, SkillAdaptor, SkillOpt, GEPA (доработка инструкций по трассам запусков).