Claude Code Hooks, Slash Commands и Skills: что выбрать для workflow

В Claude Code hooks, slash commands и skills проще всего разделять не по тому, что выглядит мощнее, а по тому, кто запускает действие. Slash command нужен, когда человек должен явно выбрать момент. Skill нужен, когда Claude должна загрузить повторяемый метод, справочные файлы, шаблон или чеклист. Hook нужен, когда событие жизненного цикла должно каждый раз запустить проверку, команду, HTTP-запрос, prompt или agent handler.

По состоянию на 1 июня 2026 года в официальных документах Claude Code есть важная поправка: custom commands folded into skills, но существующие файлы .claude/commands/ продолжают работать. Поэтому практический вопрос звучит так: действие должно запускаться человеком, выбираться Claude по контексту или выполняться runtime-событием независимо от памяти модели?

Быстрая маршрутная таблица

Запомните коротко: slash command управляет timing, skill управляет method, hook управляет certainty. Slash command похож на кнопку, которую нажимает человек. Skill похож на пакет рабочего знания. Hook похож на правило, привязанное к событию, и оно не зависит от того, вспомнит ли Claude нужную инструкцию.

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

Slash Commands отвечают за явный момент

Slash command уместна, когда важен выбранный человеком момент запуска. Вы вводите / в начале сообщения, выбираете команду и при необходимости передаете аргументы. Это хорошо работает для session control, ручного старта review, подготовки релиза, краткого отчета перед переключением задачи или действия, где человек должен оставаться в loop.

Главная причина оставить workflow command-shaped — контроль побочных эффектов. Если действие может деплоить, удалять, публиковать, списывать деньги, переписывать много файлов, обращаться к внешнему сервису или менять состояние ветки, ручной старт является частью safety model. Метод можно положить в skill, но запуск должен быть видимым.

Слияние custom commands в skills не означает, что явная /-поверхность исчезла. Скорее skills стали более богатым способом упаковать кастомные workflow: metadata, supporting files, examples, scripts, dynamic context и tool controls. Старые .claude/commands/*.md можно оставить, если они делают маленькую стабильную работу и не нуждаются в более богатом контракте.

Чистый паттерн такой: built-in commands управляют сессией; user-invoked skill запускает повторяемый workflow; legacy command file остается только там, где он уже прост и ясен. Если вы собираетесь создать команду без понятного human timing requirement, остановитесь. Возможно, это skill, который Claude должна загрузить по контексту, или hook, который должен сработать на событии.

Skills несут повторяемый метод

Skill стоит писать, когда Claude нужна повторяемая техника работы. Полезная единица — не любимая фраза в prompt, а метод с инструкциями, references, examples, scripts, templates и boundaries. SKILL.md становится входной точкой, а соседние файлы позволяют не держать весь метод в постоянных project instructions.

Skill подходит для PR review по единой evidence checklist, миграционного аудита, подготовки API docs, локализации статей по source truth pack, браузерного QA или любой операции, где повторное объяснение метода будет шумным или рискованным. Если workflow повторяется редко и не требует файлов, сначала оставьте его как note или prompt.

Есть важное различие между skill, который Claude может выбрать сама, и user-invoked skill. Если skill меняет production, вызывает внешний сервис, стоит денег или переписывает много файлов, сделайте запуск явным. Тогда skill хранит метод, а /skill-name оставляет человеческий момент видимым.

Если вы уже выбрали skill path, локальный список идей находится в /ru/posts/claude-code-best-skills. Но не пытайтесь решать skill-ом проблему доступа. Skill может научить Claude, как работать с GitHub, browser, database или deploy system, но не выдает доступ магически. Для access layer смотрите MCP и tool permissions.

Hooks обеспечивают события и инварианты

Hook нужен, когда событие должно запустить действие каждый раз. Это lifecycle automation: before или after tool use, session start, notification, context compaction или другой configured event. Handler может быть command, HTTP request, prompt или agent, в зависимости от текущих docs и типа hook.

Хорошие hook-задачи узкие: после edit записать log или запустить formatter; перед рискованной shell-командой проверить protected path; при старте сессии вставить небольшой current context; при ожидании пользователя отправить notification; в конце работы сохранить компактную запись. Они проверяемы, объяснимы и не требуют широкого вкусового решения.

Не кладите в hook тонкий review judgment. Вопрос "достаточно ли хорош architecture review" должен жить в skill, subagent или explicit review workflow. Вопрос "пытается ли команда удалить protected directory" может жить в hook. Чем автоматичнее поверхность, тем уже должно быть правило.

Начинайте с observe и log before block. Плохой skill потратит контекст или поведет задачу не туда. Плохой hook будет вмешиваться в каждую сессию, добавлять latency, шуметь в логах или ломать валидную работу. Делайте enforcement только после того, как сигнал стабилен.

Комбинируйте слои только при разных обязанностях

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

Плохая версия — command повторяет skill, skill пытается enforcing policy, hook просит Claude сделать тонкий judgment. Хорошая версия: command chooses the moment, skill teaches the method, hook enforces one invariant. Если работу каждого слоя нельзя назвать одним предложением, удалите слой.

Stop rules перед новым файлом в .claude

Не помещайте nuanced judgment в hooks. Hook может проверить path, command pattern или event payload. Review taste, архитектурный вывод и продуктовый выбор должны оставаться в skill или явном review.

Не auto-trigger destructive skills. Publish, deploy, delete, billing, production changes и large rewrites должны сохранять human invocation. Метод можно упаковать в skill, но старт не должен быть скрытым.

Не превращайте одноразовые prompts в skills. Skill заслуживает места, когда повторяемый workflow выигрывает от references, examples, scripts или templates. Иначе это просто заметка.

Не используйте command list как strategy. Полезно знать /help, /skills, /hooks и /context, но дизайн решает другой вопрос: timing, method, enforcement, access или runtime ownership. Для external access нужен MCP; для регулярного unattended workflow сначала выбирайте runtime, а не hook.

Не используйте hooks как memory. Если правило должно быть видно до работы, положите его в project instructions или memory surface. Hook срабатывает на событии; он не должен быть скрытым policy document.

Практический checklist

Перед внедрением ответьте по порядку. Кто запускает работу: человек, Claude или runtime event? Это одноразовое действие или повторяемый метод? Поведение должно сработать автоматически или on demand? Можно ли проверить правило детерминированно? Есть ли side effects, costs или production changes? Нужен ли внешний доступ? Поймет ли teammate, почему этот слой существует?

Если ответ указывает на explicit timing, начните со slash command или user-invoked skill. Если ответ указывает на method, пишите skill. Если нужен deterministic event handling, конфигурируйте hook. Если проблема в external access, смотрите MCP. Если нужна регулярная работа без открытой сессии, сначала выберите runtime owner.

Хорошая конфигурация объясняется коротко: "Эта команда запускает workflow, этот skill несет метод, этот hook проверяет один invariant". Это проще дебажить, проще ревьюить и безопаснее передавать команде.

Запишите решение как handoff для команды

Большинство ошибок появляется не при первом создании файла, а позже, когда другой разработчик открывает .claude и не понимает, почему там есть команда, skill и hook одновременно. Для каждого нового surface оставляйте короткий handoff: кто запускает действие, кто владеет ошибкой, какие side effects разрешены и при каком условии слой удаляется. Это может быть в SKILL.md, в project rules, в runbook или в PR description, но не должно жить только в памяти автора.

Для slash command handoff должен объяснять human timing. /release-check имеет смысл не потому, что release важен, а потому что человек должен выбрать момент, branch, approval state, rollback window и коммуникацию. Если все входы можно проверить детерминированно, часть работы принадлежит hook или CI. Если нужна методика review, исключения и формат отчета, эту методику надо держать в skill, а command оставить только точкой старта.

Для skill handoff должен объяснять reusable method. Хороший skill хранит цель, порядок действий, нужные evidence, шаблон вывода, ограничения инструментов и failure handling. Если skill состоит из одной любимой фразы, его лучше оставить как заметку. Если skill начинает требовать обязательного запуска при каждом событии, он больше похож на hook или pipeline rule. Метод должен помогать Claude рассуждать и действовать стабильно, но не должен тайно становиться runtime enforcement.

Для hook handoff должен объяснять invariant. Hook подходит для узких проверяемых границ: log tool use, block dangerous path, run formatter, alert on missing test, send event to audit endpoint. Как только правило требует product judgment, архитектурного tradeoff или объяснения спорной ситуации, оно должно перейти в skill, review checklist или human command. Hook ценен тем, что срабатывает предсказуемо, а не тем, что заменяет обсуждение.

При ревью существующей настройки чистите в таком порядке: hooks without owner, skills without supporting method, commands that only repeat a skill name. Удаление слоя часто улучшает workflow сильнее, чем новый automation. Зрелая конфигурация Claude Code должна показывать owner, trigger, failure path и rollback для каждого слоя.

FAQ

Slash commands и skills теперь одно и то же?

Нет. Docs говорят, что custom commands folded into skills, а skill можно вызвать через /skill-name. Но slash command остается видимой invocation surface. Думайте о command как о timing, а о skill как о packaging.

Нужно ли мигрировать все .claude/commands в skills?

Нет. Мигрируйте только когда workflow требует supporting files, metadata, dynamic context, tool controls или лучшей discoverability. Маленькая старая команда может остаться маленькой старой командой.

Hooks надежнее skills?

Они детерминированнее, но не универсально лучше. Hook срабатывает на configured event, поэтому хорош для logs, formatters, notifications и narrow guards. Skill лучше, когда Claude нужен method, context, examples или checklist.

Что проверить перед добавлением surface?

Проверьте /help или commands reference, /skills, /hooks и /context. Если после этого не ясно, чего не хватает, не добавляйте новый layer. Сначала назовите missing layer: timing, method, enforcement, access или runtime.

Где держать project-wide rules?

Широкие always-on rules принадлежат CLAUDE.md или memory surface. Детальные повторяемые процедуры принадлежат skills. Event enforcement принадлежит hooks. Не прячьте всю политику проекта в hook.

Короткий вывод

Выбирайте surface по владельцу запуска. Slash commands — explicit human timing. Skills — reusable method. Hooks — deterministic lifecycle events. Комбинируйте только когда каждый слой имеет отдельную работу. Тогда Claude Code остается предсказуемым, а не превращается в набор скрытых автоматизаций, которые никто не может объяснить.