Что такое скилл на самом деле

Эта серия статей — о скиллах для ИИ-агентов как об инженерной дисциплине. Материал собран из докладов и разговоров вокруг AI Native DevCon 2026, а четыре части разбирают путь скилла от текстового файла до управляемого элемента цепочки поставок. Первая часть отвечает на базовый вопрос: что такое скилл на самом деле.

Скилл перестал быть личным хаком

Скилл — это в основном текстовый файл. Иногда рядом лежит пара скриптов. Барьер входа почти нулевой, и именно в этом вся проблема.

Джеймс Мосс (James Moss, member of technical staff, Tessl) в докладе «Using skills to pay the bills: graduating from solo hacks to a team workflow» на AI Native DevCon 2026 формулирует это одной фразой: «It's very easy to write a small amount of text and influence how the agent works in quite a powerful way.» Написать немного текста и мощно поменять поведение агента — дёшево. Отсюда то, что Мосс называет кембрийским взрывом скиллов внутри организаций.

Масштаб взрыва он же и приводит, ссылаясь на keynote Гая Поджарни (Guy Podjarny) на той же конференции: больше 2 миллионов скиллов на GitHub в 44 000 репозиториев — и это только публичные. Сколько их лежит в приватных репозиториях и домашних директориях разработчиков, не знает никто, включая сами компании: на вопрос Мосса из зала «у кого есть ясная картина всех скиллов в вашей команде» руки не поднял почти никто.

Параллельно скиллы перестали быть игрушкой. В эпизоде «Inside Anthropic: How Claude Tag Is Changing Agentic Work» инженер applied AI team Anthropic приводит внутренние цифры: 65% пул-реквестов продуктовых команд открывает агент, а доля работы, которую компания готова ему делегировать, за год выросла примерно с 30% до 60%. В той же беседе скилл описан как единица кодификации процесса целиком: поймать фидбек в канале, затегать ответственных, завести тикет, поднять песочницу, написать код, попросить ревью — с настраиваемыми человеческими гейтами внутри. Речь о способе, которым организация записывает, как она работает, и он давно вышел за рамки «удобного промпта».

В чём тезис

Скилл — это единица знания, у которой есть версия, владелец, тест и уязвимости. Всё остальное в этой серии — следствия.

Версия — потому что скилл, который у тебя стоит, и скилл, который автор выпустил вчера, ведут себя по-разному, а устаревший скилл, по формулировке Мосса, часто ровно так же плох, как его отсутствие. Владелец — потому что текст, влияющий на вывод агента у сорока человек, не может быть ничьим. Тест — потому что единственный способ узнать, что скилл помогает, а не мешает, это прогнать задачи с ним и без него. Уязвимости — потому что чужой скилл ты ставишь себе на машину вместе с кодом, который агент возьмёт и выполнит. Исследование Snyk нашло в публичном каталоге 76 скиллов с чистым вредоносным кодом, а звучавшая на DevCon оценка доли вредоносных на OpenClaw доходила до 20%.

Сложи это вместе, и получится инженерная дисциплина со своей цепочкой поставок: авторинг, ревью, версионирование, реестр, сканирование, политики установки, эволюция и вывод из эксплуатации.

Почему это ощущается знакомым

Мосс заканчивает доклад аналогией, которая объясняет происходящее лучше любой методологии. PHP, 2005 год: пакетного менеджера нет, зависимости качаются zip-архивом с SourceForge и вендорятся прямо в кодовую базу без ревью, версионирование — по прихоти автора, деплой по FTP сразу в продакшен. Отрасли понадобилось около десяти лет, чтобы построить пакетные менеджеры, lock-файлы, реестры, CI, сканирование зависимостей и подписанные релизы.

Скиллы сейчас находятся ровно в 2005 году. Хорошая новость, по Моссу, в том, что мы уже знаем, чем эта история заканчивается, — второй раз десять лет тратить не нужно. У каждой практики из мира кода есть прямой аналог для контекста: skill review — это линтинг и юнит-тесты, evals — e2e-тесты, реестр скиллов — реестр пакетов, а человеческие проблемы те же самые: силосы знаний и bus factor.

Что дальше

Серия состоит из четырёх статей и завершается чек-листом зрелости, по которому команда может понять свой текущий уровень. Вторая статья рассказывает, как личный скилл становится командным активом: репозиторий, владелец, semver, ревью, синхронизация документации и запрет локальных скиллов. Третья посвящена цепочке поставок: два вектора атаки, находки Snyk, внутренние инциденты и то, почему сканировать нужно в реестре, а не после скачивания. Четвёртая — про практику авторинга и проверки. Там же честно разобран прямой спор источников: Cisco утверждает, что скиллы вообще не надо писать руками, другие говорят, что сгенерированные моделью скиллы дают меньший прирост, а иногда и регресс. Обе позиции подкреплены, и обе стоит услышать целиком.

Всё, что здесь сказано, сказано со сцены конкретными людьми в конкретных докладах. Где спикер сам оговаривался, что помнит цифру приблизительно, — это отмечено. Дисциплина новая, часть практик к следующему году устареет, и это тоже нормальная часть картины.

Что такое скилл на самом деле

Единственный рычаг, который у тебя есть

Джеймс Мосс (Tessl, доклад «Using skills to pay the bills», AI Native DevCon 2026) начинает с уравнения: агент — это функция трёх переменных, модель × harness × контекст. Модель тебе, как правило, выбирает организация. Harness тоже: в компании стоит Claude Code, или Copilot CLI, или Codex, и менять это решение по своему желанию ты не будешь. Остаётся контекст. Это единственная переменная, до которой у рядового инженера есть прямой доступ, и потому единственный реальный рычаг влияния на качество вывода.

Скиллы внутри контекста ценны отдельно, потому что кодируют доменную и бизнес-логику, которой в обучении модели не было и быть не могло. Джон Гретцингер (John Groetzinger, principal engineer, Cisco) в докладе «Skills Everywhere» на AI Native DevCon London 2026 доводит мысль до формулы: «You don't really need a smarter model today... The problem is really that you need smarter context.»

Промпт, правило, скилл, MCP-сервер

Границы между этими четырьмя вещами постоянно путают, а ведут они себя по-разному.

Что	Когда попадает в контекст	Кто владеет	Что кодирует
Промпт в чате	Один раз, вручную	Тот, кто печатает	Разовое намерение
Правило (CLAUDE.md, agents.md)	Всегда, целиком	Репозиторий	Постоянные ограничения проекта
Скилл	По решению агента, когда сработало описание	Автор или команда-владелец	Процедурное знание: как делается конкретная работа
MCP-сервер	По вызову инструмента	Владелец системы	Доступ к живому состоянию и действиям

Ключевое отличие скилла от правила — избирательность. Правило платит контекстом всегда, скилл платит только тогда, когда он нужен. Отличие от промпта Патрик Дебуа (Patrick Debois, Tessl) на панели «Why Agents Are Forcing Enterprises to Finally Fix Their Dev Process» свёл к одному совету, который дал бы разработчику, если бы можно было дать только один: «Don't keep telling the agent what to do, but write something down.» Если ты второй раз объясняешь агенту одно и то же в чате — это заявка на скилл.

Отличие от MCP-сервера самое важное и чаще всего игнорируемое. Роксана Фишер (Roxanne Fischer, CEO и сооснователь AnyShift) в докладе «Why LLMs Break for Infrastructure» показывает границу на конкретном примере: агент генерирует некорректный Terraform не потому, что не знает синтаксис, а потому, что ID существующих ресурсов живут только в облаке — часть из них вообще создана руками через консоль и в коде не отражена. Скилл кодирует знание и практику, но не текущее состояние системы. За состоянием нужен живой источник.

Обратное тоже верно. Андерс Свонсон (Anders Swanson, developer advocate, Oracle) в Tessl Skills Clinic описывает связку прямо: скилл даёт агенту знание точного синтаксиса, MCP-сервер базы данных — доступ к живой базе. Порознь каждый работает хуже.

Зачем скилл, если модель и так умная

Два ответа, и оба со сцены.

Первый — Свонсон, Oracle: скилл нужен там, где модель пойдёт в документацию и блоги и всё равно нагаллюцинирует. Пример — точный SQL-синтаксис property graph в Oracle. Скилл кладёт синтаксис в локальный файл, агент подтягивает его в контекст и делает с первого раза. И в тот же файл попадает не только «как», но и «как правильно»: защита от SQL-инъекций, соображения масштабируемости.

Второй — Гретцингер, Cisco: модели обучены на устаревших практиках. Просишь завести новый Python-проект — получаешь requirements.txt и pip, потому что так написано в половине интернета. Скилл «стандарт репозитория» фиксирует, что в компании используется только UV, и инженеру больше не нужно помнить, как правильно заводить проект. Это самый дешёвый класс выигрыша: скилл на несколько десятков строк, который каждый раз экономит один и тот же спор.

Устройство: SKILL.md для агента, README.md для человека

Гретцингер описывает раскладку Cisco так: всё живёт в git-репозитории, SKILL.md пишется для агента, README.md — для человека, перекрытие между ними примерно 80%, и поддерживает оба файла LLM, поэтому дублирование обходится дёшево.

Сам скилл при этом не обязан быть одним файлом. По Гретцингеру, скилл может быть тривиальным, а может включать дополнительные markdown-файлы с правилами, скрипты и скаффолдинг. Его совет по границам применимости стоит держать в голове при любом расширении: «Define the bare minimum that you expect this skill to always help with and always do it well.» Сначала определи минимум, который скилл обязан делать хорошо всегда, — потом не ломай его, обвешивая скилл новыми возможностями.

Стоит держать в голове и то, что скиллом кодируется не только инженерный приём. В эпизоде «Inside Anthropic: How Claude Tag Is Changing Agentic Work» инженер applied AI team Anthropic описывает скиллы, которые прошивают кросс-функциональный процесс целиком: поймать фидбек в канале, затегать ответственных, завести тикет в Linear, поднять песочницу, написать код, пинговать на ревью — с настраиваемыми человеческими гейтами на нужных шагах. То есть скилл кодифицирует процесс организации целиком, и объяснение агенту синтаксиса — лишь одна из его ролей. Из этого следует и требование к владению: у процесса в компании обычно есть ответственный, и у скилла, который этот процесс описывает, он тоже должен быть.

Ещё одно свойство, о котором легко забыть: скилл переживает агента. Мосс замечает, что в публичных репозиториях скиллов список путей под разные агенты (.claude, .codex, .gemini и дальше по алфавиту) тянется до буквы K и не думает заканчиваться, а через полгода набор агентов будет другим. Его вывод: «Skills are effectively your durable asset. The agent is just the runtime.» Раскладку по агентским директориям должен абстрагировать пакетный менеджер, а не автор скилла.

Прогрессивное раскрытие — это дерево, а не длинный файл

Свонсон показывает оракловский репозиторий скиллов как пример структуры: директории по продуктам, внутри поддиректории по компонентам, в каждой один SKILL.md, из которого линками расходится дерево справочных файлов — например, отдельный файл про контейнеры базы данных с pull-командами, путями к образам и паттернами запуска. Агент стартует сверху и спускается ровно по той ветке, которая нужна текущей задаче.

Смысл дерева глубже красивой раскладки: контекст платный, и всё, что агент прочитал, он оплатил токенами и местом в окне. Дерево позволяет положить в скилл много знания, но подгружать за раз мало.

Рекомендуемый размер одного SKILL.md, звучавший в Skills Clinic, — не более 500 строк. Это не физический лимит, а порог, за которым файл перестаёт быть прогрессивно раскрываемым и превращается в монолит.

Description — единственный триггер активации

В метаданных SKILL.md два поля решают всё: name и description. Ненна Ндукве (Nnenna Ndukwe, Qodo) и Андерс Свонсон в Skills Clinic под ведением Саймона Мейпла (Simon Maple, Tessl) сходятся на том, что описание работает в первую очередь как механизм активации. Оно инжектится в контекст заранее и определяет, вспомнит ли агент про скилл вообще.

Формулировка из клиники: «If that description is bad, it will never trigger your skill. And it's such a key piece that people miss.» Люди пишут в описание пару слов «на отвяжись» — и скилл не срабатывает никогда, а автор считает, что скилл плохой. Рекомендация ревью, которую получил скилл Qodo: добавить в описание естественные триггерные фразы — те слова, которыми задачу называет человек («issues», «code review»), — чтобы агент себя по ним опознал.

Важная оговорка оттуда же: хорошее описание и хороший скилл — это две разные оси. Отличное описание у плохого содержимого означает лишь, что плохой скилл будет срабатывать чаще.

Overloading: скилл, который тихо перестал существовать

Это самый неочевидный из известных режимов отказа, и его стоит знать до того, как ты соберёшь в проекте три десятка скиллов.

Механика, по Моссу: имя и описание каждого установленного скилла инжектятся в начало каждого контекстного окна. У большинства агентов есть лимит на суммарный объём этого блока, выраженный как процент контекстного окна. Когда суммарный объём описаний этот лимит превышает, агент молча обрезает описания. Скилл при этом никуда не девается — он лежит на диске, он установлен, он валиден. Но ключевые слова из его описания в контекст не попали, значит активироваться он не может.

Два обстоятельства делают это особенно неприятным. Первое: конкретный процент со сцены не назвали — поведение зависит от агента и, по словам Мосса, фактически undefined. Второе: диагностируемого признака нет. Ни ошибки, ни предупреждения, ни строчки в логе не появится. Агент просто перестаёт пользоваться скиллом, а ты будешь чинить описание, содержимое, формулировки задачи — всё, кроме реальной причины.

Практический вывод: количество установленных скиллов — это ресурс с потолком. Набор из двухсот скиллов «на всякий случай» вытесняет те скиллы, которые действительно нужны.

Коротко

• Из трёх переменных агента (модель, harness, контекст) тебе доступна одна — контекст. Скиллы кодируют в нём то, чего не было в обучении модели.
• Скилл отличается от правила избирательностью, от промпта — тем, что записан, от MCP-сервера — тем, что несёт знание, а не состояние. За состоянием всё равно нужен живой источник (Roxanne Fischer, AnyShift).
• Структура зрелого скилла: SKILL.md для агента, README.md для человека (перекрытие ~80%, Cisco), и дерево справочных файлов, по которому агент спускается по нужной ветке (Oracle).
• Описание — единственный триггер активации. Без естественных триггерных фраз скилл не сработает никогда, каким бы хорошим ни было содержимое.
• Overloading — молчаливый отказ: описания всех скиллов инжектятся в каждый контекст, при превышении лимита обрезаются, и скилл перестаёт вызываться без единого диагностируемого признака.
• Ориентир по размеру — до 500 строк на SKILL.md. Дальше начинается монолит.