@gian-tiaga/eda 0.8.6 → 1.0.1

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

@@ -0,0 +1,184 @@
+---
+name: eda-discover-automations
+description: 'Проводит экстремально широкий аудит автоматических проверок проекта и анализирует историю `docs/reviews/`, `docs/review-fixes/`, `docs/fixes/`, опционально `docs/plans/`. Перечисляет пробелы в тестах, e2e, стиле, статанализе, архитектурных границах, конфигах, безопасности, данных, производительности, релизах, browser MCP и MCP выбранного стека. Сначала предлагает детерминированные CLI/CI-проверки, затем MCP или агентные усиления. Не внедряет изменения — сохраняет приоритетный отчёт с командами и контурами запуска в `docs/automations/`.'
+---
+
+# Скил: Поиск автоматизаций (eda-discover-automations)
+
+Читаешь историю ревью и фиксов, находишь ошибки, ручные правки и недостающие проверки, которые полезно предотвращать автоматически.
+
+## Режим запуска
+
+Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
+
+Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолт: `discover-automations.include_plans: false`.
+
+Если актуального раздела `discover-automations` нет, но есть прежний раздел `automate`, используй `automate.include_plans` как совместимый fallback и сообщи, что настройку следует переименовать. Если присутствуют оба раздела, применяй только `discover-automations`.
+
+| Настройка | Значения | Аргументы в сообщении |
+|---|---|---|
+| `discover-automations.include_plans` | `true`, `false` | `plans`, «с планами»; выключение: `normal`, «без планов» |
+
+Обычный режим анализирует текущий проект и, если они есть, `docs/reviews/`, `docs/review-fixes/`, `docs/fixes/`. Режим `discover-automations.include_plans: true` добавляет `docs/plans/`. Отсутствие истории не отменяет полный аудит текущих проверок.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+
+Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Общие ограничения
+
+1. **Не внедряешь изменения.** Только отчёт с предложениями. Внедрение автоматизаций, MCP-серверов, новых скилов или правок `docs/rules.md`/`docs/arch.md` — через `eda-plan` + `eda-plan-execute`.
+2. **Повторяемость — сигнал, а не обязательное условие.** Единичную ошибку тоже предлагай закрыть, если у неё высокий ущерб, она может повториться, а проверка будет надёжной и оправданной по стоимости. Не автоматизируй малозначимые замечания только ради полноты отчёта.
+3. **Полнота каталога обязательна.** Не вводи лимит количества предложений и не останавливайся на привычном наборе `lint + unit`. Проверь каждую группу, поставь статус `покрыто` / `предложено` / `не применимо`; для `не применимо` запиши конкретную причину.
+4. **Детерминированная проверка приоритетнее AI/MCP.** MCP и агентные проверки дополняют CLI/CI только там, где нужен браузер, внешняя система или контекст, недоступный локальному инструменту.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
+
+## Этапы
+
+### 1. Выбрать диапазон
+Определи режим и диапазон по текущему сообщению и `docs/settings.yaml`. Без вопроса используй вход, если он задаёт `plans` / `normal`, последние N, период или конкретные файлы/папки. Если диапазон не указан, но источники есть, используй все ревью + фиксы по ревью + обычные фиксы по умолчанию.
+
+Если вход неоднозначен — `AskUserQuestion`: все ревью и фиксы / все ревью, фиксы и планы / последние N / период / конкретные файлы.
+
+Получи список файлов из `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`. Отсутствующие или пустые папки отметь в отчёте, но не блокируйся: проведи baseline gap-аудит по коду, manifest-файлам, конфигам, scripts и CI текущего проекта.
+
+### 2. Прочитать контекст
+- Все выбранные ревью, отчёты о фиксах по ревью и обычные фиксы.
+- В режиме `plans`: все выбранные планы из `docs/plans/`.
+- `docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
+- Какие языки и фреймворки в проекте — определи сам.
+- Какие инструменты качества уже установлены и работают: линтеры, форматтеры, статанализаторы, typecheck, все виды тестов, coverage, архитектурные проверки, валидаторы конфигов, security/supply-chain сканеры, performance budgets, pre-commit, CI, release/post-deploy проверки и npm/composer/make-скрипты.
+- Какие агентные усиления уже есть: `.claude/skills/`, `.codex/skills/`, MCP-конфиги, локальные скилы, команды для ревью/планирования. Не предлагай дубль уже установленному.
+
+### 3. Найти кандидатов на автоматизацию
+Сгруппируй замечания по сути, затем независимо от истории пройди экстремальный каталог:
+
+1. **Тесты поведения:** unit, integration, component, contract/consumer-driven contract, API, e2e, smoke, acceptance, regression, negative и edge-case.
+2. **Глубокое тестирование:** property-based, mutation, fuzz, differential, metamorphic, snapshot/golden, repeatability и flaky-test detection.
+3. **UI и браузер:** browser e2e, visual regression, accessibility, keyboard/focus, responsive, cross-browser/device, hydration, broken links, формы/uploads, locale/timezone и browser-console errors.
+4. **Стиль и качество:** formatter, linter, naming, complexity, duplication, dead code, unused exports/dependencies, forbidden patterns, TODO/FIXME policy и лимиты размера.
+5. **Статический анализ:** typecheck, nullability, data-flow/taint, API misuse, unreachable code, unsafe/undefined behavior, memory/thread/address sanitizers и анализаторы выбранного языка.
+6. **Границы кода:** forbidden imports, dependency direction, cycles, layers, public API, ownership, package/module boundaries, generated-code boundaries и architecture fitness functions.
+7. **Конфиги и инфраструктура:** schema/parse для env, YAML/JSON/TOML, CI, Docker/Compose, Kubernetes/Helm, Terraform/IaC, proxy, feature flags, IAM, observability и env-example drift.
+8. **API и совместимость:** OpenAPI/GraphQL/Proto, breaking changes, generated-code drift, serialization, backward/forward compatibility, idempotency, pagination/filter/sort.
+9. **БД и данные:** migration lint/forward/rollback/dry-run, schema drift, constraints, fixtures, transactions, concurrency, query plans/N+1, backup/restore, retention/anonymization и data invariants.
+10. **Безопасность и supply chain:** secrets, SAST, DAST, dependency/container/IaC scan, licenses, SBOM, lockfile integrity, provenance/signatures, authn/authz negative tests, injection, XSS/CSRF/SSRF, CORS/CSP/headers, rate limits и PII leakage.
+11. **Производительность и надёжность:** benchmarks/budgets, bundle size, load/stress/spike/soak, leaks, startup, timeouts/retries/circuit breakers, graceful shutdown, fault injection/chaos и recovery.
+12. **Сборка и релиз:** clean-clone/reproducible build, generated artifacts, package contents, runtime/OS/architecture matrix, install/upgrade/downgrade, semver/changelog, release dry-run, canary/rollback и post-deploy smoke.
+13. **Документация:** Markdown/style/spell, links, executable snippets, CLI help/API docs drift, diagrams/schemas и migration/release notes.
+14. **Эксплуатация:** health/readiness/liveness, metrics/log/trace schemas, no secrets/PII in logs, alert rules, dashboards as code, SLO/error budgets, disaster recovery и restore drills.
+15. **Доменные проверки:** платежи, почта, очереди, jobs, webhooks, поиск, файлы/media, mobile signing, offline/sync, localization, analytics events и другие инварианты продукта.
+16. **AI-функции:** prompt/output schemas, evals, prompt injection/jailbreak, data leakage, tool permissions, nondeterminism, latency и token/cost budgets.
+17. **MCP:** browser/Playwright MCP для сценариев и визуальных доказательств; MCP для БД, API, документации, GitHub/GitLab, cloud, observability и выбранного языка/фреймворка. Укажи точный сценарий, минимальные права и почему CLI/CI недостаточно.
+18. **Агентный процесс и планы:** чтение обязательных источников, формат артефактов, проверка критериев готовности, файлов/модулей и зависимостей задач, rollback/backup для рискованных действий, запрет пропуска команд и повторяющиеся ошибки агентов.
+
+Для каждого паттерна собери: доказательство из истории либо baseline-пробел в текущем проекте, затронутые файлы, возможный ущерб, вероятность, надёжность проверки и стоимость внедрения. Повторяющиеся паттерны обычно приоритетнее, но не отбрасывай сильного кандидата из-за одного случая или потому, что ошибка ещё не произошла.
+
+### 4. Предложить автоматизации и правки docs
+Для каждого паттерна выбери одну или несколько недублирующих реакций: `automation`, `tests`, `tooling`, `agent`, `rules`, `architecture`.
+
+**Сначала программная проверка.** Для каждого паттерна сначала оцени автоматизации на уровне языка и тулчейна: можно ли поймать его линтером, статанализатором, typecheck, тестом, pre-commit/CI-скриптом или валидатором. Агентные решения предлагай только если программная проверка невозможна, слишком дорогая или требует лучшего контекста для AI-агента.
+
+Приоритет реакций:
+1. `automation` — правило линтера, статанализатора, typecheck, custom validator, pre-commit/CI/check-скрипт.
+2. `tests` — конкретный unit/integration/contract/e2e/regression-тест или тестовый helper, который ловит этот класс багов.
+3. `tooling` — новый или донастроенный инструмент качества, если в проекте нет подходящего и инструмент стандартный для стека.
+4. `agent` — MCP-сервер, новая/обновлённая eda-инструкция, специализированная агентная проверка или обязательный источник контекста. Предлагай только когда это закрывает значимую ошибку AI-процесса или даёт агенту данные, которые нельзя надёжно получить из кода.
+5. `rules` / `architecture` — текстовые правила и архитектурные уточнения, если проблема связана с договорённостью, границей модулей или ownership.
+
+Предпочитай уже установленный инструмент, если он ловит этот класс проблем. Новый инструмент предлагай только если он не дублирует инструмент того же класса. Для проблем из планов предлагай проверку `docs/plans/*.md`, а не runtime-линтер кода. Если правило или архитектура уже зафиксированы, не дублируй текст; предложи только уточнение, которое закрывает найденный случай.
+
+Подменять линтер, статанализатор или тест MCP-сервером/скилом нельзя, если ошибку можно надёжно поймать программной проверкой.
+
+Для каждой программной проверки укажи точный инструмент, команду/сценарий и контур: `pre-commit`, `pre-push`, `PR CI`, `nightly`, `release`, `post-deploy`. Быстрые проверки отдели от тяжёлых. Для MCP укажи сервер/класс инструмента, проверяемый сценарий, минимальные права, тестовые данные и контур `MCP/manual`; MCP не называй автоматической CI-проверкой, если он реально не запускается без участия агента.
+
+### 5. Сохранить отчёт
+`docs/automations/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Slug — короткое описание набора (например, `php-strict-rules`).
+
+```markdown
+---
+date: <YYYY-MM-DD HH:MM>
+sources: [docs/reviews/..., docs/review-fixes/..., docs/fixes/...]
+mode: <normal | plans>
+status: draft
+---
+
+# Предложения по автоматизации
+
+## Контекст
+- Проанализировано: N ревью + M фиксов по ревью + F обычных фиксов + K планов
+- Стек проекта: <по конфигам>
+- Уже работающие инструменты: <список>
+- Уже найденные скилы/MCP/агентные проверки: <список или «не найдены»>
+
+## Покрытие экстремального каталога
+| Группа | Уже есть | Пробелы | Статус | Причина N/A |
+|---|---|---|---|---|
+| Тесты поведения | ... | ... | covered / proposed / not_applicable | ... |
+
+## Проверки кода и тесты
+
+### 1. <название паттерна>
+- **Тип:** automation / tests / tooling
+- **Что ловит:** ...
+- **Встречалось в:** `docs/reviews/...` (×1), `docs/reviews/...` (×2)
+- **Почему автоматизировать:** <повторяемость либо высокий ущерб и вероятность повторения>
+- **Инструмент:** <название или текущий test runner> (если новый для проекта — пометка «требует установки»)
+- **Команда / сценарий:** <точная команда, glob, правило или тестовый сценарий>
+- **Где запускать:** pre-commit / pre-push / PR CI / nightly / release / post-deploy
+- **Черновик:**
+  ```<язык>
+  <псевдокод/skeleton>
+  ```
+- **Польза:** low/medium/high
+
+### 2. ...
+
+## Агентные усиления
+
+### 1. <название паттерна>
+- **Тип:** agent
+- **Что закрывает:** <какую ошибку процесса или нехватку контекста>
+- **Встречалось в:** `docs/reviews/...` (×1), `docs/fixes/...` (×1)
+- **Почему автоматизировать:** <повторяемость либо высокий ущерб и вероятность повторения>
+- **Предложение:** MCP-сервер / новый eda-скил / правка существующего скила / специализированная агентная проверка
+- **Сценарий и доступ:** <что проверяет, минимальные права, тестовые данные, почему CLI/CI недостаточно>
+- **Черновик:**
+  ```markdown
+  <конфиг, описание скила или инструкция агентной проверки>
+  ```
+- **Польза:** low/medium/high
+
+## Правила и архитектура
+
+### 1. <название паттерна>
+- **Тип:** rules / architecture
+- **Куда:** `docs/rules.md` / `docs/arch.md`, раздел <название или «новый раздел»>
+- **Почему:** <какой паттерн закрывает>
+- **Встречалось в:** `docs/fixes/...` (×1), `docs/reviews/...` (×1)
+- **Черновик текста:**
+  ```markdown
+  <готовый фрагмент для docs/rules.md или docs/arch.md>
+  ```
+- **Польза:** low/medium/high
+
+## Приоритезация
+| # | Тип | Паттерн | Польза | Приоритет |
+|---|-----|---------|--------|-----------|
+| 1 | automation | ... | high | 1 |
+
+## Рекомендация
+<какие 1–3 внедрить первыми и почему — простыми словами>
+```
+
+### 6. Финал
+Короткое сообщение: путь к отчёту, сколько групп каталога покрыто/предложено/неприменимо, общее число предложений и их распределение по контурам, сколько MCP/агентных усилений и правок docs, топ-3 рекомендации простыми словами, подсказка дальше — «хочешь внедрить → `eda-plan` для плана, потом `eda-plan-execute`».

package/skills/{eda-explore.md → eda-explore/SKILL.md}

@@ -1,6 +1,6 @@
 ---
 name: eda-explore
-description: 'Исследует тему или задачу до конкретного результата: проясняет проблему, архитектуру, развилки, риски и короткий выбранный вариант решения без плана реализации. Работает read-only и ведёт исследование как диалог: факты собирает сам, а значимые развилки выносит пользователю по `defaults.decision_mode` из `docs/settings.yaml`. Если исследование касается пакетов, библиотек, CLI, сервисов или другого ПО, проверяет актуальные стабильные версии через context7, если он доступен, или через web search по официальным источникам. Итог сохраняет в docs/researches/. Кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true`.'
+description: 'Исследует тему или задачу до конкретного результата: проясняет проблему, архитектуру, развилки, риски и короткий выбранный вариант решения без плана реализации. Работает read-only, читает `docs/rules.md`, `docs/arch.md` и релевантные карточки из `docs/references/`, а значимые развилки выносит пользователю по `explore.decision_mode` из `docs/settings.yaml`. Для пакетов и другого ПО проверяет актуальные стабильные версии по официальным источникам. Итог сохраняет в docs/researches/. Кросс-ревью соседним агентом включается флагом `strict` или настройкой `explore.strict: true`.'
 ---
 
 # Скил: Исследователь решений (eda-explore)
@@ -11,12 +11,12 @@ description: 'Исследует тему или задачу до конкре
 
 Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
 
-Дефолты: `defaults.strict: false`, `defaults.decision_mode: recommend_and_ask`.
+Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолты: `explore.strict: false`, `explore.decision_mode: recommend_and_ask`.
 
 | Настройка | Значения | Аргументы в сообщении |
 |---|---|---|
-| `defaults.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
-| `defaults.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
+| `explore.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
+| `explore.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
 
 Если значение из настроек отсутствует или неизвестно, используй дефолт. `strict` добавляет кросс-ревью соседним агентом; обычный режим сохраняет отчёт без кросс-ревью.
 
@@ -43,7 +43,8 @@ description: 'Исследует тему или задачу до конкре
 3. **Развилки закрывай по `decision_mode`.** Значимые развилки подтверждай до финализации, мелкие локальные решения выбирай сам и не создавай шум.
 4. **Риски вплетай в исследование.** Не создавай отдельный обязательный раздел или этап рисков. Если риск влияет на выбор, источник, ограничение или будущую проверку, фиксируй его рядом с соответствующим решением: что может пойти не так и как это учитывается — снимаем, принимаем или выносим за рамки.
 5. **Версии проверяй.** Если речь о пакетах, библиотеках, CLI, сервисах или другом ПО, а версия не задана контекстом, проверь последнюю стабильную версию через context7, если он доступен, или через web search по официальным источникам.
-6. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и используй их как рамку.
+6. **Прочитай рамку проекта.** Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Если существует `docs/references.md`, прочитай индекс, выбери только карточки, применимые к исследуемым компонентам, и прочитай их целиком; нерелевантные карточки не загружай.
+7. **Соблюдай приоритеты.** Подтверждённое решение пользователя важнее `docs/rules.md`, затем идёт `docs/arch.md`, затем релевантные карточки. Не рекомендуй отклонение от эталона без явной причины и подтверждения пользователя.
 7. **Каждое фактическое утверждение — со ссылкой** (`file.ext:42`, URL, коммит). Без ссылки — помечай как «гипотеза» и не делай её основанием выбранного решения.
 8. **Простой язык.** Термины — только когда без них нельзя, сразу с пояснением.
 9. **Таблицы > сплошной текст** для фактов, развилок, сравнений, версий и источников.
@@ -69,7 +70,7 @@ description: 'Исследует тему или задачу до конкре
 
 ### 2. Собрать контекст
 
-Работай read-only: читай код, документы, конфиги, тесты, историю и внешние источники. Прочитай `docs/rules.md` и `docs/arch.md`, если они есть.
+Работай read-only: читай код, документы, конфиги, тесты, историю и внешние источники. Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Если есть `docs/references.md`, выбери по индексу только применимые карточки и используй их кодовые примеры как эталон ожидаемой формы решения.
 
 Если исследование касается пакетов или ПО:
 - сначала проверь, не зафиксирована ли версия в запросе, lock-файле, package/config-файле, `docs/rules.md`, `docs/arch.md` или связанном документе;
@@ -101,6 +102,7 @@ reviewer: <pending | none | claude | codex>
 sources:
   rules: <путь или —>
   arch: <путь или —>
+  references: [<пути к применимым карточкам или пусто>]
 ---
 
 # <Заголовок>
@@ -135,6 +137,7 @@ Quality gate перед сохранением:
 - нет высокого риска без понятного решения;
 - версии пакетов/ПО проверены или объяснено, почему это не требуется;
 - ключевые утверждения имеют источники.
+- выбранное решение следует применимым карточкам либо содержит подтверждённую пользователем причину отклонения.
 
 ### 5. Кросс-ревью — только в `strict`
 
@@ -145,13 +148,13 @@ Quality gate перед сохранением:
 Если ты в Claude Code — запускай Codex CLI:
 
 ```bash
-codex exec "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, архитектура не выдумана, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
+codex exec "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md, карточки из sources.references при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, архитектура не выдумана, применимые эталоны учтены, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
 ```
 
 Если ты в Codex — запускай Claude CLI с теми же требованиями:
 
 ```bash
-claude -p "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, архитектура не выдумана, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
+claude -p "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md, карточки из sources.references при наличии и все источники, на которые ссылается исследование. Проверь, что проблема описана конкретно, архитектура не выдумана, применимые эталоны учтены, все развилки решены, риски закрыты, версии пакетов/ПО проверены по актуальным источникам, а вариант решения не является планом или абстрактным рассуждением. Критическое ревью на русском: фактические ошибки, пропущенные развилки, незакрытые риски, слабые источники, неверные версии, неконкретный итог. Формат: '- [тип] описание — что исправить'." > "${RESEARCH_FILE%.md}_review.md"
 ```
 
 CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.

package/skills/{eda-fix.md → eda-fix/SKILL.md}

@@ -1,6 +1,6 @@
 ---
 name: eda-fix
-description: 'Делает обычные фиксы по плану, файлу плана или короткому текстовому контексту. Перед правками читает `docs/rules.md` и `docs/arch.md`, если есть, и строго следует им. Правит код, добавляет нужные тесты, прогоняет проверки и сохраняет историю в `docs/fixes/`. Не делает ревью и не коммитит.'
+description: 'Делает обычные фиксы по плану, файлу плана или короткому текстовому контексту. Перед правками читает `docs/rules.md`, `docs/arch.md` и только релевантные карточки из `docs/references/`, если они есть, и следует им с установленным приоритетом. Правит код, добавляет нужные тесты, прогоняет проверки и сохраняет историю в `docs/fixes/`. Не делает ревью и не коммитит.'
 ---
 
 # Скил: Фиксер (eda-fix)
@@ -15,7 +15,7 @@ description: 'Делает обычные фиксы по плану, файлу
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Файлов нет — продолжай.
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`. Если есть `docs/references.md`, выбери по индексу только карточки для затронутых компонентов и прочитай их целиком. Приоритет: подтверждённое решение пользователя → правила → архитектура → карточки. Файлов нет — продолжай.
 2. **Вход обязателен.** Если не передан план, файл или понятный текст задачи — спроси через интерактивный вопрос.
 3. **Делай только указанные фиксы.** Не расширяй задачу до рефакторинга и не чини соседние проблемы без необходимости.
 4. **Тесты рядом с правкой.** Меняешь поведение — добавь или обнови точечный тест.
@@ -37,10 +37,10 @@ description: 'Делает обычные фиксы по плану, файлу
 Определи `$FIX_CONTEXT`: путь к файлу прочитай, план из `docs/plans/` используй как план фикса, текст используй как контекст. Если входа нет или он неоднозначен — спроси через `AskUserQuestion`.
 
 ### 2. Прочитать рамку проекта
-Прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Если `$FIX_CONTEXT` ссылается на research, review, issue или другой файл — прочитай и его.
+Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Если существует `docs/references.md`, выбери по индексу только применимые карточки и используй их примеры как ожидаемую форму реализации. Если `$FIX_CONTEXT` ссылается на план с `sources.references`, прочитай перечисленные карточки; если ссылается на research, review, issue или другой файл — прочитай и его.
 
 ### 3. Сделать фикс
-Найди релевантный код и внеси минимальные правки. Если задача состоит из нескольких пунктов, иди по ним последовательно. Останавливайся и спрашивай, если пункт противоречит коду, требует продуктового решения, рискованной операции, миграции, удаления данных или затрагивает секреты.
+Найди релевантный код и внеси минимальные правки. Следуй применимому примеру; отклоняйся только по причине, подтверждённой пользователем или уже записанной во входном плане. Если задача состоит из нескольких пунктов, иди по ним последовательно. Останавливайся и спрашивай, если пункт противоречит коду или документации, требует необоснованного отклонения от карточки, продуктового решения, рискованной операции, миграции, удаления данных или затрагивает секреты.
 
 ### 4. Добавить или обновить тесты
 Если фикс меняет поведение — добавь тест рядом с изменением или обнови существующий. Если тесты не нужны, в отчёте коротко объясни почему.
@@ -61,7 +61,7 @@ status: done
 # Фикс: <краткий заголовок>
 
 ## Контекст
-<что было передано на вход и какие правила/архитектура учтены>
+<что было передано на вход и какие правила, архитектура и карточки учтены>
 
 ## Что изменено
 | # | Файл | Что изменено | Зачем |
@@ -83,6 +83,7 @@ status: done
 ## Чего НЕ делать
 - Коммитить, пушить, создавать PR.
 - Делать ревью вместо фикса.
-- Выполнять большой план с чекбоксами и журналом `docs/executions/` — это `eda-execute`.
+- Выполнять большой план с чекбоксами и журналом `docs/executions/` — это `eda-plan-execute`.
 - Применять замечания из готового ревью — это `eda-fix-by-review`.
 - Сохранять отчёт куда-либо кроме `docs/fixes/`.
+- Игнорировать применимую карточку или молча отклоняться от её примера.

package/skills/{eda-fix-by-review.md → eda-fix-by-review/SKILL.md}

@@ -1,6 +1,6 @@
 ---
 name: eda-fix-by-review
-description: 'Применяет замечания из ревью (`docs/reviews/...`) или из текста рядом с вызовом к коду. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им. Все пункты «править обязательно» правит сразу. Пункты «на усмотрение» в обычном режиме выносит пользователю, а в `apply-optional` решает сам: применяет полезные и отклоняет нецелесообразные с причиной. «Не править» пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью и не коммитит.'
+description: 'Применяет замечания из ревью (`docs/reviews/...`) или текста к коду. Перед правками читает `docs/rules.md`, `docs/arch.md` и релевантные карточки из `docs/references/`. Все обязательные пункты правит сразу; optional-пункты выносит пользователю или решает сам в `apply-optional`. После правок прогоняет тесты и линтеры, сохраняет отчёт в `docs/review-fixes/`. Не делает само ревью и не коммитит.'
 ---
 
 # Скил: Исправитель по ревью (eda-fix-by-review)
@@ -21,7 +21,7 @@ description: 'Применяет замечания из ревью (`docs/revie
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Это рамка проекта. Один раз в начале.
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`. Если есть `docs/references.md`, выбери по индексу только карточки для затронутых замечаниями компонентов и прочитай их целиком. Приоритет: подтверждённое решение пользователя → правила → архитектура → карточки. Сделай это один раз в начале.
 2. **Интерактивные вопросы** — по разделу ниже.
 3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
 4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
@@ -47,7 +47,7 @@ description: 'Применяет замечания из ревью (`docs/revie
 Если найдено ровно одно ревью — используй режим `$REVIEW_SOURCE=review_file` и продолжай без вопроса. Если замечания даны текстом — используй режим `$REVIEW_SOURCE=review_text` и продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста и вход не содержит замечания — остановись с понятным вопросом или статусом `blocked: нужно ревью`.
 
 ### 2. Прочитать контекст
-`docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
+Прочитай `docs/rules.md`, `docs/arch.md`, если они есть. Через `docs/references.md` выбери только применимые карточки. Если связанный план содержит `sources.references`, прочитай перечисленные карточки и не загружай остальные.
 
 Если `$REVIEW_SOURCE=review_file`, прочитай сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
 
@@ -59,7 +59,7 @@ description: 'Применяет замечания из ревью (`docs/revie
 - **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` сам реши по каждому пункту, применяй только принятые решения без вопроса, а отклонённые фиксируй с причиной.
 - **Не править** → пропусти.
 
-Останавливайся и спрашивай, если: замечание непонятно / противоречит коду / задевает рискованное вне ревью (удаление, миграции, секреты).
+Останавливайся и спрашивай, если замечание непонятно, противоречит коду или проектной документации, требует необоснованного отклонения от карточки либо задевает рискованное вне ревью (удаление, миграции, секреты). Подтверждённое отклонение зафиксируй в отчёте.
 
 ### 4. Финальная проверка
 Прогони полный сьют тестов и линтеры. Команды — стандартные для стека; непонятно — `AskUserQuestion`. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`.
@@ -116,3 +116,4 @@ status: done
 - Гонять полный сьют и линтеры на каждой правке — только в конце.
 - Пропускать финальную проверку.
 - Сохранять отчёт куда-либо кроме `docs/review-fixes/`.
+- Игнорировать применимую карточку или молча отклоняться от её примера.

package/skills/{eda-manual-test.md → eda-manual-test/SKILL.md}

@@ -127,7 +127,7 @@ status: <passed | failed | blocked>
 
 ## Чего НЕ делать
 - Править код, конфиги, миграции, seed-данные или документацию проекта, кроме отчёта в `docs/manual-tests/`.
-- Писать или обновлять unit/e2e/autotests. Это работа `eda-fix`, `eda-execute` или отдельной задачи.
+- Писать или обновлять unit/e2e/autotests. Это работа `eda-fix`, `eda-plan-execute` или отдельной задачи.
 - Устанавливать Playwright, браузеры, npm-пакеты, docker images или системные зависимости без явного подтверждения.
 - Подменять ручную проверку запуском `npm test` без фактического прохождения API/UI-сценария.
 - Проверять production или staging с изменением данных без подтверждения пользователя.

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

@@ -0,0 +1,72 @@
+---
+name: eda-merge-worktree
+description: 'Оркестрирует merge ветки из соседнего git worktree через пакетного агента на `haiku` / `gpt-5.6-luna`. Аргумент принимает как номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Перед merge проверяет оба worktree на незакоммиченные изменения. После успешного merge не удаляет worktree и ветку.'
+---
+
+# Скил: Merge из worktree (eda-merge-worktree)
+
+Работай как лёгкий оркестратор установленного агента `eda-merge-worktree-executor`. Сам не исследуй git-состояние, не определяй исходную ветку и не выполняй merge.
+
+## Вход из сообщения пользователя
+
+Сохрани весь текст текущего сообщения дословно в `$USER_REQUEST`. Это главный вход: номер worktree, короткое имя `work-<n>`, полное имя `{name}-work-<n>`, ограничения и прямые указания.
+
+Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно. При последующем ответе на вопрос сохрани исходный `$USER_REQUEST` и передай ответ отдельно.
+
+## Агент
+
+| Агент | Claude Code | Codex | Доступ |
+|---|---|---|---|
+| `eda-merge-worktree-executor` | `haiku` | `gpt-5.6-luna` | git-write |
+
+- В Claude Code запускай установленный custom agent через `Agent` tool по имени.
+- В Codex запускай установленный custom agent через `spawn_agent` или аналог по имени.
+- Не копируй в task-сообщение системный prompt агента: он уже установлен в `.claude/agents/` или `.codex/agents/`.
+- Передавай агенту только рабочую директорию, данные текущего запуска и требуемый формат результата.
+- Если custom agent или инструмент субагентов недоступен, остановись: `blocked: нужен установленный агент eda-merge-worktree-executor`. Не выполняй его роль основным агентом и не заменяй отдельным CLI-процессом.
+
+## Интерактивные вопросы
+
+Когда агент вернул `blocked`, задай его один конкретный вопрос пользователю через общий паттерн `AskUserQuestion`.
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 1–3 вариантами и остановись до ответа.
+- Codex exec / неинтерактивный запуск: не читай stdin; заверши со статусом `blocked: нужен ответ пользователя`, перечисли вопрос и варианты.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+После ответа продолжи того же агента, если хост это поддерживает. Иначе запусти `eda-merge-worktree-executor` заново с исходным запросом, полным предыдущим результатом и ответом пользователя.
+
+## Процесс
+
+Запусти `eda-merge-worktree-executor` и передай:
+
+```text
+Рабочая директория: <cwd>
+USER_REQUEST:
+<полный дословный запрос>
+
+Верни результат строго по YAML-контракту агента.
+```
+
+Обработай `status`:
+
+- `merged` или `already-up-to-date` — переходи к финалу;
+- `conflict` — сообщи список конфликтных файлов и что merge нужно завершить вручную;
+- `blocked` — задай вопрос агента и продолжи после ответа;
+- `failed` — коротко сообщи фактическую ошибку и безопасный следующий шаг.
+
+## Финал
+
+Коротко сообщи из результата агента:
+
+- исходную и текущую ветки;
+- путь исходного worktree;
+- статус: `merged`, `already up to date` или `conflict`;
+- что worktree и исходная ветка не удалялись.
+
+## Чего НЕ делать
+
+- Выполнять работу `eda-merge-worktree-executor` основным агентом.
+- Переключать целевую ветку, править код или разрешать конфликты вручную.
+- Делать отдельный commit, push или cleanup worktree и исходной ветки.
+- Терять исходный `$USER_REQUEST` после интерактивного ответа.

package/skills/eda-merge-worktree/skill.json

@@ -0,0 +1,7 @@
+{
+  "schemaVersion": 1,
+  "models": {
+    "claude": "haiku",
+    "codex": "gpt-5.6-luna"
+  }
+}