Как вести задачи для агентов

Где живёт задача?

Это самый частый вопрос во всех потоках. Задачи лежат в штабе или в каждом проекте? Почему статус в штабе один, а в проекте другой?

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

Штаб: это папка с правилами, где агент узнаёт всё про мою работу. Задачи штаб у себя не хранит. В его правилах по строке на каждый отдел: где лежат задачи этого отдела. По этим строкам агент утром собирает дела всех отделов в один список. Подробно это разобрано в гайде «Как агент ведёт мои дела».

Есть третий вид папки: сайт, бот, учебная платформа. Туда сдают работу. Своих задач там нет. Агент делает правку на сайте, а ссылка на правку возвращается в задачу отдела. Отличить отдел от такой папки помогает один вопрос: что пропадёт, если её завтра удалить. Пропал сайт, значит пропал продукт. Пропал отдел, значит пропала память о том, что делается и зачем. Подробнее эта разница разобрана в статье «Зачем агентам задачи».

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

Как дробить работу на задачи?

Это второй по частоте вопрос. Задачи выходят то слишком общими, то слишком мелкими.

Начните с проверки. Задача: это работа, результат которой можно проверить. Если проверку не сформулировать, это мелкая правка. Её агент делает сразу, без задачи.

В хорошей задаче четыре вещи. Заголовок начинается с глагола: «Отправить клиенту письмо с итогами встречи». Один ответственный: «все вместе» значит никто. Признак готовности, который видно глазами: «письмо ушло, в нём три договорённости со встречи». И ссылка на результат, которая появляется при закрытии.

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

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

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

Возьми [ПРОЕКТ ИЛИ ЦЕЛЬ] и разложи на задачи.

У каждой задачи четыре поля: заголовок с глаголом, кто ведёт, признак готовности, куда ляжет результат.

Если шаг нельзя проверить, разбей его ещё раз. Мелкие правки без проверки задачами не делай.

Свяжи все задачи с одним эпиком. Покажи мне список до того, как что-то создавать.

Что это

Начинается всё с чата. Я пишу агенту: «Хочу стратегию развития себя как специалиста на ближайший квартал». Такая задача живёт, пока живёт чат. Чтобы вернуться к ней через неделю, я прошу агента сохранить её в файл. Файл переживает и чат, и харнес, и подписку: задачу, начатую в Claude Code, продолжит Codex или GLM. Главное, что она лежит в папке.

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

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

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

Например, в папке задач отдела обучения четыре файла: «Подготовить бриф урока», «Провести эфир», «Выложить запись», «Отдать обратную связь по домашке». Главное, что даёт файл задачи, я формулировал так: «мы получаем возможность продолжать». Агент в новом разговоре открывает файл и продолжает с того же места.

Когда её хватает

Хватает, пока вы работаете за одним компьютером и агенты открыты в папках на нём. С телефона эта ступень тоже работает: у Claude Code и Codex есть удалённый доступ к агенту на вашем компьютере.

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

Что нужно заранее

• Штаб.
• Папка отдела.
• Агент: Claude Code или Codex.

Больше ничего ставить не нужно.

Как завести

Где спотыкаются

Что это

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

Папка отдела становится репозиторием: у неё есть история версий на компьютере и копия на GitHub. У каждого репозитория свой список задач, это issues. У issue есть номер, ссылка, комментарии и история. Большая задача становится эпиком с подзадачами. Задачи можно связать: «заблокирована» и «блокирует» (документация GitHub). Доска в GitHub Projects собирает задачи многих репозиториев на один экран. Сами задачи остаются в своих репозиториях.

Задачи становятся видны отовсюду: агенту на другом компьютере, облачному агенту и вам с телефона. Если один раз подключить GitHub к ChatGPT, он ответит на вопрос «что у меня на сегодня» по вашим задачам. Задачу можно сначала завести в GitHub, а потом отдать разным моделям. Так я делал на эфире с Opus 5.5.

Главное отличие от первой ступени: задача переехала из файла и живёт по ссылке. Ссылку я копирую в любого агента, и он продолжает работу. Раньше агенты работали только на моём компьютере. Теперь к задаче подключаются и облачные агенты: ChatGPT, Gemini, корпоративные. А правда о задаче по-прежнему хранится в одном месте.

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

Для команды GitHub тоже удобен. В репозиторий можно пригласить человека с нужными правами, например только на чтение. История версий показывает, какой файл и когда менялся. По ней можно откатиться, так что это ещё и бэкап. GitHub: американская компания, файлы лежат на её серверах. У многих компаний есть свой сервер, например GitLab.

Метки, статусы, связи и вид досок в GitHub настраивают агенты, интерфейс учить не нужно. Я захожу туда раз в неделю или когда нужно показать работу кому-то ещё.

Как задача ведёт работу

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

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

Как это устроено у меня

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

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

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

Когда её хватает

Хватает, пока задачи заводите вы, а агенты читают и пишут в них из разных папок и с разных компьютеров.

Пора выше, когда агенты сами заводят и разбирают задачи круглые сутки и кончаются лимиты.

Лимиты GitHub: документация GitHub, документация поиска

Агенты съедают это быстро: каждый просмотр задачи, поиск и комментарий тратит запрос. На этот случай в моём скилле manager есть правило. Если лимит не дал прочитать доску, агент перестаёт обновлять доску и оставляет пометку «rate limit». 10 сентября GitHub не дал моему агенту прочитать доску из 1314 задач.

Что нужно заранее

• Аккаунт на GitHub. Он бесплатный, нужна только почта. Если у вас есть Gmail, берите его.
• Git на компьютере: программа, которая ведёт историю версий. Ставит его агент: дайте ему ссылку на этот гайд, он установит git и свяжет компьютер с GitHub.
• Папка отдела стала репозиторием: история версий на компьютере и приватная копия на GitHub. Репозиторий по умолчанию приватный, публичным его не делайте.
• GitHub CLI, в который вы вошли своим аккаунтом. Через него агент заводит и читает задачи.
• По желанию: подключение GitHub в ChatGPT, чтобы видеть задачи с телефона.

Как завести

Перенеси открытые задачи этого отдела в GitHub Issues текущего репозитория.

Прочитай AGENTS.md и все файлы в tasks/, кроме шаблона. Открытыми считай задачи со статусом «новая», «в работе», «на приёмке» или «заблокирована». Закрытые не переноси.

Для каждой открытой задачи создай одну issue. Сохрани результат, состояние, контекст, решения, следующий шаг и ссылку на результат.

Старые файлы не удаляй. Преврати каждый в указатель: ссылка на issue и пометка, что состояние здесь больше не обновляется.

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

Проверь, что второго места для задач не осталось. Верни таблицу «файл → issue».

Где спотыкаются

Что это

Когда агентов много и они работают параллельно, лимиты GitHub кончаются быстро. Студию новостей я пробовал вести на задачах GitHub, и лимит кончался через полчаса.

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

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

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

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

Как это устроено у меня

Граф есть только у тех репозиториев, где много работы и агенты заняты круглые сутки. Девять графов живут на сервере, остальные на моём компьютере. Я перешёл на граф около двух месяцев назад. На одном проекте за день проходит около сотни задач. В графе потока Personal Corp около тысячи задач, открытых около полутора сотен.

1. Задачи заводит продюсер. Это обычный агент, которому в правилах папки записано: «Ты ничего не делаешь руками, только заводишь задачи». Я общаюсь только с ним, а он нанимает агентов на конкретные задачи. Он же единственная дверь для новых задач: мой запрос, даже срочный, идёт к нему. Если агент по ходу работы нашёл новую задачу, он заводит её сам и пишет, откуда она взялась.
2. Роли берут готовые задачи. Взятие ставит на задаче имя роли. Каждое действие в графе подписано ролью.
3. Исполнитель сдаёт задачу на проверку. Он пишет итог в комментарий и ставит статус «на проверку». Сам он свою задачу не закрывает.
4. Закрывает продюсер. В причине закрытия он называет, где лежит результат. На правки три круга, после третьего вопрос уходит мне одной строкой.
5. Продюсер работает тактами. В 08:00 и в 20:00 он принимает работу, раздаёт новую и пишет отчёт.
6. Я смотрю на две страницы. Первая называется «Что от тебя нужно». Это нумерованный список: у каждого пункта действие, что будет по умолчанию, срок и ссылка на задачу в графе. Вторая: дашборд графа. Своего дашборда у beads нет, поэтому я навайбкодил скилл, который его собирает. На дашборде видно, сколько всего задач, сколько сейчас у агентов в работе, сколько заблокировано и что ждёт моей проверки. Там же календарь потока. Страница пересобирается после каждого взятия и закрытия.

Роли и переписываются через граф: каждое сообщение лежит в нём задачей.

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

Ещё не сделаны три вещи: выгрузка итогов по эпикам в GitHub, перевод manager на граф и сводный граф штаба.

Пример: студия Нейрочела

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

Каждый шаг записывает в задачу, сколько на него ушло времени и денег. Поэтому я знаю, что один выпуск обходится в 20–30 долларов и примерно час с четвертью работы агентов. Дольше всего идут визуал и исследование. Самые дорогие шаги: визуал, сюжет и исследование, каждый по 6–7 долларов. Когда это записано, я могу попросить агента улучшить процесс. Он пробует варианты: что-то сломает, что-то сделает лучше, и по записям видно, что именно. Без таких записей улучшение превращается в гадание: попросил модель починить одно, она сломала другое.

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

Когда она окупается

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

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

Что нужно заранее

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

Как завести

Где спотыкаются

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

• Как агент ведёт мои дела: daily, manager, retroкак агент собирает план дня и записывает состояние задач
• Зачем агентам задачи, если им можно просто написать словамислой задач для команды агентов: штаб, роли, путь одной задачи
• GitHub Issues как контекст проектазадача хранит контекст между сессиями
• GitHub Projects как память агентадоска поверх задач многих репозиториев
• Задачи агента в нескольких репозиторияхкак задача проходит через несколько папок
• personal-corp-osоткрытые скиллы corp-new, grill-me, manager, daily и retro
• Эфир: агент поднимает биды и дашбордDeepSeek V4.1 Flash и DeepSeek Harness
• Эфир: биды как канал между агентамиClaude Opus 5.5, продюсер раздаёт задачи
• GitHub Docs: лимиты запросовсколько запросов пускает GitHub
• beadsграф задач для агентов; исходный код: github.com/gastownhall/beads

Штаб, отделы и задачи мы собираем руками в Personal Corp. Подробнее в боте.