Anthropic наконец опубликовали свою внутреннюю методологию Skill

Я прочитал блог команды Anthropic «Lessons from building Claude Code: How we use skills». Это, пожалуй, самый глубокий практический обзор по теме Skill, который я видел на данный момент.

Skill на самом деле несложен, но чтобы действительно хорошо реализовать Skill, я считаю, это не так просто.

Я помню, когда Skill только стал популярным, все очень любили делать разные стили Skill, писать стили для текста. Кажется, достаточно вставить свой стиль письма, и модель сможет стабильно выдавать текст в этом стиле.

Но потом я сам попробовал и понял, что во многих случаях это просто невозможно.

Потому что один стиль Skill может включать всего несколько тысяч или даже десятки тысяч слов. Как только Skill загружен, контекст занимает очень большую часть. Чем больше контекста, тем хуже становится способность модели думать.

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

Есть и другой распространённый случай.

Многие пишут Skill, добавляя туда всякие инструкции по операциям. Что делать на первом шаге, что на втором, что на третьем. В итоге при запуске модель ведёт себя нестабильно.

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

После прочтения статьи Anthropic у меня возникло сильное ощущение, что многие используют Skill, но не всегда полностью понимают его суть.

По сути, Skill — это инженерия контекста. Когда нужно вставлять знания в Skill, когда лучше разбивать их на References, когда писать скрипты, а когда использовать Gotchas для ограничения модели — в этом много опыта.

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

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

#01 Не пишите пустых слов

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

Внутри Anthropic часто подчеркивают, что в Skill нужно писать именно Gotchas — типичные ловушки и ошибки.

Например:

1. Этот таблицу нельзя сортировать по created_at

2. Возврат 200 в staging не означает успех

3. request_id и trace_id — это одно и то же

Поскольку эта информация часто есть в опыте сотрудников, важно помнить, что суть Skill — это не просто знания, а именно знания, которые требуют особого внимания.

Skill = записать опыт мастеров.

Через Skill можно накопить опыт, разбросанный по разным людям.

#02 Skill — это по сути инженерия контекста

Это, пожалуй, одно из самых глубоких утверждений Anthropic.

Skill — это не markdown-файл, а папка. Для тех, кто использует Skill, это звучит как очевидное утверждение.

Но я последние дни размышлял и постепенно понял: они именно хотят через структуру папки выразить концепцию инженерии контекста.

Рассмотрим типичную структуру Skill:

skill/  ├── SKILL.md  ├── references/ — подробные объяснения, API, границы  ├── scripts/ — исполняемые скрипты  ├── examples/ — примеры  ├── assets/ — шаблоны, картинки, статические материалы

Когда вызывается конкретный Skill, модель сначала читает SKILL.md. Если все сведения засовывать туда, контекст быстро станет слишком большим.

Например, это Skill по устранению ошибок платежей, где есть описание кодов ошибок Stripe, исторические кейсы, скрипты диагностики и шаблоны финальных отчётов.

Если всё это положить в SKILL.md, при каждом вызове модель будет заново его читать.

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

А у Anthropic подход совсем другой.

SKILL.md — это скорее навигационная страница. Его задача — подсказать модели, что при ошибках Stripe нужно обращаться к references, а при необходимости — запускать scripts, чтобы выполнить диагностику, и в конце — использовать assets для шаблонов отчётов.

Весь процесс — постепенное раскрытие информации.

Ниже есть очень хорошая иллюстрация, настоятельно советую сохранить.

#03 Используйте скрипты по максимуму

Не стоит тратить ограниченный контекст и вычислительные ресурсы модели на повторяющиеся задачи. Лучше делегировать их скриптам.

Например, многие пишут Skill так:

1. Запросить регистрационные данные; 2. Запросить платёжные данные; 3. Посчитать конверсию; 4. Проанализировать причины ошибок.

Это вполне рабочий подход. Модель может выполнить, но при каждом запуске ей приходится заново проходить весь анализ.

Запросы данных, их обработка, учёт крайних случаев — всё это повторяющиеся операции.

Если эти операции уже многократно проверены, зачем модель должна их заново изобретать? Лучше сразу подготовить скрипт.

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

С этой точки зрения, Scripts в Skill — это накопление организационных возможностей. За каждым скриптом стоит опыт, полученный командой после множества ошибок и исправлений.

Закрепив эти навыки, Claude сможет работать на базе проверенных практик, а не с нуля каждый раз.

Поэтому я всё больше убеждаюсь, что Instructions и Scripts решают разные задачи.

Instructions — это опыт и суждения, Scripts — это способности и действия.

Например, в Skill по устранению ошибок платежей может быть такая инструкция:

«Если Stripe возвращает 200, не считать платёж успешным, нужно проверить таблицу payment_events.»

Это инструкция, потому что основана на опыте. А функция check_payment_events() — скрипт, потому что это действие.

Если есть только скрипт, модель знает, как проверить, но не знает, почему.

Если есть только инструкция, модель знает, что нужно проверить, но каждый раз приходится реализовывать заново. И то, и другое важно.

#04 Описание — это скорее маршрут

Многие неправильно пишут описание Skill.

Потому что обычно описывают функции. Например: PR Management Skill помогает следить за статусами PR, решать CI-проблемы, автоматически делать merge.

Но проблема в том, что модель ищет Skill не по функциям, а по имени и описанию.

Когда пользователь задаёт вопрос, модель сначала ищет подходящий Skill по названию и Description, а потом решает, какой активировать.

Поэтому самое важное в Description — не то, что умеет Skill, а при каких условиях его нужно запускать.

Description — это своего рода маршрутизатор для Skill.

В реальной жизни редко кто говорит: «Помоги мне вызвать инструмент для управления PR». Скорее — «Посмотри, этот PR застрял, CI сломался и т.п.»

Поэтому хороший Description должен описывать именно намерения пользователя, а не функции.

Я даже предлагаю простой тест: после написания Description удалите весь Skill, оставьте только одну строку Description и спросите себя: если модель увидит вопрос пользователя, сможет ли понять, когда нужно активировать этот Skill?

Если не сможет — значит, нужно доработать.

#05 Управление и распространение Skill

Еще важный момент — управление Skill.

Когда Skill немного — несколько штук, их легко держать в порядке, обновлять и использовать самостоятельно. Но большинство команд рано или поздно сталкиваются с вопросом: как управлять большим количеством Skill?

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

Опыт Anthropic в этом очень ценен.

Маленькая команда — обычно держит Skill в репозитории проекта, в папке .claude/skills. Все используют одну и ту же коллекцию, одни и те же подходы.

Но с ростом количества Skill появляется новая проблема.

При запуске Claude Code сканирует все Skill по названию и Description, чтобы понять, какой выбрать. Чем больше Skill, тем выше издержки маршрутизации.

Именно поэтому Anthropic начали делать Marketplace. Но интереснее — как они управляют этим Marketplace.

Многие компании вводят строгие процедуры: кто написал Skill — тот должен его сначала отправить на одобрение, пройти проверку, и только потом он попадает в официальный каталог. Мы тоже так делали, но это очень тяжело и бюрократично.

А Anthropic выбрали более легкий подход.

Они позволяют новым Skill сначала распространяться внутри небольшой группы. Коллеги сами устанавливают, тестируют, используют.

Если Skill действительно решает проблему, его начинают применять шире. Тогда автор может предложить его в Marketplace.

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