@gian-tiaga/eda 0.8.6 → 1.0.0

package/skills/eda-review-check.md

@@ -1,149 +0,0 @@
----
-name: eda-review-check
-description: 'Проверяет готовое ревью из `docs/reviews/...` специализированными субагентами и, в strict-режиме, соседним CLI. Не делает первичное ревью и не правит код. Читает ревью, target/plan из front matter, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml` и связанный research при наличии. Запускает architecture-check, rules-check, plan-check только при указанном plan-файле и опциональный quality-check, затем сам применяет подтверждённые замечания к файлу ревью: добавляет, убирает или переформулирует пункты, обновляет score/status/meta_reviewers и раздел изменений после мета-ревью.'
----
-
-# Скил: Проверка ревью (eda-review-check)
-
-Берёшь уже сохранённое ревью из `docs/reviews/`, проверяешь его специализированными субагентами, затем сам правишь файл ревью по подтверждённым замечаниям. Этот скил переиспользуется обычным `eda-review` после draft-этапа и может запускаться отдельно.
-
-## Режим запуска
-
-Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
-
-Дефолты: `defaults.strict: false`, `review.include_code_quality: true`.
-
-| Настройка | Значения | Аргументы в сообщении |
-|---|---|---|
-| `defaults.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
-| `review.include_code_quality` | `true`, `false` | «проверь качество кода»; выключение: «без quality», «без проверки качества» |
-
-`strict` добавляет кросс-CLI соседним агентом. `review.include_code_quality: true` добавляет `quality-check` в обычное мета-ревью.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: путь к ревью, название или часть названия, «последнее ревью», режим, ограничения и прямые указания.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск проверить не то ревью. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Не делаешь первичное ревью.** Входом всегда является готовый файл `docs/reviews/...`.
-2. **Не правишь код.** Можно менять только выбранный файл ревью и вспомогательный файл `${REVIEW_FILE%.md}_cli_meta.md` в strict-режиме.
-3. **Мета-ревью специализированными агентами обязательно.** Базовые роли: `architecture-check`, `rules-check`. `plan-check` запускай только если в front matter ревью `plan` указывает на конкретный файл. Если включена проверка качества кода — добавь `quality-check` в тот же batch.
-4. **Главный редактор ревью — ты.** Субагенты дают предложения; решение добавить, убрать или переформулировать пункт принимаешь сам.
-5. **Ревью остаётся ревью только по проблемам.** Не добавляй выполненные пункты, похвалу, нейтральный отчёт о diff или общие рассуждения.
-6. **Каждое принятое изменение фиксируй в `## Изменения после мета-ревью`.** Отклонённые предложения тоже запиши коротко с причиной.
-7. **Оценку пересчитывай после правок.** Если изменился набор или тяжесть замечаний, обнови `score` в front matter и текст в разделе `## Оценка`.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-
-## Этапы
-
-### 1. Выбрать ревью и прочитать контекст
-
-Определи `$REVIEW_FILE`:
-- если пользователь указал путь к ревью — используй его;
-- если указал название или часть названия — найди совпадение в `docs/reviews/`;
-- если написал «последнее ревью» — возьми самый новый файл из `docs/reviews/`;
-- если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`;
-- если `docs/reviews/` отсутствует или пуста — остановись со статусом `blocked: нужно ревью`.
-
-Прочитай `$REVIEW_FILE` целиком. Из front matter и текста извлеки `$TARGET`, `$PLAN_FILE`, текущие `mode`, `score`, `status`, `meta_reviewers`. Если `plan: none` или план явно помечен как пропущенный, установи `$PLAN_FILE=none`. Если target указывает на diff-команду, получи актуальный diff. Если target указывает на файл, папку или PR — прочитай достаточно кода, чтобы проверить замечания. Прочитай `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, если они есть. Если ревью ссылается на `docs/researches/...`, прочитай связанный research.
-
-Если `$PLAN_FILE=none` или отсутствует, не угадывай план и не запускай `plan-check`. В разделе изменений после мета-ревью коротко зафиксируй: «plan-check не запускался: план не указан в ревью».
-
-### 2. Запустить специализированных субагентов
-
-Запусти **в одном сообщении и одним batch** агентов с выбранными ролями. В интерактивном Codex это означает субагентов, а не отдельные процессы `codex exec`. Не запускай сначала часть агентов, не жди их ответы и не запускай остальных позже: все выбранные проверки должны стартовать до чтения любого результата.
-
-Роли агентов:
-- `plan-check`: запускай только если `$PLAN_FILE` указывает на существующий файл. Проверяет, что реализация действительно выполнила `$PLAN_FILE`, включая частичные пункты, пропущенные требования, лишние отклонения и недостающие проверки.
-- `architecture-check`: проверяет следование `docs/arch.md`, границы модулей, контракты, зависимости и соответствие существующим архитектурным решениям.
-- `rules-check`: проверяет следование `docs/rules.md`, локальным запретам, обязательным командам, требованиям к тестам, миграциям, документации и процессу.
-- `quality-check`: запускай только если `review.include_code_quality: true` или пользователь явно попросил качество кода. Проверяет качество реализации: читаемость, сложность, дублирование, имена, размер и ответственность функций/классов, сцепление модулей, поддерживаемость и соответствие локальному стилю. Quality-замечания помечай типом `quality`; по умолчанию рекомендация `на усмотрение автора`, кроме случаев, где сложность, дублирование или неясная структура реально создают риск багов, тестовых пробелов или дорогого сопровождения.
-
-Модели:
-- Claude Code: запускай все роли через `Agent` tool на `model: "sonnet"`.
-- Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), запускай все роли через него на `gpt-5.3-codex`; не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны.
-- Codex exec / неинтерактивный fallback: если инструмента субагентов нет, запускай роли через параллельные `codex exec --model gpt-5.3-codex` одной Bash-командой с `&` и общим `wait`.
-- Если нужный идентификатор недоступен, возьми ближайшую code-capable модель того же уровня. Не используй быструю слабую модель для этих проверок: они должны читать diff, план при наличии, правила, архитектуру и релевантный код.
-
-Каждому агенту дай путь к `$REVIEW_FILE`, `$TARGET`, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, связанный research при наличии. `plan-check` дополнительно получает `$PLAN_FILE`, если он есть. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
-
-Формат ответа агентов:
-- `+` какую проблему добавить в ревью;
-- `−` что убрать как неверное или недоказанное;
-- `~` что переформулировать;
-- `?` что невозможно проверить и почему.
-
-Если `$PLAN_FILE` не передан, равен `none` или файл не найден, `plan-check` не запускай.
-
-### 3. Применить результаты обычного мета-ревью
-
-Когда все агенты ответили: прочитай ответы, **сам реши**, что применять. Добавляй только подтверждённые проблемы; предложения вида «добавить, что пункт выполнен» отклоняй как неформат ревью. Внеси правки в файл ревью.
-
-В разделе `## Изменения после мета-ревью` запиши:
-
-```markdown
-### После plan-check / architecture-check / rules-check / quality-check
-- **+ Добавлено:** <короткий список>
-- **~ Изменено:** <короткий список>
-- **− Убрано:** <короткий список>
-- **Отклонено:** <короткий список с причиной>
-```
-
-Поменяй `status: draft` → `meta-reviewed`, если статус был draft. В `meta_reviewers` добавь только фактически запущенные роли: `architecture-check`, `rules-check`, `plan-check` при наличии `$PLAN_FILE`, а если запускался — `quality-check`, и фактические модели, например `gpt-5.3-codex` или `sonnet`. Если оценка после корректировок изменилась — обнови `score`.
-
-### 4. Кросс-CLI: отдать соседнему агенту — только в `strict`
-
-Обычный режим — пропусти этап 4, иди на финал. `status: meta-reviewed` оставь как есть.
-
-В `strict`: отдай файл соседнему агенту через `Bash`. Если ты в Claude Code — запускай Codex CLI:
-
-```bash
-codex exec "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: какие проблемы добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Не предлагай перечислять выполненную работу. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
-```
-
-Если ты в Codex — запускай Claude CLI с теми же требованиями глубины:
-
-```bash
-claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: какие проблемы добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Не предлагай перечислять выполненную работу. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
-```
-
-Если `$PLAN_FILE=none`, в промпте соседнему CLI явно напиши: «План не указан; не проверяй выполнение плана и не угадывай файл плана, проверь только правила, архитектуру и код».
-
-Соседней CLI нет — `AskUserQuestion`: завершить как есть или прервать.
-
-Прочитай ответ, **сам реши**, что применять. Допиши в `## Изменения после мета-ревью`:
-
-```markdown
-### После соседнего CLI (codex|claude)
-- **+ Добавлено:** ...
-- **− Убрано:** ...
-- **Отклонено:** ...
-```
-
-Добавь в `meta_reviewers` имя CLI. `status: meta-reviewed` → `final`.
-
-### 5. Финал
-
-Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение», какие meta-reviewers запускались. Не пересказывай выполненную работу. Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review-check strict <review>`».
-
-## Чего НЕ делать
-
-- Делать первичное ревью. Это `eda-review`.
-- Править код. Это `eda-fix-by-review`.
-- Пропускать мета-ревью специализированными агентами.
-- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом остальных. Все выбранные обязательные проверки стартуют сразу.
-- Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
-- Вставлять чужие предложения механически — каждое решение принимай ты.
-- Задавать вопросы без блокировки и продолжать работу до ответа.
-- Сохранять или редактировать ревью вне `docs/reviews/`.
-- Перечислять выполненные пункты плана или давать общий отчёт о проделанной работе.

package/skills/eda-review.md

@@ -1,173 +0,0 @@
----
-name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с оценкой и сверкой с планом работ из `docs/plans/`, когда план указан или однозначно найден. Если план не указан и не найден однозначно, ревьюит без сверки с планом и не спрашивает про него. Без аргументов ревьюит незакоммиченный `git diff HEAD`. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью только по проблемам, сохраняет в `docs/reviews/` и в обычном режиме передаёт файл в `eda-review-check` для мета-проверки субагентами. Флаг `draft` сохраняет только черновое ревью без субагентов. Кросс-CLI включается флагом `strict` или настройкой `defaults.strict: true`. Не правит код — это `eda-fix-by-review`.'
----
-
-# Скил: Ревьюер (eda-review)
-
-Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Если скилл вызван без аргументов, ревьюишь незакоммиченный `git diff HEAD`. План сверяешь, только если он указан или однозначно найден; иначе ревьюишь без сверки с планом и про план не спрашиваешь. Каждый пункт начинаешь с короткого человеческого объяснения риска, без технической перегрузки; файлы, строки, детали кода и способ исправления даёшь ниже в блоке «Технические детали». Не перечисляешь, что выполнено хорошо или без замечаний. Затем в обычном режиме запускаешь `eda-review-check`, который проверяет ревью параллельными специализированными агентами; в `strict` он добавляет соседний CLI. В `draft` останавливаешься сразу после сохранения черновика.
-
-## Режим запуска
-
-Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
-
-Дефолты: `defaults.strict: false`, `review.include_code_quality: true`.
-
-| Настройка | Значения | Аргументы в сообщении |
-|---|---|---|
-| `defaults.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
-| `review.include_code_quality` | `true`, `false` | «проверь качество кода»; выключение: «без quality», «без проверки качества» |
-
-`strict` добавляет кросс-CLI соседним агентом. `review.include_code_quality: true` добавляет `quality-check` в обычное мета-ревью.
-
-Флаг `draft` отключает весь этап `eda-review-check`: сохрани ревью со `status: draft`, `meta_reviewers: []`, покажи путь и оценку, затем остановись. `draft` важнее `strict`: если пользователь написал оба режима, задай `AskUserQuestion`, потому что требования противоречат друг другу.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Замечания должны опираться на правила и архитектуру проекта, а не на твои общие представления.
-2. **Интерактивные вопросы** — по разделу ниже. Если контекст понятен, не спрашивай.
-3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
-4. **Сверка с планом — только если план есть.** Используй план, если пользователь указал путь к нему или его можно однозначно определить из diff/ссылок/существующего review-файла. Если плана нет или вариантов несколько — не спрашивай: делай ревью без сверки с планом и отметь это в ревью. Не подставляй «последний план» наугад.
-5. **Мета-ревью специализированными агентами — обязательно в normal/strict**, но выполняется отдельным скиллом `eda-review-check`. В `draft` мета-ревью не запускается.
-6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
-7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
-8. **Ревью содержит только проблемы.** Не пиши отчёт о выполненной работе, список успешно сделанных пунктов, похвалу или нейтральное перечисление изменений. В файл попадают только ошибки, недоделки, неточности, спорные решения, нарушения правил/архитектуры, риски и недостающие проверки. Если проблем нет, напиши коротко: «Явных проблем не найдено», без пересказа diff.
-9. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Проблемы сверки с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Внутри каждого пункта сначала идёт основная часть простым языком, затем блок `Технические детали`.
-10. **Основная часть замечания — главный ответ.** Пиши 1–3 коротких абзаца, и в эти же абзацы включай весь человеческий верх пункта: короткий контекст, понятный без чтения плана, diff и истории задачи; что происходит или что не подтверждено; почему это важно, какой практический риск и когда он проявится. Не начинай с имён классов, методов, строк, SQL, DTO, конфигов и внутренних деталей.
-11. **Технические детали — ниже основной части.** Там укажи тип, рекомендацию, файлы/строки, что в коде подтверждает проблему, общий подход к исправлению и конкретные шаги. Если деталь не помогает понять или исправить проблему — не пиши её.
-
-## Стиль замечаний
-
-Пиши так, чтобы первый экран пункта можно было прочитать без глубокого знания кода и без знания плана, diff или истории задачи: в 1–3 коротких абзацах объясни контекст, ситуацию, риск и когда он проявится; затем дай `Технические детали`. Не растягивай пункт, не пересказывай весь diff и не начинай с имён классов, методов, строк, SQL, DTO, конфигов.
-
-## Интерактивные вопросы
-
-Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос о цели ревью**. Вопрос о плане не задавай никогда: если план не указан и не найден однозначно, ревьюй без сверки с планом. Примеры понятного контекста:
-- пользователь указал файл, папку, PR, ветку или тип diff;
-- в запросе есть «ревью незакоммиченных изменений», «ревью текущей ветки», «проверь PR #N»;
-- в рабочем дереве есть незакоммиченные изменения и пользователь просит «сделай ревью» без других целей.
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-
-## Этапы
-
-### 1. Выбрать вход и прочитать контекст
-Сначала попробуй определить цель ревью без вопроса:
-- если пользователь указал файл, папку, PR, ветку или тип diff — используй это;
-- если пользователь просит ревью без уточнений и есть незакоммиченные изменения — используй `git diff HEAD`;
-- если незакоммиченных изменений нет, но текущая ветка не `main`/`master` и отличается от базовой ветки — используй `git diff <base>...HEAD`, где `<base>` выбери из существующих `main`, `master`, `origin/main`, `origin/master`;
-- если цель всё ещё неоднозначна или diff пустой — только тогда через `AskUserQuestion` спроси, что ревьюим: незакоммиченный diff (`git diff HEAD`) / diff ветки от main (`git diff main...HEAD`) / конкретный файл или папка / номер PR.
-
-Получи diff/исходник в `$TARGET`. Прочитай `docs/rules.md`, `docs/arch.md` и строго следуй им.
-
-Определи `$PLAN_FILE`, не задавая вопросов о плане:
-- если пользователь указал путь к плану — используй его;
-- если в diff, описании задачи или уже существующем review-файле есть однозначная ссылка на `docs/plans/...` — используй её;
-- иначе (план не указан, не найден или вариантов несколько) — установи `$PLAN_FILE=none` и ревьюй без сверки с планом. Не подставляй «последний план» наугад.
-
-Если в diff видно отсылки к исследованию из `docs/researches/` — прочитай его тоже.
-
-### 2. Сделать первичное ревью и сохранить
-Пройдись по изменениям. Если `$PLAN_FILE` указывает на файл, сначала проверь, выполнен ли план, но в ревью выноси только проблемы: что сделано частично, что не сделано, какие отклонения создают риск, какие проверки отсутствуют. Если `$PLAN_FILE=none`, не делай проверку плана и не пытайся восстановить план из последних файлов. Не перечисляй выполненные пункты плана. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию. Если `review.include_code_quality: true` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
-
-Каждое замечание должно быть самостоятельным блоком:
-- заголовок с номером и коротким смыслом;
-- основная часть простым языком: 1–3 коротких абзаца, которые включают контекст, проблему и риск без привязки к конкретному коду;
-- `Технические детали`: тип, рекомендация, конкретные файлы/строки, что именно в коде подтверждает проблему, как исправить и какие тесты добавить или обновить.
-
-Поставь оценку 0–100 (100 — идеально, 0 — переделывать).
-
-Сохрани в `docs/reviews/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Соблюдай этот формат буквально: каждый пункт сначала читается как короткий человеческий ответ, а технические детали идут ниже отдельным блоком.
-
-```markdown
----
-title: <заголовок>
-date: <YYYY-MM-DD HH:MM>
-target: <git diff HEAD | main...HEAD | path | PR#>
-plan: <docs/plans/... | none>
-mode: <draft | normal | strict>
-score: <0..100>
-status: draft
-meta_reviewers: []
----
-
-# Ревью: <заголовок>
-
-## Оценка
-
-**<N>/100.** <одно-два предложения почему>
-
-## Проблемы сверки с планом
-
-<Если `$PLAN_FILE=none`: «Проверка плана пропущена: план не указан и не найден.» Если проблем по плану нет: «Явных проблем по плану не найдено.»>
-
-### 1. <недоделка, отклонение или непроверенный пункт>
-
-<1–3 коротких абзаца: короткий контекст, понятный без плана, diff и истории задачи; что требовал план; что не сделано или не подтверждено; почему это важно, какой риск и когда он проявится. Без имён файлов, строк и внутренних деталей в начале пункта.>
-
-Технические детали:
-
-- **Статус:** <частично | не выполнено | не проверялось | отклонение>
-- **Где:** `<path/file.ts:42>` — <что смотреть>
-- **Что подтверждает проблему:** <конкретная деталь по коду, diff или плану>
-- **Как исправить:** <общий подход и конкретные шаги по коду/тестам>
-
-## Замечания
-
-<Если замечаний нет: «Явных проблем в коде не найдено.»>
-
-### 1. <короткий заголовок проблемы>
-
-<1–3 коротких абзаца: короткий контекст, понятный без плана, diff и истории задачи; что происходит; почему это проблема; какой практический риск и когда он проявится. Без технической перегрузки и без пересказа diff.>
-
-Технические детали:
-
-- **Тип:** `bug | security | performance | architecture | rules | tests | quality | docs`
-- **Рекомендация:** `править обязательно | на усмотрение автора`
-- **Где:** `<path/file.py:42>` — <что смотреть>
-- **Что подтверждает проблему:** <конкретное объяснение по коду>
-- **Как исправить:** <общий подход, затем конкретные шаги по файлам>
-- **Тесты:** <какой тест добавить или обновить; если тест не нужен, почему>
-
-## Рекомендации
-
-- **Править обязательно:** <номера>
-- **На усмотрение автора:** <номера>
-
-## Изменения после мета-ревью
-
-<заполняется на этапах 3 и 4>
-```
-
-Покажи путь.
-
-Если режим `draft` — не запускай субагентов и не вызывай `eda-review-check`; сразу переходи к финалу draft.
-
-### 3. Проверить ревью через `eda-review-check`
-В normal/strict запусти `eda-review-check` для `$REVIEW_FILE` и передай выбранный режим (`normal` или `strict`). Именно `eda-review-check` запускает `architecture-check`, `rules-check`, а если `plan` в front matter указывает на файл — ещё и `plan-check`; при включённой настройке `quality-check` тоже запускается. Затем `eda-review-check` обновляет `status`, `meta_reviewers`, `score` и раздел `## Изменения после мета-ревью`.
-
-Требования к средам остаются частью контракта ревью: Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), используй его; не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны. Codex exec / неинтерактивный fallback допустим только как fallback и описан в `eda-review-check`. Кросс-CLI выполняет только `eda-review-check strict`.
-
-### 4. Финал
-Короткое сообщение: режим (`draft`, `normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение». Не пересказывай выполненную работу. Если режим был `draft` — добавь строку «мета-ревью не запускалось; для проверки — `eda-review-check <review>`». Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review-check strict <review>`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
-
-## Чего НЕ делать
-- Править код. Это `eda-fix-by-review`.
-- Пропускать `eda-review-check` в normal/strict. Исключение — явный режим `draft`.
-- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом остальных. Все обязательные проверки стартуют сразу.
-- Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
-- Вставлять чужие предложения механически — каждое решение принимай ты.
-- Задавать вопросы без блокировки и продолжать работу до ответа.
-- Сохранять ревью куда-либо кроме `docs/reviews/`.
-- Оформлять замечания без контекста перед конкретикой.
-- Перечислять выполненные пункты плана или давать общий отчёт о проделанной работе.

package/skills/eda-start.md

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