---
name: coordinator-loop
disable-model-invocation: true
description: >-
  Координаторский цикл по цепочке готовых issue: на каждый — worker-субагент по TDD
  с ревью через claude-team-review, коммит делает координатор. Контекст координатора
  держится чистым — в него входит только индекс находок, не diff. Узкий навык, только
  по явному вызову /coordinator-loop.
---

# Координационный цикл субагентов

Ты — **координатор**. Реализацию не пишешь и код не читаешь. Ты ведёшь цепочку
зависимых issue: даёшь worker-у задачу с контекстом, принимаешь от него **индекс**,
классифицируешь на уровне цепочки и единственный делаешь коммиты.

**Ведущее правило — работай по индексу, а не по полному тексту.** Всё, что попадает в
твой контекст, — это **индекс**: находка, `файл:строка`, какой критерий нарушен,
минимальный путь воспроизведения. Полного diff, вывода тестов и нарратива ревью в твоём
контексте быть не должно — их читают субагенты у себя, а тебе возвращают индекс.
Верификацию находок делает ревьюер, не ты. (Исключение — состав diff на коммит-гейте:
`git diff --stat`/`--name-only`, какие файлы и в границах ли; это не полный текст, см.
шаг 6.) Проверяй себя каждый цикл: *в мой контекст попал полный текст вместо индекса?
Если да — это баг процесса.* Так контекст не пухнет, не компактится и не начинает
косячить — это главная болезнь, которую навык лечит.

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

Последовательные инженерные срезы с тестами и acceptance criteria, где соседние задачи
трогают близкий код и их нельзя безопасно параллелить. Не подходит: независимые задачи
(параллель), однофайловые правки, задачи без тестовой базы. Если цепочка не подходит —
скажи об этом пользователю, а не тяни цикл силой.

## Роли

- **Координатор** — ты. Порядок issue, богатый контракт, chain-level классификация по
  индексу, коммит-гейт, финальный handoff. **Код ради верификации не читаешь** — это
  ревьюер; на коммит-гейте смотришь лишь **состав** diff (не текст, см. шаг 6).
- **Worker** — субагент с одной целью (один issue). Гоняет `/goal` (петля
  план→код→тест→проверка готовности внешним ревьюером), меняет файлы, **не коммитит и не откатывает чужое**.
  Возвращает индекс + статус.
- **Ревьюер** — свежий субагент, которого запускает **сам worker** внутри `/goal` через
  `claude-team-review`. Читает код сам, докладу не верит. Триаж находок встроен в
  team-review (лид чинит нужное, отклоняет противоречащее требованиям). Нарративы ревью
  живут в контексте worker-а, до тебя доходит только его финальный индекс.

## Цикл на одну задачу

1. **Чистое дерево.** `git status --short` до старта. Чужие правки — стоп, спроси
   пользователя. Свои процессные — отдели docs-коммитом.
2. **Прочитай issue и зависимости.** Предыдущие в цепочке не закрыты — не начинай.
3. **Контракт worker-у** (см. ниже) и запусти **одного** worker-а.
4. **Дождись индекса.** Долго молчит — запроси промежуточный статус, не жди вслепую.
   Пришло push-уведомление — сразу обрабатывай, не крути опрос по кругу.
5. **Классифицируй по индексу — только chain-level** (см. «Классификация»).
6. **Коммит-гейт.** Прогони полный тест-сет, но в контекст возьми **только сводку**: код
   возврата и имена упавших тестов (`pytest -q`/хвост вывода), не полный вывод. Так же
   проверь **состав** diff (`git diff --stat`/`--name-only`: какие файлы, в границах ли —
   не полный текст) и коммить. Упали тесты — верни их worker-у по именам, трейсбеки в свой
   контекст не тащи. Это последняя точка контроля состава изменений.
7. **Закрой субагентов.** Следующий issue стартует в новом worker-е.

## Контракт задания worker-у

- **одна цель из issue** и критерий «готово» (acceptance criteria);
- **зачем**: ссылки на PRD/спеку/смежное. Без общего контекста worker триажит находки
  вслепую; с ним — способен судить сам (это и делает верификацию на воркере надёжной);
- **границы** — что трогать нельзя;
- методика **`/tdd`** (короткие срезы тест→код); точечные тесты в петле;
- **саморевью свежим взглядом** перед сдачей (отдельно от петли `/goal`) — worker
  критически перечитывает свою работу и правит очевидное. Базовый минимум даже без
  team-review: ошибаются все;
- **после реализации — `claude-team-review` по коду** (число проверок — по режиму ниже);
- **формат отчёта — индекс**: находка/изменение, `файл:строка`, минимальный repro, какой
  критерий; запрет вставлять diff и полный вывод тестов;
- **статус-контракт** `DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT` — worker сам
  стопорится на архитектурной неясности, а не додумывает молча;
- **запрет коммита** и **запрет отката чужого**.

Цель worker-а — **одна** (один issue = одна петля). Не запускай `/goal` на всю цепочку
сразу: от координатора нужна остановка на контрольных точках, а не «закрыть всё любой ценой».

## Режимы ревью — рычаг стоимости

Две проверки **разными субагентами** — по задаче и по коду — ловят непересекающиеся
множества находок, но это расход токенов (по бюджету, не по контексту координатора).
Плати по риску, не на каждой мелочи:

- **тривиальный issue** — team-review не зови; ревью только петлёй `/goal` (её внешний
  ревьюер готовности) **плюс отдельное перечитывание своей работы свежим взглядом**
  worker-ом — это не встроенный шаг `/goal` (ошибаются все);
- **обычный (дефолт)** — один прогон `claude-team-review` **по коду**; соответствие
  issue/спеке держит петля `/goal`;
- **рискованный / гейт** — два прогона разными субагентами: **по задаче** (сделал ли то,
  что в issue/спеке) + **по коду** (тонкие баги, межмодульное). Проверку по задаче можно
  на дешёвой модели — модель по роли.

Порог риска: state и сериализация, формат данных, интеграция сервиса, статистические
модели, честность документации, межмодульные инварианты.

## Классификация находок

Per-finding триаж («реально / ложно / чинить») уже делает `claude-team-review` внутри
worker-а — **не переписывай его**. Ты решаешь только **на уровне цепочки**, читая индекс:

- **записать риском** — важно помнить, текущий коммит не блокирует (реестр рисков цепочки);
- **вне скоупа** — пригодится позже, отдать в следующий issue.

## Финал цепочки

1. **Ревью на соответствие замыслу** (рекомендуется для любой нетривиальной цепочки).
   В самом конце — один прогон субагента-ревьюера **сильной моделью** (не дешёвой):
   читает **всю** реализацию против **исходной спеки/PRD** и проверяет, не разъехалась ли
   поэтапная реализация с замыслом. Возвращает индекс. Один прогон добавляет к общей
   стоимости немного, а ловит дрейф, который per-issue срезы не видят — ни одно ревью
   отдельной задачи не сверяло целое с целым замыслом. Это Codex (одна линия): берёт
   **охват** (целое против замысла), но не кросс-линию — глубокие сквозные слепые пятна
   линии остаются на п.2.
2. **Handoff, а не ревью.** Последний акт координатора — записка (`.scratch/<feature>/…`
   или через `/handoff`), которая **готовит опциональный ручной кросс-линия ревью**:
   - индекс построенного по issue (`файл:строка` ключевых стыков);
   - что покрыто ревью — **одна линия** (Codex ревьюил Codex);
   - **открытый риск**: межмодульные инварианты и форма распределения ревью другой
     родословной **не покрыты** → рекомендуется ручной проход Клодом.

   Даже если проход не запустят — дыра остаётся **видимым задокументированным риском**, а
   не тихим слепым пятном. Запустят — Клод получит нацеленный бриф, а не холодное перечитывание.

## Родословная — почему кросс-линия остаётся риском

Внутри Кодекса ревьюер — тоже Codex (одна линия), а свежий контекст не снимает общую
слепоту линии к сквозным дефектам — поэтому кросс-линия (Claude по написанному Codex)
остаётся ручным опциональным проходом **вне** скилла, не автоматизируется. Координатор её
не выполняет, а фиксирует непокрытый риск в handoff (финал, шаг 2). Эмпирика —
[references/rationale.md](references/rationale.md).

## Чек-лист координатора

- [ ] Дерево чистое перед стартом; чужие правки согласованы, процессные отделены.
- [ ] Worker получил один issue + **зачем** (PRD/спека), границы, `/tdd`, режим ревью,
      индекс-формат, статус-контракт, запрет коммита и отката; саморевью свежим взглядом сделан.
- [ ] В мой контекст вошёл **только индекс** — ни diff, ни логов, ни нарратива ревью.
- [ ] Chain-level классификация сделана по индексу (риск / вне скоупа).
- [ ] Коммит сделан координатором, diff узкий и в границах; полный тест-сет на гейте — в контекст только сводка (pass/fail + упавшие), не вывод.
- [ ] В конце цепочки — ревью на соответствие замыслу (сильная модель); дрейф от спеки проверен.
- [ ] Финальный handoff готовит кросс-линия ревью; непокрытая родословная — открытый риск.
- [ ] Субагенты закрыты; `git status` чист на выходе.

## Подробнее

- [references/rationale.md](references/rationale.md) — эмпирика: какой шаг какой класс
  дефектов ловит, центральная находка про родословную, открытые вопросы.
- `handoffs/` — экономия контекста (два пожара: контекст vs лимит), наблюдаемость и
  непроверенные кандидаты-фиксы (файловый канал, демоушн закрытых issue, точечные тесты).

## Источники упомянутых скиллов

- `/to-issues`, `/tdd`, `/claude-team-review` — инженерные скиллы (набор Matt Pocock и внутренние).
- `/goal` — встроенная петля Codex (план→код→тест→проверка готовности внешним ревьюером).