@gian-tiaga/eda 0.6.2 → 0.8.0

package/skills/eda-polish.md

@@ -0,0 +1,113 @@
+---
+name: eda-polish
+description: 'Автономно доводит изменения до заданной оценки ревью: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional`, и повторяет цикл до порога качества или лимита итераций. По умолчанию цель — 95/100, лимит — 5 итераций; порог можно переопределить в сообщении (`до 90`, `threshold 90`). Каждый шаг запускается в изолированном субагенте или отдельном CLI-процессе. Не коммитит и не отправляет ревью.'
+---
+
+# Скил: Доводка по ревью (eda-polish)
+
+Оркестрируешь цикл проверки и исправления: черновое ревью, проверка ревью, применение замечаний, новое ревью. Сам не пишешь ревью и не правишь код в основном агенте — каждый шаг запускаешь в изолированном субагенте или отдельном CLI-процессе.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: target для ревью, путь к плану, PR/ветку/diff/файл, желаемый порог, лимит итераций, ограничения и прямые указания.
+
+Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск полировать не те изменения. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Режим запуска
+
+Порог качества по умолчанию — `95`. Пользователь может переопределить его в текущем сообщении: `до 90`, `threshold 90`, `цель 90`. Допустимые значения — от `1` до `100`.
+
+Лимит по умолчанию — `5` итераций. Пользователь может явно задать меньший или больший лимит словами `лимит 3`, `max iterations 3`, `не больше 3 кругов`.
+
+`strict` или `normal` передавай в `eda-review-check` только если пользователь явно указал режим. Если режима нет, запускай `eda-review-check` без режима: он сам прочитает `docs/settings.yaml`. `eda-review draft` всегда остаётся draft без субагентов.
+
+## Главные правила
+
+1. **Изоляция шагов обязательна.** `eda-review draft`, `eda-review-check` и `eda-fix-by-review apply-optional` запускаются отдельными субагентами или отдельными CLI-процессами. Главный агент только управляет циклом и читает артефакты.
+2. **Не коммитишь и не отправляешь ревью.** Это работа `eda-commit` и `eda-send-review`.
+3. **Не обходишь границы скилов.** Ревью делает `eda-review draft`, проверку ревью делает `eda-review-check`, правки делает `eda-fix-by-review apply-optional`.
+4. **Цель цикла — score из проверенного ревью.** Сравнивай порог только с ревью после `eda-review-check`, не с draft.
+5. **Optional-замечания применяются автоматически.** Для шага фиксов всегда передавай `apply-optional`, чтобы `eda-fix-by-review` применил пункты «на усмотрение автора» без вопроса.
+6. **Останавливайся на блокерах.** Если любой субагент завершился `blocked`, проверки не проходят из-за нерешённой причины, нет применимых замечаний или score не растёт два круга подряд — останови цикл и объясни причину.
+7. **Не скрывай неудачную сходимость.** Если лимит достигнут, финал должен прямо сказать, какая оценка получилась и какие ревью/фиксы были последними.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
+
+## Запуск субагентов
+
+Каждый запуск должен получать полный, самодостаточный prompt: какой скилл выполнить, какой target или файл использовать, что считать успехом, где искать артефакт результата. Передавай только текущий вход и пути к созданным файлам, а не длинную историю чата.
+
+- Claude Code: запускай шаги через `Agent` tool, по одному шагу за раз. Для каждого шага проси агента использовать нужный скилл и вернуть путь к созданному или обновлённому файлу.
+- Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), запускай шаги через него. Не делай ревью или фиксы основным агентом, когда субагенты доступны.
+- Codex exec / неинтерактивный fallback: запускай каждый шаг отдельным `codex exec` с явной инструкцией использовать нужный скилл. Следующий шаг стартует только после чтения артефакта предыдущего.
+- Если нет ни субагентов, ни CLI-fallback, остановись со статусом `blocked: нужен инструмент изолированного запуска`.
+
+## Этапы
+
+### 1. Подготовить цель и параметры
+
+Определи `$TARGET_CONTEXT` так же, как это делает `eda-review`: указанный файл/папка/PR/ветка, незакоммиченный diff или diff текущей ветки от base. Если план указан — сохрани путь и передавай его в каждый `eda-review draft`. Если план нужен, но не указан и не определяется однозначно, вопрос задаст субагент `eda-review draft`; при его `blocked` останови весь цикл.
+
+Создай внутренний журнал итераций в сообщении агента: номер, review file, checked score, fix report, причина перехода к следующему кругу. Отдельный файл журнала не нужен.
+
+### 2. Итерационный цикл
+
+Повторяй до достижения порога или лимита:
+
+1. Запусти изолированный шаг:
+
+   ```text
+   Используй скилл eda-review draft. Сделай черновое ревью для: <TARGET_CONTEXT>. Если есть план: <PLAN_FILE>. Сохрани ревью в docs/reviews/ и верни только путь к файлу и score.
+   ```
+
+2. Получи `$REVIEW_FILE` из ответа или найди самый новый файл, созданный после старта шага. Если файл не найден — остановись `blocked: review file не создан`.
+
+3. Запусти изолированный шаг:
+
+   ```text
+   Используй скилл eda-review-check <режим, только если пользователь указал strict или normal>. Проверь ревью: <REVIEW_FILE>. Верни путь к ревью, итоговый score, статус и список meta_reviewers.
+   ```
+
+4. Прочитай `$REVIEW_FILE` после проверки и извлеки `score`. Если `score >= threshold`, останови цикл как успешный.
+
+5. Если score ниже порога, проверь, есть ли в ревью пункты «править обязательно» или «на усмотрение автора». Если применимых пунктов нет — остановись `blocked: нет применимых замечаний для повышения оценки`.
+
+6. Запусти изолированный шаг:
+
+   ```text
+   Используй скилл eda-fix-by-review apply-optional. Примени замечания из ревью: <REVIEW_FILE>. Применяй пункты «править обязательно» и «на усмотрение автора». Сохрани отчёт в docs/review-fixes/ и верни путь к отчёту, результат финальных проверок и состояние git.
+   ```
+
+7. Если фикс завершился `blocked`, с ошибкой проверок или без применённых правок — останови цикл и покажи причину.
+
+8. Перейди к следующей итерации на обновлённом рабочем дереве.
+
+Если score не растёт два проверенных круга подряд, остановись раньше лимита: дальнейший цикл, скорее всего, повторит те же замечания.
+
+### 3. Финал
+
+Короткое сообщение:
+- результат: `достигнут порог`, `достигнут лимит`, `blocked`, `нет применимых замечаний`, `score не растёт`;
+- итоговая оценка и порог;
+- сколько итераций выполнено;
+- путь к последнему ревью;
+- путь к последнему отчёту фиксов, если он был;
+- результат финальной проверки из последнего `eda-fix-by-review`;
+- состояние git («не закоммичено»).
+
+Если порог достигнут — предложи дальше `eda-commit`. Если остановка неуспешная — назови следующий конкретный шаг: ручное решение блокера, изменение порога или отдельный `eda-review strict`.
+
+## Чего НЕ делать
+
+- Делать ревью, проверку ревью или фиксы основным агентом вместо запуска скилов.
+- Запускать следующий шаг, не прочитав артефакт предыдущего.
+- Сравнивать порог с draft-оценкой до `eda-review-check`.
+- Продолжать после `blocked` или красных финальных проверок.
+- Коммитить, пушить или отправлять ревью.
+- Переписывать `docs/settings.yaml` или менять правила проекта ради достижения оценки.

package/skills/eda-review-check.md

@@ -0,0 +1,149 @@
+---
+name: eda-review-check
+description: 'Проверяет готовое ревью из `docs/reviews/...` специализированными субагентами и, в strict-режиме, соседним CLI. Не делает первичное ревью и не правит код. Читает ревью, target/plan из front matter, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml` и связанный research при наличии. Запускает architecture-check, rules-check, plan-check только при указанном plan-файле и опциональный quality-check, затем сам применяет подтверждённые замечания к файлу ревью: добавляет, убирает или переформулирует пункты, обновляет score/status/meta_reviewers и раздел изменений после мета-ревью.'
+---
+
+# Скил: Проверка ревью (eda-review-check)
+
+Берёшь уже сохранённое ревью из `docs/reviews/`, проверяешь его специализированными субагентами, затем сам правишь файл ревью по подтверждённым замечаниям. Этот скил переиспользуется обычным `eda-review` после draft-этапа и может запускаться отдельно.
+
+## Режим запуска
+
+Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
+
+Дефолты: `defaults.strict: false`, `review.include_code_quality: true`.
+
+| Настройка | Значения | Аргументы в сообщении |
+|---|---|---|
+| `defaults.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
+| `review.include_code_quality` | `true`, `false` | «проверь качество кода»; выключение: «без quality», «без проверки качества» |
+
+`strict` добавляет кросс-CLI соседним агентом. `review.include_code_quality: true` добавляет `quality-check` в обычное мета-ревью.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: путь к ревью, название или часть названия, «последнее ревью», режим, ограничения и прямые указания.
+
+Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск проверить не то ревью. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Не делаешь первичное ревью.** Входом всегда является готовый файл `docs/reviews/...`.
+2. **Не правишь код.** Можно менять только выбранный файл ревью и вспомогательный файл `${REVIEW_FILE%.md}_cli_meta.md` в strict-режиме.
+3. **Мета-ревью специализированными агентами обязательно.** Базовые роли: `architecture-check`, `rules-check`. `plan-check` запускай только если в front matter ревью `plan` указывает на конкретный файл. Если включена проверка качества кода — добавь `quality-check` в тот же batch.
+4. **Главный редактор ревью — ты.** Субагенты дают предложения; решение добавить, убрать или переформулировать пункт принимаешь сам.
+5. **Ревью остаётся ревью только по проблемам.** Не добавляй выполненные пункты, похвалу, нейтральный отчёт о diff или общие рассуждения.
+6. **Каждое принятое изменение фиксируй в `## Изменения после мета-ревью`.** Отклонённые предложения тоже запиши коротко с причиной.
+7. **Оценку пересчитывай после правок.** Если изменился набор или тяжесть замечаний, обнови `score` в front matter и текст в разделе `## Оценка`.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
+
+## Этапы
+
+### 1. Выбрать ревью и прочитать контекст
+
+Определи `$REVIEW_FILE`:
+- если пользователь указал путь к ревью — используй его;
+- если указал название или часть названия — найди совпадение в `docs/reviews/`;
+- если написал «последнее ревью» — возьми самый новый файл из `docs/reviews/`;
+- если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`;
+- если `docs/reviews/` отсутствует или пуста — остановись со статусом `blocked: нужно ревью`.
+
+Прочитай `$REVIEW_FILE` целиком. Из front matter и текста извлеки `$TARGET`, `$PLAN_FILE`, текущие `mode`, `score`, `status`, `meta_reviewers`. Если `plan: none` или план явно помечен как пропущенный, установи `$PLAN_FILE=none`. Если target указывает на diff-команду, получи актуальный diff. Если target указывает на файл, папку или PR — прочитай достаточно кода, чтобы проверить замечания. Прочитай `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, если они есть. Если ревью ссылается на `docs/researches/...`, прочитай связанный research.
+
+Если `$PLAN_FILE=none` или отсутствует, не угадывай план и не запускай `plan-check`. В разделе изменений после мета-ревью коротко зафиксируй: «plan-check не запускался: план не указан в ревью».
+
+### 2. Запустить специализированных субагентов
+
+Запусти **в одном сообщении и одним batch** агентов с выбранными ролями. В интерактивном Codex это означает субагентов, а не отдельные процессы `codex exec`. Не запускай сначала часть агентов, не жди их ответы и не запускай остальных позже: все выбранные проверки должны стартовать до чтения любого результата.
+
+Роли агентов:
+- `plan-check`: запускай только если `$PLAN_FILE` указывает на существующий файл. Проверяет, что реализация действительно выполнила `$PLAN_FILE`, включая частичные пункты, пропущенные требования, лишние отклонения и недостающие проверки.
+- `architecture-check`: проверяет следование `docs/arch.md`, границы модулей, контракты, зависимости и соответствие существующим архитектурным решениям.
+- `rules-check`: проверяет следование `docs/rules.md`, локальным запретам, обязательным командам, требованиям к тестам, миграциям, документации и процессу.
+- `quality-check`: запускай только если `review.include_code_quality: true` или пользователь явно попросил качество кода. Проверяет качество реализации: читаемость, сложность, дублирование, имена, размер и ответственность функций/классов, сцепление модулей, поддерживаемость и соответствие локальному стилю. Quality-замечания помечай типом `quality`; по умолчанию рекомендация `на усмотрение автора`, кроме случаев, где сложность, дублирование или неясная структура реально создают риск багов, тестовых пробелов или дорогого сопровождения.
+
+Модели:
+- Claude Code: запускай все роли через `Agent` tool на `model: "sonnet"`.
+- Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), запускай все роли через него на `gpt-5.3-codex`; не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны.
+- Codex exec / неинтерактивный fallback: если инструмента субагентов нет, запускай роли через параллельные `codex exec --model gpt-5.3-codex` одной Bash-командой с `&` и общим `wait`.
+- Если нужный идентификатор недоступен, возьми ближайшую code-capable модель того же уровня. Не используй быструю слабую модель для этих проверок: они должны читать diff, план при наличии, правила, архитектуру и релевантный код.
+
+Каждому агенту дай путь к `$REVIEW_FILE`, `$TARGET`, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, связанный research при наличии. `plan-check` дополнительно получает `$PLAN_FILE`, если он есть. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
+
+Формат ответа агентов:
+- `+` какую проблему добавить в ревью;
+- `−` что убрать как неверное или недоказанное;
+- `~` что переформулировать;
+- `?` что невозможно проверить и почему.
+
+Если `$PLAN_FILE` не передан, равен `none` или файл не найден, `plan-check` не запускай.
+
+### 3. Применить результаты обычного мета-ревью
+
+Когда все агенты ответили: прочитай ответы, **сам реши**, что применять. Добавляй только подтверждённые проблемы; предложения вида «добавить, что пункт выполнен» отклоняй как неформат ревью. Внеси правки в файл ревью.
+
+В разделе `## Изменения после мета-ревью` запиши:
+
+```markdown
+### После plan-check / architecture-check / rules-check / quality-check
+- **+ Добавлено:** <короткий список>
+- **~ Изменено:** <короткий список>
+- **− Убрано:** <короткий список>
+- **Отклонено:** <короткий список с причиной>
+```
+
+Поменяй `status: draft` → `meta-reviewed`, если статус был draft. В `meta_reviewers` добавь только фактически запущенные роли: `architecture-check`, `rules-check`, `plan-check` при наличии `$PLAN_FILE`, а если запускался — `quality-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"
+```
+
+Если `$PLAN_FILE=none`, в промпте соседнему CLI явно напиши: «План не указан; не проверяй выполнение плана и не угадывай файл плана, проверь только правила, архитектуру и код».
+
+Соседней CLI нет — `AskUserQuestion`: завершить как есть или прервать.
+
+Прочитай ответ, **сам реши**, что применять. Допиши в `## Изменения после мета-ревью`:
+
+```markdown
+### После соседнего CLI (codex|claude)
+- **+ Добавлено:** ...
+- **− Убрано:** ...
+- **Отклонено:** ...
+```
+
+Добавь в `meta_reviewers` имя CLI. `status: meta-reviewed` → `final`.
+
+### 5. Финал
+
+Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение», какие meta-reviewers запускались. Не пересказывай выполненную работу. Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review-check strict <review>`».
+
+## Чего НЕ делать
+
+- Делать первичное ревью. Это `eda-review`.
+- Править код. Это `eda-fix-by-review`.
+- Пропускать мета-ревью специализированными агентами.
+- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом остальных. Все выбранные обязательные проверки стартуют сразу.
+- Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
+- Вставлять чужие предложения механически — каждое решение принимай ты.
+- Задавать вопросы без блокировки и продолжать работу до ответа.
+- Сохранять или редактировать ревью вне `docs/reviews/`.
+- Перечислять выполненные пункты плана или давать общий отчёт о проделанной работе.

package/skills/eda-review.md

@@ -1,76 +1,54 @@
 ---
 name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью только по проблемам: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Не перечисляет выполненную работу. Сохраняет в docs/reviews/. Всегда запускает параллельные специализированные субагентные проверки: выполнение плана, следование архитектуре, следование правилам; проверка качества кода включается настройкой `review.include_code_quality: true` в `docs/settings.yaml`. Кросс-CLI (Claude ↔ Codex) включается флагом `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 с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Каждый пункт начинаешь с короткого человеческого объяснения риска, без технической перегрузки; файлы, строки, детали кода и способ исправления даёшь ниже в блоке «Технические детали». Не перечисляешь, что выполнено хорошо или без замечаний. Затем проверяешь ревью параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
+Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Если скилл вызван без аргументов, ревьюишь незакоммиченный `git diff HEAD` и не проверяешь план. Каждый пункт начинаешь с короткого человеческого объяснения риска, без технической перегрузки; файлы, строки, детали кода и способ исправления даёшь ниже в блоке «Технические детали». Не перечисляешь, что выполнено хорошо или без замечаний. Затем в обычном режиме запускаешь `eda-review-check`, который проверяет ревью параллельными специализированными агентами; в `strict` он добавляет соседний CLI. В `draft` останавливаешься сразу после сохранения черновика.
 
-## Режимы вызова
+## Режим запуска
 
-- Обычный: `eda-review` — этапы 1–3 + финал. Кросс-CLI не запускается.
-- Строгий: `eda-review strict` — обычный режим + кросс-CLI соседним агентом + допил.
+Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
 
-Если в `docs/settings.yaml` указано `defaults.strict: true`, строгий режим включён по умолчанию. Явное указание пользователя в текущем сообщении важнее настройки: `strict` включает строгий режим, `normal` / `без strict` / `без строгого режима` выключает его для текущего запуска.
+Дефолты: `defaults.strict: false`, `review.include_code_quality: true`.
 
-## Вход из сообщения пользователя
+| Настройка | Значения | Аргументы в сообщении |
+|---|---|---|
+| `defaults.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
+| `review.include_code_quality` | `true`, `false` | «проверь качество кода»; выключение: «без quality», «без проверки качества» |
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+`strict` добавляет кросс-CLI соседним агентом. `review.include_code_quality: true` добавляет `quality-check` в обычное мета-ревью.
 
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+Флаг `draft` отключает весь этап `eda-review-check`: сохрани ревью со `status: draft`, `meta_reviewers: []`, покажи путь и оценку, затем остановись. `draft` важнее `strict`: если пользователь написал оба режима, задай `AskUserQuestion`, потому что требования противоречат друг другу.
 
-## Настройки проекта
-
-Перед выбором режима и набора проверок прочитай `docs/settings.yaml`, если файл есть.
+## Вход из сообщения пользователя
 
-Если файла нет — используй значения по умолчанию:
-- `defaults.strict: false`
-- `review.include_code_quality: true`
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
 
-Прямое указание пользователя в текущем сообщении важнее `docs/settings.yaml`: `strict` включает строгий режим, `normal` / `без strict` выключает его; «проверь качество кода» включает quality-проверку, «без quality» / «без проверки качества» выключает её для текущего запуска.
+Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
 ## Главные правила
 
 1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Замечания должны опираться на правила и архитектуру проекта, а не на твои общие представления.
 2. **Интерактивные вопросы** — по разделу ниже. Если контекст понятен, не спрашивай.
 3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
-4. **План работ обязателен для ревью выполненных изменений.** Если путь к плану не указан в запросе и его нельзя однозначно определить из diff/ссылок, спроси путь к файлу плана и остановись до ответа. Не подставляй «последний план» наугад.
-5. **Мета-ревью специализированными агентами — обязательно**, без флага: проверка выполнения плана, проверка архитектуры, проверка правил. Если включена проверка качества кода — добавь `quality-check` тем же batch. Кросс-CLI — только в `strict`.
+4. **План работ обязателен для явно заданного ревью выполненных изменений.** Если пользователь указал файл, папку, PR, ветку, тип diff или другую цель ревью, а путь к плану не указан и его нельзя однозначно определить из diff/ссылок, спроси путь к файлу плана и остановись до ответа. Исключение: запуск без аргументов — ревью незакоммиченного `git diff HEAD` без проверки плана. Не подставляй «последний план» наугад.
+5. **Мета-ревью специализированными агентами — обязательно в normal/strict**, но выполняется отдельным скиллом `eda-review-check`. В `draft` мета-ревью не запускается.
 6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
 7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
 8. **Ревью содержит только проблемы.** Не пиши отчёт о выполненной работе, список успешно сделанных пунктов, похвалу или нейтральное перечисление изменений. В файл попадают только ошибки, недоделки, неточности, спорные решения, нарушения правил/архитектуры, риски и недостающие проверки. Если проблем нет, напиши коротко: «Явных проблем не найдено», без пересказа diff.
 9. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Проблемы сверки с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Внутри каждого пункта сначала идёт основная часть простым языком, затем блок `Технические детали`.
-10. **Основная часть замечания — главный ответ.** Пиши 2–4 коротких абзаца: что происходит, почему это проблема, какой практический риск, когда риск проявится. Не начинай с имён классов, методов, строк, SQL, DTO, конфигов и внутренних деталей.
+10. **Основная часть замечания — главный ответ.** Пиши 1–3 коротких абзаца, и в эти же абзацы включай весь человеческий верх пункта: короткий контекст, понятный без чтения плана, diff и истории задачи; что происходит или что не подтверждено; почему это важно, какой практический риск и когда он проявится. Не начинай с имён классов, методов, строк, SQL, DTO, конфигов и внутренних деталей.
 11. **Технические детали — ниже основной части.** Там укажи тип, рекомендацию, файлы/строки, что в коде подтверждает проблему, общий подход к исправлению и конкретные шаги. Если деталь не помогает понять или исправить проблему — не пиши её.
 
 ## Стиль замечаний
 
-Пиши так, чтобы первый экран пункта можно было прочитать без глубокого знания кода. Хороший пункт похож на короткое объяснение ревьюера человеку:
-
-```markdown
-### 1. Может быть слишком много запросов во внешний сервис
-
-Сейчас проверка идёт по одному ответу за раз: один ответ в нашей системе — один запрос во внешний сервис.
-
-Если таких ответов 50, задача может сделать 50 запросов подряд. У внешнего сервиса на такие методы обычно есть ограничения по частоте. Если общая защита от лимитов реально разруливает это снаружи, пункт можно ослабить. Но по самому PR этого не видно.
-
-Риск такой: внешний сервис начнёт отвечать ошибками, а ответы в нашей системе продолжат висеть «на проверке».
-
-Технические детали:
-
-- **Тип:** `performance`
-- **Рекомендация:** `править обязательно`
-- **Где:** `path/to/file.ts:42` — цикл с запросом на каждый ответ.
-- **Как исправить:** добавить батчинг, ограничение параллелизма или явную обработку rate limit.
-- **Тесты:** проверить несколько ответов, ошибку внешнего сервиса и повторный запуск задачи.
-```
-
-Это ориентир по стилю, а не текст для копирования. Не растягивай пункт: основная часть должна быть короче технических деталей или сопоставима с ними, без канцелярита и без пересказа всего diff.
+Пиши так, чтобы первый экран пункта можно было прочитать без глубокого знания кода и без знания плана, diff или истории задачи: в 1–3 коротких абзацах объясни контекст, ситуацию, риск и когда он проявится; затем дай `Технические детали`. Не растягивай пункт, не пересказывай весь diff и не начинай с имён классов, методов, строк, SQL, DTO, конфигов.
 
 ## Интерактивные вопросы
 
-Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос о цели ревью**. Это не отменяет обязательный вопрос о `$PLAN_FILE`, если план не указан и не найден однозначно. Примеры понятного контекста:
+Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос о цели ревью**. Это не отменяет обязательный вопрос о `$PLAN_FILE` для явно заданной цели, если план не указан и не найден однозначно. Для запуска без аргументов вопрос о плане не задавай: проверка плана пропускается. Примеры понятного контекста:
 - пользователь указал файл, папку, PR, ветку или тип diff;
 - в запросе есть «ревью незакоммиченных изменений», «ревью текущей ветки», «проверь PR #N»;
 - в рабочем дереве есть незакоммиченные изменения и пользователь просит «сделай ревью» без других целей.
@@ -92,20 +70,21 @@ description: 'Ревью изменений (незакоммиченный diff
 
 Получи diff/исходник в `$TARGET`. Прочитай `docs/rules.md`, `docs/arch.md` и строго следуй им.
 
-Определи `$PLAN_FILE`:
+Определи `$PLAN_FILE` и `$PLAN_MODE`:
+- если пользователь вызвал скилл без аргументов, а целью выбран незакоммиченный `git diff HEAD` — установи `$PLAN_FILE=none`, `$PLAN_MODE=skipped_no_args` и не спрашивай план;
 - если пользователь указал путь к плану — используй его;
 - если в diff, описании задачи или уже существующем review-файле есть однозначная ссылка на `docs/plans/...` — используй её;
-- если есть несколько возможных планов или нет ни одного — спроси: «Какой файл плана использовать для проверки выполнения работ?» и остановись до ответа;
+- если цель ревью явно задана пользователем и есть несколько возможных планов или нет ни одного — спроси: «Какой файл плана использовать для проверки выполнения работ?» и остановись до ответа;
 - если пользователь явно просит ревью без сверки с планом — продолжай, но в ревью укажи, что проверка выполнения плана пропущена по явному указанию пользователя.
 
 Если в diff видно отсылки к исследованию из `docs/researches/` — прочитай его тоже.
 
 ### 2. Сделать первичное ревью и сохранить
-Пройдись по изменениям. Сначала проверь, выполнен ли `$PLAN_FILE`, но в ревью выноси только проблемы: что сделано частично, что не сделано, какие отклонения создают риск, какие проверки отсутствуют. Не перечисляй выполненные пункты плана. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию. Если `review.include_code_quality: true` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
+Пройдись по изменениям. Если `$PLAN_FILE` указывает на файл, сначала проверь, выполнен ли план, но в ревью выноси только проблемы: что сделано частично, что не сделано, какие отклонения создают риск, какие проверки отсутствуют. Если `$PLAN_FILE=none`, не делай проверку плана и не пытайся восстановить план из последних файлов. Не перечисляй выполненные пункты плана. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию. Если `review.include_code_quality: true` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
 
 Каждое замечание должно быть самостоятельным блоком:
 - заголовок с номером и коротким смыслом;
-- основная часть простым языком: контекст, проблема и риск без привязки к конкретному коду;
+- основная часть простым языком: 1–3 коротких абзаца, которые включают контекст, проблему и риск без привязки к конкретному коду;
 - `Технические детали`: тип, рекомендация, конкретные файлы/строки, что именно в коде подтверждает проблему, как исправить и какие тесты добавить или обновить.
 
 Поставь оценку 0–100 (100 — идеально, 0 — переделывать).
@@ -117,7 +96,8 @@ description: 'Ревью изменений (незакоммиченный diff
 title: <заголовок>
 date: <YYYY-MM-DD HH:MM>
 target: <git diff HEAD | main...HEAD | path | PR#>
-mode: <normal | strict>
+plan: <docs/plans/... | none>
+mode: <draft | normal | strict>
 score: <0..100>
 status: draft
 meta_reviewers: []
@@ -131,11 +111,11 @@ meta_reviewers: []
 
 ## Проблемы сверки с планом
 
-<Если проблем по плану нет: «Явных проблем по плану не найдено.»>
+<Если `$PLAN_FILE=none`: «Проверка плана пропущена: запуск без аргументов использует незакоммиченный `git diff HEAD` без сверки с планом.» Если проблем по плану нет: «Явных проблем по плану не найдено.»>
 
 ### 1. <недоделка, отклонение или непроверенный пункт>
 
-<2–4 коротких абзаца: что требовал план, что не сделано или не подтверждено, почему это важно. Без имён файлов, строк и внутренних деталей в начале пункта.>
+<1–3 коротких абзаца: короткий контекст, понятный без плана, diff и истории задачи; что требовал план; что не сделано или не подтверждено; почему это важно, какой риск и когда он проявится. Без имён файлов, строк и внутренних деталей в начале пункта.>
 
 Технические детали:
 
@@ -150,7 +130,7 @@ meta_reviewers: []
 
 ### 1. <короткий заголовок проблемы>
 
-<2–4 коротких абзаца: что происходит, почему это проблема, какой практический риск, когда он проявится. Без технической перегрузки и без пересказа diff.>
+<1–3 коротких абзаца: короткий контекст, понятный без плана, diff и истории задачи; что происходит; почему это проблема; какой практический риск и когда он проявится. Без технической перегрузки и без пересказа diff.>
 
 Технические детали:
 
@@ -173,77 +153,19 @@ meta_reviewers: []
 
 Покажи путь.
 
-### 3. Мета-ревью специализированными агентами (параллельно)
-Запусти **в одном сообщении и одним batch** агентов с разными ролями. В интерактивном Codex это означает субагентов, а не отдельные процессы `codex exec`. Базовые три роли обязательны всегда. Если включена проверка качества кода, в тот же batch добавь четвёртого агента `quality-check`. Не запускай сначала часть агентов, не жди их ответы и не запускай остальных позже: все проверки должны стартовать до чтения любого результата.
-
-Роли агентов:
-- `plan-check`: проверяет, что реализация действительно выполнила `$PLAN_FILE`, включая частичные пункты, пропущенные требования, лишние отклонения и недостающие проверки.
-- `architecture-check`: проверяет следование `docs/arch.md`, границы модулей, контракты, зависимости и соответствие существующим архитектурным решениям.
-- `rules-check`: проверяет следование `docs/rules.md`, локальным запретам, обязательным командам, требованиям к тестам, миграциям, документации и процессу.
-- `quality-check`: запускай только если `review.include_code_quality: true` или пользователь явно попросил качество кода. Проверяет качество реализации: читаемость, сложность, дублирование, имена, размер и ответственность функций/классов, сцепление модулей, поддерживаемость и соответствие локальному стилю. Quality-замечания помечай типом `quality`; по умолчанию рекомендация `на усмотрение автора`, кроме случаев, где сложность, дублирование или неясная структура реально создают риск багов, тестовых пробелов или дорогого сопровождения.
-
-Модели:
-- Claude Code: запускай все роли через `Agent` tool на `model: "sonnet"`.
-- Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), запускай все роли через него на `gpt-5.3-codex`; не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны.
-- Codex exec / неинтерактивный fallback: если инструмента субагентов нет, запускай роли через параллельные `codex exec --model gpt-5.3-codex` одной Bash-командой с `&` и общим `wait`.
-- Если нужный идентификатор недоступен, возьми ближайшую code-capable модель того же уровня. Не используй быструю слабую модель для этих проверок: они должны читать diff, план, правила, архитектуру и релевантный код.
+Если режим `draft` — не запускай субагентов и не вызывай `eda-review-check`; сразу переходи к финалу draft.
 
-Каждому дай путь к файлу ревью, `$TARGET`, `$PLAN_FILE`, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, связанный research при наличии. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
-
-Формат ответа агентов:
-- `+` какую проблему добавить в ревью;
-- `−` что убрать как неверное или недоказанное;
-- `~` что переформулировать;
-- `?` что невозможно проверить и почему.
-
-Для `plan-check` добавь явную инструкцию: «Если `$PLAN_FILE` не передан или файл не найден, верни только `? план не проверен: нужен путь к файлу`; не пытайся угадывать план.»
-
-Когда все агенты ответили: прочитай ответы, **сам реши**, что применять. Добавляй только подтверждённые проблемы; предложения вида «добавить, что пункт выполнен» отклоняй как неформат ревью. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
-
-```markdown
-### После plan-check / architecture-check / rules-check / quality-check
-- **+ Добавлено:** <короткий список>
-- **~ Изменено:** <короткий список>
-- **− Убрано:** <короткий список>
-- **Отклонено:** <короткий список с причиной>
-```
-
-Поменяй `status: draft` → `meta-reviewed`, в `meta_reviewers` добавь `plan-check`, `architecture-check`, `rules-check`, а если запускался — `quality-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)
-- **+ Добавлено:** ...
-- **− Убрано:** ...
-- **Отклонено:** ...
-```
+### 3. Проверить ревью через `eda-review-check`
+В normal/strict запусти `eda-review-check` для `$REVIEW_FILE` и передай выбранный режим (`normal` или `strict`). Именно `eda-review-check` запускает `architecture-check`, `rules-check`, а если `plan` в front matter указывает на файл — ещё и `plan-check`; при включённой настройке `quality-check` тоже запускается. Затем `eda-review-check` обновляет `status`, `meta_reviewers`, `score` и раздел `## Изменения после мета-ревью`.
 
-Добавь в `meta_reviewers` имя CLI. `status: meta-reviewed` → `final`.
+Требования к средам остаются частью контракта ревью: Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), используй его; не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны. Codex exec / неинтерактивный fallback допустим только как fallback и описан в `eda-review-check`. Кросс-CLI выполняет только `eda-review-check strict`.
 
-### 5. Финал
-Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение». Не пересказывай выполненную работу. Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review strict`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
+### 4. Финал
+Короткое сообщение: режим (`draft`, `normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение». Не пересказывай выполненную работу. Если режим был `draft` — добавь строку «мета-ревью не запускалось; для проверки — `eda-review-check <review>`». Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review-check strict <review>`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
 
 ## Чего НЕ делать
 - Править код. Это `eda-fix-by-review`.
-- Пропускать мета-ревью специализированными агентами (это часть обычного режима, не под флагом).
+- Пропускать `eda-review-check` в normal/strict. Исключение — явный режим `draft`.
 - Запускать мета-ревьюеров частями: сначала 1–2 агента, потом остальных. Все обязательные проверки стартуют сразу.
 - Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
 - Вставлять чужие предложения механически — каждое решение принимай ты.