Скиллы для AI-агентов: что это и как их использовать

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

Ниже — как устроены скиллы, как ставить чужие и не подцепить лишнего, как за вечер собрать свой и почему задумки «сделать бота» или «найти сервис» закрываются одним markdown-файлом.

Скилл — это папка с файлом SKILL.md внутри. В файле две части: короткая шапка со служебными полями и тело, где описана процедура.

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

Минимальный рабочий скилл — одна папка и один файл. Всё остальное добавляется, когда понадобится.

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

Поэтому тридцать установленных скиллов не мешают друг другу и не съедают контекст. До момента вызова каждый из них весит одну строку.

Это главное отличие скиллов от всего остального, чем настраивают агента, и его чаще всего упускают.

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

Личные скиллы — ваши и только ваши. Командные попадают к коллегам вместе с проектом, обычным клонированием.

Практическое следствие простое. Настроили скилл для договоров, работая над сайтом, — через месяц открыли совершенно другую папку, сказали «сделай договор для нового клиента», и он делается. Скиллу всё равно, где вы находитесь.

Проектные инструкции при этом никуда не деваются: файл CLAUDE.md в корне репозитория по-прежнему описывает конкретный проект, его структуру и договорённости. Разделение получается чистое. В проекте — контекст проекта. В скиллах — ваши процедуры, которые от проекта не зависят.

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

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

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

Чаще всего скиллы применяют в терминальных агентах: Claude Code и Codex. Там агент сидит прямо в вашей файловой системе, а значит может открыть папку скилла, прочитать инструкцию, запустить приложенный скрипт и сохранить результат.

Формат при этом открытый и текстовый, и на этом держится вся переносимость. В Claude Code механизм родной: положили папку в ~/.claude/skills/, она подхватилась. Другие агенты читают тот же файл, где-то нативно, где-то по прямой ссылке.

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

Готовых скиллов на GitHub уже много: редактура текста, работа с документами, аудит кода, генерация презентаций, слои памяти для агента. Ставится любой из них тремя способами, от ленивого к аккуратному.

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

Установка, проверка и отчёт за один заход. Руками не делается ничего.

Если хотите понимать, что происходит, две команды в терминале дают тот же результат:

Плюс этого способа в том, что обновления апстрима подтягиваются одной командой.

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

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

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

• Кто автор. Известное имя в сообществе, компания, автор инструмента, под который написан скилл. Аккаунт, созданный месяц назад и с одним репозиторием, требует другого уровня внимания.
• Звёзды и форки. Грубый, но рабочий сигнал: сотни звёзд означают, что файл читали сотни глаз. Три звезды означают, что не читал никто.
• Активность. Дата последнего коммита, открытые issues, отвечает ли автор. Заброшенный полгода назад скилл под старую версию агента чинить придётся вам.
• Лицензия. MIT или Apache говорят о том, что автор понимает, что делает. Отсутствие лицензии — повод спросить себя, зачем вам это.

Дальше открываете SKILL.md и читаете целиком. Это текст на человеческом языке, час на него не нужен. Заодно смотрите, что лежит в папке рядом.

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

Последняя фраза ответа — именно то, ради чего эта проверка делается.

• Скачивание и немедленный запуск кода из сети одной командой
• Обращения к ключам, паролям и переменным окружения: .env, ~/.ssh, файлы с токенами
• Отправка чего-либо на сторонний адрес без внятного объяснения зачем
• Нечитаемый или запакованный код в скриптах рядом с инструкцией
• Просьбы к агенту не сообщать пользователю о своих действиях
• Широкие разрешения в шапке при узкой задаче скилла

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

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

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

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

Мой скилл для текстов вырос ровно так. За основу взят открытый Humanizer, дальше он оброс моими правилами и примерами и стал отдельным автором.

Начинается это одной фразой в чат: «сделай скилл, который делает то-то». Агент создаст папку, напишет файл и положит его куда надо. Дальше вы правите текст, как правили бы инструкцию для нового сотрудника.

Весь скилл — это шапка на пять строк и процедура словами. Ни строчки кода.

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

1. Описание. Строка description — единственное, что агент видит до вызова. Именно по ней он решает, подходит скилл к задаче или нет. Пишите туда ситуации применения человеческими словами, включая то, как вы формулируете просьбу в жизни. Расплывчатое описание означает, что скилл придётся звать руками каждый раз.
2. Разрешённые инструменты. Поле allowed-tools определяет, что скиллу позволено. Свод правил для текста обходится чтением и записью. Скиллу, который качает и конвертирует файлы, нужен терминал. Давайте ровно столько, сколько требует задача.
3. Правки идут в файл. Каждое замечание, которое вы делаете второй раз, дописывается в скилл прямо в тот же момент. Иначе завтра вы объясните то же самое заново. Самые ценные правила рождаются из бытовых мелочей, до которых за столом не додумаешься.

Теперь то, ради чего вся эта история имеет смысл за пределами работы с кодом.

Когда придумывается автоматизация или маленький продукт, первая мысль обычно одинаковая: надо сделать веб-приложение, или телеграм-бота, или сценарий в n8n. И почти всегда следом идёт оценка, из которой понятно, что за вечер это не собрать.

Между тем задача в один-два шага закрывается скиллом. Без интерфейса, без сервера, без деплоя. Одна папка и одна фраза в чате.

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

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

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

• Один огромный скилл на всё. Растёт, теряет фокус, срабатывает невпопад. Разбирается на части по первому же неудобству.
• Описание написано в последнюю очередь и кое-как. Самая частая причина, по которой скилл лежит мёртвым грузом: агент просто не понимает, когда его звать.
• Правила без примеров. Абзац с формулировкой «делай хорошо» даёт ровно тот результат, который вы ожидаете. Один показанный образец стоит десяти строк требований.
• Установка пачками. Двадцать скиллов из каталога за вечер дают шум в выборе и двадцать непрочитанных файлов на диске. Ставьте по одному, под конкретную повторяющуюся задачу.
• Правки остаются в чате. Поправили результат, порадовались, закрыли сессию. Завтра всё то же самое. Скилл становится полезным ровно в тот момент, когда замечания начинают уходить в файл.

• Скилл — это папка с файлом SKILL.md: шапка со служебными полями плюс процедура человеческими словами.
• До вызова скилл весит одну строку описания, поэтому десятки установленных скиллов не мешают друг другу.
• Скиллы живут поверх системы и работают в любом проекте. Проектные договорённости остаются в CLAUDE.md.
• MCP даёт агенту руки, скилл даёт процедуру. Вместе они и работают.
• Готовый скилл ставится одной ссылкой: киньте репозиторий агенту и попросите разобраться.
• Перед установкой проверяйте автора, активность и содержимое файла. Аудит удобно поручить агенту в отдельной сессии.
• Сложное берите готовым, простое пишите сами: свой скилл знает ваши папки, форматы и реквизиты.
• Задумали автоматизацию в один-два шага — пробуйте закрыть её скиллом до того, как идти делать бота или сервис.
• Лучше пять узких скиллов, чем один универсальный: узкие переиспользуются и вызывают друг друга.

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

А какую свою рутину вы бы закрыли скиллом первой? Пишите в комментариях — разберу интересные случаи.