docs(skills): добавлен README для coordinator-loop
- Зачем: - дать человеку и будущей сессии быстрый вход: зачем навык, где в конвейере, что на выходе. - Что: - описаны место в потоке (brainstorm/grill -> to-issues -> coordinator-loop -> приёмка) и границы навыка. - зафиксировано, что проверяемость результата закладывается при проектировании, а не в этом скилле. - якоря контекста самодостаточны: ссылки только на SKILL.md и references/rationale.md. - Проверка: - открыть agents/.agents/skills/coordinator-loop/README.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
1 parent
aa3e362e4f
commit
2c70c97db3
1 file changed
+90
@@ -0,0 +1,90 @@
|
||||
# coordinator-loop
|
||||
|
||||
Координаторский цикл: проводит готовые issues через subagent-worker по TDD, держит
|
||||
границы задач, фильтрует находки и сам делает коммиты.
|
||||
|
||||
## Зачем
|
||||
|
||||
Когда подряд идёт несколько связанных кодовых срезов, писать их «одним потоком» —
|
||||
значит терять границы задач и контроль над тем, что попало в коммит. Навык
|
||||
разделяет роли: один subagent-worker делает **одну** issue по TDD и не коммитит, а
|
||||
координатор проверяет, классифицирует находки и фиксирует результат. Навык узкий и
|
||||
работает только по явному вызову (`/coordinator-loop`): он не проектирует, он
|
||||
исполняет.
|
||||
|
||||
## Где в потоке
|
||||
|
||||
coordinator-loop — исполнительное звено в середине цепочки, а не вся цепочка:
|
||||
|
||||
```text
|
||||
проектная документация (/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 → саморевью → классификация → ревью на риске → коммит.
|
||||
- **После скилла — приёмка.** Результат уходит на ревью другим агентом (обычно
|
||||
Claude — это и есть взгляд другой родословной) и на ручную проверку.
|
||||
|
||||
## Что делает и чего не делает
|
||||
|
||||
Делает: ведёт по одному issue за раз, держит границы, фильтрует находки, коммитит.
|
||||
Подробный цикл и роли — в [SKILL.md](SKILL.md).
|
||||
|
||||
Не делает:
|
||||
|
||||
- не проектирует и не пишет документацию — это upstream;
|
||||
- не нарезает issues — это `/to-issues`;
|
||||
- не отвечает за проверяемость результата — она закладывается при проектировании;
|
||||
- не делает финальную приёмку — это ревью другим агентом плюс человек;
|
||||
- не готовит набор issues «пачкой» автоматически — пока не цель.
|
||||
|
||||
## Что получается
|
||||
|
||||
Результат прогона по одной issue — «пакет для проверки»:
|
||||
|
||||
- **отдельный коммит на каждую issue** с узким, в границах задачи, diff;
|
||||
- **финальный отчёт worker-а**: какие файлы, какие тесты прогнаны, какие acceptance
|
||||
criteria закрыты, риски, `git status`;
|
||||
- **классификация находок** (чинили / риск / ложная тревога / вне скоупа).
|
||||
|
||||
Один issue = один проверяемый коммит плюс отчёт — так пост-цикловое ревью и ручная
|
||||
проверка остаются посильными.
|
||||
|
||||
**Про проверяемость.** Прошлый прогон показал: если «готово» у issue — это «прочитай
|
||||
diff», проверить всю цепочку руками не выходит. Лекарство — на уровне
|
||||
проектирования: формулировать issue так, чтобы «готово» было **наблюдаемым** (запись
|
||||
в Kafka-топик, строки в конкретной таблице, панель дашборда, вывод команды). Это
|
||||
ответственность `/to-issues` и брейншторма, **не** этого скилла. Если issue пришла
|
||||
без наблюдаемого критерия, координатор отметит это как **риск** («проверять придётся
|
||||
чтением кода») и вернёт сигнал на уровень выше, но сам проверку не выдумывает.
|
||||
|
||||
## Как вызвать
|
||||
|
||||
Только по явному запросу — навык узкий и не срабатывает сам:
|
||||
|
||||
```text
|
||||
/coordinator-loop
|
||||
```
|
||||
|
||||
## Статус и что дальше
|
||||
|
||||
Экспериментальный — прямое продолжение эксперимента с координатором субагентов,
|
||||
будет дорабатываться. Открытые вопросы (когда нужен отдельный ревьюер, обязательные
|
||||
промежуточные отчёты, бюджет кругов ревью) собраны в разделе «Открытые вопросы»
|
||||
файла [references/rationale.md](references/rationale.md).
|
||||
|
||||
## Что читать рядом
|
||||
|
||||
- [SKILL.md](SKILL.md) — как координатор исполняет цикл (инструкция для агента).
|
||||
- [references/rationale.md](references/rationale.md) — почему цикл устроен так:
|
||||
эмпирика эксперимента, находка про ревьюера другой родословной, открытые вопросы.
|
||||
Reference in new issue
Block a user