@gian-tiaga/eda 0.2.7 → 0.2.8

package/README.md

@@ -3,7 +3,7 @@
 > Поточная разработка с AI-агентами — на русском языке.
 > Набор готовых скилов для **Claude Code** и **Codex CLI**, которые ведут тебя через весь цикл: от исследования до коммита.
 
-`eda` — это девять скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
+`eda` — это десять скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
 
 ---
 
@@ -19,7 +19,7 @@ npm install -g @gian-tiaga/eda
 eda init
 ```
 
-Скил спросит, куда ставить — в Claude Code, в Codex или в обе среды сразу. Дальше можно работать.
+Установщик покажет чекбоксы: стрелками выбираешь среду, пробелом отмечаешь, Enter продолжает. Можно поставить Claude Code, Codex CLI или обе среды сразу.
 
 ---
 
@@ -30,6 +30,7 @@ eda init
 | `eda-research` | Глубоко изучает тему или задачу. Без правок кода. Все вопросы — через интерактивный диалог. На выходе — понятный отчёт со ссылками на источники, диаграммами и таблицами | `docs/researches/` |
 | `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. Подтягивает контекст из `docs/rules.md`, `docs/arch.md`, при желании — релевантное исследование. Затем три параллельных модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
 | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
+| `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
 | `eda-review` | Делает код-ревью с оценкой 0–100. Затем три параллельных модели (Sonnet, Haiku, Opus) проверяют само ревью — добавляют пропущенное, убирают лишнее. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
 | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
 | `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
@@ -59,12 +60,15 @@ eda init
 flowchart LR
     R[🔍 research] --> P[📝 plan]
     P --> E[⚙️ execute]
-    E --> V[🧐 review]
+    E --> X[🛠️ fix]
+    X --> V[🧐 review]
+    E --> V
     V --> F[🛠️ fix-by-review]
     F --> S[📤 send-review]
     F --> C[💾 commit]
     V -.-> A[⚡ automate]
     F -.-> A
+    X -.-> A
     D[📚 docs] -.-> P
     D -.-> E
 ```

package/docs/skills/eda-automate.md

@@ -1,26 +1,26 @@
 ---
 name: eda-automate
-description: 'Анализирует историю `docs/reviews/` и `docs/review-fixes/`, а с аргументом `plans` ещё и `docs/plans/`. Ищет повторяющиеся замечания и проблемы планирования, предлагает автоматизации — кастомные правила линтеров, статанализаторов, pre-commit-проверок или checks для планов. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет автоматизации — выдаёт приоритезированный список с черновиками правил. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Все вопросы — через интерактивный вопрос.'
+description: 'Анализирует историю `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`, а с аргументом `plans` ещё и `docs/plans/`. Ищет повторяющиеся замечания, фиксы и проблемы планирования, предлагает автоматизации, а также черновики дополнений для `docs/rules.md` и `docs/arch.md`. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет изменения — выдаёт приоритезированный список с черновиками правил, проверок и правок документации. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Все вопросы — через интерактивный вопрос.'
 ---
 
 # Скил: Автоматизатор (eda-automate)
 
-Читаешь историю ревью и фиксов, находишь повторяющиеся замечания, предлагаешь, какие из них можно поймать автоматически: кастомным правилом линтера, статанализатора, pre-commit-проверкой. Если передан аргумент `plans`, дополнительно читаешь планы из `docs/plans/` и ищешь повторяющиеся проблемы планирования, которые можно ловить автоматической проверкой плана. Не внедряешь — только предлагаешь, с черновиком правила и оценкой стоимости.
+Читаешь историю ревью и фиксов, находишь повторяющиеся замечания и исправления, предлагаешь, какие из них можно поймать автоматически: кастомным правилом линтера, статанализатора, pre-commit-проверкой. Также предлагаешь, что стоит дописать в `docs/rules.md` или `docs/arch.md`, если повторяющийся паттерн лучше закрепить правилом проекта или архитектурным описанием. Если передан аргумент `plans`, дополнительно читаешь планы из `docs/plans/` и ищешь повторяющиеся проблемы планирования, которые можно ловить автоматической проверкой плана. Не внедряешь — только предлагаешь, с черновиками и оценкой стоимости.
 
 ## Режимы вызова
 
 | Режим | Запуск | Что анализирует |
 |---|---|---|
-| Обычный | `eda-automate` | `docs/reviews/` + `docs/review-fixes/` |
-| С планами | `eda-automate plans` | `docs/reviews/` + `docs/review-fixes/` + `docs/plans/` |
+| Обычный | `eda-automate` | `docs/reviews/` + `docs/review-fixes/` + `docs/fixes/` |
+| С планами | `eda-automate plans` | `docs/reviews/` + `docs/review-fixes/` + `docs/fixes/` + `docs/plans/` |
 
 ## Главные правила
 
 1. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть. Не предлагай то, что уже зафиксировано как автоматизированное правило.
 2. **Интерактивные вопросы** — по разделу ниже.
-3. **Не внедряешь автоматизации.** Только отчёт с предложениями. Внедрение — `eda-plan` + `eda-execute`.
+3. **Не внедряешь изменения.** Только отчёт с предложениями. Внедрение автоматизаций или правок `docs/rules.md`/`docs/arch.md` — через `eda-plan` + `eda-execute`.
 4. **Предлагай только повторяющееся.** Минимум — паттерн встречается в 2+ разных ревью или в 3+ местах одного. Единичные замечания не автоматизируем.
-5. **Каждое предложение — с черновиком правила.** Не «надо бы что-то сделать», а конкретный фрагмент: имя инструмента, имя правила, псевдокод/skeleton.
+5. **Каждое предложение — с черновиком.** Не «надо бы что-то сделать», а конкретный фрагмент: правило линтера, псевдокод/skeleton, текст для `docs/rules.md` или патч для `docs/arch.md`.
 6. **Простой язык. Таблицы** для приоритезации.
 7. **Планы анализируй только с аргументом `plans`.** Без него не читай `docs/plans/`, если пользователь не указал конкретные файлы планов.
 
@@ -38,16 +38,16 @@ description: 'Анализирует историю `docs/reviews/` и `docs/rev
 Определи режим по аргументам вызова. Если передан `plans`, включи планы в источники без отдельного вопроса.
 
 `AskUserQuestion`: какую историю анализировать.
-- Все ревью + фиксы (по умолчанию)
-- Все ревью + фиксы + планы (если передан `plans`)
+- Все ревью + фиксы по ревью + обычные фиксы (по умолчанию)
+- Все ревью + фиксы по ревью + обычные фиксы + планы (если передан `plans`)
 - Последние N (5/10/20)
 - За период (последние N дней)
 - Конкретные файлы
 
-Получи список файлов из `docs/reviews/` и `docs/review-fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`.
+Получи список файлов из `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`.
 
 ### 2. Прочитать контекст
-- Все выбранные ревью и отчёты о фиксах.
+- Все выбранные ревью, отчёты о фиксах по ревью и обычные фиксы.
 - В режиме `plans`: все выбранные планы из `docs/plans/`.
 - `docs/rules.md`, `docs/arch.md` (если есть).
 - Какие языки и фреймворки в проекте — определи сам.
@@ -59,23 +59,30 @@ description: 'Анализирует историю `docs/reviews/` и `docs/rev
 - Нарушения архитектурных границ (импорты не из API соседнего модуля).
 - Забытое: error handling, validation, очистка ресурсов.
 - Стиль: имена, форматирование, порядок.
+- Для обычных фиксов: повторяющиеся причины правок, одинаковые классы багов, места где агент регулярно вручную добавляет проверки/валидацию/guard clauses.
 - Для планов: пропущенные тесты, отсутствующая проверка после шага, слишком крупные шаги, шаги без файлов/модулей, противоречие `docs/rules.md` или `docs/arch.md`, нет критерия готовности, рискованные действия без rollback/backup.
 
-Для каждого паттерна собери: где встречался (ссылки на ревью), сколько раз, в каких файлах.
+Для каждого паттерна собери: где встречался (ссылки на источники), сколько раз, в каких файлах.
 
-### 4. Предложить автоматизации
-Для каждого паттерна выбери подходящий инструмент. Логика выбора:
+### 4. Предложить автоматизации и правки docs
+Для каждого паттерна выбери подходящий тип реакции. Один паттерн может дать 1–2 предложения, если нужны и правило в docs, и автоматическая проверка.
 
 1. Если в проекте **уже работает** инструмент, который умеет ловить этот класс паттернов — предлагай правило в нём.
 2. Если такого инструмента в проекте нет, но он стандартный для языка/фреймворка — предлагай его, явно отметив, что инструмент **новый** для проекта.
 3. **Не предлагай альтернативу уже установленному инструменту того же класса.** Если в проекте уже есть один статанализатор — не предлагай второй для тех же задач, даже если он мощнее.
 4. Для паттернов из планов предлагай проверку плана: скрипт, markdownlint-правило, pre-commit/check, CI-check или custom validator для `docs/plans/*.md`. Не притворяйся, что runtime-линтер кода поймает проблему, которая живёт только в тексте плана.
+5. Если паттерн повторяется потому, что правило проекта отсутствует, расплывчатое или противоречит практике — предложи дополнение к `docs/rules.md`.
+6. Если паттерн повторяется из-за неясной границы модулей, слоя, API, ownership, потоков данных или зависимостей — предложи правку `docs/arch.md`.
+7. Если правило уже есть в `docs/rules.md` или архитектура уже описана в `docs/arch.md`, не дублируй текст. Предлагай только уточнение, если текущая формулировка реально не закрывает повторяющийся случай.
 
 Каждое предложение содержит:
+- Тип: `automation` / `rules` / `architecture`.
 - Что ловит (одна-две фразы простым языком).
 - Где встречалось (ссылки на 2–3 источника: ревью, фиксы или планы).
-- Инструмент и тип правила. Если инструмент **новый** для проекта — пометка «требует установки».
-- **Черновик правила** — псевдокод или фрагмент конфигурации.
+- Для `automation`: инструмент и тип правила. Если инструмент **новый** для проекта — пометка «требует установки».
+- Для `rules`: целевой раздел `docs/rules.md` и черновик текста правила.
+- Для `architecture`: целевой раздел `docs/arch.md` и черновик текста или diff-блок.
+- **Черновик** — псевдокод, фрагмент конфигурации или markdown-текст.
 - Польза: `low` / `medium` / `high` (по частоте паттерна и вреду от пропуска).
 
 ### 5. Сохранить отчёт
@@ -84,19 +91,19 @@ description: 'Анализирует историю `docs/reviews/` и `docs/rev
 ```markdown
 ---
 date: <YYYY-MM-DD HH:MM>
-sources: [docs/reviews/..., docs/review-fixes/...]
+sources: [docs/reviews/..., docs/review-fixes/..., docs/fixes/...]
 mode: <normal | plans>
 status: draft
 ---
 
-# Предложения по автоматизации
+# Предложения по автоматизации и правилам
 
 ## Контекст
-- Проанализировано: N ревью + M фиксов + K планов
+- Проанализировано: N ревью + M фиксов по ревью + F обычных фиксов + K планов
 - Стек проекта: <по конфигам>
 - Уже работающие инструменты: <список>
 
-## Предложения
+## Автоматизации
 
 ### 1. <название паттерна>
 - **Что ловит:** ...
@@ -110,23 +117,36 @@ status: draft
 
 ### 2. ...
 
+## Правила и архитектура
+
+### 1. <название паттерна>
+- **Тип:** rules / architecture
+- **Куда:** `docs/rules.md` / `docs/arch.md`, раздел <название или «новый раздел»>
+- **Почему:** <какой повторяющийся паттерн закрывает>
+- **Встречалось в:** `docs/fixes/...` (×2), `docs/reviews/...` (×1)
+- **Черновик текста:**
+  ```markdown
+  <готовый фрагмент для docs/rules.md или docs/arch.md>
+  ```
+- **Польза:** low/medium/high
+
 ## Приоритезация
-| # | Паттерн | Польза | Приоритет |
-|---|---------|--------|-----------|
-| 1 | ... | high | 1 |
+| # | Тип | Паттерн | Польза | Приоритет |
+|---|-----|---------|--------|-----------|
+| 1 | automation | ... | high | 1 |
 
 ## Рекомендация
 <какие 1–3 внедрить первыми и почему — простыми словами>
 ```
 
 ### 6. Финал
-Короткое сообщение: путь к отчёту, сколько паттернов нашёл, топ-3 рекомендации простыми словами, подсказка дальше — «хочешь внедрить → `eda-plan` для плана, потом `eda-execute`».
+Короткое сообщение: путь к отчёту, сколько паттернов нашёл, сколько предложений по автоматизациям и сколько по `docs/rules.md`/`docs/arch.md`, топ-3 рекомендации простыми словами, подсказка дальше — «хочешь внедрить → `eda-plan` для плана, потом `eda-execute`».
 
 ## Чего НЕ делать
-- Внедрять автоматизации (создавать конфиги, ставить пакеты, править pre-commit) — только предлагать.
+- Внедрять автоматизации или править `docs/rules.md`/`docs/arch.md` — только предлагать.
 - Предлагать на основе единичных замечаний — иначе получится белый шум.
 - Игнорировать существующий стек и предлагать новый инструмент, когда уже есть подходящий.
 - Предлагать второй инструмент того же класса в дополнение к уже установленному.
 - Сохранять отчёт куда-либо кроме `docs/automations/`.
-- Дублировать в предложениях правила, которые уже зафиксированы в `docs/rules.md` как автоматизированные.
+- Дублировать в предложениях правила или архитектурные тезисы, которые уже зафиксированы в `docs/rules.md` или `docs/arch.md`.
 - В обычном режиме без `plans` смешивать проблемы планирования с ревью и фиксами.

package/docs/skills/eda-commit.md

@@ -1,6 +1,6 @@
 ---
 name: eda-commit
-description: 'Формирует коммит из незакоммиченных изменений в стиле проекта (по docs/rules.md или истории), коммитит без `--no-verify`. В конце спрашивает интерактивно: push (если есть remote) / merge в main + переключение + удаление ветки (если не в main) / ничего. Не правит логику кода, не пишет тесты — это `eda-execute` или `eda-fix-by-review`.'
+description: 'Формирует коммит из незакоммиченных изменений в стиле проекта (по docs/rules.md или истории), включая связанные артефакты из `docs/**`, которые создали скилы. Коммитит без `--no-verify`. В конце спрашивает интерактивно: push (если есть remote) / merge в main + переключение + удаление ветки (если не в main) / ничего. Не правит логику кода, не пишет тесты — это `eda-execute`, `eda-fix` или `eda-fix-by-review`.'
 ---
 
 # Скил: Коммитер (eda-commit)
@@ -13,7 +13,8 @@ description: 'Формирует коммит из незакоммиченны
 2. **Не правишь логику кода и не пишешь тесты.** Если на этапе коммита что-то не работает (упал hook, обнаружились сырые правки) — спроси через `AskUserQuestion`, не «допиливай» молча.
 3. **Pre-commit / pre-push hooks не отключай.** Никаких `--no-verify`. Hook упал → правим причину → новый коммит (не `--amend`).
 4. **Один логический коммит за вызов.** Если в diff видишь явно разные изменения — спроси через `AskUserQuestion`, разделить на несколько коммитов или коммитить одним.
-5. **Простой язык** в сообщениях пользователю.
+5. **Не пропускай `docs/**`.** Планы, исследования, журналы, ревью, отчёты о фиксах, автоматизации, `docs/rules.md` и `docs/arch.md`, созданные или обновлённые скилами, — часть изменения. Если они относятся к текущей задаче, добавляй их в коммит вместе с кодом.
+6. **Простой язык** в сообщениях пользователю.
 
 ## Интерактивные вопросы
 
@@ -27,13 +28,20 @@ description: 'Формирует коммит из незакоммиченны
 ## Этапы
 
 ### 1. Посмотреть состояние
-`git status`, `git diff --stat`, `git log -5 --oneline` — определи стиль коммитов проекта по последним коммитам.
+`git status`, `git diff --stat`, `git log -5 --oneline` — определи стиль коммитов проекта по последним коммитам. Смотри и tracked, и untracked файлы.
 
 Если незакоммиченных изменений нет — сообщи и выйди.
 
 ### 2. Сформировать коммит
 Составь сообщение в стиле проекта: первая строка короткая (до ~70 символов), при необходимости — тело с пояснением «почему» (не «что» — это в diff).
 
+Перед `git add` явно выбери файлы для коммита. Включай связанные документы из `docs/**`, особенно:
+- `docs/plans/`, `docs/researches/`, `docs/executions/`;
+- `docs/reviews/`, `docs/review-fixes/`, `docs/fixes/`;
+- `docs/automations/`, `docs/rules.md`, `docs/arch.md`.
+
+Не считай эти файлы «служебным шумом» и не оставляй их untracked, если они созданы скилами для текущей задачи. Если документ из `docs/**` выглядит несвязанным с текущим изменением — спроси через `AskUserQuestion`, включать ли его.
+
 Закоммить через `git add` (точечно по файлам, не `-A`) и `git commit -m`. Не пуш, не `--amend`, не `--no-verify`.
 
 Если hook упал — прочитай вывод, исправь причину, повтори через **новый** коммит (не amend).
@@ -75,6 +83,7 @@ description: 'Формирует коммит из незакоммиченны
 - `--no-verify`, `--no-gpg-sign` — никогда.
 - `--amend` существующего коммита — создавай новый.
 - `git add -A` или `git add .` — добавляй файлы по имени.
+- Пропускать связанные файлы из `docs/**` только потому, что это документация или артефакты скилов.
 - Коммитить файлы с похожими на секреты именами (`.env`, `credentials*`) без явного подтверждения через `AskUserQuestion`.
 - Push --force в main или master.
 - Делать ревью или править логику кода — это другие скилы.

package/docs/skills/eda-fix.md

@@ -0,0 +1,93 @@
+---
+name: eda-fix
+description: 'Делает обычные фиксы по плану, файлу плана или короткому текстовому контексту. Перед правками читает `docs/rules.md` и `docs/arch.md`, если есть. Правит код, добавляет нужные тесты, прогоняет проверки и сохраняет историю в `docs/fixes/`. Не делает ревью и не коммитит.'
+---
+
+# Скил: Фиксер (eda-fix)
+
+Делаешь конкретные исправления и сохраняешь отчёт, чтобы потом было понятно, что и почему правилось. Это не выполнение большого плана и не фиксы по ревью: вход может быть короткой строкой, баг-репортом, файлом плана или списком задач.
+
+## Режимы вызова
+
+| Режим | Запуск | Что делает |
+|---|---|---|
+| По контексту | `eda-fix <что исправить>` | Делает фиксы по тексту пользователя |
+| По плану | `eda-fix docs/plans/<file>.md` | Делает фиксы по указанному плану |
+
+## Главные правила
+
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Файлов нет — продолжай.
+2. **Вход обязателен.** Если не передан план, файл или понятный текст задачи — спроси через интерактивный вопрос.
+3. **Делай только указанные фиксы.** Не расширяй задачу до рефакторинга и не чини соседние проблемы без необходимости.
+4. **Тесты рядом с правкой.** Меняешь поведение — добавь или обнови точечный тест.
+5. **Финальная проверка обязательна.** В конце прогони подходящие тесты и линтеры проекта.
+6. **Историю фиксируй в `docs/fixes/`.** Отчёт обязателен даже для маленькой правки.
+7. **Не коммить и не пушь.** Это `eda-commit`. Не делай ревью — это `eda-review`.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
+
+## Этапы
+
+### 1. Определить задачу
+Определи `$FIX_CONTEXT`:
+- если передан путь к файлу — прочитай его;
+- если это план из `docs/plans/` — используй его как план фикса;
+- если передан текст — используй его как контекст;
+- если входа нет или он неоднозначен — спроси через `AskUserQuestion`.
+
+### 2. Прочитать рамку проекта
+Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Если `$FIX_CONTEXT` ссылается на research, review, issue или другой файл — прочитай и его.
+
+### 3. Сделать фикс
+Найди релевантный код и внеси минимальные правки. Если задача состоит из нескольких пунктов, иди по ним последовательно. Останавливайся и спрашивай, если пункт противоречит коду, требует продуктового решения, рискованной операции, миграции, удаления данных или затрагивает секреты.
+
+### 4. Добавить или обновить тесты
+Если фикс меняет поведение — добавь тест рядом с изменением или обнови существующий. Если тесты не нужны, в отчёте коротко объясни почему.
+
+### 5. Финальная проверка
+Прогони подходящие тесты и линтеры. Команды определи по стеку проекта. Свои поломки — исправь и повтори. Чужие или несвязанные поломки — зафиксируй в отчёте и спроси через `AskUserQuestion`, если без решения нельзя продолжать.
+
+### 6. Сохранить отчёт
+Сохрани отчёт в `docs/fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+
+```markdown
+---
+date: <YYYY-MM-DD HH:MM>
+source: <text | path | docs/plans/...>
+status: done
+---
+
+# Фикс: <краткий заголовок>
+
+## Контекст
+<что было передано на вход и какие правила/архитектура учтены>
+
+## Что изменено
+| # | Файл | Что изменено | Зачем |
+|---|------|--------------|-------|
+| 1 | `path/file.ext` | ... | ... |
+
+## Тесты и проверки
+| Команда | Результат | Заметки |
+|---------|-----------|---------|
+| `<command>` | ✓ / ✗ | ... |
+
+## Открытые вопросы
+<если нет — «Нет»>
+```
+
+### 7. Финал
+Короткое сообщение: путь к отчёту, что исправлено, какие тесты/линтеры прошли, состояние git («не закоммичено»), дальше — `eda-review` или `eda-commit`.
+
+## Чего НЕ делать
+- Коммитить, пушить, создавать PR.
+- Делать ревью вместо фикса.
+- Выполнять большой план с чекбоксами и журналом `docs/executions/` — это `eda-execute`.
+- Применять замечания из готового ревью — это `eda-fix-by-review`.
+- Сохранять отчёт куда-либо кроме `docs/fixes/`.

package/docs/skills/eda-research.md

@@ -1,6 +1,6 @@
 ---
 name: eda-research
-description: 'Глубокое исследование темы или задачи. Без правки кода. Все вопросы — через интерактивный вопрос. Mermaid-диаграммы и markdown-таблицы — там где это даёт ясность. Итог сохраняется в docs/researches/. По умолчанию без кросс-ревью; кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict`.'
+description: 'Глубокое исследование темы или задачи в read-only режиме. Без правки кода. Все вопросы — через интерактивный вопрос. Mermaid-диаграммы и markdown-таблицы — там где это даёт ясность. Итог сохраняется в docs/researches/. По умолчанию без кросс-ревью; кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict`.'
 ---
 
 # Скил: Исследователь (eda-research)
@@ -37,7 +37,7 @@ description: 'Глубокое исследование темы или зада
 Прочитай запрос. Сформулируй цель и 3–7 конкретных вопросов. Неясности — задай через `AskUserQuestion`. Не уходи дальше, пока цель не подтверждена.
 
 ### 2. Собрать материал
-Включи explore / read-only режим хост-агента (в Claude Code — `EnterPlanMode`, в Codex — встроенный режим без правок). Инструменты выбирай сам, рамка одна — ничего не правишь в коде. Перед сохранением отчёта (этап 4) выйди из режима.
+Работай в read-only режиме: читай файлы, ищи по проекту, смотри историю и запускай только команды, которые не меняют рабочее дерево. Код, конфиги и зависимости не правь. Запись разрешена только на этапе 4 при сохранении итогового отчёта в `docs/researches/`.
 
 ### 3. Диаграммы (если уместно)
 Есть поток / связи / состояния / последовательность шагов — нарисуй 1–3 Mermaid-диаграммы. Подписи на русском. Если показывать нечего — в разделе диаграмм отчёта одна строка: «Не требуется — тема не имеет графовой структуры.»

package/lib/install.js

@@ -1,17 +1,21 @@
+import checkbox from '@inquirer/checkbox';
 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');
+const TARGET_CHOICES = [
+  { value: 'claude', label: 'Claude Code', dir: '.claude/skills/' },
+  { value: 'codex', label: 'Codex CLI', dir: '.codex/skills/' }
+];
 
-export async function init({ cwd }) {
-  const targets = await askTargets();
+export async function init({ cwd, input = process.stdin, output = process.stdout }) {
+  const targets = await askTargets({ input, output });
   if (targets.length === 0) {
-    process.stdout.write('Ничего не выбрано — выходим.\n');
+    output.write('Ничего не выбрано — выходим.\n');
     return;
   }
   await syncSkills(cwd, targets);
@@ -27,25 +31,24 @@ export async function update({ cwd }) {
   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 [];
+export async function askTargets({ input = process.stdin, output = process.stdout } = {}) {
+  if (!input.isTTY || !output.isTTY) {
+    output.write('Нет интерактивного терминала — устанавливаю Claude Code и Codex CLI.\n');
+    return TARGET_CHOICES.map(choice => choice.value);
   }
+
+  return checkbox({
+    message: 'Куда устанавливать скилы?',
+    instructions: 'Стрелки — выбрать, Space — отметить, Enter — продолжить',
+    choices: TARGET_CHOICES.map(choice => ({
+      name: `${choice.label} (${choice.dir})`,
+      value: choice.value,
+      checked: true
+    }))
+  }, {
+    input,
+    output
+  });
 }
 
 async function detectTargets(cwd) {

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.2.7",
-  "description": "Набор скилов eda-* для Claude Code и Codex CLI: research, plan, execute, review, fix, send-review, commit, docs, automate",
+  "version": "0.2.8",
+  "description": "Набор скилов eda-* для Claude Code и Codex CLI: research, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
   "type": "module",
   "bin": {
     "eda": "bin/cli.js"
@@ -35,5 +35,8 @@
   "homepage": "https://github.com/falur/eda#readme",
   "bugs": {
     "url": "https://github.com/falur/eda/issues"
+  },
+  "dependencies": {
+    "@inquirer/checkbox": "^4.3.2"
   }
 }