Фича целиком: от задачи в трекере до MR

Отдельные приёмы — план, тесты, ревью — полезны сами по себе, но настоящий выигрыш появляется, когда они складываются в один поток. В этом уроке — сквозной пример: задача из Kaiten превращается в merge request в GitLab, а вы управляете процессом, не набирая каждую строку.

Задача для примера: «В форме заявки на сайте добавить поле "Удобное время звонка" и передавать его в CRM».

Шаг 0. Процесс — в AGENTS.md

Если каждый раз объяснять агенту, как называть ветки и что запускать перед коммитом, к третьей задаче вы начнёте это забывать. Процесс команды записывается в AGENTS.md один раз (основы — в уроке «AGENTS.md»):

## Рабочий процесс
- Ветка под задачу: task-<ID карточки в Kaiten>, от свежего main.
- Коммит: "task-<ID> | что и зачем", по одному логическому шагу.
- Перед коммитом: composer test; после правок фронта — npm run build.
- MR — в main. В описании: ссылка на задачу, что сделано, как проверить.
- Не трогать: миграции, уже попавшие в main; конфиги продакшена.

Шаг 1. Ветка и текст задачи

git switch main && git pull
git switch -c task-1234
codex

Агенту нужен текст задачи целиком: описание, критерии приёмки, ссылки на макет. Проще всего скопировать карточку в промпт. Если для трекера настроен MCP-сервер, агент прочитает карточку сам — подключение внешних инструментов разбирается в уроке «MCP на практике».

Шаг 2. План

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

/plan Задача ниже. Изучи, как устроены форма заявки и отправка в CRM,
задай вопросы и предложи план.

(текст карточки)

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

Шаг 3. Реализация небольшими шагами

Просите выполнять план по шагам с проверкой после каждого:

Выполняй план по шагам. После каждого шага запускай тесты, которые
затрагивает изменение, и делай коммит по правилам из AGENTS.md.
Если тест падает и причина неочевидна — остановись и опиши, что видишь.

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

Смотреть на каждое действие агента не нужно: руководство OpenAI прямо относит пошаговое наблюдение к типичным ошибкам. Но руку на руле держите:

• Enter во время работы добавляет указание в текущий ход: «поле необязательное, правило required убери».
• Tab ставит сообщение в очередь на следующий ход: «после этого добавь поле в экспорт заявок».
• /diff показывает текущие изменения, включая новые файлы.

Мелкие коммиты здесь — не бюрократия. Если на четвёртом шаге агент свернул не туда, вы откатываете один коммит, а не разбираете общий дифф на 600 строк. Подробнее — в уроке «Git как страховка».

Шаг 4. Проверка поведения

Зелёные тесты — необходимое условие, но не достаточное. Попросите агента показать поведение:

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

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

Шаг 5. Самопроверка

Перед тем как звать коллегу, прогоните ревью агентом — отдельным проходом, свежим взглядом. Наберите /review и выберите сравнение с базовой веткой main. Ревьюер прочитает весь дифф ветки и вернёт находки по приоритетам, ничего не меняя в файлах. Как работать с находками — в уроке «Ревью кода командой /review». Затем прочитайте дифф сами; на что смотреть — в уроке «Как ревьюить код, написанный агентом».

Шаг 6. Merge request

Описание MR агент пишет хорошо: у него есть карточка, план и дифф.

Напиши описание MR: ссылка на задачу, что сделано по пунктам, решения,
о которых стоит знать ревьюеру, как проверить вручную. Без воды,
не пересказывай дифф построчно.

Создать MR можно прямо из терминала — GitLab принимает параметры при push:

git push -u origin task-1234 \
  -o merge_request.create \
  -o merge_request.target=main \
  -o merge_request.title="task-1234 | Время звонка в форме заявки"

Другой вариант — glab, официальный CLI GitLab: glab mr create --target-branch main --title "..." --description "...". Агент может выполнить эти команды сам, но в режиме по умолчанию сеть в песочнице выключена, и на git push он запросит одобрение. Это правильно: публикация в общий репозиторий — как раз то место, где «да» должны сказать вы.

Если в вашем GitLab подключено облачное ревью Codex (интеграция в бете), его можно запросить комментарием @codex review в MR. Настройка для команды разобрана в курсе для тимлидов: «Codex как ревьюер в GitLab и GitHub».

Что остаётся за вами

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