Codex в Slack: как превратить обсуждение в рабочую задачу

В Slack часто рождается настоящая работа. Кто-то заметил баг, кто-то добавил скриншот, кто-то вспомнил ограничение, кто-то написал «надо бы поправить». Через десять сообщений уже вроде всё понятно, но задачи всё ещё нет.

Codex в Slack полезен именно в этот момент. Его можно упомянуть в канале или треде, и он создаст cloud task. Но простое @Codex сделай это часто слишком слабое. Для человека «это» понятно из переписки. Для агента лучше превратить тред в маленькое рабочее поручение.

Смысл не в том, чтобы заменить project management. Смысл в том, чтобы не дать хорошему обсуждению раствориться в чате.

Почему Slack-тред сам по себе ещё не задача

Тред хранит контекст, но не всегда хранит решение. В нём есть реплики, эмоции, уточнения, спорные варианты и устаревшие предположения. Человек умеет вытащить из этого суть. Агенту нужно помочь.

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

Поэтому перед упоминанием Codex важно сделать короткую рамку: что нужно сделать, где это делать, какой результат вернуть и что нельзя менять.

Хороший Slack-запуск Codex — это не магическая команда. Это перевод разговора в рабочее задание.

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

Официальная документация OpenAI описывает Codex в Slack как способ запускать coding tasks из каналов и тредов. Пользователь упоминает @Codex с prompt, Codex создаёт cloud task и отвечает результатом.

Для работы нужны Codex cloud tasks, подключённый GitHub account и хотя бы одно environment. В Slack можно указать environment или repository прямо в prompt, например попросить выполнить задачу в конкретном репозитории.

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

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

В enterprise-средах администратор может ограничить финальные ответы в Slack. Тогда Codex будет давать ссылку на task, а детали нужно смотреть там.

Что написать перед @Codex

Перед вызовом Codex полезно собрать пять элементов.

Первое — короткий итог треда. Не весь разговор, а суть: «мы нашли, что форма падает при пустом email», «CI красный из-за миграции», «на мобильной версии кнопка перекрывает текст».

Второе — действие. Исправить, диагностировать, проверить гипотезу, подготовить diff, найти причину, предложить план.

Третье — результат. Codex должен вернуть не просто ответ, а artifact: task link, summary, diff, PR-ready handoff, список изменённых файлов или вопросы.

Четвёртое — ограничение. Что не менять, какие ветки не трогать, какие данные не выносить в Slack, когда остановиться.

Пятое — acceptance. Как человек поймёт, что задача сделана: тест проходит, экран не ломается, ошибка воспроизводится и исправлена, PR можно открыть.

Как закрепить repo и environment

Самая частая ошибка — думать, что Codex всегда сам выберет правильный контур. Документация говорит, что он выбирает из доступных environments, а при неоднозначности может fallback’нуться на недавно использованный.

Если в компании один repo и один environment, это может быть нормально. Но если проектов несколько, лучше писать явно:

@Codex fix this in company/product-web

Или:

@Codex run this in the staging environment for product-web

Для владельца проекта это критично. Ошибка в repo или environment превращает хорошую задачу в лишнюю работу. Лучше потратить одну строку на уточнение, чем потом разбирать результат не из того места.

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

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

Если задача не может стартовать, это тоже результат. Codex должен сказать, какой connection, environment или repo не хватает, а не изображать работу.

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

Непрограммисту не нужно читать весь diff, чтобы понять, правильно ли сработал Slack-запуск.

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

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

Третий вопрос: есть ли artifact? Если Codex только рассуждает, но не оставил проверяемого результата, задача ещё не закрыта.

Четвёртый вопрос: понятно ли, что делать дальше? Принять, открыть PR, попросить fix, дать недостающий доступ, уточнить acceptance.

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

Codex может взять тред, создать cloud task, поработать в репозитории и вернуть результат. Но Slack не должен становиться местом автоматического принятия.

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

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

Шаблон запроса

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

@Codex

Короткий итог треда:
[что произошло и почему это важно]

Задача:
[исправь / диагностируй / проверь гипотезу / подготовь diff]

Контур:
[repo и environment, если их несколько]

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

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

Так Slack остаётся местом обсуждения, а Codex получает рабочую рамку. Не «сделай что-нибудь по треду», а «вот задача, вот контур, вот результат, вот где человек принимает решение».