Чтобы Claude Code автоматически проверял правки сайта, настройте хуки: правила, которые запускают команды при определённых событиях работы агента. Для проверки нового кода обычно нужен запуск после изменения файлов, а перед публикацией нужен отдельный контроль. Проверка до записи видит прежнее содержимое и не подтверждает качество будущей правки. Ниже разберём, как выбрать момент запуска, подготовить тесты и проверить саму автоматизацию. Это поможет владельцу бизнеса сформулировать задачу разработчику и принимать изменения по результатам проверок.
Что проверяет хук и почему важно выбрать момент запуска?
Хук Claude Code связывает событие с действием. Например, агент изменил файл, после чего запускается команда проверки проекта. Сам хук не знает, правильно ли сайт считает стоимость заказа: это описывает тест. Поэтому настройку начинают с проверок, которые уже умеют находить нужные ошибки.
Фраза «проверять перед сохранением» звучит понятно, но смешивает разные этапы. Сохранение файла, завершение задачи агентом и публикация сайта происходят отдельно. Для каждого этапа нужен свой контроль.
- До изменения файла можно ограничить действие агента, например запретить правки в определённой папке. Проверить ещё не записанный результат обычной командой тестов здесь не получится.
- После изменения файла можно проверить новое содержимое. Этот момент подходит для коротких проверок синтаксиса и связанных тестов.
- Перед завершением задачи полезно проверить согласованность нескольких изменений и изучить ошибки, которые остались.
- Перед публикацией нужен отдельный запуск обязательных проверок, даже если локальные хуки уже отработали.
Для бизнес-сайта сформулируйте правило через результат: «После изменения расчёта цены запускается тест расчёта, а перед выпуском проверяется путь от выбора услуги до подтверждения заявки». Так разработчик сможет выбрать подходящее событие и команду, вместо того чтобы просто включить автоматический запуск всего подряд.
Какие тесты запускать после изменений сайта?
Начните с функций, ошибка в которых мешает работе бизнеса. Для каталога это поиск и карточка товара, для калькулятора — формула расчёта, для формы заявки — проверка полей и сообщение об успешной отправке. Это примеры задач, а не универсальный комплект: список зависит от того, что делает ваш сайт.
Разделите проверки по объёму работы. После небольшой правки нужен короткий ответ, иначе агент будет тратить время на один и тот же полный прогон. Перед выпуском проверяйте весь важный пользовательский сценарий, включая переходы между страницами.
- Проверка синтаксиса обнаруживает код, который среда разработки не сможет прочитать или выполнить.
- Проверка типов, если проект её поддерживает, помогает заметить несовместимые данные: например, текст вместо ожидаемой суммы.
- Тест отдельной функции проверяет конкретное правило, например расчёт итога при изменении количества.
- Сквозной тест открывает сайт в браузере и повторяет действия посетителя. Он проверяет, работают ли части сайта вместе.
В каталоге «Термос Беспалова» скилл E2e Testing описан как инструмент для сквозных тестов на Playwright, включая структуру тестов и работу с нестабильными проверками. Там же Eval Harness посвящён измерению качества работы агента. Эти задачи стоит разделять: оценка поведения агента не заменяет проверку формы или расчёта на сайте (источник: «Тестирование и безопасность — скиллы для Claude Code», «Термос Беспалова»).
Скилл даёт агенту инструкции по работе, а хук запускает действие по событию. Сначала добейтесь, чтобы нужная команда проверки работала вручную в тестовой среде. Затем подключайте её к автоматическому запуску.
Как настроить хуки Claude Code без ложного ощущения защиты?
Точные названия событий и формат настройки сверяйте с документацией установленной версии Claude Code. Универсальный фрагмент конфигурации без сведений о проекте легко привязать к неверному событию. В русскоязычном руководстве Claude Code Handbook есть разделы о хуках, скиллах и шаблонах CLAUDE.md; их удобно использовать как отправную точку для настройки (источник: sfrangulov/claude-code-handbook-ru).
- Найдите команду проверки в проекте. Попросите разработчика записать, из какой папки её запускать, что нужно для работы и где появляется результат.
- Проверьте команду вручную. Успешный результат должен означать, что нужные тесты действительно выполнились. Отсутствие тестов нельзя считать подтверждением качества.
- Выберите событие после изменения файлов и ограничьте запуск нужными инструментами или путями, если выбранный механизм это поддерживает. Изменение картинки не должно без причины запускать проверки расчётной логики.
- Определите реакцию на ошибку. Вывод должен попадать в доступный агенту отчёт, а обязательная проверка перед выпуском должна останавливать публикацию при неуспехе.
- Проверьте настройку на заведомо неверной правке в отдельной рабочей копии. Убедитесь, что тест обнаружил ошибку, отчёт сохранился, а установленное ограничение сработало.
- Верните правильный код и повторите запуск. Проверьте оба исхода: отказ и успешное завершение.
Отдельно договоритесь, что делать, если команда зависла или тестовая среда недоступна. Такой результат означает «проверка не завершена». Он не даёт оснований считать правку исправной. В отчёте должно быть видно различие между ошибкой сайта и сбоем самой проверки.
Не каждый хук блокирует дальнейшую работу: это зависит от события и настроек. Поэтому ограничение нужно испытать на практике. Подробности такой схемы можно разобрать по материалу как запускать проверки после правок Claude Code через хуки, а в задаче разработчику отдельно указать, какое действие запрещено после неуспешного теста.
Как принимать правки и выпускать их на рабочий сайт?
Попросите приложить к задаче короткий отчёт: что изменили, какие команды запускали, чем они завершились и что проверили вручную. Сообщение агента «готово» такого отчёта не заменяет. Для владельца малого бизнеса это понятный способ принимать работу без чтения каждой строки кода.
Автоматические тесты покрывают только те условия, которые в них заложили. Если тест нажимает кнопку и проверяет появление сообщения, он ещё не подтверждает правильность текста, удобство на телефоне или работу всех вариантов формы. Добавляйте ручную проверку именно тех деталей, которые затронула задача.
Перед выпуском подготовьте тестовую версию сайта и способ вернуть предыдущую рабочую версию. Такой порядок согласуется с рекомендациями о preview-среде, мониторинге и понятном rollback в материале «Вайбкодинг в 2026: от идеи до безопасного production» (источник: Мадияр Хамзанов). Практическую подготовку описывает инструкция как подготовить откат сайта перед публикацией правок Claude Code.
После публикации проверьте сайт снаружи: открывается ли нужная страница, выполняется ли основное действие, нет ли новых ошибок в журнале. Локальный тест не подтверждает доступность рабочего сайта. Для этого пригодится отдельный порядок проверки доступности сайта после правок Claude Code.
Если настройку передаёте подрядчику, включите в результат работ сами тесты, конфигурацию хуков и инструкцию по разбору сбоя. Попросите показать не только успешный запуск, но и остановку на ошибке. Тогда следующий разработчик сможет воспроизвести проверку без переписки с автором настройки.
Типичные ошибки при настройке хуков
- Запускать тесты до записи и считать, что они проверили будущую правку. Для нового содержимого нужен запуск после изменения.
- Проверять только факт старта команды. Смотрите, какие тесты выполнились и с каким результатом завершился процесс.
- Запускать полный набор после каждого изменения. Выделите короткие проверки для работы агента и обязательный набор перед выпуском.
- Разрешать агенту отключать неудобный тест ради завершения задачи. Изменение тестов требует отдельного объяснения: какое требование поменялось и почему.
- Давать тестам доступ к рабочим операциям. Используйте отдельную среду, чтобы пробный сценарий не создавал реальные заявки и не менял рабочие данные.
- Исправлять сразу все ошибки без повторной проверки. Сохраняйте сообщения отдельно, устраняйте конкретную причину и запускайте соответствующий тест заново.
Начните с одного важного сценария сайта и команды, которая проверяет его вручную. Затем подключите запуск после правок и намеренно внесите ошибку в тестовой копии. Когда хук обнаружит её, сохранит понятный отчёт и выполнит нужное ограничение, добавляйте остальные проверки. Перед публикацией оставьте отдельный контроль и подготовленный откат.
