Скилы (skills)

Модель знает «всё вообще»: как пишут код-ревью в среднем по индустрии, как обычно оформляют баг-репорты, как принято делать релизы. Но она не знает, как это делаете вы: что у вашей команды ревью начинается с проверки миграций, что баг-репорт без шагов воспроизведения возвращается автору, что релиз в пятницу запрещён регламентом. Скилы (skills) закрывают этот разрыв.

Что такое скил

Скил упаковывает инструкцию или процедуру, которую агент подгружает, когда задача её требует. По сути это документ «как у нас делается X», написанный для агента, а не для человека, и подключённый к харнесу (agent harness).

Распространённый формат: файл SKILL.md в отдельной папке. У него две части:

Описание-триггер. Короткая аннотация: что этот скил умеет и когда его применять. Например: «Регламент подготовки релиза. Используй, когда просят собрать релиз, подготовить changelog или выкатить версию».
Тело. Сама процедура: шаги, правила, шаблоны, примеры. Рядом со скилом могут лежать вспомогательные файлы: шаблоны документов, скрипты, примеры «как надо».

Работает это так: харнес показывает модели только описания всех доступных скилов: несколько строк на каждый. Когда приходит задача «подготовь релиз 2.4», модель по описанию понимает, что есть подходящий скил, и подгружает его целиком. Дальше она следует вашей процедуре, а не «средней по интернету».

Прогрессивная подгрузка: почему скилы дёшевы

Ключевое свойство скилов: они не занимают контекст, пока не нужны.

Контекстное окно (context window) остаётся дефицитным ресурсом: всё, что в него положено, конкурирует за внимание модели с самой задачей. Если бы все регламенты команды постоянно висели в контексте, десять подробных процедур съели бы заметную его часть, притом что в конкретной сессии обычно нужна одна из них или ни одной.

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

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

Примеры скилов для команды

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

«Наш процесс код-ревью». Что проверять в первую очередь, какие замечания блокирующие, в каком тоне писать комментарии, чек-лист для миграций и изменений API. Агент-ревьюер с таким скилом проверяет то, что важно вам, а не абстрактный «чистый код».
«Шаблон постановки задачи». Обязательные секции: контекст, критерии приёмки, ограничения. Агент, помогающий аналитику, выдаёт задачи сразу в формате команды.
«Регламент релиза». Последовательность шагов, правила версионирования, формат changelog, кого уведомить, что проверить перед выкаткой и в каком случае остановиться.
«Стиль баг-репорта». Структура: шаги воспроизведения, ожидаемое и фактическое поведение, окружение, серьёзность. Тестировщик получает от агента черновики отчётов, которые не стыдно отправлять как есть.

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

Скилы, системный промпт, память: что куда класть

У агента несколько мест для инструкций, и их легко перепутать. Ориентир такой:

Системный промпт задаёт харнес: это его зона ответственности, и трогать её обычно не нужно. Пользовательские правила уровня «всегда и везде» чаще всего живут не здесь, а в памяти.
Память (Память). То, что должно быть в голове агента в каждой сессии этого проекта: команды сборки и тестов, архитектурные соглашения, стиль кода, запреты. Короткие факты, нужные постоянно.
Скилы. Процедуры, нужные иногда: подробные пошаговые регламенты, которые применяются к определённому типу задач. Длинные инструкции, нужные по случаю.

Практическое правило: факт, нужный всегда, держите в памяти; процедуру, нужную иногда, выносите в скил. Если положить длинный регламент релиза в память, он будет занимать контекст в каждой сессии, включая те, где вы просто чините тест. Если, наоборот, спрятать в скил команду запуска тестов, агент не увидит её в обычной работе.

Скилы как командный актив

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

Это тот же сдвиг, что когда-то произошёл с инфраструктурой: от «настроено руками у сисадмина» к «описано кодом в репозитории». Знание «как у нас принято» перестаёт быть устным преданием и становится файлом, который можно улучшать.

Что дальше

Память: что агент должен знать в каждой сессии.
Контекст-инжиниринг: как управлять контекстом агента в целом.

Автор учебника: Шахматов Алексей