@gian-tiaga/eda 0.7.0 → 0.8.1

package/README.md

@@ -3,7 +3,7 @@
 > Поточная разработка с AI-агентами — на русском языке.
 > Набор готовых скилов для **Claude Code** и **Codex CLI**, которые ведут тебя через весь цикл: от исследования до коммита.
 
-`eda` — это пятнадцать скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
+`eda` — это восемнадцать скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
 
 ---
 
@@ -35,14 +35,17 @@ eda update-all ~/Code
 
 | Скил | Что делает | Куда складывает |
 |---|---|---|
+| `eda-start` | Помогает стартовать новый проект: собирает требования, вместе с пользователем выбирает стек, архитектуру, инструменты качества кода, AI-скилы, агентные инструкции, MCP-серверы и правила проекта. Для выбранных пакетов всегда ищет последние стабильные версии по официальным источникам. Не пишет код и не ставит зависимости; сохраняет согласованные стартовые решения и по подтверждению создаёт черновики правил/архитектуры/AGENTS | `docs/project-starts/`, опционально `docs/rules.md`, `docs/arch.md`, `AGENTS.md` |
 | `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 или заданного порога. Сначала основной агент оценивает план; если оценка ниже порога, запускает три изолированных параллельных plan-polish агента, анализирует их предложения, правит только файл плана и повторяет цикл до качества или лимита | `docs/plans/` |
 | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Перед правками читает план, `docs/rules.md` и `docs/arch.md`; правила и архитектура обязательны к исполнению. Если шаг плана им противоречит, останавливается и спрашивает. Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
-| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ, но в файл пишет только проблемы: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Не перечисляет выполненную работу. В обычном режиме после черновика передаёт файл в `eda-review-check`; с флагом `draft` сохраняет только первичное ревью без субагентов | `docs/reviews/` |
-| `eda-review-check` | Проверяет готовое ревью из `docs/reviews/` специализированными субагентами: выполнение плана, архитектуру, правила и при включённой настройке качество кода. В строгом режиме добавляет кросс-ревью между Claude и Codex. Сам применяет подтверждённые замечания к файлу ревью, но не правит код | `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` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `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 итераций. Каждый шаг идёт в изолированном субагенте или отдельном CLI-процессе. Не коммитит | `docs/reviews/`, `docs/review-fixes/` |
 | `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
 | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
@@ -122,21 +125,36 @@ review:
 
 ## 🔄 Воркфлоу
 
+```text
+start ─────────────> docs ───────────────┬───────────────┐
+                    │                     │               │
+                    v                     v               v
+                 roadmap ────────> explore ─────> plan ───> plan-polish ───> execute ───┬──> manual-test ───> review ───> review-check ───> fix-by-review ───┬──> send-review
+                                              │                         │                                  │
+                                              └────────────> plan       v                                  └──> commit
+                                                                     fix ─────────────> manual-test
+```
+
+Если проект уже существует, можно начинать без `eda-start`:
+
 ```text
 docs ───────────────┬───────────────┐
                     │               │
                     v               v
-roadmap ────────> explore ─────> plan ───> execute ───┬──> review ───> review-check ───> fix-by-review ───┬──> send-review
+roadmap ────────> explore ─────> plan ───> plan-polish ───> execute ───┬──> manual-test ───> review ───> review-check ───> fix-by-review ───┬──> send-review
                     │                                  │                                  │
                     └──────────────> plan              v                                  └──> commit
-                                                      fix ─────────────> review
+                                                      fix ─────────────> manual-test
 
 polish = review draft ─> review-check ─> fix-by-review apply-optional ─> повтор до нужной оценки
+plan-polish = оценка плана ─> 3 plan-polish агента ─> правка плана ─> повтор до 95/100
 
 automate может запускаться от review, fix-by-review или fix.
 ```
 
-Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-roadmap`, `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
+`eda-manual-test` обычно ставится после `eda-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API/UI перед ревью или коммитом.
+
+Использовать всю цепочку не обязательно — каждый скил самодостаточен. Новый проект можно начать с `eda-start`; существующий — с `eda-roadmap`, `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
 
 ---
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.7.0",
-  "description": "Набор скилов eda-* для Claude Code и Codex CLI: roadmap, explore, plan, execute, fix, review, review-check, fix-by-review, polish, send-review, commit, worktree, merge-worktree, docs, automate",
+  "version": "0.8.1",
+  "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": {
     "eda": "bin/cli.js"

package/skills/eda-manual-test.md

@@ -0,0 +1,135 @@
+---
+name: eda-manual-test
+description: 'Делает ручную smoke/acceptance-проверку после изменений: сам строит чеклист из входа пользователя, плана или незакоммиченного diff; для API выполняет curl/HTTP-запросы, для фронта использует Playwright или доступную browser automation. Сам запускает очевидные dev/API-серверы, фиксирует фактическое поведение и сохраняет QA-отчёт в docs/manual-tests/. Не правит код, не пишет автотесты, не ставит зависимости, не коммитит.'
+---
+
+# Скил: Ручное тестирование (eda-manual-test)
+
+Делаешь ручную smoke/acceptance-проверку уже сделанных изменений. Проверяешь не «что тесты зелёные», а что пользовательский или API-сценарий реально работает: страница открывается, действие проходит, endpoint отвечает, ошибки выглядят ожидаемо. Сохраняешь QA-отчёт. Код не правишь.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: URL, endpoint, сценарий, план, ревью, issue, ветку, ограничение по окружению, логин/роль без секретов и прямые указания.
+
+Если входа достаточно, продолжай без вопроса. Если входа нет, построй минимальный smoke-чеклист по незакоммиченному `git diff HEAD`, релевантному коду и документации проекта. `AskUserQuestion` задавай только если цель противоречива, найдено несколько равных окружений/URL, нужна авторизация без доступных тестовых данных или есть риск выполнить разрушительное действие. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Ручная проверка, не разработка.** Не правь код, не пиши и не обновляй автотесты, не меняй конфиги, не коммить и не пушь.
+2. **Smoke по умолчанию.** Проверь запуск, основной happy path изменённой области и 1–2 негативных или edge-сценария, которые естественно следуют из задачи.
+3. **API проверяй запросами.** Используй `curl`, встроенный HTTP-клиент, Node `fetch` или проектные scripts. Фиксируй method, URL, важные headers без секретов, body, status code и ключевые поля ответа.
+4. **Фронт проверяй браузером.** Если в проекте есть Playwright — используй Playwright. Если Playwright не установлен, используй доступную browser automation хост-агента. Если браузерной автоматизации нет — спроси через `AskUserQuestion`; не устанавливай зависимости молча.
+5. **Серверы поднимай сам, если это очевидно.** Определи команды по `package.json`, README, docker compose, Makefile или локальным инструкциям. Останавливай только процессы, которые сам запустил.
+6. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
+7. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, миграции, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
+8. **Проверяй фактическое поведение.** Не ограничивайся чтением кода. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
+9. **Отчёт обязателен.** Сохрани результат в `docs/manual-tests/`, даже если проверка заблокирована или нашла баги.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
+
+## Этапы
+
+### 1. Определить цель проверки
+Разбери вход пользователя. Если указан файл плана, ревью, research, issue или другой артефакт — прочитай его. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
+
+Определи `$TEST_TARGET`: `api`, `frontend`, `fullstack` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
+
+### 2. Прочитать рамку проекта
+Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
+
+Не устанавливай Playwright, браузеры, пакеты, docker images или системные зависимости молча. Если без этого проверка невозможна — спроси через `AskUserQuestion` или зафиксируй `blocked` в неинтерактивном режиме.
+
+### 3. Составить smoke-чеклист
+Составь короткий чеклист:
+- запуск приложения или API;
+- основной happy path изменённой области;
+- 1–2 негативных или edge-сценария;
+- явные acceptance criteria из плана или входа пользователя;
+- для фронта: console errors, network errors и видимые regressions на основной странице;
+- для API: status code, схема/ключевые поля ответа, обработка неверного ввода или прав доступа, если это относится к задаче.
+
+Не расширяй проверку до полного exploratory QA, если пользователь не попросил.
+
+### 4. Запустить окружение
+Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
+
+Фиксируй команды запуска в черновике отчёта. Не заверши свой ответ, пока запущенные тобой процессы, нужные только для проверки, ещё работают.
+
+### 5. Проверить API
+Для API-сценариев выполни реальные запросы. Предпочитай воспроизводимые команды `curl`, но можно использовать Node `fetch` или проектный HTTP-клиент, если так безопаснее.
+
+Проверяй:
+- успешный status code и ключевые поля ответа;
+- корректную ошибку для неверного ввода, отсутствующих прав или несуществующей сущности, если это относится к задаче;
+- отсутствие явных server errors, stack traces и утечек секретов в ответе.
+
+Секретные headers и cookies в отчёт не вставляй: пиши `<redacted>`.
+
+### 6. Проверить фронт
+Для фронтовых сценариев открой страницу в браузере. Если доступен Playwright, используй его для навигации, кликов, ввода и проверок. Если доступен browser plugin или другой инструмент браузерной автоматизации — используй его. Проверяй фактический UI, а не только DOM-текст.
+
+Проверяй:
+- страница загружается без критических console/network errors;
+- основной сценарий пользователя проходит до ожидаемого результата;
+- видимые состояния ошибок, пустых данных или невалидного ввода, если они относятся к задаче;
+- текст и элементы управления не ломаются на очевидном desktop/mobile viewport, если менялась вёрстка.
+
+Скриншоты сохраняй только если инструмент это поддерживает и они помогают подтвердить результат или баг. Складывай их рядом с отчётом или в подпапку `docs/manual-tests/assets/`.
+
+### 7. Сохранить отчёт
+Сохрани отчёт в `docs/manual-tests/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+
+```markdown
+---
+date: <YYYY-MM-DD HH:MM>
+source: <text | git diff HEAD | docs/plans/... | docs/reviews/...>
+target: <api | frontend | fullstack | other>
+status: <passed | failed | blocked>
+---
+
+# Ручная проверка: <краткий заголовок>
+
+## Контекст
+<что проверялось и откуда взяты сценарии>
+
+## Окружение
+| Что | Значение |
+|---|---|
+| Команды запуска | `<command>` |
+| URL / endpoint | `<url или endpoint>` |
+| Авторизация | `<не нужна | тестовый пользователь | уже настроена | blocked>` |
+
+## Чеклист
+| # | Сценарий | Способ проверки | Результат | Заметки |
+|---|----------|-----------------|-----------|---------|
+| 1 | ... | `curl ...` / Playwright / browser | ✓ / ✗ / ? | ... |
+
+## Найденные проблемы
+<если нет — «Явных проблем не найдено»; если есть — список с воспроизведением и фактическим/ожидаемым результатом>
+
+## Артефакты
+<ссылки на скриншоты, логи или «Нет»>
+
+## Итог
+<passed / failed / blocked и короткое объяснение>
+```
+
+Если найден баг, статус отчёта `failed`. Если проверка невозможна из-за окружения, авторизации, отсутствующих зависимостей или непонятного риска, статус `blocked`.
+
+### 8. Финал
+Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, какие сценарии реально проверены, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
+
+## Чего НЕ делать
+- Править код, конфиги, миграции, seed-данные или документацию проекта, кроме отчёта в `docs/manual-tests/`.
+- Писать или обновлять unit/e2e/autotests. Это работа `eda-fix`, `eda-execute` или отдельной задачи.
+- Устанавливать Playwright, браузеры, npm-пакеты, docker images или системные зависимости без явного подтверждения.
+- Подменять ручную проверку запуском `npm test` без фактического прохождения API/UI-сценария.
+- Проверять production или staging с изменением данных без подтверждения пользователя.
+- Сохранять секреты, cookies, токены или passwords в отчёт.
+- Коммитить, пушить, создавать PR или отправлять ревью.

package/skills/eda-plan-polish.md

@@ -0,0 +1,209 @@
+---
+name: eda-plan-polish
+description: 'Итерационно полирует готовый план из `docs/plans/...` до оценки 95/100 или заданного порога. Сначала основной агент оценивает план по шкале 0–100. Если оценка ниже порога, запускает три изолированных параллельных plan-polish агента, получает конкретные предложения правок, сам принимает или отклоняет замечания, правит только файл плана и пересчитывает оценку. Не создаёт план с нуля, не меняет код, конфиги и зависимости.'
+---
+
+# Скил: Полировка плана (eda-plan-polish)
+
+Берёшь готовый план из `docs/plans/`, оцениваешь его по шкале 0–100 и доводишь до качества, достаточного для `eda-execute`. Порог по умолчанию — `95`: если план уже набирает 95 или выше, фиксируешь оценку и ничего не меняешь. Если ниже — запускаешь цикл полировки через три изолированных агента, применяешь принятые замечания, снова оцениваешь план и повторяешь до порога или лимита.
+
+Основной агент остаётся редактором: он не вставляет предложения механически, а решает, какие принять, какие отклонить и какие требуют вопроса пользователю.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: путь к плану, название или часть названия, «последний план», желаемый порог, лимит итераций, ограничения, прямые указания и запреты на типы правок.
+
+Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск полировать не тот план. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Режим запуска
+
+Порог качества по умолчанию — `95`. Пользователь может переопределить его в текущем сообщении: `до 90`, `threshold 90`, `цель 90`. Допустимые значения — от `1` до `100`.
+
+Лимит по умолчанию — `5` итераций полировки. Пользователь может явно задать меньший или больший лимит словами `лимит 3`, `max iterations 3`, `не больше 3 кругов`.
+
+Оценка плана:
+- `95–100` — план готов к исполнению, агенты полировки не нужны;
+- `80–94` — план в целом рабочий, но требует уточнений перед `eda-execute`;
+- `60–79` — план рискован: есть пропуски, общие шаги или слабые критерии готовности;
+- `<60` — план нельзя исполнять без серьёзной переработки или вопросов пользователю.
+
+## Главные правила
+
+1. **Не создаёшь план с нуля.** Входом всегда является уже сохранённый файл `docs/plans/...`.
+2. **Не правишь код, миграции, конфиги и зависимости.** Можно менять только выбранный файл плана.
+3. **Сначала оцениваешь план сам.** До запуска агентов поставь текущую оценку 0–100 и коротко зафиксируй причины.
+4. **Агенты запускаются только если оценка ниже порога.** Если план набрал `threshold` или выше, не запускай изолированные проверки ради формы.
+5. **Три изолированных plan-polish агента обязательны в каждой итерации ниже порога.** Запусти `completeness-polisher`, `rules-arch-polisher` и `execution-readiness-polisher` параллельно, до чтения любого результата.
+6. **Главный редактор плана — ты.** Субагенты предлагают конкретные правки; решение применить, отклонить или спросить пользователя принимаешь сам.
+7. **Не добавляй неподтверждённые существенные решения.** Новые БД/API-контракты, зависимости, архитектурные развилки, auth/permissions/payments/secrets/персональные данные и миграции можно добавить только если они уже подтверждены в плане, research, `docs/rules.md`, `docs/arch.md` или ответом пользователя.
+8. **План должен остаться планом.** Не превращай его в отчёт ревью: принятые замечания встраивай в целевые разделы, а журнал решений держи коротким в конце.
+9. **Структуру `eda-plan` сохраняй.** Не удаляй обязательные разделы `Целевой алгоритм`, `Контракты реализации`, `Фазы выполнения`, `Тесты`, `Логирование`, если они есть или должны быть по формату `eda-plan`.
+10. **Останавливайся на блокерах.** Если качество не растёт два круга подряд, агенты предлагают только неподтверждённые развилки, нужен ответ пользователя или достигнут лимит — остановись и честно назови причину.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
+
+## Этапы
+
+### 1. Выбрать план и прочитать контекст
+
+Определи `$PLAN_FILE`:
+- если пользователь указал путь к плану — используй его;
+- если указал название или часть названия — найди совпадение в `docs/plans/`;
+- если написал «последний план» — возьми самый новый файл из `docs/plans/`;
+- если входа нет — `AskUserQuestion` со списком последних файлов из `docs/plans/`;
+- если `docs/plans/` отсутствует или пуста — остановись со статусом `blocked: нужен готовый план`.
+
+Прочитай `$PLAN_FILE` целиком. Из front matter извлеки `status`, `mode`, `plan_size`, `test_strategy`, `logging_strategy`, `sources.rules`, `sources.arch`, `sources.research`, `meta_reviewers`.
+
+Прочитай `docs/rules.md`, `docs/arch.md`, если они есть. Если в `sources.research` указан файл исследования — прочитай его. Если план ссылается на конкретные файлы, модули, API, миграции или тесты, открой достаточно релевантного кода, чтобы понять реализуемость плана.
+
+### 2. Первичная оценка плана
+
+Поставь `$SCORE` по шкале 0–100. Оцени:
+- следование `docs/rules.md` и `docs/arch.md`;
+- отсутствие неподтверждённых существенных решений;
+- конкретность `Целевого алгоритма`;
+- полноту `Контрактов реализации`, особенно БД/API/внешних контрактов;
+- исполнимость фаз: цель, шаги, результат, сценарии тестирования, проверка;
+- применение `test_strategy` и `logging_strategy`;
+- отсутствие альтернатив вида «выбрать», «решить», «уточнить позже»;
+- возможность передать план в `eda-execute` без нового исследования.
+
+Если `$SCORE >= threshold`, добавь или обнови в конце плана короткий раздел:
+
+```markdown
+## Оценка plan-polish
+- **Итоговая оценка:** <score>/100
+- **Порог:** <threshold>/100
+- **Итерации:** 0
+- **Решение:** план уже готов к исполнению, изолированные агенты не запускались.
+```
+
+После этого переходи к финалу.
+
+### 3. Итерационный цикл полировки
+
+Если `$SCORE < threshold`, повторяй до достижения порога или лимита.
+
+#### 3.1. Запустить три изолированных агента
+
+Запусти **в одном сообщении и одним batch** три роли. Не запускай сначала одного агента, не читай его ответ и не стартуй остальных после этого.
+
+Роли:
+- `completeness-polisher` — предлагает конкретные правки для пропущенных шагов, состояний UI/API, миграций/backfill/rollback, edge cases, документации и эксплуатационных шагов.
+- `rules-arch-polisher` — предлагает конкретные правки для соответствия `docs/rules.md`, `docs/arch.md`, границам модулей, локальным запретам, архитектурным решениям, API/БД-контрактам и требованиям к проверкам.
+- `execution-readiness-polisher` — предлагает конкретные правки, чтобы `eda-execute` мог выполнить план без нового исследования: фазы, критерии готовности, порядок работ, тестовые сценарии, команды проверки, логирование и удаление альтернатив вида «выбрать» или «решить».
+
+Модели:
+- Claude Code: запускай все роли через `Agent` tool, предпочтительно на `model: "sonnet"`.
+- Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), запускай все роли через него, предпочтительно на `gpt-5.3-codex`.
+- Codex exec / неинтерактивный fallback: если инструмента субагентов нет, запускай три `codex exec --model gpt-5.3-codex` параллельно одной Bash-командой с `&` и общим `wait`.
+- Если указанный идентификатор модели недоступен, возьми ближайшую code-capable модель того же уровня. Не используй одну и ту же беседу вместо изолированных агентов.
+
+Каждому агенту дай путь к `$PLAN_FILE`, текущий `$SCORE`, `$threshold`, номер итерации, `docs/rules.md`, `docs/arch.md`, `sources.research` при наличии и список релевантных файлов, найденных при чтении плана. Проси открывать код только в рамках своей роли и не править файлы.
+
+Формат ответа агентов:
+
+```text
+score: <оценка плана 0–100 по мнению агента>
++ Применить: <конкретная правка и куда встроить>
+~ Уточнить: <что переформулировать>
+-- Убрать: <что неверно, лишнее или противоречит контексту>
+? Вопрос: <что нельзя безопасно решить без пользователя>
+```
+
+#### 3.2. Проанализировать замечания
+
+Когда все три агента ответили, сгруппируй замечания:
+- **Принять** — подтверждено планом, правилами, архитектурой, research или кодом; улучшает исполнимость без новой развилки.
+- **Отклонить** — противоречит контексту, дублирует уже закрытый пункт, расширяет задачу, требует неподтверждённого существенного решения или выходит за рамки плана.
+- **Спросить** — замечание выглядит существенным и полезным, но требует выбора пользователя или меняет ранее подтверждённое решение.
+
+Если есть вопросы класса **Спросить**, задай один сгруппированный `AskUserQuestion` и не редактируй план до ответа. Если вопрос нужен только из-за предложения субагента, которое можно безопасно отклонить как расширение задачи, отклони его и продолжай.
+
+#### 3.3. Отредактировать план
+
+Внеси принятые замечания в основные разделы плана:
+- конкретизируй `Целевой алгоритм`, если не хватает сквозного поведения;
+- уточни `Контракты реализации`, если БД/API/внешние контракты затронуты, но описаны неполно;
+- дополни фазы шагами, результатами, сценариями тестирования и проверками;
+- приведи `Тесты` и `Логирование` в соответствие с `test_strategy` и `logging_strategy`;
+- убери неподтверждённые альтернативы, общие формулировки и противоречия правилам/архитектуре.
+
+Не меняй смысл подтверждённых решений без вопроса. Если план был `short`, не раздувай его больше 2 фаз: лучше заменить общие шаги конкретными, а лишнее отклонить как выход за short-рамку.
+
+В конец плана добавь или обнови раздел:
+
+```markdown
+## Изменения после plan-polish
+
+### Итерация <N>: completeness-polisher / rules-arch-polisher / execution-readiness-polisher
+- **Оценка до:** <score_before>/100
+- **+ Добавлено:** <3–7 главных изменений>
+- **~ Уточнено:** <1–5 важных уточнений>
+- **− Убрано:** <если удалено>
+- **Отклонено:** <существенные отклонённые предложения и причина>
+- **Вопросы пользователя:** <если были, кратко решение>
+```
+
+В front matter добавь фактически запущенные роли в `meta_reviewers`, если поле есть. Если поля нет — не перестраивай весь YAML ради этого, достаточно раздела `Изменения после plan-polish`. Если `status: draft` и после правок не осталось открытых вопросов, поменяй на `status: meta-reviewed`. Если статус уже `meta-reviewed` или `reviewed`, оставь его.
+
+#### 3.4. Пересчитать оценку
+
+Перечитай изменённый план и поставь новую оценку `$SCORE`.
+
+Добавь или обнови в разделе `## Оценка plan-polish`:
+
+```markdown
+## Оценка plan-polish
+- **Итоговая оценка:** <score>/100
+- **Порог:** <threshold>/100
+- **Итерации:** <N>
+- **Решение:** <готов к исполнению | нужен следующий круг | blocked | достигнут лимит>
+```
+
+Если `$SCORE >= threshold`, останови цикл: план готов. Если оценка не выросла два круга подряд, остановись `blocked: score не растёт`. Если лимит достигнут, остановись и прямо сообщи, что порог не достигнут.
+
+### 4. Финальная самопроверка
+
+Перед финалом перечитай изменённый план и проверь:
+- план строго следует `docs/rules.md` и `docs/arch.md`;
+- нет неподтверждённых существенных решений и альтернатив вида «выбрать» / «решить»;
+- БД/API изменения описаны конкретно или явно помечены как `Не затрагивается`;
+- каждая фаза имеет цель, шаги, результат, сценарии тестирования и проверку;
+- `test_strategy` и `logging_strategy` применены в фазах и отдельных разделах;
+- план можно передать в `eda-execute` без нового исследования;
+- журнал `Изменения после plan-polish` не заменяет содержание плана, а только объясняет редакторские решения.
+
+Если после самопроверки остаётся блокер, не маскируй его правками: остановись со статусом `blocked` и назови, какой ответ или файл нужен.
+
+### 5. Финал
+
+Короткое сообщение:
+- путь к отполированному плану;
+- итоговая оценка и порог;
+- сколько итераций выполнено;
+- какие три агента запускались, если запускались;
+- 3–5 главных принятых изменений;
+- существенные отклонённые замечания, если были;
+- причина остановки: `готов`, `достигнут лимит`, `score не растёт`, `blocked`;
+- следующий шаг при успехе: `eda-execute <PLAN_FILE>`.
+
+## Чего НЕ делать
+
+- Создавать новый план вместо полировки существующего.
+- Править код, миграции, конфиги, lock-файлы или зависимости.
+- Запускать агентов, если первичная оценка уже достигла порога.
+- Запускать агентов последовательно и менять промпты следующих агентов после первых ответов.
+- Вставлять все предложения субагентов без анализа.
+- Добавлять новые существенные решения без подтверждения пользователя.
+- Удалять обязательные разделы плана ради краткости.
+- Превращать план в длинный отчёт о ревью.
+- Скрывать, что порог не достигнут.
+- Коммитить, пушить или запускать `eda-execute`.

package/skills/eda-review-check.md

@@ -1,6 +1,6 @@
 ---
 name: eda-review-check
-description: 'Проверяет готовое ревью из `docs/reviews/...` специализированными субагентами и, в strict-режиме, соседним CLI. Не делает первичное ревью и не правит код. Читает ревью, target/plan из front matter, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml` и связанный research при наличии. Запускает plan-check, architecture-check, rules-check и опциональный quality-check, затем сам применяет подтверждённые замечания к файлу ревью: добавляет, убирает или переформулирует пункты, обновляет score/status/meta_reviewers и раздел изменений после мета-ревью.'
+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)
@@ -30,7 +30,7 @@ description: 'Проверяет готовое ревью из `docs/reviews/..
 
 1. **Не делаешь первичное ревью.** Входом всегда является готовый файл `docs/reviews/...`.
 2. **Не правишь код.** Можно менять только выбранный файл ревью и вспомогательный файл `${REVIEW_FILE%.md}_cli_meta.md` в strict-режиме.
-3. **Мета-ревью специализированными агентами обязательно.** Базовые роли: `plan-check`, `architecture-check`, `rules-check`. Если включена проверка качества кода — добавь `quality-check` в тот же batch.
+3. **Мета-ревью специализированными агентами обязательно.** Базовые роли: `architecture-check`, `rules-check`. `plan-check` запускай только если в front matter ревью `plan` указывает на конкретный файл. Если включена проверка качества кода — добавь `quality-check` в тот же batch.
 4. **Главный редактор ревью — ты.** Субагенты дают предложения; решение добавить, убрать или переформулировать пункт принимаешь сам.
 5. **Ревью остаётся ревью только по проблемам.** Не добавляй выполненные пункты, похвалу, нейтральный отчёт о diff или общие рассуждения.
 6. **Каждое принятое изменение фиксируй в `## Изменения после мета-ревью`.** Отклонённые предложения тоже запиши коротко с причиной.
@@ -55,16 +55,16 @@ description: 'Проверяет готовое ревью из `docs/reviews/..
 - если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`;
 - если `docs/reviews/` отсутствует или пуста — остановись со статусом `blocked: нужно ревью`.
 
-Прочитай `$REVIEW_FILE` целиком. Из front matter и текста извлеки `$TARGET`, `$PLAN_FILE`, текущие `mode`, `score`, `status`, `meta_reviewers`. Если target указывает на diff-команду, получи актуальный diff. Если target указывает на файл, папку или PR — прочитай достаточно кода, чтобы проверить замечания. Прочитай `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, если они есть. Если ревью ссылается на `docs/researches/...`, прочитай связанный research.
+Прочитай `$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` отсутствует, не угадывай план. `plan-check` всё равно запускается, но получает явную инструкцию вернуть только `? план не проверен: нужен путь к файлу`.
+Если `$PLAN_FILE=none` или отсутствует, не угадывай план и не запускай `plan-check`. В разделе изменений после мета-ревью коротко зафиксируй: «plan-check не запускался: план не указан в ревью».
 
 ### 2. Запустить специализированных субагентов
 
-Запусти **в одном сообщении и одним batch** агентов с разными ролями. В интерактивном Codex это означает субагентов, а не отдельные процессы `codex exec`. Не запускай сначала часть агентов, не жди их ответы и не запускай остальных позже: все проверки должны стартовать до чтения любого результата.
+Запусти **в одном сообщении и одним batch** агентов с выбранными ролями. В интерактивном Codex это означает субагентов, а не отдельные процессы `codex exec`. Не запускай сначала часть агентов, не жди их ответы и не запускай остальных позже: все выбранные проверки должны стартовать до чтения любого результата.
 
 Роли агентов:
-- `plan-check`: проверяет, что реализация действительно выполнила `$PLAN_FILE`, включая частичные пункты, пропущенные требования, лишние отклонения и недостающие проверки.
+- `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`; по умолчанию рекомендация `на усмотрение автора`, кроме случаев, где сложность, дублирование или неясная структура реально создают риск багов, тестовых пробелов или дорогого сопровождения.
@@ -73,9 +73,9 @@ description: 'Проверяет готовое ревью из `docs/reviews/..
 - 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, план, правила, архитектуру и релевантный код.
+- Если нужный идентификатор недоступен, возьми ближайшую code-capable модель того же уровня. Не используй быструю слабую модель для этих проверок: они должны читать diff, план при наличии, правила, архитектуру и релевантный код.
 
-Каждому агенту дай путь к `$REVIEW_FILE`, `$TARGET`, `$PLAN_FILE`, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, связанный research при наличии. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
+Каждому агенту дай путь к `$REVIEW_FILE`, `$TARGET`, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, связанный research при наличии. `plan-check` дополнительно получает `$PLAN_FILE`, если он есть. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
 
 Формат ответа агентов:
 - `+` какую проблему добавить в ревью;
@@ -83,7 +83,7 @@ description: 'Проверяет готовое ревью из `docs/reviews/..
 - `~` что переформулировать;
 - `?` что невозможно проверить и почему.
 
-Для `plan-check` добавь явную инструкцию: «Если `$PLAN_FILE` не передан или файл не найден, верни только `? план не проверен: нужен путь к файлу`; не пытайся угадывать план.»
+Если `$PLAN_FILE` не передан, равен `none` или файл не найден, `plan-check` не запускай.
 
 ### 3. Применить результаты обычного мета-ревью
 
@@ -99,7 +99,7 @@ description: 'Проверяет готовое ревью из `docs/reviews/..
 - **Отклонено:** <короткий список с причиной>
 ```
 
-Поменяй `status: draft` → `meta-reviewed`, если статус был draft. В `meta_reviewers` добавь `plan-check`, `architecture-check`, `rules-check`, а если запускался — `quality-check`, и фактические модели, например `gpt-5.3-codex` или `sonnet`. Если оценка после корректировок изменилась — обнови `score`.
+Поменяй `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`
 
@@ -117,6 +117,8 @@ codex exec "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, d
 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`: завершить как есть или прервать.
 
 Прочитай ответ, **сам реши**, что применять. Допиши в `## Изменения после мета-ревью`:
@@ -139,7 +141,7 @@ claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, do
 - Делать первичное ревью. Это `eda-review`.
 - Править код. Это `eda-fix-by-review`.
 - Пропускать мета-ревью специализированными агентами.
-- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом остальных. Все обязательные проверки стартуют сразу.
+- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом остальных. Все выбранные обязательные проверки стартуют сразу.
 - Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
 - Вставлять чужие предложения механически — каждое решение принимай ты.
 - Задавать вопросы без блокировки и продолжать работу до ответа.

package/skills/eda-review.md

@@ -1,11 +1,11 @@
 ---
 name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `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 с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Каждый пункт начинаешь с короткого человеческого объяснения риска, без технической перегрузки; файлы, строки, детали кода и способ исправления даёшь ниже в блоке «Технические детали». Не перечисляешь, что выполнено хорошо или без замечаний. Затем в обычном режиме запускаешь `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. **План работ обязателен для ревью выполненных изменений.** Если путь к плану не указан в запросе и его нельзя однозначно определить из diff/ссылок, спроси путь к файлу плана и остановись до ответа. Не подставляй «последний план» наугад.
+4. **План работ обязателен для явно заданного ревью выполненных изменений.** Если пользователь указал файл, папку, PR, ветку, тип diff или другую цель ревью, а путь к плану не указан и его нельзя однозначно определить из diff/ссылок, спроси путь к файлу плана и остановись до ответа. Исключение: запуск без аргументов — ревью незакоммиченного `git diff HEAD` без проверки плана. Не подставляй «последний план» наугад.
 5. **Мета-ревью специализированными агентами — обязательно в normal/strict**, но выполняется отдельным скиллом `eda-review-check`. В `draft` мета-ревью не запускается.
 6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
 7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
@@ -48,7 +48,7 @@ description: 'Ревью изменений (незакоммиченный diff
 
 ## Интерактивные вопросы
 
-Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос о цели ревью**. Это не отменяет обязательный вопрос о `$PLAN_FILE`, если план не указан и не найден однозначно. Примеры понятного контекста:
+Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос о цели ревью**. Это не отменяет обязательный вопрос о `$PLAN_FILE` для явно заданной цели, если план не указан и не найден однозначно. Для запуска без аргументов вопрос о плане не задавай: проверка плана пропускается. Примеры понятного контекста:
 - пользователь указал файл, папку, PR, ветку или тип diff;
 - в запросе есть «ревью незакоммиченных изменений», «ревью текущей ветки», «проверь PR #N»;
 - в рабочем дереве есть незакоммиченные изменения и пользователь просит «сделай ревью» без других целей.
@@ -70,16 +70,17 @@ 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` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
 
 Каждое замечание должно быть самостоятельным блоком:
 - заголовок с номером и коротким смыслом;
@@ -95,6 +96,7 @@ description: 'Ревью изменений (незакоммиченный diff
 title: <заголовок>
 date: <YYYY-MM-DD HH:MM>
 target: <git diff HEAD | main...HEAD | path | PR#>
+plan: <docs/plans/... | none>
 mode: <draft | normal | strict>
 score: <0..100>
 status: draft
@@ -109,7 +111,7 @@ meta_reviewers: []
 
 ## Проблемы сверки с планом
 
-<Если проблем по плану нет: «Явных проблем по плану не найдено.»>
+<Если `$PLAN_FILE=none`: «Проверка плана пропущена: запуск без аргументов использует незакоммиченный `git diff HEAD` без сверки с планом.» Если проблем по плану нет: «Явных проблем по плану не найдено.»>
 
 ### 1. <недоделка, отклонение или непроверенный пункт>
 
@@ -154,7 +156,7 @@ meta_reviewers: []
 Если режим `draft` — не запускай субагентов и не вызывай `eda-review-check`; сразу переходи к финалу draft.
 
 ### 3. Проверить ревью через `eda-review-check`
-В normal/strict запусти `eda-review-check` для `$REVIEW_FILE` и передай выбранный режим (`normal` или `strict`). Именно `eda-review-check` запускает `plan-check`, `architecture-check`, `rules-check` и при включённой настройке `quality-check`, обновляет `status`, `meta_reviewers`, `score` и раздел `## Изменения после мета-ревью`.
+В 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` и раздел `## Изменения после мета-ревью`.
 
 Требования к средам остаются частью контракта ревью: Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), используй его; не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны. Codex exec / неинтерактивный fallback допустим только как fallback и описан в `eda-review-check`. Кросс-CLI выполняет только `eda-review-check strict`.
 

package/skills/eda-start.md

@@ -0,0 +1,233 @@
+---
+name: eda-start
+description: 'Помогает стартовать новый проект: собирает требования, критерии MVP, ограничения и риски; вместе с пользователем выбирает стек, архитектуру, инструменты качества кода, AI-скилы, агентные инструкции, MCP-серверы и правила проекта. Для пакетов всегда ищет последние стабильные версии по официальным источникам; для библиотек, CLI, сервисов и MCP проверяет актуальные стабильные версии, если они не заданы. Не пишет код и не устанавливает зависимости: сохраняет согласованный стартовый документ в docs/project-starts/ и черновики docs/rules.md / docs/arch.md / AGENTS.md, если пользователь это подтвердил.'
+---
+
+# Скил: Старт проекта (eda-start)
+
+Помогаешь начать новый проект с понятной рамкой: что делаем, для кого, на каком стеке, с какой архитектурой, какими проверками качества, какими AI-скилами и MCP-серверами, и какие правила сразу внедряем. Работаешь как технический партнёр: сначала собираешь факты, затем рекомендуешь варианты и принимаешь решения вместе с пользователем.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: идею проекта, продуктовую цель, аудиторию, ограничения, сроки, предпочтения по стеку, инфраструктуре, бюджету, команде, требованиям к качеству, безопасности и эксплуатации.
+
+Если входа достаточно для первого анализа, не спрашивай подтверждение самой темы, но всё равно задай вопросы по значимым стартовым решениям. `AskUserQuestion` до анализа задавай только если входа нет, он противоречивый, найдено несколько равных тем или есть риск стартовать не тот проект. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Интерактивное совместное решение обязательно.** Нельзя молча выбрать стек, архитектуру, правила, MCP или инструменты качества, если это значимо влияет на проект.
+2. **Не пишешь код и не ставишь пакеты.** Запись только в `docs/project-starts/` и, после явного подтверждения пользователя, в `docs/rules.md`, `docs/arch.md`, `AGENTS.md`.
+3. **Требования раньше стека.** Сначала выясни продукт, пользователей, MVP, ограничения, данные, интеграции, безопасность, эксплуатацию и команду. Только после этого выбирай стек.
+4. **Стек подбирается под задачу.** Не навязывай любимые технологии. Для каждого ключевого выбора дай 2–3 реалистичных варианта, рекомендацию и причину.
+5. **Инструменты качества обязательны для выбранного стека.** Подбери форматтер, линтер, статанализатор/typecheck, тестовый стек, coverage, dependency/security audit, pre-commit и CI-проверки, если они есть и уместны в выбранной экосистеме.
+6. **MCP и скилы — только по делу.** Рекомендуй MCP-сервер или скил, когда он закрывает реальную нехватку контекста, интеграцию, повторяемый процесс или качество агентной работы.
+7. **Версии пакетов проверяй всегда.** Если предлагаешь npm/pip/gem/cargo/go/composer-пакет или пакет из другой экосистемы, найди последнюю стабильную версию через context7, если он доступен, или через web search по официальной документации, registry, release notes или репозиторию проекта. Не пиши `latest` без конкретной версии и источника. Если пользователь явно зафиксировал другую версию, не меняй её молча: покажи текущую стабильную, зафиксированную пользователем и причину расхождения.
+8. **Версии ПО тоже проверяй.** Если предлагаешь CLI, фреймворки, сервисы или MCP-серверы, а версия не зафиксирована пользователем, проверь актуальную стабильную версию через context7, если он доступен, или через web search по официальным источникам.
+9. **Архитектура должна быть объяснима.** Выбранная архитектура обязана соответствовать масштабу MVP, рискам, команде и будущему росту. Не предлагай сложность без причины.
+10. **Правила должны быть применимы.** Каждое правило должно отвечать на конкретный риск проекта и иметь понятную проверку: автоматическую, ревью-проверку или договорённость в `docs/rules.md`.
+11. **Простой язык. Таблицы** используй для сравнений стека, инструментов, MCP, скилов, правил и архитектурных вариантов.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+Вопросы задавай пакетами по 1–3 за раз. Сначала спрашивай только то, без чего следующий шаг будет гаданием. После каждого пакета используй ответ, обновляй рекомендацию и продолжай.
+
+## Этапы
+
+### 1. Собрать требования
+
+Собери и зафиксируй:
+- цель проекта и аудиторию;
+- MVP и что точно не входит в первую версию;
+- основные пользовательские сценарии;
+- типы данных, чувствительные данные, персональные данные и требования к хранению;
+- интеграции, платежи, auth, уведомления, файлы, поиск, аналитика, админку;
+- нагрузку, SLA, бюджет, сроки, размер команды и опыт команды;
+- платформы: web, mobile, desktop, API, CLI, bot, internal tool;
+- ограничения по хостингу, лицензиям, vendor lock-in, compliance и региону.
+
+Если не хватает критичных требований, задай `AskUserQuestion` и остановись до ответа.
+
+### 2. Выбрать стек
+
+Сравни 2–3 подходящих варианта стека. Для каждого укажи:
+- где он силён для этого проекта;
+- главный риск;
+- стоимость внедрения и поддержки;
+- зрелость экосистемы;
+- совместимость с командой и MVP.
+
+Рекомендуй один вариант. Если пользователь не дал режим «сам выбирай», задай `AskUserQuestion`: принять рекомендацию / выбрать альтернативу / сузить требования и пересчитать выбор.
+
+Для выбранного стека зафиксируй конкретные версии основных компонентов или источник версии: runtime, framework, БД, ORM, тестовый фреймворк, build tool, package manager, контейнеры и ключевые сервисы.
+
+Для каждого выбранного пакета отдельно зафиксируй:
+- последнюю стабильную версию;
+- источник версии и дату проверки;
+- если версия зафиксирована пользователем и отличается от последней стабильной — обе версии и причину, почему остаёмся на pinned-версии или почему предлагаем обновление.
+
+### 3. Подобрать инструменты качества
+
+Для выбранного стека подбери инструменты с обоснованием:
+- форматирование кода;
+- линтеры;
+- статический анализ и typecheck;
+- unit/integration/e2e/contract-тесты;
+- coverage;
+- dependency audit и security scan;
+- schema/API validation;
+- миграции БД и проверки миграций;
+- pre-commit hooks;
+- CI pipeline;
+- генераторы типов или клиентов, если API/схемы это требуют.
+
+Не предлагай инструмент, если он дублирует уже выбранный инструмент того же класса без явной пользы. Если в экосистеме есть несколько нормальных вариантов, сравни их и выбери один.
+
+### 4. Выбрать архитектуру
+
+Предложи 2–3 архитектурных варианта, соответствующих выбранному стеку и масштабу:
+- простой монолит / modular monolith;
+- API + frontend;
+- event-driven части;
+- serverless;
+- mobile-first / offline-first;
+- plugin/module architecture;
+- другой вариант, если он лучше подходит.
+
+Для каждого варианта покажи границы модулей, поток данных, риски и что будет сложно менять позже. Рекомендуй один вариант и задай `AskUserQuestion`, если выбор влияет на стоимость, сроки, масштабирование, данные или команду.
+
+### 5. Решить правила проекта
+
+Сформируй набор правил, которые стоит внедрить с первого дня:
+- структура проекта и границы модулей;
+- стиль кода и naming;
+- работа с ошибками и логированием;
+- тестовая стратегия;
+- миграции и данные;
+- API-контракты;
+- безопасность и секреты;
+- доступность и UX, если есть UI;
+- observability;
+- работа с AI-агентами, планами, ревью и коммитами;
+- политика зависимостей и обновлений.
+
+Для каждого правила укажи: какой риск оно закрывает, как проверяется, где будет зафиксировано. Затем спроси пользователя, какие правила принять сейчас, какие оставить предложениями и какие убрать.
+
+### 6. Подобрать AI-скилы, агентные инструкции и MCP
+
+Подбирай рабочий набор AI-инструментов только после требований, стека, инструментов качества, архитектуры и правил. Эти решения задают контекст: какие источники нужны агенту, какие проверки уже закрыты кодовыми инструментами, где нужны отдельные роли и какие права доступа допустимы.
+
+Подбери:
+- какие AI-скилы, slash-команды, агентные инструкции или специализированные роли нужны сразу: старт проекта, продуктовый discovery, планирование, исполнение задач, ревью, security review, проверка доступности, работа с документацией, релизный процесс, domain-expert по предметной области;
+- какие готовые скилы можно взять из доступных наборов, включая `eda-*`, Claude/Codex skills, командные инструкции репозитория или публичные каталоги, если они подходят;
+- какие проектные скилы стоит написать специально под этот проект: например для доменной модели, архитектурных границ, API-контрактов, миграций, дизайн-системы, ревью UI, работы с данными или внутренними интеграциями;
+- какие скилы и агентные роли отложить до появления кода, команды или повторяющейся проблемы;
+- какие MCP-серверы помогут агенту: файловая система, GitHub/GitLab, Postgres/SQLite, браузер, Playwright, Figma, документация, API-клиенты, issue tracker, cloud provider;
+- какие MCP не нужны, потому что выбранная архитектура, правила или инструменты качества уже закрывают задачу.
+
+Для каждого скила или агентной инструкции укажи: какую работу закрывает, кто запускает, на каких источниках должен основываться, какой артефакт создаёт, чем проверять результат и почему обычного промпта недостаточно. Не ограничивайся `eda-*`: они только один из возможных источников.
+
+Для каждого MCP укажи: зачем он нужен именно при выбранной архитектуре и правилах, какие данные откроет агенту, риски доступа, минимальные права и когда подключать. MCP с доступом к продакшену, секретам, платежам или персональным данным не включай по умолчанию: вынеси на отдельное подтверждение.
+
+### 7. Сохранить стартовый документ
+
+Сохрани стартовый документ в `docs/project-starts/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+
+Формат:
+
+```markdown
+---
+title: <заголовок>
+date: <YYYY-MM-DD HH:MM>
+status: draft
+sources:
+  existing_rules: <путь или —>
+  existing_arch: <путь или —>
+---
+
+# Старт проекта
+
+## Требования
+<цель, аудитория, MVP, ограничения, не входит>
+
+## Принятые решения
+| Область | Решение | Почему | Подтверждение |
+|---|---|---|---|
+| Стек | ... | ... | ответ пользователя / рекомендация принята |
+
+## Стек
+| Компонент | Выбор | Версия / источник | Обоснование |
+|---|---|---|---|
+
+## Инструменты качества
+| Класс | Инструмент | Где запускать | Почему |
+|---|---|---|---|
+
+## Архитектура
+<выбранный вариант, границы модулей, поток данных, важные ограничения>
+
+## Правила
+| Правило | Риск | Проверка | Статус |
+|---|---|---|---|
+
+## AI-скилы и агентные инструкции
+| Скил / инструкция | Источник | Когда использовать | Артефакт | Почему |
+|---|---|---|---|---|
+
+## MCP
+| MCP | Когда подключать | Права доступа | Риски |
+|---|---|---|---|
+
+## Открытые вопросы
+- <если есть>
+
+## Следующие шаги
+1. <создать/обновить docs/rules.md>
+2. <создать/обновить docs/arch.md>
+3. <запустить eda-plan для первого инкремента>
+```
+
+Quality gate перед сохранением:
+- есть требования и границы MVP;
+- выбран один основной стек, а не список равных вариантов;
+- инструменты качества покрывают форматирование, lint/static analysis/typecheck, тесты и CI или объясняют, почему часть не нужна;
+- выбрана архитектура и описаны границы;
+- правила имеют риск и способ проверки;
+- есть список AI-скилов, агентных инструкций или ролей с назначением, источником и артефактом, подобранный под выбранную архитектуру и правила;
+- MCP-серверы имеют обоснование, права и риски, связанные с выбранной архитектурой, данными и интеграциями;
+- все значимые решения имеют подтверждение пользователя или явно помечены как автономная рекомендация;
+- для каждого выбранного пакета указана последняя стабильная версия и источник; если используется не последняя стабильная версия, причина явно записана;
+- версии другого ПО проверены или объяснено, почему это не требуется.
+
+### 8. Создать черновики правил и архитектуры
+
+После сохранения стартового документа спроси `AskUserQuestion`: создать черновики `docs/rules.md`, `docs/arch.md` и `AGENTS.md` сейчас / только стартовый документ / выбрать отдельные документы.
+
+Если пользователь подтвердил:
+- не перезаписывай существующие файлы молча;
+- для каждого существующего файла спроси: дополнить / создать рядом / оставить как есть;
+- в `docs/rules.md` перенеси только принятые правила, а предложения оставь отдельным разделом;
+- в `docs/arch.md` перенеси выбранную архитектуру, границы модулей, поток данных, данные и интеграции;
+- в `AGENTS.md` добавь краткую карту проекта и ссылки на `docs/rules.md`, `docs/arch.md`, стартовый документ и команды проверки.
+
+Если пользователь отказался, не создавай эти файлы и запиши отказ в финале.
+
+### 9. Финал
+
+Короткое сообщение: путь к стартовому документу, какие решения приняты, какие документы созданы или не созданы, какие вопросы остались открытыми, какой следующий скил логично использовать (`eda-plan` для первого инкремента или `eda-docs` для доработки правил и архитектуры).
+
+## Чего НЕ делать
+
+- Создавать приложение, писать код, миграции, конфиги, CI или устанавливать зависимости.
+- Выбирать стек до требований.
+- Давать один вариант без объяснения альтернатив, если решение значимое.
+- Ставить MCP по умолчанию с широкими правами доступа.
+- Подменять линтеры, статанализаторы, typecheck и тесты агентными проверками.
+- Внедрять правила без согласия пользователя.
+- Перезаписывать существующие `docs/rules.md`, `docs/arch.md` или `AGENTS.md` без отдельного подтверждения.
+- Сохранять стартовый документ куда-либо кроме `docs/project-starts/`.