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 по /tdd → саморевью → ревью → коммит
        ↓
приёмка                   ревью другим агентом (обычно Claude) + ручная проверка

• До скилла — проектирование. Сначала выверенная верхнеуровневая документация (/brainstorm-with-docs или /grill-with-docs): без неё issues не на чем основывать. Затем /to-issues режет её на узкие задачи. Именно здесь закладывается проверяемость результата (см. «Что получается»).
• Скилл — исполнение. Берёт готовые issues по одной и проводит каждую через цикл worker → саморевью → классификация → ревью на риске → коммит.
• После скилла — приёмка. Результат уходит на ревью агентом другой модельной линии, если он доступен, и на ручную проверку.

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

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

Не делает:

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

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

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

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

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

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

Как вызвать

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

/coordinator-loop

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

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

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

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