Код-ревью — идеальный кандидат на подагента, и сразу по трём причинам. Во-первых, оно шумное: чтобы дать заключение на пять строк, нужно прочитать дифф, соседние файлы, иногда тесты. Всё это осядет в вашем контексте, если делать ревью в главной беседе. Во-вторых, оно повторяемое: чек-лист от задачи к задаче один и тот же. В-третьих, оно принципиально безопасно ограничиваемо: ревьюер обязан смотреть и говорить, но не чинить.

Последний пункт важнее, чем кажется. Агент с правом на запись, обнаружив проблему, склонен её сразу исправить — и вы получаете вместо списка замечаний непрошеный дифф поверх своего. Ревьюер без Write и Edit такого сделать не может по построению. В этом уроке мы соберём такого агента от frontmatter до системного промпта и проверим на реальном диффе.

Что уже умеем / что добавим

Вы умеете создавать файл подагента, задавать обязательные name и description, ограничивать инструменты через tools и disallowedTools, выбирать модель и подключать скиллы.

Теперь мы применим всё это к одной задаче целиком и разберём то, что в предыдущем уроке осталось за скобками: как подобрать набор инструментов под конкретную работу, как написать системный промпт, дающий воспроизводимый результат, и как отладить агента, если он ведёт себя не так.

Что вы узнаете в рамках статьи

• Как подобрать минимально достаточный набор инструментов для ревьюера
• Почему Bash(git diff:*) лучше, чем полный доступ к Bash
• Как написать системный промпт, дающий стабильный формат ответа
• Как отладить подагента, который делает не то, что вы ожидали
• Как проверить, что ограничения действительно работают

Ключевые термины

• Код-ревью — проверка изменений в коде на корректность, читаемость и соответствие принятым в проекте правилам.
• Дифф — набор изменений между двумя состояниями кода; для агента это основной входной материал.
• Минимально достаточный набор инструментов — принцип: агенту выдаётся ровно то, без чего он не решит задачу, и ничего сверх.
• Системный промпт агента — текст после frontmatter, задающий постоянные инструкции: что делать, на что смотреть, в каком виде отвечать.

Подбираем набор инструментов

Начнём не с промпта, а с прав. Спросим себя: что ревьюеру физически нужно?

Ему нужно увидеть изменения — значит, доступ к git diff. Нужно открыть изменённые файлы целиком, потому что дифф без окружения читается плохо, — значит, Read. Нужно проверить, не используется ли изменённая функция где-то ещё, — значит, Grep и Glob.

Чего ему не нужно: Write, Edit, установка пакетов, запуск деплоя, сетевые запросы.

Заметьте важный нюанс с Bash. Ревьюеру нужна одна команда — git diff. Но выдать ему Bash целиком означает выдать всё: и rm, и git push, и что угодно ещё. Поэтому инструмент лучше сузить до конкретного шаблона команды.

tools: Read, Grep, Glob, Bash(git diff:*), Bash(git log:*)

Такая запись оставляет агенту ровно то, что нужно для чтения истории и изменений.

Собираем файл агента

Создайте файл .claude/agents/code-reviewer.md. Проектный scope выбран сознательно: ревьюер отражает договорённости команды, поэтому логично держать его в репозитории и коммитить вместе с кодом.

---
name: code-reviewer
description: Проверяет изменения в коде на корректность, читаемость и соблюдение правил проекта. Вызывайте после внесения правок, перед коммитом или созданием pull request.
tools: Read, Grep, Glob, Bash(git diff:*), Bash(git log:*)
model: sonnet
color: yellow
---

Вы — внимательный ревьюер кода. Ваша задача — найти проблемы и объяснить их,
а не исправлять. Вы не изменяете файлы ни при каких обстоятельствах.

Порядок работы:

1. Получите изменения командой `git diff`. Если изменений нет, скажите об этом
   и завершите работу.
2. Прочитайте каждый изменённый файл целиком: дифф без окружающего кода
   вводит в заблуждение.
3. Для каждой изменённой функции проверьте через Grep, где она вызывается,
   и не сломает ли изменение вызывающий код.

На что смотреть, в порядке убывания важности:

- Корректность: необработанные ошибки, краевые случаи, потерянные await,
  обращение к возможному null.
- Безопасность: секреты в коде, неэкранированный пользовательский ввод,
  конкатенация SQL-запросов.
- Читаемость: непонятные имена, дублирование, функции длиннее экрана.
- Соответствие проекту: расхождение со стилем соседних файлов.

Формат ответа — ровно такой:

## Критично
Проблемы, из-за которых нельзя мержить. Для каждой: файл, строка, суть, как чинить.

## Стоит поправить
Существенное, но не блокирующее.

## На ваше усмотрение
Замечания по вкусу.

Если в какой-то категории пусто, напишите «нет замечаний». Не выдумывайте
проблемы ради заполнения разделов. Уложитесь в 400 слов.

Разберём решения, принятые в этом файле.

Описание. В нём есть не только «что делает», но и «когда вызывать»: после правок, перед коммитом. Именно по этой фразе Claude поймёт, что пора делегировать.

Запрет на правки записан дважды. Он реализован технически — Write и Edit нет в tools — и продублирован в промпте. Технический запрет надёжнее, текстовый избавляет агента от попыток, которые всё равно упрутся в ошибку.

Порядок работы задан по шагам. Без этого агент может ограничиться диффом и не заметить, что изменённая функция вызывается в трёх других местах.

Формат ответа зафиксирован. Разделы с приоритетами позволяют читать вывод по диагонали: посмотрели «Критично» — если пусто, дальше можно не вчитываться.

Ограничение по объёму. Помните, что результат подагента возвращается в вашу беседу и занимает контекст. Ревью на две тысячи слов противоречит смыслу делегирования.

Запускаем и отлаживаем

Проверка проще всего на реальных изменениях:

# Внесите правку в любой файл проекта
git status

# В сессии Claude Code:
# Используй подагента code-reviewer, чтобы проверить мои текущие изменения

Типичные проблемы и что с ними делать.

Агент не вызывается сам. Claude выбирает агента по полю description. Уточните его, добавив условия вызова. И помните: вызвать агента явно по имени можно всегда.

Агент не запустился и сообщил об инструментах. Если ни одна запись в tools не распознана, подагент обычно не стартует, а ошибка называет непонятые записи. Проверьте написание имён — они регистрозависимы.

Файл вообще не подхватился. Молча пропускаются файлы без name, без description, с открывающим --- не на первой строке, с двоеточием или ведущим дефисом в name, а также с невалидным YAML. Запустите Claude Code с --debug, чтобы увидеть причину.

Ответ слишком длинный или бесформенный. Это лечится промптом: жёстче зафиксируйте структуру и предел объёма.

Отдельно стоит проверить сами ограничения. Попросите агента исправить найденную проблему — он должен ответить, что не может менять файлы. Это и есть подтверждение того, что права настроены верно.

Частые ошибки

• Выдать ревьюеру Write и Edit «на всякий случай». Агент начнёт чинить вместо того, чтобы докладывать, и вы получите чужой дифф поверх своего.
• Открыть полный доступ к Bash ради одной команды. Сузьте до шаблона вроде Bash(git diff:*) — этого достаточно для работы и несравнимо безопаснее.
• Не задать формат ответа. Без явной структуры вывод будет разным от запуска к запуску, и сравнивать результаты станет невозможно.
• Не ограничить объём отчёта. Результат подагента возвращается в вашу беседу; многословное ревью съедает контекст, который вы хотели сэкономить.

Наиболее частые вопросы

• Почему запрет на правки записан и в tools, и в промпте? — Технический запрет надёжен, текстовый экономит время: агент не пытается сделать невозможное.
• Где лучше держать ревьюера: в проекте или в ~/.claude/agents/? — В проекте, если он отражает договорённости команды. В личном каталоге — если это ваш индивидуальный чек-лист.
• Как передать агенту стандарты кодирования команды? — Через поле skills: содержимое перечисленных скиллов подгружается в его контекст целиком.
• Агент вызывается не тогда, когда нужно. Что делать? — Переписать description, добавив явные условия вызова, или обращаться к агенту по имени.
• Почему созданный файл агента не появился? — Возможных причин несколько: нет name или description, -- не на первой строке, двоеточие в имени, битый YAML. Флаг -debug покажет точную.

Итоги

Отличный результат — вы собрали своего первого рабочего подагента целиком, от прав до формата вывода. Это уже не учебное упражнение: такой ревьюер экономит время на каждом коммите и делает проверку одинаковой независимо от того, насколько вы устали к концу дня.

Главное, что вы отработали здесь, — мышление от ограничений. Вы начали не с промпта, а с вопроса «что этому агенту физически нужно», и сузили Bash до конкретных команд вместо того, чтобы выдать его целиком. Этот подход переносится на любого следующего агента. В следующем уроке мы разберём противоположный случай: форк сессии через /subtask, когда подагенту нужен не чистый контекст, а наоборот — вся ваша беседа целиком.