Настройка Code Review

Настройте, что Code Review отмечает в ваших pull request, с помощью REVIEW.md и CLAUDE.md: перекалибруйте серьёзность, исключите пути, добавьте проверки и узнайте, какая копия применяется.

Вы можете изменить, что Code Review отмечает в вашем репозитории, закоммитив в него инструкции. Так можно сократить количество мелких замечаний, отключить комментарии к сгенерированным файлам или добавить правило, важное для вашей команды. Поместите их в один из двух файлов:

• CLAUDE.md: инструкции проекта, которые Claude Code читает для каждой задачи, включая ревью. Code Review читает их как контекст проекта и отмечает изменения, которые их нарушают.
• REVIEW.md: инструкции только для ревью. Используйте его, чтобы указать, что ваша команда хочет отмечать, с какой серьёзностью и что пропускать.

Добавьте REVIEW.md в корень репозитория и выполните слияние. Затем защитите ветку по умолчанию.

[!NOTE]

Чтобы изменить тщательность ревью или момент их запуска, попросите Owner изменить уровень ревью или настройку Review runs.

Используйте CLAUDE.md для правил всего проекта

Code Review читает файлы CLAUDE.md вашего репозитория как контекст проекта. Изменение, нарушающее одно из их правил, становится замечанием с тем уровнем серьёзности, который соответствует проблеме.

Ревью читает CLAUDE.md в корне репозитория и файлы CLAUDE.md в родительских каталогах каждого изменённого файла. CLAUDE.md подкаталога читается, когда pull request изменяет файл по этому пути.

Используйте REVIEW.md для правил, относящихся только к ревью

REVIEW.md — это файл в корне репозитория, который адаптирует Code Review к вашему репозиторию. Вы также можете добавить REVIEW.md в подкаталог, чтобы добавить проверки для изменений по этому пути в дополнение к корневому файлу.

Агенты, которые находят проблемы, и агенты, которые их проверяют, получают его содержимое как инструкции ревью вашего репозитория вместе со стандартными рекомендациями Code Review. Этап, на котором пишется итоговое ревью, обращается к нему, прежде чем определить серьёзность и написать сводку.

В этом примере структуры есть корневой файл и один файл в подкаталоге:

your-repo/
├── REVIEW.md            # Root file
├── services/
│   └── billing/
│       └── REVIEW.md    # Adds checks for changes under services/billing/
└── src/

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

[!NOTE]

Сервис Code Review и локальная команда /code-review — это два отдельных инструмента, и они читают разные файлы. Сервис читает и CLAUDE.md, и REVIEW.md. Команда /code-review, которую вы запускаете в сессии Claude Code на своём компьютере, читает ваши файлы CLAUDE.md, но не REVIEW.md. Указания, которые должны применяться в обоих местах, помещайте в CLAUDE.md, а REVIEW.md оставьте для правил, специфичных для ревью pull request.

Пример REVIEW.md

Этот REVIEW.md перекалибровывает серьёзность для бэкенд-сервиса, ограничивает количество мелких замечаний, пропускает сгенерированные файлы и добавляет проверки, специфичные для репозитория.

# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review.

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant

Выбор содержимого REVIEW.md

REVIEW.md — это Markdown в свободной форме, который изменяет то, что ревью находит и сообщает. Он не меняет формат ревью. Найдите проблему, с которой вы столкнулись, и добавьте инструкцию, подобную показанной. В примере используются первые четыре.

• Не то помечается как Important: переопределите, что означает 🔴 Important для вашего репозитория. Калибровка по умолчанию ориентирована на production-код, а для репозитория документации, репозитория конфигурации или прототипа может потребоваться гораздо более узкое определение. Укажите, какие классы замечаний являются Important, а какие — максимум Nit. Можно также повышать серьёзность, например считать любое нарушение CLAUDE.md как Important.
• Слишком много мелких замечаний: ограничьте количество комментариев 🟡 Nit, которые публикует одно ревью. Ограничение вроде «сообщать не более пяти мелких замечаний» сохраняет ревью практичными.
• Комментарии к сгенерированным файлам или к тому, что уже проверяет CI: перечислите пути и категории замечаний, для которых Claude должен пропускать замечания. Типичные кандидаты — сгенерированный код, lock-файлы и вендорные зависимости, а также всё, что уже обеспечивает ваш CI, например линтинг или проверка орфографии. Для путей, которые требуют некоторого ревью, но не полного анализа, задайте более высокую планку: «в scripts/ сообщать только о почти несомненных и серьёзных проблемах».
• Правило команды не проверяется: добавьте правила, которые должны отмечаться в каждом pull request, например «новые маршруты API должны иметь интеграционный тест».
• Замечания оказываются ошибочными: требуйте доказательств перед публикацией определённого класса замечаний. Например, «утверждения о поведении требуют ссылки file:line в исходном коде, а не вывода из названий» сокращает ложные срабатывания, которые иначе стоили бы автору лишнего цикла.

Некоторым из этих инструкций требуется корневой файл в защищённой ветке по умолчанию.

Оставляйте в REVIEW.md только инструкции, изменяющие поведение ревью, а общий контекст проекта — в CLAUDE.md.

Включение других файлов в REVIEW.md

Вы можете разделить инструкции ревью на несколько файлов и подключить их в корневой REVIEW.md. Используйте это, когда REVIEW.md становится слишком длинным или когда вы уже храните правила ревью в другом файле.

Чтобы включить файл, добавьте в корневой REVIEW.md строку, содержащую только @ и имя файла. Code Review подставляет содержимое файла вместо этой строки, поэтому оно применяется как часть REVIEW.md. В этом примере корневой файл даёт одну собственную инструкцию, а затем включает два файла с правилами:

# Review instructions

Report at most five Nits per review.

@review-security.md
@review-api.md

Сохраните включаемые файлы в корне репозитория рядом с REVIEW.md:

your-repo/
├── REVIEW.md
├── review-security.md
└── review-api.md

Code Review включает файлы, когда читает REVIEW.md из защищённой ветки, поэтому проверьте, какую ветку читает ревью для вашего репозитория:

• Защищённая ветка: Code Review подставляет включаемый файл вместо его строки @
• Незащищённая ветка по умолчанию: строка @ остаётся в REVIEW.md как обычный текст. Если pull request изменяет файл, указанный в строке, строка опускается.

Если ревью не применяет включаемый файл, проверьте каждый из следующих пунктов:

• Расположение: переместите файл в корень репозитория. Путь в подкаталог, например @docs/review-rules.md, не включается.
• Имя: указывайте имя файла точно, с учётом регистра, и используйте имя без пробелов. Строка, имя в которой не совпадает ни с одним файлом рядом с REVIEW.md, остаётся в REVIEW.md как обычный текст, и check run не сообщает о ней как о пропущенном включении.
• Один уровень: перечислите все файлы в корневом REVIEW.md. Строка @ во включаемом файле или в REVIEW.md подкаталога остаётся обычным текстом, а ссылка Markdown на другой файл не является включением.
• Ограничения: включайте не более восьми разных файлов, а общий размер REVIEW.md и включаемых им файлов должен быть меньше 150 000 байт. Файл, который достиг бы ограничения по байтам, пропускается целиком, а не обрезается. Check run сообщает, сколько строк включения было пропущено из-за каждого из ограничений.
• Ссылки: общее количество ссылок Markdown в REVIEW.md и включаемых им файлах должно быть не более 64. Ссылки на адреса http, https или mailto и на якоря # не учитываются. При превышении этого ограничения ревью пропускает весь ваш корневой REVIEW.md, а не только включаемые файлы. В этом случае check run сообщает, что инструкции не были применены.
• Копия после слияния: выполните слияние включаемого файла в ветку, из которой читается REVIEW.md. Ревью читает оба файла из одного и того же коммита, но никогда из изменений самого pull request.

Из какой ветки читается REVIEW.md

Code Review читает REVIEW.md из базовой ветки pull request или из ветки по умолчанию, но никогда из изменений самого pull request. Чтобы изменить поведение ревью, сначала выполните слияние изменения REVIEW.md.

Храните REVIEW.md в ветке по умолчанию и защитите эту ветку. Когда ревью читает копию из защищённой ветки по умолчанию (первая строка таблицы ниже), оно соблюдает следующие инструкции из корневого файла:

• Понижение серьёзности замечания
• Исключение путей, файлов или классов проблем
• Ограничение количества мелких замечаний

Что считается защитой ветки

Code Review считает защитой следующие настройки:

• Ветка по умолчанию: классическое правило защиты ветки или ruleset
• Любая другая ветка: только ruleset

Ruleset засчитывается, если он ограничивает обновления или требует pull request как минимум с одним одобрением. Если он требует pull request, он также должен отзывать это одобрение при новом push или требовать, чтобы одобрение было получено после последнего push.

Что читает ревью при каждой настройке веток

Найдите ситуацию вашего репозитория в первом столбце таблицы ниже.

Если в check run упоминается REVIEW.md, см. The check run mentions REVIEW.md.

Связанные ресурсы

• Code Review: что представляет собой сервис и как выполняется ревью
• Чтение и запрос ревью в pull request: что означает каждый уровень серьёзности и как отображаются замечания
• Настройка Code Review: уровень ревью и момент запуска ревью, которые задаёт Owner
• Локальное ревью с помощью /code-review: команда /code-review, её аргументы и уровни effort
• Память: как работают файлы CLAUDE.md в Claude Code