Команда Codex CLI /goal: постановка и отслеживание целей

Слеш-команда Codex CLI /goal применяется для задания, изменения, приостановки, возобновления, просмотра и удаления цели задачи — то есть главного результата, к которому должен последовательно двигаться агент во время работы. В отличие от разового указания вроде «исправь этот тест», цель задаёт более широкий контекст: например, «перевести модуль авторизации на OAuth 2.0, сохранить обратную совместимость и добавить проверку ошибок».

Цель — это не очередная команда для текущего шага, а ориентир для всей серии действий. Она помогает Codex CLI понимать, какой результат считать правильным, даже если по дороге приходится изучать код, менять план и выполнять несколько независимых операций.

На практике /goal особенно полезна в длинных задачах, где одного сообщения недостаточно. С её помощью можно отделить устойчивое намерение пользователя от временного плана, посмотреть, что именно сейчас считается главной задачей, поставить работу на паузу или полностью убрать устаревшую цель. При этом точный набор подкоманд и форма аргументов могут зависеть от версии Codex CLI, поэтому перед использованием в конкретной установке полезно проверить встроенную справку через /help.

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

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

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

Базовый вариант выглядит так:

/goal Перевести обработку платежей на новый API, сохранить публичные интерфейсы и добавить тесты

После этого цель становится частью текущего рабочего контекста. Агент может использовать её при анализе репозитория, составлении плана и выборе следующего действия. Если в задаче появились новые ограничения, цель можно уточнить или заменить. Для этого в разных версиях интерфейса применяются формы вроде /goal <новый текст>, /goal set <текст> или /goal update <текст>. Если конкретная форма не распознаётся, следует открыть справку.

Действие	Пример	Зачем нужно
Задать цель	/goal Добавить поиск по названию и тегам	Создать ориентир для текущей работы
Изменить цель	/goal update ...	Уточнить результат, ограничения или приоритеты
Просмотреть цель	/goal или /goal show	Проверить, какой контекст сейчас активен
Приостановить цель	/goal pause	Временно прекратить её влияние на текущую сессию
Возобновить цель	/goal resume	Вернуть ранее приостановленный ориентир
Удалить цель	/goal clear или /goal delete	Убрать цель, которая больше не актуальна

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

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

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

Слабая формулировка	Проблема	Более полезная формулировка
/goal Сделай проект лучше	Нет измеримого результата	/goal Уменьшить время запуска CLI и добавить замеры для ключевых этапов
/goal Почини пользователей	Непонятна область ошибки	/goal Исправить сбой регистрации при повторном email и добавить проверку API
/goal Перепиши всё на TypeScript	Слишком широкий масштаб	/goal Перевести модуль уведомлений на TypeScript без изменения внешнего контракта
/goal Добавь фичу	Не описана сама фича	/goal Добавить фильтр заказов по статусу и сохранить пагинацию

Просмотр, изменение и удаление

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

/goal
Текущая цель:
Перевести модуль уведомлений на очередь сообщений, сохранить порядок доставки и добавить интеграционные тесты.

/goal update Использовать существующий Redis, не добавлять новый брокер сообщений

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

Операция	Что меняется	Что не меняется автоматически
Изменение цели	Ориентир для последующих действий	Уже созданные файлы и коммиты
Приостановка	Активность цели в текущем рабочем процессе	Содержимое репозитория
Возобновление	Возврат цели в рабочий контекст	Автоматическое выполнение всех пропущенных шагов
Удаление	Запись о цели	История чата и изменения в Git

Пауза и возобновление

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

/goal pause

Сейчас исправляем критическую ошибку экспорта заказов.
После её устранения вернуться к ранее заданной цели.

/goal resume

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

Ситуация	Что выбрать	Почему
Нужно временно отвлечься на аварийный баг	Пауза цели	Основное направление остаётся актуальным
Требования полностью изменились	Изменение цели	Старый ориентир будет вводить в заблуждение
Проект закрыт и продолжения не будет	Удаление цели	Неактуальный контекст больше не нужен
Нужно продолжить работу в новой сессии	Возобновление или восстановление чата	Следует вернуть не только цель, но и рабочий контекст

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

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

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

Команда особенно уместна в следующих случаях:

• при рефакторинге нескольких связанных модулей;
• при миграции библиотеки, фреймворка или схемы данных;
• при реализации функции, затрагивающей backend, frontend и тесты;
• при расследовании сложной ошибки с несколькими гипотезами;
• при подготовке проекта к релизу;
• при работе несколькими короткими сессиями в разные дни.

Тип задачи	Нужна ли цель	Пример
Мелкое исправление	Обычно нет	Исправить опечатку в сообщении об ошибке
Средний рефакторинг	Желательно	Разделить перегруженный сервис на три компонента
Крупная миграция	Да	Перейти с REST-клиента на новый SDK
Исследование причины сбоя	Часто да	Найти источник утечки памяти и подтвердить исправление
Разовая справка	Нет	Объяснить назначение конкретной функции

Цель также полезна, когда пользователь не хочет заранее диктовать каждый технический шаг. Вместо инструкции «открой файл A, затем измени функцию B, потом запусти команду C» можно описать ожидаемый результат и ограничения. Codex CLI сам исследует репозиторий и предложит последовательность действий, а пользователь сможет скорректировать её через /plan или обычное сообщение.

/goal Подготовить сервис к запуску в Docker:
- сохранить локальный режим разработки;
- добавить healthcheck;
- не хранить секреты в образе;
- проверить сборку и запуск контейнера

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

Признак	Цель помогает	Цель мешает
Масштаб	Несколько файлов или подсистем	Одна очевидная строка
Продолжительность	Работа в несколько этапов	Ответ должен быть получен сразу
Изменчивость требований	Нужно сохранять общий ориентир	Каждый запрос независим
Проверка результата	Есть тесты или критерии готовности	Невозможно определить, что значит «готово»

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

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

1. Рефакторинг без изменения внешнего поведения

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

/goal Разделить монолитный модуль заказов на независимые сервисы расчёта цены, доставки и скидок. Сохранить текущий публичный API, не менять формат ответов и добавить тесты на существующее поведение.

Найди зависимости перед изменением архитектуры и предложи план работ.

Здесь цель не диктует конкретную структуру каталогов. Она задаёт результат и ограничения, оставляя агенту пространство для анализа существующего проекта.

2. Миграция базы данных

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

/goal Перевести поле users.phone на нормализованный формат хранения. Сохранить чтение старых значений на переходный период, подготовить безопасную миграцию, добавить проверку дубликатов и описать процедуру отката.

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

/goal update Не выполнять разрушающую миграцию в этом релизе. Подготовить только совместимый слой чтения, диагностический отчёт и отдельную миграцию для следующего релиза.

3. Исправление сложной ошибки

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

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

После обнаружения причины можно уточнить ориентир:

/goal update Причина подтверждена: повторный webhook обрабатывается до фиксации ключа идемпотентности. Исправить гонку, добавить тест с параллельной обработкой и не менять внешний контракт webhook API.

4. Подготовка к релизу

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

/goal Подготовить версию 3.4.0 к выпуску: обновить changelog, проверить миграции, прогнать критические тесты, убедиться в совместимости конфигурации и собрать production-артефакт. Не добавлять новые функции, не относящиеся к релизу.

5. Временная пауза из-за срочной задачи

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

/goal pause

Основная цель временно приостановлена.
Причина: сначала нужно исправить критический сбой запуска в production.
После исправления проверить состояние изменений и выполнить /goal resume.

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

/goal resume

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

6. Удаление устаревшей цели

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

/goal clear

Старая цель по переходу на REST больше не актуальна.
Новая задача будет сформулирована отдельно после уточнения требований.

После очистки цель можно задать заново уже с обновлёнными вводными:

/goal Подготовить GraphQL-шлюз для мобильного клиента, сохранив существующий REST API для веб-приложения и добавив нагрузочные тесты для наиболее частых запросов.

Сценарий	Что обязательно указать в цели	Чего лучше избегать
Рефакторинг	Сохраняемое поведение и границы изменений	Слепого требования переписать всё
Миграция	Совместимость, порядок и откат	Непроверяемого «перенести данные»
Баг	Симптом, тест воспроизведения и критерий исправления	Выдачи гипотезы за установленный факт
Релиз	Список проверок и запрет лишних функций	Расширения объёма «по пути»
Пауза	Причину и условие возвращения	Удаления актуальной долгосрочной цели

Чем /goal отличается от других команд

Команды /plan, /status и /resume могут использоваться рядом с /goal, но решают разные задачи. Главная причина путаницы в том, что все они связаны с продолжением работы и состоянием сессии.

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

Команда	Основной объект	Главный вопрос
/goal	Долгосрочный результат	Что в итоге должно быть достигнуто?
/plan	План отдельной задачи	Какие шаги выполнить сейчас?
/status	Текущее состояние работы	Что уже сделано и что происходит?
/resume	Прерванная сессия или чат	Как продолжить ранее начатую работу?

/goal и /plan

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

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

/goal Перевести приложение на структурированные JSON-логи, сохранить поиск по текущим полям и не раскрывать секреты.

/plan
1. Проверить текущие логгеры и форматы.
2. Найти места, где выводятся токены и пароли.
3. Выбрать совместимый формат.
4. Обновить конфигурацию и тесты.
5. Проверить фильтрацию чувствительных данных.

Критерий	/goal	/plan
Срок жизни	Может охватывать несколько этапов и сессий	Обычно относится к текущей задаче
Уровень детализации	Результат и ограничения	Конкретные действия
Изменение по ходу работы	Меняется при смене требований	Часто меняется после анализа кода
Главный риск	Слишком расплывчатая цель	План без связи с нужным результатом

/goal и /status

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

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

/status

Цель: подготовить Docker-сборку сервиса.
Выполнено: создан Dockerfile, добавлен healthcheck.
В работе: исправление переменных окружения.
Ожидается: запуск интеграционных тестов.

Вопрос пользователя	Подходящая команда	Пример результата
Какой результат нужен в итоге?	/goal	Сформулированная долгосрочная цель
Что уже сделано?	/status	Список выполненных и текущих действий
Какой шаг выполнять следующим?	/plan	Последовательность операций
Как вернуться к старой сессии?	/resume	Восстановленный рабочий контекст

/goal и /resume

/resume предназначена для возобновления ранее прерванного чата или рабочего сеанса. Она отвечает за возвращение контекста: переписки, связанной задачи и доступной истории. Но восстановление чата не всегда означает, что цель автоматически будет активной в том виде, в каком пользователь её помнит. После возобновления стоит проверить цель и состояние явно.

/resume

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

/goal

Иными словами, /resume возвращает рабочее место, а /goal определяет, какая задача считается главной. Если возобновлённый чат содержит несколько старых направлений, проверка цели особенно важна: иначе агент может продолжить не ту ветку, которая сейчас нужна.

Понятие	Смысл	Пример
Долгосрочная цель	Итоговое состояние проекта	Перевести авторизацию на OAuth 2.0
План	Маршрут к ближайшему результату	Изучить провайдеров, обновить callback, добавить тесты
Состояние сеанса	Фактический прогресс и текущие проблемы	Callback обновлён, один тест падает
Возобновление чата	Возврат к прежнему контексту	Продолжить вчерашний анализ после перерыва

Как использовать команды вместе

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

1. Сформулируйте проверяемую цель через /goal.
2. Попросите Codex CLI составить или уточнить план через /plan.
3. Периодически проверяйте прогресс через /status.
4. Если требования изменились, обновите цель, а не только отдельный шаг плана.
5. При временной остановке поставьте цель на паузу и зафиксируйте причину.
6. После возвращения восстановите чат через /resume, затем снова проверьте цель и статус.

/goal Добавить кэширование каталога с корректной инвалидацией после изменения товара и без устаревших цен.

/plan Составь план с учётом текущего механизма обновления каталога.

/status

/goal update Кэш должен работать только для чтения; операции записи не изменять.

/resume Продолжить работу над кэшированием после последней сохранённой сессии.

Этап работы	Команда	Практический результат
Постановка направления	/goal	Понятен конечный результат
Проектирование действий	/plan	Есть последовательность шагов
Контроль исполнения	/status	Видны прогресс и блокеры
Перерыв	/goal pause	Направление временно неактивно
Возврат к работе	/resume и /goal resume	Восстановлены чат и цель
Смена требований	/goal update	Ориентир приведён в соответствие с новой задачей

Главное практическое правило простое: не используйте /goal как замену подробному плану и не используйте /status как замену постановке задачи. Цель задаёт смысл работы, план помогает двигаться к нему, статус показывает фактический прогресс, а возобновление возвращает прерванный контекст. Вместе эти команды превращают длинную сессию Codex CLI из набора разрозненных запросов в управляемый рабочий процесс.

/goal Результат: ускорить запуск CLI минимум на 30%, сохранив поведение команд и добавив измерения до и после изменений.

/plan Составь план диагностики и оптимизации.

/status Покажи прогресс после каждого крупного изменения.

/goal pause Приостановить оптимизацию до завершения исправления критического бага.

/resume Восстановить сессию оптимизации после перерыва.

/goal resume Продолжить активную цель и начать с проверки последнего измерения.