Как писать, проверять и чек-лист зрелости

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

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

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

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

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

Позиция с другой стороны. Саймон Мейпл (Tessl) в Skills Clinic ссылается на исследовательскую работу: контекст, сгенерированный агентом в креативном режиме, прирост даёт, но валидированные и доработанные человеком скиллы дают заметно больший — по памяти спикера, средний прирост около 14% для написанных человеком скиллов, у чисто агентных ниже, а иногда наблюдался и регресс. Мейпл сам не уверен в точности: «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. Не редактировать чужой скилл у себя в репозитории. «Ваши коллеги вас не полюбят»: при обновлении апстрима правки либо потеряются, либо конфликтуют. Правильный ход — написать собственный скилл, который вызывает чужой и переопределяет нужное.
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.» Скиллом это не лечится.
• Когда нужно состояние, а не знание. Возврат к границе, которую обозначила Роксана Фишер (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: возможность инъекции в сочетании с каналом эксфильтрации
• Нет глобального состояния — хуков и скиллов, установленных на машину целиком
• Есть инвентаризация: какие скиллы где лежат, какие собственные и какие сторонние, сколько токенов потребляют, какие дубли и какие устарели

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

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

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

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

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

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

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

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

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

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

Последнее

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

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

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