Anthropic наконец раскрыла, как она использует Claude Code Skills внутри компании. Команда провела полный разбор внутренних практик: на какие 9 категорий делятся Skills, какой категории стоит уделить больше внимания и как писать Skills, чтобы они действительно работали. Этот опыт ранее циркулировал только внутри Anthropic, теперь всё объяснено подробно.
Первое: правильно понять, что такое Skill
Anthropic сначала исправила распространённое заблуждение.
Skill — это не просто несколько фрагментов промптов, это скорее папка, организованная вокруг задачи.
В этой папке можно разместить SKILL.md, справочные документы, скрипты, шаблоны, примеры, hooks и даже данные, которые будут использованы в последующих задачах. Когда Claude вызывает Skill, он получает полный набор материалов, необходимых для выполнения задачи.
Это определение очень важно. Потому что многим командам не хватает "ещё одного фрагмента промпта", а нужно привести в порядок уже проверенные подходы, деликатные детали, обычные скрипты и стандартные процессы и потом их повторно использовать.
Второе: Anthropic распределила внутренние Skills по 9 категориям
Anthropic провела инвентаризацию внутренних Skills и разделила их примерно на 9 категорий. Вместе они напоминают полный цикл разработки ПО: от дополнения знаний до написания кода, тестирования, развёртывания, отладки и операций.
Распределение 9 категорий Skills в Anthropic
Первые три категории: дополнение знаний, валидация и данные для модели
Первая категория — library и API reference. Объясняют модели, как правильно использовать библиотеку, CLI или SDK внутри команды, указывают на распространённые ошибки.
Вторая категория — product verification. Проверяет, действительно ли работает результат, например, полный проход регистрации и оформления заказа в безголовом браузере. Anthropic прямо говорит, что эта категория наиболее заметно улучшает качество результатов, стоит потратить неделю инженера на её совершенствование.
Третья категория — data fetching and analysis. Связана с хранилищем данных и системами мониторинга. Здесь инкапсулированы методы получения данных, соглашения об именах полей и типичные пути анализа, так что модели не нужно угадывать структуру и названия.
Три средние категории: автоматизация процессов в команде
Четвёртая категория — business process and team automation. Повторяющиеся процессы команды превращаются в рабочие потоки, запускаемые одной командой, например, standup только с изменениями или еженедельный отчёт в стандартном формате. Видно, что Skill охватывает не только задачи кодирования, но и совместную работу.
Пятая категория — code scaffolding and templates. Генерирует код с фиксированной структурой, но содержащий множество ограничений на естественном языке, например, новый сервис или файлы миграции. Это то, что обычные генераторы шаблонов не могут охватить.
Шестая категория — code quality and review. Помогает коду соответствовать стандартам качества команды. Типичный пример — adversarial-review, подключает "новый взгляд" суб-агента для поиска ошибок. Эта способность может быть также встроена в CI как hook.
Последние три категории: уже подключены к production
Седьмая категория — CI/CD and deployment. Переводит код из разработки в production. Например, babysit-pr отслеживает полный цикл PR, а deploy- связывает build, постепенный выпуск, сравнение частоты ошибок и условия отката.
Восьмая категория — runbooks. Входной сигнал — это не "что я хочу написать", а "какой симптом сейчас". По alert, Slack thread или request ID определяются нужные инструменты и пути анализа, в результате выводится структурированное заключение.
Девятая категория — infrastructure operations. Обработка очистки ресурсов, управления зависимостями и анализа затрат. Эти действия часто деструктивны, поэтому в Skill нужно указать guardrail: сначала уведомить, потом подтвердить, только потом выполнить.
Третье: Anthropic упор делает не только на "написание", но и на "правильное написание"
После систематизации 9 категорий Anthropic рассказала более фундаментальные принципы: какие Skills стабильнее, куда стоит вложить больше сил.
Хорошие Skills обычно очень сфокусированы
Anthropic говорит прямо: лучшие Skills обычно очень сфокусированы. Skills, которые ясно относятся к одной категории, обычно стабильнее; Skills, пытающиеся охватить слишком много, наоборот, легче введут модель в заблуждение.
Это очень полезное наблюдение. Потому что когда команды начинают писать Skills, самая частая ошибка — попытка "сделать всё сразу", в результате Skill и трудно триггерить, и трудно поддерживать.
Среди всех категорий они особенно ценят «валидацию»
Anthropic особенно подчёркивает verification. Потому что модели легко создают иллюзию "уже сделано", а на самом деле проблемы часто на последнем этапе валидации.
Оригинальный текст даже рекомендует выделить неделю инженера на доведение verification Skills до хорошего уровня. Это звучит дорого, но если это влияет на качество результата, на самом деле экономно.
Они дали два очень практичных совета. Один: пусть Claude записывает видео своего тестирования, так вы видите, что оно действительно тестировал.
Второй: добавляйте программные утверждения в критических точках. Изменилось ли состояние, упало ли событие в БД, дошла ли страница в целевое состояние — всё старайтесь не оставлять на "выглядит нормально".
Самый ценный контент — это обычно gotchas
Anthropic ясно определила приоритеты контента в Skills. Самая информативная часть обычно не типовые шаги, а gotchas.
Потому что Claude и так может писать код и читать кодовую базу. То, что "по умолчанию он сможет", в Skill только добавляет контекст, не обязательно ценность.
Настоящий вес — в деталях, которые вытянут модель из стандартного мышления. Например, таблица subscriptions — append-only, нужно найти максимальную версию, не просто смотреть последний created_at.
Или одно поле в API gateway называется @request_id, а в billing-сервисе — trace_id. Или staging вернул 200, но это не значит, что Stripe webhook действительно обработал, нужно проверить реальное состояние в payment_events.
Такие детали небольшие, но если ошибиться, результат будет неправильным. Ценность Skills часто в этих "все в команде знают, но модель по умолчанию не знает".
Четвёртое: как действительно писать Skills
Anthropic объяснила "что делать сначала", теперь поделилась внутренним опытом "как конкретно писать, чтобы Skills действительно работали".
1. Не переписывайте очевидное
Первая деталь: не переписывайте очевидное. Skill не для человеческого резюме, он восполняет то, что модель не получит по умолчанию или легко может неправильно понять.
Anthropic привела пример frontend design Skill. Его ценность не в обучении Claude писать фронтенд, а в передаче "дизайнерского вкуса", выкристаллизовавшегося после многих итераций с клиентом, и избежании ошибок, например, избегать банальных шрифтов и цветовых схем.
2. SKILL.md — скорее оглавление, чем свалка
Вторая деталь: SKILL.md не должен быть свалкой. Лучше пусть служит оглавлением и путеводителем, разместив конкретный материал по отдельным файлам по мере надобности.
Например, если задача застопорилась, прочитайте stuck-jobs.md. Сигнатуры функций API и примеры использования могут быть в references/api.md.
Если нужен готовый markdown-файл, шаблон может быть в assets/. Скрипты, справочники, примеры тоже можно разместить по папкам, пусть Claude берёт при необходимости.
Это воплощение progressive disclosure. Сама файловая система — тоже форма инженерии контекста.
3. Не пишите Skills слишком жёстко
Третья деталь: не пишите Skills слишком жёстко. Дайте Claude ключевые правила, но оставьте место для адаптации, иначе при повторном использовании Skill легко застопорится в других ситуациях.
4. Подумайте о setup заранее
Четвёртая деталь: продумайте setup заранее. Многие Skills при запуске не хватает контекста от пользователя, например, в какой Slack-канал отправить сообщение.
Рекомендуется поместить такие конфигурации в config.json. Если конфигурация ещё не подготовлена, Claude сначала спросит пользователя; если нужны структурированные вопросы с множественным выбором, можно прямо вызвать инструмент AskUserQuestion.
5. Description должна работать на триггер
Пятая деталь: description пишите для модели. Claude Code в начале просканирует имена и описания всех Skills, затем решит, есть ли применимый Skill для этого запроса.
Поэтому description — не резюме, это описание условий триггера. Какие ключевые слова может сказать пользователь, какие файлы загрузить, в каких ситуациях активировать этот Skill — всё прямо там.
Оригинал привёл мелкий, но типичный пример. Триггерное слово вроде "babysit" должно прямо быть в description.
Пятое: когда Skills начинают активно использоваться, первыми вырастают память, скрипты и hooks
Anthropic специально посвятила этому отдельный раздел. Многие Skills начинаются с нескольких строк описания, но с активным использованием первыми добавляются память, скрипты и hooks.
Память
Как standup-post Skill может записывать каждый результат в standups.log, а при следующем запуске сначала читает историю и определяет, что изменилось со вчерашнего дня.
Такая память может быть простой, хватит append-only текста или JSON; может быть сложнее, прямо с SQLite. Оригинал также упомянул, что можно использовать переменную окружения ${CLAUDE_PLUGIN_DATA} для получения стабильной директории для такого хранилища.
Скрипты
Теперь о скриптах. Суждение Anthropic ясно: один из самых сильных инструментов для Claude — это сам код.
Если предварительно разместить обычные функции извлечения данных, анализа или операции, Claude не будет каждый раз переписывать шаблонный код с нуля, а потратит больше витков на "как это оркестрировать" и "что дальше".
Например, Skill анализа данных может иметь набор helper функций. Тогда, когда пользователь спросит "что произошло во вторник", Claude может быстро собрать более сложный скрипт анализа, не начиная с переделки базовой инфраструктуры.
Hooks
Наконец, on-demand hooks. Они срабатывают только при вызове Skill и существуют только в текущей сессии.
Оригинал привёл два типичных примера.
/careful перехватит опасные операции вроде rm -rf, DROP TABLE, force-push, kubectl delete; /freeze заблокирует Edit и Write вне указанной директории, полезно при отладке, чтобы не разломать случайно другое.
Шестое: когда команда начинает массово использовать Skills, дальше идёт распределение и управление
Это следующий уровень развития отдельного Skill. Когда Skill начинает распространяться в команде, проблема становится не только "как писать", но и "как делить с другими, как управлять".
Два основных пути: check-in в репо и plugin marketplace
Один — прямо check-in Skill в ./.claude/skills репо. Для небольших команд или взаимодействия в нескольких кодовых базах это уже хорошо.
Другой — делать плагины через внутренний Claude Code Plugin marketplace. Когда команда растёт, преимущества второго подхода очевидны.
Причина простая. Каждый добавленный check-in Skill увеличивает видимый модели контекст; а marketplace позволяет членам команды сами решать, что устанавливать, плюс удобнее организовать setup процесс.
Anthropic не применяет централизованное одобрение. Обычнее практика: кто хочет поделиться Skill, загружает в песочницу GitHub, потом публикует в Slack или другом канале для пробы.
Когда Skill получает признание, его автор подаёт PR, перемещая из песочницы в marketplace. Процесс лёгкий, но подходит для природы Skills — того, что растёт при реальном использовании.
Skills могут работать вместе
Оригинал упомянул интересное направление: skill composition. Например, можно иметь Skill загрузки файлов и Skill генерации CSV, потом второй после генерации вызывает первый для загрузки.
Такое управление зависимостями пока не встроено в marketplace или механизм Skills, но если в Skill просто ссылаться на имя другого, модель при условии, что оба установлены, сможет соединить цепь.
Можно измерять использование
Anthropic также упомянула использование PreToolUse hook для записи внутреннего использования Skills компанией.
Так видно, какие Skills популярны, какие недостаточно триггеристы.
Такие данные полезны. Потому что истинная проблема Skills после выпуска часто не "может ли работать", а "вспомнит ли о нём в нужный момент".
На заключение
Anthropic в концовке упоминает деталь: лучшие внутренние Skills часто начинались с нескольких строк и одного gotcha, становясь полнее по мере использования.
Это практически руководство начинающим. Skill не должен быть идеален с первого дня; сначала напишите способ валидации, запомните реальные ошибки, скрипты, память, hooks и распределение придут позже с использованием.
Если вы тоже используете Claude Code, начните с самой повторяющейся задачи. Напишите несколько строк описания, добавьте один gotcha, остальное доверьте времени и частоте использования.
Ссылка на оригинал: https://claude.com/blog/lessons-from-building-claude-code-how-we-use-skills
Александр — сооснователь RockAPI, эксперт в области ИИ и разработки API. RockAPI предоставляет неограниченный доступ к передовым моделям ИИ, таким как DeepSeek, GPT-4o, Claude и Gemini, с простой интеграцией и гибкими способами оплаты. Зарегистрируйтесь на https://www.rockapi.ru/ и получите бесплатный стартовый кредит для новых пользователей — начните свое путешествие в мир ИИ уже сегодня!