@gian-tiaga/eda 3.12.0 → 3.13.0

package/README.md

@@ -43,7 +43,7 @@ eda update-all ~/Code
 |---|---|---|
 | `eda-orhestra` | Выполняет настраиваемую цепочку `eda-*`-скилов. В `subagents` каждый этап получает чистый контекст, в `main` этапы выполняет текущий агент, а `main_propagated` дополнительно передаёт `main` в совместимые execute/review-этапы. По умолчанию: план без проверок → полировка плана → выполнение → автономное ревью и исправления → ручные тесты. Если QA нашёл баг, оркестра запускает fix и повторяет только ручной тест. В `orhestra.steps` шаги можно переставлять, отключать и снабжать `args`. Не коммитит | Артефакты включённых скилов |
 | `eda-aim` | Сначала через отдельного агента-планировщика согласует с человеком одну или несколько простых проверяемых целей, затем передаёт их агентам-исполнителям и повторяет работу до независимого подтверждения агентом-проверяющим. При необходимости использует установленные скилы в отдельных изолированных субагентах. В `automatic` отвечает на безопасные рабочие вопросы самостоятельно, в `manual` передаёт их человеку; режим задаётся через `aim.mode` или текущий вызов. Точный список новых целей человек подтверждает всегда | `docs/artifacts/aims/` и артефакты задействованных скилов |
-| `eda-new-project` | Помогает стартовать новый проект: собирает и согласует требования, функциональность и границы, ограничения и архитектурные драйверы, сравнивает варианты основного стека и фиксирует выбранные компоненты с актуальными стабильными версиями. Не проектирует архитектуру, правила, проверки, AI-скилы или MCP; сохраняет подтверждённый стартовый бриф и всегда без дополнительного вопроса запускает полный технический bootstrap через `eda-prepare-ai` | `docs/artifacts/project-starts/`, затем артефакты `eda-prepare-ai` |
+| `eda-new-project` | Помогает стартовать новый проект: собирает и согласует требования, функциональность и границы, ограничения и архитектурные драйверы, сравнивает варианты основного стека и фиксирует выбранные компоненты с актуальными стабильными версиями. Если у стека есть официальный generator/scaffold CLI, передаёт его как обязательный способ разворачивания вместо ручного создания основы. Не проектирует архитектуру, правила, проверки, AI-скилы или MCP; сохраняет подтверждённый стартовый бриф и всегда без дополнительного вопроса запускает полный технический bootstrap через `eda-prepare-ai` | `docs/artifacts/project-starts/`, затем артефакты `eda-prepare-ai` |
 | `eda-business` | Совместно с человеком описывает целевое поведение проекта по тематическим карточкам: сложные темы фиксирует подробно, но без шума, соседних модулей и привязки к текущему коду. Может закрепить значимый механизм вроде JWT или серверного хранения токенов, но не язык, библиотеку или конкретную СУБД. `about` содержит лишь короткое описание проекта и основные возможности | `docs/business.md`, `docs/business/` |
 | `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/artifacts/roadmaps/` |
 | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. После определения темы читает только применимые business- и reference-карточки. В дефолтном режиме ведёт исследование как диалог; для пакетов и ПО проверяет актуальные стабильные версии | `docs/artifacts/researches/` |
@@ -58,11 +58,11 @@ eda update-all ~/Code
 | `eda-fix-by-review` | Применяет все находки из ревью с учётом правил, архитектуры и применимых карточек. Спрашивает только при неоднозначности, конфликте, расширении scope или рискованном действии. В конце ссылается на отчёт прямо в файле ревью | `docs/artifacts/review-fixes/` |
 | `eda-manual-test` | Делает ручную проверку после изменений. По умолчанию проверка полная: разбирает план или другой артефакт по разделам, дополняет его фактическим `git diff HEAD` и закрывает матрицу областей — API, база данных, консольные команды, интерфейс, алгоритмы, фон и интеграции, права и роли, конфигурация, логи, регрессии рядом. Область нельзя закрыть чтением кода или зелёными автотестами; незакрытая область даёт `blocked`. Быстрый smoke включается настройкой `manual-test.depth` или словом в запросе. Применимая business-карточка может добавить только относящийся к задаче инвариант или сценарий. Не правит код, не пишет автотесты и не коммитит | `docs/artifacts/manual-tests/` |
 | `eda-polish` | Оркестрирует доводку изменений: запускает полное `eda-review`, затем `eda-fix-by-review` и повторяет цикл до `clean` и отсутствия находок либо до лимита 5 итераций. Режим цикла задаёт `polish.execution`: в `main` оба контракта выполняет основной агент без субагентов, в `subagents` каждый шаг получает отдельный изолированный контекст. Все находки исправляются, score остаётся справочным. Не коммитит | `docs/artifacts/reviews/`, `docs/artifacts/review-fixes/` |
-| `eda-send-review` | На `sonnet` / `gpt-5.6-terra` отправляет ревью на GitHub PR через `gh` всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода. Без явно указанного типа использует `comment`; `approve` и `request-changes` берёт только из контекста текущего вызова. По настройке может скрыть предыдущие сводки eda-send-review и зарезолвить их inline-треды. По умолчанию шлёт все пункты. Claude-модель закрепляется при установке; Codex-модель хранится как рекомендуемый будущий override | (комментарий в PR) |
-| `eda-commit` | Работает как лёгкий оркестратор одного `sonnet` / `gpt-5.6-terra` агента: тот сам собирает git-контекст, пишет сообщения и тексты PR по исходному запросу и фактическим изменениям, точечно коммитит и выполняет явно заданные push/PR/merge-действия. Агент экономит время: собирает контекст одним вызовом, не читает кодовую базу и документацию целиком, вместо полного diff берёт сводку `--stat` и дочитывает только неясные файлы, а смысл работы берёт из свежих артефактов `docs/artifacts/**`, если они есть в составе изменений. Весь состав идёт одним коммитом; на несколько логически цельных коммитов он делится только по явной просьбе (`split`, «раздели», «отдельными коммитами») или при явно раздельном scope. Для PR использует шаблон репозитория, отражает все группы изменений и указывает только реально выполненные проверки. С явным контекстом охватывает указанный состав; без контекста коммитит всё — все tracked-изменения и все untracked-файлы независимо от авторства и связи с текущей задачей, кроме очевидных кэшей и локальных служебных артефактов вроде `.DS_Store`. В Claude Code сам оркестратор закреплён за `sonnet`; в Codex остаётся на активной модели сессии из-за отсутствия per-skill override. При вероятном секрете агент блокируется до индексации затронутой группы. После любого push всегда возвращает ссылку — на существующий PR или на его создание — и спрашивает, создавать ли PR, если его нет. Если продолжение не задано, предлагает применимые варианты | (git, опционально GitHub PR) |
+| `eda-send-review` | На `sonnet` / `gpt-5.6-terra` отправляет ревью на открытый GitHub PR через `gh` всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода. Закрытый или смерженный PR не переиспользует и предлагает создать новый либо указать другой открытый PR. Без явно указанного типа использует `comment`; `approve` и `request-changes` берёт только из контекста текущего вызова. По настройке может скрыть предыдущие сводки eda-send-review и зарезолвить их inline-треды. По умолчанию шлёт все пункты. Claude-модель закрепляется при установке; Codex-модель хранится как рекомендуемый будущий override | (комментарий в PR) |
+| `eda-commit` | Работает как лёгкий оркестратор одного `sonnet` / `gpt-5.6-terra` агента: тот сам собирает git-контекст, пишет сообщения и тексты PR по исходному запросу и фактическим изменениям, точечно коммитит и выполняет явно заданные push/PR/merge-действия. Агент экономит время: собирает контекст одним вызовом, не читает кодовую базу и документацию целиком, вместо полного diff берёт сводку `--stat` и дочитывает только неясные файлы, а смысл работы берёт из свежих артефактов `docs/artifacts/**`, если они есть в составе изменений. Весь состав идёт одним коммитом; на несколько логически цельных коммитов он делится только по явной просьбе (`split`, «раздели», «отдельными коммитами») или при явно раздельном scope. Для PR использует шаблон репозитория, отражает все группы изменений и указывает только реально выполненные проверки; существующим считает только открытый PR, а после закрытого или смерженного создаёт новый. С явным контекстом охватывает указанный состав; без контекста коммитит всё — все tracked-изменения и все untracked-файлы независимо от авторства и связи с текущей задачей, кроме очевидных кэшей и локальных служебных артефактов вроде `.DS_Store`. В Claude Code сам оркестратор закреплён за `sonnet`; в Codex остаётся на активной модели сессии из-за отсутствия per-skill override. При вероятном секрете агент блокируется до индексации затронутой группы. После любого push всегда возвращает ссылку — на существующий PR или на его создание — и спрашивает, создавать ли PR, если его нет. Если продолжение не задано, предлагает применимые варианты | (git, опционально GitHub PR) |
 | `eda-worktree` | На `haiku` / `gpt-5.6-luna` создаёт через пакетного агента git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базу берёт из аргумента или спрашивает | соседняя папка `{name}-work-{n}` |
 | `eda-merge-worktree` | На `haiku` / `gpt-5.6-luna` мержит через пакетного агента ветку из соседнего worktree в текущую ветку. Принимает номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Worktree и ветку после merge не удаляет | (git) |
-| `eda-prepare-ai` | Выполняет технический bootstrap нового или существующего проекта: проектирует архитектуру, строгие правила и профиль инструментов, проходит полный каталог автоматических проверок, подбирает применимые AI-скилы, роли и MCP, затем создаёт AI-документацию. Один факт хранит у одного владельца: `docs/rules.md` содержит рабочие действия, запреты и команды проверок, а `docs/arch.md` — топологию исходного кода, ownership, зависимости и потоки без рабочих инструкций. Подтверждённые требования, стек и архитектурные драйверы из `eda-new-project` принимает как обязательный вход и не переоткрывает без обнаруженного конфликта. Для пустого проекта не выдумывает reference-карточки и не выдаёт неустановленные инструменты за доступные | `docs/rules.md`, `docs/arch.md`, `docs/references.md`, `docs/references/`, `AGENTS.md`, `CLAUDE.md` |
+| `eda-prepare-ai` | Выполняет технический bootstrap нового или существующего проекта: проектирует архитектуру, строгие правила и профиль инструментов, проходит полный каталог автоматических проверок, подбирает применимые AI-скилы, роли и MCP, затем создаёт AI-документацию. Для нового проекта фиксирует точную команду официального scaffold CLI выбранного стека, чтобы основа создавалась штатным инструментом, а не вручную. Один факт хранит у одного владельца: `docs/rules.md` содержит рабочие действия, запреты и команды проверок, а `docs/arch.md` — топологию исходного кода, ownership, зависимости и потоки без рабочих инструкций. Подтверждённые требования, стек и архитектурные драйверы из `eda-new-project` принимает как обязательный вход и не переоткрывает без обнаруженного конфликта. Для пустого проекта не выдумывает reference-карточки и не выдаёт неустановленные инструменты за доступные | `docs/rules.md`, `docs/arch.md`, `docs/references.md`, `docs/references/`, `AGENTS.md`, `CLAUDE.md` |
 | `eda-discover-automations` | Проводит baseline gap-аудит проекта даже без истории, а при наличии анализирует ревью, планы и фиксы. Не ограничивает число предложений: проверяет тесты/e2e, стиль, статанализ, границы модулей, конфиги/IaC, API/БД, security/supply chain, performance, release, эксплуатацию, browser MCP и MCP стека. Для каждой идеи даёт команду, контур запуска и приоритет; ничего не внедряет | `docs/artifacts/automations/` |
 
 ### Структура `docs/`

package/agents/eda-commit-executor/prompt.md

@@ -2,6 +2,8 @@
 
 Ты — единственный исполнитель `eda-commit`. Собери минимально достаточный git-контекст, определи состав по правилам ниже, закоммить его и выполни только явно разрешённое продолжение.
 
+Ты уже запущен как `eda-commit-executor`: выполняй работу сам и верни результат вызывающему агенту. Не запускай субагентов и не применяй навык `eda-commit` как оркестратор, даже если он упомянут во входном сообщении или прочитан при сборе контекста.
+
 Работай дёшево: каждое лишнее чтение и каждый лишний вызов команды замедляют коммит. Не читай кодовую базу, документацию проекта и большие файлы целиком, если этого прямо не требует правило ниже.
 
 ## Вход
@@ -100,8 +102,8 @@
 - Передавай многострочное описание через временный файл и `--body-file`, чтобы shell quoting не повредил Markdown. Не оставляй незаполненные placeholder'ы шаблона.
 
 - Для push используй существующий upstream, иначе `git push -u origin <branch>`.
-- Для PR определи base по `origin/HEAD`, сначала проверь текущую ветку через `gh pr view`; существующий PR не дублируй.
-- Если PR отсутствует, создай его через `gh pr create --title <title> --body-file <file>`, затем получи фактические номер и URL через `gh`; не угадывай ссылку. Если PR уже существует, меняй его заголовок или описание только по явному запросу пользователя через `gh pr edit`; обычный push не перезаписывает текст PR.
+- Для PR определи base по `origin/HEAD`, затем получи PR текущей ветки вместе с `state` через `gh pr list --head <branch> --state all --json number,url,state,headRefName,baseRefName`. Существующим считай только PR со `state: OPEN`; его не дублируй.
+- Закрытый или смерженный PR этой ветки не переиспользуй и не считай существующим: если создание PR запрошено, создай новый через `gh pr create --title <title> --body-file <file>`. Если открытого PR нет, действуй как при отсутствии PR. После создания получи фактические номер и URL, а также состояние через `gh`; не угадывай ссылку. Заголовок или описание открытого PR меняй только по явному запросу пользователя через `gh pr edit`; обычный push не перезаписывает текст PR.
 - После любого выполненного push всегда возвращай ссылку. Если PR текущей ветки есть — `pr.status: existing` и его фактический URL. Если PR нет — `pr.status: absent` и `pr.create_url`: ссылка на создание PR, собранная из фактического URL репозитория (`gh repo view`), base из `origin/HEAD` и имени ветки.
 - Если PR нет, а его создание не запрошено, сам PR не создавай: верни `completed`, `pr.create_url`, вопрос «Создать PR?» и варианты «создать PR» / «оставить ссылку на создание».
 - Если репозиторий не на GitHub или `gh` недоступен, верни `pr.create_url: null` и назови причину в `error`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "3.12.0",
+  "version": "3.13.0",
   "description": "Пакет скилов и специализированных агентов eda-* для Claude Code и Codex CLI",
   "type": "module",
   "bin": {

package/skills/eda-commit/SKILL.md

@@ -5,6 +5,8 @@ description: 'Коммитит выбранные или все незакомм
 
 # Скил: Коммитер (eda-commit)
 
+Этот навык предназначен для основного агента-оркестратора. Если ты уже запущен в роли `eda-commit-executor`, выполняй инструкции своей роли самостоятельно: не применяй процесс оркестратора ниже и не запускай другого `eda-commit-executor`.
+
 Работай как лёгкий оркестратор установленного агента `eda-commit-executor`. Сам не исследуй diff, не выбирай файлы, не составляй commit message и не выполняй git/GitHub-команды.
 
 ## Вход из сообщения пользователя
@@ -133,5 +135,6 @@ COMMIT_SPLIT:
 - Дробить состав на несколько коммитов, когда пользователь об этом не просил.
 - Спрашивать про push или PR, если пользователь уже явно приказал выполнить их.
 - Заканчивать выполненный push без ссылки на PR или на его создание.
+- Переиспользовать закрытый или смерженный PR вместо создания нового открытого PR.
 - Отключать hooks, использовать `--amend`, делать force-push в `main`/`master` или создавать дубликат PR.
 - Делать ревью или править логику кода — это другие скилы.

package/skills/eda-just-do-it/SKILL.md

@@ -21,7 +21,8 @@ description: 'Прямо выполняет задачу, указанную п
 4. **Сохраняй пользовательскую работу.** Перед изменениями проверь текущее состояние рабочей директории и не перезаписывай несвязанные правки.
 5. **Проверяй результат.** Для изменений поведения добавь или обнови точечные тесты. Выполни применимые тесты, линтеры, typecheck, сборку или предметную проверку; не заявляй о том, что не запускалось.
 6. **Внешние и git-действия — только по запросу.** Не коммить, не пушь, не создавай PR, не публикуй и не деплой без прямого указания рядом с вызовом. Для необратимого или разрушительного действия нужен однозначный target; при неоднозначности спроси.
-7. **Артефакт обязателен.** Создай отчёт до первого содержательного изменения и поддерживай его в актуальном состоянии. Заверши отчёт даже при частичном результате, блокере или ошибке.
+7. **Новый проект разворачивай штатным CLI.** Если для выбранного стека существует официальный generator/scaffold CLI, используй его через package manager или runtime (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог), а не создавай генерируемую основу вручную. Затем меняй полученный scaffold в рамках запроса. Если подходящих CLI несколько и выбор меняет результат, задай `AskUserQuestion`.
+8. **Артефакт обязателен.** Создай отчёт до первого содержательного изменения и поддерживай его в актуальном состоянии. Заверши отчёт даже при частичном результате, блокере или ошибке.
 
 ## Как выбрать контекст
 

package/skills/eda-new-project/SKILL.md

@@ -23,6 +23,7 @@ description: 'Собирает и согласует требования, гр
 6. **Не пишешь код и не ставишь пакеты.** Сам меняй только `docs/artifacts/project-starts/`; не создавай конфиги, CI или проектную AI-документацию.
 7. **Проверяй версии выбранного стека.** Для каждого подтверждаемого пакета, runtime, framework, СУБД, CLI или сервиса найди актуальную стабильную версию по официальному источнику. Не пиши `latest` без номера версии, источника и даты проверки.
 8. **Не усиливай требования догадками.** Отделяй прямой факт пользователя от вывода: например, хостинг в конкретной стране сам по себе не означает обязательную резидентность данных. Не подтверждённое следствие запиши как открытый вопрос, а не как принятое ограничение.
+9. **Передавай штатный способ разворачивания.** Если у выбранного языка, framework или package manager есть официальный CLI для создания проекта, зафиксируй его как обязательный способ последующего bootstrap. Не проектируй файлы scaffold вручную и не запускай CLI внутри этого скила.
 
 ## Интерактивные вопросы
 
@@ -125,6 +126,7 @@ status: ready-for-prepare-ai
 - <если есть>
 
 ## Handoff в eda-prepare-ai
+- Разворачивать основу проекта штатным CLI выбранного стека или package manager, а не создавать доступный ему scaffold вручную.
 - Спроектировать и согласовать архитектуру.
 - Сформировать строгие правила проекта и профиль инструментов.
 - Провести полный аудит автоматических проверок.
@@ -138,6 +140,7 @@ status: ready-for-prepare-ai
 - выбран один основной стек, а не список равных вариантов;
 - все значимые решения подтверждены пользователем или явно помечены как автономный выбор;
 - для каждого выбранного компонента указаны версия, официальный источник и дата проверки;
+- для нового проекта указан официальный CLI bootstrap выбранного стека, если такой CLI существует;
 - правила, архитектура, проверки и AI/MCP-рекомендации не спроектированы внутри стартового документа.
 
 ### 5. Всегда передать стартовый документ `eda-prepare-ai`

package/skills/eda-plan/SKILL.md

@@ -69,7 +69,8 @@ description: 'Создаёт понятный исполнимый план ре
 12. Один факт — одно место. Поведение описано в `Целевом алгоритме`, контракты — в `Контрактах реализации`, фаза на них опирается и не повторяет их.
 13. План доводится до первой точки, где результат можно запустить и проверить целиком. Дальше планируй следующей вехой, на фактах.
 14. Если нужны пакеты, библиотеки, CLI или сервисы, а версия не указана в контексте или lock-файлах, найди последнюю стабильную версию через context7 или web search. Не пиши `latest` без конкретной версии и источника.
-15. Финальный план прост, исполним и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
+15. Если план разворачивает новый проект и у выбранного стека есть официальный generator/scaffold CLI, план обязан использовать точную команду этого CLI или package manager (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог). Не планируй ручное создание файлов, которые штатно генерирует этот инструмент; последующие целевые изменения поверх результата CLI допустимы.
+16. Финальный план прост, исполним и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
 
 ## Технические остановки субагентов
 
@@ -210,6 +211,7 @@ Quality gate перед показом на подтверждение, пере
 - ни один факт не описан в двух разделах;
 - `test_strategy` и `logging_strategy` применены;
 - пакеты имеют конкретные версии или ссылку на существующий lock;
+- bootstrap нового проекта использует существующий официальный CLI выбранного стека, а не ручное воспроизведение scaffold;
 - нет неподтверждённых существенных решений, неразрешённых альтернатив и открытых вопросов;
 - нет общих призывов, повторов и пояснений, удаление которых не меняет действия, контракты, проверки или принятые решения;
 - объём: `normal` — не больше 40 КБ, `short` — не больше 12 КБ и 2 фаз. Это стоп, а не цель: план настолько короткий, насколько позволяет однозначность. При превышении раздели план по вехам и предложи пользователю первую;

package/skills/eda-plan-execute/SKILL.md

@@ -57,7 +57,8 @@ plan-execute:
 6. **Блокируй конфликт.** План задаёт область выполняемой работы, а применимые business-карточки — требования к затронутому поведению. Если план противоречит business-карточке, `rules.md`, `arch.md` или reference-карточке, останови фазу и через `AskUserQuestion` спроси: изменить план через `eda-plan` или сначала пересогласовать правило через `eda-business`.
 7. **Отмечай только подтверждённое.** Фазу закрывай только после выполнения и прошедшей проверки: в `subagents` это `completed` от исполнителя и отдельный `passed` от проверяющего, в `main` — пройденные критерии и команды проверки фазы с сохранённым выводом. При последующем опровержении верни отметку в незавершённое состояние.
 8. **Проверки нельзя подавлять.** Не отключай и не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, не добавляй игноры и не ослабляй команды и правила. Сначала исправляется причина падения, затем проверка повторяется.
-9. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
+9. **Новый проект разворачивай штатным CLI.** Если фаза создаёт основу нового проекта и для выбранного стека существует официальный generator/scaffold CLI, исполнитель обязан вызвать его через подходящий package manager или runtime (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог). Не создавай вручную файлы, которые генерирует CLI; после генерации изменяй результат только в границах плана. Если точная команда отсутствует в плане и проектных правилах, верни фазу в `eda-plan`, а не импровизируй ручной scaffold.
+10. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
 
 ## Вопросы
 

package/skills/eda-prepare-ai/SKILL.md

@@ -23,6 +23,7 @@ description: 'Готовит проект к работе с AI: проекти
 8. **Стартовый бриф задаёт цель, а не реализацию.** Подтверждённые требования, основной стек и архитектурные драйверы из `eda-new-project` считай обязательным входом. Не переоткрывай выбор стека без обнаруженного противоречия; архитектуру, правила, проверки и AI/MCP-процесс спроектируй здесь.
 9. **Максимальная практическая строгость по умолчанию.** Для каждого применимого инструмента предложи самый строгий стабильный полезный профиль. Ослабления показывай как отдельные решения с последствиями и минимальной областью действия.
 10. **Не внедряй tooling.** Можешь рекомендовать пакеты, команды, конфиги, скилы и MCP, но не устанавливай и не настраивай их; для внедрения предложи `eda-plan`.
+11. **Новый проект разворачивается штатным CLI.** Для bootstrap из `eda-new-project` найди официальный генератор выбранного стека и точную воспроизводимую команду через его package manager (`composer create-project`, `npm create`, `npx`, `cargo new` или реальный аналог). Зафиксируй эту команду в `docs/rules.md` как обязательную для создания основы проекта; не предлагай вручную воспроизводить файлы, которые создаёт доступный официальный CLI.
 
 ## Интерактивные вопросы
 
@@ -125,6 +126,7 @@ description: 'Готовит проект к работе с AI: проекти
 В `docs/rules.md` уместны:
 
 - обязательные команды и момент их запуска;
+- для нового проекта — точная команда официального scaffold/generator CLI выбранного стека вместо ручного создания его основы;
 - действующие соглашения об именовании, формате и совместимости;
 - требования к изменениям, например обязательная миграция при изменении схемы или обновление контракта при изменении публичного API;
 - точечные запреты небезопасных конструкций, бесконтрольных подавлений, утечки секретов и персональных данных;
@@ -261,6 +263,7 @@ description: 'Готовит проект к работе с AI: проекти
 - browser MCP и MCP выбранного стека оценены отдельно от детерминированных CLI/CI-проверок;
 - выбранные инструменты имеют максимальный применимый строгий профиль, а каждое ослабление явно обосновано;
 - для нового проекта требования, стек и архитектурные драйверы взяты из стартового документа, а архитектура и правила спроектированы внутри `eda-prepare-ai`;
+- для нового проекта с доступным официальным генератором в `docs/rules.md` записана точная bootstrap-команда package manager или CLI;
 - AI-скилы, роли и MCP разделены на уже доступные и требующие отдельного внедрения;
 - у каждого факта есть ровно один документ-владелец, а остальные документы при необходимости только ссылаются на него без пересказа;
 - между документами нет дублей, архитектурных путей в `docs/rules.md`, императивных рабочих инструкций в `docs/arch.md` и противоречий с проектом или друг с другом.

package/skills/eda-send-review/SKILL.md

@@ -58,9 +58,9 @@ description: 'Публикует готовое ревью в GitHub PR как
 **Что отправлять.** По умолчанию — все замечания. Если в тексте указано подмножество, отправь только его. Синтаксис свободный, распознавай по смыслу: по номерам («пункты 1, 3, 5») или по типу («только security» → замечания с этим `Тип`). У находок нет разных степеней обязательности: каждый отправляемый пункт требует исправления. Выбор влияет и на сводку, и на комментарии к строкам. Для старого формата отправляй только раздел `Править обязательно`; предложения из остальных групп отбрасывай.
 
 ### 3. Найти целевой PR
-Если номер PR указан в тексте пользователя — используй его. Иначе попробуй `gh pr view --json number,url,headRefName` — если у текущей ветки уже есть PR, возьми его номер.
+Если номер PR указан в тексте пользователя — проверь его через `gh pr view <num> --json number,url,state,headRefName`. Иначе найди PR текущей ветки через `gh pr list --head <branch> --state all --json number,url,state,headRefName`.
 
-Если PR нет — `AskUserQuestion`: «PR ещё нет: создать PR из текущей ветки / указать номер существующего PR / прервать». При создании используй `gh pr create` (заголовок и тело — по последним коммитам ветки).
+Целью может быть только PR со `state: OPEN`. Закрытый или смерженный PR не переиспользуй: считай, что подходящего PR нет. Тогда задай `AskUserQuestion`: «Открытого PR нет: создать новый PR из текущей ветки / указать номер другого открытого PR / прервать». При выборе создания используй `gh pr create` (заголовок и тело — по последним коммитам ветки), затем заново получи фактические номер, URL и состояние.
 
 ### 4. Выбрать статус review