Команда Codex CLI /plan: как перейти в режим планирования

Слеш-команда /plan в Codex CLI применяется для подготовки понятного пошагового плана работы перед тем, как агент начнёт изменять файлы, выполнять команды или перестраивать часть проекта. Она особенно полезна в задачах, где недостаточно сразу написать несколько строк кода: нужно разобраться в структуре репозитория, найти связанные компоненты, оценить риски и договориться о последовательности действий.

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

По сути, /plan переводит взаимодействие с Codex CLI из режима «сразу делай» в режим «сначала разберись и объясни, что собираешься делать». Это не магическая кнопка, которая гарантирует безошибочный результат, а инструмент для структурирования работы. Пользователь получает возможность проверить замысел агента до внесения изменений, уточнить требования, добавить ограничения и только после этого перейти к реализации.

Как использовать /plan

В этом разделе разберём базовый сценарий запуска команды, особенности формулировки задачи и то, как читать предложенный план. Такой порядок важен: качество результата зависит не только от самой команды, но и от контекста, который получает Codex CLI.

Команда /plan полезнее всего тогда, когда вопрос сформулирован не как «сделай что-нибудь», а как «исследуй проблему, предложи последовательность решений и обозначь места, требующие моего подтверждения».

Обычно работу начинают из корня нужного проекта, запустив Codex CLI в терминале. После появления интерактивного интерфейса вводят /plan, а затем описывают задачу обычным языком. В зависимости от версии CLI и настроек интерфейса команда может открывать специальный режим планирования или просить агента подготовить план текущей задачи. Поэтому внешний вид диалога может отличаться: в одной версии план появляется сразу, в другой его формирование сопровождается вопросами.

Пример запуска:
$ cd ~/projects/shop
$ codex
> /plan
> Добавь поддержку промокодов в оформлении заказа. Сначала изучи текущую модель заказа,
> расчёт итоговой суммы и существующие тесты. Ничего не изменяй до моего подтверждения.

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

Элемент запроса	Что в нём указать	Зачем это нужно
Цель	Какой результат должен получить пользователь или система	Помогает не свести задачу к изменению одного случайного файла
Границы	Какие части проекта можно или нельзя менять	Снижает риск побочных изменений
Ограничения	Версия языка, фреймворк, совместимость, стиль кода	Делает план применимым к конкретному проекту
Проверка	Какие тесты, проверки или сценарии нужно выполнить	Связывает план с измеримым результатом
Режим изменений	Нужно ли только исследование или можно редактировать файлы	Позволяет контролировать момент перехода к реализации

Необязательно писать длинное техническое задание. Но чем выше цена ошибки, тем полезнее сообщить контекст заранее. Например, фраза «исправь авторизацию» слишком широкая. Гораздо практичнее написать, что проблема проявляется при обновлении токена, воспроизводится только для мобильного клиента, а менять контракт публичного API нельзя.

Минимальный сценарий

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

Запрос:
/plan Исправь ошибку: кнопка «Сохранить» на странице профиля остаётся неактивной
после изменения номера телефона. Найди причину, предложи файлы для изменения
и перечисли проверки.

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

Планирование с запретом на изменения

Когда задача касается критичного кода, сначала явно попросите только исследование. Это помогает отделить анализ от реализации и не превращать просмотр плана в неожиданное редактирование репозитория.

Запрос:
/plan Проанализируй переход с Redis-кэша на встроенный кэш приложения.
Пока не изменяй файлы и не запускай миграцию. Покажи:
1) какие модули используют Redis;
2) какие данные кэшируются;
3) какие риски есть у замены;
4) как проверить обратную совместимость.

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

План с критериями готовности

Если план должен привести к конкретному результату, добавьте критерии готовности. Они помогают Codex CLI связать действия с проверяемым состоянием проекта, а не просто составить список файлов.

Запрос:
/plan Реализуй пагинацию списка заказов.
Готово, если:
- API возвращает номер страницы и общее количество страниц;
- старые клиенты продолжают работать;
- есть тесты для первой, последней и пустой страницы;
- интерфейс показывает состояние загрузки и ошибку сети.

Слабая формулировка	Более точная формулировка	Как меняется план
Сделай поиск	Добавь поиск по названию и артикулу с задержкой 300 мс	Появляются требования к фильтрации, debounce и тестам
Ускорь приложение	Сократи время ответа каталога с 800 до 300 мс на тестовом наборе	План включает измерения и критерии сравнения
Обнови зависимости	Обнови библиотеку платежей без изменения публичного API	Учитываются совместимость и регрессионные проверки
Добавь уведомления	Отправляй письмо после успешной оплаты, но не после повторной доставки события	В план попадают идемпотентность и обработка событий

Когда применять /plan

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

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

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

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

Тип задачи	Нужен ли /plan	Почему
Переименование одной локальной переменной	Обычно нет	Объём и риск невелики, планирование может быть дороже самой правки
Добавление новой бизнес-функции	Да	Нужно связать интерфейс, серверную логику, данные и тесты
Миграция базы данных	Обязательно	Важны порядок миграций, откат, данные и совместимость версий
Исправление очевидной опечатки	Нет	Достаточно прямого действия и быстрой проверки
Изменение системы авторизации	Да	Высокая цена ошибки и множество пограничных сценариев
Обновление крупной зависимости	Желательно	Нужно заранее оценить breaking changes и тестовый охват

Новые функции

Для новой функции план помогает ответить на главный вопрос: какие слои системы действительно должны измениться. Без этого легко реализовать красивый интерфейс, который не сохраняет данные, или API, для которого забыли обновить клиент.

Запрос:
/plan Добавь возможность сохранять товары в избранное для авторизованных пользователей.
Изучи текущую модель пользователя, API каталога и существующий способ хранения связей.
Учти гостевой режим, повторное добавление товара и удаление из избранного.

Ожидаемый результат должен включать модель данных или способ хранения, API-операции, изменения интерфейса, правила доступа и тесты для повторных запросов. Если агент сразу предлагает создавать новую таблицу, стоит спросить, нет ли уже универсального механизма пользовательских коллекций.

Рефакторинг и смена архитектуры

Рефакторинг опасен тем, что внешне может выглядеть как «перенос кода», хотя на деле меняет зависимости, порядок вызовов и ответственность модулей. /plan помогает заранее зафиксировать границы преобразования.

Запрос:
/plan Раздели большой модуль InvoiceService на отдельные компоненты расчёта,
валидации и отправки счёта. Сохрани публичное поведение и текущие имена методов.
Определи безопасный порядок переноса и список регрессионных тестов.

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

Миграции и изменения схемы

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

Запрос:
/plan Добавь обязательное поле country_code в таблицу users.
Учти существующие записи, порядок развёртывания, заполнение исторических данных,
совместимость старой версии приложения и безопасный способ сделать поле NOT NULL.

Если план сразу предлагает добавить ограничение обязательности до заполнения старых строк, это тревожный сигнал. Сначала должна появиться совместимая схема, затем данные нужно обработать, и только после проверки — ужесточать ограничение.

Признак хорошего плана миграции	Что он должен раскрывать
Совместимость	Как старая и новая версии приложения работают одновременно
Данные	Как заполняются старые записи и обрабатываются пропуски
Откат	Что происходит при неудачном развёртывании
Нагрузка	Будет ли операция блокировать таблицу или перегружать базу
Проверка	Какими запросами и тестами подтверждается корректность

Сложные ошибки

При непонятном дефекте планирование полезно направить не на немедленное «исправление», а на поиск причин. Чем хуже воспроизводится проблема, тем важнее перечислить наблюдаемые симптомы, окружение и уже проверенные гипотезы.

Запрос:
/plan После истечения access token часть запросов возвращает 401, хотя refresh token
действителен. Ошибка проявляется только при нескольких параллельных запросах.
Проанализируй механизм обновления токена, возможную гонку и существующие логи.
Сначала предложи план диагностики, затем варианты исправления.

В такой ситуации план должен разделять диагностику и исправление. Иначе агент может замаскировать симптом повторными запросами, не устранив гонку, из-за которой несколько потоков одновременно обновляют один и тот же токен.

Примеры использования /plan

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

Каждый пример построен так, чтобы Codex CLI получил не только пожелание, но и полезные рамки: что исследовать, что не менять, какие риски учитывать и каким способом подтвердить результат.

Пример 1. Новый REST-эндпоинт

Такой запрос подходит, когда нужно добавить API-операцию и не забыть о валидации, авторизации, документации и тестах.

Запрос:
/plan Добавь POST /api/v1/projects для создания проекта.
Изучи существующие контроллеры, DTO, обработку ошибок и правила доступа.
Не меняй формат уже существующих ответов. В плане укажи валидацию,
коды ошибок, тесты и необходимость обновления OpenAPI-документации.

Что проверить в плане	Хороший признак	Повод уточнить
Авторизация	Указано, какая роль может создавать проект	Написано только «добавить проверку доступа»
Ошибки	Перечислены коды и формат ответа	Ошибки описаны как «обработать исключения»
Тесты	Есть успешный и отрицательные сценарии	Упомянут только один happy path

Пример 2. Изменение пользовательского интерфейса

Планирование фронтенд-задачи помогает учесть состояние загрузки, пустые результаты, ошибки и доступность, а не только внешний вид основного экрана.

Запрос:
/plan Переделай страницу списка клиентов: добавь фильтр по статусу,
сортировку по дате регистрации и состояние «нет результатов».
Сохрани текущую навигацию. Изучи используемые UI-компоненты,
паттерны запросов и существующие тесты. Учти мобильную ширину экрана
и доступность элементов управления.

Если в плане указаны только изменения JSX или шаблонов, попросите дополнительно показать, где хранится состояние фильтров и как оно синхронизируется с URL. Иначе после обновления страницы выбранные параметры могут исчезать.

Пример 3. Оптимизация медленного запроса

Оптимизация без измерений часто превращается в соревнование по интуиции. В запросе стоит потребовать сначала найти узкое место и определить базовые показатели.

Запрос:
/plan Ускорь запрос списка заказов для менеджера.
Сначала найди фактический SQL, измерь узкие места и проверь индексы.
Не меняй структуру базы без объяснения ожидаемого эффекта.
План должен включать способ сравнить время ответа до и после изменения
и проверку того, что результаты запроса не изменились.

Зрелый план упоминает план выполнения запроса, объём данных, сортировку, пагинацию и влияние индекса на операции записи. Простое предложение «добавить индекс на все поля» почти никогда не является полноценной оптимизацией.

Пример 4. Обновление зависимости

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

Запрос:
/plan Обнови библиотеку платежей до версии 6.
Проверь changelog и места использования API в проекте.
Составь список потенциальных breaking changes, предложи порядок изменений
и набор тестов для оплаты, возврата, webhook-событий и повторной доставки.

Область проверки	Вопрос	Результат планирования
Публичный API	Изменились ли имена методов или типы параметров?	Список мест, требующих адаптации
Конфигурация	Изменились ли переменные окружения или формат ключей?	План обновления окружений
Ошибки	Изменился ли тип исключений или код отказа?	Проверка обработчиков ошибок
Тесты	Покрывают ли они реальные сценарии провайдера?	Набор регрессионных проверок

Пример 5. Исправление проблемы с кэшем

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

Запрос:
/plan Пользователь видит старую цену товара после изменения менеджером.
Изучи ключи кэша, TTL, операции обновления товара и места очистки кэша.
Найди, может ли существовать несколько вариантов ключа для одного товара.
Предложи исправление и тест, подтверждающий актуальность цены.

В плане должны быть отдельно рассмотрены чтение, запись и инвалидирование кэша. Если используется несколько уровней кэширования, например серверный и браузерный, одной очистки на сервере может быть недостаточно.

Пример 6. Добавление фоновой задачи

Фоновая обработка связана с повторными запусками, очередями, тайм-аутами и идемпотентностью. Поэтому планирование здесь полезнее, чем попытка сразу написать обработчик.

Запрос:
/plan Перенеси отправку отчёта в фоновую очередь.
Изучи текущую отправку писем, используемый брокер и механизм повторных попыток.
Учти, чтобы один отчёт не отправлялся дважды при повторной доставке сообщения.
Опиши мониторинг, обработку окончательной ошибки и тестирование.

Риск фоновой задачи	Вопрос к плану	Возможное решение
Дубликаты	Что произойдёт при повторной доставке?	Идемпотентный ключ или таблица обработанных событий
Потеря сообщения	Когда сообщение считается принятым?	Подтверждение после сохранения и контролируемые повторы
Зависшая задача	Как обнаружить превышение времени?	Тайм-аут, метрика и очередь повторной обработки
Неисправимая ошибка	Куда попадает задача после исчерпания попыток?	Dead-letter очередь и уведомление ответственного

Пример 7. Покрытие существующего кода тестами

Если тестов мало, не обязательно начинать с механического покрытия каждой строки. Лучше попросить Codex CLI определить критические сценарии и места, где тесты дадут наибольшую защиту.

Запрос:
/plan Добавь тесты для расчёта стоимости доставки.
Изучи бизнес-правила, существующие фикстуры и тестовый фреймворк.
Покрой бесплатную доставку, разные регионы, минимальную сумму заказа,
пограничные значения и неизвестный тариф. Не переписывай production-код
без отдельного объяснения причины.

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

Пример 8. Безопасное изменение авторизации

Авторизация требует особенно осторожного плана: нужно проверить не только успешный вход, но и истечение сессии, отзыв прав, сброс пароля и поведение разных ролей.

Запрос:
/plan Добавь роль support, которая может просматривать заказы,
но не может менять цены и возвращать деньги.
Изучи текущую модель ролей, middleware и проверки на уровне сервисов.
Проверь, нет ли обхода через прямой вызов API.
В плане отдельно перечисли тесты на разрешённые и запрещённые действия.

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

Пример 9. Подготовка к удалению старого кода

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

Запрос:
/plan Удали старый endpoint /api/legacy/export.
Проверь использование в исходном коде, тестах, CI, документации и конфигурации.
Определи, есть ли признаки внешних клиентов. Предложи этапы deprecation,
метрику контроля обращений и только затем окончательное удаление.

Перед удалением нужно проверить	Пример источника зависимости
Код	Внутренние вызовы, маршруты, клиенты SDK
Автоматизацию	CI-скрипты, cron-задачи, deployment hooks
Документацию	OpenAPI, инструкции, примеры интеграции
Наблюдаемость	Метрики обращений, логи, алерты
Внешних пользователей	Партнёры, мобильные приложения, старые версии клиентов

Пример 10. Подготовка релиза

Перед релизом /plan помогает превратить длинный список пожеланий в проверяемую последовательность: код, миграции, конфигурация, тесты, наблюдаемость и откат.

Запрос:
/plan Подготовь релиз функции промокодов.
Сверь изменения в API, базе данных, интерфейсе и фоновых задачах.
Проверь переменные окружения, миграции, feature flag, мониторинг,
план отката и smoke-тесты после развёртывания.

Такой запрос особенно полезен, если над функцией работали несколько человек. Codex CLI может обнаружить разрыв между частями системы, например наличие миграции без обновлённого deploy-скрипта или UI-флага без серверной проверки.

Чем /plan отличается от похожих команд

Слеш-команды в Codex CLI могут выполнять разные роли: одни меняют режим работы, другие запускают проверку, третьи обращаются к истории или управляют параметрами среды. Их нельзя считать взаимозаменяемыми. Названия и доступный набор команд могут зависеть от версии Codex CLI, поэтому при сомнениях полезно обратиться к встроенной справке.

/plan отвечает прежде всего на вопрос «что и в каком порядке делать», а не на вопросы «как откатить изменения», «какой режим разрешений включён» или «как проверить уже написанный код».

/review

/review обычно используют для анализа уже внесённых изменений: поиска дефектов, регрессий, проблем безопасности и несоответствий требованиям. В отличие от /plan, эта команда смотрит назад — на diff или текущий результат, а не только вперёд, на предполагаемую реализацию.

Команда	Основной момент применения	Главный вопрос
/plan	До реализации	Как безопасно решить задачу?
/review	После изменений	Что в сделанном коде может быть неправильно?

Сценарий:
/plan Добавь аудит изменений профиля с учётом требований задачи.
...
/review Проверь внесённые изменения: безопасность, полноту аудита,
утечки персональных данных и регрессионные риски.

/diff и просмотр изменений

Просмотр diff показывает, что именно изменилось в рабочих файлах. Это конкретный технический снимок, тогда как /plan является намерением и последовательностью действий. План может обещать обновить тесты, но только diff покажет, были ли они действительно добавлены.

Сценарий:
/plan Исправь обработку пустого ответа внешнего сервиса
и добавь регрессионный тест.
...
Покажи diff и объясни, какие изменения соответствуют каждому пункту плана.

Если в конкретной версии CLI нет отдельной слеш-команды /diff, изменения можно просмотреть средствами Git, например командой git diff. Название или доступность вспомогательной команды не меняет базовый принцип: план и фактический diff нужно сопоставлять.

/model

/model относится к выбору модели или параметров, с которыми будет работать Codex CLI. Она не создаёт план сама по себе. Выбор модели может повлиять на глубину анализа, скорость и расход ресурсов, но не отменяет необходимости ясно описать задачу.

Инструмент	На что влияет	Чего не делает
/plan	Структурирует решение и порядок работы	Не гарантирует корректность архитектуры
/model	Выбирает рабочую модель или режим	Не заменяет требования и критерии готовности

/approvals и режимы разрешений

/approvals обычно связан с тем, какие действия Codex CLI может выполнять самостоятельно: запуск команд, изменение файлов или запрос подтверждения. Это вопрос контроля полномочий, а не содержания плана. Безопасный режим разрешений полезен даже тогда, когда используется /plan, поскольку планирование не должно автоматически означать безусловное выполнение опасных операций.

Безопасная последовательность:
/approvals
Проверь текущие разрешения и убедись, что изменения требуют подтверждения.

/plan Изучи причину сбоя миграции. Не удаляй данные и не запускай destructive-команды.
Покажи план диагностики и список безопасных проверок.

Типичные ошибки при работе с /plan

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

Ниже перечислены типичные ошибки, которые делают план формальным. Для каждой важно не только понять проблему, но и увидеть способ исправить запрос.

Ошибка 1. Слишком расплывчатая задача

Запрос «улучши производительность» или «сделай нормальную авторизацию» не задаёт границ. Codex CLI вынужден угадывать, что именно считать улучшением, а разные разработчики могут понимать цель совершенно по-разному.

Плохо:
/plan Улучши каталог.

Лучше:
/plan Найди причину, почему каталог отвечает дольше 700 мс при 50 000 товаров.
Сначала предложи измерения и безопасные оптимизации. Не меняй контракт API.
Критерий успеха — p95 ниже 400 мс на тестовом наборе.

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

Ошибка 2. Игнорирование контекста репозитория

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

Плохо:
/plan Добавь кэширование ответов.

Лучше:
/plan Добавь кэширование ответов каталога.
Используй существующий Redis-клиент, не добавляй новую зависимость,
не кэшируй персонализированные ответы и учитывай очистку после изменения товара.

Недостающий контекст	Какой риск возникает	Что добавить в запрос
Стек проекта	Неподходящая библиотека или синтаксис	Язык, фреймворк и актуальные версии
Границы API	Ломающие изменения для клиентов	Что запрещено менять
Ограничения данных	Потеря или неправильная обработка записей	Правила миграции и сохранения
Критерии успеха	Невозможно объективно принять результат	Тесты, метрики или пользовательские сценарии

Ошибка 3. Слепое принятие плана

План — это предложение, а не доказательство правильности решения. Codex CLI может не увидеть внешнюю зависимость, неверно понять бизнес-правило или выбрать чрезмерно сложную архитектуру.

Запрос на проверку:
/plan Ты предложил добавить отдельную таблицу для статусов заказа.
Перед реализацией сравни это решение с существующей моделью событий,
объясни плюсы и минусы обоих вариантов и укажи влияние на миграции и отчёты.

Полезно задавать уточняющие вопросы: почему выбран этот файл, какие альтернативы рассматривались, что произойдёт при повторном запросе, как выполняется откат и какие тесты поймают регрессию.

Ошибка 4. Отсутствие границы между планом и реализацией

Если пользователь хочет сначала только разобраться, это нужно сказать прямо. Иначе агент может перейти к изменению файлов сразу после анализа, особенно если задача сформулирована как приказ «реализуй».

Плохо:
/plan Перепиши механизм авторизации и исправь все ошибки.

Лучше:
/plan Сначала исследуй текущий механизм авторизации.
Не изменяй файлы и не выполняй миграции.
Покажи найденные проблемы, варианты решения, риски и порядок внедрения.
После моего подтверждения перейдём к реализации.

При этом режим разрешений остаётся отдельным уровнем защиты. Текстовая просьба не менять файлы полезна, но её разумно дополнять безопасными настройками среды.

Краткая памятка

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

Перед запуском убедитесь, что Codex CLI открыт в правильном репозитории, а затем сформулируйте цель, ограничения и критерии готовности. После получения плана проверьте затронутые файлы, зависимости, риски, тесты и способ отката.

Шаг	Что сделать	Проверочный вопрос
1. Подготовить контекст	Открыть нужный проект и указать важные ограничения	Агент видит правильный репозиторий и понимает границы?
2. Запустить планирование	Ввести /plan и описать задачу	Сформулирована ли цель, а не только название функции?
3. Уточнить план	Попросить объяснить спорные решения и альтернативы	Понятно ли, почему выбран именно этот путь?
4. Проверить риски	Посмотреть на данные, безопасность, совместимость и откат	Что может сломаться при частичном выполнении?
5. Согласовать реализацию	Подтвердить границы изменений и порядок действий	Есть ли ясное понимание того, что будет изменено?
6. Проверить результат	Сопоставить diff, тесты и критерии готовности с планом	Сделано ли всё обещанное и не появилось ли лишнего?

• Используйте /plan до реализации, когда задача затрагивает несколько файлов, слоёв или компонентов.
• Добавляйте критерии готовности, чтобы план можно было проверить, а не просто похвалить за убедительный вид.
• Указывайте запреты: не менять API, не запускать миграции, не добавлять зависимости или не редактировать файлы до подтверждения.
• Просите учитывать тесты, откат и совместимость, особенно для базы данных, авторизации, платежей и фоновых задач.
• Не путайте план с ревью: /plan описывает предполагаемый путь, а /review проверяет уже выполненную работу.
• Не принимайте результат автоматически: даже подробный план нужно сопоставить с требованиями проекта и реальными ограничениями.

В повседневной работе /plan лучше всего воспринимать как короткое техническое совещание с Codex CLI перед началом изменений. Вы не обязаны принимать первый вариант без вопросов: можно попросить сократить объём, сравнить альтернативы, разбить задачу на безопасные этапы или отдельно разобрать риски. Именно такой диалог превращает слеш-команду из формальности в практический инструмент инженерной работы.