Skill в Claude Code — это пакет инструкций в папке с файлом SKILL.md: Claude подгружает его, когда описание подходит к вашему запросу, либо вы вызываете его командой по имени. Для команды это способ записать повторяемый процесс один раз, например проверку перед релизом или подготовку описания изменений, и получать одинаковый результат от любого сотрудника. Пакет окупается на задачах, которые выполняются регулярно по одним и тем же шагам, а для разового эксперимента хватит обычного запроса.
Из чего состоит skill
Skill — это папка с файлом SKILL.md, где в заголовке заданы имя и описание, а в тексте шаги процесса; описание решает, когда Claude подключит инструкцию, поэтому его пишут с учётом реальных формулировок запросов.
По документации Claude Code, обязательной частью служит файл SKILL.md: вверху находится заголовок с именем и описанием, ниже идут инструкции. Описание отвечает на два вопроса: что делает пакет и когда им пользоваться. После вызова текст пакета остаётся в контексте до конца разговора и дальше берётся оттуда, поэтому правила в нём пишут так, чтобы они действовали на протяжении всей работы. Правки файла применяются в той же сессии без перезапуска. Именно по описанию Claude решает, подгружать ли инструкцию, поэтому расплывчатая формулировка вроде «помощь с кодом» приводит к тому, что пакет срабатывает невпопад или молчит.
К основному файлу можно добавить справочные материалы и скрипты в той же папке, а в самом файле сослаться на них. Так основной текст остаётся коротким, а подробности подгружаются по необходимости. Общий обзор того, как команда осваивает инструмент, дан в статье обучение Claude Code, а работа команды целиком описана в материале Claude Code для команды; здесь разговор только о пакетах инструкций.
- Имя: короткое, под него вызывается пакет, если запускать вручную.
- Описание: что делает пакет и в каких случаях его подключать, словами, которые встречаются в ваших запросах.
- Инструкции: пронумерованные шаги, критерии готовности и список того, что запрещено делать.
- Дополнительные файлы: шаблоны, примеры, справочники, скрипты проверки.
- Настройки доступа: какие инструменты пакет может использовать без запроса разрешения.
Где хранится
Место хранения определяет, кто увидит пакет. Один и тот же файл, положенный в разные каталоги, работает для одного человека, для одного репозитория или для всей организации.
| Где лежит | Кто видит | Когда выбирать |
|---|---|---|
| Личный каталог на вашем компьютере | Вы во всех проектах | Личные привычки и эксперименты |
| Папка проекта в репозитории | Все, кто работает с этим репозиторием | Процессы команды: релиз, ревью, оформление |
| Управляемые настройки организации | Вся организация | Обязательные правила и политики |
| Внутри плагина | Те, у кого плагин включён | Набор пакетов для нескольких проектов |
Для команды разработки основной путь — папка проекта: пакет лежит рядом с кодом, попадает в историю изменений и проходит ревью, как любой другой файл. Когда пакетов становится много, их собирают в плагин; о нём подробно рассказывает статья Claude Code plugins, а здесь важно другое: пакет в репозитории доступен коллеге сразу после получения изменений, без отдельной установки.
Тест на задаче
Начните с малого: один процесс, один автор, один проверяющий. Большие наборы пакетов, созданные за один присест, обычно содержат заметную долю неработающих инструкций. Пакет, написанный за столом, почти всегда оказывается неточным. Проверяйте его на задаче, которая уже решалась вручную: тогда у вас есть эталон результата и понятно, что именно улучшилось или испортилось.
- Выберите задачу, которую команда выполняет регулярно и результат которой легко оценить.
- Запишите шаги так, как их делает опытный сотрудник, включая проверки и места, где требуется остановиться.
- Сформулируйте описание и проверьте, что пакет подключается на типичных запросах и молчит на посторонних.
- Запустите пакет на реальном примере и сравните результат с ручным решением.
- Отметьте расхождения и поправьте шаги пакета, а подгонять отдельный запрос к модели бессмысленно.
- Повторите на втором примере другого типа, чтобы убедиться, что пакет работает и за пределами первого примера.
Если пакет подключается слишком часто, сузьте описание или отключите автоматический вызов: по документации, для действий с побочными эффектами, например выкладки на сервер, предусмотрен запуск только вручную. Если подключается слишком редко, добавьте в описание слова из реальных запросов коллег. Первые правки обычно уходят на описание, и лишь потом на сами шаги.
Какую повторяемую задачу вашей команды стоит оформить пакетом?
Версия и доступ
Пакет получает доступ к вашим файлам и командам, поэтому его правят как код: через запрос на изменение, с ревью и записью о том, что поменялось и зачем.
Хорошая практика — приложить к пакету короткий файл с примерами запросов и ожидаемых результатов: он служит и документацией, и набором проверок при каждом изменении. Для версий достаточно обычной истории репозитория. К пакету, который лежит в проекте, применяют те же правила, что к скриптам сборки: изменение проходит ревью, а в описании запроса указано, на каких примерах оно проверено. Когда пакет выходит за пределы одного репозитория, например в виде плагина, добавляется номер версии и заметки об изменениях.
Границы доступа задаются двумя способами. Первый — список инструментов, которые пакет вправе использовать без запроса разрешения: давайте минимум, достаточный для процесса, а запись в рабочие системы открывайте только при настоящей необходимости. Второй — правила разрешений в настройках Claude Code: какие записи запрещают или разрешают отдельные пакеты, сверяйте по документации. Пакет можно вызвать и из рабочего процесса в репозитории: путь от упоминания в задаче до ветки описан в статье Claude Code GitHub.
Границы применения
Для сравнения представьте два случая. Первый: оформление описания изменений по одному шаблону для всех разработчиков. Второй: ответ на вопрос о текущем курсе или составе дежурных. Первый превосходно ложится в пакет, второй требует живого источника. Пакет инструкций хорош для процедур и плох для знаний, которые меняются каждый день. Шаги проверки перед релизом живут месяцами, а список актуальных цен или состав команды устаревает за неделю, и такие сведения лучше брать из источника в момент запроса.
- Подходит: процедуры с чёткими шагами, шаблоны документов, правила оформления, чек-листы проверки.
- Подходит условно: справочные материалы по проекту, если у них есть владелец, обновляющий их.
- Противопоказано: быстро меняющиеся данные, секреты и пароли, всё, что требует человеческого решения на каждом шаге.
- Требует осторожности: пакеты с доступом к рабочим системам и внешним сервисам.
Отдельное правило касается секретов: пароли, ключи доступа и токены в пакет попадать нельзя, их исключают, даже если репозиторий закрыт, потому что история изменений хранит всё. Каждый пакет увеличивает нагрузку на контекст: имя и описание подключённых пакетов присутствуют в разговоре постоянно, а полный текст подгружается при использовании. Поэтому лишние пакеты отключайте, а описания держите короткими. Раз в квартал просматривайте набор и убирайте то, что осталось без пользователей.
Если вам нужна помощь в том, чтобы превратить процессы команды в набор проверенных пакетов с правами и ревью, мы делаем это в рамках разработки ИИ-агентов. Первым пакетом возьмите один процесс с двумя проверочными примерами, а следующие добавляйте после оценки вместе с коллегами.