На GitHub лежат сотни AI-скиллов. Скилл для code review, скилл для дебага, скилл для обработки PDF, скилл для анализа безопасности. Установил в Cursor или Claude Code — и твой AI-ассистент стал умнее. Звучит как npm install: поставил пакет, он работает.

Но скилл — не пакет. Это текстовый файл с инструкциями, который читает языковая модель. А модели читают по-разному.

Представьте: вы написали подробное ТЗ и отдали его четырём специалистам. Все четверо — профессионалы, все мотивированы, все прочитали ТЗ целиком. Результат будет разный. Каждый делает как его учили, как привык, какой опыт накопил. И всегда есть шанс, что кто-то начнёт не с того конца или вообще решит ответить устно вместо того, чтобы сделать.

Модель = работник. Скилл = ТЗ. Я взял одно ТЗ, отдал четырём работникам, и каждый выполнял его 120 раз. Вот что получилось.

Забегая вперёд: скиллы работают. Но не так, как обещают. И самый интересный результат оказался не там, где я ожидал.

Эта статья — для тех, кто использует или пишет AI-скиллы и хочет понять, чего от них ожидать. Не научная работа, а практический эксперимент с цифрами. Весь код и данные — в репозитории, воспроизведите сами.

---

Скилл — это ТЗ для робота. Хорошее ТЗ.

Если вы не сталкивались со скиллами — объясню за минуту.

AI-скилл — это файл в формате markdown с инструкциями для языковой модели. Вот тебе роль, вот инструменты, вот порядок действий, вот что делать в особых случаях. Устанавливается в IDE (Cursor, VS Code, Claude Code) или передаётся через API. Модель читает инструкцию и пытается ей следовать.

Ключевое слово — «пытается». Как отметил автор подробного руководства по SKILL.md: скиллы не гарантируют исполнение — модель сама решает, следовать ли инструкциям. Это структурированное руководство, которое повышает стабильность, но не детерминированная автоматизация.

Программа при одинаковых входных данных всегда даёт одинаковый результат. Скилл — нет. Это не баг, это фундаментальное свойство: языковая модель не исполняет инструкции, она интерпретирует их. В статье O’Reilly это сформулировано точно: AI-системы ведут себя не как детерминированные компоненты, а как недетерминированные коллабораторы — одни и те же входные данные могут дать разные результаты.

Есть три уровня, на которых результат может разойтись. Первый — разные модели: Claude и GPT читают одну и ту же инструкцию, но «понимают» её по-разному. Второй — разные оболочки: Cursor и VS Code по-разному передают инструкцию модели. Третий — разные запуски: даже одна модель на одном и том же входе может выдать другой результат.

---

Один скилл. Четыре модели. 480 запусков.

На GitHub есть awesome-agent-skills с сотнями скиллов, GitHub Copilot ввёл свой стандарт Agent Skills, Anthropic, OpenAI и Google сошлись на похожем формате. Экосистема растёт. Но ни один скилл в репозиториях не указывает success rate и не помечен «протестировано на моделях X, Y, Z». Anthropic сами признали эту проблему в апреле 2026 года, выпустив eval-фреймворк для скиллов. Я решил проверить, насколько результаты расходятся на практике.

Я написал скилл для обработки входящих обращений пользователей. Тему выбрал универсальную — тикет-система. Каждая компания работает с обращениями, не нужно быть разработчиком, чтобы понять результаты.

Скилл делает три вещи: классифицирует обращение (баг, запрос на фичу, вопрос, жалоба), проверяет дубликаты в базе, создаёт задачу в трекере с правильным приоритетом. Или не создаёт — если обращение не требует задачи.

Я подготовил 10 тестовых обращений четырёх уровней сложности:

• Простые — «не работает оплата картой, клиенты жалуются». Тут всё очевидно: баг, критический.

• Неочевидные — «конкурент уже давно сделал интеграцию с Telegram, когда вы?». Это запрос на фичу, но сформулирован как жалоба. Нужно подумать.

• Цепочки — «не могу войти, коллега тоже не может». Массовая проблема, нужно найти дубликат и привязать к нему. Или: два бага в одном сообщении — нужно создать две задачи.

• Сдержанность — «спасибо, всё заработало, закройте тикет». Задачу создавать не нужно.

Прогнал через четыре модели — те, на которых реально строят продукты:

Все четыре — через OpenRouter, одним API-ключом, одинаковый формат запросов, temperature=0. Ключевые обращения — по 20 повторов, остальные — по 5. Итого 480 запусков со скиллом.

Три уровня сравнения. Чтобы понять, где заканчивается эффект обычного промпта и начинается вклад скилловой структуры, я прогнал ключевые обращения в трёх режимах:

1. Baseline — tools + голое обращение, без system prompt вообще.

2. Простой промпт — одна фраза вместо скилла: «Ты обработчик входящих обращений пользователей. Классифицируй тип обращения, поищи дубликаты в базе и создай задачу в трекере если нужно. Если обращение — вопрос или благодарность, задачу не создавай.»

3. Скилл — полный SKILL.md с правилами приоритетов, порядком шагов, таблицами типов, негативными инструкциями и описанием особых случаев.

Что считается успехом. Успешным считается запуск, в котором совпало всё: правильная классификация типа, приоритет в допустимом диапазоне, правильная последовательность вызовов инструментов, и правильное решение — создавать задачу или нет.

Это разведочный эксперимент, не статистическое исследование. 10 обращений достаточно, чтобы показать паттерны, но недостаточно для статистически строгих выводов. Числа округлены до целых.

---

Результаты

Скилл — это не просто длинный промпт

Первый вопрос, который я ожидал от читателей: «А может любой system prompt даёт такой же эффект? Зачем подробный скилл, если достаточно написать три предложения?»

Вот зачем три уровня сравнения. Результаты по ключевым обращениям (кейсы 1, 5, 7, 9):

Для GPT и Gemini картина предсказуемая: простой промпт даёт основной подъём, скилл добавляет ещё немного сверху. Логично — модель получила задачу, стала работать лучше.

Но у Claude и DeepSeek — сюрпризы.

Claude с простым промптом стал хуже, чем без промпта. 75% baseline → 65% с простым промптом. Короткая инструкция не помогла — она навредила. Зато подробный скилл поднял до 78%. Почему так? Вероятная причина: без промпта Claude опирается на собственное обучение и принимает решения свободно. Короткий промпт задаёт рамку, но не даёт достаточно деталей — модель начинает «следовать инструкции», но инструкция слишком скупа, и модель теряет уверенность там, где без промпта действовала правильно. Подробный скилл решает эту проблему: рамка есть, и деталей достаточно. Сильная модель либо разбирается сама, либо ей нужны детальные инструкции. Полумеры — хуже обоих вариантов.

DeepSeek с простым промптом — 0%. Ноль процентов. Все 20 запусков — ошибки. Половина — вообще не вызвал инструменты, половина — передал неправильные параметры. А со скиллом тот же DeepSeek показывает 62%. Для этой модели разница между простым промптом и подробным скиллом — это разница между нерабочей и рабочей системой.

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

Простые задачи — почти все справились

На прямолинейных задачах (со скиллом) картина ровная:

Даже DeepSeek за $0.55 справляется в четырёх случаях из пяти. «Оплата не работает» → баг → критический — тут все молодцы. Для простой маршрутизации и первичной классификации дешёвая модель со скиллом — рабочий вариант. Экономия по сравнению с Claude — в шесть раз.

Когда НЕ делать — тоже все молодцы

Сдержанность — 100% у всех четырёх моделей. Ни одна не создала тикет на «спасибо, всё заработало» и на вопрос «какие форматы поддерживаете?». Негативные инструкции («когда НЕ создавать задачу») — самая надёжная часть скилла.

На простом и на сдержанности — всё хорошо. А вот дальше начинается цирк.

Ловушки — где DeepSeek паникует

На неочевидных задачах DeepSeek проваливается до 58%.

Обращение 5: пользователь раздражённо пишет «ваш конкурент уже давно сделал интеграцию с Telegram, когда вы?». Claude видит запрос на фичу — человек хочет конкретную функциональность. DeepSeek видит разъярённого клиента и создаёт жалобу с высоким приоритетом. Как стажёр, который услышал повышенный тон и побежал к директору.

Обращение 4: «перешли на новый тариф, в личном кабинете старая цена, деньги списались правильно». Claude понимает — деньги в порядке, проблема только в отображении, приоритет средний. DeepSeek видит слово «деньги» и ставит критический.

Claude и GPT — 100% на неочевидных задачах. Они умеют читать контекст: «деньги списались правильно» = не критично, «потом всё работает» = не критично. DeepSeek читает ключевые слова, а не контекст.

GPT не умеет читать до конца

Обращение 8: «мне третий раз за неделю приходит письмо о продлении, хотя я уже продлил. Плюс в мобильном приложении кнопка «Поддержка» ведёт на 404». Две проблемы в одном сообщении.

Claude — 100%: видит обе проблемы, создаёт две задачи. Gemini — 100%. DeepSeek — 67%. А GPT-4.1 — 17%. В пяти случаях из шести GPT видит только первую проблему и игнорирует вторую.

Как коллега, который читает письмо до середины и бежит исполнять. Вторая половина? Какая вторая половина?

Это не вопрос «кто лучше». Это конкретная слепая зона конкретной модели. Один и тот же скилл, одна и та же инструкция «если в обращении несколько проблем — создай отдельную задачу на каждую». Claude следует. GPT — нет.

Стабильность: топ стабилен, бюджет — рулетка

Ключевые обращения прогонялись по 20 раз. Вопрос: сколько раз из 20 модель даст одинаковый результат?

Claude и GPT при temperature=0 оказались полностью стабильны — каждый запуск давал тот же результат. Это лучше, чем я ожидал.

DeepSeek в каждом восьмом запуске выдавал другой ответ на тот же вход. Та же задача, тот же скилл, та же модель, те же настройки — а результат другой. Если вы строите продукт на бюджетной модели и рассчитываете на предсказуемость — закладывайте запас.

Главная ошибка — одна у всех

Я классифицировал каждую ошибку: модель не вызвала инструмент (тип A), вызвала не тот (тип B), передала неправильные параметры (тип C), нарушила порядок (тип D).

Тип A — «не вызвал инструмент, ответил текстом» — от 78% до 96% всех ошибок. У всех четырёх моделей.

Модели не путают инструменты. Не передают неправильные параметры. Они просто забывают, что инструменты существуют, и пишут ответ как обычный чатбот. Это подтверждает наблюдение из бенчмарка tool-calling: когда задача требует суждения, модели часто не справляются с вызовом инструментов, и размер модели — слабый предиктор точности.

Вы дали работнику набор инструментов, подробную инструкцию — а он просто ответил вам устно, не прикоснувшись ни к одному инструменту.

Итоговая картина

DeepSeek на L3 (цепочки) показал 82% против 78% у Claude — контринтуитивный результат, который может быть связан с малым количеством L3-кейсов в выборке. Относитесь к нему с осторожностью.

---

Скилл работает. Но не как программа. И это нормально.

Скилл — выравниватель, не гарантия

Главный практический вывод: подробный скилл драматически улучшает модели послабее. DeepSeek с 0% (простой промпт) до 62% (скилл). Gemini с 70% до 73%. Для сильных моделей скилл тоже помогает, но иначе — Claude поднялся с 65% (простой промпт) до 78%.

Экономическая логика: зачем платить $3 за Claude на простую классификацию, если DeepSeek за $0.55 со скиллом справляется в 82% случаев на L1? А на сложных задачах — переключайте на Claude.

У каждой модели — свои грабли

GPT-4.1 не видит множественные проблемы в одном обращении. DeepSeek не понимает нюансы классификации и паникует от ключевых слов. Gemini иногда теряет стабильность. Claude — ровный, но дорогой.

Нельзя написать один скилл и забыть. Нужно тестировать на целевой модели. Как минимум — прогнать десять задач пять раз. Это займёт полчаса и сэкономит недели отладки в продакшене.

Что с этим делать

Если вы пишете скиллы: указывайте, на каких моделях тестировали. Публикуйте success rate — хотя бы приблизительный. Негативные инструкции («когда НЕ делать») работают лучше всего — не скупитесь на них.

Если вы строите продукт: тестируйте скилл на вашей конкретной модели, не верьте чужим результатам. Для простых задач — модель послабее + хороший скилл = рабочее решение. Для сложных — скилл не заменяет качество модели. И закладывайте fallback: модель может «забыть» про инструменты в 20-25% случаев.

Если вы делаете платформу: индустрии нужен стандарт skill-карточек — модель, версия, success rate, типы ошибок. Как у npm-пакетов есть engines и peerDependencies. Anthropic уже движется в эту сторону — их eval-фреймворк для скиллов позволяет запускать бенчмарки и A/B-сравнения версий. Но это пока инструмент, а не стандарт.

---

Проверяйте сами

Я не говорю, что скиллы бесполезны — данные показали обратное. Подробный скилл поднял DeepSeek с нуля до 62%.

Я говорю: тестируйте. Измеряйте. Не верьте на слово — ни авторам скиллов, ни мне. Код, скилл, тестовые обращения, сырые результаты — всё в репозитории. Прогоните на своих моделях и своих задачах. Расскажите, что получилось.

Если ваш скилл стабильно работает на трёх моделях с 90% success rate — это отличный скилл. Просто напишите об этом в README.

Хороший скилл превращает модель послабее в рабочую. Но не в отличную. И узнать разницу можно только одним способом — проверить.

---

Эксперимент проведён в апреле 2026 года. Модели: Claude Sonnet 4.6, GPT-4.1, Gemini 2.5 Pro, DeepSeek V3 (deepseek-chat-v3-0324). Все запросы через OpenRouter API, temperature=0. Полная методология, параметры запросов и данные — в репозитории.