12 скиллов для Claude Code, которые стоит поставить
Опубликовать скилл ничего не стоит, поэтому большая часть того, что есть, — сохранённый промпт с шапкой. Четыре правила отбора, двенадцать скиллов и что меняется, когда папку коммитят в репозиторий.
Скилл для Claude Code — это папка с файлом SKILL.md. Кладёте её в .claude/skills/ своего проекта, и Claude сам берёт файл, когда задача подходит под описание: упоминать скилл в каждом сообщении не нужно. Простота устройства и объясняет, почему таких файлов опубликованы уже тысячи — и почему большинство из них не стоит держать у себя.
Мы разбираем каждый публичный репозиторий, где есть скиллы, — сейчас это 10 441 штука, и у каждой написано вручную, что она делает, — каталог Skills для Claude Code. Ниже — что видно с этой стороны и какие двенадцать скиллов мы поставили бы в рабочий репозиторий сегодня.
Как устроен скилл
У SKILL.md есть YAML-шапка — имя и описание, когда файл применять, — а дальше обычные инструкции в Markdown. Claude держит перед глазами описания всех установленных скиллов и подгружает полный текст только того, который понадобился. В папке скилла может лежать не только текст: scripts/ — для частей, которые должны выполняться детерминированно, references/ — материал, который подтягивается по мере надобности, assets/ — шаблоны, из которых собирается результат.
От промпта скилл отличается тем, где он живёт и когда срабатывает. Промпт лежит в заметках, и вы вставляете его заново каждый раз. Скилл лежит в репозитории рядом с кодом, проходит ревью как любой другой файл и работает у всех, кто склонировал проект.
Зачем вообще отбор
Опубликовать скилл ничего не стоит, поэтому заметная часть того, что есть, — это сохранённый промпт, которому приделали шапку. Такие файлы пересказывают документацию инструмента, обрываются на самом интересном месте или описывают процесс, который автор не повторял дважды. Они не вредят — они шум, а у шума есть цена: описание каждого установленного скилла занимает место в контексте модели независимо от того, сработал он или нет.
Как каталог выглядит сегодня: 10 441 активный скилл из 567 репозиториев. Одна самая большая коллекция даёт из них около трёх тысяч. По задачам самая крупная полка — интеграции: 2 511 скиллов, примерно по одному на внешний сервис. Дальше 1 388 про сам код, 917 общих, 826 маркетинговых, 587 про инженерную практику, 573 про контент, 357 про тестирование и 327 про документацию. Написание кода — меньшая часть того, ради чего заводят скиллы, и это полезно знать до того, как идти искать.
Из десяти тысяч до двенадцати нас довели четыре правила.
Скилл закрывает работу целиком. «Проверить пул-реквест и опубликовать результат» — это работа. «Написать хорошее сообщение коммита» — шаг внутри неё, и отдельный файл для него не нужен.
В нём есть не только текст. Скрипты, справочные файлы, шаблоны, разобранные примеры. Скилл из одних инструкций — это промпт, которому добавили лишний слой.
Он называет, чего не делает. Лучшие файлы каталога обозначают свою границу в первом же абзаце. Скилл, который обещает всё, не решает ничего.
Он живёт в коде, которым пользуются. Звёзды репозитория-хозяина измеряют проект, а не скилл, — но файл, который правят внутри продукта, выходящего каждый день, уже поправила реальность, а файл из пустого репозитория — нет. Мы взяли этот признак как довесок, а не как проверку: пять скиллов из двенадцати ниже пришли из репозиториев, у которых меньше двухсот звёзд.
Пул-реквесты и ревью кода
pr-reviewer сначала собирает о пул-реквесте всё — метаданные, дифф, комментарии, коммиты, связанные задачи — и пишет три отдельных файла: подробное внутреннее ревью, чистую версию для публикации и список предлагаемых инлайн-комментариев. В GitHub ничего не уходит, пока вы не наберёте /send. Публикация в два шага и есть причина, по которой он в списке: большинство ревью-скиллов сначала постит.
handle-pr-comments — его правят внутри Storybook — проходит незакрытые треды ревью по одному через GraphQL-запрос reviewThreads. По каждому треду читает окружающий код, пересказывает замечание, предлагает конкретную правку и спрашивает: применить, ответить или пропустить. Комментарии живых ревьюеров обрабатываются раньше ботов. Это единственный найденный нами скилл, который относится к треду как к разговору, а не как к пункту списка.
my-pr-checker берёт другую сторону: ваш собственный пул-реквест после ревью. Смотрит статус CI, разбирает инлайновые и общие комментарии — включая те десятки, что оставляют Copilot и CodeRabbit, — коммитит исправления, пушит и повторяет, пока проверки не станут зелёными, а треды закрытыми.
contrib-pr-review проверяет пул-реквест от постороннего участника и единственный в этом списке относится к вкладу как к возможной атаке: ищет правки workflow в .github/ вместе с pull_request_target, а также изменения AGENTS.md и конфигурации самого агента. Если вы принимаете чужие пул-реквесты в репозиторий, который читает агент, ставьте этот скилл первым.
Остальные — в подборке скиллов для GitHub.
Документация
documentation из собственных knowledge-work-плагинов Anthropic закрывает README, справочник API, runbook'и, архитектурные заметки и онбординг-гайды, причём у каждого формата своя структура: README ведёт к первому работающему результату за пять минут, документация API покрывает аутентификацию, коды ошибок и примеры SDK, runbook несёт шаги отката и пути эскалации.
update-docs — его правят внутри Anytype — держит README рядом с кодом, который тот описывает, и трогает только разделы, которых коснулось изменение. Дельта вместо перегенерации: ровно в этом разница между документацией, которая остаётся актуальной, и документацией, которой никто не верит.
author-product-docs раскладывает пользовательскую документацию по методологии Diátaxis — туториалы, how-to, справочник, объяснение — и отказывается утверждать что-либо о поведении продукта, не прочитав исходники. Он же называет, для чего не предназначен: спецификации фич, RFC и ADR прямо вынесены за границу.
crafting-effective-readmes начинает с вопроса, что именно вы делаете — пишете с нуля, добавляете раздел, обновляете устаревшее или проверяете, — и подбирает один из четырёх шаблонов по аудитории: open source, личный проект, внутренний инструмент, репозиторий конфигов. README для контрибьюторов и README для себя будущего — разные документы, и редкий скилл это проговаривает.
Остальные — в подборке скиллов для документации.
Стандарты репозитория и собственные скиллы
managing-git-workflow из монорепозитория HASH фиксирует имена веток, заголовки пул-реквестов и тело по шаблону, а дальше проводит изменение через merge queue и обратно к задаче в трекере. Это тот скилл, который стоит прочитать, чтобы увидеть, как выглядит записанным «вся команда работает одинаково».
documentation-guide несёт матрицу требований: какие документы обязательны, рекомендованы или не нужны в зависимости от того, новый это проект, рефакторинг, миграция или поддержка, — по README, ARCHITECTURE, API, DATABASE, DEPLOYMENT, MIGRATION, ADR и CHANGELOG.
skill-creator ставится раньше, чем вы начнёте писать своё. Он описывает анатомию пакета целиком — обязательную шапку, scripts/, references/, assets/ — и приём прогрессивного раскрытия, который держит SKILL.md коротким, вынося подробности в отдельные файлы.
atopile-skills — его обратная половина и самый недооценённый файл в списке. В нём описано, как держать собственные SKILL.md правдивыми: найти первоисточник, проверить каждое утверждение прямо в коде через rg, починить устаревшие пути и вызовы, оставить быстрый старт на пять–двадцать строк. Скиллы протухают ровно так же, как протухает документация, и почти никто не записывает, как это остановить.
Остальные — в подборке скиллов для команды.
Как поставить
Положите файл в .claude/skills/<имя>/SKILL.md своего проекта и опишите задачу обычными словами. Настраивать нечего, перезапускать тоже. Скилл, положенный в пользовательскую папку, ходит за вами по всем проектам; скилл, закоммиченный в репозиторий, ходит за проектом по всем людям.
Начните с двух-трёх. Описание каждого установленного скилла лежит в контексте, поэтому папка из сорока хуже папки из четырёх: Claude тратит внимание на выбор между ними и чаще ошибается.
Что меняется, когда скиллы общие
Закоммитьте папку. Это решение и есть большая часть пользы — и именно его имеют в виду, когда спрашивают, как поделиться скиллами с командой: правила ревью, формат коммитов, релизный чек-лист и договорённости по фреймворку перестают быть тем, что каждый помнит по-своему.
Держится это на двух привычках. Правки скиллов проходят ревью как код — скилл это инструкция агенту с правом записи в ваш репозиторий, и внимания он заслуживает не меньше, чем скрипт. И неиспользуемые скиллы удаляются: протухший скилл хуже отсутствующего, потому что он всё равно сработает.
Где остальные
Каталог открыт без регистрации: карточки, описания и категории читает кто угодно. Сам файл SKILL.md и ссылка на первоисточник выдаются по подписке, начиная с Базового тарифа.
По задачам: GitHub · документация · тестирование · безопасность · команда · контент · SEO · дизайн.
FAQ
Где скиллы Claude Code лежат на GitHub?
Почти все — внутри обычных репозиториев проектов, в папке .claude/skills/ рядом с кодом, а не в отдельных репозиториях «под скиллы». Поэтому их тяжело искать поиском по GitHub: скилл лежит подпапкой проекта, название которого не имеет к нему отношения. Наш каталог разбирает именно эти папки и описывает каждый скилл отдельно.
Сколько скиллов держать в проекте?
Меньше, чем хочется. Описание каждого установленного скилла лежит в контексте модели, поэтому большая папка делает выбор сложнее, а не богаче. Три–восемь штук, каждая из которых закрывает настоящую работу, лучше сорока пересекающихся.
Как раздать скиллы всей команде?
Закоммитить .claude/skills/ в репозиторий. Их получает каждый, кто склонировал проект, правки проходят ревью как любой другой файл, а история показывает, кто и когда поменял правило. Скиллы в личной папке ходят за человеком, а не за проектом, — это противоположность тому, что нужно команде.
Может ли скилл навредить?
Скилл — это инструкция агенту, который умеет писать файлы и запускать команды, так что да: к чужому скиллу стоит относиться как к любой другой зависимости. Прочитайте SKILL.md и всё, что лежит в scripts/, до установки, и особенно внимательно — скиллы, трогающие настройки CI. По той же причине contrib-pr-review выше проверяет входящие пул-реквесты на правки конфигурации агента.
Работают ли скиллы вне Claude Code?
Формат принадлежит Claude, но часть позиций каталога поставляет те же инструкции и для других агентных инструментов. Если переносимость важна, выбирайте скиллы, логика которых лежит в scripts/: они переезжают, а текст, настроенный под одну модель, — нет.