@gian-tiaga/eda 0.8.4 → 0.8.6

package/README.md

@@ -39,15 +39,15 @@ eda update-all ~/Code
 | `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/roadmaps/` |
 | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. В дефолтном режиме ведёт исследование как диалог: факты собирает сам, а значимые развилки выносит тебе с рекомендацией. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
 | `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. `docs/rules.md` и `docs/arch.md` использует как обязательную рамку, а не справочный контекст: план должен строго следовать правилам и архитектуре. В плане явно фиксирует контракты БД/API, если задача их затрагивает. Затем три параллельных субагента/модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
-| `eda-plan-polish` | Полирует уже готовый план до оценки 95/100 или заданного порога. Каждая итерация сразу запускает три изолированных параллельных агента на быстрой, кодовой и флагманской моделях. Все агенты получают один общий промпт и проверяют весь план целиком. Основной агент после их ответов выставляет оценку, анализирует предложения, правит только файл плана при оценке ниже порога и не запускает проверки проекта | `docs/plans/` |
+| `eda-plan-polish` | Полирует уже готовый план до оценки 95/100 или заданного порога. Каждая итерация сразу запускает три изолированных параллельных агента на быстрой, кодовой и флагманской моделях. В strict дополнительно отдаёт план соседнему CLI (Claude ↔ Codex) на кросс-ревью. Основной агент после ответов выставляет оценку, анализирует предложения, содержательно правит только файл плана при оценке ниже порога и не запускает проверки проекта | `docs/plans/` |
 | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Перед правками читает план, `docs/rules.md` и `docs/arch.md`; правила и архитектура обязательны к исполнению. Если шаг плана им противоречит, останавливается и спрашивает. Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
-| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ, но в файл пишет только проблемы: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Если запущен без аргументов, ревьюит незакоммиченный `git diff HEAD` без проверки плана. Не перечисляет выполненную работу. В обычном режиме после черновика передаёт файл в `eda-review-check`; с флагом `draft` сохраняет только первичное ревью без субагентов | `docs/reviews/` |
+| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ, но в файл пишет только проблемы: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Сверяет с планом, только если он указан или однозначно найден; иначе ревьюит без сверки с планом и про план не спрашивает. Без аргументов ревьюит незакоммиченный `git diff HEAD`. Не перечисляет выполненную работу. В обычном режиме после черновика передаёт файл в `eda-review-check`; с флагом `draft` сохраняет только первичное ревью без субагентов | `docs/reviews/` |
 | `eda-review-check` | Проверяет готовое ревью из `docs/reviews/` специализированными субагентами: архитектуру, правила, выполнение плана при указанном plan-файле и при включённой настройке качество кода. В строгом режиме добавляет кросс-ревью между Claude и Codex. Сам применяет подтверждённые замечания к файлу ревью, но не правит код | `docs/reviews/` |
 | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — все сразу. Optional-пункты в обычном режиме спрашивает, а в `apply-optional` сам решает: применяет полезные, отклонённые обосновывает в отчёте. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
 | `eda-manual-test` | Делает ручную smoke/acceptance-проверку после изменений: API прогоняет через `curl`/HTTP-запросы, фронт — через Playwright или доступную browser automation. Сам строит чеклист из входа, плана или diff, запускает очевидные dev/API-серверы и сохраняет QA-отчёт. Не правит код, не пишет автотесты и не коммитит | `docs/manual-tests/` |
 | `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/` |
-| `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
+| `eda-send-review` | Отправляет ревью на GitHub PR через `gh` всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода. Тип (`comment`/`approve`/`request-changes`) задаёт только статус review; `approve` и `request-changes` подтверждаются. По умолчанию шлёт все пункты. Сам определяет PR по текущей ветке | (комментарий в PR) |
 | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
 | `eda-worktree` | Создаёт git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базу берёт из аргумента или спрашивает | соседняя папка `{name}-work-{n}` |
 | `eda-merge-worktree` | Мержит ветку из соседнего worktree в текущую ветку. Принимает номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Worktree и ветку после merge не удаляет | (git) |
@@ -66,6 +66,7 @@ eda update-all ~/Code
 |---|---|---|---|
 | `eda-explore` | `strict` | После сохранения отчёта отдаёт его соседнему CLI (Claude → Codex или наоборот) на критическое ревью конкретности, фактов, развилок, рисков и версий; затем доправляет отчёт по замечаниям | Серьёзные исследования, которые лягут в основу больших решений; когда хочется второго мнения от другой модели/среды |
 | `eda-plan` | `strict` | После обычного мета-ревью трёх субагентов/моделей отдаёт план соседнему CLI на дополнительный круг проверки; доправляет план | Большие или ответственные планы, особенно затрагивающие смежные системы |
+| `eda-plan-polish` | `strict` | В каждой итерации после трёх полных ревью плана отдаёт план соседнему CLI (Claude → Codex или Codex → Claude) на кросс-ревью; затем учитывает его в итоговой оценке и правках | Максимальная полировка ответственных планов перед `eda-execute` |
 | `eda-review` | `draft` | Сохраняет первичное ревью со статусом `draft` и не запускает `eda-review-check`, субагентов и кросс-CLI | Когда ревью нужно как черновик для внешней оркестрации, например `eda-polish` |
 | `eda-review` | `strict` | После draft-ревью запускает `eda-review-check strict`: специализированные субагенты плюс соседний CLI; доправляет ревью по подтверждённым замечаниям | Ревью важных PR; когда нужен максимальный охват |
 | `eda-review-check` | `strict` | Проверяет уже готовое ревью специализированными субагентами и затем отдаёт его соседнему CLI на дополнительный круг проверки | Когда черновик ревью уже есть и нужно усилить только проверку ревью |
@@ -83,7 +84,7 @@ eda update-all ~/Code
 version: 1
 
 defaults:
-  # Включает strict-режим по умолчанию для eda-explore, eda-plan, eda-review и eda-review-check.
+  # Включает strict-режим по умолчанию для eda-explore, eda-plan, eda-plan-polish, eda-review и eda-review-check.
   # true | false
   strict: false
   # Задаёт размер плана по умолчанию для eda-plan.
@@ -111,7 +112,7 @@ review:
 ```
 
 Что означают настройки:
-- `defaults.strict` — включает strict-режим по умолчанию для `eda-explore`, `eda-plan`, `eda-review` и `eda-review-check`.
+- `defaults.strict` — включает strict-режим по умолчанию для `eda-explore`, `eda-plan`, `eda-plan-polish`, `eda-review` и `eda-review-check`.
 - `defaults.plan_size` — размер плана для `eda-plan`: `normal`, `short` или `ask_each_time`.
 - `defaults.decision_mode` — как `eda-explore` ведёт исследовательские развилки, а `eda-plan` принимает существенные решения: `autonomous` выбирает сам, `recommend_and_ask` рекомендует и спрашивает по значимым развилкам, `ask_each_time` спрашивает по каждой развилке, которая влияет на ход работы или итоговый выбор.
 - `defaults.test_strategy` — стратегия тестов для `eda-plan`: `after_each_phase`, `tdd_each_phase`, `end_of_plan` или `ask_each_time`.
@@ -147,7 +148,7 @@ roadmap ────────> explore ─────> plan ───> plan-
                                                       fix ─────────────> manual-test
 
 polish = review draft ─> review-check ─> fix-by-review apply-optional ─> повтор до нужной оценки
-plan-polish = 3 полных ревью плана разными моделями ─> оценка ─> правка плана ─> повтор до 95/100
+plan-polish = 3 полных ревью плана разными моделями ─> strict: кросс-CLI ─> оценка ─> правка плана ─> повтор до 95/100
 
 automate может запускаться от review, fix-by-review или fix.
 ```

package/lib/install.js

@@ -165,7 +165,7 @@ export async function updateAll({
     output.write(`\n=== ${projectLabel} ===\n`);
 
     try {
-      const targets = await detectTargets(projectDir);
+      const targets = await detectInstalledTargets(projectDir);
       if (targets.length === 0) {
         output.write('Пропускаю: установленные среды исчезли во время обхода.\n');
         skippedProjects.push(projectDir);
@@ -295,6 +295,28 @@ async function detectTargets(cwd) {
   return targets;
 }
 
+// Среда считается установленной, только если в её папке скилов лежит хотя бы один eda-скил.
+// Используется при массовом обходе (update-all), чтобы не засыпать скилами проекты,
+// где папка .claude/skills или .codex/skills есть, но eda-скилов в ней нет.
+async function detectInstalledTargets(cwd) {
+  const targets = [];
+  if (await hasInstalledSkill(path.join(cwd, '.claude/skills'))) targets.push('claude');
+  if (await hasInstalledSkill(path.join(cwd, '.codex/skills'))) targets.push('codex');
+  return targets;
+}
+
+async function hasInstalledSkill(skillsDir) {
+  let entries;
+  try {
+    entries = await fs.readdir(skillsDir, { withFileTypes: true });
+  } catch (err) {
+    if (['ENOENT', 'ENOTDIR', 'EACCES', 'EPERM'].includes(err?.code)) return false;
+    throw err;
+  }
+  // eda-скилы лежат как папка eda-* (новый layout) или файл eda-*.md (старый Codex layout).
+  return entries.some(entry => entry.name.startsWith('eda-'));
+}
+
 async function syncSkills(cwd, targets, output = process.stdout, { action = 'update', writeDone = true } = {}) {
   const skills = await listSkills();
   if (skills.length === 0) {
@@ -326,7 +348,7 @@ async function findInstalledProjects(rootDir, maxDepth) {
   const projects = [];
 
   async function walk(dir, depth) {
-    const targets = await detectTargets(dir);
+    const targets = await detectInstalledTargets(dir);
     if (targets.length > 0) projects.push(dir);
     if (depth >= maxDepth) return;
 
@@ -378,7 +400,7 @@ function formatSettings(settings) {
   return `version: 1
 
 defaults:
-  # Включает strict-режим по умолчанию для eda-explore, eda-plan, eda-review и eda-review-check.
+  # Включает strict-режим по умолчанию для eda-explore, eda-plan, eda-plan-polish, eda-review и eda-review-check.
   # true | false
   strict: ${settings.strict ? 'true' : 'false'}
   # Задаёт размер плана по умолчанию для eda-plan.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.8.4",
+  "version": "0.8.6",
   "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",
   "type": "module",
   "bin": {

package/skills/eda-plan-polish.md

@@ -1,11 +1,11 @@
 ---
 name: eda-plan-polish
-description: 'Полирует готовый план из `docs/plans/...` до оценки 95/100 или заданного порога. Каждая итерация начинается с трёх изолированных параллельных агентов на быстрой, кодовой и флагманской моделях. Все агенты получают один общий промпт и проверяют весь план целиком. Основной агент читает их результаты, выставляет итоговую оценку, принимает или отклоняет предложения, правит только файл плана, не меняет код и не запускает проверки.'
+description: 'Полирует готовый план из `docs/plans/...` до оценки 95/100 или заданного порога. Каждая итерация начинается с трёх изолированных параллельных агентов на быстрой, кодовой и флагманской моделях. В strict дополнительно запускает кросс-CLI ревью плана: Claude отдаёт план Codex, Codex отдаёт план Claude. Основной агент читает результаты, выставляет итоговую оценку, принимает или отклоняет предложения, содержательно правит только файл плана, не меняет код и не запускает проверки.'
 ---
 
 # Скил: Полировка плана (eda-plan-polish)
 
-Берёшь готовый план из `docs/plans/` и доводишь его до состояния, когда его можно передать в `eda-execute`. Порог по умолчанию — `95`, лимит по умолчанию — `5` итераций.
+Берёшь готовый план из `docs/plans/` и доводишь его до состояния, когда его можно передать в `eda-execute`. Порог по умолчанию — `95`, лимит по умолчанию — `5` итераций. В `strict` каждая итерация после трёх моделей дополнительно отдаёт план соседнему CLI на кросс-ревью.
 
 Каждая итерация начинается с трёх независимых моделей с одним и тем же промптом. Основной агент не ставит предварительную оценку сам: он оценивает план только после ответов агентов, принимает или отклоняет предложения, правит план при оценке ниже порога и запускает новую итерацию.
 
@@ -17,6 +17,11 @@ description: 'Полирует готовый план из `docs/plans/...` д
 
 ## Настройки
 
+Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
+
+Дефолты: `defaults.strict: false`.
+
+- `strict` включает кросс-CLI ревью плана после трёх агентов в каждой итерации; выключение: `normal`, `без strict`, `без строгого режима`.
 - Порог качества по умолчанию — `95`, можно переопределить словами `до 90`, `threshold 90`, `цель 90`.
 - Лимит по умолчанию — `5` итераций, можно переопределить словами `лимит 3`, `max iterations 3`, `не больше 3 кругов`.
 - Оценка `95–100` означает готовность к исполнению; `80–94` — нужно уточнить; `60–79` — рискованный план; ниже `60` — нужен серьёзный переплан или вопросы пользователю.
@@ -24,14 +29,15 @@ description: 'Полирует готовый план из `docs/plans/...` д
 ## Жёсткие правила
 
 1. Работай только с готовым файлом плана в `docs/plans/`.
-2. Не правишь код. Менять можно только выбранный файл плана; миграции, конфиги, зависимости и lock-файлы не трогай.
+2. Не правишь код. Содержательно менять можно только выбранный файл плана; в `strict` можно создать или обновить только вспомогательный файл `${PLAN_FILE%.md}_strict_cli_review.md`. Миграции, конфиги, зависимости и lock-файлы не трогай.
 3. Не запускай проверки и исполняющие команды: `test`, `lint`, `build`, `typecheck`, `check`, `dev`, `start`, миграции, seed, smoke-тесты, браузерные проверки и API-запросы. При полировке плана можно читать файлы и искать по коду, но нельзя проверять проект выполнением команд.
 4. Не ставь предварительную оценку без агентов. Сразу запускай три изолированных агента параллельно, одним batch, до чтения любого результата.
-5. Итоговую оценку 0–100 выставляй только после чтения результатов всех трёх агентов.
+5. Итоговую оценку 0–100 выставляй только после чтения результатов всех трёх агентов, а в `strict` — ещё и результата соседнего CLI.
 6. У всех трёх агентов один общий промпт: каждый проверяет весь план целиком, а не отдельную роль.
 7. Не добавляй неподтверждённые существенные решения: БД/API-контракты, зависимости, архитектурные развилки, auth/permissions/payments/secrets/персональные данные и миграции.
 8. Сохраняй структуру `eda-plan`: `Целевой алгоритм`, `Контракты реализации`, `Фазы выполнения`, `Тесты`, `Логирование`, если эти разделы есть или должны быть по формату.
-9. Если качество не растёт два круга подряд, достигнут лимит или нужен ответ пользователя, остановись и честно назови причину.
+9. Не пропускай кросс-CLI молча в `strict`: если соседней CLI нет, спроси через `AskUserQuestion`, завершить как normal или прервать.
+10. Если качество не растёт два круга подряд, достигнут лимит или нужен ответ пользователя, остановись и честно назови причину.
 
 ## Интерактивные вопросы
 
@@ -87,9 +93,29 @@ score: <0–100>
 ? Вопрос: <что нельзя безопасно решить без пользователя>
 ```
 
-### 3. Оценить результаты
+### 3. Strict: кросс-CLI ревью плана
+
+Обычный режим пропускает этот этап. В `strict` после ответов трёх агентов, но до итоговой оценки, отдай план соседнему CLI через `Bash`.
+
+Если ты в Claude Code — запускай Codex CLI:
+
+```bash
+codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, sources.research при наличии и релевантные файлы, на которые ссылается план. Глубоко проверь весь план целиком: исполнимость, соответствие правилам и архитектуре, полноту целевого алгоритма, БД/API/внешние контракты, фазы, тесты, логирование, неподтверждённые решения, скрытые риски и места, где eda-execute не сможет продолжить без нового исследования. Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы. Ответь кратко: score: <0–100>; + Принять; ~ Уточнить; -- Убрать; ? Вопрос." > "${PLAN_FILE%.md}_strict_cli_review.md"
+```
+
+Если ты в Codex — запускай Claude CLI:
+
+```bash
+claude -p "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, sources.research при наличии и релевантные файлы, на которые ссылается план. Глубоко проверь весь план целиком: исполнимость, соответствие правилам и архитектуре, полноту целевого алгоритма, БД/API/внешние контракты, фазы, тесты, логирование, неподтверждённые решения, скрытые риски и места, где eda-execute не сможет продолжить без нового исследования. Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы. Ответь кратко: score: <0–100>; + Принять; ~ Уточнить; -- Убрать; ? Вопрос." > "${PLAN_FILE%.md}_strict_cli_review.md"
+```
+
+Если соседней CLI нет — `AskUserQuestion`: продолжить как `normal` без кросс-CLI или прервать полировку. Не заменяй кросс-CLI четвёртым локальным субагентом.
+
+Прочитай ответ соседнего CLI и дальше оцени его вместе с тремя агентами. Файл `${PLAN_FILE%.md}_strict_cli_review.md` можно создать и обновлять в `strict`; это единственный вспомогательный файл, кроме самого плана, который разрешён в strict-режиме.
+
+### 4. Оценить результаты
 
-Когда все три агента ответили, прочитай их замечания и оценки. После этого основной агент выставляет итоговый `$SCORE` по шкале 0–100.
+Когда все три агента ответили, а в `strict` ещё и соседний CLI, прочитай их замечания и оценки. После этого основной агент выставляет итоговый `$SCORE` по шкале 0–100.
 
 Оцени:
 - план следует `docs/rules.md` и `docs/arch.md`;
@@ -108,13 +134,14 @@ score: <0–100>
 - **Итоговая оценка:** <score>/100
 - **Порог:** <threshold>/100
 - **Итерации:** <N>
-- **Модели:** <фактически запущенные модели>
+- **Модели:** <фактически запущенные модели и соседний CLI в strict>
+- **Режим:** <normal | strict>
 - **Решение:** план готов к исполнению.
 ```
 
 На этом остановись.
 
-### 4. Отредактировать план
+### 5. Отредактировать план
 
 Если `$SCORE < threshold`, сгруппируй замечания:
 - **Принять** — подтверждено планом, правилами, архитектурой, research или кодом и улучшает исполнимость без новой развилки.
@@ -130,7 +157,7 @@ score: <0–100>
 
 ### Итерация <N>
 - **Оценка после проверки:** <score>/100
-- **Модели:** <фактически запущенные модели>
+- **Модели:** <фактически запущенные модели и соседний CLI в strict>
 - **+ Добавлено:** <3–7 главных изменений>
 - **~ Уточнено:** <1–5 важных уточнений>
 - **− Убрано:** <если удалено>
@@ -138,9 +165,9 @@ score: <0–100>
 - **Вопросы пользователя:** <если были, кратко решение>
 ```
 
-В `meta_reviewers`, если поле есть, добавь фактически запущенные модели. Если `status: draft` и открытых вопросов не осталось, поменяй на `status: meta-reviewed`; `meta-reviewed` и `reviewed` не понижай.
+В `meta_reviewers`, если поле есть, добавь фактически запущенные модели и имя соседнего CLI в `strict`. Если `status: draft` и открытых вопросов не осталось, поменяй на `status: meta-reviewed`; `meta-reviewed` и `reviewed` не понижай.
 
-### 5. Продолжить или остановиться
+### 6. Продолжить или остановиться
 
 После правок обнови:
 
@@ -149,7 +176,8 @@ score: <0–100>
 - **Итоговая оценка:** <score>/100
 - **Порог:** <threshold>/100
 - **Итерации:** <N>
-- **Модели:** <фактически запущенные модели>
+- **Модели:** <фактически запущенные модели и соседний CLI в strict>
+- **Режим:** <normal | strict>
 - **Решение:** <готов к исполнению | нужен следующий круг | blocked | достигнут лимит>
 ```
 
@@ -157,7 +185,7 @@ score: <0–100>
 
 ## Финал
 
-Сообщи кратко: путь к плану, итоговую оценку и порог, число итераций, какие модели запускались, главные принятые изменения, существенные отклонения, причину остановки и следующий шаг `eda-execute <PLAN_FILE>` при успехе.
+Сообщи кратко: режим (`normal` или `strict`), путь к плану, путь к strict-review-файлу при наличии, итоговую оценку и порог, число итераций, какие модели и CLI запускались, главные принятые изменения, существенные отклонения, причину остановки и следующий шаг `eda-execute <PLAN_FILE>` при успехе. Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-plan-polish strict <PLAN_FILE>`».
 
 ## Чего НЕ делать
 
@@ -167,6 +195,7 @@ score: <0–100>
 - Ставить предварительную оценку без трёх агентных проверок.
 - Запускать агентов последовательно или давать им разные промпты.
 - Запускать все три прохода на одной модели.
+- Пропускать кросс-CLI молча в `strict`.
 - Вставлять предложения агентов без анализа.
 - Добавлять существенные решения без подтверждения пользователя.
 - Превращать план в длинный отчёт о ревью.

package/skills/eda-review.md

@@ -1,11 +1,11 @@
 ---
 name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с оценкой и сверкой с планом работ из `docs/plans/`, когда план указан или однозначно найден. Если запущен без аргументов, ревьюит незакоммиченный `git diff HEAD` без проверки плана. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью только по проблемам, сохраняет в `docs/reviews/` и в обычном режиме передаёт файл в `eda-review-check` для мета-проверки субагентами. Флаг `draft` сохраняет только черновое ревью без субагентов. Кросс-CLI включается флагом `strict` или настройкой `defaults.strict: true`. Не правит код — это `eda-fix-by-review`.'
+description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с оценкой и сверкой с планом работ из `docs/plans/`, когда план указан или однозначно найден. Если план не указан и не найден однозначно, ревьюит без сверки с планом и не спрашивает про него. Без аргументов ревьюит незакоммиченный `git diff HEAD`. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью только по проблемам, сохраняет в `docs/reviews/` и в обычном режиме передаёт файл в `eda-review-check` для мета-проверки субагентами. Флаг `draft` сохраняет только черновое ревью без субагентов. Кросс-CLI включается флагом `strict` или настройкой `defaults.strict: true`. Не правит код — это `eda-fix-by-review`.'
 ---
 
 # Скил: Ревьюер (eda-review)
 
-Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Если скилл вызван без аргументов, ревьюишь незакоммиченный `git diff HEAD` и не проверяешь план. Каждый пункт начинаешь с короткого человеческого объяснения риска, без технической перегрузки; файлы, строки, детали кода и способ исправления даёшь ниже в блоке «Технические детали». Не перечисляешь, что выполнено хорошо или без замечаний. Затем в обычном режиме запускаешь `eda-review-check`, который проверяет ревью параллельными специализированными агентами; в `strict` он добавляет соседний CLI. В `draft` останавливаешься сразу после сохранения черновика.
+Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Если скилл вызван без аргументов, ревьюишь незакоммиченный `git diff HEAD`. План сверяешь, только если он указан или однозначно найден; иначе ревьюишь без сверки с планом и про план не спрашиваешь. Каждый пункт начинаешь с короткого человеческого объяснения риска, без технической перегрузки; файлы, строки, детали кода и способ исправления даёшь ниже в блоке «Технические детали». Не перечисляешь, что выполнено хорошо или без замечаний. Затем в обычном режиме запускаешь `eda-review-check`, который проверяет ревью параллельными специализированными агентами; в `strict` он добавляет соседний CLI. В `draft` останавливаешься сразу после сохранения черновика.
 
 ## Режим запуска
 
@@ -33,7 +33,7 @@ description: 'Ревью изменений (незакоммиченный diff
 1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Замечания должны опираться на правила и архитектуру проекта, а не на твои общие представления.
 2. **Интерактивные вопросы** — по разделу ниже. Если контекст понятен, не спрашивай.
 3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
-4. **План работ обязателен для явно заданного ревью выполненных изменений.** Если пользователь указал файл, папку, PR, ветку, тип diff или другую цель ревью, а путь к плану не указан и его нельзя однозначно определить из diff/ссылок, спроси путь к файлу плана и остановись до ответа. Исключение: запуск без аргументов — ревью незакоммиченного `git diff HEAD` без проверки плана. Не подставляй «последний план» наугад.
+4. **Сверка с планом — только если план есть.** Используй план, если пользователь указал путь к нему или его можно однозначно определить из diff/ссылок/существующего review-файла. Если плана нет или вариантов несколько — не спрашивай: делай ревью без сверки с планом и отметь это в ревью. Не подставляй «последний план» наугад.
 5. **Мета-ревью специализированными агентами — обязательно в normal/strict**, но выполняется отдельным скиллом `eda-review-check`. В `draft` мета-ревью не запускается.
 6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
 7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
@@ -48,7 +48,7 @@ description: 'Ревью изменений (незакоммиченный diff
 
 ## Интерактивные вопросы
 
-Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос о цели ревью**. Это не отменяет обязательный вопрос о `$PLAN_FILE` для явно заданной цели, если план не указан и не найден однозначно. Для запуска без аргументов вопрос о плане не задавай: проверка плана пропускается. Примеры понятного контекста:
+Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос о цели ревью**. Вопрос о плане не задавай никогда: если план не указан и не найден однозначно, ревьюй без сверки с планом. Примеры понятного контекста:
 - пользователь указал файл, папку, PR, ветку или тип diff;
 - в запросе есть «ревью незакоммиченных изменений», «ревью текущей ветки», «проверь PR #N»;
 - в рабочем дереве есть незакоммиченные изменения и пользователь просит «сделай ревью» без других целей.
@@ -70,12 +70,10 @@ description: 'Ревью изменений (незакоммиченный diff
 
 Получи diff/исходник в `$TARGET`. Прочитай `docs/rules.md`, `docs/arch.md` и строго следуй им.
 
-Определи `$PLAN_FILE` и `$PLAN_MODE`:
-- если пользователь вызвал скилл без аргументов, а целью выбран незакоммиченный `git diff HEAD` — установи `$PLAN_FILE=none`, `$PLAN_MODE=skipped_no_args` и не спрашивай план;
+Определи `$PLAN_FILE`, не задавая вопросов о плане:
 - если пользователь указал путь к плану — используй его;
 - если в diff, описании задачи или уже существующем review-файле есть однозначная ссылка на `docs/plans/...` — используй её;
-- если цель ревью явно задана пользователем и есть несколько возможных планов или нет ни одного — спроси: «Какой файл плана использовать для проверки выполнения работ?» и остановись до ответа;
-- если пользователь явно просит ревью без сверки с планом — продолжай, но в ревью укажи, что проверка выполнения плана пропущена по явному указанию пользователя.
+- иначе (план не указан, не найден или вариантов несколько) — установи `$PLAN_FILE=none` и ревьюй без сверки с планом. Не подставляй «последний план» наугад.
 
 Если в diff видно отсылки к исследованию из `docs/researches/` — прочитай его тоже.
 
@@ -111,7 +109,7 @@ meta_reviewers: []
 
 ## Проблемы сверки с планом
 
-<Если `$PLAN_FILE=none`: «Проверка плана пропущена: запуск без аргументов использует незакоммиченный `git diff HEAD` без сверки с планом.» Если проблем по плану нет: «Явных проблем по плану не найдено.»>
+<Если `$PLAN_FILE=none`: «Проверка плана пропущена: план не указан и не найден.» Если проблем по плану нет: «Явных проблем по плану не найдено.»>
 
 ### 1. <недоделка, отклонение или непроверенный пункт>
 

package/skills/eda-send-review.md

@@ -1,25 +1,27 @@
 ---
 name: eda-send-review
-description: 'Отправляет ревью из `docs/reviews/...`, выбранное по тексту рядом с вызовом, на GitHub PR через `gh` — как review (comment/approve/request-changes) или как обычный комментарий. Перед отправкой читает `docs/rules.md` и `docs/arch.md` и строго следует им. Целевой PR определяется из текста или автоматически по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку на PR-комментарий. Не правит код, не делает само ревью. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
+description: 'Отправляет ревью из `docs/reviews/...`, выбранное по тексту рядом с вызовом, на GitHub PR через `gh` — всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода (inline). Тип отправки (`comment`/`approve`/`request-changes`) задаёт только статус review, но не структуру вывода. По умолчанию отправляет все пункты; если в тексте указано подмножество — только его. Перед отправкой читает `docs/rules.md` и `docs/arch.md` и строго следует им. Целевой PR определяется из текста или по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку. Не правит код, не делает само ревью. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
 ---
 
 # Скил: Отправитель ревью (eda-send-review)
 
-Берёшь готовое ревью из `docs/reviews/`, отправляешь его на GitHub PR через `gh`. В конец файла ревью дописываешь, куда отправил.
+Берёшь готовое ревью из `docs/reviews/`, отправляешь его на GitHub PR через `gh`. Отправляешь **всегда в одном формате**: общий комментарий-сводка плюс комментарии к строкам кода. В конец файла ревью дописываешь, куда отправил.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения, какие пункты отправлять и прямые указания.
 
 Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
 ## Главные правила
 
-1. **Интерактивные вопросы** — по разделу ниже.
-2. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе способа отправки и финальной отметке.
-3. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
-4. **Никаких самостоятельных оценок.** Тип отправки определяется на основе ревью и текста пользователя. `comment` означает обычный комментарий PR, `review-comment` — review без статуса. `approve` и `request-changes` всегда подтверждаются пользователем.
-5. **Простой язык.** В сообщениях пользователю и комментарии PR без лишних терминов.
+1. **Единый формат всегда.** Отправляешь как GitHub review: тело — общий комментарий-сводка, а каждое замечание с привязкой к строке — отдельным комментарием к строке кода (inline). Тип отправки меняет только статус review (`event`), но не структуру вывода.
+2. **По умолчанию — все пункты.** Если пользователь не указал, что отправлять, отправляешь все замечания ревью. Если указал подмножество — только его.
+3. **Интерактивные вопросы** — по разделу ниже.
+4. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе способа отправки и финальной отметке.
+5. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
+6. **Никаких самостоятельных оценок.** Статус review определяется по оценке ревью и тексту пользователя. `approve` и `request-changes` всегда подтверждаются пользователем.
+7. **Простой язык.** В сообщениях пользователю и комментариях PR без лишних терминов.
 
 ## Интерактивные вопросы
 
@@ -28,61 +30,82 @@ description: 'Отправляет ревью из `docs/reviews/...`, выбр
 - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
 - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
 - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для отправки ревью это правило важнее продолжения: не создавай PR, не отправляй approve/request-changes и не меняй тип отправки вместо ответа пользователя.
+- Для отправки ревью это правило важнее продолжения: не создавай PR, не отправляй approve/request-changes и не меняй статус отправки вместо ответа пользователя.
 
 ## Этапы
 
 ### 1. Проверить инструменты
 `gh --version` + `gh auth status`. Если `gh` отсутствует или не авторизован — остановись, сообщи и выйди (это пользователю нужно решить).
 
-### 2. Выбрать ревью
-Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`) и тип отправки (`comment`, `review-comment`, `approve`, `request-changes`).
+### 2. Выбрать ревью и что отправлять
+Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`) и статус отправки (`comment`, `review-comment`, `approve`, `request-changes`).
 
 Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: оценку, замечания, рекомендации.
 
+**Что отправлять.** По умолчанию — все замечания. Если в тексте указано подмножество, отправь только его. Синтаксис свободный, распознавай по смыслу: по номерам («пункты 1, 3, 5»), по обязательности («только обязательные» → раздел «Править обязательно»), по типу («только security» → замечания с этим `Тип`). Выбор влияет и на сводку, и на комментарии к строкам.
+
 ### 3. Найти целевой PR
 Если номер PR указан в тексте пользователя — используй его. Иначе попробуй `gh pr view --json number,url,headRefName` — если у текущей ветки уже есть PR, возьми его номер.
 
 Если PR нет — `AskUserQuestion`: «PR ещё нет: создать PR из текущей ветки / указать номер существующего PR / прервать». При создании используй `gh pr create` (заголовок и тело — по последним коммитам ветки).
 
-### 4. Выбрать тип отправки
-Предложи вариант по оценке: score ≥ 80 → **approve** с комментарием; score < 50 → **request-changes**; иначе → **review-comment**.
+### 4. Выбрать статус review
+Review отправляется всегда; здесь выбирается только его статус (`event`).
+
+| Условие | event | Подтверждение |
+|---|---|---|
+| score ≥ 80 (или в тексте `approve`) | `APPROVE` | всегда `AskUserQuestion` |
+| score < 50 (или в тексте `request-changes`) | `REQUEST_CHANGES` | всегда `AskUserQuestion` |
+| иначе (или в тексте `comment` / `review-comment`) | `COMMENT` | без подтверждения |
+
+`comment` и `review-comment` означают review без статуса (`event=COMMENT`) — обычный комментарий-ревью, который тоже несёт сводку и комментарии к строкам. `approve` и `request-changes` подтверждай через `AskUserQuestion` всегда, даже если указаны в тексте. Если предложенный статус противоречит ревью — `AskUserQuestion`: подтвердить / выбрать другой.
 
-Если тип отправки указан в тексте и это `comment` или `review-comment`, используй его без дополнительного выбора, если нет противоречий с ревью. `approve` и `request-changes` всегда подтверждай через `AskUserQuestion`, даже если они указаны inline. Если тип не указан или противоречит ревью — `AskUserQuestion`: подтвердить предложенный тип / выбрать другой / отправить как обычный комментарий PR (вне review).
+### 5. Собрать сводку и комментарии к строкам
+Из выбранных пунктов собери две части.
 
-### 5. Сформировать тело
-Структура комментария:
+**Сводка** — тело review:
 
 ```markdown
 ## Ревью: <заголовок>
 
 **Оценка:** N/100. <одно-два предложения почему>
 
-### Замечания
-1. **[тип]** `path/file.py:42` — <что не так>. → <что предлагаешь>
-2. ...
+<короткое резюме: что отправлено и общий вывод>
 
 ### Рекомендации
 - **Править обязательно:** 1, 3, 5
 - **На усмотрение автора:** 2, 4
-- **Не править:** —
+
+### Замечания вне diff
+1. **[тип]** `path/file.py:42` — <что не так>. → <что предлагаешь>
 
 _Сгенерировано из `<путь к docs/reviews/...>`_
 ```
 
+Раздел «Замечания вне diff» добавляй только если такие пункты есть (см. ниже); иначе опусти его.
+
+**Комментарии к строкам** — по одному на каждое отправляемое замечание, чьё `Где: path:line` входит в diff PR. Для каждого: `{ "path": "<path>", "line": <line>, "side": "RIGHT", "body": "<суть простым языком + рекомендация + как исправить>" }`. Для замечания об удалённой строке используй `"side": "LEFT"`.
+
+Какие строки входят в diff — определи по `gh pr diff <num>`. Замечания, чьи строки в diff не попали (или без `path:line`), в комментарии к строкам **не** клади — перенеси их в раздел «Замечания вне diff» сводки, чтобы ничего не потерялось.
+
 ### 6. Отправить
-По выбранному типу:
+Тело сводки и комментарии собери в один JSON через `mktemp`:
 
-| Тип | Команда |
-|---|---|
-| comment (PR comment) | `gh pr comment <num> --body-file <tmpfile>` |
-| review-comment | `gh pr review <num> --comment --body-file <tmpfile>` |
-| approve | `gh pr review <num> --approve --body-file <tmpfile>` |
-| request-changes | `gh pr review <num> --request-changes --body-file <tmpfile>` |
+```json
+{ "body": "<сводка>", "event": "COMMENT|APPROVE|REQUEST_CHANGES", "comments": [ { "path": "...", "line": 42, "side": "RIGHT", "body": "..." } ] }
+```
+
+Отправь одним вызовом Reviews API:
 
-Тело пиши во временный файл (`mktemp`) и передавай через `--body-file` — иначе спецсимволы и переносы поедут не туда.
+```bash
+OWNER_REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
+gh api "repos/$OWNER_REPO/pulls/<num>/reviews" --method POST --input <payload.json>
+```
 
-Если команда упала — покажи вывод пользователю и спроси через `AskUserQuestion` (повторить / другой тип / прервать).
+Fallback'ы:
+- API упал с `422` из-за конкретных строк — перенеси эти пункты в раздел «Замечания вне diff» сводки и переотправь без них.
+- У цели нет diff/строк PR вовсе (нечего привязывать) — отправь только сводку обычным комментарием: `gh pr comment <num> --body-file <tmpfile>`.
+- Другая ошибка — покажи вывод пользователю и спроси через `AskUserQuestion` (повторить / другой статус / прервать).
 
 ### 7. Дописать ссылку в файл ревью
 В конец `$REVIEW_FILE` добавь:
@@ -90,16 +113,19 @@ _Сгенерировано из `<путь к docs/reviews/...>`_
 ```markdown
 ## Отправлено
 - PR: <URL из ответа gh>
-- Тип: <comment | review-comment | approve | request-changes>
+- Статус: <comment | approve | request-changes>
+- Отправлено пунктов: <сколько / inline + сколько в сводке>
 - Дата: <YYYY-MM-DD HH:MM>
 ```
 
 ### 8. Финал
-Короткое сообщение: PR-номер и URL, тип отправки, путь к файлу ревью.
+Короткое сообщение: PR-номер и URL, статус отправки, сколько пунктов ушло комментариями к строкам и сколько в сводку, путь к файлу ревью.
 
 ## Чего НЕ делать
 - Делать само ревью или править замечания — это `eda-review` / `eda-fix-by-review`.
-- Отправлять `approve` без явного подтверждения через `AskUserQuestion`, даже если оценка ≥ 80.
-- Передавать тело комментария через `-b "..."` со спецсимволами без `--body-file` — поломает форматирование.
+- Отправлять всё одним обычным комментарием PR, когда строки можно привязать к diff — обычный комментарий только fallback при отсутствии diff.
+- Терять замечания вне diff — они идут в сводку отдельным разделом.
+- Отправлять `approve` или `request-changes` без явного подтверждения через `AskUserQuestion`, даже если оценка ≥ 80.
+- Передавать тело через `-b "..."` со спецсимволами — только `--input` (Reviews API) или `--body-file` (fallback).
 - Создавать PR молча, если его нет — только через `AskUserQuestion`.
 - Сохранять копии отправленного в отдельные файлы — связь через ссылку в файле ревью.