@gian-tiaga/eda 0.2.0

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

@@ -0,0 +1,86 @@
+---
+name: eda-fix-by-review
+description: Применяет замечания из ревью (`docs/reviews/...`) к коду. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает через AskUserQuestion; «не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью (это `eda-review`), не коммитит (это `eda-commit`). Все вопросы — через AskUserQuestion.
+---
+
+# Скил: Исправитель по ревью (eda-fix-by-review)
+
+Берёшь готовое ревью из `docs/reviews/`, применяешь замечания к коду, сохраняешь отчёт о фиксах в `docs/review-fixes/`. После всех правок — полный прогон тестов и линтеров.
+
+## Главные правила
+
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Это рамка проекта. Один раз в начале.
+2. **Все вопросы — через `AskUserQuestion`** (в Codex — короткий нумерованный список).
+3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
+4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
+5. **Логика по группам ревью:**
+   - «Править обязательно» — правишь сразу, без вопросов.
+   - «На усмотрение автора» — спроси через `AskUserQuestion` (объединяй до 4 пунктов за раунд: применить / пропустить / переформулировать).
+   - «Не править» — пропускаешь молча, в отчёте отметь как «осознанно не применено».
+6. **Тесты — внутри той же правки.** Замечание касается поведения → правка кода + тесты к ней в одном шаге, точечно прогнал.
+7. **Финальный полный прогон тестов и линтеров — обязателен.** В конце, не на каждой правке.
+8. **Простой язык** в формулировках и сообщениях. **Таблицы** для отчёта о фиксах.
+
+## Этапы
+
+### 1. Выбрать ревью
+Если путь не передан — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Получи `$REVIEW_FILE`.
+
+### 2. Прочитать контекст
+`docs/rules.md`, `docs/arch.md` (если есть). Сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
+
+### 3. Применить замечания
+Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
+- **Править обязательно** → правишь сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
+- **На усмотрение автора** → собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя.
+- **Не править** → пропусти.
+
+Останавливайся и спрашивай, если: замечание непонятно / противоречит коду / задевает рискованное вне ревью (удаление, миграции, секреты).
+
+### 4. Финальная проверка
+Прогони полный сьют тестов и линтеры. Команды — стандартные для стека; непонятно — `AskUserQuestion`. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`.
+
+### 5. Сохранить отчёт о фиксах и связать с ревью
+Сохрани отчёт в `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же что у ревью или близкий). Затем **допиши в конец файла ревью** (`$REVIEW_FILE`) раздел со ссылкой:
+
+```markdown
+## Применённые фиксы
+Отчёт: `docs/review-fixes/{file}.md`
+```
+
+Шаблон отчёта:
+
+```markdown
+---
+review: <путь к docs/reviews/...>
+date: <YYYY-MM-DD HH:MM>
+status: done
+---
+
+# Фиксы по ревью: <заголовок>
+
+## Применённые правки
+| # | Замечание | Файлы | Тесты | Статус |
+|---|-----------|-------|-------|--------|
+| 1 | <кратко из ревью> | `path/a.py` | `path/test_a.py` (2 ✓) | ✓ применено |
+| 2 | ... | ... | — | ✓ применено |
+| 3 | ... | — | — | ✗ пропущено (на усмотрение, пользователь отклонил) |
+| 4 | ... | — | — | — не править (по решению ревью) |
+
+## Финальная проверка
+- **Тесты:** `<команда>` — ✓ / ✗
+- **Линтер:** `<команда>` — ✓ / ✗
+- **Заметки:** <если что-то осталось не зелёным — почему>
+```
+
+### 6. Финал
+Короткое сообщение: путь к ревью, путь к отчёту о фиксах, сколько применено / пропущено / отклонено, результат финальной проверки, состояние git («не закоммичено»). Подсказка дальше — `eda-commit`.
+
+## Чего НЕ делать
+- Делать само ревью — это `eda-review`.
+- Коммитить, пушить — это `eda-commit`.
+- Применять «на усмотрение» молча — только через `AskUserQuestion`.
+- Игнорировать «не править» и пробовать «на всякий случай» — это нарушает решение ревью.
+- Гонять полный сьют и линтеры на каждой правке — только в конце.
+- Пропускать финальную проверку.
+- Сохранять отчёт куда-либо кроме `docs/review-fixes/`.

package/docs/skills/eda-plan.md

@@ -0,0 +1,118 @@
+---
+name: eda-plan
+description: Написание плана реализации через стандартный Plan Mode (Claude Code / Codex). Перед планированием подтягивает docs/rules.md, docs/arch.md, при необходимости — релевантное исследование. Согласованный план сохраняется в docs/plans/. Всегда проверяет план тремя параллельными моделями (слабая, средняя, мощная) на реалистичность, пропущенные шаги, нарушения правил и риски — главный планировщик сам решает, что добавить/убрать. В `strict` — ещё и кросс-CLI (Claude ↔ Codex). Все вопросы — через AskUserQuestion.
+---
+
+# Скил: Планировщик (eda-plan)
+
+Собираешь контекст, прогоняешь задачу через **стандартный Plan Mode** хост-агента, сохраняешь план в файл. Затем три параллельные модели проверяют план на реалистичность — главный планировщик сам решает, что применить из их предложений. При `strict` — ещё и кросс-CLI на втором круге.
+
+## Режимы вызова
+
+| Режим | Запуск | Что делает |
+|---|---|---|
+| Обычный | `eda-plan <тема>` | Этапы 1–6 + финал. Кросс-CLI не запускается. |
+| Строгий | `eda-plan strict <тема>` | + кросс-CLI соседним агентом + допил. |
+
+## Главные правила
+
+1. **Никаких правок кода.** Запись только в `docs/plans/`.
+2. **Все вопросы — через `AskUserQuestion`** (в Codex, если его нет — короткий нумерованный список).
+3. **Plan Mode — главный инструмент.** Не изобретай свой формат планирования поверх — используй то, что Plan Mode даёт.
+4. **Не переформулируй запрос пользователя** перед Plan Mode. Уйдёт оригинал + ответы на уточнения. Своя цель/критерии разводят смысл.
+5. **План сохраняется в файл до любой верификации** — иначе ревьюеру нечего читать.
+6. **Простой язык** в сообщениях, вопросах, шапке плана. Термины — только если без них нельзя, и сразу с пояснением. Текст самого Plan Mode не переписывай.
+7. **Диаграммы — желательно, не любой ценой.** Линейный план — диаграмма не нужна.
+8. **Таблицы > сплошной текст** для структурируемых данных.
+
+## Этапы
+
+### 1. Подтянуть контекст
+Прочитай `docs/rules.md`, `docs/arch.md` (если есть). Через `AskUserQuestion` спроси про релевантное исследование — покажи последние файлы из `docs/researches/` + опция «нет».
+
+### 2. Уточнить, если есть неясность
+Не переформулируй запрос. Если есть конкретная неясность, без которой планировать нельзя — задай 1–4 точечных вопроса через `AskUserQuestion`. Не задавай «на всякий случай». Пары «вопрос → ответ» сохрани — они идут в Plan Mode.
+
+### 3. Спланировать через Plan Mode
+Войди в Plan Mode хост-агента (`EnterPlanMode` в Claude Code, встроенный план-режим в Codex). На вход:
+1. Дословный запрос пользователя.
+2. Пары «вопрос → ответ» из этапа 2.
+3. Ссылки на `docs/rules.md`, `docs/arch.md`, исследование (без пересказа — Plan Mode прочитает сам).
+4. Инструкция: «все вопросы пользователю — только через `AskUserQuestion`, никаких догадок и свободного текста».
+
+Не выходи, пока пользователь не подтвердил план.
+
+### 4. Сохранить файл
+`docs/plans/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Структура — **только YAML-шапка и текст плана от Plan Mode**, как он его выдал:
+
+```markdown
+---
+title: <заголовок>
+date: <YYYY-MM-DD HH:MM>
+mode: <normal | strict>
+status: <draft | meta-reviewed | reviewed>
+reviewer: <pending | none | claude | codex>
+meta_reviewers: []
+sources:
+  rules: <путь или —>
+  arch: <путь или —>
+  research: <путь или —>
+---
+
+<текст плана из Plan Mode дословно>
+```
+
+Покажи путь.
+
+### 5. Мета-ревью плана тремя моделями (параллельно)
+Запусти **в одном сообщении** трёх агентов на трёх разных моделях — слабая, средняя, мощная.
+
+| Среда | Слабая (быстрая) | Средняя (код) | Мощная (флагман) |
+|---|---|---|---|
+| Claude Code (`Agent` tool) | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
+| Codex CLI (`codex exec --model …`) | `gpt-5.4-mini` | `gpt-5.3-codex` | `gpt-5.5` |
+
+В Codex запускай три параллельных `codex exec --model <id>` через `Bash` с `&`. Если `gpt-5.5` недоступен (ограничение account/auth) — возьми `gpt-5.4` как мощную. Если какой-либо идентификатор отсутствует у тебя — возьми ближайший аналог того же тира из доступных в твоей версии Codex.
+
+Каждому передай путь к файлу плана и `docs/rules.md`, `docs/arch.md` (если есть). Попроси: «прочитай план; проверь, что шаги **реалистичны и не ломают ничего вокруг** — нет ли пропущенных шагов, неучтённых зависимостей, нарушений правил и архитектуры, рисков для смежного кода, шагов без критерия готовности. Верни список `+ N | − N | ~ N: причина` без воды.»
+
+Когда все три ответили — прочитай ответы, **сам реши**, что применять (не вставляй чужие пункты механически). Внеси правки в файл плана. Допиши в конец раздел:
+
+```markdown
+## Изменения после мета-ревью
+
+### После моделей
+- **+ Добавлено:** ...
+- **− Убрано:** ...
+- **Отклонено:** ...
+```
+
+В YAML-шапке: `status: draft` → `meta-reviewed`, в `meta_reviewers` — имена/идентификаторы моделей.
+
+### 6. Кросс-CLI — только в `strict`
+Обычный режим — пропусти этапы 6–7, иди на финал.
+
+В `strict`: отдай файл соседнему агенту через `Bash`:
+
+```bash
+codex exec "Прочитай $PLAN_FILE. Критическое ревью на русском: пропущенные шаги, неучтённые зависимости, нарушения docs/rules.md и docs/arch.md, скрытые риски, шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
+# Если ты Codex — claude -p вместо codex exec.
+```
+
+Соседней CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.
+
+### 7. Допилить по ревью — только в `strict`
+Бесспорные замечания → правишь сразу. Спорные → `AskUserQuestion`. Отклонённые → оставляешь, причина в журнал. В конец файла добавь раздел `## Реакция на ревью` (Принято / Отклонено / Спорное). Поменяй `status: meta-reviewed` → `reviewed`. Покажи дифф.
+
+### 8. Финал
+Короткое сообщение: режим, путь к плану, путь к ревью (если был `strict`), 3–5 главных шагов простыми словами, что предлагаешь дальше (но не делай — это `eda-execute`).
+
+## Чего НЕ делать
+- Править код, запускать миграции.
+- Задавать вопросы свободным текстом.
+- Переформулировать запрос пользователя своими словами перед Plan Mode.
+- Пропускать сохранение файла плана.
+- Дублировать логику Plan Mode своим самописным форматом.
+- Пропускать мета-ревью тремя моделями — это часть обычного режима, не под флагом.
+- Вставлять предложения мета-ревьюеров механически — каждое решение принимаешь ты.
+- Пропускать кросс-CLI молча в `strict` (если CLI нет — спроси).

package/docs/skills/eda-research.md

@@ -0,0 +1,97 @@
+---
+name: eda-research
+description: Глубокое исследование темы или задачи. Без правки кода. Все вопросы — через AskUserQuestion. Mermaid-диаграммы и markdown-таблицы — там где это даёт ясность. Итог сохраняется в docs/researches/. По умолчанию без кросс-ревью; кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict`.
+---
+
+# Скил: Исследователь (eda-research)
+
+Разбираешься в теме, собираешь понятный отчёт. Не правишь код, не торопишься с выводами.
+
+## Режимы вызова
+
+| Режим | Запуск | Что делает |
+|---|---|---|
+| Обычный | `eda-research <тема>` | Этапы 1–4 + финал. |
+| Строгий | `eda-research strict <тема>` | + кросс-ревью соседним агентом + допил. |
+
+## Главные правила
+
+1. **Никаких правок кода.** Запись только в `docs/researches/`.
+2. **Все вопросы — через `AskUserQuestion`** (в Codex, если его нет — короткий нумерованный список).
+3. **Простой язык.** Термины — только когда без них нельзя, сразу с пояснением.
+4. **Каждое утверждение — со ссылкой** (`file.ext:42`, URL, коммит). Без ссылки — помечай как «гипотеза».
+5. **Диаграммы — желательно, не любой ценой.** Тема плоская — не выдумывай.
+6. **Таблицы > сплошной текст** для структурируемых данных.
+
+## Этапы
+
+### 1. Понять задачу
+Прочитай запрос. Сформулируй цель и 3–7 конкретных вопросов. Неясности — задай через `AskUserQuestion`. Не уходи дальше, пока цель не подтверждена.
+
+### 2. Собрать материал
+Включи explore / read-only режим хост-агента (в Claude Code — `EnterPlanMode`, в Codex — встроенный режим без правок). Инструменты выбирай сам, рамка одна — ничего не правишь в коде. Перед сохранением отчёта (этап 4) выйди из режима.
+
+### 3. Диаграммы (если уместно)
+Есть поток / связи / состояния / последовательность шагов — нарисуй 1–3 Mermaid-диаграммы. Подписи на русском. Если показывать нечего — в разделе диаграмм отчёта одна строка: «Не требуется — тема не имеет графовой структуры.»
+
+### 4. Собрать отчёт
+`docs/researches/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+
+```markdown
+---
+title: <заголовок>
+date: <YYYY-MM-DD HH:MM>
+mode: <normal | strict>
+status: <draft | reviewed>
+reviewer: <pending | none | claude | codex>
+---
+
+# <Заголовок>
+
+## 1. Цель и вопросы
+**Цель:** ...
+**Вопросы:** 1) ... 2) ...
+
+## 2. Диаграммы
+<Mermaid или строка про «не требуется»>
+
+## 3. Находки
+| # | Факт | Источник | Что это значит |
+|---|------|----------|-----------------|
+
+## 4. Риски и открытые вопросы
+| Риск/неясность | Почему важно | Что предлагаешь |
+|----------------|---------------|------------------|
+
+## 5. Итог
+<3–7 предложений простыми словами>
+```
+
+Покажи путь.
+
+### 5. Кросс-ревью — только в `strict`
+Обычный режим — пропусти этапы 5–6, иди на финал. `reviewer: none`, `status: draft`.
+
+В `strict`: отдай файл соседнему агенту через `Bash`:
+
+```bash
+codex exec "Прочитай $RESEARCH_FILE. Критическое ревью на русском: фактические ошибки, пропущенные риски, неподтверждённые утверждения, неточности диаграмм. Список '- [тип] описание — что предлагаешь'." > "${RESEARCH_FILE%.md}_review.md"
+# Если ты Codex — claude -p вместо codex exec.
+```
+
+CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.
+
+### 6. Допилить по ревью — только в `strict`
+Бесспорные → правишь. Спорные → `AskUserQuestion`. Отклонённые → оставляешь с причиной. В конец отчёта раздел `## 6. Реакция на ревью` (Принято / Отклонено / Спорное). `status: reviewed`. Покажи дифф.
+
+### 7. Финал
+Короткое сообщение: режим, путь к отчёту, путь к ревью (если `strict`), 3–5 главных выводов простыми словами, что предлагаешь дальше (но не делай — это работа другого скила).
+
+## Чего НЕ делать
+- Править код, запускать миграции, менять конфиги.
+- Задавать вопросы свободным текстом.
+- Делать выводы без ссылок на источник.
+- Пропускать кросс-ревью молча в `strict`.
+- Сохранять отчёт куда-либо кроме `docs/researches/`.
+- Рисовать диаграмму ради галочки.
+- Оформлять структурируемые данные сплошным текстом.

package/docs/skills/eda-review.md

@@ -0,0 +1,124 @@
+---
+name: eda-review
+description: Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл). Формирует пронумерованные замечания, оценку 0–100, рекомендации «править / на усмотрение / не править». Сохраняет в docs/reviews/. Всегда проверяет своё же ревью тремя параллельными моделями (Sonnet, Haiku, Opus); кросс-CLI (Claude ↔ Codex) включается только флагом `strict`. После каждой проверки сам корректирует ревью. Не правит код — это `eda-fix-by-review`. Все вопросы — через AskUserQuestion.
+---
+
+# Скил: Ревьюер (eda-review)
+
+Делаешь ревью изменений: пишешь замечания, ставишь оценку, сохраняешь файл. Затем проверяешь сам себя через три параллельные модели; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
+
+## Режимы вызова
+
+| Режим | Запуск | Что делает |
+|---|---|---|
+| Обычный | `eda-review` | Этапы 1–3 + финал. Кросс-CLI не запускается. |
+| Строгий | `eda-review strict` | + кросс-CLI соседним агентом + допил. |
+
+## Главные правила
+
+1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Замечания должны опираться на правила проекта, а не на твои общие представления.
+2. **Все вопросы — через `AskUserQuestion`** (в Codex — короткий нумерованный список).
+3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
+4. **Мета-ревью тремя моделями — обязательно**, без флага. Кросс-CLI — только в `strict`.
+5. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
+6. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
+7. **Таблицы для замечаний.** Сплошной текст — только для оценки и общего вывода.
+
+## Этапы
+
+### 1. Выбрать вход и прочитать контекст
+Через `AskUserQuestion` спроси, что ревьюим: незакоммиченный diff (`git diff HEAD`) / diff ветки от main (`git diff main...HEAD`) / конкретный файл или папка / номер PR. Получи diff/исходник в `$TARGET`. Прочитай `docs/rules.md`, `docs/arch.md`. Если в diff видно отсылки к плану из `docs/plans/` или исследованию из `docs/researches/` — прочитай их тоже.
+
+### 2. Сделать первичное ревью и сохранить
+Пройдись по изменениям. Замечания группируй по типу: bug / архитектура / стиль / тесты / безопасность / производительность / документация. Каждое — с локацией (`file:line`) и предложением «что сделать». Поставь оценку 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#>
+mode: <normal | strict>
+score: <0..100>
+status: draft
+meta_reviewers: []
+---
+
+# Ревью: <заголовок>
+
+## Оценка
+**<N>/100.** <одно-два предложения почему>
+
+## Замечания
+| # | Тип | Где | Что не так | Что предлагаешь |
+|---|-----|-----|------------|-----------------|
+| 1 | bug | `path/file.py:42` | ... | ... |
+
+## Рекомендации
+- **Править обязательно:** <номера>
+- **На усмотрение автора:** <номера>
+- **Не править:** <номера или —>
+
+## Изменения после мета-ревью
+<заполняется на этапах 3 и 4>
+```
+
+Покажи путь.
+
+### 3. Мета-ревью тремя моделями (параллельно)
+Запусти **в одном сообщении** трёх агентов на трёх разных моделях — слабая, средняя, мощная.
+
+| Среда | Слабая (быстрая) | Средняя (код) | Мощная (флагман) |
+|---|---|---|---|
+| Claude Code (`Agent` tool) | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
+| Codex CLI (`codex exec --model …`) | `gpt-5.4-mini` | `gpt-5.3-codex` | `gpt-5.5` |
+
+В Codex — три параллельных `codex exec --model <id>` через `Bash` с `&`. Если `gpt-5.5` недоступен (ограничение account/auth) — возьми `gpt-5.4` как мощную. Если какой-либо идентификатор отсутствует у тебя — возьми ближайший аналог того же тира из доступных в твоей версии Codex.
+
+Каждому дай путь к файлу ревью + указание на `$TARGET` и попроси: «прочитай ревью и diff; предложи, какие пункты добавить (которых не хватает), какие убрать (избыточные/неверные), какие переформулировать. Список `+ N | − N | ~ N: причина`. Без воды.»
+
+Когда все три ответили: прочитай ответы, **сам реши**, что применять. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
+
+```markdown
+### После Sonnet/Haiku/Opus
+- **+ Добавлено:** <короткий список>
+- **− Убрано:** <короткий список>
+- **Отклонено:** <короткий список с причиной>
+```
+
+Поменяй `status: draft` → `meta-reviewed`, в `meta_reviewers` добавь `sonnet, haiku, opus`. Если оценка после корректировок изменилась — обнови `score`.
+
+### 4. Кросс-CLI: отдать соседнему агенту — только в `strict`
+Обычный режим — пропусти этап 4, иди на финал. `status: meta-reviewed` оставь как есть.
+
+В `strict`: если ты Claude → отдай Codex, и наоборот. Передай путь к файлу ревью и `$TARGET`:
+
+```bash
+codex exec "Прочитай $REVIEW_FILE и $TARGET. Мета-ревью на русском: какие пункты добавить, убрать, переформулировать. Список '+ N | − N | ~ N: причина'." > "${REVIEW_FILE%.md}_cli_meta.md"
+```
+
+Соседней CLI нет — `AskUserQuestion`: завершить как есть или прервать.
+
+Прочитай ответ, **сам реши**, что применять. Допиши в `## Изменения после мета-ревью`:
+
+```markdown
+### После соседнего CLI (codex|claude)
+- **+ Добавлено:** ...
+- **− Убрано:** ...
+- **Отклонено:** ...
+```
+
+Добавь в `meta_reviewers` имя CLI. `status: meta-reviewed` → `final`.
+
+### 5. Финал
+Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение» / «не править». Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review strict`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
+
+## Чего НЕ делать
+- Править код. Это `eda-fix-by-review`.
+- Пропускать мета-ревью тремя моделями (это часть обычного режима, не под флагом).
+- Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
+- Вставлять чужие предложения механически — каждое решение принимай ты.
+- Задавать вопросы свободным текстом.
+- Сохранять ревью куда-либо кроме `docs/reviews/`.
+- Оформлять замечания сплошным текстом — только таблица.

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

@@ -0,0 +1,90 @@
+---
+name: eda-send-review
+description: Отправляет ревью из `docs/reviews/...` на GitHub PR через `gh` — как review (comment/approve/request-changes) или как обычный комментарий. Целевой PR определяется автоматически по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку на PR-комментарий. Не правит код, не делает само ревью. Все вопросы — через AskUserQuestion.
+---
+
+# Скил: Отправитель ревью (eda-send-review)
+
+Берёшь готовое ревью из `docs/reviews/`, отправляешь его на GitHub PR через `gh`. В конец файла ревью дописываешь, куда отправил.
+
+## Главные правила
+
+1. **Все вопросы — через `AskUserQuestion`** (в Codex — короткий нумерованный список).
+2. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
+3. **Никаких самостоятельных оценок.** Тип отправки (comment / approve / request-changes) определяется на основе ревью + подтверждается пользователем.
+4. **Простой язык.** В сообщениях пользователю и комментарии PR без лишних терминов.
+
+## Этапы
+
+### 1. Проверить инструменты
+`gh --version` + `gh auth status`. Если `gh` отсутствует или не авторизован — остановись, сообщи и выйди (это пользователю нужно решить).
+
+### 2. Выбрать ревью
+Если путь не передан — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Прочитай файл целиком: оценку, замечания, рекомендации.
+
+### 3. Найти целевой PR
+Попробуй `gh pr view --json number,url,headRefName` — если у текущей ветки уже есть PR, возьми его номер.
+
+Если PR нет — `AskUserQuestion`: «PR ещё нет: создать PR из текущей ветки / указать номер существующего PR / прервать». При создании используй `gh pr create` (заголовок и тело — по последним коммитам ветки).
+
+### 4. Выбрать тип отправки
+Предложи вариант на основе оценки в ревью:
+- score ≥ 80 → предложить **approve** (с комментарием).
+- score < 50 → предложить **request-changes**.
+- иначе → **comment** (review без статуса).
+
+`AskUserQuestion`: подтвердить предложенный тип / выбрать другой / отправить как обычный комментарий PR (вне review).
+
+### 5. Сформировать тело
+Структура комментария:
+
+```markdown
+## Ревью: <заголовок>
+
+**Оценка:** N/100. <одно-два предложения почему>
+
+### Замечания
+1. **[тип]** `path/file.py:42` — <что не так>. → <что предлагаешь>
+2. ...
+
+### Рекомендации
+- **Править обязательно:** 1, 3, 5
+- **На усмотрение автора:** 2, 4
+- **Не править:** —
+
+_Сгенерировано из `<путь к docs/reviews/...>`_
+```
+
+### 6. Отправить
+По выбранному типу:
+
+| Тип | Команда |
+|---|---|
+| comment (PR comment) | `gh pr comment <num> --body-file <tmpfile>` |
+| review-comment | `gh pr review <num> --comment --body-file <tmpfile>` |
+| approve | `gh pr review <num> --approve --body-file <tmpfile>` |
+| request-changes | `gh pr review <num> --request-changes --body-file <tmpfile>` |
+
+Тело пиши во временный файл (`mktemp`) и передавай через `--body-file` — иначе спецсимволы и переносы поедут не туда.
+
+Если команда упала — покажи вывод пользователю и спроси через `AskUserQuestion` (повторить / другой тип / прервать).
+
+### 7. Дописать ссылку в файл ревью
+В конец `$REVIEW_FILE` добавь:
+
+```markdown
+## Отправлено
+- PR: <URL из ответа gh>
+- Тип: <comment | review-comment | approve | request-changes>
+- Дата: <YYYY-MM-DD HH:MM>
+```
+
+### 8. Финал
+Короткое сообщение: PR-номер и URL, тип отправки, путь к файлу ревью.
+
+## Чего НЕ делать
+- Делать само ревью или править замечания — это `eda-review` / `eda-fix-by-review`.
+- Отправлять `approve` без явного подтверждения через `AskUserQuestion`, даже если оценка ≥ 80.
+- Передавать тело комментария через `-b "..."` со спецсимволами без `--body-file` — поломает форматирование.
+- Создавать PR молча, если его нет — только через `AskUserQuestion`.
+- Сохранять копии отправленного в отдельные файлы — связь через ссылку в файле ревью.

package/lib/install.js

@@ -0,0 +1,108 @@
+import fs from 'node:fs/promises';
+import path from 'node:path';
+import readline from 'node:readline/promises';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+const PACKAGE_ROOT = path.resolve(__dirname, '..');
+const SKILLS_SRC = path.join(PACKAGE_ROOT, 'docs/skills');
+
+export async function init({ cwd }) {
+  const targets = await askTargets();
+  if (targets.length === 0) {
+    process.stdout.write('Ничего не выбрано — выходим.\n');
+    return;
+  }
+  await syncSkills(cwd, targets);
+}
+
+export async function update({ cwd }) {
+  const targets = await detectTargets(cwd);
+  if (targets.length === 0) {
+    process.stdout.write('Не нашёл установленных скилов в этом проекте. Запусти `eda init`.\n');
+    return;
+  }
+  process.stdout.write(`Найдены установленные среды: ${targets.join(', ')}\n`);
+  await syncSkills(cwd, targets);
+}
+
+async function askTargets() {
+  const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
+  const answer = await rl.question(
+    'Куда устанавливать скилы?\n' +
+    '  [1] Claude Code (.claude/skills/)\n' +
+    '  [2] Codex CLI (.codex/skills/)\n' +
+    '  [3] Обе среды\n' +
+    'Выбор [3]: '
+  );
+  rl.close();
+  const choice = answer.trim() || '3';
+  switch (choice) {
+    case '1': return ['claude'];
+    case '2': return ['codex'];
+    case '3': return ['claude', 'codex'];
+    default:
+      process.stdout.write(`Неизвестный выбор «${choice}» — выходим.\n`);
+      return [];
+  }
+}
+
+async function detectTargets(cwd) {
+  const targets = [];
+  if (await dirExists(path.join(cwd, '.claude/skills'))) targets.push('claude');
+  if (await dirExists(path.join(cwd, '.codex/skills'))) targets.push('codex');
+  return targets;
+}
+
+async function syncSkills(cwd, targets) {
+  const skills = await listSkills();
+  if (skills.length === 0) {
+    throw new Error(`В пакете нет скилов (искал в ${SKILLS_SRC}).`);
+  }
+  process.stdout.write(`Скилы для установки: ${skills.map(s => s.name).join(', ')}\n`);
+
+  if (targets.includes('claude')) await installToClaude(cwd, skills);
+  if (targets.includes('codex')) await installToCodex(cwd, skills);
+
+  process.stdout.write('\nГотово.\n');
+}
+
+async function listSkills() {
+  const entries = await fs.readdir(SKILLS_SRC);
+  return entries
+    .filter(f => f.endsWith('.md'))
+    .map(f => ({ name: f.replace(/\.md$/, ''), path: path.join(SKILLS_SRC, f) }))
+    .sort((a, b) => a.name.localeCompare(b.name));
+}
+
+async function installToClaude(cwd, skills) {
+  const dst = path.join(cwd, '.claude/skills');
+  await fs.mkdir(dst, { recursive: true });
+  for (const skill of skills) {
+    const skillDir = path.join(dst, skill.name);
+    await fs.mkdir(skillDir, { recursive: true });
+    const content = await fs.readFile(skill.path, 'utf-8');
+    await fs.writeFile(path.join(skillDir, 'SKILL.md'), content);
+  }
+  process.stdout.write(`  ✓ Claude Code: ${dst}\n`);
+}
+
+async function installToCodex(cwd, skills) {
+  const dst = path.join(cwd, '.codex/skills');
+  await fs.mkdir(dst, { recursive: true });
+  for (const skill of skills) {
+    const content = await fs.readFile(skill.path, 'utf-8');
+    await fs.writeFile(path.join(dst, `${skill.name}.md`), content);
+  }
+  process.stdout.write(`  ✓ Codex CLI: ${dst}\n`);
+}
+
+async function dirExists(p) {
+  try {
+    const st = await fs.stat(p);
+    return st.isDirectory();
+  } catch {
+    return false;
+  }
+}