code-reviewer - Ревью изменений кода перед слиянием

Когда звать

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

Для чего подключать Code Reviewer

Code Reviewer задаёт агенту последовательность чтения изменений и формат обратной связи. Он охватывает корректность, архитектуру, производительность, безопасность и тесты в одном обзоре. В прочитанном SKILL.md указана версия 1.1.0, а в allowed-tools перечислены Read, Grep и Glob.

Такой набор подходит для чтения файлов и поиска по проекту. Он не означает, что агент сможет автоматически запустить тесты или исправить исходники. В задании нужно отдельно определить, нужен только отчёт или дальнейшая работа будет выполняться другим агентом с разрешёнными инструментами.

Сначала цель изменения

Рабочий процесс начинается с описания pull request и задачи, которую он решает. Автор требует пересказать цель одним предложением до перехода к деталям. Если смысл неясен, нужно получить уточнение. Ревью без понимания причины изменения прямо запрещено.

Далее агент оценивает структуру: соблюдены ли существующие правила проекта и оправданы ли новые абстракции. После этого проверяет детали, включая N+1, секреты и риски инъекций. Тесты рассматриваются отдельным этапом и должны изучаться так же внимательно, как реализация.

В примере N+1 автор показывает запрос заказов внутри цикла пользователей и вариант предварительной загрузки связанных данных. Ещё один пример заменяет необъяснённое число именованной константой. Такие фрагменты поясняют направление замечания, но не доказывают наличие проблемы в любом похожем цикле.

Какие замечания считать обязательными

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

Автор требует конкретных предложений с примерами кода. Нельзя блокировать изменение из-за личного вкуса, особенно если форматирование уже задаёт линтер. Если разработчик объяснил необычное решение, его довод нужно учесть до предложения замены.

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

Пример задачи на первый обзор

Можно дать запрос: «Проверьте diff обработчика и связанные тесты. Сначала сформулируйте цель. Для каждой проблемы укажите место, условие ошибки и минимальную правку. Не меняйте файлы, не выдавайте замечания по форматированию за препятствие слиянию». Для результата нужно предоставить сам diff и достаточный контекст вокруг него.

По шаблону автора в отчёте должны быть резюме, три уровня замечаний, положительные наблюдения, вопросы и один вердикт: Approve, Request Changes или Comment. Критический риск следует отметить сразу, не ожидая завершения полного обзора.

Справочники по чек-листу, частым ошибкам, обратной связи и соответствию заданию нужно сохранять вместе с основным файлом. В тексте отмечена адаптация части материалов из obra/superpowers по MIT. Мы проверили источники, но не установку или работу в Claude Code и Codex. Узкий защитный обзор описан отдельно в Security Reviewer.