Настройка 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.

Включение файла скилла

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

Добавьте @ и путь к SKILL.md в формате .claude/skills/<folder>/SKILL.md на отдельной строке:

# Review instructions

Report at most five Nits per review.

@.claude/skills/api-review/SKILL.md

Treat any change under `migrations/` as Important.

Защитите ветку, из которой читается REVIEW.md, поскольку Code Review включает файл скилла, только когда читает REVIEW.md из защищённой ветки. Файл скилла учитывается в ограничениях в восемь файлов и 150 000 байт, а также имеет собственное ограничение в 30 000 байт.

Напишите строку скилла, которую Code Review включит

Используйте имя папки без пробелов. Строка с пробелом в пути остаётся в REVIEW.md как обычный текст, и check run не сообщает о ней как о пропущенном включении.

Если строка @ для скилла нарушает одно из приведённых ниже правил, Code Review не включает скилл из этой строки:

• Путь: указывайте путь в виде .claude/skills/<folder>/SKILL.md от корня репозитория, при этом папка скилла должна находиться непосредственно в skills/. В отличие от имени файла в корне, путь такого вида, не совпадающий ни с одним файлом, пропускается и учитывается.
• Источник: скопируйте указания из любого другого файла в .claude/ или из встроенного, личного скилла или скилла плагина в файл рядом с REVIEW.md. Включить их напрямую нельзя.
• Файл: сделайте коммит SKILL.md как обычного текстового файла. Code Review не переходит по символическим ссылкам, будь то сам файл или папка в его пути.
• Размер: размер SKILL.md должен быть не более 30 000 байт, включая frontmatter
• Количество: пишите не более восьми строк скиллов. Повторяющаяся строка снова учитывается в этих восьми.
• Блоки в REVIEW.md: не размещайте строку @ внутри блоков кода. Закройте все HTML-комментарии и все блоки <pre>, <script>, <style> или <textarea> выше неё.

Когда Code Review пропускает строку скилла из-за нарушения правил «Файл», «Размер», «Количество» или «Блоки», она учитывается в сообщении check run о пропущенных строках включения. Это сообщение появляется, только когда ревью применяет REVIEW.md из защищённой ветки.

Проверьте, что ревью получает из скилла

Когда скилл включён, ревью получает тело SKILL.md и ничего больше из скилла, поэтому проверьте скилл по списку ниже.

• Frontmatter: повторите в теле всё, что нужно ревью из frontmatter, например условия использования скилла, указанные в description
• Внедряемые команды: распишите то, что предоставила бы команда !. Code Review не выполняет команду и заменяет всю строку или блок, где она находится, заполнителем.
• Подстановки: замените $ARGUMENTS и другие подстановки фиксированным текстом, поскольку ревью не передаёт аргументы и оставляет их как есть
• Вспомогательные файлы: скопируйте то, что нужно ревью, в SKILL.md, поскольку Code Review не загружает скрипты, связанные файлы или ссылки @file
• Исключения и ограничения Nit: пишите инструкции, исключающие замечания или ограничивающие количество Nit, в REVIEW.md или в файле рядом с ним, а не в скилле. Code Review не принимает текст скилла как основание ни для того, ни для другого.
• Ссылки на файлы репозитория: опишите словами, на что указывает ссылка или ссылка @file. Ревью видит путь как обычный текст или как заполнитель.

Если вы редактируете команды !, $ARGUMENTS или ссылки скилла, вы также меняете то, как он работает в Claude Code. Если ваша команда на них полагается, скопируйте указания в файл рядом с REVIEW.md и включите этот файл вместо скилла.

Символы, которые Code Review изменяет в тексте скилла

Code Review изменяет некоторые символы в тексте скилла, поэтому ваши примеры кода попадают в ревью в виде, показанном ниже.

In SKILL.md:       Use `items[0]`, never `List<String>`.
The review reads:  Use ˋitems(0)ˋ, never ˋList< String>ˋ.

In SKILL.md:       Run `ps | grep api` and ask @alice.
The review reads:  Run ˋps ¦ grep apiˋ and ask @ alice.

Если правило зависит от одного из этих символов, опишите его также словами.

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

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

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

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

Пишите исключения и ограничения Nit в 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