@gian-tiaga/eda 1.0.2 → 1.0.3

package/README.md

@@ -42,9 +42,9 @@ eda update-all ~/Code
 | `eda-new-project` | Помогает стартовать новый проект: собирает и согласует требования, функциональность и границы, ограничения и архитектурные драйверы, сравнивает варианты основного стека и фиксирует выбранные компоненты с актуальными стабильными версиями. Не проектирует архитектуру, правила, проверки, AI-скилы или MCP; сохраняет подтверждённый стартовый бриф и всегда без дополнительного вопроса запускает полный технический bootstrap через `eda-prepare-ai` | `docs/project-starts/`, затем артефакты `eda-prepare-ai` |
 | `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/roadmaps/` |
 | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. Читает только применимые карточки из `docs/references/`, если они есть. В дефолтном режиме ведёт исследование как диалог; для пакетов и ПО проверяет актуальные стабильные версии | `docs/researches/` |
-| `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. `docs/rules.md`, `docs/arch.md` и применимые кодовые эталоны использует как обязательную рамку. В плане явно фиксирует контракты БД/API, прямые зависимости задач и какие задачи безопасно выполнять параллельно. Затем три параллельных субагента/модели проверяют реалистичность, полноту и соблюдение рамки | `docs/plans/` |
+| `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. `docs/rules.md`, `docs/arch.md` и применимые кодовые эталоны использует как обязательную рамку. В плане явно фиксирует контракты БД/API, прямые зависимости задач и связные фазы, рассчитанные на одного исполнителя. Затем три параллельных субагента/модели проверяют реалистичность, полноту и соблюдение рамки | `docs/plans/` |
 | `eda-plan-polish` | Полирует готовый план до оценки 95/100 или заданного порога. Каждая итерация запускает три изолированных агента, которые проверяют план по правилам, архитектуре, `sources.references`, research и коду. В strict дополнительно запускается кросс-ревью Claude ↔ Codex. Основной агент правит только файл плана и не запускает проверки проекта | `docs/plans/` |
-| `eda-plan-execute` | Управляет выполнением плана по фазам. Фазы проходят строго последовательно, а безопасно совместимые задачи внутри фазы запускаются параллельно отдельными изолированными субагентами. Код, исправления, фазовые и финальные проверки основной агент не выполняет: он управляет зависимостями, отмечает подтверждённые задачи и ведёт журнал | `docs/executions/` |
+| `eda-plan-execute` | Управляет выполнением плана по фазам. Каждую фазу целиком выполняет отдельный изолированный субагент: он читает план, правила и архитектуру, а применимые карточки — по ходу работы через индекс `docs/references.md`. Фазы проходят строго последовательно и принимаются независимыми проверяющими. Основной агент отмечает подтверждённые задачи и ведёт журнал | `docs/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или плану. Перед правками читает правила, архитектуру и только применимые карточки, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
 | `eda-review` | Оркестрирует отдельные read-only проверки корректности, архитектуры, правил, references, плана, качества, тестов, безопасности, производительности, frontend/UI/UX, API, БД, документации и предыдущих ревью. По конфигу запускает только применимые packaged-агенты, объединяет подтверждённые проблемы, ставит экспертную оценку 0–100 и сохраняет покрытие. Без аргументов ревьюит `git diff HEAD`. Код и удалённые обсуждения не меняет | `docs/reviews/` |
 | `eda-fix-by-review` | Применяет замечания из ревью с учётом правил, архитектуры и применимых карточек. Обязательные пункты исправляет сразу; optional-пункты спрашивает или решает сам в `apply-optional`. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |

package/package.json

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

package/skills/eda-aim/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-aim
-description: 'Согласует с пользователем одну или несколько простых проверяемых целей, сохраняет их в компактном файле `docs/aims/` и ведёт работу до достижения. Планирование, выполнение и итоговая проверка идут через отдельных пакетных субагентов; основной агент только оркестрирует вопросы и передачи. Поддерживает automatic/manual из `aim.mode` или текущего вызова; при необходимости использует установленные скилы в изолированных субагентах.'
+description: 'Согласует одну или несколько проверяемых целей и ведёт их выполнение до независимо подтверждённого результата.'
 ---
 
 # Скил: Достижение цели (eda-aim)

package/skills/eda-commit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-commit
-description: 'Оркестрирует один логический коммит через двух последовательных пакетных агентов. `eda-commit-context` на `haiku` / `gpt-5.6-luna` собирает read-only контекст; `eda-commit-executor` на `sonnet` / `gpt-5.6-terra` формирует сообщение, коммитит и выполняет явно указанные push, PR или merge-действия. Учитывает весь текст текущего сообщения: если пользователь уже попросил отправить ветку, создать PR и дать ссылку, не задаёт общий вопрос после коммита. Не правит код и не отключает hooks.'
+description: 'Создаёт один логический git-коммит и по явному запросу выполняет push, создание PR или merge.'
 ---
 
 # Скил: Коммитер (eda-commit)

package/skills/eda-discover-automations/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-discover-automations
-description: 'Проводит экстремально широкий аудит автоматических проверок проекта и анализирует историю `docs/reviews/`, `docs/review-fixes/`, `docs/fixes/`, опционально `docs/plans/`. Перечисляет пробелы в тестах, e2e, стиле, статанализе, архитектурных границах, конфигах, безопасности, данных, производительности, релизах, browser MCP и MCP выбранного стека. Сначала предлагает детерминированные CLI/CI-проверки, затем MCP или агентные усиления. Не внедряет изменения — сохраняет приоритетный отчёт с командами и контурами запуска в `docs/automations/`.'
+description: 'Аудирует автоматические проверки проекта и предлагает недостающие тесты, статический анализ, CI, MCP и другие автоматизации.'
 ---
 
 # Скил: Поиск автоматизаций (eda-discover-automations)

package/skills/eda-explore/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-explore
-description: 'Исследует тему или задачу до конкретного результата: проясняет проблему, архитектуру, развилки, риски и короткий выбранный вариант решения без плана реализации. Работает read-only, читает `docs/rules.md`, `docs/arch.md` и релевантные карточки из `docs/references/`, а значимые развилки выносит пользователю по `explore.decision_mode` из `docs/settings.yaml`. Для пакетов и другого ПО проверяет актуальные стабильные версии по официальным источникам. Итог сохраняет в docs/researches/. Кросс-ревью соседним агентом включается флагом `strict` или настройкой `explore.strict: true`.'
+description: 'Исследует техническую тему или задачу, сравнивает варианты и фиксирует выбранное решение без плана реализации.'
 ---
 
 # Скил: Исследователь решений (eda-explore)

package/skills/eda-fix/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-fix
-description: 'Делает обычные фиксы по плану, файлу плана или короткому текстовому контексту. Перед правками читает `docs/rules.md`, `docs/arch.md` и только релевантные карточки из `docs/references/`, если они есть, и следует им с установленным приоритетом. Правит код, добавляет нужные тесты, прогоняет проверки и сохраняет историю в `docs/fixes/`. Не делает ревью и не коммитит.'
+description: 'Вносит изменения в код по плану или текстовому описанию задачи и проверяет результат.'
 ---
 
 # Скил: Фиксер (eda-fix)

package/skills/eda-fix-by-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-fix-by-review
-description: 'Применяет замечания из ревью (`docs/reviews/...`) или текста к коду. Перед правками читает `docs/rules.md`, `docs/arch.md` и релевантные карточки из `docs/references/`. Все обязательные пункты правит сразу; optional-пункты выносит пользователю или решает сам в `apply-optional`. После правок прогоняет тесты и линтеры, сохраняет отчёт в `docs/review-fixes/`. Не делает само ревью и не коммитит.'
+description: 'Исправляет код по готовому ревью из файла или сообщения и проверяет результат.'
 ---
 
 # Скил: Исправитель по ревью (eda-fix-by-review)

package/skills/eda-manual-test/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-manual-test
-description: 'Делает ручную smoke/acceptance-проверку после изменений: сам строит чеклист из входа пользователя, плана или незакоммиченного diff; для API выполняет curl/HTTP-запросы, для фронта использует Playwright или доступную browser automation. Сам запускает очевидные dev/API-серверы, фиксирует фактическое поведение и сохраняет QA-отчёт в docs/manual-tests/. Не правит код, не пишет автотесты, не ставит зависимости, не коммитит.'
+description: 'Проводит ручную smoke/acceptance-проверку изменённого API или интерфейса и сохраняет отчёт.'
 ---
 
 # Скил: Ручное тестирование (eda-manual-test)

package/skills/eda-merge-worktree/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-merge-worktree
-description: 'Оркестрирует merge ветки из соседнего git worktree через пакетного агента на `haiku` / `gpt-5.6-luna`. Аргумент принимает как номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Перед merge проверяет оба worktree на незакоммиченные изменения. После успешного merge не удаляет worktree и ветку.'
+description: 'Мержит ветку из соседнего git worktree в текущую рабочую ветку.'
 ---
 
 # Скил: Merge из worktree (eda-merge-worktree)
@@ -9,7 +9,7 @@ description: 'Оркестрирует merge ветки из соседнего
 
 ## Вход из сообщения пользователя
 
-Сохрани весь текст текущего сообщения дословно в `$USER_REQUEST`. Это главный вход: номер worktree, короткое имя `work-<n>`, полное имя `{name}-work-<n>`, ограничения и прямые указания.
+Сохрани весь текст текущего сообщения дословно в `$USER_REQUEST`. Это главный вход: номер worktree, короткое имя или полное имя, ограничения и прямые указания. Аргумент принимает как `1`, `work-1` или `{name}-work-1`.
 
 Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно. При последующем ответе на вопрос сохрани исходный `$USER_REQUEST` и передай ответ отдельно.
 
@@ -64,6 +64,8 @@ USER_REQUEST:
 - статус: `merged`, `already up to date` или `conflict`;
 - что worktree и исходная ветка не удалялись.
 
+После успешного merge скил не удаляет worktree и ветку.
+
 ## Чего НЕ делать
 
 - Выполнять работу `eda-merge-worktree-executor` основным агентом.

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

@@ -1,6 +1,6 @@
 ---
 name: eda-new-project
-description: 'Помогает начать новый проект: вместе с пользователем собирает требования, функциональность, границы, сценарии, ограничения и архитектурные драйверы, сравнивает варианты основного стека и фиксирует выбранные компоненты с актуальными стабильными версиями. Не проектирует архитектуру, правила, проверки, AI-скилы или MCP, не пишет код и не ставит зависимости: сохраняет подтверждённый стартовый документ в docs/project-starts/ и всегда передаёт его eda-prepare-ai для полного технического bootstrap.'
+description: 'Собирает и согласует требования, границы, архитектурные драйверы и основной стек нового проекта, затем запускает его техническую подготовку.'
 ---
 
 # Скил: Новый проект (eda-new-project)

package/skills/eda-orhestra/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-orhestra
-description: 'Оркестрирует настраиваемую цепочку установленных `eda-*`-скилов по описанию задачи или готовому артефакту. Каждый этап, включая составные скилы, запускает в отдельном изолированном субагенте. Порядок, включение шагов и аргументы берёт из `orhestra.steps` в `docs/settings.yaml` или текущего вызова. В `automatic` безопасно закрывает рабочие вопросы сам, в `manual` ведёт планирование вместе с человеком. Умеет после failed manual-test запустить настроенный fix и повторные шаги. Не выполняет git/publish-действия.'
+description: 'Выполняет настраиваемую цепочку `eda-*`-скилов для задачи или готового артефакта.'
 ---
 
 # Скил: Оркестра полного цикла (eda-orhestra)

package/skills/eda-plan/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: eda-plan
-description: 'Пишет исполнимый план реализации через стандартный Plan Mode Claude Code / Codex и сохраняет его в docs/plans/. Перед планированием читает docs/rules.md, docs/arch.md и только релевантные карточки из docs/references/ как обязательную рамку, подтягивает research и настройки. Не оставляет неподтверждённых решений, явно описывает БД/API-контракты и помечает задачи, которые безопасно выполнять параллельно. После сохранения всегда запускает три параллельных мета-ревьюера; strict добавляет кросс-CLI.'
+description: 'Создаёт подробный исполнимый план реализации задачи и сохраняет его в `docs/plans/`.'
 ---
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости и безопасную параллельность задач, затем проверяешь план тремя параллельными субагентами/моделями. В `strict` добавляешь кросс-CLI проверку.
+Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости задач и формируешь связные фазы для выполнения одним агентом, затем проверяешь план тремя параллельными субагентами/моделями. В `strict` добавляешь кросс-CLI проверку.
 
 ## Режим запуска
 
@@ -61,7 +61,7 @@ description: 'Пишет исполнимый план реализации че
 7. Финальный план должен быть простым, исполнимым и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
 8. Если нужны пакеты, библиотеки, CLI, сервисы или другое ПО, а версия не указана в контексте или lock/config-файлах, найди последнюю стабильную версию через context7 или web search по официальным источникам. Не пиши `latest` без конкретной версии и источника.
 9. Если выбран `plan.size: short`, но задача не укладывается в ограничения, не сохраняй short-план: объясни причину, оцени нужный объём и спроси, продолжать в `normal` или сузить задачу.
-10. Каждой задаче в фазах присвой уникальный ID, укажи её прямые зависимости и явно пометь, с какими задачами её безопасно выполнять параллельно. Не считай задачи параллельными, если они меняют один файл или участок кода, общий изменяемый контракт, одну миграционную цепочку либо используют результат друг друга.
+10. Каждой задаче в фазах присвой уникальный ID и укажи её прямые зависимости. Собери каждую фазу вокруг одной связной цели и объёма, который один исполнитель может реализовать и проверить за один проход; слишком крупную или несвязную фазу раздели.
 
 ## Этапы
 
@@ -86,7 +86,7 @@ description: 'Пишет исполнимый план реализации че
 5. Пути к `docs/rules.md`, `docs/arch.md`, применимым карточкам, research и выписку обязательных элементов рамки.
 6. Требование: план следует правилам, архитектуре и применимым эталонам с указанным приоритетом; при конфликте или необоснованном отклонении остановиться и спросить пользователя.
 7. Требование: финальный план нормализуется в структуру ниже, не смешивает исследование с исполнением и не добавляет неподтверждённые существенные решения.
-8. Требование: каждая задача получает уникальный ID, прямые зависимости и явную маркировку безопасной параллельности с другими задачами.
+8. Требование: каждая задача получает уникальный ID и прямые зависимости, а каждая фаза образует связный объём работы для одного исполнителя.
 
 Не выходи из Plan Mode, пока пользователь не подтвердил план.
 
@@ -135,9 +135,9 @@ sources:
 Цель: <зачем нужна фаза>.
 
 Что сделать:
-- `[1.1]` <конкретная задача>. Зависит от: `—`. Параллельно: `[1.2]`.
-- `[1.2]` <конкретная задача>. Зависит от: `—`. Параллельно: `[1.1]`.
-- `[1.3]` <конкретная задача>. Зависит от: `[1.1, 1.2]`. Параллельно: `нет`.
+- `[1.1]` <конкретная задача>. Зависит от: `—`.
+- `[1.2]` <конкретная задача>. Зависит от: `[1.1]`.
+- `[1.3]` <конкретная задача>. Зависит от: `[1.2]`.
 
 Результат: <готовое состояние>.
 
@@ -163,10 +163,9 @@ sources:
 Правила структуры:
 
 - Риски не выносятся в отдельный обязательный раздел; закрытые риски встраиваются в решения, фазы, сценарии тестирования, проверки, логирование или эксплуатацию.
-- Отдельный раздел порядка выполнения не нужен: основной поток задаётся номерами фаз, ID задач и их зависимостями, а допустимые пересечения — полем `Параллельно` внутри каждой задачи.
+- Отдельный раздел порядка выполнения не нужен: основной поток задаётся номерами фаз, ID задач и их зависимостями.
 - ID задачи имеет формат `[<номер фазы>.<номер задачи>]` и уникален во всём плане. В `Зависит от` перечисляй только прямые зависимости; `—` означает, что задачу можно начинать независимо от других задач плана.
-- В `Параллельно` перечисляй ID всех задач, которые можно безопасно выполнять одновременно с этой задачей, либо пиши `нет`. Маркировка должна быть симметричной: если `[1.1]` параллельна `[2.1]`, это указывается у обеих задач.
-- Перед маркировкой проверь пересечения по файлам и участкам кода, данным, БД-миграциям, API/событийным схемам, сгенерированным артефактам и общему изменяемому состоянию. При конфликте или зависимости параллельность запрещена.
+- Одну фазу целиком выполняет один изолированный субагент `eda-plan-execute`. Задачи фазы должны относиться к общей цели, иметь согласованный scope и помещаться в один исполнительский проход вместе с точечными и фазовыми проверками.
 - В `Контракты реализации` попадают схемы данных, БД, API и внешние контракты; если область не затрагивается, напиши `Не затрагивается`.
 - В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Для UI опиши пользовательский сценарий, состояния успеха/ошибки и видимый результат; для внутренней логики — ответственность частей, поток данных, состояния и ошибки.
 - Если нужен раздел `Открытые вопросы`, оставь `status: draft`, сохрани файл и не запускай мета-ревью до ответа пользователя.
@@ -179,7 +178,7 @@ Quality gate перед сохранением и после мета-ревью
 - нет конфликтов с правилами, архитектурой, границами модулей, API, миграциями, зависимостями и командами проверки;
 - БД/API изменения описаны конкретно, а не общими словами;
 - каждая фаза имеет цель, шаги, результат, сценарии тестирования и проверку;
-- каждая задача имеет уникальный ID, прямые зависимости и поле `Параллельно`; ссылки на ID существуют, параллельность симметрична и не конфликтует с зависимостями или общими изменяемыми ресурсами;
+- каждая задача имеет уникальный ID и прямые зависимости, ссылки на ID существуют, а каждая фаза связна и выполнима одним агентом за один проход;
 - `test_strategy` и `logging_strategy` применены в фазах и отдельных разделах;
 - для `short` не больше 2 фаз и явно указан ожидаемый объём;
 - пакеты/ПО имеют конкретные версии или ссылку на существующий lock/config;
@@ -198,7 +197,7 @@ Quality gate перед сохранением и после мета-ревью
 
 В интерактивном Codex, если доступен инструмент субагентов (`spawn_agent` или аналог), используй его. Не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны. В неинтерактивном fallback запускай три `codex exec --model <id>` параллельно одной Bash-командой с `&` и общим `wait`.
 
-Промпт всем: прочитать план, `docs/rules.md`, `docs/arch.md`, карточки из `sources.references`, research из `sources.research` при наличии и релевантный код по глубине модели. Найти пропущенные шаги, нарушения правил/архитектуры/эталонов, необоснованные отклонения, скрытые риски, риски для смежного кода, недостающие тесты, шаги без критериев готовности, неверные зависимости и небезопасную или упущенную параллельность. Формат ответа: `+ N | − N | ~ N: причина`; флагману явно скажи открывать файлы модулей, API, тестов и сценариев, на которые ссылается план.
+Промпт всем: прочитать план, `docs/rules.md`, `docs/arch.md`, карточки из `sources.references`, research из `sources.research` при наличии и релевантный код по глубине модели. Найти пропущенные шаги, нарушения правил/архитектуры/эталонов, необоснованные отклонения, скрытые риски, риски для смежного кода, недостающие тесты, шаги без критериев готовности, неверные зависимости и слишком крупные или несвязные фазы для одного исполнителя. Формат ответа: `+ N | − N | ~ N: причина`; флагману явно скажи открывать файлы модулей, API, тестов и сценариев, на которые ссылается план.
 
 После ответов интегрируй принятые замечания в основные разделы плана, снова прогони quality gate и добавь:
 

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

@@ -1,11 +1,11 @@
 ---
 name: eda-plan-execute
-description: 'Управляет выполнением готового плана из docs/plans/: проходит фазы строго последовательно, строит волны задач по зависимостям и запускает безопасно совместимые задачи параллельно в отдельных изолированных субагентах. Разработку, исправления и все проверки выполняют только субагенты; основной агент координирует их, ведёт чекбоксы плана и журнал в docs/executions/. Не коммитит и не делает ревью.'
+description: 'Выполняет готовый план из `docs/plans/` последовательно по фазам с независимой проверкой результата.'
 ---
 
 # Скил: Управляющий выполнением плана (eda-plan-execute)
 
-Оркестрируй выполнение готового плана. Сам не реализуй задачи и не запускай проверки проекта: передавай каждую задачу, исправление и проверку новому изолированному субагенту. Сам выбирай готовые к запуску задачи, связывай результаты, обновляй прогресс плана и журнал выполнения.
+Оркестрируй выполнение готового плана. Сам не реализуй задачи и не запускай проверки проекта: передавай каждую фазу целиком отдельному изолированному субагенту, а её приёмку — отдельному проверяющему. Связывай результаты фаз, обновляй прогресс плана и журнал выполнения.
 
 ## Вход из сообщения пользователя
 
@@ -16,14 +16,13 @@ description: 'Управляет выполнением готового пла
 ## Главные правила
 
 1. **Основной агент только управляет.** Разрешены чтение контекста, построение очереди, запуск и контроль субагентов, вопросы пользователю, обновление `$PLAN_FILE` и `$EXECUTION_FILE`. Код, тесты, миграции, конфиги, зависимости, документацию проекта и git-состояние меняют только назначенные субагенты.
-2. **Фазы выполняй строго последовательно.** Не запускай задачу следующей фазы, пока все задачи текущей фазы не завершены и отдельная проверка фазы не прошла.
-3. **Каждая работа изолирована.** Каждую задачу плана, подготовку ветки/worktree, исправление после падения, проверку фазы и финальную проверку запускай новым субагентом со свежим контекстом без истории диалога.
-4. **Безопасную параллельность используй обязательно.** Внутри текущей фазы одновременно запускай все готовые задачи, которые план взаимно пометил как параллельные и которые не пересекаются по изменяемым файлам, контрактам, данным или общему состоянию. Остальные запускай последовательными волнами по зависимостям.
-5. **План и проектная документация — обязательная рамка исполнения.** Перед запуском прочитай план, `docs/rules.md`, `docs/arch.md` и карточки из `sources.references`; для старого плана выбери через `docs/references.md` только применимые карточки.
-6. **Соблюдай приоритет и блокируй конфликт.** Приоритет: подтверждённое решение пользователя → `docs/rules.md` → `docs/arch.md` → релевантные карточки. При конфликте или необоснованном отклонении от примера применимой карточки не поручай реализацию: спроси, адаптировать план, вернуться к `eda-plan` или отдельно изменить документацию.
-7. **Отмечай только подтверждённое.** Ставь задаче `[x]` только после `completed` от исполнителя и успешных обязательных проверок задачи. Фазу закрывай только после отдельного `passed` от проверяющего фазы. При последующем опровержении верни отметку в незавершённое состояние.
-8. **Проверки нельзя подавлять.** Не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, добавлять игноры или ослаблять команды и правила. Причину падения исправляет отдельный субагент, затем новый субагент повторяет проверку.
-9. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
+2. **Фазы выполняй строго последовательно.** Не запускай следующую фазу, пока исполнитель текущей не завершил все её задачи и отдельная проверка фазы не прошла.
+3. **Одна фаза — один исполнитель.** Запускай каждую фазу целиком в новом субагенте со свежим контекстом без истории диалога. Сохраняй идентификатор исполнителя и продолжай его же для вопросов и исправлений этой фазы, пока среда позволяет.
+4. **Рамку читает исполнитель фазы.** Каждый исполнитель целиком читает план, `docs/rules.md`, `docs/arch.md` и индекс `docs/references.md`, если файлы существуют. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, исполнитель читает эту карточку целиком перед соответствующим изменением.
+5. **Соблюдай приоритет и блокируй конфликт.** Приоритет: подтверждённое решение пользователя → `docs/rules.md` → `docs/arch.md` → релевантные карточки. При конфликте или необоснованном отклонении от примера применимой карточки исполнитель возвращает `blocked`, а основной агент спрашивает, адаптировать план, вернуться к `eda-plan` или отдельно изменить документацию.
+6. **Отмечай только подтверждённое.** Ставь задаче `[x]` только после `completed` от исполнителя и успешной точечной проверки. Фазу закрывай только после отдельного `passed` от проверяющего фазы. При последующем опровержении верни отметку в незавершённое состояние.
+7. **Проверки нельзя подавлять.** Не поручай отключать линтеры, тесты, typecheck, static analysis и другие проверки, добавлять игноры или ослаблять команды и правила. Причину падения исправляет исполнитель соответствующей фазы, затем отдельный субагент повторяет проверку.
+8. **Не коммить, не пушь и не делай ревью.** Это другие скилы.
 
 ## Интерактивные вопросы
 
@@ -53,19 +52,16 @@ description: 'Управляет выполнением готового пла
 
 Сам git-команды не выполняй. Для выбранной новой ветки или worktree запусти отдельного изолированного субагента подготовки окружения. Передай ему только выбранный вариант, slug плана, рабочую директорию и запрет менять код. Если выбран worktree, после успешного создания остановись и дай готовую команду перехода и нового запуска `eda-plan-execute <PLAN_FILE>`: текущая сессия не переезжает в другую директорию.
 
-### 3. Прочитать рамку и построить граф
+### 3. Прочитать план и проверить фазы
 
-Прочитай `$PLAN_FILE`, `docs/rules.md` и `docs/arch.md`, если они есть. Прочитай перечисленные в `sources.references` карточки. Для старого плана без поля прочитай индекс `docs/references.md` и выбери только карточки для затронутых компонентов.
-
-Для каждой фазы извлеки задачи, ID, прямые зависимости, поле `Параллельно`, ожидаемый результат, сценарии тестирования и проверки. До запуска проверь:
+Прочитай `$PLAN_FILE`. Для каждой фазы извлеки задачи, ID, прямые зависимости, ожидаемый результат, сценарии тестирования и проверки. До запуска проверь:
 
 - все ID уникальны, а ссылки ведут на существующие задачи;
 - зависимости не образуют цикл и не ведут в будущую фазу;
-- параллельность симметрична и не противоречит зависимостям;
-- параллельные задачи не меняют одни файлы или участки, общий контракт, одну миграционную цепочку, общие генерируемые артефакты или иное изменяемое состояние;
-- шаги не конфликтуют с правилами, архитектурой и применимыми карточками;
 - у каждой фазы есть проверяемый результат и команда либо критерий проверки.
 
+Поля `Параллельно` в старых планах не влияют на исполнение: все задачи фазы выполняет один субагент по зависимостям.
+
 Если граф неоднозначен или небезопасен, не исправляй смысл плана молча. Используй `AskUserQuestion` с предложением вернуть план в `eda-plan` или `eda-plan-polish`.
 
 ### 4. Инициализировать прогресс
@@ -89,7 +85,7 @@ current_phase: <номер>
 |---|---|---|---|
 
 ## Запуски субагентов
-| Время | Роль | Задача | Результат | Файлы | Проверки |
+| Время | Роль | Фаза | Результат | Файлы | Проверки |
 |---|---|---|---|---|---|
 
 ## Решения и блокеры
@@ -103,22 +99,26 @@ current_phase: <номер>
 
 В Codex используй `spawn_agent` с `fork_turns: "none"` или точный аналог. В Claude Code используй новый `Agent` с самодостаточным task-сообщением. Если чистая изоляция или субагенты недоступны, остановись с `blocked: недоступно изолированное выполнение`; не выполняй работу основным агентом и не добавляй CLI-fallback.
 
-Каждому исполнителю задачи передай только:
+Каждому исполнителю фазы передай:
 
-- рабочую директорию, `$PLAN_FILE`, ID и полный текст одной задачи;
-- цель и критерии готовности текущей фазы;
-- прямые зависимости и краткие результаты уже завершённых зависимостей;
-- пути к `docs/rules.md`, `docs/arch.md`, применимым карточкам и другим явно нужным источникам;
-- команды или критерии проверки этой задачи;
-- ограничения пользователя, запрет коммитить и запрет менять план и журнал.
+- рабочую директорию, `$PLAN_FILE`, номер и полный текст текущей фазы;
+- краткие результаты уже завершённых фаз;
+- пути к `docs/rules.md`, `docs/arch.md` и `docs/references.md`;
+- ограничения пользователя, команды и критерии проверки фазы, запрет коммитить и запрет менять план и журнал.
 
-Исполнитель сам читает переданные файлы, исследует нужный код, реализует только назначенную задачу и выполняет её точечные проверки. Требуй YAML-результат:
+Исполнитель целиком читает `$PLAN_FILE`, `docs/rules.md` и `docs/arch.md`, затем выполняет все задачи назначенной фазы по прямым зависимостям. Если выполнение фазы затрагивает компонент, для которого в `docs/references.md` указана карточка, исполнитель читает эту карточку целиком перед соответствующим изменением. После каждой задачи он выполняет её точечные проверки, а в конце — все проверки фазы. Требуй YAML-результат:
 
 ```yaml
 status: completed | needs_input | failed | blocked
-task: <ID>
+phase: <номер>
 summary: <что сделано>
+tasks:
+  - id: <ID>
+    status: completed | failed | blocked
+    summary: <кратко>
+    checks: [<результаты точечных проверок>]
 files_changed: [<пути>]
+references_read: [<пути или пусто>]
 checks:
   - command: <команда или критерий>
     status: passed | failed | not_run
@@ -128,26 +128,22 @@ risks: [<остаточные риски или пусто>]
 questions: [<вопросы или пусто>]
 ```
 
-Не принимай `completed`, если обязательная проверка задачи не прошла, исполнитель вышел за назначенный scope, молча отклонился от рамки или изменил план/журнал.
+Не принимай `completed`, если хотя бы одна задача или обязательная проверка фазы не прошла, исполнитель вышел за назначенный scope, молча отклонился от рамки или изменил план/журнал.
 
-### 6. Выполнять фазы волнами
+### 6. Выполнять фазы
 
 Для каждой фазы по порядку:
 
-1. Вычисли готовые задачи: все их прямые зависимости уже отмечены выполненными.
-2. Из готовых задач собери максимальную безопасную волну по взаимным полям `Параллельно` и отсутствию пересечений. Не включай задачу в параллельную волну только по догадке, если план не разрешает параллельность явно.
-3. Запусти всех исполнителей волны одновременно одним batch до чтения отдельных результатов. Если лимит среды меньше размера волны, используй максимально доступное число слотов и запускай остаток сразу после освобождения слотов.
-4. После завершения каждого исполнителя проверь контракт, фактический scope файлов и результат точечных проверок. Запиши запуск в журнал и поставь `[x]` только успешной задаче.
-5. `needs_input` передай пользователю одним блокирующим вопросом и после ответа продолжи ту же задачу новым изолированным субагентом с ответом и предыдущим результатом.
-6. Для `failed` запусти нового изолированного субагента исправления этой же задачи. Передай исходную задачу, полный неуспешный результат и актуальное состояние файлов. После исправления новый субагент должен повторить точечную проверку. Если две попытки подряд возвращают ту же причину без содержательного изменения результата, остановись с `blocked: выполнение не сходится` и зафиксируй доказательства вместо бесконечного цикла.
-7. Для `blocked` останови зависимые задачи. Если блокер внешний или требует изменения scope, задай вопрос; основной агент не устраняет его содержательно.
-8. Когда волна завершена, пересчитай готовые задачи. Не переходи к следующей фазе, пока текущая не закрыта.
-
-Если параллельные исполнители неожиданно пересеклись по файлам или контракту, не объединяй результаты вслепую. Останови затронутые задачи, запиши конфликт и запусти отдельного субагента для диагностики и безопасного согласования изменений.
+1. Запусти одного нового изолированного исполнителя и сохрани его идентификатор как исполнителя этой фазы.
+2. После ответа проверь YAML-контракт, фактический scope файлов и результаты точечных и фазовых проверок. Запиши запуск в журнал и поставь `[x]` только задачам со статусом `completed` и успешными точечными проверками.
+3. `needs_input` передай пользователю одним блокирующим вопросом. После ответа продолжи того же исполнителя фазы с ответом и его предыдущим результатом. Если среда не умеет продолжать завершённого субагента, запусти нового изолированного исполнителя этой же фазы и передай ему полный предыдущий результат.
+4. Для `failed` продолжи того же исполнителя фазы с полным неуспешным результатом и поручением исправить причину и повторить проверки. Если две попытки подряд возвращают ту же причину без содержательного изменения результата, остановись с `blocked: выполнение не сходится` и зафиксируй доказательства вместо бесконечного цикла.
+5. Для `blocked` останови выполнение. Если блокер внешний или требует изменения scope, задай вопрос; основной агент не устраняет его содержательно.
+6. После `completed` запусти независимую проверку фазы. Не переходи к следующей фазе, пока текущая не закрыта.
 
 ### 7. Проверять каждую фазу
 
-После выполнения всех задач фазы запусти нового изолированного субагента-проверяющего. Он не меняет файлы, читает итог фазы, выполняет все проверки из раздела фазы и подтверждает критерии результата. Требуй YAML:
+После `completed` от исполнителя запусти нового изолированного субагента-проверяющего. Он не меняет файлы, целиком читает план, `docs/rules.md`, `docs/arch.md` и индекс `docs/references.md`, если они существуют. Если итог фазы затрагивает компонент, для которого в индексе указана карточка, проверяющий читает её целиком. Затем он выполняет все проверки из раздела фазы и подтверждает критерии результата. Требуй YAML:
 
 ```yaml
 status: passed | failed | blocked
@@ -157,29 +153,29 @@ checks:
     status: passed | failed
     result: <кратко>
 failures: [<проблемы с доказательствами или пусто>]
+references_read: [<пути или пусто>]
 ```
 
-При `failed` сопоставь проблемы с задачами и запусти по каждой отдельного изолированного субагента исправления. Затем запусти нового проверяющего всей фазы. Основной агент не чинит код и не переиспользует контекст прежнего проверяющего. При `passed` отметь фазу завершённой и только тогда переходи к следующей.
+При `failed` передай полный результат проверки исполнителю этой фазы и поручи исправить все подтверждённые проблемы, затем запусти нового проверяющего всей фазы. Если продолжить прежнего исполнителя невозможно, запусти одного нового изолированного исполнителя для исправления всей фазы с её полным контекстом. Основной агент не чинит код и не переиспользует контекст прежнего проверяющего. При `passed` отметь фазу завершённой и только тогда переходи к следующей.
 
 ### 8. Выполнить финальную проверку
 
-После всех фаз запусти отдельного нового субагента для полного набора тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Он только проверяет и не меняет файлы.
+После всех фаз запусти отдельного нового субагента для полного набора тестов, линтеров, typecheck, static analysis и других обязательных команд проекта. Он только проверяет и не меняет файлы, целиком читает план, `docs/rules.md`, `docs/arch.md` и индекс `docs/references.md`, если они существуют. Если итоговые изменения затрагивают компонент, для которого в индексе указана карточка, проверяющий читает её целиком перед оценкой соответствующего результата.
 
-Если финальная проверка упала из-за сделанных изменений, запусти изолированных субагентов исправления по независимым группам ошибок, затем повтори всю финальную проверку новым субагентом. Чужую или несвязанную поломку зафиксируй и используй `AskUserQuestion`, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
+Если финальная проверка упала из-за сделанных изменений, сопоставь ошибки с фазами и передай каждую группу исполнителю соответствующей фазы; несколько затронутых фаз исправляй по порядку плана. Если продолжить прежнего исполнителя невозможно, запусти одного нового изолированного исполнителя для каждой затронутой фазы. Затем повтори всю финальную проверку новым субагентом. Чужую или несвязанную поломку зафиксируй и используй `AskUserQuestion`, если без решения нельзя завершить план. Запрещено делать проверки зелёными через подавление ошибок, игноры, исключения, ослабление конфигов или изменение команд проверки.
 
 Запиши команды и результаты в `## Финальная проверка`. Только после `passed` поставь в журнале `status: done` и время завершения. Если обязательная проверка объективно недоступна, сохрани `status: blocked`, причину и непройденные критерии; не выдавай план за выполненный.
 
 ### 9. Финал
 
-Коротко сообщи пути к плану и журналу, завершённые фазы и задачи, какие волны выполнялись параллельно, результат фазовых и финальной проверок, оставшиеся блокеры, состояние git «не закоммичено» и следующий шаг: `eda-review` или `eda-commit`.
+Коротко сообщи пути к плану и журналу, завершённые фазы и задачи, результат фазовых и финальной проверок, оставшиеся блокеры, состояние git «не закоммичено» и следующий шаг: `eda-review` или `eda-commit`.
 
 ## Чего НЕ делать
 
 - Самому менять код, тесты, миграции, конфиги, зависимости или проектную документацию.
 - Самому запускать тесты, линтеры, typecheck, сборку, миграции, серверы или другие команды разработки и проверки.
-- Передавать одному субагенту несколько независимых задач только ради экономии запусков.
+- Дробить одну фазу между несколькими исполнителями или поручать одному исполнителю несколько фаз.
 - Запускать следующую фазу до успешной отдельной проверки текущей.
-- Запускать параллельно задачи без явной безопасной маркировки плана или с пересечением изменяемых ресурсов.
 - Давать субагентам историю диалога или разрешать им менять план и журнал.
 - Исправлять падение основным агентом либо продолжать после него без повторной проверки новым субагентом.
 - Подавлять ошибки проверок, ослаблять правила или менять команды ради зелёного результата.

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

@@ -1,6 +1,6 @@
 ---
 name: eda-plan-polish
-description: 'Полирует готовый план из `docs/plans/...` до оценки 95/100 или заданного порога. Каждая итерация запускает три изолированных параллельных агента, которые читают правила, архитектуру, `sources.references`, research и релевантный код. В strict дополнительно запускает кросс-CLI ревью. Основной агент оценивает ответы, принимает или отклоняет предложения, содержательно правит только файл плана, не меняет код и не запускает проверки.'
+description: 'Проверяет и улучшает готовый план реализации итерациями до заданной оценки.'
 ---
 
 # Скил: Полировка плана (eda-plan-polish)
@@ -81,7 +81,7 @@ description: 'Полирует готовый план из `docs/plans/...` д
 ```text
 Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references, sources.research при наличии и релевантные файлы, на которые ссылается план. Если sources.references отсутствует, прочитай docs/references.md и выбери только применимые карточки.
 
-Проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и применимым эталонам, обоснованность отклонений от примеров, полноту целевого алгоритма, БД/API/внешние контракты, фазы, тестовые сценарии, логирование, неподтверждённые решения, скрытые риски и места, где eda-plan-execute не сможет продолжить без нового исследования.
+Проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и применимым эталонам, обоснованность отклонений от примеров, полноту целевого алгоритма, БД/API/внешние контракты, связность и размер фаз для одного исполнителя на фазу, тестовые сценарии, логирование, неподтверждённые решения, скрытые риски и места, где eda-plan-execute не сможет продолжить без нового исследования.
 
 Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы.
 
@@ -100,13 +100,13 @@ score: <0–100>
 Если ты в Claude Code — запускай Codex CLI:
 
 ```bash
-codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references, sources.research при наличии и релевантные файлы, на которые ссылается план. Если sources.references отсутствует, выбери применимые карточки через docs/references.md. Глубоко проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и эталонам, обоснованность отклонений, полноту целевого алгоритма, БД/API/внешние контракты, фазы, тесты, логирование, неподтверждённые решения и скрытые риски. Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы. Ответь кратко: score: <0–100>; + Принять; ~ Уточнить; -- Убрать; ? Вопрос." > "${PLAN_FILE%.md}_strict_cli_review.md"
+codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references, sources.research при наличии и релевантные файлы, на которые ссылается план. Если sources.references отсутствует, выбери применимые карточки через docs/references.md. Глубоко проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и эталонам, обоснованность отклонений, полноту целевого алгоритма, БД/API/внешние контракты, связность и размер фаз для одного исполнителя на фазу, тесты, логирование, неподтверждённые решения и скрытые риски. Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы. Ответь кратко: score: <0–100>; + Принять; ~ Уточнить; -- Убрать; ? Вопрос." > "${PLAN_FILE%.md}_strict_cli_review.md"
 ```
 
 Если ты в Codex — запускай Claude CLI:
 
 ```bash
-claude -p "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references, sources.research при наличии и релевантные файлы, на которые ссылается план. Если sources.references отсутствует, выбери применимые карточки через docs/references.md. Глубоко проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и эталонам, обоснованность отклонений, полноту целевого алгоритма, БД/API/внешние контракты, фазы, тесты, логирование, неподтверждённые решения и скрытые риски. Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы. Ответь кратко: score: <0–100>; + Принять; ~ Уточнить; -- Убрать; ? Вопрос." > "${PLAN_FILE%.md}_strict_cli_review.md"
+claude -p "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references, sources.research при наличии и релевантные файлы, на которые ссылается план. Если sources.references отсутствует, выбери применимые карточки через docs/references.md. Глубоко проверь весь план целиком: исполнимость, соответствие правилам, архитектуре и эталонам, обоснованность отклонений, полноту целевого алгоритма, БД/API/внешние контракты, связность и размер фаз для одного исполнителя на фазу, тесты, логирование, неподтверждённые решения и скрытые риски. Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы. Ответь кратко: score: <0–100>; + Принять; ~ Уточнить; -- Убрать; ? Вопрос." > "${PLAN_FILE%.md}_strict_cli_review.md"
 ```
 
 Если соседней CLI нет — `AskUserQuestion`: продолжить как `normal` без кросс-CLI или прервать полировку. Не заменяй кросс-CLI четвёртым локальным субагентом.
@@ -124,6 +124,7 @@ claude -p "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карто
 - `Целевой алгоритм` описывает сквозное поведение;
 - `Контракты реализации` конкретны, особенно БД/API/внешние контракты;
 - фазы имеют цель, шаги, результат, сценарии тестирования и проверку;
+- каждая фаза связна и выполнима одним агентом за один проход;
 - `test_strategy` и `logging_strategy` отражены в фазах и разделах;
 - нет альтернатив вида «выбрать», «решить», «уточнить позже»;
 - план можно передать в `eda-plan-execute` без нового исследования.

package/skills/eda-polish/SKILL.md

@@ -1,11 +1,12 @@
 ---
 name: eda-polish
-description: 'Автономно доводит изменения до заданной оценки: в каждой итерации запускает полное `eda-review`, затем `eda-fix-by-review apply-optional` и повторяет цикл до порога или лимита. Все обязательные замечания исправляются, optional-пункты fix-агент применяет или отклоняет с причиной. По умолчанию цель — 95/100, лимит — 5 итераций. Каждый шаг идёт в изолированном субагенте. Не делает ревью или правки основным агентом и не коммитит.'
+description: 'Итеративно ревьюит и исправляет изменения до заданной оценки качества.'
 ---
 
 # Скил: Полировка изменений (eda-polish)
 
 Оркестрируй цикл `eda-review` → `eda-fix-by-review apply-optional` → повторное `eda-review`. Основной агент только управляет итерациями, читает сохранённые артефакты и сообщает результат.
+В начале каждой итерации запускай полное `eda-review` целевого изменения.
 
 ## Вход из сообщения пользователя
 

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

@@ -1,6 +1,6 @@
 ---
 name: eda-prepare-ai
-description: 'Проектирует или актуализирует архитектуру, строгие правила, профиль инструментов, автоматические проверки и AI-процесс проекта, затем создаёт `docs/rules.md`, `docs/arch.md`, индекс и карточки `docs/references/`, компактный `AGENTS.md` и минимальный `CLAUDE.md`. Для нового проекта принимает подтверждённый бриф eda-new-project как источник требований, стека и архитектурных драйверов. Подбирает применимые AI-скилы, агентные роли и MCP, но не пишет код, не меняет конфиги и не ставит зависимости.'
+description: 'Готовит проект к работе с AI: проектирует архитектуру, правила, проверки, references и агентный процесс.'
 ---
 
 # Скил: Подготовка проекта для AI (eda-prepare-ai)

package/skills/eda-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-review
-description: 'Оркестрирует полное read-only ревью diff, ветки, PR/MR, коммита, папки или файла через отдельные packaged-агенты correctness, architecture, rules, references, plan alignment, code quality, tests, security, performance, frontend, API, database, documentation и previous reviews. Выбирает применимые проверки по конфигу, объединяет только подтверждённые проблемы, ставит оценку 0–100 и сохраняет итог в docs/reviews/. Не правит код и не запускает другой CLI.'
+description: 'Проводит полное read-only ревью diff, ветки, PR/MR, коммита, папки или файла и сохраняет итоговый отчёт.'
 ---
 
 # Скил: Ревьюер (eda-review)

package/skills/eda-roadmap/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: eda-roadmap
-description: 'Создаёт roadmap-файл по продуктовой или технической теме: собирает из сообщения пользователя цель, ограничения и список задач, формулирует задачи коротко, понятно и недвусмысленно, без деталей реализации, файлов, библиотек, API и пошагового плана. При необходимости читает docs/rules.md, docs/arch.md и существующие docs/roadmaps/. Задаёт вопросы только если без ответа нельзя составить корректный список задач. Итог сохраняет в docs/roadmaps/. Не исследует глубоко, не планирует реализацию и не меняет код.'
+description: 'Создаёт продуктовый или технический roadmap как список будущих задач без деталей реализации.'
 ---
 
 # Скил: Roadmap (eda-roadmap)

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

@@ -1,6 +1,6 @@
 ---
 name: eda-send-review
-description: 'Отправляет готовое ревью из `docs/reviews/...` на GitHub PR через `gh`: сводку в теле review и замечания комментариями к строкам. Явный `comment`/`approve`/`request-changes` берёт из контекста текущего вызова, без него сразу использует `comment` независимо от score. По умолчанию отправляет все пункты, а по контексту — указанное подмножество. Настройка `send-review.close_previous_reviews` позволяет после успешной отправки скрыть предыдущие сводки eda-send-review и зарезолвить связанные inline-треды; текущий запрос может её переопределить. PR определяет из текста или текущей ветки, после отправки дописывает ссылку в файл. Не правит код и не делает новое ревью.'
+description: 'Публикует готовое ревью из `docs/reviews/` в GitHub PR как сводку и inline-комментарии.'
 ---
 
 # Скил: Отправитель ревью (eda-send-review)

package/skills/eda-worktree/SKILL.md

@@ -1,15 +1,17 @@
 ---
 name: eda-worktree
-description: 'Оркестрирует создание нового git worktree через пакетного агента на `haiku` / `gpt-5.6-luna`. Worktree создаётся рядом с основным проектом в папке `{name}-work-{n}` с одноимённой веткой. Базовую ветку берёт из текста рядом с вызовом, если она указана, иначе спрашивает интерактивно. Не правит код, не коммитит и не мержит обратно.'
+description: 'Создаёт новый соседний git worktree и одноимённую ветку для изолированной работы.'
 ---
 
 # Скил: Создатель worktree (eda-worktree)
 
 Работай как лёгкий оркестратор установленного агента `eda-worktree-executor`. Сам не исследуй git-состояние, не выбирай имя или базу и не выполняй команды.
+Создаваемые директория и ветка используют шаблон `{name}-work-{n}`.
 
 ## Вход из сообщения пользователя
 
 Сохрани весь текст текущего сообщения дословно в `$USER_REQUEST`. Это главный вход: базовая ветка или ref, ограничения и прямые указания.
+Базовую ветку берёт из текста рядом с вызовом исполнитель; если она не указана, он возвращает вопрос.
 
 Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно. При последующем ответе на вопрос сохрани исходный `$USER_REQUEST` и передай ответ отдельно.