dotfiles/agents/.agents/skills/coordinator-loop

coordinator-loop

Координаторский цикл: проводит готовые issues через subagent-worker по TDD, держит границы задач, фильтрует находки и сам делает коммиты.

Зачем

Когда подряд идёт несколько связанных кодовых срезов, писать их «одним потоком» — значит терять границы задач и контроль над тем, что попало в коммит. Навык разделяет роли: один subagent-worker делает одну issue по TDD и не коммитит, а координатор проверяет, классифицирует находки и фиксирует результат. Навык узкий и работает только по явному вызову (/coordinator-loop): он не проектирует, он исполняет.

Где в потоке

coordinator-loop — исполнительное звено в середине цепочки, а не вся цепочка:

проектная документация    (/brainstorm-with-docs | /grill-with-docs)
        ↓
узкие проверяемые issues  (/to-issues)
        ↓
coordinator-loop          каждый issue: worker (/goal + /tdd) + независимое ревью
                          (запускает координатор) → индекс → коммит координатора;
                          в финале — ревью на соответствие замыслу + handoff
        ↓
приёмка                   ручной кросс-линия ревью (обычно Claude) + проверка человеком

• До скилла — проектирование. Сначала выверенная верхнеуровневая документация (/brainstorm-with-docs или /grill-with-docs): без неё issues не на чем основывать. Затем /to-issues режет её на узкие задачи. Именно здесь закладывается проверяемость результата (см. «Что получается»).
• Скилл — исполнение. Берёт готовые issues по одной и проводит каждую через цикл worker (/goal + /tdd) → независимое ревью (ревьюеры-наблюдатели, запускает координатор; триаж находок — в worker-е) → индекс → chain-level классификация → коммит координатора. Контекст координатора держится на индексах, не на diff'ах. В финале цепочки координатор прогоняет ревью на соответствие замыслу (целое против исходной спеки, сильной моделью на усиленном уровне) и пишет handoff, готовящий приёмку.
• После скилла — приёмка. Ревью другой модельной линией (Codex ревьюил Codex, так что кросс-линия — обычно ручной проход Клодом) плюс проверка человеком. Скилл её не автоматизирует — только передаёт эстафету с зафиксированным открытым риском.

Что делает и чего не делает

Делает: ведёт по одному issue за раз, держит границы, фильтрует находки, коммитит. Подробный цикл и роли — в SKILL.md.

Не делает:

• не создаёт проектную документацию и не принимает архитектурные решения — это предыдущий этап;
• не нарезает issues — это /to-issues;
• не отвечает за проверяемость результата — она закладывается при проектировании;
• не делает финальную приёмку — это ревью другим агентом плюс человек;
• не готовит набор issues «пачкой» автоматически — пока не цель.

Что получается

Результат прогона по одной issue — «пакет для проверки»:

• отдельный коммит на каждую issue с узким, в границах задачи, diff;
• финальный отчёт worker-а: какие файлы, какие тесты прогнаны, какие acceptance criteria закрыты, риски, git status;
• chain-level классификация (риск / вне скоупа); per-finding триаж («реально / ложно / чинить») делает worker по индексам ревьюеров.

Один issue = один проверяемый коммит плюс отчёт — так пост-цикловое ревью и ручная проверка остаются посильными.

Про проверяемость. Прошлый прогон показал: если итог цепочки можно принять только чтением diff, ручная проверка становится слишком дорогой. Лекарство — на уровне проектирования: у всего набора issues должен быть наблюдаемый конечный результат для приёмки (запись в Kafka-топик, строки в конкретной таблице, панель дашборда, вывод команды). Это ответственность /to-issues и брейншторма, не этого скилла. Координатор может отметить слабую проверяемость как риск и вернуть сигнал на уровень выше, но сам критерий приёмки не выдумывает.

Как вызвать

Только по явному запросу — навык узкий и не срабатывает сам:

/coordinator-loop

Статус и что дальше

Экспериментальный — прямое продолжение эксперимента с координатором субагентов, будет дорабатываться. Открытые вопросы (когда нужен отдельный ревьюер, обязательные промежуточные отчёты, бюджет worker-а) собраны в разделе «Открытые вопросы» файла references/rationale.md.

Что читать рядом

• SKILL.md — как координатор исполняет цикл (инструкция для агента).
• references/rationale.md — почему цикл устроен так: эмпирика эксперимента, находка про ревьюера другой родословной, открытые вопросы.