From 8f6d9de9d5e8a3295db5b45e98d56896ecc0fbdc Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Sun, 14 Jun 2026 18:57:48 +0300 Subject: [PATCH] =?UTF-8?q?docs(skill):=20=D1=83=D1=82=D0=BE=D1=87=D0=BD?= =?UTF-8?q?=D0=B5=D0=BD=D0=BE=20=D0=BD=D0=B0=D0=B7=D0=BD=D0=B0=D1=87=D0=B5?= =?UTF-8?q?=D0=BD=D0=B8=D0=B5=20README=20coordinator-loop?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Зачем: - README должен описывать границы скилла без ложных ожиданий от runtime-поведения. - Что: - уточнена приёмка через агент другой модельной линии, если он доступен. - разделены проектная документация и документационные правки внутри issue. - проверяемость описана как свойство конечного результата цепочки. - Проверка: - просмотрен staged diff README coordinator-loop. --- .../.agents/skills/coordinator-loop/README.md | 21 ++++++++++--------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/agents/.agents/skills/coordinator-loop/README.md b/agents/.agents/skills/coordinator-loop/README.md index 6382988..b3bf0b3 100644 --- a/agents/.agents/skills/coordinator-loop/README.md +++ b/agents/.agents/skills/coordinator-loop/README.md @@ -32,8 +32,8 @@ coordinator-loop каждый issue: worker по /tdd → саморе закладывается проверяемость результата (см. «Что получается»). - **Скилл — исполнение.** Берёт **готовые** issues по одной и проводит каждую через цикл worker → саморевью → классификация → ревью на риске → коммит. -- **После скилла — приёмка.** Результат уходит на ревью другим агентом (обычно - Claude — это и есть взгляд другой родословной) и на ручную проверку. +- **После скилла — приёмка.** Результат уходит на ревью агентом другой модельной + линии, если он доступен, и на ручную проверку. ## Что делает и чего не делает @@ -42,7 +42,8 @@ coordinator-loop каждый issue: worker по /tdd → саморе Не делает: -- не проектирует и не пишет документацию — это upstream; +- не создаёт проектную документацию и не принимает архитектурные решения — это + предыдущий этап; - не нарезает issues — это `/to-issues`; - не отвечает за проверяемость результата — она закладывается при проектировании; - не делает финальную приёмку — это ревью другим агентом плюс человек; @@ -60,13 +61,13 @@ coordinator-loop каждый issue: worker по /tdd → саморе Один issue = один проверяемый коммит плюс отчёт — так пост-цикловое ревью и ручная проверка остаются посильными. -**Про проверяемость.** Прошлый прогон показал: если «готово» у issue — это «прочитай -diff», проверить всю цепочку руками не выходит. Лекарство — на уровне -проектирования: формулировать issue так, чтобы «готово» было **наблюдаемым** (запись -в Kafka-топик, строки в конкретной таблице, панель дашборда, вывод команды). Это -ответственность `/to-issues` и брейншторма, **не** этого скилла. Если issue пришла -без наблюдаемого критерия, координатор отметит это как **риск** («проверять придётся -чтением кода») и вернёт сигнал на уровень выше, но сам проверку не выдумывает. +**Про проверяемость.** Прошлый прогон показал: если итог цепочки можно принять +только чтением diff, ручная проверка становится слишком дорогой. Лекарство — на +уровне проектирования: у всего набора issues должен быть **наблюдаемый конечный +результат** для приёмки (запись в Kafka-топик, строки в конкретной таблице, панель +дашборда, вывод команды). Это ответственность `/to-issues` и брейншторма, **не** +этого скилла. Координатор может отметить слабую проверяемость как **риск** и вернуть +сигнал на уровень выше, но сам критерий приёмки не выдумывает. ## Как вызвать