Скиллы как дисциплина

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

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

Джеймс Мосс (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.

Что дальше

Дальше — четыре раздела и чек-лист.

Раздел 1 разбирает, чем скилл отличается от промпта, правила и MCP-сервера, как он устроен внутри и какие у него встроенные ограничения, включая самый неприятный failure mode — молчаливое отключение при переполнении контекста.

Раздел 2 — про переход от личного хака к командному активу: репозиторий, владелец, semver, ревью, синхронизация документации и запрет локальных скиллов.

Раздел 3 — про цепочку поставок: два вектора атаки, находки Snyk, внутренние инциденты и то, почему сканировать нужно в реестре, а не после скачивания.

Раздел 4 — про практику авторинга и проверки. Там же честно разобран прямой спор источников: 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, поднять песочницу, написать код, пинговать на ревью — с настраиваемыми человеческими гейтами на нужных шагах. То есть скилл — это единица кодификации процесса организации, а не только способ объяснить агенту синтаксис. Из этого следует и требование к владению: у процесса в компании обычно есть ответственный, и у скилла, который этот процесс описывает, он тоже должен быть.

Ещё одно свойство, о котором легко забыть: скилл переживает агента. Мосс замечает, что в публичных skills-репозиториях список путей под разные агенты (.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: скилл, который тихо перестал существовать

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

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

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

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

Коротко

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

От личного хака к командному активу

Личный скилл рождается за одну сессию. Кшиштоф Хушча (Krzysztof Huszcza, product leader AI security, Snyk) в эпизоде «76 Malicious AI Skills Were Hiding in Plain Sight» описывает свою рабочую практику буквально в одну строчку: прошёл workflow один раз вместе с агентом, в конце сессии сказал «напиши скилл, чтобы повторить это», сохранил. Это тривиально.

Дальше начинается всё остальное. Его же формулировка: «When I want to share that with other people, that is much more tricky because now I want the skill to generalize.» Между «работает у меня» и «работает у сорока человек» лежит примерно всё содержание этого раздела.

Четыре режима отказа, которые появляются от масштаба

Джеймс Мосс (Tessl) перечисляет их как список того, что ломается само собой, без чьей-либо ошибки.

• Overlap. Несколько команд независимо пишут один и тот же скилл. Никто не виноват, просто никто не знал.
• Drift. Вышла новая версия чужого скилла, команды её не подхватили. Пример со сцены: Мэтт Покок выпустил grill-with-docs вместо grill-me, и многие продолжают сидеть на старом. Вывод Мосса: «Having an outdated skill can often be just as bad as having no skill at all.»
• Отсутствие activation. Непонятно, вызываются ли скиллы вообще — ни людьми, ни агентами. Скилл может быть написан, установлен и ни разу не сработать.
• Overloading. Описания переполнили лимит, часть скиллов молча выпала (разбор механики — в разделе 1).

Состояние отрасли Мосс иллюстрирует цитатами своих заказчиков. «It's a free fall right now. For the most part everyone's been doing their own thing.» Скиллы размазаны по десяткам репозиториев, свести их, централизовать и раздать по командам практически невозможно.

Из этого выросла отдельная продуктовая категория — инвентаризация. Tessl подключается к GitHub-организации, вытягивает все найденные скиллы по всем репозиториям и показывает разбивку: по репозиторию, по скиллу, first-party против third-party, потребление токенов, плюс автоматически находит перечисленные failure modes. Для сторонних скиллов подтягиваются ревью, eval-скоры и результаты security-сканов из публичного реестра. На момент доклада — private beta.

Первое правило: никаких локальных скиллов

Скилл, живущий в домашней директории разработчика, а не в репозитории, ломает воспроизводимость самым неприятным способом: два человека запускают одну задачу на одном коде и получают разный результат. И расхождение невозможно отладить — скилла нет ни в диффе, ни в ревью, ни в CI. Бумажного следа не остаётся вообще.

Мосс приводит на этот счёт цитату Бориса Черни, создателя Claude Code, прозвучавшую на закрытом форуме: «We ban any local setup. All agent workflow improvements, hooks, skills, etc. must be checked into the repo for everyone.»

Фикс здесь ровно тот же, что для кода, и формулируется одной строкой: то, что влияет на вывод, версионируется рядом с тем, на что оно влияет. Локальный скилл — это «works on my machine», перенесённое на контекст.

Репозиторий команды и правила общей библиотеки

Cisco решает вопрос хранения так: у каждой инженерной команды свой репозиторий скиллов — не по проектам, а по командам. PR может открыть кто угодно. Правило Гретцингера: «It's not any different than a shared library with unit testing.» Не сломай функциональность для остальных, а доказательство того, что не сломал, — evals.

Побочный эффект такой раскладки — поиск. На вопрос из зала, как агенту находить нужный скилл при масштабе, Гретцингер отвечает без изящества и по делу: самое дешёвое работающее решение сегодня — сложить все скиллы в один GitHub-репозиторий и дать агенту грепать по нему. Специализированные серверы поиска по скиллам — следующий шаг, но грепа по репозиторию хватает надолго.

Semver как сигнал доверия, а не формальность

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

• 0.0.x — «я пользуюсь этим сам».
• 0.x — обкатано в узкой группе.
• 1.0 — обещание, что скилл сработает как заявлено, с первого раза и почти без трения.

«If I go look at a skill and it's version 1.0, I expect it to do exactly what it's supposed to do on the first try... And if it doesn't do that, you've lost my trust.» Обратная сторона обещания: выставил 1.0 и не выполнил — доверие потеряно не к версии, а к тебе как к автору.

Практический смысл в том, что semver здесь решает проблему, которую в организации обычно решают репутацией и слухами. Инженер видит номер версии и понимает, брать ли скилл в свой рабочий поток, не спрашивая никого.

Один источник для агента и для человека

У версионирования есть скучная, но критичная спутница — синхронизация документации. У Cisco задача выглядела так: агенты читают SKILL.md, а менеджеры в git не заходят вообще.

Решение Гретцингера: README.md детерминированным скриптом конвертируется в страницу Confluence — # превращается в H1 и так далее. Не через LLM — это токеноёмко и здесь не нужно. В результате агенты и менеджеры читают ровно один источник, дрейфа между «что написано в скилле» и «что написано в вики» не возникает по построению.

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

Владелец: кто в организации отвечает за скиллы

Единого ответа со сцены нет, и панель «Why Agents Are Forcing Enterprises to Finally Fix Their Dev Process» (Патрик Дебуа, Tessl; Дэниел Джонс, re:cinq; Таммуз Дубнов, Autonomy AI) честно это признаёт.

Чаще всего скиллы достаются DevEx- или платформенной команде: строить, раздавать и обеспечивать качество скиллов логично ложится на тех, чья работа — снижать когнитивную нагрузку разработчиков. Проблема в том, что нынешние платформенные команды заточены на инфраструктуру и не являются AI-savvy, — образуется вакуум. При этом именно они контролируют бюджет, модели и гейтвеи, так что мимо них всё равно не пройти. Панель отмечает и то, что платформенных отделов может быть несколько — cloud, AI, data platform, — и тогда вопрос владения усложняется ещё на уровень.

Исторический паттерн, на который ссылаются участники: сначала маленькая incubation-команда (как когда-то agile-команда, потом DevOps-команда), затем практика расползается по организации, и отдельная «команда по скиллам» исчезает за ненадобностью.

Раздача практики скиллом вместо митинга

Со сцены: eval-фреймворк в восемь команд за неделю

• Кто и где: Джон Гретцингер, principal engineer, Cisco — доклад «Skills Everywhere», AI Native DevCon London 2026
• Что показали: нужно было внедрить единый eval-фреймворк в восемь распределённых по миру команд. Митинг для этого не годится — «никакой разработчик не любит тестирование», слушать не будут. Вместо митинга сделали плагин со скиллом, примерами скриптов и примерами evals. Команды поставили плагин и попросили своего кодинг-агента сделать «то, что хочет Джон».
• Цифры: 8 команд, около одной недели, организация в сотни инженеров.
• Что это меняет: к концу недели у всех команд были датасеты в одном формате и сопоставимые метрики. Без этого получили бы шкалы 0–10 у одной команды, 0–5 у другой, 0–1 у третьей — то есть метрики, которые невозможно сравнивать между собой.

Тот же механизм с другой стороны описывает Таммуз Дубнов (Autonomy AI): один человек находит полезный приём — и есть готовый способ раздать его всем, после чего учится вся команда, а не один инженер. Скилл здесь работает как канал распространения практики, а не как инструкция.

Есть и культурная часть, которую Cisco насаждает намеренно. Любой повторяющийся вопрос в мессенджере — «где инфа по DevOps», «как получить доступ к кластеру» — получает в ответ не объяснение, а вопрос: есть ли на это скилл? Если нет, заводим и поддерживаем вместе. Мотив Гретцингера прямой: «I don't want 15 engineers creating 15 skills for the same thing.»

Пайплайн «статья базы знаний → скилл»

Самый проработанный процесс во всём материале — кейс Cisco TAC, и начался он с провала.

Первая попытка была очевидной: дать агенту инструмент поиска по корпоративной базе знаний и пусть разбирается сам. Отдельные победы были, но много галлюцинаций — в базе лежат протухшие статьи, и скармливать их агенту без отбора нельзя. Дальше пришла вторая беда: агенты строят собственные memories, те дрейфуют от исходных статей, и ответ клиенту начинает противоречить статье, на которую он же ссылается. После этого, замечает Гретцингер, доверие теряется ко всей системе целиком, а не к отдельному ответу.

Что сделали вместо этого:

1. Отбор руками. В скиллы конвертируются вручную отобранные высококачественные статьи, а не всё подряд.
2. Триггер на изменение. Статью поменяли — запускается пайплайн.
3. Классификация диффа. LLM смотрит дифф и относит изменение к minor / moderate / major.
4. Правка и evals. LLM сам вносит правку в скилл и запускает evals.
5. Гейт по классу. Minor и evals прошли — автоматический релиз без человека. Major, то есть новая тема, — человеческий гейт и новый eval.

Позиция Гретцингера про роль человека в этом конвейере: «If your engineers are reviewing text diffs on a skill, you are wasting a lot of time.» При этом он же оговаривает ограничение: новая тема означает обязательно новый eval, и хотя написать eval может LLM, что считается успехом, определяет человек.

Сколько стоит качество: цифры Skills Clinic

Tessl Skills Clinic даёт редкие измеренные значения — правда, измеряется в них соответствие best practices, а не эффективность.

Скилл	До	После автофикса
Qodo PR Resolver (Nnenna Ndukwe, Qodo)	78%	89%
Oracle DB skill (Anders Swanson, Oracle)	95%	100%

Практический порог, который называют в клинике, — не ниже 80%; при этом многие приходят со скиллами на 20–30%. Оговорка оттуда же: это соответствие рекомендациям Anthropic, а не доказанная польза, у организации могут быть свои правила, и просадка скора не всегда означает ухудшение скилла.

Реестр вместо «дёргаем прямо из GitHub»

Загрузка скиллов напрямую из репозиториев — путь наименьшего сопротивления. Мосс перечисляет, что взамен даёт реестр: один источник правды и пиннинг версий; безопасное обновление (узнать про апдейт, посмотреть дифф, откатиться); discoverability, которая закрывает overlap. На GitHub уже идёт взрыв форков: два скилла с одинаковым именем выглядят одинаково и ведут себя по-разному.

Есть и неожиданная статья расходов. Компании, раскатывающие скиллы на нетехнических сотрудников, вынуждены покупать этим людям GitHub seat только ради доступа к приватному репозиторию со скиллами — при том что ни одной функцией GitHub они не пользуются («however many dollars a month», конкретную сумму Мосс не называет). Реестр перед репозиторием эту статью снимает.

Сама раздача скиллов нетехническим сотрудникам остаётся нерешённой. Ожидать, что не-инженеры будут собирать скиллы CLI-командами в терминале, нереалистично; гонять зипы по почте — тоже не вариант. Вероятный ответ — GUI, но твёрдого решения нет: «This is a huge problem right now... I don't think there's a good answer.» Cisco закрыла свою половину проблемы обходным путём — менеджерам отдали README, синхронизированный в Confluence.

Это тот же SDLC, который отрасль уже прошла

Мосс сводит всё в отображение, которое стоит держать перед глазами при любом решении про скиллы:

Практика для кода	Аналог для контекста
Линтинг и юнит-тесты	Skill review
E2E-тесты	Evals
Реестр пакетов	Реестр скиллов
Композиция, отказ от глобального состояния	Те же рефлексы авторинга
Bus factor, силосы знаний	Ровно те же человеческие риски

Context development lifecycle — это тот же SDLC, который индустрия уже прошла за десять лет. Разница только в том, что в 2005-м никто не знал, чем всё кончится, а сейчас знает.

Есть и приятный побочный эффект зрелого контекста, который отмечает Cisco. Все harness и модели тренируются уважать скиллы, поэтому один и тот же скилл ведёт себя схоже в Claude Code, Copilot CLI и других. Это позволило Cisco перевести baseline на модель среднего уровня (Sonnet, GPT medium reasoning) и уходить в топовые только для сложного планирования. Триггером для экономии стал fan-out: один промпт разворачивался в 15 сабагентов, стоимость превратилась в проблему, и организации пришлось ограничивать использование моделей. Хороший контекст оказался дешевле умной модели.

Коротко

• Личный скилл пишется за одну сессию; сложность начинается там, где его надо обобщить для других (Krzysztof Huszcza, Snyk).
• Локальные скиллы запрещаются в первую очередь: они ломают воспроизводимость и не оставляют следа ни в диффе, ни в ревью, ни в CI.
• Скиллы живут в репозитории команды и трактуются как общая библиотека: PR открывает кто угодно, доказательство «не сломал» — evals (Cisco).
• Semver — сигнал доверия: 0.0.x «пользуюсь сам», 0.x «обкатано узко», 1.0 «сработает с первого раза»; невыполненное обещание 1.0 стоит доверия к автору.
• Документация для человека синхронизируется детерминированным скриптом, а не LLM, чтобы агент и менеджер читали один источник.
• Пайплайн «отобранная статья → скилл → классификация диффа → evals → автоматический релиз для minor» снимает с инженеров ревью текстовых диффов; человек остаётся определять, что считается успехом.

Цепочка поставок и вредоносные скиллы

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

Что нашли

Со сцены: 76 вредоносных скиллов

• Кто и где: Кшиштоф Хушча (Krzysztof Huszcza, Chris), product leader AI security, Snyk — бонусный эпизод подкаста AI Native Dev «76 Malicious AI Skills Were Hiding in Plain Sight», в разговоре с Саймоном Мейплом (Tessl)
• Что показали: на волне взрывного роста OpenClaw сообщество массово заливало скиллы в каталог ClawHub. Snyk проанализировал этот корпус целиком — примерно в марте — и разделил находки на два класса: скиллы с чисто вредоносным кодом и скиллы с prompt injection в текстовой части.
• Цифры: около 76 скиллов с малварью (спикер оговаривается: «I don't remember the exact number»); отдельно на DevCon звучала оценка, что до 20% всех скиллов на OpenClaw — вредоносные.
• Что это меняет: атаки на кодинг-агентов перестали быть теоретическим упражнением. Это supply chain в чистом виде, просто в новой упаковке — и с двумя векторами вместо одного.

Формулировка Хушчи про первый класс находок: «We found... 76 skills that had purely malicious code. So, malware.»

Вектор первый: в скилле бывает не только markdown

Скилл — это MD-файл с инструкцией и, часто, код рядом. Ставя чужой скилл, ты кладёшь себе на машину исполняемый код, который агент возьмёт и выполнит. Ничего экзотического здесь нет — это классическая атака на цепочку поставок, знакомая по npm и PyPI.

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

Вектор второй: prompt injection в естественном языке

Вторая половина находок Snyk — инъекции в текстовой части скилла. Здесь традиционные сканеры бесполезны уже не частично, а полностью: вредоносная нагрузка написана человеческим языком и не является кодом ни в каком смысле. Сканировать нечего.

Механика, которую описывает Хушча: «Agents are not very good at distinguishing between your instruction and context that is passed through third parties.» Агент плохо отличает инструкцию пользователя от контента, пришедшего от третьих лиц. Захваченный агент дальше выкачивает креденшлы из окружения, в котором он запущен, — а запущен он обычно там, где эти креденшлы есть.

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

Сканировать нужно в реестре, а не после скачивания

Это главная архитектурная позиция эпизода, и она короткая: скан должен стоять на стороне реестра, до того как артефакт оказался на машине. Скачал и потом просканировал — «might actually be game over».

Логика прямая. Если скилл уже лежит на диске, а агент в этой сессии уже читал файлы проекта, вопрос «а не выполнил ли он что-нибудь по дороге» становится вопросом расследования, а не проверки. Гейт, стоящий после установки, защищает от повторного использования, но не от первого.

Отсюда же следует, что реестр — это не удобство раздачи, а точка контроля. Джеймс Мосс (Tessl) перечисляет, какие политики на реестр естественно ложатся:

• only approved skills — все свои first-party плюс узкий белый список сторонних;
• обязательный порог security-скана (у Tessl — через партнёрство со Snyk);
• minimum release age — запрет ставить пакеты моложе N дней.

Сканы привязываются к версиям

Отдельный класс риска, который проговаривают Мейпл и Хушча: разработчик поставил безопасный скилл, а потом подтянул апдейт. Если версионирования нет, при обновлении ты тащишь неизвестно что — и проверка, сделанная неделю назад, относится к другому артефакту.

Поэтому в реестр добавили версионирование скиллов, а скан Snyk привязывается к конкретной версии. Это делает semver из раздела 2 не только сигналом доверия, но и единицей аудита: у версии есть результат скана, у «последнего main» — нет.

Почему minimum release age — не бюрократия

Со сцены: npm-инцидент, который прошёл мимо

• Кто и где: Джеймс Мосс, Tessl — «Using skills to pay the bills», AI Native DevCon 2026
• Что показали: за три-четыре недели до доклада произошёл инцидент в цепочке поставок npm, который в кулуарах называли «mini Shai-Hulud». Он затронул зависимости самой Tessl. Отличительная черта той малвари — персистентность: она прописывала на машину глобальный хук Claude Code, чтобы переустанавливаться после чистки.
• Цифры: в пакетном менеджере Tessl стоял minimum release age «несколько дней»; за это время инцидент нашли и почистили.
• Что это меняет: Tessl не пострадали, не сделав ничего специального. Политика «не ставим ничего моложе N дней» — самая дешёвая защита из существующих: она не требует ни анализа, ни экспертизы, ни доверия к сканеру.

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

Внутренний реестр: вектор другой, ущерб тот же

Легко решить, что вся эта история — про публичные каталоги и незнакомых авторов. Хушча приводит внутренний случай самого Snyk, который эту иллюзию снимает.

Разработчик написал скилл, который раздавал агентам доступ к продовым креденшлам — мимо согласованного пути (paved path), без just-in-time инъекции секретов, с избыточными правами. Скилл работал, был удобен, им пользовались. «When our security team saw that developers are using a skill like that, they freaked out.»

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

Смежное архитектурное соображение звучало в эпизоде «Inside Anthropic» от инженера applied AI team: в их системе агент получает собственные ключи и права, а не работает под правами вызвавшего его человека, и права скоупятся по каналам — у каждого канала свой набор инструментов, ключей и доступов. Помимо прочего это делает аудит осмысленным: в логе видно «это сделал агент», а не «это сделал ты». Приложенное к скиллам, это ставит вопрос, который стоит задать про каждый свой скилл: под чьими правами исполняется то, что скилл велит агенту сделать?

Сканер как обратная связь, а не только как гейт

Интереснее всего у Хушчи не гейт, а петля. Его личная практика: pre-commit hook со сканером перед пушем собственного скилла в GitHub. Скилл выкачивал данные из Slack — сканер предупредил, что в этих данных возможен prompt injection. Автор не стал спорить с гейтом: он попросил агента добавить базовые защиты прямо в скилл.

Петля «сканер → фидбек → агент правит скилл» полезнее блокировки, потому что блокировка сообщает «нельзя», а фидбек сообщает «вот что именно ты сделал». Хушча честно отмечает ограничение: проверки для «моего скилла» и для «скачанного скилла» — это разные наборы, и вторые уже сделаны, а первые ещё нет.

Куда эти проверки движутся, он тоже называет:

• не создаёт ли скилл конфигурацию lethal trifecta — агент может быть заинжекчен и при этом имеет канал эксфильтрации;
• не заставляет ли скилл передавать секреты в plaintext;
• не может ли он выполнить деструктивное действие в проде.

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

Что вокруг этого строится

Хушча описывает три продуктовых направления (продукт Evo), и они хорошо очерчивают периметр задачи:

1. Governance цепочки поставок — видеть, какие скиллы и MCP-серверы реально используют разработчики на всех машинах, оценивать риск и накладывать политики. Пример политики: MCP-сервер не должен ходить под personal access token.
2. Безопасность того, что агент генерирует — код и подтягиваемые им зависимости.
3. Guardrailing поведения агента в рантайме — утечки креденшлов, prompt injection на лету. На момент записи это направление выходило в open preview, GA планировалось позже; по словам Хушчи, для security-команд оно самое горячее.

Ещё одно наблюдение оттуда же, снимающее иллюзию выбора: разница между агентами с точки зрения безопасности минимальна. Codex, Claude Code, Cursor по вектору риска почти одинаковы, главное различие — поддерживает ли агент хуки. Практический вывод: инструменты защиты должны быть кроссагентными, а скиллы — project-level, то есть поставленными один раз в проект, с агентскими директориями, ссылающимися на общую папку.

Что это значит для команды

Свести всё можно к одному правилу: скилл надо ревьюить как зависимость, а не как документ.

Из него следует набор рабочих требований:

Вопрос	Как проверяется
Откуда взялся скилл	Реестр с политикой approved skills, а не ссылка из чата
Проверен ли он	Скан на стороне реестра, привязанный к конкретной версии
Что изменилось при обновлении	Пиннинг версий и дифф перед апдейтом
Что он исполняет	Ревью кода и скриптов рядом со SKILL.md
Что он читает и куда отправляет	Проверка на lethal trifecta и обращение с секретами
Под какими правами	Явные права агента, just-in-time секреты, никаких прод-креденшлов в скилле
Как быстро мы ставим новое	Minimum release age в несколько дней

Итоговая рекомендация Хушчи звучит скучно ровно настолько, насколько скучно звучат все работающие рекомендации по безопасности: не включать auto-approve на всё подряд, не ставить скиллы просто потому что, использовать sandbox, брать скиллы из доверенных реестров и проверять их. Его же формулировка про главное: «Don't outsource thinking to your agent. Just think for yourself what you're doing.»

И честная оговорка, без которой совет был бы неполным: полноценно засандбоксить агента сегодня всё ещё непросто — инструментов не хватает. Это не значит, что sandbox не нужен; это значит, что на него одного полагаться нельзя.

Коротко

• Snyk нашёл в публичном каталоге около 76 скиллов с малварью, а оценка доли вредоносных на OpenClaw доходила до 20%; спикер сам оговаривается, что точное число помнит приблизительно.
• Векторов два: исполняемый код внутри скилла (традиционные сканеры ловят его плохо, потому что код может лишь влиять на генерацию) и prompt injection в тексте (сканеры не видят его в принципе — нужен отдельный классификатор).
• Сканировать надо в реестре, до попадания артефакта на машину: «download and scan after — might actually be game over», и сканы должны быть привязаны к версиям.
• Minimum release age в несколько дней спас Tessl во время npm-инцидента с персистентным глобальным хуком — самая дешёвая из работающих защит.
• Внутренний реестр опаснее иначе: не злоумышленник, а свой разработчик, раздавший агентам прод-креденшлы мимо paved path.
• Практический вывод один: скилл — это зависимость, и ревьюить его надо как зависимость, включая вопрос о том, под чьими правами исполняется написанное в нём.

Как писать и проверять

Спор, который стоит увидеть целиком

В материале есть прямое разногласие, и оно касается самого базового вопроса: пишет скилл человек или модель.

Позиция Cisco. Джон Гретцингер («Skills Everywhere», AI Native DevCon London 2026) формулирует резче всех: «The skill is not for you. The skill's for your agent.» Скилл написан не для человека, поэтому содержимое скилла тебя волновать не должно — волновать должен результат его применения. Человеческое время — самый дорогой ресурс в системе — тратится на края процесса: на входе вкус и отбор материала, на выходе eval. Середину, то есть сам текст скилла, генерирует LLM. Он доводит мысль до логического конца: если workflow будет исполнять маленькая модель, пусть маленькая модель сама и напишет себе скилл в удобной ей форме. И отдельно, про ревью: «If your engineers are reviewing text diffs on a skill, you are wasting a lot of time.»

Позиция с другой стороны. Саймон Мейпл (Tessl) в Skills Clinic ссылается на исследовательскую работу: контекст, сгенерированный агентом в креативном режиме, прирост даёт, но валидированные и доработанные человеком скиллы дают заметно больший — по памяти спикера, средний прирост около 14% для human-written, у чисто агентных ниже, а иногда наблюдался и регресс. Мейпл сам не уверен в точности: «I think the paper said». Цифру перед тем, как на неё опираться, нужно проверять по первоисточнику — здесь она приводится ровно с той степенью уверенности, с какой прозвучала.

Косвенных подтверждений второй позиции в материале несколько. Джеймс Мосс (Tessl) на демо получил для скилла скор LLM-as-judge 20% с вердиктом «inherently dangerous financial operations» — то есть плохой скилл вполне может выглядеть как нормальный текст. Cisco же на собственном опыте столкнулась с тем, что агенты строят memories, дрейфующие от исходных статей, после чего ответы начинают противоречить источнику, — это ровно история про сгенерированный без надзора контекст.

Как читать этот спор. Он не сводится к «кто прав», потому что спорщики говорят о разных участках процесса.

	Cisco (Groetzinger)	Skills Clinic (Maple, со ссылкой на статью)
Кто пишет текст	LLM	Человек дорабатывает и валидирует
Куда идёт человеческое время	Отбор входа и eval выхода	В том числе в сам текст
Что считается доказательством	Прошедший eval	Измеренный прирост
При каком условии позиция верна	Evals есть и они настоящие	Evals может не быть

Гретцингер сам ставит условие, которое обычно теряется при пересказе его тезиса: это работает только при наличии evals. Без них генерация скиллов моделью — это производство мусора без обратной связи, и тогда правы те, кто говорит про регресс. Мейпл, в свою очередь, меряет прирост в мире, где систематических evals у команд пока нет, — и в этом мире человеческая валидация действительно единственный доступный фильтр качества.

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

Тот же вывод приходит с третьей стороны. Инженер applied AI team Anthropic («Inside Anthropic») описывает смещение работы разработчика к формулированию критериев успеха: если можешь чётко описать, что такое «сделано хорошо», дальше отдаёшь модели, и она крутится с ревьюером до готовности.

Как тестировать скилл

Проверок ровно три уровня, и их полезно не смешивать.

Уровень 1: автоматическое ревью — линтер плюс LLM-as-judge. По Моссу, ревью быстрое: гоняется локально после правок для короткой петли обратной связи и в CI как гейт против регрессий. Проверяет валидность скилла, длину в строках, корректность front matter, поверх — LLM-as-judge со скором. Скилл с 20% просто не публикуется.

Ограничение, которое честно проговорили в Skills Clinic: LLM-as-judge шумит. Тот же скилл без единого изменения при повторных прогонах может дать 80% вместо 89%. Скор — это индикатор, а не метрика, и строить на нём точные пороги наивно.

Уровень 2: evals как юнит-тесты агента. У Cisco механика такая: вместо импорта — эндпоинт. Eval-код бьёт в эндпоинт агента, получает ответ, потом идёт в observability (LangSmith и аналоги) и проверяет — те ли инструменты вызваны, с теми ли параметрами, уложились ли в ожидаемое количество токенов, какая была латентность против прошлого baseline. Один и тот же код работает на ноутбуке, в dev и в staging. Условие работоспособности: нужен baseline по токенам и латентности, иначе сравнивать не с чем.

Уровень 3: сценарные evals — со скиллом и без скилла. Мейпл разделяет два принципиально разных числа: review score (соответствие best practices) и impact score (реальный эффект). Impact меряется прогоном одних и тех же задач с скиллом и без него и сравнением по критериям. Показательная деталь: оба гостя клиники — Qodo и Oracle, то есть команды с публичными зрелыми скиллами — на записи этого ещё не делали и договорились прогнать «оффлайн». Даже у продвинутых команд evals скиллов пока не в рутине.

Есть и прокси-метрика уровнем выше отдельного скилла. Патрик Дебуа (Tessl) предлагает мерить не «сколько кода написал разработчик», а сколько ходов агенту нужно, чтобы выполнить работу. Число снижается тремя способами — сменой модели, правильными инструментами и лучшим контекстом, — то есть при фиксированных модели и инструментах метрика прямо измеряет качество скиллов.

Одна мелочь про формат датасетов хорошо показывает требуемый уровень дисциплины. Cisco перевела eval-датасеты с JSON на JSONL: обычный JSON — одна длинная строка, и агент, читающий файл с 1000 примеров, взрывает себе контекст, а построчный формат позволяет править точечно. Датасеты никто не курирует руками — их редактирует кодинг-агент, значит формат должен быть агенто-дружелюбным.

Типовые ошибки

Разбор реального скилла в Skills Clinic (Ненна Ндукве, Qodo, скилл PR Resolver) дал набор замечаний, которые повторяются почти у всех.

• Битые ссылки. 20 нерабочих относительных ссылок в одном скилле. Прогрессивное раскрытие через дерево файлов работает только пока ссылки живые.
• Повторы. Вердикт ревью: «strong actionability, needs less repetition». Люди по инерции повторяют одно и то же, считая, что агенту надо сказать трижды. Современным моделям — не надо. Автофикс сжал дублирующиеся секции.
• Описание без триггерных фраз. Описание может быть содержательно сильным и при этом не содержать слов, которыми задачу называет человек.
• Нет самопроверки. Самое ценное, что добавил автофикс, — секция validate-after-apply: после того как агент внёс правки в код, запустить линтер, type check и тесты, если они есть. Верификация — часть скилла, а не то, что помнит человек.

Последний пункт хорошо рифмуется с советом Патрика Дебуа: если ты проверяешь результат агента вручную — дай агенту инструмент для этой проверки. И с наблюдением Таммуза Дубнова (Autonomy AI) про тесты: недостаточно «покрыть тестом», сообщение об ошибке, ассерт и комментарий должны нести контекст для следующего агента. «assert true failed» бесполезен для агента ровно так же, как для человека.

От одного скилла к набору

Мосс формулирует три правила авторинга, и все три — прямые заимствования из практики работы с кодом.

1. Не писать монолитов. Разбивать на мелкие скиллы и собирать в плагины. У каждого куска своё описание — это повышает вероятность точечной активации нужного, а не «большого скилла обо всём».
2. Не редактировать чужой скилл у себя в репозитории. «Ваши коллеги вас не полюбят»: при обновлении апстрима правки либо потеряются, либо конфликтуют. Правильный ход — написать свой first-party скилл, который вызывает чужой и переопределяет нужное.
3. SRP из SOLID применим буквально. Один скилл — одна ответственность.

Как это выглядит в жизни, показывает внутренний UI-кейс Tessl: верхний скилл разбирает Figma-дизайн на компоненты и передаёт работу вниз — отдельный скилл на кнопки, отдельный на формы и композицию инпутов, отдельный на страницы. Побочная выгода чисто человеческая: если нужен один маленький виджет, человек вызывает нижний скилл напрямую, минуя цепочку.

Отдельный сценарий эволюции — скилл как агрегатор экспертизы. Андерс Свонсон (Oracle) описывает свой скилл по базам данных как результат вкладов множества SME: инженеры, продакт-менеджеры, каждый в своём узком домене, ни один человек не знает всего. «This is information that has been accumulated over probably cumulative hundreds of years of database experience... your agent can be that one person.» Скилл здесь — не записка одного человека, а место сборки знания, которого целиком нет ни у кого.

Про обслуживание накопленного набора есть ранняя, но показательная практика — механизм dreaming в research preview Managed Agents (Anthropic). Отдельный агент получает memory stores и транскрипты сессий и ищет расхождения: чего не хватало, что вводит в заблуждение и деградирует качество, что стоит переорганизовать для поиска. На выходе — гипотезы с привязкой к конкретным сессиям как доказательствам; запускается по расписанию, решение остаётся за человеком. Вывод для корпуса скиллов прямой: контекст стареет, и обслуживать его тоже должен агент.

Когда скилл не нужен

Это самая недооценённая часть дисциплины, и материала по ней достаточно.

• Когда модель поумнела. В Anthropic с каждой новой моделью пересматривают harness и спокойно удаляют из него куски: поведение, которое раньше приходилось прошивать снаружи — например, самопроверку результата, — переезжает внутрь модели. «Sometimes it means less is more.» Прикладной вывод для скиллов: часть твоих скиллов после апгрейда модели превращается в лишнее раздувание контекста, и это надо регулярно перепроверять теми же evals.
• Когда ты слишком «мнение». Там же: пробовали индексированные memory stores и специализированные инструменты чтения-записи памяти — отказались в пользу простой файловой системы и нативных bash и grep. Вывод команды: были слишком мнением о том, как агент должен работать с памятью, а он справляется лучше, если оставить его в покое.
• Когда нужна платформа, а не скилл. Дэниел Джонс (re:cinq) на панели DevCon называет прямой антипаттерн: люди используют скиллы, чтобы разобраться, как выкатить в прод. Платформы для этого существуют десять лет, они детерминированные и предсказуемые. «Maybe use agents to build your platform, but don't replace your platform with agents burning tokens reinventing the wheel.»
• Когда сломан процесс. Он же, со ссылкой на DORA: бутылочные горлышки при внедрении агентов оказываются обычными дефектами разработки — плохой CI/CD, отсутствие тестов, несогласованные стандарты кода. У незрелых в инженерных практиках команд agentic coding работу замедляет, у зрелых — ускоряет; где точка перелома, неизвестно. «The bottlenecks that become apparent are often deficiencies in just doing software development well.» Скиллом это не лечится.
• Когда нужно состояние, а не знание. Возврат к границе из раздела 1 (Roxanne Fischer, AnyShift): текущее состояние системы скилл не кодирует, за ним нужен живой источник.
• Когда быстрее сделать самому. Томас Домке (ex-CEO GitHub) в разговоре с Гаем Поджарни называет ключевым остающимся человеческим навыком решение, что отдать агенту: менять цвет фона в CSS через агента — идиотизм, если знаешь, где строка.

Дисциплина: не плодить сущности

Три практики, которые удерживают набор скиллов от превращения в свалку.

• Спрашивать «есть скилл?» до того, как писать новый. Cisco делает это культурной нормой: «I don't want 15 engineers creating 15 skills for the same thing.» Дешевле найти чужой и дополнить.
• Не тащить в скиллы вирусные цифры. Мосс собрал коллекцию постов из Reddit и LinkedIn как антипример: «скилл режет расход токенов на 60–80%», «4 правила в CLAUDE.md подняли coding accuracy с 65% до 94%», «магический промпт убивает 90% продовых багов до их появления». Ни одно утверждение не подкреплено методикой. Его цитата на этот счёт — от Адама Сэвиджа: «The difference between screwing around and science is writing it down.»
• Разбивать проверку на детерминированные линзы. Дэниел Джонс (инструмент Assembly Line) и Таммуз Дубнов (тот же приём под именем «nudging») описывают одно и то же: вместо того чтобы напихать всё в agents.md и надеяться, что агент учтёт все аспекты за один проход, после изменения запускается серия отдельных агентов с узкими детерминированными промптами — проверь мёртвый код, проверь непокрытые тестами места, — и фидбек быстро возвращается основному агенту, пока он не ушёл далеко.

Коротко

• Спор «писать руками или генерировать» разрешается не выбором стороны: Cisco права при наличии настоящих evals, критики генерации правы там, где evals нет.
• Проверок три уровня: автоматическое ревью (линтер + LLM-as-judge, шумит), evals через эндпоинт агента с проверкой инструментов, токенов и латентности против baseline, и сценарные evals со скиллом против без скилла.
• Порог качества в практике — не ниже 80%, но review score и impact score — разные числа, и второе почти никто ещё не мерит.
• Типовые ошибки: битые ссылки, повторы «чтобы агент точно понял», описание без триггерных фраз, отсутствие секции самопроверки после применения.
• Набор растёт декомпозицией, а не разрастанием одного файла: мелкие скиллы, SRP, свой скилл поверх чужого вместо правки чужого.
• Скилл не нужен, когда модель уже умеет сама, когда нужна платформа, когда сломан процесс, когда нужно состояние системы и когда быстрее сделать руками.

Чек-лист зрелости

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

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

Три уровня

• Уровень 1 — личный хак. Скилл живёт в домашней директории. Работает у автора. Никто, включая автора, не может доказать, что скилл помогает. Это нормальная стартовая точка и ненормальное место для остановки: по Джеймсу Моссу (Tessl), именно здесь ломается воспроизводимость — два человека запускают одну задачу на одном коде и получают разный результат, а отладить расхождение невозможно, потому что скилла нет ни в диффе, ни в ревью, ни в CI.
• Уровень 2 — командный актив. Скилл лежит в репозитории, у него есть владелец, версия и ревью. Правило Cisco: обращаться со скиллами как с общей библиотекой — не сломай остальным, докажи evals.
• Уровень 3 — управляемая цепочка поставок. Скиллы ставятся из реестра с пиннингом версий, сканируются до попадания на машину, обновляются по политике, а часть релизного цикла идёт без человека, потому что за качество отвечают evals.

Чек-лист

Уровень 1 → 2: из личного хака в командный актив

• Ни один скилл, влияющий на рабочий вывод, не лежит вне репозитория
• У каждого скилла есть явный владелец — человек или команда, а не «исторически»
• Есть SKILL.md для агента и README.md для человека
• Проставлена версия по semver: 0.0.x — сам, 0.x — узкая группа, 1.0 — обещание
• SKILL.md не длиннее ~500 строк; длинное вынесено в дерево справочных файлов
• Описание содержит естественные триггерные фразы, которыми задачу называет человек
• Все относительные ссылки внутри скилла живые (типовая находка ревью — 20 битых)
• В скилле есть шаг самопроверки: после применения запустить линтер, типы, тесты
• Определён bare minimum: что скилл обязан делать хорошо всегда
• Известно, сколько скиллов установлено суммарно (риск overloading — молчаливого обрезания описаний, при котором скилл перестаёт активироваться без признаков)

Уровень 2 → 3: из командного актива в управляемую цепочку поставок

• Скиллы ставятся из реестра, а не дёргаются напрямую из GitHub
• Версии запиннены; перед обновлением смотрится дифф, есть путь отката
• Скан безопасности стоит на стороне реестра, до скачивания, и привязан к версии
• Действует политика approved skills: все свои + узкий белый список сторонних
• Действует minimum release age (несколько дней) для сторонних пакетов и скиллов
• Ни один скилл не раздаёт агенту прод-креденшлы в обход paved path
• Известно, под чьими правами исполняется то, что скилл велит агенту сделать
• Проверяется lethal trifecta: возможность инъекции плюс канал эксфильтрации
• Нет глобального состояния — хуков и скиллов, установленных на машину целиком
• Есть инвентаризация: какие скиллы где лежат, first-party против third-party, сколько токенов потребляют, какие дубли и какие устарели

Сквозное: измерение (без него оба перехода — вопрос веры)

• Автоматическое ревью гоняется локально после правок и в CI как гейт
• Практический порог качества зафиксирован (в клинике называют не ниже 80%)
• Есть evals: те ли инструменты вызваны, с теми ли параметрами, сколько токенов, какая латентность против baseline
• Есть baseline по токенам и латентности, иначе сравнивать не с чем
• Хотя бы один скилл прогнан сценарно: с ним и без него, на одних задачах
• Eval-датасеты в JSONL, а не в JSON (агент правит их построчно, не взрывая контекст)
• Известно, что считается успехом, — и это определил человек, а не LLM
• Есть регулярная ревизия: какие скиллы стали лишними после апгрейда модели

Что проверить у себя сегодня

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

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

Второе: найти локальные скиллы. Всё, что лежит в домашней директории и влияет на вывод агента, — кандидат либо в репозиторий, либо на удаление. Позиция Бориса Черни, создателя Claude Code, приведённая Моссом: любые улучшения агентного workflow — хуки, скиллы и прочее — должны быть закоммичены в репозиторий для всех.

Третье: взять один скилл и прогнать задачу с ним и без него. Это единственная проверка, которая отвечает на вопрос «а он вообще помогает». Показательно, что в Skills Clinic обе гостевые команды — Qodo и Oracle, с публичными зрелыми скиллами — этого на момент записи ещё не делали.

Куда двигаться дальше

Открытых мест в дисциплине много, и это стоит держать в голове, планируя работу.

• Зависимости между скиллами. Как выразить зависимость скилла от скилла из другого пакета — открытый вопрос, за который, по словам Мосса, «все боятся браться». Возможный ответ — peer dependencies, но не исключено, что они артефакт детерминированного мира: агент может просто прочитать скилл и понять, что ему нужен ещё один.
• Раздача скиллов нетехническим сотрудникам. Твёрдого решения нет ни у кого. Ожидать, что не-инженеры будут ставить скиллы CLI-командами, нереалистично; зипы по почте — тоже не вариант. Cisco закрыла свою половину проблемы обходным путём: менеджерам отдали README, детерминированно синхронизированный в Confluence.
• Проверки для собственных скиллов. У Snyk сделаны проверки для скачанных скиллов; проверки для «моего скилла» — направление в работе. Полноценно засандбоксить агента сегодня всё ещё непросто, и это признаётся прямо.
• Владение. Кто в организации отвечает за скиллы, отрасль ещё не решила. Панель DevCon ставит на DevEx/платформенную команду, но отмечает вакуум: нынешние платформенные команды заточены на инфраструктуру и не AI-savvy, при этом контролируют бюджет, модели и гейтвеи.

Последнее

Всё, что здесь описано, собрано из докладов и эпизодов одного сезона. Часть цифр — self-reported и независимо не проверена: «×72 быстрее» у команды клиента re:cinq, 65% PR у Anthropic, прирост около 14% у human-written скиллов, который сам спикер приводит по памяти со словами «I think the paper said». Их стоит воспринимать как направление, а не как ориентир для планирования.

Дисциплина новая, и половина практик изменится. Скорее всего, изменится в сторону упрощения: инженер Anthropic описывает, как с каждой новой моделью harness становится не больше, а меньше — поведение, которое раньше приходилось прошивать снаружи, переезжает внутрь модели. Ровно это ждёт и часть скиллов: сегодняшний полезный скилл через два релиза модели превратится в лишние токены, и узнаешь ты об этом только если у тебя есть чем измерить.

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