@gian-tiaga/eda 0.8.1 → 0.8.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (5) hide show
  1. package/README.md +5 -5
  2. package/package.json +1 -1
  3. package/skills/eda-fix-by-review.md +15 -9
  4. package/skills/eda-plan-polish.md +97 -133
  5. package/skills/eda-polish.md +3 -3
package/README.md CHANGED
@@ -39,14 +39,14 @@ eda update-all ~/Code
39
39
  | `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/roadmaps/` |
40
40
  | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. В дефолтном режиме ведёт исследование как диалог: факты собирает сам, а значимые развилки выносит тебе с рекомендацией. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
41
41
  | `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. `docs/rules.md` и `docs/arch.md` использует как обязательную рамку, а не справочный контекст: план должен строго следовать правилам и архитектуре. В плане явно фиксирует контракты БД/API, если задача их затрагивает. Затем три параллельных субагента/модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
42
- | `eda-plan-polish` | Полирует уже готовый план до оценки 95/100 или заданного порога. Сначала основной агент оценивает план; если оценка ниже порога, запускает три изолированных параллельных plan-polish агента, анализирует их предложения, правит только файл плана и повторяет цикл до качества или лимита | `docs/plans/` |
42
+ | `eda-plan-polish` | Полирует уже готовый план до оценки 95/100 или заданного порога. Каждая итерация сразу запускает три изолированных параллельных агента на быстрой, кодовой и флагманской моделях. Все агенты получают один общий промпт и проверяют весь план целиком. Основной агент после их ответов выставляет оценку, анализирует предложения, правит только файл плана при оценке ниже порога и не запускает проверки проекта | `docs/plans/` |
43
43
  | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Перед правками читает план, `docs/rules.md` и `docs/arch.md`; правила и архитектура обязательны к исполнению. Если шаг плана им противоречит, останавливается и спрашивает. Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
44
44
  | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
45
45
  | `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ, но в файл пишет только проблемы: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Если запущен без аргументов, ревьюит незакоммиченный `git diff HEAD` без проверки плана. Не перечисляет выполненную работу. В обычном режиме после черновика передаёт файл в `eda-review-check`; с флагом `draft` сохраняет только первичное ревью без субагентов | `docs/reviews/` |
46
46
  | `eda-review-check` | Проверяет готовое ревью из `docs/reviews/` специализированными субагентами: архитектуру, правила, выполнение плана при указанном plan-файле и при включённой настройке качество кода. В строгом режиме добавляет кросс-ревью между Claude и Codex. Сам применяет подтверждённые замечания к файлу ревью, но не правит код | `docs/reviews/` |
47
- | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
47
+ | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — все сразу. Optional-пункты в обычном режиме спрашивает, а в `apply-optional` сам решает: применяет полезные, отклонённые обосновывает в отчёте. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
48
48
  | `eda-manual-test` | Делает ручную smoke/acceptance-проверку после изменений: API прогоняет через `curl`/HTTP-запросы, фронт — через Playwright или доступную browser automation. Сам строит чеклист из входа, плана или diff, запускает очевидные dev/API-серверы и сохраняет QA-отчёт. Не правит код, не пишет автотесты и не коммитит | `docs/manual-tests/` |
49
- | `eda-polish` | Оркестрирует доводку изменений: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional` и повторяет цикл до оценки 95/100 или лимита 5 итераций. Каждый шаг идёт в изолированном субагенте или отдельном CLI-процессе. Не коммитит | `docs/reviews/`, `docs/review-fixes/` |
49
+ | `eda-polish` | Оркестрирует доводку изменений: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional` и повторяет цикл до оценки 95/100 или лимита 5 итераций. Обязательные замечания чинятся все, optional-пункты fix-агент применяет или отклоняет сам с обоснованием. Каждый шаг идёт в изолированном субагенте или отдельном CLI-процессе. Не коммитит | `docs/reviews/`, `docs/review-fixes/` |
50
50
  | `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
51
51
  | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
52
52
  | `eda-worktree` | Создаёт git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базу берёт из аргумента или спрашивает | соседняя папка `{name}-work-{n}` |
@@ -69,7 +69,7 @@ eda update-all ~/Code
69
69
  | `eda-review` | `draft` | Сохраняет первичное ревью со статусом `draft` и не запускает `eda-review-check`, субагентов и кросс-CLI | Когда ревью нужно как черновик для внешней оркестрации, например `eda-polish` |
70
70
  | `eda-review` | `strict` | После draft-ревью запускает `eda-review-check strict`: специализированные субагенты плюс соседний CLI; доправляет ревью по подтверждённым замечаниям | Ревью важных PR; когда нужен максимальный охват |
71
71
  | `eda-review-check` | `strict` | Проверяет уже готовое ревью специализированными субагентами и затем отдаёт его соседнему CLI на дополнительный круг проверки | Когда черновик ревью уже есть и нужно усилить только проверку ревью |
72
- | `eda-fix-by-review` | `apply-optional` | Применяет не только обязательные, но и пункты «на усмотрение автора» без дополнительного вопроса | Для заранее согласованной автоматической доводки, прежде всего внутри `eda-polish` |
72
+ | `eda-fix-by-review` | `apply-optional` | Применяет все обязательные пункты, а пункты «на усмотрение автора» разбирает без вопроса: применяет выбранные и отклоняет нецелесообразные с причиной | Для автономной доводки, прежде всего внутри `eda-polish` |
73
73
 
74
74
  ---
75
75
 
@@ -147,7 +147,7 @@ roadmap ────────> explore ─────> plan ───> plan-
147
147
  fix ─────────────> manual-test
148
148
 
149
149
  polish = review draft ─> review-check ─> fix-by-review apply-optional ─> повтор до нужной оценки
150
- plan-polish = оценка плана ─> 3 plan-polish агента ─> правка плана ─> повтор до 95/100
150
+ plan-polish = 3 полных ревью плана разными моделями ─> оценка ─> правка плана ─> повтор до 95/100
151
151
 
152
152
  automate может запускаться от review, fix-by-review или fix.
153
153
  ```
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@gian-tiaga/eda",
3
- "version": "0.8.1",
3
+ "version": "0.8.4",
4
4
  "description": "Набор скилов eda-* для Claude Code и Codex CLI: start, roadmap, explore, plan, plan-polish, execute, fix, review, review-check, fix-by-review, manual-test, polish, send-review, commit, worktree, merge-worktree, docs, automate",
5
5
  "type": "module",
6
6
  "bin": {
package/skills/eda-fix-by-review.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: eda-fix-by-review
3
- description: 'Применяет замечания из ревью (`docs/reviews/...`) или из текста рядом с вызовом к коду. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно, кроме явного режима `apply-optional`, где применяет их без вопроса. «Не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью и не коммитит.'
3
+ description: 'Применяет замечания из ревью (`docs/reviews/...`) или из текста рядом с вызовом к коду. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им. Все пункты «править обязательно» правит сразу. Пункты «на усмотрение» в обычном режиме выносит пользователю, а в `apply-optional` решает сам: применяет полезные и отклоняет нецелесообразные с причиной. «Не править» пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью и не коммитит.'
4
4
  ---
5
5
 
6
6
  # Скил: Исправитель по ревью (eda-fix-by-review)
@@ -15,9 +15,9 @@ description: 'Применяет замечания из ревью (`docs/revie
15
15
 
16
16
  ## Режим запуска
17
17
 
18
- Обычный режим: «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
18
+ Обычный режим: все пункты «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
19
19
 
20
- Режим `apply-optional`: применяешь «Править обязательно» и «На усмотрение автора» без вопроса. Этот режим нужен для `eda-polish`, где пользователь заранее разрешил автоматическую доводку по optional-замечаниям. Пункты «Не править» всё равно пропускаешь.
20
+ Режим `apply-optional`: все пункты «Править обязательно» применяешь без исключений. По каждому пункту «На усмотрение автора» сам принимаешь решение без вопроса: применяешь, если правка явно улучшает качество, снижает риск или стоит дёшево; отклоняешь, если польза спорная, правка расширяет scope, создаёт риск регрессии, конфликтует с правилами/архитектурой или требует продуктового решения. Название режима означает «разобрать optional без вопроса», а не «механически применить все optional». Пункты «Не править» всё равно пропускаешь.
21
21
 
22
22
  ## Главные правила
23
23
 
@@ -25,7 +25,7 @@ description: 'Применяет замечания из ревью (`docs/revie
25
25
  2. **Интерактивные вопросы** — по разделу ниже.
26
26
  3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
27
27
  4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
28
- 5. **Логика по группам ревью:** «Править обязательно» — правишь сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`; «Не править» — пропускаешь и отмечаешь в отчёте.
28
+ 5. **Логика по группам ревью:** «Править обязательно» — правишь все сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`, где сам решаешь применить или отклонить; «Не править» — пропускаешь и отмечаешь в отчёте.
29
29
  6. **Тесты — внутри той же правки.** Замечание касается поведения → правка кода + тесты к ней в одном шаге, точечно прогнал.
30
30
  7. **Финальный полный прогон тестов и линтеров — обязателен.** В конце, не на каждой правке.
31
31
  8. **Простой язык** в формулировках и сообщениях. **Таблицы** для отчёта о фиксах.
@@ -37,7 +37,7 @@ description: 'Применяет замечания из ревью (`docs/revie
37
37
  - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
38
38
  - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
39
39
  - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
40
- - Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
40
+ - Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`, где решение принимает сам агент; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
41
41
 
42
42
  ## Этапы
43
43
 
@@ -55,8 +55,8 @@ description: 'Применяет замечания из ревью (`docs/revie
55
55
 
56
56
  ### 3. Применить замечания
57
57
  Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
58
- - **Править обязательно** → правишь сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
59
- - **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` применяй сразу без вопроса.
58
+ - **Править обязательно** → правишь все пункты сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
59
+ - **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` сам реши по каждому пункту, применяй только принятые решения без вопроса, а отклонённые фиксируй с причиной.
60
60
  - **Не править** → пропусти.
61
61
 
62
62
  Останавливайся и спрашивай, если: замечание непонятно / противоречит коду / задевает рискованное вне ревью (удаление, миграции, секреты).
@@ -90,22 +90,28 @@ status: done
90
90
  |---|-----------|-------|-------|--------|
91
91
  | 1 | <кратко из ревью> | `path/a.py` | `path/test_a.py` (2 ✓) | ✓ применено |
92
92
  | 2 | ... | ... | — | ✓ применено |
93
- | 3 | ... | — | — | ✗ пропущено (на усмотрение, пользователь отклонил) |
93
+ | 3 | ... | — | — | ✗ отклонено (на усмотрение, причина: <короткое обоснование>) |
94
94
  | 4 | ... | — | — | — не править (по решению ревью) |
95
95
 
96
+ ## Решения по optional
97
+ - **Принято:** <номера и коротко почему>
98
+ - **Отклонено:** <номера и коротко почему, чтобы следующие ревьюеры не повторяли это как открытое замечание>
99
+
96
100
  ## Финальная проверка
97
101
  - **Тесты:** `<команда>` — ✓ / ✗
98
102
  - **Линтер:** `<команда>` — ✓ / ✗
99
103
  - **Заметки:** <если что-то осталось не зелёным — почему>
100
104
  ```
101
105
 
106
+ Если `$REVIEW_SOURCE=review_file` и в режиме `apply-optional` отклонены пункты «На усмотрение автора», в добавляемом в ревью разделе `## Применённые фиксы` после ссылки на отчёт добавь короткий список `Отклонённые optional-решения` с причинами. Это нужно, чтобы следующие ревьюеры видели уже принятое решение и не повторяли тот же optional-пункт без новых аргументов.
107
+
102
108
  ### 6. Финал
103
109
  Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к отчёту о фиксах, сколько применено / пропущено / отклонено, результат финальной проверки, состояние git («не закоммичено»). Подсказка дальше — `eda-commit`.
104
110
 
105
111
  ## Чего НЕ делать
106
112
  - Делать само ревью — это `eda-review`.
107
113
  - Коммитить, пушить — это `eda-commit`.
108
- - Применять «на усмотрение» молча без явного режима `apply-optional`.
114
+ - Применять или отклонять «на усмотрение» молча без явного режима `apply-optional` или ответа пользователя.
109
115
  - Игнорировать «не править» и пробовать «на всякий случай» — это нарушает решение ревью.
110
116
  - Гонять полный сьют и линтеры на каждой правке — только в конце.
111
117
  - Пропускать финальную проверку.
package/skills/eda-plan-polish.md CHANGED
@@ -1,150 +1,136 @@
1
1
  ---
2
2
  name: eda-plan-polish
3
- description: 'Итерационно полирует готовый план из `docs/plans/...` до оценки 95/100 или заданного порога. Сначала основной агент оценивает план по шкале 0–100. Если оценка ниже порога, запускает три изолированных параллельных plan-polish агента, получает конкретные предложения правок, сам принимает или отклоняет замечания, правит только файл плана и пересчитывает оценку. Не создаёт план с нуля, не меняет код, конфиги и зависимости.'
3
+ description: 'Полирует готовый план из `docs/plans/...` до оценки 95/100 или заданного порога. Каждая итерация начинается с трёх изолированных параллельных агентов на быстрой, кодовой и флагманской моделях. Все агенты получают один общий промпт и проверяют весь план целиком. Основной агент читает их результаты, выставляет итоговую оценку, принимает или отклоняет предложения, правит только файл плана, не меняет код и не запускает проверки.'
4
4
  ---
5
5
 
6
6
  # Скил: Полировка плана (eda-plan-polish)
7
7
 
8
- Берёшь готовый план из `docs/plans/`, оцениваешь его по шкале 0–100 и доводишь до качества, достаточного для `eda-execute`. Порог по умолчанию — `95`: если план уже набирает 95 или выше, фиксируешь оценку и ничего не меняешь. Если ниже — запускаешь цикл полировки через три изолированных агента, применяешь принятые замечания, снова оцениваешь план и повторяешь до порога или лимита.
8
+ Берёшь готовый план из `docs/plans/` и доводишь его до состояния, когда его можно передать в `eda-execute`. Порог по умолчанию — `95`, лимит по умолчанию — `5` итераций.
9
9
 
10
- Основной агент остаётся редактором: он не вставляет предложения механически, а решает, какие принять, какие отклонить и какие требуют вопроса пользователю.
10
+ Каждая итерация начинается с трёх независимых моделей с одним и тем же промптом. Основной агент не ставит предварительную оценку сам: он оценивает план только после ответов агентов, принимает или отклоняет предложения, правит план при оценке ниже порога и запускает новую итерацию.
11
11
 
12
12
  ## Вход из сообщения пользователя
13
13
 
14
- Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: путь к плану, название или часть названия, «последний план», желаемый порог, лимит итераций, ограничения, прямые указания и запреты на типы правок.
14
+ Текст рядом с вызовом скилла — главный вход. Разбери путь к плану, название или часть названия, «последний план», порог, лимит итераций, ограничения и прямые запреты.
15
15
 
16
- Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск полировать не тот план. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
16
+ Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, найдено несколько равных вариантов или есть риск полировать не тот план. Старую историю не считай входом, если пользователь не связал её с текущим вызовом явно.
17
17
 
18
- ## Режим запуска
18
+ ## Настройки
19
19
 
20
- Порог качества по умолчанию — `95`. Пользователь может переопределить его в текущем сообщении: `до 90`, `threshold 90`, `цель 90`. Допустимые значения — от `1` до `100`.
20
+ - Порог качества по умолчанию — `95`, можно переопределить словами `до 90`, `threshold 90`, `цель 90`.
21
+ - Лимит по умолчанию — `5` итераций, можно переопределить словами `лимит 3`, `max iterations 3`, `не больше 3 кругов`.
22
+ - Оценка `95–100` означает готовность к исполнению; `80–94` — нужно уточнить; `60–79` — рискованный план; ниже `60` — нужен серьёзный переплан или вопросы пользователю.
21
23
 
22
- Лимит по умолчанию — `5` итераций полировки. Пользователь может явно задать меньший или больший лимит словами `лимит 3`, `max iterations 3`, `не больше 3 кругов`.
24
+ ## Жёсткие правила
23
25
 
24
- Оценка плана:
25
- - `95–100` — план готов к исполнению, агенты полировки не нужны;
26
- - `80–94` — план в целом рабочий, но требует уточнений перед `eda-execute`;
27
- - `60–79` — план рискован: есть пропуски, общие шаги или слабые критерии готовности;
28
- - `<60` — план нельзя исполнять без серьёзной переработки или вопросов пользователю.
29
-
30
- ## Главные правила
31
-
32
- 1. **Не создаёшь план с нуля.** Входом всегда является уже сохранённый файл `docs/plans/...`.
33
- 2. **Не правишь код, миграции, конфиги и зависимости.** Можно менять только выбранный файл плана.
34
- 3. **Сначала оцениваешь план сам.** До запуска агентов поставь текущую оценку 0–100 и коротко зафиксируй причины.
35
- 4. **Агенты запускаются только если оценка ниже порога.** Если план набрал `threshold` или выше, не запускай изолированные проверки ради формы.
36
- 5. **Три изолированных plan-polish агента обязательны в каждой итерации ниже порога.** Запусти `completeness-polisher`, `rules-arch-polisher` и `execution-readiness-polisher` параллельно, до чтения любого результата.
37
- 6. **Главный редактор плана — ты.** Субагенты предлагают конкретные правки; решение применить, отклонить или спросить пользователя принимаешь сам.
38
- 7. **Не добавляй неподтверждённые существенные решения.** Новые БД/API-контракты, зависимости, архитектурные развилки, auth/permissions/payments/secrets/персональные данные и миграции можно добавить только если они уже подтверждены в плане, research, `docs/rules.md`, `docs/arch.md` или ответом пользователя.
39
- 8. **План должен остаться планом.** Не превращай его в отчёт ревью: принятые замечания встраивай в целевые разделы, а журнал решений держи коротким в конце.
40
- 9. **Структуру `eda-plan` сохраняй.** Не удаляй обязательные разделы `Целевой алгоритм`, `Контракты реализации`, `Фазы выполнения`, `Тесты`, `Логирование`, если они есть или должны быть по формату `eda-plan`.
41
- 10. **Останавливайся на блокерах.** Если качество не растёт два круга подряд, агенты предлагают только неподтверждённые развилки, нужен ответ пользователя или достигнут лимит — остановись и честно назови причину.
26
+ 1. Работай только с готовым файлом плана в `docs/plans/`.
27
+ 2. Не правишь код. Менять можно только выбранный файл плана; миграции, конфиги, зависимости и lock-файлы не трогай.
28
+ 3. Не запускай проверки и исполняющие команды: `test`, `lint`, `build`, `typecheck`, `check`, `dev`, `start`, миграции, seed, smoke-тесты, браузерные проверки и API-запросы. При полировке плана можно читать файлы и искать по коду, но нельзя проверять проект выполнением команд.
29
+ 4. Не ставь предварительную оценку без агентов. Сразу запускай три изолированных агента параллельно, одним batch, до чтения любого результата.
30
+ 5. Итоговую оценку 0–100 выставляй только после чтения результатов всех трёх агентов.
31
+ 6. У всех трёх агентов один общий промпт: каждый проверяет весь план целиком, а не отдельную роль.
32
+ 7. Не добавляй неподтверждённые существенные решения: БД/API-контракты, зависимости, архитектурные развилки, auth/permissions/payments/secrets/персональные данные и миграции.
33
+ 8. Сохраняй структуру `eda-plan`: `Целевой алгоритм`, `Контракты реализации`, `Фазы выполнения`, `Тесты`, `Логирование`, если эти разделы есть или должны быть по формату.
34
+ 9. Если качество не растёт два круга подряд, достигнут лимит или нужен ответ пользователя, остановись и честно назови причину.
42
35
 
43
36
  ## Интерактивные вопросы
44
37
 
45
- Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
38
+ Когда инструкция говорит `AskUserQuestion`, это блокирующий вопрос:
46
39
  - Claude Code: используй `AskUserQuestion`.
47
- - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
48
- - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
49
- - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
40
+ - Codex interactive: если доступен `request_user_input`, используй его; иначе задай один короткий вопрос в чат с вариантами 1–3 и остановись до ответа.
41
+ - Codex exec / non-interactive: не читай stdin; если без ответа нельзя безопасно продолжать, заверши со статусом `blocked: нужен ответ пользователя`.
50
42
 
51
- ## Этапы
43
+ ## Процесс
52
44
 
53
- ### 1. Выбрать план и прочитать контекст
45
+ ### 1. Выбрать план
54
46
 
55
47
  Определи `$PLAN_FILE`:
56
- - если пользователь указал путь к плану — используй его;
57
- - если указал название или часть названия — найди совпадение в `docs/plans/`;
58
- - если написал «последний план» — возьми самый новый файл из `docs/plans/`;
59
- - если входа нет — `AskUserQuestion` со списком последних файлов из `docs/plans/`;
60
- - если `docs/plans/` отсутствует или пуста — остановись со статусом `blocked: нужен готовый план`.
61
-
62
- Прочитай `$PLAN_FILE` целиком. Из front matter извлеки `status`, `mode`, `plan_size`, `test_strategy`, `logging_strategy`, `sources.rules`, `sources.arch`, `sources.research`, `meta_reviewers`.
63
-
64
- Прочитай `docs/rules.md`, `docs/arch.md`, если они есть. Если в `sources.research` указан файл исследования — прочитай его. Если план ссылается на конкретные файлы, модули, API, миграции или тесты, открой достаточно релевантного кода, чтобы понять реализуемость плана.
65
-
66
- ### 2. Первичная оценка плана
67
-
68
- Поставь `$SCORE` по шкале 0–100. Оцени:
69
- - следование `docs/rules.md` и `docs/arch.md`;
70
- - отсутствие неподтверждённых существенных решений;
71
- - конкретность `Целевого алгоритма`;
72
- - полноту `Контрактов реализации`, особенно БД/API/внешних контрактов;
73
- - исполнимость фаз: цель, шаги, результат, сценарии тестирования, проверка;
74
- - применение `test_strategy` и `logging_strategy`;
75
- - отсутствие альтернатив вида «выбрать», «решить», «уточнить позже»;
76
- - возможность передать план в `eda-execute` без нового исследования.
77
-
78
- Если `$SCORE >= threshold`, добавь или обнови в конце плана короткий раздел:
48
+ - указан путь — используй его;
49
+ - указано название или часть названия — найди совпадение в `docs/plans/`;
50
+ - сказано «последний план» — возьми самый новый файл из `docs/plans/`;
51
+ - входа нет — спроси, показав несколько последних планов;
52
+ - `docs/plans/` нет или она пуста — остановись: `blocked: нужен готовый план`.
79
53
 
80
- ```markdown
81
- ## Оценка plan-polish
82
- - **Итоговая оценка:** <score>/100
83
- - **Порог:** <threshold>/100
84
- - **Итерации:** 0
85
- - **Решение:** план уже готов к исполнению, изолированные агенты не запускались.
86
- ```
54
+ Прочитай только выбранный план целиком. По front matter извлеки `status`, `mode`, `plan_size`, `test_strategy`, `logging_strategy`, `sources.rules`, `sources.arch`, `sources.research`, `meta_reviewers`.
87
55
 
88
- После этого переходи к финалу.
56
+ Сам не читай `docs/rules.md`, `docs/arch.md`, `sources.research` и релевантный код на этом шаге. Передай эти пути агентам в общем промпте: проверка правил, архитектуры, research и кода — их работа. Основной агент может открыть внешний файл только позже и точечно, если нужно проверить конкретное предложение агента перед правкой плана. Не запускай проверки.
89
57
 
90
- ### 3. Итерационный цикл полировки
58
+ ### 2. Запустить три модели
91
59
 
92
- Если `$SCORE < threshold`, повторяй до достижения порога или лимита.
60
+ В каждой итерации, включая первую, запускай в одном batch три изолированных агента:
93
61
 
94
- #### 3.1. Запустить три изолированных агента
62
+ | Уровень | Claude Code (`Agent` tool) | Codex interactive (`spawn_agent`) | Codex exec / non-interactive fallback |
63
+ |---|---|---|---|
64
+ | Быстрая модель | `haiku` | `gpt-5.4-mini` | `gpt-5.4-mini` |
65
+ | Кодовая модель | `sonnet` | `gpt-5.3-codex` | `gpt-5.3-codex` |
66
+ | Флагманская модель | `opus` | `gpt-5.5` | `gpt-5.5` |
95
67
 
96
- Запусти **в одном сообщении и одним batch** три роли. Не запускай сначала одного агента, не читай его ответ и не стартуй остальных после этого.
68
+ - Claude Code: используй `Agent` tool с моделями из таблицы.
69
+ - Codex interactive: если доступен `spawn_agent` или аналог, используй субагентов с моделями из таблицы. Не используй отдельные `codex exec`, когда субагенты доступны.
70
+ - Codex exec / non-interactive fallback: если субагентов нет, запусти три `codex exec --model <id>` параллельно одной Bash-командой с `&` и общим `wait`.
71
+ - Если модель недоступна, возьми ближайшую code-capable модель того же уровня. Не заменяй три уровня одной моделью.
97
72
 
98
- Роли:
99
- - `completeness-polisher` — предлагает конкретные правки для пропущенных шагов, состояний UI/API, миграций/backfill/rollback, edge cases, документации и эксплуатационных шагов.
100
- - `rules-arch-polisher` — предлагает конкретные правки для соответствия `docs/rules.md`, `docs/arch.md`, границам модулей, локальным запретам, архитектурным решениям, API/БД-контрактам и требованиям к проверкам.
101
- - `execution-readiness-polisher` — предлагает конкретные правки, чтобы `eda-execute` мог выполнить план без нового исследования: фазы, критерии готовности, порядок работ, тестовые сценарии, команды проверки, логирование и удаление альтернатив вида «выбрать» или «решить».
73
+ Общий промпт каждому агенту:
102
74
 
103
- Модели:
104
- - Claude Code: запускай все роли через `Agent` tool, предпочтительно на `model: "sonnet"`.
105
- - Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), запускай все роли через него, предпочтительно на `gpt-5.3-codex`.
106
- - Codex exec / неинтерактивный fallback: если инструмента субагентов нет, запускай три `codex exec --model gpt-5.3-codex` параллельно одной Bash-командой с `&` и общим `wait`.
107
- - Если указанный идентификатор модели недоступен, возьми ближайшую code-capable модель того же уровня. Не используй одну и ту же беседу вместо изолированных агентов.
75
+ ```text
76
+ Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, sources.research при наличии и релевантные файлы, на которые ссылается план.
108
77
 
109
- Каждому агенту дай путь к `$PLAN_FILE`, текущий `$SCORE`, `$threshold`, номер итерации, `docs/rules.md`, `docs/arch.md`, `sources.research` при наличии и список релевантных файлов, найденных при чтении плана. Проси открывать код только в рамках своей роли и не править файлы.
78
+ Проверь весь план целиком: исполнимость, соответствие правилам и архитектуре, полноту целевого алгоритма, БД/API/внешние контракты, фазы, тестовые сценарии, логирование, неподтверждённые решения, скрытые риски и места, где eda-execute не сможет продолжить без нового исследования.
110
79
 
111
- Формат ответа агентов:
80
+ Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы.
112
81
 
113
- ```text
114
- score: <оценка плана 0–100 по мнению агента>
115
- + Применить: <конкретная правка и куда встроить>
82
+ Ответь кратко:
83
+ score: <0–100>
84
+ + Принять: <конкретная правка и куда встроить>
116
85
  ~ Уточнить: <что переформулировать>
117
86
  -- Убрать: <что неверно, лишнее или противоречит контексту>
118
87
  ? Вопрос: <что нельзя безопасно решить без пользователя>
119
88
  ```
120
89
 
121
- #### 3.2. Проанализировать замечания
90
+ ### 3. Оценить результаты
122
91
 
123
- Когда все три агента ответили, сгруппируй замечания:
124
- - **Принять** — подтверждено планом, правилами, архитектурой, research или кодом; улучшает исполнимость без новой развилки.
125
- - **Отклонить** — противоречит контексту, дублирует уже закрытый пункт, расширяет задачу, требует неподтверждённого существенного решения или выходит за рамки плана.
126
- - **Спросить** — замечание выглядит существенным и полезным, но требует выбора пользователя или меняет ранее подтверждённое решение.
92
+ Когда все три агента ответили, прочитай их замечания и оценки. После этого основной агент выставляет итоговый `$SCORE` по шкале 0–100.
127
93
 
128
- Если есть вопросы класса **Спросить**, задай один сгруппированный `AskUserQuestion` и не редактируй план до ответа. Если вопрос нужен только из-за предложения субагента, которое можно безопасно отклонить как расширение задачи, отклони его и продолжай.
94
+ Оцени:
95
+ - план следует `docs/rules.md` и `docs/arch.md`;
96
+ - нет неподтверждённых существенных решений;
97
+ - `Целевой алгоритм` описывает сквозное поведение;
98
+ - `Контракты реализации` конкретны, особенно БД/API/внешние контракты;
99
+ - фазы имеют цель, шаги, результат, сценарии тестирования и проверку;
100
+ - `test_strategy` и `logging_strategy` отражены в фазах и разделах;
101
+ - нет альтернатив вида «выбрать», «решить», «уточнить позже»;
102
+ - план можно передать в `eda-execute` без нового исследования.
129
103
 
130
- #### 3.3. Отредактировать план
104
+ Если `$SCORE >= threshold`, не вноси содержательные правки ради формы. Только добавь или обнови:
131
105
 
132
- Внеси принятые замечания в основные разделы плана:
133
- - конкретизируй `Целевой алгоритм`, если не хватает сквозного поведения;
134
- - уточни `Контракты реализации`, если БД/API/внешние контракты затронуты, но описаны неполно;
135
- - дополни фазы шагами, результатами, сценариями тестирования и проверками;
136
- - приведи `Тесты` и `Логирование` в соответствие с `test_strategy` и `logging_strategy`;
137
- - убери неподтверждённые альтернативы, общие формулировки и противоречия правилам/архитектуре.
106
+ ```markdown
107
+ ## Оценка plan-polish
108
+ - **Итоговая оценка:** <score>/100
109
+ - **Порог:** <threshold>/100
110
+ - **Итерации:** <N>
111
+ - **Модели:** <фактически запущенные модели>
112
+ - **Решение:** план готов к исполнению.
113
+ ```
114
+
115
+ На этом остановись.
138
116
 
139
- Не меняй смысл подтверждённых решений без вопроса. Если план был `short`, не раздувай его больше 2 фаз: лучше заменить общие шаги конкретными, а лишнее отклонить как выход за short-рамку.
117
+ ### 4. Отредактировать план
140
118
 
141
- В конец плана добавь или обнови раздел:
119
+ Если `$SCORE < threshold`, сгруппируй замечания:
120
+ - **Принять** — подтверждено планом, правилами, архитектурой, research или кодом и улучшает исполнимость без новой развилки.
121
+ - **Отклонить** — противоречит контексту, дублирует уже закрытое, расширяет задачу или требует неподтверждённого решения.
122
+ - **Спросить** — полезно, но требует выбора пользователя или меняет подтверждённое решение.
123
+
124
+ Если есть вопросы класса **Спросить**, задай один сгруппированный `AskUserQuestion` и не редактируй план до ответа. Если предложение можно безопасно отклонить как расширение задачи, отклони его и продолжай.
125
+
126
+ Принятые замечания встраивай в основные разделы плана. Журнал в конце держи коротким:
142
127
 
143
128
  ```markdown
144
129
  ## Изменения после plan-polish
145
130
 
146
- ### Итерация <N>: completeness-polisher / rules-arch-polisher / execution-readiness-polisher
147
- - **Оценка до:** <score_before>/100
131
+ ### Итерация <N>
132
+ - **Оценка после проверки:** <score>/100
133
+ - **Модели:** <фактически запущенные модели>
148
134
  - **+ Добавлено:** <3–7 главных изменений>
149
135
  - **~ Уточнено:** <1–5 важных уточнений>
150
136
  - **− Убрано:** <если удалено>
@@ -152,58 +138,36 @@ score: <оценка плана 0–100 по мнению агента>
152
138
  - **Вопросы пользователя:** <если были, кратко решение>
153
139
  ```
154
140
 
155
- В front matter добавь фактически запущенные роли в `meta_reviewers`, если поле есть. Если поля нет — не перестраивай весь YAML ради этого, достаточно раздела `Изменения после plan-polish`. Если `status: draft` и после правок не осталось открытых вопросов, поменяй на `status: meta-reviewed`. Если статус уже `meta-reviewed` или `reviewed`, оставь его.
156
-
157
- #### 3.4. Пересчитать оценку
141
+ В `meta_reviewers`, если поле есть, добавь фактически запущенные модели. Если `status: draft` и открытых вопросов не осталось, поменяй на `status: meta-reviewed`; `meta-reviewed` и `reviewed` не понижай.
158
142
 
159
- Перечитай изменённый план и поставь новую оценку `$SCORE`.
143
+ ### 5. Продолжить или остановиться
160
144
 
161
- Добавь или обнови в разделе `## Оценка plan-polish`:
145
+ После правок обнови:
162
146
 
163
147
  ```markdown
164
148
  ## Оценка plan-polish
165
149
  - **Итоговая оценка:** <score>/100
166
150
  - **Порог:** <threshold>/100
167
151
  - **Итерации:** <N>
152
+ - **Модели:** <фактически запущенные модели>
168
153
  - **Решение:** <готов к исполнению | нужен следующий круг | blocked | достигнут лимит>
169
154
  ```
170
155
 
171
- Если `$SCORE >= threshold`, останови цикл: план готов. Если оценка не выросла два круга подряд, остановись `blocked: score не растёт`. Если лимит достигнут, остановись и прямо сообщи, что порог не достигнут.
172
-
173
- ### 4. Финальная самопроверка
174
-
175
- Перед финалом перечитай изменённый план и проверь:
176
- - план строго следует `docs/rules.md` и `docs/arch.md`;
177
- - нет неподтверждённых существенных решений и альтернатив вида «выбрать» / «решить»;
178
- - БД/API изменения описаны конкретно или явно помечены как `Не затрагивается`;
179
- - каждая фаза имеет цель, шаги, результат, сценарии тестирования и проверку;
180
- - `test_strategy` и `logging_strategy` применены в фазах и отдельных разделах;
181
- - план можно передать в `eda-execute` без нового исследования;
182
- - журнал `Изменения после plan-polish` не заменяет содержание плана, а только объясняет редакторские решения.
183
-
184
- Если после самопроверки остаётся блокер, не маскируй его правками: остановись со статусом `blocked` и назови, какой ответ или файл нужен.
156
+ Если оценка ниже порога и лимит не достигнут, запускай новую итерацию с тремя агентами. Если оценка не выросла два круга подряд — остановись `blocked: score не растёт`. Если лимит достигнут — остановись и явно скажи, что порог не достигнут.
185
157
 
186
- ### 5. Финал
158
+ ## Финал
187
159
 
188
- Короткое сообщение:
189
- - путь к отполированному плану;
190
- - итоговая оценка и порог;
191
- - сколько итераций выполнено;
192
- - какие три агента запускались, если запускались;
193
- - 3–5 главных принятых изменений;
194
- - существенные отклонённые замечания, если были;
195
- - причина остановки: `готов`, `достигнут лимит`, `score не растёт`, `blocked`;
196
- - следующий шаг при успехе: `eda-execute <PLAN_FILE>`.
160
+ Сообщи кратко: путь к плану, итоговую оценку и порог, число итераций, какие модели запускались, главные принятые изменения, существенные отклонения, причину остановки и следующий шаг `eda-execute <PLAN_FILE>` при успехе.
197
161
 
198
162
  ## Чего НЕ делать
199
163
 
200
164
  - Создавать новый план вместо полировки существующего.
201
165
  - Править код, миграции, конфиги, lock-файлы или зависимости.
202
- - Запускать агентов, если первичная оценка уже достигла порога.
203
- - Запускать агентов последовательно и менять промпты следующих агентов после первых ответов.
204
- - Вставлять все предложения субагентов без анализа.
205
- - Добавлять новые существенные решения без подтверждения пользователя.
206
- - Удалять обязательные разделы плана ради краткости.
166
+ - Запускать любые проверки проекта, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы.
167
+ - Ставить предварительную оценку без трёх агентных проверок.
168
+ - Запускать агентов последовательно или давать им разные промпты.
169
+ - Запускать все три прохода на одной модели.
170
+ - Вставлять предложения агентов без анализа.
171
+ - Добавлять существенные решения без подтверждения пользователя.
207
172
  - Превращать план в длинный отчёт о ревью.
208
- - Скрывать, что порог не достигнут.
209
173
  - Коммитить, пушить или запускать `eda-execute`.
package/skills/eda-polish.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: eda-polish
3
- description: 'Автономно доводит изменения до заданной оценки ревью: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional`, и повторяет цикл до порога качества или лимита итераций. По умолчанию цель — 95/100, лимит — 5 итераций; порог можно переопределить в сообщении (`до 90`, `threshold 90`). Каждый шаг запускается в изолированном субагенте или отдельном CLI-процессе. Не коммитит и не отправляет ревью.'
3
+ description: 'Автономно доводит изменения до заданной оценки ревью: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional`, и повторяет цикл до порога качества или лимита итераций. Все обязательные замечания чинятся, optional-замечания fix-агент применяет или отклоняет сам с обоснованием. По умолчанию цель — 95/100, лимит — 5 итераций; порог можно переопределить в сообщении (`до 90`, `threshold 90`). Каждый шаг запускается в изолированном субагенте или отдельном CLI-процессе. Не коммитит и не отправляет ревью.'
4
4
  ---
5
5
 
6
6
  # Скил: Доводка по ревью (eda-polish)
@@ -27,7 +27,7 @@ description: 'Автономно доводит изменения до зада
27
27
  2. **Не коммитишь и не отправляешь ревью.** Это работа `eda-commit` и `eda-send-review`.
28
28
  3. **Не обходишь границы скилов.** Ревью делает `eda-review draft`, проверку ревью делает `eda-review-check`, правки делает `eda-fix-by-review apply-optional`.
29
29
  4. **Цель цикла — score из проверенного ревью.** Сравнивай порог только с ревью после `eda-review-check`, не с draft.
30
- 5. **Optional-замечания применяются автоматически.** Для шага фиксов всегда передавай `apply-optional`, чтобы `eda-fix-by-review` применил пункты «на усмотрение автора» без вопроса.
30
+ 5. **Обязательные замечания исправляются все.** Для шага фиксов всегда передавай `apply-optional`, чтобы `eda-fix-by-review` не спрашивал пользователя в цикле: все пункты «править обязательно» он обязан исправить, а по пунктам «на усмотрение автора» сам решает, применить или отклонить с причиной.
31
31
  6. **Останавливайся на блокерах.** Если любой субагент завершился `blocked`, проверки не проходят из-за нерешённой причины, нет применимых замечаний или score не растёт два круга подряд — останови цикл и объясни причину.
32
32
  7. **Не скрывай неудачную сходимость.** Если лимит достигнут, финал должен прямо сказать, какая оценка получилась и какие ревью/фиксы были последними.
33
33
 
@@ -81,7 +81,7 @@ description: 'Автономно доводит изменения до зада
81
81
  6. Запусти изолированный шаг:
82
82
 
83
83
  ```text
84
- Используй скилл eda-fix-by-review apply-optional. Примени замечания из ревью: <REVIEW_FILE>. Применяй пункты «править обязательно» и «на усмотрение автора». Сохрани отчёт в docs/review-fixes/ и верни путь к отчёту, результат финальных проверок и состояние git.
84
+ Используй скилл eda-fix-by-review apply-optional. Разбери замечания из ревью: <REVIEW_FILE>. Все пункты «править обязательно» исправь. По каждому пункту «на усмотрение автора» сам реши, применять ли его; отклонённые optional-пункты запиши с причиной в отчёт и ссылку в ревью, чтобы следующие ревьюеры не повторяли их без новых аргументов. Сохрани отчёт в docs/review-fixes/ и верни путь к отчёту, результат финальных проверок и состояние git.
85
85
  ```
86
86
 
87
87
  7. Если фикс завершился `blocked`, с ошибкой проверок или без применённых правок — останови цикл и покажи причину.