@gian-tiaga/eda 0.8.6 → 1.0.0

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

@@ -0,0 +1,227 @@
+---
+name: eda-prepare-ai
+description: 'Проектирует или актуализирует архитектуру, строгие правила, профиль инструментов, автоматические проверки и AI-процесс проекта, затем создаёт `docs/rules.md`, `docs/arch.md`, индекс и карточки `docs/references/`, компактный `AGENTS.md` и минимальный `CLAUDE.md`. Для нового проекта принимает подтверждённый бриф eda-new-project как источник требований, стека и архитектурных драйверов. Подбирает применимые AI-скилы, агентные роли и MCP, но не пишет код, не меняет конфиги и не ставит зависимости.'
+---
+
+# Скил: Подготовка проекта для AI (eda-prepare-ai)
+
+Превращаешь реальный проект или подтверждённый стартовый бриф в согласованную техническую рамку для людей и AI-агентов: проектируешь архитектуру, правила, строгий профиль инструментов, матрицу проверок и AI-процесс, затем создаёшь или обновляешь `docs/rules.md`, `docs/arch.md`, `docs/references.md`, карточки в `docs/references/`, `AGENTS.md` и `CLAUDE.md`.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом уточняет задачу: он может задавать основное направление или быть вспомогательным контекстом. Учти прямые указания, ограничения и названные файлы; остальное определи по проекту. Спрашивай только когда без ответа есть реальный риск выбрать неверное решение.
+
+## Главные правила
+
+1. **Не правишь код.** Меняй только `docs/rules.md`, `docs/arch.md`, `docs/references.md`, `docs/references/*.md`, `AGENTS.md` и `CLAUDE.md`; не ставь пакеты и не меняй конфиги.
+2. **Опирайся на проект.** Читай код, структуру, зависимости, команды, тесты, инфраструктуру, git-историю и существующие документы. Не генерируй универсальный шаблон.
+3. **Не дублируй документы.** Правила отвечают «как работать», архитектура — «как устроен проект», references — «как выглядит типовая реализация», `AGENTS.md` — «что это за проект и где читать обязательную рамку».
+4. **Обновляй осмысленно.** Сохраняй актуальное, исправляй неверное, удаляй устаревшее и перестраивай документ настолько сильно, насколько требует проект. Не спрашивай отдельно, что делать с каждым существующим файлом.
+5. **Не выдавай предположение за факт.** Значимые неподтверждённые архитектурные решения предложи пользователю; после выбора зафиксируй принятый вариант.
+6. **Предлагай экстремальный профиль проверок.** Не ограничивайся уже установленными командами или базовыми lint/test. Пройди весь каталог ниже, предложи все применимые проверки и объясни каждое `не применимо`; в документацию переноси только подтверждённые правила.
+7. **MCP не заменяет CI.** Обязательно оцени browser automation MCP и MCP выбранного стека, но предпочитай детерминированную CLI/CI-проверку, если она ловит тот же класс ошибок.
+8. **Стартовый бриф задаёт цель, а не реализацию.** Подтверждённые требования, основной стек и архитектурные драйверы из `eda-new-project` считай обязательным входом. Не переоткрывай выбор стека без обнаруженного противоречия; архитектуру, правила, проверки и AI/MCP-процесс спроектируй здесь.
+9. **Максимальная практическая строгость по умолчанию.** Для каждого применимого инструмента предложи самый строгий стабильный полезный профиль. Ослабления показывай как отдельные решения с последствиями и минимальной областью действия.
+10. **Не внедряй tooling.** Можешь рекомендовать пакеты, команды, конфиги, скилы и MCP, но не устанавливай и не настраивай их; для внедрения предложи `eda-plan`.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+## Этапы
+
+### 1. Проанализировать проект
+
+Определи языки, фреймворки, точки входа, зависимости, тесты, хранилища данных, внешние интеграции, инфраструктуру, CI, инструменты качества, структуру директорий и сложившиеся соглашения. Для команд и соглашений используй конфиги и git-историю, а не догадки.
+
+Если вызов пришёл из `eda-new-project`, прочитай переданный `docs/project-starts/*.md`. Подтверждённые требования, основной стек и архитектурные драйверы считай источником целевого состояния; открытые вопросы и отклонённые варианты фактами не считай. Не требуй от стартового документа готовой архитектуры, правил, матрицы проверок или AI/MCP-рекомендаций — их обязан спроектировать этот скил.
+
+### 2. Прочитать существующую документацию
+
+Прочитай `docs/rules.md`, `docs/arch.md`, `docs/references.md`, карточки из `docs/references/`, `AGENTS.md` и `CLAUDE.md`, если они есть. Также прочитай релевантные документы из `docs/`, на которые они ссылаются. Найди дубли, противоречия и устаревшие сведения.
+
+### 3. Определить область обновления
+
+Определи область по текущему сообщению:
+
+- если пользователь вызвал просто `eda-prepare-ai` и не назвал документ — обнови весь набор: `docs/rules.md`, `docs/arch.md`, `docs/references.md`, все актуальные карточки в `docs/references/`, `AGENTS.md` и `CLAUDE.md`;
+- если явно назвал rules, architecture, `AGENTS.md` или `CLAUDE.md` — обнови только названные документы;
+- если явно назвал references — обнови `docs/references.md` и актуальные карточки, затем добавь или актуализируй ссылку на `docs/references.md` в `AGENTS.md`;
+- если явно назвал одну карточку — обнови только её и соответствующую строку `docs/references.md`.
+- если явно запросил проверки без полного вызова — проведи полный аудит проверок, предложи матрицу и после подтверждения обнови только относящиеся к ней правила в `docs/rules.md`;
+- если передан стартовый документ `eda-new-project` — считай это полным bootstrap-вызовом: спроектируй архитектуру, правила, строгий профиль инструментов, матрицу проверок и AI/MCP-процесс; обнови весь набор документов, если пользователь явно не сузил область.
+
+При любом изменении `CLAUDE.md` сохраняй его минимальным указателем на `AGENTS.md`. Не меняй `CLAUDE.md` в точечном режиме, если пользователь его не называл. Прямой запрет пользователя на изменение зависимого файла важнее автоматической синхронизации; сообщи о несинхронизированной ссылке в финале.
+
+### 4. Решить архитектурные развилки
+
+Для существующего проекта сначала отдели фактическое устройство от целевого. Для нового проекта опирайся на подтверждённые требования, стек и архитектурные драйверы стартового документа.
+
+Если устройство ещё не определено или нуждается в изменении:
+- сравни 2–3 подходящих архитектурных варианта без лишней сложности;
+- для каждого покажи соответствие драйверам, границы ответственности, основные runtime/data-flow, владение данными, направления зависимостей, риски и дорогие для изменения решения;
+- рекомендуй один вариант и через `AskUserQuestion` согласуй только значимые развилки;
+- не переоткрывай подтверждённый стек, если он совместим с требованиями; при конфликте покажи доказательство и отдельно запроси решение пользователя.
+
+Сохрани выбранное решение для последующего обновления `docs/arch.md`. Для нового или пустого проекта явно называй его целевой архитектурой, а не уже реализованным состоянием.
+
+### 5. Предложить строгий профиль и экстремальную матрицу проверок
+
+По умолчанию предложи самый строгий стабильный профиль, практически применимый к выбранному стеку и ограничениям проекта. Не ограничивайся фактом установки инструмента или его preset по умолчанию: проверь значимые режимы, отключённые категории и правила по актуальной документации. Включи все стабильные, недублирующие и применимые проверки; экспериментальные, конфликтующие, устаревшие и стабильно шумные проверки перечисли с причиной отключения.
+
+Для языков с динамической или слабой типизацией отдельно предложи максимально строгую доступную статическую типизацию: strict-режим typechecker/compiler, nullability, типизированные границы и публичные контракты, generics/shape-типы, runtime-валидацию внешних данных и запрет неявных `any` / `mixed` / dynamic / untyped-значений там, где стек позволяет выразить точный тип. Ориентиры: все применимые strict-флаги TypeScript, `strict` у mypy/Pyright, `strict_types` и максимальный уровень PHPStan/Psalm, `strict` у Sorbet. Если полностью строгий режим нельзя включить сразу, предложи измеримый переход; новые и изменяемые файлы не должны расширять область нетипизированного кода.
+
+Для каждого инструмента проверь максимальный применимый режим:
+- compiler/runtime/build: строгие и безопасные флаги, warnings/deprecations как ошибки, запрет неявных небезопасных преобразований и undefined behavior;
+- formatter/linter/static analysis: максимальные stable recommended/strict/type-aware/security/framework-наборы, нулевой бюджет предупреждений, анализ тестов и конфигов, запрет blanket-ignore;
+- typechecker и schema validators: строгая проверка исходников, тестов, API, конфигов, сериализации и внешних входов без непроверенных обходов;
+- тестовые инструменты: fail-on-warning/deprecation, flaky detection, coverage и mutation budgets по осмысленным порогам, изоляция и воспроизводимость;
+- dependency/build/release/security: lockfile integrity, audit/license/SBOM/provenance-политики, reproducible build и отказ при нарушении обязательного gate;
+- CI и hooks: те же строгие команды, что локально, без `continue-on-error`, подавления exit code и расхождения конфигураций между контурами.
+
+Для каждого нового пакета, CLI, сервиса или MCP укажи конкретную актуальную стабильную версию, официальный источник и дату проверки. Если инструмент ещё не установлен, пометь команду как предлагаемую и не выдавай её за подтверждённо работающую.
+
+Проведи полный gap-аудит, даже если проект новый или почти пустой. Не вводи фиксированный максимум и не останавливайся после 10–20 предложений. Для каждой группы поставь `уже есть` / `предложено` / `позже` / `не применимо` и объясни последнее значение:
+
+1. **Тесты:** unit, integration, component, contract, API, e2e, smoke, acceptance, regression, negative и edge-case.
+2. **Глубокие тесты:** property-based, mutation, fuzz, differential, metamorphic, snapshot/golden, repeatability и flaky detection.
+3. **UI/browser:** browser e2e, visual regression, accessibility, keyboard/focus, responsive, cross-browser/device, hydration, broken links, forms/uploads, locale/timezone и console errors.
+4. **Стиль и качество:** formatter, linter, naming, complexity, duplication, dead code, unused exports/dependencies, forbidden patterns, TODO/FIXME и size limits.
+5. **Статический анализ:** typecheck, nullability, data-flow/taint, API misuse, unreachable code, unsafe behavior, memory/thread/address sanitizers и анализаторы языка.
+6. **Границы модулей:** forbidden imports, dependency direction, cycles, layers, public API, ownership, package boundaries, generated code и architecture fitness functions.
+7. **Конфиги/IaC:** env, YAML/JSON/TOML, CI, Docker/Compose, Kubernetes/Helm, Terraform, proxy, feature flags, IAM, observability и env-example drift.
+8. **API/compatibility:** OpenAPI/GraphQL/Proto, breaking changes, generated-code drift, serialization, backward/forward compatibility, idempotency и pagination/filter/sort.
+9. **БД/данные:** migrations forward/rollback/dry-run, schema drift, constraints, fixtures, transactions, concurrency, N+1/query plans, backup/restore, retention/anonymization и invariants.
+10. **Security/supply chain:** secrets, SAST, DAST, dependencies, licenses, SBOM, lockfiles, container/IaC, provenance, authn/authz, injection, XSS/CSRF/SSRF, CORS/CSP/headers, rate limits и PII leakage.
+11. **Performance/reliability:** benchmarks/budgets, bundle size, load/stress/spike/soak, leaks, startup, timeout/retry/circuit breaker, graceful shutdown, chaos/fault injection и recovery.
+12. **Build/release:** clean-clone и reproducible builds, 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 drift, diagrams/schemas и migration/release notes.
+14. **Эксплуатация:** health/readiness/liveness, metric/log/trace schemas, no secrets/PII in logs, alerts, dashboards as code, SLO/error budgets, disaster recovery и restore drills.
+15. **Домен:** платежи, почта, очереди/jobs, webhooks, поиск, files/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 недостаточно.
+
+Для каждого предложения укажи конкретный инструмент, точную команду или сценарий, закрываемый риск и контур: `pre-commit`, `pre-push`, `PR CI`, `nightly`, `release`, `post-deploy`, `MCP/manual`. Отдели быстрый обязательный gate от тяжёлых scheduled/release-проверок, чтобы экстремальный профиль оставался исполнимым.
+
+Покажи матрицу пользователю и одним `AskUserQuestion` предложи: принять весь применимый экстремальный профиль / принять только быстрый baseline / выбрать пункты. В неинтерактивном запуске не записывай новые неподтверждённые процессные правила: перечисли предложения в финале и поставь `blocked: нужно подтвердить профиль проверок`, продолжая только те документальные обновления, которым подтверждение не требуется.
+
+### 6. Обновить `docs/rules.md`
+
+Собери столько правил, сколько действительно нужно проекту; не вводи числовой лимит. Каждое правило формулируй коротко, однозначно и проверяемо. Группируй правила по темам только когда это ускоряет поиск.
+
+В файле должны быть только действующие правила проекта. Не добавляй введение, объяснения пользы, обоснования, предложения, наблюдения, архитектурное описание или декоративные разделы. Команду проверки указывай только как конкретное правило, например: «Перед финалом запусти `npm test`».
+
+Не спрашивай подтверждение списка правил перед записью. Если правило нельзя уверенно вывести из проекта или прямого указания пользователя и оно заметно меняет процесс команды, сначала предложи его через `AskUserQuestion`; непринятые предложения в файл не записывай.
+
+Принятые проверки записывай как короткие обязательные правила с точной командой и моментом запуска. Не копируй в `docs/rules.md` сравнительную матрицу, список неприменимых проверок, описания инструментов или неподтверждённые предложения.
+
+Для каждого принятого инструмента запиши точный строгий режим и запрет бесконтрольных подавлений. Если инструмент ещё не внедрён и команда не подтверждена проектом, не записывай её как действующее правило: оставь рекомендацию в финале и передай внедрение в `eda-plan`.
+
+### 7. Обновить `docs/arch.md`
+
+Опиши устройство проекта, не повторяя рабочие правила из `docs/rules.md`. Документ должен позволять понять, где находится нужная часть системы, за что она отвечает и как связана с остальными.
+
+Включи релевантные проекту сведения:
+- выбранный архитектурный подход, например модульный монолит, слоистая архитектура или набор сервисов, и коротко почему он подходит проекту;
+- дерево основных папок с назначением каждой значимой части;
+- компоненты, модули или слои, их ответственность и границы;
+- допустимые направления зависимостей между частями;
+- ключевые runtime- и data-flow от точки входа до результата;
+- владение данными, хранилища и внешние интеграции;
+- важные архитектурные решения и ограничения.
+
+Сначала зафиксируй фактическое текущее состояние. Если архитектура не определена, непоследовательна или не подходит целям проекта, предложи целевой подход и значимые развилки через `AskUserQuestion`. После ответа запиши выбранную целевую архитектуру и явно отдели её от текущего состояния. Не превращай `docs/arch.md` в план миграции или список правил разработки.
+
+### 8. Обновить references
+
+Сначала определи повторяющиеся типы компонентов, для которых проекту действительно нужен эталон: например, controller, service, repository, handler, job, UI-компонент или тест. Не создавай карточки по универсальному списку — набор должен следовать реальному стеку и структуре проекта. Для нового проекта без реального кода не выдумывай эталоны: оставь индекс пустым или не создавай карточки и сообщи, что references нужно повторно подготовить после появления устойчивых реализаций.
+
+Сделай `docs/references.md` коротким индексом:
+
+```markdown
+# Эталоны кода
+
+| Компонент | Когда применять | Карточка |
+|---|---|---|
+| Контроллер | При добавлении HTTP endpoint | [Контроллер](references/controller.md) |
+```
+
+Индекс содержит ссылки только на карточки. В каждой карточке должны быть:
+
+- назначение и границы ответственности компонента;
+- условия, при которых пример применим;
+- один минимальный, законченный и синтаксически цельный пример в fenced code block с указанием языка;
+- короткий разбор элементов примера, которые нужно повторять;
+- допустимые варианты и условия осознанного отклонения.
+
+Формируй пример как нормализованный эталон: опирайся на `docs/rules.md`, `docs/arch.md`, установленный стек и устойчивые практики нескольких релевантных файлов, убирай бизнес-детали и используй нейтральные имена. Не копируй целый рабочий файл, не выдумывай отсутствующие зависимости, API, слои или инфраструктуру.
+
+Карточка должна быть самодостаточной. Не добавляй в неё Markdown-ссылки, URL, пути к исходным файлам или указания «смотри реализацию в ...». Ссылки на карточки хранятся только в `docs/references.md`.
+
+Если ожидаемую форму важного компонента нельзя вывести однозначно, собери все такие категории в один `AskUserQuestion`: покажи найденные варианты и попроси выбрать соглашение. До ответа не создавай и не обновляй спорные карточки. В неинтерактивном запуске заверши работу со статусом `blocked: нужен ответ пользователя`.
+
+При обновлении сохрани актуальные карточки и переработай устаревшие примеры, если изменились правила, архитектура, стек или устойчивые практики. Перед удалением карточки, которая больше не соответствует проекту, запроси подтверждение через `AskUserQuestion`; без подтверждения оставь файл и отметь проблему в финале.
+
+### 9. Подобрать AI-скилы, агентные роли и MCP
+
+После архитектуры, правил и матрицы проверок определи, какие AI-инструменты действительно нужны проекту:
+- доступные `eda-*`, Claude/Codex skills, проектные инструкции и специализированные роли для discovery, планирования, исполнения, ревью, security, accessibility, документации и релиза;
+- проектные скилы или роли, которые оправданы устойчивой доменной, архитектурной или интеграционной спецификой;
+- browser/Playwright MCP и MCP для БД, API, документации, GitHub/GitLab, cloud, observability, дизайна и выбранного стека;
+- инструменты, которые нужно отложить до появления кода, инфраструктуры, команды или повторяемого процесса.
+
+Для каждого скила или агента укажи задачу, обязательные источники, артефакт, способ проверки и почему обычной инструкции недостаточно. Для каждого MCP укажи сценарий, данные, минимальные права, риск, тестовое окружение и почему CLI/CI недостаточно. MCP с доступом к продакшену, секретам, платежам или персональным данным вынеси на отдельное подтверждение.
+
+Активные подтверждённые правила использования уже доступных инструментов можно кратко записать в `docs/rules.md`. Не записывай ещё не установленные скилы или MCP как действующую возможность и не раздувай ими `AGENTS.md`: перечисли такие рекомендации в финале и предложи отдельный `eda-plan` на внедрение.
+
+### 10. Обновить `AGENTS.md`
+
+Сделай `AGENTS.md` короткой входной картой для AI-агента. В нём должны быть:
+- краткое описание проекта;
+- ссылки на `docs/rules.md`, `docs/arch.md`, `docs/references.md` и другие действительно обязательные документы из `docs/`;
+- требование прочитать их и следовать им до работы над проектом.
+
+Не копируй в `AGENTS.md` правила, архитектуру, полное дерево папок, длинное описание стека, справочник команд или содержимое README. Если старый файл раздут или построен иначе, сократи или перестрой его целиком.
+
+### 11. Обновить `CLAUDE.md`
+
+Сделай корневой `CLAUDE.md` минимальным указателем на `AGENTS.md`. Обязательный смысл: «Прочитай `AGENTS.md` и следуй всем инструкциям в нём». Не дублируй в `CLAUDE.md` содержимое `AGENTS.md`, правил или архитектуры. Если файл уже содержит полезные самостоятельные указания, сохрани их только когда они не противоречат `AGENTS.md` и действительно нужны именно Claude Code.
+
+### 12. Проверить результат
+
+Убедись, что:
+- `docs/rules.md` содержит только лаконичные действующие правила;
+- `docs/arch.md` объясняет подход, структуру папок, части системы и их связи без повторения правил;
+- `docs/references.md` ссылается на все актуальные карточки и не содержит самих примеров;
+- каждая карточка самодостаточна, содержит законченный пример кода и не содержит ссылок или неподтверждённых элементов;
+- `AGENTS.md` остаётся коротким и ведёт к обязательным документам;
+- `CLAUDE.md` явно требует читать и соблюдать `AGENTS.md`;
+- экстремальный каталог проверок пройден полностью, для каждой группы есть статус, а принятые команды отражены в `docs/rules.md` без неподтверждённых предложений;
+- browser MCP и MCP выбранного стека оценены отдельно от детерминированных CLI/CI-проверок;
+- выбранные инструменты имеют максимальный применимый строгий профиль, а каждое ослабление явно обосновано;
+- для нового проекта требования, стек и архитектурные драйверы взяты из стартового документа, а архитектура и правила спроектированы внутри `eda-prepare-ai`;
+- AI-скилы, роли и MCP разделены на уже доступные и требующие отдельного внедрения;
+- документы не противоречат проекту и друг другу.
+
+### 13. Финал
+
+Коротко перечисли созданные и обновлённые файлы, существенные архитектурные решения, строгий профиль ключевых инструментов, число уже имеющихся/принятых/отложенных/неприменимых проверок, их распределение по контурам, доступные и предложенные AI-скилы/роли/MCP, что требует внедрения через `eda-plan`, и вопросы, которые остались неподтверждёнными.
+
+## Чего НЕ делать
+
+- Править файлы вне разрешённого набора проектной документации.
+- Спрашивать, какие документы обновлять, если пользователь их не назвал: по умолчанию обновляется весь набор.
+- Просить выбрать режим перезаписи для каждого существующего файла.
+- Ограничивать правила фиксированным количеством или разбавлять их пояснениями и предложениями.
+- Дублировать правила и архитектуру в `AGENTS.md` или `CLAUDE.md`.
+- Ссылаться из карточек на код проекта или внешние материалы вместо самодостаточного примера.
+- Создавать спорный эталон без ответа пользователя.
+- Выдавать предлагаемую архитектуру за уже реализованную.
+- Ограничиваться unit-тестами, линтером и typecheck, не проходя весь экстремальный каталог.
+- Записывать неподтверждённые проверки в `docs/rules.md` или подменять детерминированную проверку MCP/AI-анализом.
+- Переоткрывать подтверждённый `eda-new-project` стек без найденного конфликта с требованиями.
+- Выдавать неустановленный инструмент, скил или MCP за доступную возможность проекта.

package/skills/eda-review/SKILL.md

@@ -0,0 +1,212 @@
+---
+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.'
+---
+
+# Скил: Ревьюер (eda-review)
+
+Работай как оркестратор установленных `eda-review-*` агентов. Сам не выполняй их специализированные роли и не копируй их системные prompts в task-сообщения. Определи target и контекст, выбери проверки, запусти агентов, проверь их структурированные ответы, объедини подтверждённые находки и сохрани одно итоговое ревью.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении — главный вход. Сначала разбери target, план, ссылку, ограничения, отключённые или принудительно включённые проверки и разовые модели.
+
+Если входа достаточно, продолжай без вопроса. Без аргументов ревьюй незакоммиченный `git diff HEAD`. Ссылка на PR/MR задаёт target однозначно. Если пользователь дал только корень удалённого репозитория, обязательно попроси указать PR/MR, ветку, коммит или файлы; весь репозиторий и последний PR автоматически не выбирай.
+
+Разовые указания вида «без performance», «включи database», «architecture на opus» или «tests на gpt-5.6-sol» важнее `docs/settings.yaml` и действуют только на текущий запуск.
+
+## Настройки
+
+Прочитай `docs/settings.yaml`, если файл есть. Поддерживается только `version: 2`. Используй `review.agents.<check>.mode` и `review.agents.<check>.model.<platform>`. Если файла нет или версия отличается, используй defaults и добавь предупреждение; настройки v1 не применяй.
+
+Допустимые режимы:
+
+- `always` — запускать при каждом ревью;
+- `auto` — запускать только когда проверка применима;
+- `off` — не запускать.
+
+Допустимые модели по умолчанию: Claude Code — `haiku`, `sonnet`, `opus`; Codex — `gpt-5.6-luna`, `gpt-5.6-terra`, `gpt-5.6-sol`. Неизвестное или отсутствующее значение замени default-значением конкретного агента и добавь предупреждение в покрытие.
+
+Если `version: 2` существует, но раздела `review.agents` нет, используй defaults ниже. Устаревшие поля `review.strict`, `review.include_code_quality` и раздел `review-check` не применяй; добавь предупреждение с просьбой перенести настройки вручную. Существующий файл настроек не переписывай.
+
+| Проверка | Default mode | Claude | Codex |
+|---|---|---|---|
+| `correctness` | `always` | `sonnet` | `gpt-5.6-terra` |
+| `architecture` | `auto` | `opus` | `gpt-5.6-sol` |
+| `rules` | `always` | `haiku` | `gpt-5.6-luna` |
+| `references` | `auto` | `haiku` | `gpt-5.6-luna` |
+| `plan_alignment` | `auto` | `sonnet` | `gpt-5.6-terra` |
+| `code_quality` | `always` | `sonnet` | `gpt-5.6-terra` |
+| `tests` | `always` | `sonnet` | `gpt-5.6-terra` |
+| `security` | `auto` | `opus` | `gpt-5.6-sol` |
+| `performance` | `auto` | `sonnet` | `gpt-5.6-terra` |
+| `frontend` | `auto` | `sonnet` | `gpt-5.6-terra` |
+| `api` | `auto` | `sonnet` | `gpt-5.6-terra` |
+| `database` | `auto` | `opus` | `gpt-5.6-sol` |
+| `documentation` | `auto` | `haiku` | `gpt-5.6-luna` |
+| `previous_reviews` | `auto` | `haiku` | `gpt-5.6-luna` |
+
+## Вопросы
+
+Задавай вопрос только когда target противоречив, дана лишь ссылка на корень репозитория или безопасно выбрать цель невозможно. Вопрос о плане не задавай: используй план только если пользователь указал его или путь определяется однозначно; иначе установи `$PLAN_FILE=none`.
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай короткий вопрос с 2–3 вариантами и остановись до ответа.
+- Codex exec и другой неинтерактивный запуск: не читай stdin; верни `blocked: нужен target` с конкретным вопросом.
+
+## Подготовить контекст
+
+1. Определи `$TARGET`: явный файл, папка, URL PR/MR, ветка, коммит, указанный diff или `git diff HEAD` без аргументов. Для GitHub/GitLab URL получи metadata и diff read-only командами `gh`/`glab`; для другого сервиса используй доступное read-only средство. Если основной diff недоступен, остановись: warning разрешён только для недоступных прошлых обсуждений, а не для самого target.
+2. Прочитай `AGENTS.md`, `CLAUDE.md`, `docs/rules.md`, `docs/arch.md` и сам target настолько, чтобы выбрать проверки и передать агентам точный контекст. На этом шаге не делай собственное code review.
+3. Определи `$PLAN_FILE`. Если его нет, используй `none` и не пытайся восстановить последний план наугад.
+4. Определи `$REFERENCE_FILES`: если план содержит `sources.references`, используй их; иначе через `docs/references.md` выбери только применимые карточки для компонентов target. Если карточек нет, используй `none`.
+5. Сформируй краткий `$REVIEW_CONTEXT`: тип target, base, изменённые области, применимые документы и явные решения пользователя. Не включай в него domain-инструкции агентов.
+
+Приоритет решений: подтверждённое решение пользователя → действующие правила → архитектура → применимые карточки.
+
+## Выбрать проверки
+
+Сначала примени разовые overrides, затем настройки, затем defaults.
+
+- `always` включай всегда, `off` всегда пропускай.
+- `architecture` в `auto` включай при изменении границ модулей, зависимостей, публичных контрактов или разделения ответственности.
+- `references` включай только при непустом `$REFERENCE_FILES`.
+- `plan_alignment` включай только при непустом `$PLAN_FILE`.
+- `security` включай для auth, permissions, внешнего ввода, файлов, сети, секретов, криптографии и других границ доверия.
+- `performance` включай для запросов, пакетной обработки, кешей, конкурентности, памяти или горячих путей.
+- `frontend` обязательно включай при изменении компонентов, стилей, клиентских маршрутов, состояния или другой UI-части.
+- `api` включай при изменении routes, handlers, DTO, OpenAPI, GraphQL, RPC или клиент-серверного контракта.
+- `database` включай при изменении миграций, моделей хранения, SQL, схем, индексов или транзакций.
+- `documentation` включай при изменении публичного API, CLI, конфигурации, установки или пользовательского поведения.
+- `previous_reviews` включай для URL PR/MR или другой удалённой цели, у которой могут быть обсуждения ревью.
+
+Для каждой проверки сохрани причину `selected` или `skipped`; она попадёт в покрытие.
+
+## Запустить packaged-агентов
+
+Имя агента получается из имени проверки:
+
+- `plan_alignment` → `eda-review-plan-alignment`;
+- `code_quality` → `eda-review-code-quality`;
+- `previous_reviews` → `eda-review-previous-reviews`;
+- остальные → `eda-review-<check>`.
+
+В Claude Code запускай установленный custom agent через `Agent` tool. В Codex запускай установленный custom agent через `spawn_agent` или аналог. Передай выбранную модель как runtime override. Если хост не умеет применить выбранную модель или нативные субагенты недоступны, остановись: не выполняй роли главным агентом и не создавай отдельные CLI-процессы.
+
+Запусти все выбранные проверки одним параллельным пакетом; если хост ограничивает concurrency, разреши ему поставить лишние задачи в очередь. Каждому агенту передай только:
+
+```text
+Рабочая директория: <cwd>
+TARGET: <target>
+PLAN_FILE: <path | none>
+REFERENCE_FILES: <paths | none>
+MODEL: <фактически выбранная модель>
+REVIEW_CONTEXT: <краткий общий контекст>
+
+Верни результат строго по YAML-контракту установленного агента.
+```
+
+Не вставляй системный prompt агента в task-сообщение.
+
+## Проверить ответы и обработать сбои
+
+Проверь для каждого ответа `status`, `check`, фактически запрошенный `model` и структуру `findings`. Несовпадение модели считай ошибкой контракта. Находка без конкретного риска и доказательства не подтверждена.
+
+- При `blocked`, неверном YAML или отсутствующих обязательных полях один раз повтори того же агента на той же модели с исходным контекстом и описанием ошибки формата.
+- `completed` означает успешно выполненную проверку. `not_applicable` перенеси в skipped с причиной и не повторяй.
+- Если повторно не завершилась любая проверка, кроме `previous_reviews`, остановись без создания итогового файла ревью.
+- Для `previous_reviews` статусы `unavailable` или повторный технический сбой преврати в warning и продолжай. Не утверждай, что старые обсуждения проверены.
+- `previous_reviews` ничего не закрывает удалённо. Актуальные незакрытые замечания добавь в общий набор; исправленные, но открытые треды покажи только в покрытии.
+
+## Собрать итог
+
+Главный агент выполняет только редакторскую работу над результатами:
+
+1. Проверь находки по указанным evidence и отклони неподтверждённые.
+2. Объедини дубли разных агентов в один пункт, сохранив все полезные доказательства.
+3. Распредели проблемы по тяжести и рекомендации `required` или `optional`.
+4. Сам выставь итоговый `score` от 0 до 100 по серьёзности, вероятности, влиянию и общему качеству реализации. Не используй фиксированные вычеты, среднее или минимум оценок агентов. Добавь короткое обоснование числа.
+5. Не выполняй дополнительное самостоятельное ревью и не добавляй новые domain-находки от себя.
+
+Ревью содержит только проблемы. Не перечисляй выполненную работу, похвалу и успешные проверки. Исключение — короткий технический раздел покрытия.
+
+## Сохранить ревью
+
+Создай файл `docs/reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md` только после успешной обработки всех обязательных агентов. Для недоступного `previous_reviews` используй `status: reviewed-with-warnings`, иначе `status: reviewed`.
+
+```markdown
+---
+target: <что проверено>
+plan: <docs/plans/... | none>
+score: <0..100>
+status: <reviewed | reviewed-with-warnings>
+date: <YYYY-MM-DD HH:MM>
+checks:
+  - name: <check>
+    model: <model>
+    status: <completed | skipped | warning>
+    reason: <почему запущен, пропущен или неполон>
+---
+
+# Ревью: <краткое название>
+
+## Оценка
+
+**<N>/100.** <краткое экспертное обоснование>
+
+## Покрытие
+
+- **Completed:** <проверки и модели>
+- **Skipped:** <проверки и причины>
+- **Warnings:** <предупреждения или «нет»>
+- **Frontend:** <если запускался: «UI/UX проверены по коду; браузерная проверка не выполнялась»>
+- **Previous reviews:** <актуальные / исправленные, но открытые / недоступны>
+
+## Проблемы сверки с планом
+
+<Только подтверждённые plan_alignment-проблемы. Если плана нет: «Проверка плана пропущена: план не указан и не найден.»>
+
+## Проблемы в коде
+
+### 1. <короткий заголовок>
+
+<1–3 коротких абзаца: контекст, проблема, практический риск и когда он проявится. Не начинай с внутренних имён.>
+
+#### Технические детали
+
+- **Тип:** <check>
+- **Тяжесть:** <critical | high | medium | low>
+- **Рекомендация:** <править обязательно | на усмотрение автора>
+- **Файлы:** `<path:line>`
+- **Что подтверждает проблему:** <evidence>
+- **Как исправить:** <общий подход и конкретные шаги>
+- **Тесты:** <что добавить или обновить>
+
+## Рекомендации
+
+### Править обязательно
+- <номера или «Нет»>
+
+### На усмотрение автора
+- <номера или «Нет»>
+
+### Не править
+- <только явно отклонённые пункты или «Нет»>
+```
+
+Основная часть каждого замечания — главный ответ: простой язык, 1–3 коротких абзаца и контекст, понятный без чтения diff или плана. Файлы, строки, SQL, DTO и внутренние имена давай ниже в `Технические детали`.
+
+## Финал
+
+Коротко сообщи путь к ревью, статус, score, количество обязательных и optional-проблем, completed/skipped/warnings. Предложи `eda-fix-by-review` для исправления или `eda-commit`, если результат приемлем.
+
+## Чего НЕ делать
+
+- Править код, настройки проекта или удалённые обсуждения.
+- Выполнять специализированную роль главным агентом.
+- Запускать другой CLI или подменять отсутствующих субагентов одним общим ревью.
+- Записывать итоговый файл после повторного сбоя обязательного агента.
+- Выбирать последний PR или весь репозиторий по ссылке на корень.
+- Загружать все карточки references без отбора.
+- Усреднять оценки агентов или считать score по фиксированной формуле.
+- Утверждать, что UI визуально проверен без `eda-manual-test`.