Слеш-команда Codex CLI /review применяется для проверки рабочего дерева и поиска проблем в локальных изменениях: она помогает посмотреть на незакоммиченный код глазами внимательного ревьюера, выявить возможные ошибки, сомнительные места, регрессии и несоответствия задаче. Это особенно полезно перед коммитом, отправкой pull request или передачей результата коллеге.
Главная ценность
/review— не в автоматической гарантии качества, а в дополнительном независимом взгляде на уже внесённые изменения. Команда может заметить то, что легко пропустить после нескольких часов работы над одним и тем же кодом.
При этом ревью не заменяет тесты, ручную проверку, анализ требований и полноценную проверку поведения приложения. Codex CLI оценивает доступный ему контекст и состояние рабочего дерева, поэтому качество результата зависит от размера изменений, ясности задачи, наличия тестов и того, какие файлы действительно попали в область анализа. Ниже разберём, как применять /review, в какие моменты она особенно полезна и чем отличается от соседних команд.
- Как использовать /review
- Как подготовить запрос к ревью
- Когда применять /review
- Примеры использования /review
- Пример 1. Проверка нового API-метода
- Пример 2. Проверка миграции базы данных
- Пример 3. Проверка исправления ошибки в авторизации
- Пример 4. Проверка рефакторинга
- Пример 5. Проверка тестов и конфигурации
- Как читать результаты ревью
- Чем /review отличается от других команд
- /diff: просмотр изменений
- /plan: планирование до реализации
- /feedback: отправка обратной связи
- Как выстроить команды в один рабочий процесс
Как использовать /review
Этот раздел важен потому, что результат ревью во многом зависит не только от самой команды, но и от состояния репозитория. Перед запуском нужно понимать, какие изменения находятся в рабочем дереве, какие файлы уже добавлены в индекс, а какие ещё нет, и какую задачу должен был решить код.
Хорошее ревью начинается не с вопроса «есть ли здесь ошибки?», а с вопроса «что именно должен был изменить этот набор файлов и не нарушил ли он остальное?»
Обычно работа выглядит так: вы открываете Codex CLI в каталоге проекта, убеждаетесь, что находитесь в нужной ветке, просматриваете статус Git и запускаете /review. В зависимости от версии CLI и текущего режима команда может анализировать изменения рабочего дерева, включая незакоммиченные правки. Точный набор поддерживаемых аргументов лучше сверять с документацией установленной версии.
| Шаг | Что сделать | Зачем это нужно |
|---|---|---|
| 1 | Перейти в корень проекта | Чтобы инструмент увидел правильный репозиторий и его конфигурацию |
| 2 | Проверить активную ветку | Чтобы случайно не анализировать изменения из другой задачи |
| 3 | Посмотреть статус Git | Чтобы понять, какие файлы изменены, добавлены или удалены |
| 4 | Убедиться, что важные файлы сохранены | Ревью проверяет состояние файлов на момент запуска |
| 5 | Запустить /review |
Получить список найденных рисков и замечаний |
| 6 | Проверить замечания вручную | Отделить реальные проблемы от предположений и спорных рекомендаций |
Перед ревью полезно привести рабочее дерево в понятное состояние. Необязательно коммитить изменения, но стоит убрать случайные временные файлы, незаконченные эксперименты и посторонние правки. Иначе команда может обратить внимание на шум, а действительно важная проблема затеряется среди второстепенных замечаний.
git status --short git diff --stat git diff # После проверки состояния репозитория: /review
Если изменения большие, лучше заранее понять их границы. Например, отдельно проверить новый модуль, затем интеграцию с API, а после этого — тесты и конфигурацию. Такой подход не всегда означает запуск нескольких независимых ревью: иногда достаточно сформулировать в запросе, на какую часть изменений обратить особое внимание.
| Состояние рабочего дерева | Что увидит ревьюер | Риск | Рекомендация |
|---|---|---|---|
| Небольшие изменения в нескольких файлах | Связную картину задачи | Низкий | Можно запускать ревью сразу |
| Большой набор разнотипных изменений | Смешанный контекст | Средний | Разделить работу на логические части |
| Есть временные файлы | Лишний шум | Средний | Убрать файлы или явно обозначить их назначение |
| Изменения не сохранены | Неполное состояние проекта | Высокий | Сохранить файлы перед запуском |
| Одновременно изменены код и сгенерированные файлы | Причины и последствия вперемешку | Средний | Уточнить, какие файлы являются источниками истины |
Как подготовить запрос к ревью
Само имя команды уже задаёт общий сценарий, но дополнительный контекст помогает получить более полезный результат. Можно указать, что именно изменилось, какие требования особенно важны и какие риски нужно проверить: авторизацию, обработку ошибок, совместимость API, производительность или обратную совместимость.
Я добавил проверку прав доступа к маршрутам заказов. Проверь: — нельзя ли обойти проверку через другой endpoint; — не раскрываются ли данные чужого заказа; — корректно ли обрабатываются ошибки 401 и 403; — не сломалась ли работа администратора. /review
| Тип контекста | Пример формулировки | Когда полезен |
|---|---|---|
| Цель изменения | «Добавлена фильтрация заказов по статусу» | Чтобы оценить соответствие реализации задаче |
| Критический риск | «Особенно проверь утечку данных между пользователями» | Для безопасности и изоляции данных |
| Ограничение | «Публичный API нельзя менять обратно несовместимым способом» | Для сохранения совместимости |
| Ожидаемое поведение | «При пустом результате должен возвращаться пустой список» | Для проверки граничных случаев |
Когда применять /review
/review лучше всего использовать в точках, где цена ошибки уже заметна, но исправить её ещё относительно дёшево. Это не только финальная проверка перед коммитом: команда полезна и после крупного промежуточного шага, когда направление работы уже понятно, а код ещё легко изменить.
Чем раньше обнаружена проблема в небольшой порции изменений, тем меньше вероятность, что она успеет «раствориться» в десятках последующих правок.
Наиболее очевидный сценарий — проверка перед созданием pull request. К этому моменту разработчик уже считает задачу законченной, но именно тогда часто обнаруживаются забытые ветки условной логики, неиспользуемые параметры, некорректные коды ответа и расхождения между реализацией и описанием задачи.
# Реализована задача, тесты проходят git status --short git diff --check /review # После исправлений: git diff
Команда особенно уместна после изменений, затрагивающих несколько слоёв приложения. Например, добавление поля в базу данных может потребовать обновления миграции, модели, схемы валидации, обработчика HTTP-запроса, документации и тестов. Человек нередко проверяет только тот файл, в котором писал основную логику, а ревью помогает посмотреть на цепочку целиком.
| Ситуация | Почему стоит запустить ревью | На что обратить внимание |
|---|---|---|
| Перед коммитом | Можно исправить проблему до фиксации истории | Лишние файлы, ошибки логики, незавершённые участки |
| Перед pull request | Снижается количество очевидных замечаний от команды | Соответствие задаче, тесты, читаемость |
| После рефакторинга | Структура могла измениться без изменения внешнего поведения | Регрессии, пропущенные вызовы, изменённые зависимости |
| После исправления бага | Фикс может затронуть соседние сценарии | Граничные случаи и повторное появление ошибки |
| Перед релизом | Последняя проверка локальных правок | Конфигурация, миграции, обратная совместимость |
Есть и ситуации, когда запускать /review преждевременно. Если код находится на стадии наброска, требования ещё меняются, а файлы содержат множество временных решений, список замечаний будет длинным и малоценным. В такой момент лучше сначала уточнить план реализации, а затем провести ревью уже более устойчивого результата.
Не стоит воспринимать положительный результат как доказательство отсутствия дефектов. Автоматическая проверка может не воспроизвести реальную инфраструктуру, не знать скрытых бизнес-правил, не увидеть проблему в стороннем сервисе или не распознать ошибку, проявляющуюся только при особой последовательности действий.
| Задача проверки | /review |
Дополнительная проверка |
|---|---|---|
| Очевидная ошибка в условии | Часто может обнаружить | Тест на положительный и отрицательный сценарии |
| Нарушение бизнес-правила | Зависит от контекста | Проверка требований владельцем продукта |
| Проблема производительности | Может заметить подозрительный код | Профилирование и нагрузочный тест |
| Ошибка конфигурации окружения | Может быть не видна локально | Проверка CI/CD и тестового окружения |
| Уязвимость в зависимости | Не является заменой аудиту | Сканирование зависимостей и анализ безопасности |
Примеры использования /review
Практические сценарии помогают понять, какие вопросы можно задавать команде и как превращать общий запуск ревью в полезную проверку. Ниже приведены примеры для разных типов изменений: API, базы данных, интерфейса, безопасности, тестов и конфигурации.
Пример 1. Проверка нового API-метода
Новый endpoint может выглядеть корректно при обычном запросе, но скрывать проблемы с валидацией, авторизацией или форматом ошибок. В запросе полезно перечислить ожидаемые статусы и ограничения доступа.
Я добавил POST /api/orders. Проверь: — обязательность полей; — обработку неверного JSON; — проверку прав пользователя; — повторную отправку одного и того же заказа; — соответствие кодов ответа API-контракту. /review
Сценарий: Красная зона: пользователь не должен создать заказ от имени другого пользователя. Синяя зона: успешный ответ должен содержать идентификатор созданного заказа. /review
Пример 2. Проверка миграции базы данных
Изменения схемы опасны тем, что могут повлиять не только на новый код, но и на старые записи, порядок развёртывания и откат. Ревью стоит направить на совместимость и поведение при частично обновлённой системе.
Добавлено поле orders.delivery_date. Проверь: — безопасно ли применять миграцию к существующей базе; — допустимо ли значение NULL для старых записей; — не сломаются ли запросы и индексы; — можно ли выполнить откат; — совпадает ли тип поля с моделью приложения. /review
Особое условие: миграция должна выполняться на таблице с несколькими миллионами строк без длительной блокировки. /review
Пример 3. Проверка исправления ошибки в авторизации
В безопасности недостаточно проверить только «правильный» сценарий. Нужно рассмотреть обходы: отсутствие токена, просроченный токен, подмена идентификатора, доступ к чужому ресурсу и различия между ролями.
Исправлена проверка доступа кGET /api/profile/:id. Проверь: — может ли обычный пользователь запросить чужой профиль; — что происходит без токена; — обрабатывается ли просроченный токен; — не доверяет ли сервер значениюidиз URL; — одинаково ли защищены связанные endpoints. /review
Считай критической проблему, если доступ разрешается только потому, что идентификатор пользователя пришёл из запроса и не сверяется с данными из проверенного токена. /review
Пример 4. Проверка рефакторинга
Рефакторинг часто обещает не менять поведение программы, но именно это обещание и нужно проверять. Особенно полезно искать изменившиеся значения по умолчанию, порядок вызовов, обработку исключений и побочные эффекты.
Перенёс логику расчёта скидки из контроллера в сервис. Проверь: — полностью ли сохранено прежнее поведение; — не изменился ли порядок округления; — не исчезла ли обработка промокодов; — не вызывается ли сервис дважды; — не появились ли циклические зависимости. /review
Цель рефакторинга — изменить структуру, но не бизнес-результат. Сравни старый и новый путь для: — обычного заказа; — заказа со скидкой; — заказа с бесплатной доставкой; — отменённого заказа. /review
Пример 5. Проверка тестов и конфигурации
Проходящие тесты не всегда означают, что тесты действительно проверяют нужное поведение. Иногда в тесте есть слабое утверждение, случайно отключённый сценарий или подмена, скрывающая настоящую проблему.
Добавил тесты для обработки платежа. Проверь: — проверяют ли они результат, а не только отсутствие исключения; — есть ли сценарий отказа платёжного сервиса; — проверяется ли повторный запрос; — не слишком ли широко используются моки; — могут ли тесты пройти при неверном статусе платежа. /review
Изменил конфигурацию приложения. Проверь: — нет ли секретов в репозитории; — корректны ли значения по умолчанию; — не отключена ли проверка TLS; — совпадают ли имена переменных в коде и CI; — не изменилось ли поведение production-окружения. /review
| Тип изменения | Главный вопрос | Типичная ошибка | Что подтвердить вручную |
|---|---|---|---|
| API | Сохраняется ли контракт? | Неверный статус или формат ответа | Интеграционные сценарии |
| Авторизация | Можно ли обойти ограничение? | Доверие данным из запроса | Проверка ролей и чужих ресурсов |
| Миграция | Безопасно ли обновлять старые данные? | Блокировка или несовместимый тип | Тестовая копия production-базы |
| Рефакторинг | Не изменилось ли поведение? | Потерянная ветка логики | Сравнение сценариев до и после |
| Тесты | Ловят ли тесты реальную ошибку? | Слабое утверждение | Намеренное внесение дефекта |
Как читать результаты ревью
Ответ /review лучше воспринимать как список гипотез и направлений для проверки, а не как окончательный вердикт. Одно замечание может указывать на реальный дефект, другое — на потенциальный риск, а третье — быть предложением по улучшению, которое не обязательно нужно принимать.
Хорошее замечание должно приводить к проверяемому вопросу: при каких входных данных проблема проявится и какое поведение ожидается вместо текущего?
Начинайте с замечаний, которые могут привести к потере данных, нарушению авторизации, падению сервиса или несовместимости. Затем переходите к корректности, тестируемости и читаемости. Не стоит тратить одинаковое время на критическую уязвимость и спорное переименование локальной переменной.
| Категория замечания | Пример | Приоритет | Действие |
|---|---|---|---|
| Критическая безопасность | Доступ к чужим данным | Немедленно | Подтвердить тестом и исправить до слияния |
| Потеря данных | Удаление записей без фильтра | Очень высокий | Остановить выпуск и проверить сценарий |
| Функциональная ошибка | Неверный расчёт суммы | Высокий | Добавить воспроизводящий тест |
| Регрессия | Старый сценарий перестал работать | Высокий | Сравнить поведение до и после |
| Стиль или поддерживаемость | Дублирование кода | Средний или низкий | Исправить, если улучшение оправдано |
Удобная практика — превращать каждое существенное замечание в небольшой проверяемый сценарий. Если ревью указывает, что пустой список обрабатывается неправильно, создайте тест с пустым списком. Если говорится о возможной утечке данных, проверьте запрос от имени одного пользователя к ресурсу другого.
Замечание ревью: «При повторной отправке запроса может создаваться два платежа». Проверка: 1. Отправить один и тот же запрос дважды. 2. Использовать одинаковый ключ идемпотентности. 3. Убедиться, что создан один платёж. 4. Проверить ответ второго запроса. Вывод: замечание подтверждено только после воспроизводимого сценария.
Если замечание кажется ошибочным, не обязательно сразу его отклонять. Сначала проверьте предпосылки: возможно, ревью не знало о внешнем ограничении, нестандартном формате данных или намеренном компромиссе. Краткое пояснение в коде, тесте или описании pull request иногда снимает вопрос лучше, чем спор о формулировках.
| Результат ревью | Как поступить | Чего избегать |
|---|---|---|
| Подтверждённый дефект | Исправить и добавить тест | Ограничиваться ручным изменением без проверки |
| Потенциальный риск | Воспроизвести сценарий | Считать риск доказанной ошибкой |
| Спорное предложение | Сопоставить с требованиями проекта | Механически переписывать код |
| Ложное срабатывание | Зафиксировать причину и контекст | Игнорировать все будущие замечания |
Чем /review отличается от других команд
Похожие слеш-команды могут использоваться рядом, но решают разные задачи. /diff показывает изменения, /plan помогает спроектировать работу до реализации, а /feedback предназначена для отправки обратной связи. /review занимает промежуточное место между просмотром результата и содержательной оценкой его качества.
| Команда | Основной вопрос | Момент применения | Результат |
|---|---|---|---|
/diff |
Что именно изменилось? | До и во время анализа правок | Представление различий между версиями |
/review |
Есть ли в изменениях заметные проблемы? | После появления рабочего результата | Замечания о рисках, ошибках и качестве |
/plan |
Как лучше реализовать задачу? | До внесения изменений | План действий и последовательность шагов |
/feedback |
Как сообщить мнение или проблему? | После использования инструмента или результата | Отправленная обратная связь |
/diff: просмотр изменений
Команда /diff отвечает прежде всего на вопрос «какие строки поменялись?». Это визуальная и содержательная основа для анализа, но сам просмотр diff не обязательно означает полноценное ревью поведения. Можно увидеть добавленную проверку, но не заметить, что она никогда не вызывается в нужном сценарии.
/diff Что проверить глазами: — какие файлы изменены; — нет ли случайных удалений; — не попали ли секреты; — соответствует ли размер diff заявленной задаче. /review
Удобная последовательность такова: сначала открыть diff, чтобы понять масштаб и направление изменений, затем запустить /review, чтобы получить независимую оценку рисков. Если замечание относится к конкретному месту, снова вернитесь к diff и проверьте окружающий код.
| Критерий | /diff |
/review |
|---|---|---|
| Показывает строки изменений | Да, это основная задача | Может использовать изменения как контекст |
| Ищет логические проблемы | Не является основной целью | Да, в пределах доступного контекста |
| Проверяет соответствие задаче | Только глазами пользователя | Может указать на несоответствие |
| Заменяет тесты | Нет | Нет |
/plan: планирование до реализации
Команда /plan нужна до того, как изменения появились в рабочем дереве. Она помогает разложить задачу на шаги, определить затрагиваемые компоненты и заранее обнаружить архитектурные ограничения. /review, напротив, оценивает уже сделанную работу.
Задача: добавить экспорт отчётов в CSV. /plan Ожидаемые вопросы: — какие слои приложения затрагиваются; — где будет формироваться файл; — как ограничить размер отчёта; — как обрабатывать ошибки; — какие тесты нужны. # После реализации: /review
Эти команды хорошо дополняют друг друга. Если план был составлен заранее, во время ревью можно проверить не только качество кода, но и соответствие реализации первоначальному замыслу. Однако хороший план не гарантирует хороший результат: требования могут измениться, а реализация — отклониться от плана по уважительной причине.
| Этап работы | Подходящая команда | Главная польза |
|---|---|---|
| Понять задачу | /plan |
Выстроить последовательность действий |
| Сравнить фактические правки с ожиданием | /diff |
Увидеть конкретные изменения |
| Найти возможные проблемы | /review |
Получить дополнительный анализ |
| Сообщить о качестве инструмента | /feedback |
Передать обратную связь разработчикам |
/feedback: отправка обратной связи
Команда /feedback предназначена не для проверки рабочего дерева как такового, а для сообщения о впечатлениях, проблемах или предложениях по работе инструмента. Если /review нашла сомнительное место в вашем коде, это не означает, что нужно отправлять результат через /feedback. Сначала разберитесь с замечанием; обратная связь нужна, когда вы хотите сообщить о поведении самого Codex CLI.
После использования /review инструмент несколько раз ошибочно считает обычный вызов API уязвимостью. /feedback Описание: — версия CLI; — краткий фрагмент контекста; — полученное замечание; — почему оно не соответствует проекту; — ожидаемое поведение.
Обратная связь особенно полезна, если команда стабильно неправильно понимает определённый паттерн, выдаёт неполные результаты или неудобно формулирует важные замечания. Чем точнее описаны входные данные и ожидаемый результат, тем полезнее будет такое сообщение.
| Вопрос | /review |
/feedback |
|---|---|---|
| Проверяет ли команда ваш код? | Да, в рамках доступного контекста | Нет, она передаёт сообщение |
| Кому адресован результат? | Разработчику или команде проекта | Команде, которая улучшает инструмент |
| Когда запускать? | После появления изменений | Когда есть наблюдение о работе CLI |
| Что нужно приложить? | Рабочее дерево и контекст задачи | Описание проблемы, версию и ожидаемое поведение |
Как выстроить команды в один рабочий процесс
В реальной задаче команды можно использовать последовательно. Сначала сформулировать план, затем реализовать изменения, посмотреть diff, провести ревью и после исправлений отправить обратную связь, если поведение инструмента оказалось неточным или неудобным.
1. /plan Определить архитектурные шаги и список затрагиваемых файлов. 2. Реализация Внести изменения и локально запустить тесты. 3. /diff Проверить фактический набор правок. 4. /review Попросить найти возможные дефекты и риски. 5. /feedback Сообщить о проблеме в работе самого инструмента, если она обнаружена.
Важно не превращать этот порядок в формальный ритуал. Маленький косметический фикс не всегда требует подробного плана, а срочный исправляющий коммит может начинаться с diff и теста. Смысл команд — помогать принимать решения, а не добавлять проекту церемоний ради церемоний.
| Размер задачи | Минимальный набор | Расширенный набор |
|---|---|---|
| Мелкая правка | /diff → тест |
/diff → /review |
| Обычная функциональность | /plan → код → /review |
/plan → /diff → /review → тесты |
| Изменение безопасности | План → код → ревью → ручные проверки | План → diff → ревью → security-тесты → ручной аудит |
| Изменение инструмента или процесса | Воспроизвести проблему | Воспроизвести → /feedback → отслеживать результат |
В итоге /review — это практичный этап проверки локальных изменений, а не магический сертификат качества. Используйте её после осмысленного изменения, задавайте конкретные вопросы, связывайте замечания с тестами и не забывайте о ручной проверке. /diff покажет, что изменилось, /plan поможет понять, как действовать до реализации, а /feedback позволит сообщить о качестве работы самого инструмента. Вместе эти команды формируют понятный цикл: спланировать, реализовать, увидеть изменения, проверить результат и улучшить процесс.