Как трекать задачи агентом в нескольких репо

Сережа Рис · 22 April 2026

Если трек тянется больше двух недель и артефакты оседают в двух-трёх репо — это уже не issue. Это инициатива. Для таких случаев у GitHub есть готовая форма — её описали William Salazar и Kitty Chiu в Well-Architected библиотеке GitHub в феврале. Пять простых элементов делают трек читаемым и для тебя, и для AI-агента, который через месяц должен будет восстановить контекст.

Момент, когда становится нужна форма

Вот сценарий, в который я упёрся. Партнёрский образовательный трек на два месяца. Деки — в одном репо. Программа и учебные материалы — в другом. Карточка сделки в CRM — в третьем. Фронтенд лендинга партнёрки — в четвёртом. Бэкенд с биллингом и учётом участников — в пятом. Плюс внешние ссылки: Luma, Zoom, чат с партнёром.

Я спрашиваю у агента: «что у нас открыто по этому треку?». Агент честно отвечает: не знает. Задачи размазаны по репо, в каждом свой backlog, связывающей нити между ними нет.

Раньше я писал про GitHub Projects как память для AI-агента — там речь шла про один репо: доска = память, агент читает и отвечает. Когда работа в одном месте, этого хватает. Но как только инициатива разрастается на несколько репо, одной доски недостаточно. Нужна форма, в которой доска, эпик, лейблы и коммиты собираются в одно целое.

Пять элементов

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

         ┌────────────────────────────────┐
         │         PROJECT                │  ← общая доска на
         │  (всё по инициативе здесь)     │     всю инициативу
         └────────────┬───────────────────┘
                      │
                      ▼
              ┌───────────────┐
              │     ЭПИК      │  ← один issue в «родном»
              │  (overview)   │     репо инициативы
              └───┬───────┬───┘
                  │       │
       ┌──────────┘       └──────────┐
       ▼                             ▼
 ┌───────────┐              ┌───────────────┐
 │ задача в  │              │  задача в     │
 │  репо А   │              │    репо B     │
 └───────────┘              └───────────────┘

 LABEL: общий маркер во всех репо ────────────┐
 COMMIT-ПРЕФИКС: [slug] в каждом коммите ─────┤ ← агент
 TRACKING: блок-указатель в README-ах ────────┘   найдёт
                                                   всё

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

Эпик. Один issue в роли overview. Живёт в «родном» репо инициативы: для образовательной программы — в репо программы, для B2B — в CRM. В теле эпика — что, зачем, на какой срок, ссылки. Все остальные задачи трека — дети этого эпика, даже если физически они в других репо. Агент открывает эпик — видит дерево.

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

Префикс в коммитах. Каждый коммит, который касается инициативы, начинается с [slug]. Агент читает историю и восстанавливает хронологию. Без догадок, без разбора 40 коммитов вручную.

Блок Tracking. В каждом артефакте (README, CRM-карточка, папка программы) — маленькая секция «Tracking» с тремя указателями: ссылка на Project, на эпик, имя label. Не копия содержимого эпика, а именно указатели. Открываешь папку через месяц — сразу видишь, куда идти за контекстом.

Деталь, которая всё это скрепляет

Не пять элементов — а файл с правилами. Сами элементы это форма, но она не сработает, если каждый раз её изобретать заново. Скрепа — глобальный файл ~/.claude/rules/multi-repo-initiatives.md. Форма описана там один раз. Агент читает правила автоматически в каждой сессии. И когда появляется новая инициатива, подходящая под критерии, он сам применяет форму — не потому что я ему напомнил, а потому что она уже в его контексте.

Именно поэтому каждый коммит по треку получает нужный префикс, каждая новая задача — нужный label, каждый README — блок Tracking. Я не диктую это заново каждый раз. Диктует правило. Я только создаю задачу.

Технически сама возможность сцеплять задачи из разных репо появилась у GitHub в апреле 2025, когда sub-issues вышли в общий доступ, а в сентябре появился REST API и улучшения для работы между репо. Без этого дерево подзадач из разных мест было невозможно. Но это просто technical capability — инструмент. Скрепляющая деталь — правила в файле.

Как это появилось на живом треке

Сегодня я запустил такой трек — партнёрская образовательная программа на апрель-май. Пять репо: деки, программа, CRM, фронтенд лендинга, бэкенд с биллингом. Саму форму я не выдумал и не нашёл ручным гуглением. Попросил агента сделать research через Exa MCP — тот же приём, что использую для контент-плана:

Написал Claude Code на Opus 4.7:

Агент нашёл рекомендацию GitHub из Well-Architected, достал оттуда пять элементов и записал в ~/.claude/rules/multi-repo-initiatives.md. Правила из этой папки автоматически попадают в контекст любой сессии — про этот приём (AGENTS.md как источник правды) я уже писал. Когда пришло время применить — агент уже знал форму и предложил. Я согласился. Он создал Project, выбрал репо для эпика (программа → репо программы), завёл метку в пяти репо, расставил блоки Tracking.

Итог: три ссылки (доска, эпик, label) и работающий трек. Каждый коммит с префиксом, каждая новая задача подцепляется к эпику.

Через месяц

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

Агент сам идёт в Project, эпик, фильтрует label, смотрит git log с префиксом. Форма сама подсказывает ему, где контекст.

Что нужно, чтобы это заработало

Под капотом агент использует gh CLI для работы с GitHub — создания Project, эпика, лейблов, tracking-блоков. Если у тебя gh не установлен — скажи агенту поставить его, он сам разберётся с brew / apt / установщиком под твою систему. Дальше агент попросит авторизоваться в GitHub через браузер — это одноразово, потом токен живёт в системе. И третье — сам протокол в файле ~/.claude/rules/multi-repo-initiatives.md, чтобы агент видел его в контексте. Правила из этой папки загружаются автоматически, просить «прочитай» не нужно. Попроси агента сначала исследовать через Exa best practices multi-repo, а потом оформить их как файл-правило — так родилась и моя версия.

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

Когда НЕ применять

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

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

Почему это работает

Эту форму я не придумал и это не чей-то лайфхак из чата. Сам GitHub описал её как рекомендацию в своей Well-Architected библиотеке 24 февраля 2026 года — именно для случаев, когда работа идёт в нескольких репо одновременно. Пять элементов дают агенту структуру, которую он читает без догадок. Проект — общий статус. Эпик — overview. Метка — чем помечено. Префикс коммитов — хронология. Блок Tracking в README — куда вернуться за контекстом.

Тот же принцип, что я описывал в посте про синхронизацию Claude Code на четырёх компах — превращать инфраструктуру в источник правды, чтобы агент не догадывался, а читал. Там речь шла про конфиги. Здесь — про инициативы, которые растут больше чем на один репо.

Момент, когда инициатива перерастает один репо — это момент, когда ты даёшь треку форму. В ней трек останется читаемым через месяц, через три, через полгода. Агент — или ты сам — сможет вернуться и продолжить с того места, где остановился. Без раскопок. Без «а где мы вообще это обсуждали».

Об авторе

Подписаться на обновления — @sereja_tech