25 практических промптов для проведения Code Review с помощью Claude Code: от проверки безопасности до архитектурного анализа

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

В Claude Code есть встроенная команда /security-review и мультиагентная система для Code Review, но стандартные ответы часто бывают слишком многословными и перегруженными деталями. Хороший промпт для ревью должен быть точным, как тест-кейс: определять область проверки, задавать приоритеты и требовать указания конкретных строк кода с рекомендациями по исправлению. В этой статье я собрал 25 промптов для 7 сценариев — от безопасности до архитектурного аудита. Каждый из них можно сразу копировать и использовать в работе.

Основная ценность: 25 промптов для самых частых задач Code Review, а также формула их написания и примеры «хорошо/плохо».

Формула написания промптов для Code Review

Хороший промпт для ревью — это как точный тест-кейс. Плохой промпт — как расплывчатое сообщение в Slack.

Формула из пяти элементов

[Роль] С позиции старшего инженера {язык/область}
[Область] Проведи ревью {изменений} в {файле/директории/PR}
[Фокус] Удели особое внимание {безопасности/производительности/логике/архитектуре}
[Формат] Формат вывода: {нумерованный список/таблица/инлайн-комментарии}
[Уровень] Укажи уровень серьезности: {Critical/High/Medium/Low}

Элемент	Плохой пример	Хороший пример
Роль	(не задана)	"С позиции старшего бэкенд-разработчика"
Область	"Посмотри этот код"	"Проверь недавний git diff в src/auth/"
Фокус	"Дай какой-нибудь фидбек"	"Сосредоточься на SQL-инъекциях и обходе аутентификации"
Формат	(как получится)	"Нумерованный список: файл:строка, описание проблемы, совет по исправлению"
Уровень	(не требуется)	"Укажи уровень Critical/High/Medium/Low"

---

Сценарий 1: Проверка безопасности (4 промпта)

Проверка безопасности — это приоритет №1 при Code Review. В Claude Code есть встроенная команда /security-review, но кастомные промпты позволяют копнуть гораздо глубже.

Промпт №1: Полное сканирование по OWASP Top 10

С позиции инженера по безопасности проведи ревью всех файлов, измененных в директории src/.
Проверь их по списку OWASP Top 10:
1. Инъекции (SQL/NoSQL/командные инъекции)
2. Дефекты аутентификации
3. Раскрытие конфиденциальных данных
4. XXE
5. Дефекты контроля доступа
6. Ошибки конфигурации безопасности
7. XSS
8. Небезопасная десериализация
9. Использование компонентов с уязвимостями
10. Недостаточное логирование и мониторинг

Формат вывода: нумерованный список, каждый пункт включает [файл:строка] [уровень серьезности] [описание проблемы] [совет по исправлению].
Сообщай только о реально существующих проблемах, не нужно описывать теоретические риски.

Промпт №2: Проверка безопасности API-эндпоинтов

Проверь все файлы маршрутизации API (routes/, controllers/), уделив внимание следующему:
- Есть ли эндпоинты, где пропущено middleware аутентификации
- Проводится ли валидация и санитайзинг входных параметров
- Есть ли риск массового присвоения (mass assignment)
- Настроены ли лимиты запросов (rate limiting)
- Не раскрывают ли сообщения об ошибках внутреннюю информацию

Выведи таблицу: Путь эндпоинта | Проблема | Уровень серьезности | Решение

Промпт №3: Поиск утечек конфиденциальной информации

Просканируй весь проект и проверь, не были ли случайно захардкожены или раскрыты следующие данные:
- API-ключи, секреты, токены
- Строки подключения к БД
- Приватные ключи и сертификаты
- Внутренние IP и доменные имена
- Пароли или учетные данные в комментариях

Область проверки включает: исходный код, конфигурационные файлы, .env.example, docker-compose.yml, README.
Укажи путь к файлу и номер строки для каждой находки.

Промпт №4: Проверка логики аутентификации и авторизации

С позиции эксперта по безопасности проверь код, отвечающий за аутентификацию и авторизацию:
1. Полная ли логика проверки JWT-токенов (срок действия, подпись, защита от подмены)
2. Используется ли безопасное хеширование для хранения паролей (bcrypt/argon2)
3. Есть ли риск атаки с фиксацией сессии (Session Fixation)
4. Не слишком ли мягкая конфигурация CORS
5. Проверяется ли параметр state в колбэках OAuth

Сообщай только о проблемах уровней Critical и High, приложи пример исправленного кода.

Сценарий 2: Поиск багов (4 промпта)

Промпт №5: Нулевые указатели и граничные условия

Проанализируй измененные файлы на предмет потенциальных багов:
- Обращение к свойствам без проверки на null/undefined
- Выход за границы массива
- Ошибки деления на ноль
- Необработанные пустые строки
- Необработанные NaN при использовании parseInt/parseFloat

Для каждой находки укажи условия возникновения (какой ввод приведет к сбою) и предложи исправленный код.

Промпт №6: Асинхронность и конкурентность

Проверь весь асинхронный код в проекте (async/await, Promise, колбэки) на наличие:
- Promise без обработки ошибок через .catch()
- Состояний гонки (race condition)
- Последовательного выполнения в цикле через await (следует использовать Promise.all)
- Callback hell, который можно отрефакторить
- Корректности отката транзакций

Оформи отчет в виде: [Файл:Строка] [Проблема] [Влияние] [Решение]

Промпт №7: Охотник за логическими ошибками

Внимательно изучи бизнес-логику следующих функций и найди:
- Покрывают ли все случаи ветки if/else
- Корректны ли условия завершения циклов
- Правильно ли используются операторы сравнения (== vs ===, > vs >=)
- Верна ли область видимости переменных
- Определены ли возвращаемые значения для всех путей выполнения

Не обращай внимания на стиль кода, сфокусируйся только на логической корректности.

Промпт №8: Проверка обработки ошибок

Проверь механизм обработки ошибок в проекте:
1. Перехватываются ли конкретные исключения, а не общий класс Error?
2. Не «проглатываются» ли ошибки в блоках catch (пустые catch)?
3. Корректно ли ошибки передаются на верхний уровень?
4. Понятны ли пользователю сообщения об ошибках (не раскрывают ли они внутреннюю информацию)?
5. Есть ли механизмы отката для критических операций (платежи, изменение данных)?

Отсортируй результаты по степени критичности.

---

Сценарий 3: Анализ производительности (3 промпта)

Промпт №9: Производительность SQL-запросов

Проверь код запросов к базе данных (models/, repositories/, вызовы ORM) на наличие:
- Проблемы N+1 (запросы внутри циклов)
- Полей, по которым нет индексов
- Использования SELECT *, которое лучше заменить на конкретные поля
- Отсутствия пагинации при выборке больших объемов данных
- Повторяющихся запросов, которые можно оптимизировать кэшированием

Для каждой проблемы оцени влияние на производительность (низкое/среднее/высокое) и предложи оптимизированный код.

Промпт №10: Утечки памяти и ресурсов

Проверь проект на возможные утечки памяти и ресурсов:
- Удаляются ли обработчики событий при размонтировании компонентов?
- Очищаются ли таймеры (setInterval/setTimeout)?
- Корректно ли закрываются соединения с БД?
- Освобождаются ли файловые дескрипторы в блоке finally?
- Удаляются ли ссылки на большие массивы/объекты после использования?

Удели особое внимание очистке useEffect в React-компонентах и потокам (streams) в Node.js.

Промпт №11: Анализ алгоритмической сложности

Проанализируй недавно измененные функции на предмет временной и пространственной сложности:
- Есть ли реализации с O(n²) или выше, которые можно оптимизировать?
- Можно ли заменить линейный поиск на хеш-таблицу?
- Нет ли избыточного глубокого копирования объектов?
- Стоит ли заменить конкатенацию строк на StringBuilder/join?
- Используются ли подходящие алгоритмы сортировки?

Укажи: текущая сложность → целевая сложность → конкретный план оптимизации.

Сценарий 4: Архитектурный обзор (4 промпта)

Промпт #12: Анализ зависимостей и связанности

Проанализируй зависимости модулей в src/:
1. Построй граф зависимостей между модулями (какой модуль импортирует какие модули)
2. Найди циклические зависимости
3. Выяви модули с наибольшей связанностью (от которых зависит больше всего других модулей)
4. Предложи, какие зависимости стоит развязать через интерфейсы/абстракции

Вывод: таблица зависимостей + список циклических зависимостей + рекомендации по декомпозиции.

Промпт #13: Проверка соответствия многоуровневой архитектуре

Проверь, следует ли код принципам многоуровневой архитектуры:
- Содержит ли уровень Controller бизнес-логику (должен заниматься только маршрутизацией и валидацией параметров)
- Работает ли уровень Service напрямую с базой данных (должен через Repository)
- Содержит ли уровень Model/Entity логику, связанную с HTTP
- Есть ли вызовы через уровень (например, Controller напрямую вызывает Repository)

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

Промпт #14: Обзор дизайна API

Проведи аудит всех API-эндпоинтов с точки зрения лучших практик RESTful API:
- Соответствуют ли имена URL соглашениям REST (существительные во множественном числе, иерархические отношения)
- Правильно ли используются методы HTTP (GET — только чтение, POST — создание, PUT — обновление, DELETE — удаление)
- Согласован ли формат ответов (коды ошибок, формат пагинации, формат времени)
- Реализовано ли версионирование API
- Есть ли избыточные эндпоинты, которые можно объединить

Вывод: таблица рекомендаций по улучшению (текущее состояние → предложение → причина).

Промпт #15: Оценка технического долга

Проведи комплексную оценку технического долга проекта:
1. Устаревшие зависимости и версии фреймворков
2. Устаревшие (deprecated) вызовы API
3. Хардкод конфигурационных значений (которые должны быть в переменных окружения)
4. Дублирующиеся блоки кода (copy-paste)
5. Ключевые модули без модульных тестов
6. Чрезмерно сложные функции (цикломатическая сложность > 15)

Отсортируй по срочности исправления: блокирующие (исправить немедленно) > высокий > средний > низкий.

---

Сценарий 5: PR Review (4 промпта)

Промпт #16: Быстрый обзор PR Diff

Проанализируй diff текущей ветки относительно main и оцени его как старший инженер:
1. Какова цель этого PR (исходя из diff)
2. Являются ли изменения полными (нет ли пропущенных файлов или логики)
3. Не привнесены ли новые баги или регрессии
4. Достаточно ли покрытие тестами
5. Есть ли ненужные изменения (отладочный код, «шум» от форматирования)

Сообщай только о проблемах уровней High и Critical. Не придирайся к стилю кода.

Промпт #17: Проверка обратной совместимости

Изучи все изменения в текущем PR и проверь их на наличие несовместимых изменений:
- Изменились ли сигнатуры или возвращаемые значения публичных API
- Есть ли критические изменения (breaking changes) в схеме базы данных
- Изменился ли формат конфигурационных файлов
- Были ли удалены функции, используемые в других модулях
- Изменились ли имена или форматы переменных окружения

Для каждого несовместимого изменения оцени область влияния и предложи план миграции.

Промпт #18: Проверка достаточности тестирования

Сравни изменения в коде текущего PR с изменениями в тестах:
1. Есть ли соответствующие модульные тесты для новых функций
2. Обновлены ли существующие тесты при изменении логики
3. Покрыты ли тестами граничные условия и исключительные ситуации
4. Покрывают ли интеграционные тесты новые API-эндпоинты
5. Являются ли тестовые данные адекватными (не случайные 123, abc)

Составь список рекомендаций по недостающим тест-кейсам: имя функции | недостающий сценарий тестирования | приоритет.

Промпт #19: Обзор качества коммитов

Проанализируй историю коммитов текущего PR:
1. Четко ли описаны изменения в сообщениях коммитов
2. Является ли каждый коммит атомарным (один коммит — одна цель)
3. Есть ли мелкие коммиты, которые стоит объединить (squash)
4. Есть ли временные коммиты типа "fix typo", "wip", которые нужно почистить
5. Логичен ли порядок коммитов (сначала инфраструктура, затем бизнес-логика)

Предложи, какие коммиты стоит привести в порядок и какой должна быть итоговая структура истории.

Сценарий 6: Читабельность (3 промпта)

Промпт #20: Проверка именования

Проверь именование всех переменных, функций и классов в недавно измененных файлах:
- Есть ли имена с размытым значением (data, info, temp, res, obj)?
- Есть ли чрезмерные сокращения (usr → user, btn → button)?
- Есть ли булевы переменные, названия которых не начинаются с is/has/should?
- Начинаются ли имена функций с глагола, точно описывающего действие?
- Начинаются ли имена классов с существительного, точно описывающего их ответственность?

Для каждого неудачного имени предложи более подходящий вариант.

Промпт #21: Проверка качества комментариев

Проверь качество комментариев в коде:
- Есть ли комментарии типа "что" (what), которые следует заменить на "почему" (why)?
- Есть ли устаревшие комментарии (не соответствующие коду)?
- Есть ли комментарии, которые лучше вынести в название функции?
- Не хватает ли пояснительных комментариев для сложной бизнес-логики?
- Есть ли JSDoc/docstring для публичных API?

Не предлагай добавлять очевидные комментарии (например, "// increment counter").

Промпт #22: Рекомендации по разделению функций

Проверь все функции длиннее 30 строк и оцени, стоит ли их разделить:
- Имеет ли функция несколько зон ответственности (выполняет несколько несвязанных задач)?
- Превышает ли уровень вложенности 3 слоя?
- Превышает ли количество параметров 4?
- Есть ли повторяющаяся логика, которую можно вынести?

Предложи конкретный план разделения: исходная функция → список новых функций → ответственность каждой из них.

---

Сценарий 7: Рекомендации по рефакторингу (3 промпта)

Промпт #23: Обнаружение нарушений DRY

Просканируй проект на наличие дублирующегося кода:
- Найди блоки повторяющегося кода длиннее 3 строк.
- Найди код с похожей логикой, но разным написанием.
- Найди общие паттерны, которые можно вынести в утилитарные функции.

Для каждой группы дубликатов предложи реализацию в виде общей функции.

Промпт #24: Оптимизация паттернов проектирования

Проверь код с точки зрения эксперта по паттернам проектирования:
- Стоит ли заменить множество if/else или switch на паттерн «Стратегия»?
- Стоит ли использовать паттерн «Фабрика» или «Строитель» для создания сложных объектов?
- Стоит ли использовать «Шаблонный метод» для повторяющегося шаблонного кода?
- Стоит ли использовать «Цепочку обязанностей» для многоуровневых вложенных колбэков?
- Стоит ли использовать «Наблюдатель» для управления глобальным состоянием?

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

Промпт #25: Модернизация устаревшего кода

Проверь устаревший код в проекте и найди части, которые можно переписать с использованием современного синтаксиса:
- var → const/let
- колбэк-функции → async/await
- цикл for → map/filter/reduce
- конкатенация строк → шаблонные строки
- require → import
- Class → функциональные компоненты + Hooks (React)

Приведи сравнение кода до и после рефакторинга и оцени риск изменений (низкий/средний/высокий).

🎯 Совет по использованию: Рекомендуем сохранять наиболее часто используемые промпты для ревью в файле CLAUDE.md или в .claude/skills/ для унификации стандартов в команде. С помощью команды /loop можно автоматизировать проверку безопасности и PR-ревью.
Если вы строите систему автоматизированного ревью через API, рекомендуем подключать Claude Opus 4.6 через сервис-прокси API APIYI (apiyi.com) со скидкой 20%.

Обзор персистентности промптов: от временных решений до командных стандартов

Шаг 1: Временное использование Просто введите промпт прямо в диалоге Одноразовое использование, не сохраняется Подходит для: первичного тестирования результатов 25 промптов в этой статье Сначала скопируйте и вставьте для тестирования

Шаг 2: Превращение в навык Сохранить как .claude/skills/ Зарегистрироваться как /slash-command Подходит для: частого личного использования /безопасное-глубокое-сканирование /pr-review-strict

Шаг 3: Стандартизация команды Записать в REVIEW.md / CLAUDE.md Закоммитить в git для общего доступа команды Подходит для: унификации стандартов ревью в команде Стандарт проверки для всех участников одинаков Автоматический PR-ревью для обеспечения единообразия качества

Продвинутый уровень: эффективный рабочий процесс проверки с использованием комбинации инструментов

При отправке PR #16 Обзор PR Diff + #1 Сканирование безопасности + #5 Детектирование багов

Перед выпуском мажорной версии #1 OWASP + #9 производительность базы данных + #15 технический долг + #17 совместимость

Ревью кода новичка #20 Именование + #7 Логика + #8 Обработка ошибок + #22 Разделение функций

/loop непрерывный Review /loop 15m #16 + /loop 2h #1 + /loop 24h #15

Рекомендуем APIYI: стабильный и надежный сервис-прокси API для больших языковых моделей, низкие цены, бесплатная пробная версия

Часто задаваемые вопросы

Q1: Что делать, если стандартный /code-review слишком многословен?

Создайте файл REVIEW.md в корне проекта или добавьте правила ревью в CLAUDE.md, четко указав Claude, на чем стоит сосредоточиться, а что игнорировать. Например: «Сообщай только о критических (Critical) и высокоуровневых (High) проблемах. Не придирайся к стилю кода и именованию. Не предлагай добавлять комментарии». Claude Code будет автоматически считывать этот файл при каждом ревью.

Q2: Как сохранить промпт в виде переиспользуемого навыка (Skill)?

Сохраните ваш промпт для проверки безопасности в файле .claude/skills/security-review/SKILL.md и установите параметр user-invocable: true. После этого он будет зарегистрирован как слэш-команда /security-review. В дальнейшем вы сможете просто вводить /security-review для запуска, не копируя и не вставляя текст каждый раз. Вы можете создавать сколько угодно таких навыков для разных задач.

Q3: Может ли ревью PR автоматически публиковаться в комментариях GitHub?

Да. Есть два способа: 1) Введите @claude review в комментарии к PR — Claude автоматически проанализирует diff и опубликует свои выводы в виде инлайн-комментариев; 2) Используйте команду /code-review --comment, и Claude опубликует результаты ревью как комментарий к PR. В марте 2026 года Anthropic представила специализированную мультиагентную систему для Code Review, которая координирует группу профильных агентов для проверки PR с разных сторон: безопасности, логики, тестирования и т.д.

Q4: Сколько токенов расходует промпт для ревью?

Зависит от объема проверки. Ревью одного файла обычно занимает около 2000–5000 токенов, полное сканирование проекта на безопасность — от 10 000 до 30 000 токенов. Рекомендуется ограничивать область проверки конкретными файлами или директориями, чтобы не тратить токены на «сканирование всего подряд». Подключаясь к Claude Opus 4.6 через APIYI (apiyi.com) со скидкой 20%, вы сможете существенно снизить затраты на ревью.

---

Итоги

Ключевые моменты при работе с промптами для Code Review в Claude Code:

1. 25 промптов для 7 сценариев: проверка безопасности (4), поиск багов (4), анализ производительности (3), архитектурный обзор (4), PR Review (4), читаемость (3), рекомендации по рефакторингу (3) — просто копируйте и используйте.
2. Формула идеального промпта из пяти элементов: Роль + Область + Фокус + Формат + Уровень критичности. Будьте точны, как в тестовых сценариях, а не расплывчаты, как в сообщениях в Slack.
3. Трехуровневая система ревью: встроенные команды (/security-review) → пользовательские промпты (25 штук из этой статьи) → автоматизация через /loop.

Рекомендуем подключаться к API Claude Opus 4.6 через APIYI (apiyi.com) со скидкой 20% для создания собственной системы автоматизированного Code Review.

📚 Справочные материалы

1. Официальная документация Claude Code Code Review: Полное руководство по встроенной функции Review

   • Ссылка: code.claude.com/docs/en/code-review
   • Описание: Включает обзор PR, многоагентные системы и методы кастомизации

2. Claude Code Security Review: Официальное решение Anthropic по проверке безопасности

   • Ссылка: github.com/anthropics/claude-code-security-review
   • Описание: Содержит полную реализацию команды /security-review

3. 7 промптов для PR Review в Claude: Проверенные сообществом промпты для ревью

   • Ссылка: rephrase-it.com/blog/7-claude-pr-review-prompts-for-2026
   • Описание: Включает структурированные шаблоны промптов для проверки PR

4. Центр документации APIYI: Подключение к API Claude Opus 4.6 со скидкой 20%

   • Ссылка: docs.apiyi.com
   • Описание: Оптимальное API-решение для построения автоматизированных систем ревью

---

Автор: Техническая команда APIYI
Техническое обсуждение: Приглашаем к дискуссии в комментариях, больше материалов доступно в центре документации APIYI по адресу docs.apiyi.com