@gian-tiaga/eda 0.3.2 → 0.3.4

package/README.md

@@ -31,7 +31,7 @@ eda init
 | `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. Подтягивает контекст из `docs/rules.md`, `docs/arch.md`, при желании — релевантное исследование. Затем три параллельных модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
 | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
-| `eda-review` | Делает код-ревью с оценкой 0–100. Затем три параллельных модели (Sonnet, Haiku, Opus) проверяют само ревью — добавляют пропущенное, убирают лишнее. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
+| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ. Замечания пишет блоками: сначала контекст и риск, потом конкретные файлы/строки и шаги исправления. Затем три параллельных специализированных агента проверяют выполнение плана, архитектуру и правила. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
 | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
 | `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
 | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
@@ -50,7 +50,7 @@ eda init
 |---|---|---|---|
 | `eda-research` | `strict` | После сохранения отчёта отдаёт его соседнему CLI (Claude → Codex или наоборот) на критическое ревью; затем доправляет отчёт по их замечаниям | Серьёзные исследования, которые лягут в основу больших решений; когда хочется второго мнения от другой модели/среды |
 | `eda-plan` | `strict` | После мета-ревью трёх моделей (это есть всегда) отдаёт план соседнему CLI на дополнительный круг проверки; доправляет план | Большие или ответственные планы, особенно затрагивающие смежные системы |
-| `eda-review` | `strict` | После мета-ревью тремя моделями (Sonnet/Haiku/Opus — это есть всегда) отдаёт ревью соседнему CLI на дополнительный круг проверки; доправляет ревью по его замечаниям | Ревью важных PR; когда нужен максимальный охват |
+| `eda-review` | `strict` | После мета-ревью тремя специализированными агентами отдаёт ревью соседнему CLI на дополнительный круг проверки; доправляет ревью по его замечаниям | Ревью важных PR; когда нужен максимальный охват |
 
 ---
 
@@ -106,6 +106,8 @@ eda update           # синхронизировать скилы в текущ
 
 ## 📁 Куда устанавливаются скилы
 
+Исходники скилов в этом пакете лежат в `skills/`. Установщик читает именно эту папку и копирует каждый `<skill>.md` в формат `<skill>/SKILL.md` для выбранной среды.
+
 | Среда | Куда |
 |---|---|
 | **Claude Code** | `<project>/.claude/skills/<skill>/SKILL.md` — отдельная папка на каждый скил |

package/lib/install.js

@@ -6,7 +6,7 @@ import { fileURLToPath } from 'node:url';
 const __filename = fileURLToPath(import.meta.url);
 const __dirname = path.dirname(__filename);
 const PACKAGE_ROOT = path.resolve(__dirname, '..');
-const SKILLS_SRC = path.join(PACKAGE_ROOT, 'docs/skills');
+const SKILLS_SRC = path.join(PACKAGE_ROOT, 'skills');
 const TARGET_CHOICES = [
   { value: 'claude', label: 'Claude Code', dir: '.claude/skills/' },
   { value: 'codex', label: 'Codex CLI', dir: '.codex/skills/' }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.3.2",
+  "version": "0.3.4",
   "description": "Набор скилов eda-* для Claude Code и Codex CLI: research, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
   "type": "module",
   "bin": {
@@ -9,7 +9,7 @@
   "files": [
     "bin",
     "lib",
-    "docs/skills",
+    "skills",
     "README.md"
   ],
   "engines": {

package/{docs/skills → skills}/eda-execute.md

@@ -21,8 +21,9 @@ description: 'Исполняет план из docs/plans/ по пути или
 4. **Не коммитить, не пушить, не делать ревью.** Это другие скилы.
 5. **Идти целиком**, не делать паузы «для подтверждения». Останавливайся только если: тест упал, шаг противоречив, есть риск потерять данные, рискованная операция вне плана.
 6. **Тесты — внутри шага.** Меняешь поведение → пишешь тесты к этому изменению в том же шаге, точечно прогоняешь только их. Полный сьют и линтеры — один раз в конце (этап 7), не на каждом шаге.
-7. **Простой язык** в сообщениях пользователю и вопросах. Термины — только если без них нельзя, и сразу с пояснением.
-8. **Таблицы для структурируемых данных** в журнале. Диаграммы — только если действительно есть что показать.
+7. **Проверки нельзя подавлять.** Не отключай линтеры, тесты, typecheck, static analysis и другие проверки; не добавляй игноры, исключения из проверок, ослабление правил или изменение команд так, чтобы проверка перестала запускаться. Пиши и правь код так, чтобы проверки проходили по сути.
+8. **Простой язык** в сообщениях пользователю и вопросах. Термины — только если без них нельзя, и сразу с пояснением.
+9. **Таблицы для структурируемых данных** в журнале. Диаграммы — только если действительно есть что показать.
 
 ## Интерактивные вопросы
 
@@ -118,7 +119,7 @@ cd ../<repo-name>-<slug>
 Если в «Изменениях в docs» что-то накопилось — допиши в `docs/rules.md` или `docs/arch.md` минимально достаточно. Файлов нет — пропусти (создаёт `eda-docs`).
 
 ### 7. Финальная проверка
-Прогони полный сьют тестов и линтеры на проекте. Команды — стандартные для стека; если непонятно — `AskUserQuestion` один раз. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`. Результат фиксируй разделом `## Финальная проверка` в журнале.
+Прогони полный сьют тестов и линтеры на проекте. Команды — стандартные для стека; если непонятно — `AskUserQuestion` один раз. Свои поломки — правишь причину и повторяешь. Запрещено делать проверки зелёными через подавление ошибок, отключение правил, исключение файлов, ослабление конфигов или изменение команд проверки. Чужие/несвязанные — `AskUserQuestion`. Результат фиксируй разделом `## Финальная проверка` в журнале.
 
 ### 8. Финал
 Короткое сообщение: пути к плану и журналу, сводка шагов, результат финальной проверки, состояние git («не закоммичено»), 1–3 главных «что важно знать», подсказка «дальше — `eda-review` или `eda-commit`».
@@ -130,3 +131,4 @@ cd ../<repo-name>-<slug>
 - Делать паузу после каждого шага «для подтверждения».
 - Пропускать обновление чекбоксов и журнала — иначе теряется состояние.
 - Делать рискованное (удаление файлов, миграции, секреты) без подтверждения, даже если упомянуто в плане.
+- Подавлять ошибки линтеров, тестов, typecheck или других проверок вместо исправления кода.

package/skills/eda-review.md

@@ -0,0 +1,221 @@
+---
+name: eda-review
+description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует блочные замечания без таблиц: сначала контекст и обоснование без привязки к коду, затем конкретные локации; исправление так же сначала концептуально, потом конкретными шагами. Сохраняет в docs/reviews/. Всегда запускает параллельные специализированные проверки: выполнение плана, следование архитектуре, следование правилам. Кросс-CLI (Claude ↔ Codex) включается только флагом `strict`. Не правит код — это `eda-fix-by-review`.'
+---
+
+# Скил: Ревьюер (eda-review)
+
+Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь замечания, ставишь оценку, сохраняешь файл. Затем проверяешь ревью тремя параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
+
+## Режимы вызова
+
+- Обычный: `eda-review` — этапы 1–3 + финал. Кросс-CLI не запускается.
+- Строгий: `eda-review strict` — обычный режим + кросс-CLI соседним агентом + допил.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+
+Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Замечания должны опираться на правила и архитектуру проекта, а не на твои общие представления.
+2. **Интерактивные вопросы** — по разделу ниже. Если контекст понятен, не спрашивай.
+3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
+4. **План работ обязателен для ревью выполненных изменений.** Если путь к плану не указан в запросе и его нельзя однозначно определить из diff/ссылок, спроси путь к файлу плана и остановись до ответа. Не подставляй «последний план» наугад.
+5. **Мета-ревью тремя специализированными агентами — обязательно**, без флага: проверка выполнения плана, проверка архитектуры, проверка правил. Кросс-CLI — только в `strict`.
+6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
+7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
+8. **Не используй таблицы в файле ревью**, если пользователь прямо не попросил таблицу. Замечания, сверку с планом и рекомендации оформляй блоками друг под другом.
+9. **В каждом замечании сначала объясняй контекст без привязки к коду**, чтобы читатель понял проблему и риск. Только после этого давай конкретные файлы/строки. Исправление оформляй так же: сначала общий подход, затем конкретные шаги по коду.
+
+## Интерактивные вопросы
+
+Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос о цели ревью**. Это не отменяет обязательный вопрос о `$PLAN_FILE`, если план не указан и не найден однозначно. Примеры понятного контекста:
+- пользователь указал файл, папку, PR, ветку или тип diff;
+- в запросе есть «ревью незакоммиченных изменений», «ревью текущей ветки», «проверь PR #N»;
+- в рабочем дереве есть незакоммиченные изменения и пользователь просит «сделай ревью» без других целей.
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
+
+## Этапы
+
+### 1. Выбрать вход и прочитать контекст
+Сначала попробуй определить цель ревью без вопроса:
+- если пользователь указал файл, папку, PR, ветку или тип diff — используй это;
+- если пользователь просит ревью без уточнений и есть незакоммиченные изменения — используй `git diff HEAD`;
+- если незакоммиченных изменений нет, но текущая ветка не `main`/`master` и отличается от базовой ветки — используй `git diff <base>...HEAD`, где `<base>` выбери из существующих `main`, `master`, `origin/main`, `origin/master`;
+- если цель всё ещё неоднозначна или diff пустой — только тогда через `AskUserQuestion` спроси, что ревьюим: незакоммиченный diff (`git diff HEAD`) / diff ветки от main (`git diff main...HEAD`) / конкретный файл или папка / номер PR.
+
+Получи diff/исходник в `$TARGET`. Прочитай `docs/rules.md`, `docs/arch.md` и строго следуй им.
+
+Определи `$PLAN_FILE`:
+- если пользователь указал путь к плану — используй его;
+- если в diff, описании задачи или уже существующем review-файле есть однозначная ссылка на `docs/plans/...` — используй её;
+- если есть несколько возможных планов или нет ни одного — спроси: «Какой файл плана использовать для проверки выполнения работ?» и остановись до ответа;
+- если пользователь явно просит ревью без сверки с планом — продолжай, но в ревью укажи, что проверка выполнения плана пропущена по явному указанию пользователя.
+
+Если в diff видно отсылки к исследованию из `docs/researches/` — прочитай его тоже.
+
+### 2. Сделать первичное ревью и сохранить
+Пройдись по изменениям. Сначала проверь, выполнен ли `$PLAN_FILE`: что сделано, что сделано частично, что не сделано, какие отклонения создают риск. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию.
+
+Каждое замечание должно быть самостоятельным блоком:
+- заголовок с номером и коротким смыслом;
+- тип и рекомендация: `править обязательно`, `на усмотрение автора` или `не править`;
+- контекст: объяснение проблемы без привязки к конкретному коду;
+- риск: почему это важно для поведения, сопровождения, денег, безопасности или эксплуатации;
+- где: конкретные файлы/строки;
+- детали: что именно в коде подтверждает проблему;
+- как исправить: сначала общий подход без привязки к коду;
+- конкретные шаги: что поменять в файлах/тестах.
+
+Поставь оценку 0–100 (100 — идеально, 0 — переделывать).
+
+Сохрани в `docs/reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+
+```markdown
+---
+title: <заголовок>
+date: <YYYY-MM-DD HH:MM>
+target: <git diff HEAD | main...HEAD | path | PR#>
+mode: <normal | strict>
+score: <0..100>
+status: draft
+meta_reviewers: []
+---
+
+# Ревью: <заголовок>
+
+## Оценка
+**<N>/100.** <одно-два предложения почему>
+
+## Сверка с планом
+### 1. <пункт или этап плана>
+Статус: <выполнено | частично | не выполнено | не проверялось>
+
+Контекст:
+<что требовал план простыми словами, без привязки к коду>
+
+Итог:
+<что фактически сделано или не сделано>
+
+Конкретика:
+- `<path/file.ts:42>` — <короткое подтверждение>
+
+## Замечания
+### 1. <короткий заголовок проблемы>
+Тип: `bug`
+
+Рекомендация: `править обязательно`
+
+Контекст:
+<объясни проблему и предметную причину без привязки к конкретному коду>
+
+Риск:
+<что сломается или почему это важно>
+
+Где:
+- `<path/file.py:42>` — <что смотреть>
+
+Детали:
+<конкретное объяснение по коду>
+
+Как исправить:
+<общий подход без привязки к конкретному файлу>
+
+Конкретные шаги:
+- <что поменять в коде>
+- <какой тест добавить или обновить>
+
+## Рекомендации
+- **Править обязательно:** <номера>
+- **На усмотрение автора:** <номера>
+- **Не править:** <номера или —>
+
+## Изменения после мета-ревью
+<заполняется на этапах 3 и 4>
+```
+
+Покажи путь.
+
+### 3. Мета-ревью тремя специализированными агентами (параллельно)
+Запусти **в одном сообщении и одним batch** трёх агентов с разными ролями. Не запускай сначала одного-двух, не жди их ответы и не запускай третьего позже: все три проверки должны стартовать до чтения любого результата.
+
+Роли агентов:
+- `plan-check`: проверяет, что реализация действительно выполнила `$PLAN_FILE`, включая частичные пункты, пропущенные требования, лишние отклонения и недостающие проверки.
+- `architecture-check`: проверяет следование `docs/arch.md`, границы модулей, контракты, зависимости и соответствие существующим архитектурным решениям.
+- `rules-check`: проверяет следование `docs/rules.md`, локальным запретам, обязательным командам, требованиям к тестам, миграциям, документации и процессу.
+
+Модели:
+- Claude Code: запускай все три роли на `model: "sonnet"`.
+- Codex: запускай все три роли на `gpt-5.3-codex`.
+- Если нужный идентификатор недоступен, возьми ближайшую code-capable модель того же уровня. Не используй быструю слабую модель для этих трёх проверок: они должны читать diff, план, правила, архитектуру и релевантный код.
+
+Каждому дай путь к файлу ревью, `$TARGET`, `$PLAN_FILE`, `docs/rules.md`, `docs/arch.md`, связанный research при наличии. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
+
+Формат ответа агентов:
+- `+` что добавить в ревью;
+- `−` что убрать как неверное или недоказанное;
+- `~` что переформулировать;
+- `?` что невозможно проверить и почему.
+
+Для `plan-check` добавь явную инструкцию: «Если `$PLAN_FILE` не передан или файл не найден, верни только `? план не проверен: нужен путь к файлу`; не пытайся угадывать план.»
+
+Когда все три ответили: прочитай ответы, **сам реши**, что применять. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
+
+```markdown
+### После plan-check / architecture-check / rules-check
+- **+ Добавлено:** <короткий список>
+- **~ Изменено:** <короткий список>
+- **− Убрано:** <короткий список>
+- **Отклонено:** <короткий список с причиной>
+```
+
+Поменяй `status: draft` → `meta-reviewed`, в `meta_reviewers` добавь `plan-check`, `architecture-check`, `rules-check` и фактические модели, например `gpt-5.3-codex` или `sonnet`. Если оценка после корректировок изменилась — обнови `score`.
+
+### 4. Кросс-CLI: отдать соседнему агенту — только в `strict`
+Обычный режим — пропусти этап 4, иди на финал. `status: meta-reviewed` оставь как есть.
+
+В `strict`: отдай файл соседнему агенту через `Bash`. Если ты в Claude Code — запускай Codex CLI:
+
+```bash
+codex exec "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: что добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Формат: '+', '−', '~', '?' без таблиц." > "${REVIEW_FILE%.md}_cli_meta.md"
+```
+
+Если ты в Codex — запускай Claude CLI с теми же требованиями глубины:
+
+```bash
+claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: что добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Формат: '+', '−', '~', '?' без таблиц." > "${REVIEW_FILE%.md}_cli_meta.md"
+```
+
+Соседней CLI нет — `AskUserQuestion`: завершить как есть или прервать.
+
+Прочитай ответ, **сам реши**, что применять. Допиши в `## Изменения после мета-ревью`:
+
+```markdown
+### После соседнего CLI (codex|claude)
+- **+ Добавлено:** ...
+- **− Убрано:** ...
+- **Отклонено:** ...
+```
+
+Добавь в `meta_reviewers` имя CLI. `status: meta-reviewed` → `final`.
+
+### 5. Финал
+Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение» / «не править». Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review strict`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
+
+## Чего НЕ делать
+- Править код. Это `eda-fix-by-review`.
+- Пропускать мета-ревью тремя специализированными агентами (это часть обычного режима, не под флагом).
+- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом третьего. Все три стартуют сразу.
+- Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
+- Вставлять чужие предложения механически — каждое решение принимай ты.
+- Задавать вопросы без блокировки и продолжать работу до ответа.
+- Сохранять ревью куда-либо кроме `docs/reviews/`.
+- Оформлять замечания таблицей или без контекста перед конкретикой.

package/docs/skills/eda-review.md

@@ -1,166 +0,0 @@
----
-name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл). Если контекст ревью понятен из запроса или репозитория, не задаёт уточняющий вопрос и сразу выбирает цель. Перед ревью читает `docs/rules.md` и `docs/arch.md` и строго следует им. Формирует пронумерованные замечания, оценку 0–100, рекомендации «править / на усмотрение / не править». Сохраняет в docs/reviews/. Всегда проверяет своё же ревью тремя параллельными моделями (Sonnet, Haiku, Opus); кросс-CLI (Claude ↔ Codex) включается только флагом `strict`. После каждой проверки сам корректирует ревью. Не правит код — это `eda-fix-by-review`. Вопросы — только когда без ответа нельзя безопасно продолжать.'
----
-
-# Скил: Ревьюер (eda-review)
-
-Делаешь ревью изменений: пишешь замечания, ставишь оценку, сохраняешь файл. Затем проверяешь сам себя через три параллельные модели; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
-
-## Режимы вызова
-
-| Режим | Запуск | Что делает |
-|---|---|---|
-| Обычный | `eda-review` | Этапы 1–3 + финал. Кросс-CLI не запускается. |
-| Строгий | `eda-review strict` | + кросс-CLI соседним агентом + допил. |
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Замечания должны опираться на правила и архитектуру проекта, а не на твои общие представления.
-2. **Интерактивные вопросы** — по разделу ниже. Если контекст понятен, не спрашивай.
-3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
-4. **Мета-ревью тремя моделями — обязательно**, без флага. Кросс-CLI — только в `strict`.
-5. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
-6. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
-7. **Таблицы для замечаний.** Сплошной текст — только для оценки и общего вывода.
-
-## Интерактивные вопросы
-
-Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос**. Примеры понятного контекста:
-- пользователь указал файл, папку, PR, ветку или тип diff;
-- в запросе есть «ревью незакоммиченных изменений», «ревью текущей ветки», «проверь PR #N»;
-- в рабочем дереве есть незакоммиченные изменения и пользователь просит «сделай ревью» без других целей.
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-
-## Этапы
-
-### 1. Выбрать вход и прочитать контекст
-Сначала попробуй определить цель ревью без вопроса:
-- если пользователь указал файл, папку, PR, ветку или тип diff — используй это;
-- если пользователь просит ревью без уточнений и есть незакоммиченные изменения — используй `git diff HEAD`;
-- если незакоммиченных изменений нет, но текущая ветка не `main`/`master` и отличается от базовой ветки — используй `git diff <base>...HEAD`, где `<base>` выбери из существующих `main`, `master`, `origin/main`, `origin/master`;
-- если цель всё ещё неоднозначна или diff пустой — только тогда через `AskUserQuestion` спроси, что ревьюим: незакоммиченный diff (`git diff HEAD`) / diff ветки от main (`git diff main...HEAD`) / конкретный файл или папка / номер PR.
-
-Получи diff/исходник в `$TARGET`. Прочитай `docs/rules.md`, `docs/arch.md` и строго следуй им. Если в diff видно отсылки к плану из `docs/plans/` или исследованию из `docs/researches/` — прочитай их тоже.
-
-### 2. Сделать первичное ревью и сохранить
-Пройдись по изменениям. Замечания группируй по типу: bug / архитектура / стиль / тесты / безопасность / производительность / документация. Каждое — с локацией (`file:line`) и предложением «что сделать». Поставь оценку 0–100 (100 — идеально, 0 — переделывать).
-
-Сохрани в `docs/reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
-
-```markdown
----
-title: <заголовок>
-date: <YYYY-MM-DD HH:MM>
-target: <git diff HEAD | main...HEAD | path | PR#>
-mode: <normal | strict>
-score: <0..100>
-status: draft
-meta_reviewers: []
----
-
-# Ревью: <заголовок>
-
-## Оценка
-**<N>/100.** <одно-два предложения почему>
-
-## Замечания
-| # | Тип | Где | Что не так | Что предлагаешь |
-|---|-----|-----|------------|-----------------|
-| 1 | bug | `path/file.py:42` | ... | ... |
-
-## Рекомендации
-- **Править обязательно:** <номера>
-- **На усмотрение автора:** <номера>
-- **Не править:** <номера или —>
-
-## Изменения после мета-ревью
-<заполняется на этапах 3 и 4>
-```
-
-Покажи путь.
-
-### 3. Мета-ревью тремя моделями (параллельно)
-Запусти **в одном сообщении и одним batch** трёх агентов на трёх разных моделях — слабая, средняя, мощная. Не запускай сначала одного-двух, не жди их ответы и не запускай третьего позже: все три проверки должны стартовать до чтения любого результата.
-
-| Среда | Слабая (быстрая) | Средняя (код) | Мощная (флагман) |
-|---|---|---|---|
-| Claude Code (`Agent` tool) | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
-| Codex CLI (`codex exec --model …`) | `gpt-5.4-mini` | `gpt-5.3-codex` | `gpt-5.5` |
-
-В Claude Code запускай три параллельных `Agent` tool в одном ответе/tool-use batch с моделями из таблицы и передавай им промпты нужной глубины из таблицы ниже. В Codex запускай три параллельных `codex exec --model <id>` одной Bash-командой с `&` и общим `wait`. Если `gpt-5.5` недоступен (ограничение account/auth) — возьми `gpt-5.4` как мощную. Если какой-либо идентификатор отсутствует у тебя — возьми ближайший аналог того же тира из доступных в твоей версии Codex.
-
-Каждому дай путь к файлу ревью, указание на `$TARGET`, `docs/rules.md`, `docs/arch.md` (если есть), связанный план/research (если ревью на них ссылается). Формулируй задание как содержательную проверку с глубиной чтения, указанной для тира модели ниже.
-
-Глубина проверки зависит от модели:
-
-| Модель | Что просить |
-|---|---|
-| Слабая | Быстро проверить ревью, diff и правила; код смотреть только точечно, если без этого нельзя оценить пункт. |
-| Средняя | Проверить ревью по diff и прочитать релевантные файлы/контракты, которые прямо следуют из изменений; найти пропущенные или неверные замечания. |
-| Мощная | Провести глубокую проверку: прочитать ревью, diff, правила, архитектуру, связанный план/research и релевантный код настолько глубоко, чтобы подтвердить корректность замечаний, найти пропущенные баги, риски для смежного кода и недостающие тесты. |
-
-Базовый формат ответа для всех: `+ N | − N | ~ N: причина`, без воды. Для мощной модели добавь явную инструкцию: «Если ревью или diff ссылаются на модуль, API, тесты или сценарий, открой соответствующие файлы и проверь фактическое поведение проекта.»
-
-Когда все три ответили: прочитай ответы, **сам реши**, что применять. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
-
-```markdown
-### После Sonnet/Haiku/Opus
-- **+ Добавлено:** <короткий список>
-- **− Убрано:** <короткий список>
-- **Отклонено:** <короткий список с причиной>
-```
-
-Поменяй `status: draft` → `meta-reviewed`, в `meta_reviewers` добавь `sonnet, haiku, opus`. Если оценка после корректировок изменилась — обнови `score`.
-
-### 4. Кросс-CLI: отдать соседнему агенту — только в `strict`
-Обычный режим — пропусти этап 4, иди на финал. `status: meta-reviewed` оставь как есть.
-
-В `strict`: отдай файл соседнему агенту через `Bash`. Если ты в Claude Code — запускай Codex CLI:
-
-```bash
-codex exec "Прочитай $REVIEW_FILE, $TARGET, docs/rules.md, docs/arch.md, связанный план/research при наличии. Затем глубоко проверь ревью по релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: какие пункты добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Список '+ N | − N | ~ N: причина'." > "${REVIEW_FILE%.md}_cli_meta.md"
-```
-
-Если ты в Codex — запускай Claude CLI с теми же требованиями глубины:
-
-```bash
-claude -p "Прочитай $REVIEW_FILE, $TARGET, docs/rules.md, docs/arch.md, связанный план/research при наличии. Затем глубоко проверь ревью по релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: какие пункты добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Список '+ N | − N | ~ N: причина'." > "${REVIEW_FILE%.md}_cli_meta.md"
-```
-
-Соседней CLI нет — `AskUserQuestion`: завершить как есть или прервать.
-
-Прочитай ответ, **сам реши**, что применять. Допиши в `## Изменения после мета-ревью`:
-
-```markdown
-### После соседнего CLI (codex|claude)
-- **+ Добавлено:** ...
-- **− Убрано:** ...
-- **Отклонено:** ...
-```
-
-Добавь в `meta_reviewers` имя CLI. `status: meta-reviewed` → `final`.
-
-### 5. Финал
-Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение» / «не править». Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review strict`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
-
-## Чего НЕ делать
-- Править код. Это `eda-fix-by-review`.
-- Пропускать мета-ревью тремя моделями (это часть обычного режима, не под флагом).
-- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом третьего. Все три стартуют сразу.
-- Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
-- Вставлять чужие предложения механически — каждое решение принимай ты.
-- Задавать вопросы без блокировки и продолжать работу до ответа.
-- Сохранять ревью куда-либо кроме `docs/reviews/`.
-- Оформлять замечания сплошным текстом — только таблица.