Skills для проверки работы

Видео: «Skills для проверки работы»

По мере роста проекта вы начинаете замечать, что одна и та же работа повторяется снова и снова. Вы уже знаете, что skills (навыки) хорошо подходят для автоматизации повторяющейся работы. В этом уроке мы рассмотрим одну конкретную задачу, с которой skills справляются отлично: проверку собственной работы. Если создавать какой-то skill первым, то именно этот.

Почему skill для проверки стоит создать первым

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

Skill для проверки устраняет эту зависимость. Вот как он устроен. Вы просите Claude что-то отрефакторить. Когда он заканчивает, изменение соответствует описанию skill, поэтому skill срабатывает сам. Дальше он:

• Запускает набор тестов.
• Читает diff.
• Проверяет, что ни один тест не был ослаблен только ради того, чтобы всё прошло.
• Сообщает, пройдена проверка или нет, и прикладывает доказательства.

Весь процесс выполняется без вашего запроса. Его запускает описание skill, а после срабатывания skill каждый раз проходит одни и те же шаги.

Обратите внимание на последнюю проверку в этой цепочке. Недостаточно запустить тесты и увидеть зелёный цвет. Тест можно незаметно ослабить так, что он будет проходить при любых условиях. Поэтому skill читает diff и подтверждает, что тесты не ослаблены. «Готово» не означает, что код выглядит правильно при чтении diff. «Готово» означает, что все проверки запущены, их результаты получены и явно указаны.

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

В папке skill может быть не только инструкция

Skill не ограничивается одним файлом SKILL.md. В папке рядом с ним можно хранить и другое, и именно это делает skills полезными для проверки.

• Положите рядом с SKILL.md файл reference.md с подробными материалами и сошлитесь на него из SKILL.md. Claude прочитает его только тогда, когда понадобится такая глубина. Основной файл при этом остаётся коротким.
• Положите в папку и скрипты. Claude выполняет их, а не загружает их содержимое в контекст. Значит, skill может нести собственные инструменты, например check.sh, который запускает все проверки.

Вывод: сам SKILL.md должен оставаться компактным. Выносите объёмные материалы (длинные объяснения и исполняемые скрипты) в соседние файлы. Компактный файл описывает, что делать. Соседние файлы содержат подробности и инструменты.

Где должно жить каждое правило

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

Соглашения, которые действуют всегда, например правила именования или расположение файлов, относятся к файлу CLAUDE.md. Процедуры и справочные материалы, связанные с определённым типом задач, относятся к skill.

Есть и третий случай. Правило, которое Claude не должен иметь возможности пропустить, относится к hook (хуку), а не к одному из вариантов выше. Дело в том, что CLAUDE.md и skills представляют собой инструкции, которым Claude следует, а hook является кодом, который действительно выполняется. Если пропуск правила недопустим, не полагайтесь на то, что инструкции будут выполнены.

Итоги

Skill представляет собой папку с файлом SKILL.md внутри: название, описание, которое его запускает, и сама процедура. Пока skill не понадобится, в контекст загружаются только описания, поэтому упаковать в skills каждую повторяющуюся процедуру почти ничего не стоит.

Начните с проверки. Создайте skill, добавьте его в папку .claude/skills вашего проекта, и вся команда получит тот же приём. Работа каждого проверяется одинаково, автоматически, и никому не нужно помнить, что об этом надо попросить.