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

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

Дальше начинается всё остальное. Его же формулировка: «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.»
• Отсутствие активации. Непонятно, вызываются ли скиллы вообще — ни людьми, ни агентами. Скилл может быть написан, установлен и ни разу не сработать.
• Overloading. Описания переполнили лимит, часть скиллов молча выпала (механика — в предыдущей статье серии).

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

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

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

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

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- или платформенной команде: строить, раздавать и обеспечивать качество скиллов логично ложится на тех, чья работа — снижать когнитивную нагрузку разработчиков. Проблема в том, что нынешние платформенные команды заточены на инфраструктуру и слабо разбираются в ИИ, — образуется вакуум. При этом именно они контролируют бюджет, модели и гейтвеи, так что мимо них всё равно не пройти. Панель отмечает и то, что платформенных отделов может быть несколько — cloud, AI, data platform, — и тогда вопрос владения усложняется ещё на уровень.

Исторический паттерн, на который ссылаются участники: сначала маленькая команда-инкубатор (как когда-то 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»

Загрузка скиллов напрямую из репозиториев — путь наименьшего сопротивления. Мосс перечисляет, что взамен даёт реестр: один источник правды и пиннинг версий; безопасное обновление (узнать про апдейт, посмотреть дифф, откатиться); находимость, которая закрывает 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-изменений снимает с инженеров ревью текстовых диффов. Человек остаётся определять, что считается успехом.