Хуки для Claude Code: 8 запретов, которые агент не обойдёт

Замки для Claude Code: 8 запретов, которые агент не обойдёт

Шаблон задачи, где агент доказывает «готово», раздел «Ревью», 8 запретов с тестами, уровни риска и замок на выпуск в main. Шесть слоёв проверки команды Claude Code, переложенные на одного человека с обычной подпиской, за 1 вечер.

Claude пишет около 90% кода Claude Code, и каждую строку там больше не читают

15 октября команда Claude Code рассказала, как проверяет код, который пишет сам Claude. Я перенёс их схему в свой продукт Yoolip AI и собрал из неё набор для одного человека на обычной подписке. Смотри на три числа, они объясняют, зачем он нужен.

Проверку держат механизмы, которые срабатывают всегда. Текст в CLAUDE.md агент может прочитать, а может и пропустить.

38 правил из 62 у моих агентов держались на честном слове

Yoolip AI - мой сервис аналитики для продавцов на маркетплейсах. Код в нём пишут агенты, в среднем 16 коммитов в день. Правила для них жили в CLAUDE.md (это памятка, которую агент читает перед работой), капсом: «никогда не пушь в main», то есть не выпускай код пользователям сам, и «никогда не читай .env» - файл с ключами и паролями.

В конце октября я проверил, что из этого держится на деле. Из 62 правил для агента 38 держались только текстом, запретов в настройках - 0. А в локальных настройках лежало 10 разрешений, которые прямо противоречили CLAUDE.md: push в main, сброс правок через reset и другие. Текст запрещает, настройка пускает без вопроса - как записка «не открывать» на шкафчике, в замке которого торчит ключ.

Цена тоже нашлась. В выборке из 20 исправлений 8 чинили то, что сломала предыдущая правка. И 1 выпуск из 22 ушёл без полной проверки: это было моё решение, и технически его ничто не остановило.

Anthropic перестала спрашивать, прочитал ли человек код, и задала другой вопрос

Ревью кода - это когда твою правку читает кто-то ещё, прежде чем её принять. Оно всегда делало две работы: ловило проблемы до выпуска и давало команде понимать, что творится в коде. В монорепозитории Anthropic в мае было около 2 500 изменений в день, в сентябре - больше 30 000. Чтением такое уже не закрыть.

Поэтому вопрос поменяли. Было: «человек прочитал этот код?» Стало: «что может сломаться в этой правке и какая проверка, автоматическая или человек, должна это поймать?» Как учитель, у которого учеников стало в 12 раз больше: каждую тетрадь он уже не прочитает, зато знает, где обычно ошибаются, и ставит туда проверку.

Цель у команды смелая: большинство правок принимается, когда на них посмотрел максимум 1 человек, и этим человеком может быть сам автор. Ограничитель - откаты и поломки у пользователей. Если они растут, время людей никто не сэкономил, его перенесли на потом. Под новый вопрос у них 6 слоёв проверки и быстрый откат под ними. Представь 6 сит одно под другим: что проскочило через одно, застрянет в следующем, а если проскочило через все - есть кнопка «отменить».

Агент пишет «готово». Требуй вывод проверки, и читать код не придётся

Текст (порядок внутри блока менять нельзя: абзацы → блок-промпт → абзац → три блока-примера):

Первый слой у Anthropic - доказательство до ревью. Claude запускает тесты и сборку, снимает скриншоты и вместо «готово» показывает вывод. Потом субагент читает изменения с чистым контекстом: это отдельный помощник, который не видел, как код писался, и поэтому его не защищает. Как с уборкой: сначала фото комнаты, потом заходит человек, который уборку не видел. По словам Бориса Черни, создателя Claude Code, такая проверка делает результат в 2–3 раза лучше.

У меня это шаблон задачи. Строка «Готово, когда» - команда проверки и вывод, который она должна напечатать: как выглядит «готово», мы договариваемся заранее. И агент печатает этот вывод в чат дословно. Почему в чат: у команды /goal есть судья - маленькая модель, которая решает, выполнена ли цель. Файлы она не читает и команды не запускает, видит только разговор. Нет вывода в чате - нечего проверять. А мне хватает сверить одну строку вместо всего кода.

[блок-промпт] метка «в начало задачи»; микрокопия «любая задача агенту · заполни 4 строки»:

Строка «Лимит» важнее, чем кажется: не больше 2 попыток на одну проверку. Откуда она взялась, расскажу в блоке про 50 кругов. Ниже три примера под разный риск правки: обычная правка, интеграция с внешним сервисом и деньги.

[блок-промпт] метка «пример: обычная правка»; микрокопия «уровень FAST · падающий тест, правка, тест после»:

[блок-промпт] метка «пример: интеграция»; микрокопия «уровень STANDARD · целевые тесты и проверка типов»:

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

Нельзя менять: схему базы, ключи доступа и файлы .env.

Готово, когда: команда npm test печатает результат без failed, среди тестов есть два новых — на повторный заказ и на ответ API с ошибкой, а npx tsc --noEmit проходит без ошибок. Напечатай вывод обеих команд в чат дословно.

Лимит: 40 ходов, не больше 2 попыток на одну проверку. Не прошло со 2 раза — остановись и напиши, что мешает.

[блок-промпт] метка «пример: деньги»; микрокопия «уровень RELEASE_CRITICAL · выпуск только с твоего «да»»:

Задача: в price.py итоговая цена товара не может быть ниже себестоимости плюс комиссия маркетплейса. Если расчёт даёт меньше — верни минимальную допустимую цену и пометку «упёрлись в минимум».

Нельзя менять: файлы в data/ и уже существующие тесты.

Готово, когда: команда python3 -m pytest -q печатает строку с passed и без failed, а среди тестов есть новый — на цену ниже себестоимости. Напечатай вывод pytest в чат дословно.

Лимит: 40 ходов, не больше 2 попыток на одну проверку. Не прошло со 2 раза — остановись и напиши, что мешает.

«Готово» без вывода проверки - это мнение агента. Требуй строку вывода, и проверка займёт у тебя секунды.

/code-review есть на любом тарифе, но REVIEW.md она не читает

Второй слой - ИИ-ревью каждой правки, пока человек не смотрел. Несколько агентов параллельно ищут ошибки, потом другая группа голосует по каждой находке, и наружу выходит только то, с чем согласились. Как контрольную проверяют сразу несколько учителей, и в журнал идут только ошибки, с которыми согласны все. Третий слой - отдельное ревью безопасности, этот проверяющий ищет только дыры. В репозиториях Anthropic правку не принимают, пока открыта хоть одна находка любого из двух ревью.

Публичная версия второго слоя - сервис Code Review: он сам проверяет каждую правку на GitHub. Он только для тарифов Team и Enterprise и никогда не одобряет и не блокирует изменение, решение остаётся за людьми. На любом тарифе есть команда /code-review прямо в сессии Claude Code. Она идёт отдельным субагентом со своим контекстом, смотрит на код свежим взглядом и не засоряет разговор.

Тонкость, на которой все спотыкаются: файл REVIEW.md из поста Anthropic читает только сервис на GitHub. Локальная /code-review следует CLAUDE.md, поэтому правила ревью пишем туда. Что писать: что важно именно в твоём проекте (деньги, чужие данные, ключи) и потолок на мелочи. Иначе ревью тонет в придирках к стилю и к коду, который был до правки, - как учитель, который снижает оценку за почерк.

[блок-промпт] метка «в Claude Code, в корне проекта»; микрокопия «один раз на проект · дописывает раздел в CLAUDE.md»:

Находки приходят списком: файл, строка, одно предложение. Хочешь, чтобы Claude сразу их исправил, - та же команда с флагом --fix. Перед выпуском добавь /security-review, это и есть третий слой.

Каждое «НИКОГДА» капсом либо удали, либо преврати в замок

Дальше у Anthropic правило, которое я считаю главным: повторяющуюся находку чинят у источника. Лужу каждый день не вытирают, чинят кран. CLAUDE.md держат коротким (стек, договорённости, цели), а что важно на ревью, пишут отдельно.

Источник у меня сидел в CLAUDE.md. Правило простое: пройди по файлу и найди всё, что написано капсом. Каждое такое правило - одно из двух. Либо Claude и так это делает, и строку можно удалить. Либо это не должно случиться никогда, и тогда ему место в hook. Hook - это проверка, которая срабатывает перед командой агента всегда, что бы модель ни решила. Запрет из hook держится в любом режиме, даже с флагом, который отключает все вопросы о разрешениях.

Промпт ниже делает это за тебя: раскладывает правила на группы, пишет hooks с отказом или вопросом и тест к каждому. То, что по команде не проверить, остаётся текстом, только без капса.

[блок-промпт] метка «в Claude Code, в корне проекта»; микрокопия «один раз на проект · в конце таблица «правило → hook или текст» и прогон тестов»:

Проверь сразу: попроси агента выполнить cat .env. Правильный ответ - отказ с причиной, содержимого файла в чате быть не должно. Если hook начал резать нормальную работу, его не снимают: сужают правило и добавляют тест на этот случай (как - в блоке про журнал).

8 опасных команд, которые агент больше не выполнит, и тесты, которые это доказывают

Текст (порядок внутри блока менять нельзя: абзацы → главный визуал → абзац → блок-промпт):

Из 38 текстовых правил у меня 20 можно было проверить по самой команде, которую запускает агент. Они и стали 16 правилами-проверками. Опасное блокируется сразу: обход проверок перед коммитом, git stash (спрятать правки), git reset --hard (стереть несохранённое), force-push (переписать историю на сервере), git add без списка файлов и чтение .env с ключами. Спорное спрашивает меня: выпуск в main, новая ветка, правка самих защит.

Проверил вживую: попросил агента спрятать мои правки через git stash. Команда даже не запустилась, в ответе - номер правила H-02 и причина. И агент обход не ищет: в сообщении правила сказано сообщить мне. Вот она, разница между запиской и замком.

У каждой защиты должен быть тест: команды, которые правило обязано остановить, и похожие, которые оно обязано пропустить. Свой ключ должен открывать, чужой - нет. Без теста hook начнёт резать нормальную работу, и ты его снимешь. У меня таких тестов 116, упавших - 0.

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

[блок-промпт] метка «в Claude Code, в корне проекта»; микрокопия «после промпта «НИКОГДА → hooks» или вместо него · в конце число тестов и упавших»:

Поставь в этом проекте 8 запретов для Claude Code.

Как: PreToolUse hook на Bash, скрипт в .claude/hooks/, регистрация в .claude/settings.json. Проверяй каждую часть составной команды: после &&, ;, | и внутри bash -c. На запрещённую команду — отказ с номером правила и причиной, в конце сообщения: «Не переформулируй команду и не ищи обход: сообщи мне, я выполню её сам».

Запреты:

З-1. Обход проверок коммита: --no-verify, -n у git commit, смена core.hooksPath. Читать core.hooksPath можно.

З-2. Любой git stash: прячет мои незакоммиченные правки.

З-3. git reset --hard: стирает несохранённое.

З-4. git rebase: переписывает историю.

З-5. git push --force, --force-with-lease и push с плюсом перед веткой: переписывают историю на сервере.

З-6. git add -A, git add . и git add -u: в коммит уходит всё подряд.

З-7. git commit -a и git commit без списка файлов: коммит только своих путей через -- <пути>.

З-8. Чтение .env и .env.* любыми командами: cat, grep, source, cp. Файлы .env.example читать можно.

Тесты — отдельный скрипт в .claude/hooks/, запуск одной командой. Для каждого запрета минимум 2 команды, которые он обязан остановить, и 2 похожие, которые обязан пропустить. Обязательно:

остановить — git commit --no-verify -m "x" -- src/a.js; git stash; cd src && git stash pop; git reset --hard HEAD~1; git rebase main; git push --force origin dev; git add -A; git add .; git commit -am "x"; git commit -m "x"; cat .env; grep KEY .env.local

пропустить — git commit -m "x" -- src/a.js; git status; echo "не делай git stash"; git diff; git log --oneline; git push origin dev; git add src/a.js; cat .env.example; git config --get core.hooksPath

Каждое срабатывание пиши строкой в .claude/hooks/journal.tsv: время, правило, решение — без текста команды.

В конце запусти тесты и напечатай в чат, сколько случаев проверено и сколько упало.

Сколько проверок нужно правке, решает то, что она задевает

Справедливый вопрос: кто тогда решает, что правку можно выпускать? Отвечаю: сама правка. У Anthropic это четвёртый и пятый слои. Четвёртый - скучные обязательные проверки, через которые проходят все, как рамка в аэропорту: стиль, типы, тесты, сборка. Пятый - человек по уровню риска. Как в ремонте: лампочку меняешь сам, а в электрощиток без второй пары глаз не лезешь. Документы, тексты и новое за флагом, которое пользователи пока не видят, принимаются без людей, когда автоматика зелёная. Обычная работа - 1 человек. Самый рискованный код - 2.

К этому 5 правил. Уровень задаёт само изменение: правку читает классификатор, программа, которая сама определяет риск. Лёгкий путь - только доверенным авторам. Одобрение агента никогда не считается за человека. Кто ставил задачу агенту, тот и отвечает за изменение. И одобрение действует на 1 коммит: новый коммит - одобрять заново.

Шестой слой у Anthropic - очередь слияния и флаги. Очереди у меня нет, в боевую версию выпускаю я один. Зато есть замок. Раньше выпуск держался только на тексте правила: одна команда push, и код уходит пользователям, даже если проверка не прошла. Теперь push в main проходит, только если для этого же кода есть файл-доказательство зелёной проверки, и Claude Code ещё спрашивает меня. Если мне нужно выпустить без зелёной проверки, это моё действие, в моём терминале, с записью исключения. Замок держится вместе с запретом З-1: без него агент обошёл бы проверку перед отправкой флагом --no-verify.

[блок-промпт] метка «в Claude Code, в корне проекта»; микрокопия «один раз на проект · выпуск в main только с зелёной проверкой и твоим «да»»:

Одна правка за ночь прошла больше 50 кругов проверки, и 59% находок были старым кодом

Круг - это когда ИИ проверил, агент исправил, и снова проверка. Одно изменение в Claude Code за ночь прошло больше 50 кругов ИИ-ревью и исправлений, пока автор утром это не остановил. Посмотрели историю строк: около 59% того, что ревьюер раз за разом отмечал, было кодом, который лежал там с самого первого прохода.

Новых ошибок ревьюер не находил, он каждый круг находил ещё немного старых. Как мыть пол, когда тебе каждый раз показывают ещё одно пятно, которое было до тебя. Человек отмахивается от такой придирки за 2 секунды. Агент старается и чинит, а это новый коммит, новое ревью, новый круг.

Исправили лимитом. После 3 кругов ревьюер просит автора остановиться и пересмотреть подход. Дальше проверяется только новая правка, ошибка отмечается целым классом («везде, где так сделано»), и находка не повторяется. А прошлые правки, из-за которых случались инциденты, собрали в набор и гоняют по нему ревьюера, как экзамен из прошлых ошибок: стал он лучше или хуже.

Отсюда строка в моём шаблоне задачи: не больше 2 попыток на одну проверку и 40 ходов на всю задачу. Не прошло со 2 раза - агент останавливается и пишет, что мешает, и не жжёт лимит подписки по кругу.

Ставь лимит попыток в каждую задачу. Две неудачи подряд - повод менять подход, и пусть агент сам напишет, что мешает.

Рубильника нет даже у Anthropic. У меня вместо него журнал

Есть следующий шаг, которого пока нет даже у Anthropic, - рубильник: при росте откатов система сама ужесточает одобрение. Как на конвейере: брак на одном участке, и линия замедляется, пока не испортила всю партию. Автоматического рубильника нет и у меня. Зато есть журнал: каждое срабатывание защиты пишется строкой - время, правило, решение, без текста команды.

Раз в неделю я размечаю каждое срабатывание: по делу или ложное. Ложное - сужаю правило с тестом, защиту не снимаю. Порог: больше 1 ложной блокировки на 10 задач - правило переписывается. В первый же день журнал показал правило, которое спрашивало подтверждение на простое чтение настроек. Поправил в тот же день, с тестом.

[блок-промпт] метка «в терминале, в корне проекта»; микрокопия «сколько раз сработало каждое правило и с каким решением»:

cut -f2,3 .claude/hooks/journal.tsv | sort | uniq -c

[блок-промпт] метка «в Claude Code, раз в неделю»; микрокопия «разбор журнала · защиты не ослабляет»:

Свожу всё в одну таблицу, чтобы было видно, что поменялось.

116 тестов - цифра красивая, но она меряет сами защиты. Мерить надо откаты: до замков 8 исправлений из 20 чинили прошлую правку, и сколько их станет после, покажет конец пилота. Очереди слияния и рубильника у меня нет, выпускаю я один.

Три отговорки, из-за которых замки так и не ставят

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

Сообщение карточек: у каждой отговорки есть ответ фактом из работающего проекта.

Открой Claude Code и поставь первый замок сегодня вечером

Ты уже держишь все шесть слоёв в руках: шаблон задачи, раздел «Ревью», промпт для капса, 8 запретов, уровни риска и замок на main лежат выше. Осталось поставить их по порядку, и в одиночку это пять шагов.

Если совсем коротко: записки в CLAUDE.md меняем на замки, а слово «готово» - на вывод проверки. И считай откаты: если они растут, время ты просто перенёс на потом.

Сегодня мы поставили агентам замки: они доказывают работу, не обходят запреты и не выпускают код без человека. Следующий шаг - зарабатывать на таких системах. Об этом мой мастер-класс «Деньги на ИИ-системе»: что в своём деле имеет смысл автоматизировать, как собрать систему, за которую платит заказчик, кто проверяет результат и когда заказное решение становится продуктом. Мастер-класс бесплатный и проходит в Telegram.

И один вопрос. Напиши под видео одним предложением, какое «НИКОГДА» из своего CLAUDE.md ты первым превратишь в замок. Я читаю.