Codex в Linear: как превратить issue в рабочую задачу

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

Codex в Linear позволяет назначить issue агенту или позвать @Codex в комментарии. После этого создаётся cloud task, а в issue появляются progress и результат. Но качество такого запуска зависит от того, насколько issue похож на поручение.

Смысл не в том, чтобы свалить весь backlog на агента. Смысл в том, чтобы из хорошо описанного issue сделать проверяемую работу.

Почему issue ещё не поручение

Issue часто отвечает на вопрос «что болит». Агенту нужно ещё понять «что сделать».

Например, issue может называться «форма оплаты иногда падает». Для человека из команды очевидно, где искать, какой repo открыть, какой сценарий проверить. Для Codex это может быть неоднозначно: фронтенд, backend, платежный адаптер, тесты, staging, production logs.

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

Хороший issue для Codex содержит outcome, repo или environment, acceptance criteria и ограничения. Тогда Linear становится не просто списком задач, а входом в рабочий контур.

Что документация говорит о Codex в Linear

Официальная документация OpenAI описывает два способа делегировать работу из Linear: назначить issue на Codex или упомянуть @Codex в комментарии. В обоих случаях Codex создаёт cloud task и отвечает прогрессом и результатами.

Для работы нужно настроить Codex cloud tasks: подключить GitHub и создать environment для нужного репозитория. В Enterprise-сценариях администратор также включает Codex cloud tasks и connector для Linear.

После запуска Codex выбирает environment и repo по контексту issue. Если выбор неоднозначен, он может использовать недавно применявшийся environment. Чтобы избежать ошибки, в комментарии можно прямо указать repo, например: @Codex fix this in openai/codex.

Progress видно в Activity, а task link позволяет смотреть детали. Когда задача завершена, Codex публикует summary и ссылку на completed task, после чего можно создать pull request.

Документация также описывает triage rules: новые issues в triage можно автоматически делегировать Codex. Но это уже следующий уровень, не первый шаг.

Что подготовить перед назначением

Перед тем как назначать issue Codex, нужно добавить пять вещей.

Первое — outcome. Не «разобраться», а «найти причину падения формы и предложить fix», «починить CI», «подготовить PR-ready diff», «проверить, воспроизводится ли баг».

Второе — repo или environment. Если проектов несколько, лучше указать явно.

Третье — acceptance criteria. Например: тест проходит, ошибка больше не воспроизводится, экран не ломается на mobile, endpoint возвращает ожидаемый статус.

Четвёртое — ограничения. Что нельзя менять, какие области не трогать, где остановиться и спросить.

Пятое — формат результата: summary, task link, список изменений, вопросы, PR-ready handoff.

Как закрепить правильный repo

Repo и environment — это рабочий адрес задачи. Если адрес неверный, даже хороший результат будет бесполезен.

Документация говорит, что Linear может подсказать repository по контексту, а Codex выбирает подходящий environment. Но если issue касается нескольких систем, лучше не полагаться на угадывание.

В комментарии можно написать:

@Codex please run this in company/product-api

Или:

@Codex fix this in the web app environment, not the backend repo.

Для владельца проекта это самый простой способ снизить шум: не заставлять Codex сначала выбирать поле боя.

Как должен выглядеть результат

Хороший результат в Linear должен быть видимым и проверяемым.

Если Codex не может стартовать, это тоже должно быть явно: не хватает connection, environment, repo map или доступа.

Как проверить работу без кода

Непрограммисту нужно проверить не каждую строку, а управляемость результата.

Первый вопрос: Codex работал по правильному issue? Итог должен отвечать на исходную задачу, а не на соседнюю проблему.

Второй вопрос: правильный ли repo/environment? Это должно быть видно в task или summary.

Третий вопрос: связан ли результат с acceptance criteria? Если критериев не было, их нужно добавить перед повторным запуском.

Четвёртый вопрос: есть ли следующий шаг? PR, уточнение, закрытие issue, новый task или возврат человеку.

Где остаётся человеческое решение

Codex может взять issue, выполнить cloud task и вернуть результат. Но он не должен сам решать, что backlog теперь принят.

Человек решает, можно ли назначать issue агенту. Человек решает, достаточно ли контекста. Человек решает, создавать ли PR. Человек решает, закрывать ли issue. Человек решает, какие issues можно отдавать через triage rules автоматически.

Автоматическая делегация полезна только после того, как команда научилась писать agent-ready issues. Иначе triage rules будут ускорять не работу, а путаницу.

Шаблон комментария

В Linear можно написать:

@Codex

Outcome:
[что должно быть сделано]

Repo/environment:
[куда идти, если выбор может быть неоднозначным]

Acceptance criteria:
- [как проверить результат]
- [что должно пройти]

Ограничения:
- не менять [область];
- если не хватает connection/environment, остановись и напиши что нужно;
- если задача шире issue, верни вопросы.

Результат:
1. дай progress в issue;
2. верни completed task link;
3. дай summary;
4. перечисли artifact: diff, diagnosis, PR-ready handoff или вопросы;
5. скажи следующий шаг для человека.

Так issue становится не просто карточкой боли, а рабочим поручением. Codex получает контур, команда видит progress, а человек сохраняет решение о PR и приёмке.