@gian-tiaga/eda 0.2.0

package/README.md

@@ -0,0 +1,128 @@
+# 🌊 eda
+
+> Поточная разработка с AI-агентами — на русском языке.
+> Набор готовых скилов для **Claude Code** и **Codex CLI**, которые ведут тебя через весь цикл: от исследования до коммита.
+
+`eda` — это девять скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
+
+---
+
+## ⚡ Установка
+
+```bash
+npm install -g @gian-tiaga/eda
+```
+
+В корне твоего проекта:
+
+```bash
+eda init
+```
+
+Скил спросит, куда ставить — в Claude Code, в Codex или в обе среды сразу. Дальше можно работать.
+
+---
+
+## 🛠️ Скилы
+
+| Скил | Что делает | Куда складывает |
+|---|---|---|
+| `eda-research` | Глубоко изучает тему или задачу. Без правок кода. Все вопросы — через интерактивный диалог. На выходе — понятный отчёт со ссылками на источники, диаграммами и таблицами | `docs/researches/` |
+| `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. Подтягивает контекст из `docs/rules.md`, `docs/arch.md`, при желании — релевантное исследование. Затем три параллельных модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
+| `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
+| `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) |
+| `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
+| `eda-docs` | Создаёт или обновляет `docs/rules.md` (максимально строгие правила для твоего стека), `docs/arch.md` (архитектура проекта) и шапку `AGENTS.md`. Может предлагать инструменты, которых ещё нет в проекте | `docs/rules.md`, `docs/arch.md`, `AGENTS.md` |
+| `eda-automate` | Анализирует историю ревью и фиксов. Если какое-то замечание встречается раз за разом — предлагает кастомное правило линтера или статанализатора, чтобы ловить это автоматически | `docs/automations/` |
+
+---
+
+## 🚩 Флаги скилов
+
+У некоторых скилов есть флаг `strict` — он включает дополнительные тяжёлые проверки. Передаётся как часть запроса агенту, например: `eda-research strict <тема>` или просто `сделай ревью этого PR в strict-режиме`.
+
+Скилы, которых нет в таблице ниже, флагов не поддерживают — у них всё включено по умолчанию.
+
+| Скил | Флаг | Что включает | Когда стоит использовать |
+|---|---|---|---|
+| `eda-research` | `strict` | После сохранения отчёта отдаёт его соседнему CLI (Claude → Codex или наоборот) на критическое ревью; затем доправляет отчёт по их замечаниям | Серьёзные исследования, которые лягут в основу больших решений; когда хочется второго мнения от другой модели/среды |
+| `eda-plan` | `strict` | После мета-ревью трёх моделей (это есть всегда) отдаёт план соседнему CLI на дополнительный круг проверки; доправляет план | Большие или ответственные планы, особенно затрагивающие смежные системы |
+| `eda-review` | `strict` | После мета-ревью тремя моделями (Sonnet/Haiku/Opus — это есть всегда) отдаёт ревью соседнему CLI на дополнительный круг проверки; доправляет ревью по его замечаниям | Ревью важных PR; когда нужен максимальный охват |
+
+---
+
+## 🔄 Воркфлоу
+
+```mermaid
+flowchart LR
+    R[🔍 research] --> P[📝 plan]
+    P --> E[⚙️ execute]
+    E --> V[🧐 review]
+    V --> F[🛠️ fix-by-review]
+    F --> S[📤 send-review]
+    F --> C[💾 commit]
+    V -.-> A[⚡ automate]
+    F -.-> A
+    D[📚 docs] -.-> P
+    D -.-> E
+```
+
+Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-research`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны.
+
+---
+
+## 🎯 Главные принципы
+
+- **Простой язык.** Скилы общаются с тобой так, чтобы понял человек без глубоких знаний предмета. Термины — только когда без них нельзя.
+- **Все вопросы — структурированно.** Никаких «а уточни, пожалуйста, на какую ветку?» в свободном тексте. Только через `AskUserQuestion` (или нумерованный список в Codex).
+- **Артефакты по папкам.** Исследования отдельно, планы отдельно, ревью отдельно. Между файлами — ссылки. Через месяц легко найти, кто что когда решал.
+- **Границы между скилами жёсткие.** `execute` не коммитит — это работа `commit`. `review` не правит код — это `fix-by-review`. Никаких размытых ответственностей.
+- **Доверие модели.** Скилы короткие. Они говорят «что» и «почему», а «как именно» — модель разбирается сама.
+
+---
+
+## 💻 Команды
+
+```bash
+eda init      # выбрать Claude Code / Codex / обе среды и установить скилы
+eda update    # обновить уже установленные скилы из текущей версии пакета
+eda --help    # справка
+```
+
+Когда выходит новая версия пакета:
+
+```bash
+npm update -g @gian-tiaga/eda    # подтянуть новый код
+eda update           # синхронизировать скилы в текущем проекте
+```
+
+---
+
+## 📁 Куда устанавливаются скилы
+
+| Среда | Куда |
+|---|---|
+| **Claude Code** | `<project>/.claude/skills/<skill>/SKILL.md` — отдельная папка на каждый скил |
+| **Codex CLI** | `<project>/.codex/skills/<skill>.md` — отдельный файл на каждый скил |
+
+`eda update` идемпотентно перезаписывает файлы в обеих папках. Если ты хочешь подправить скил локально — лучше копию сделай рядом, а не прямо в `.claude/skills/` или `.codex/skills/`, иначе при следующем `update` твои правки потеряются.
+
+`AGENTS.md` (как и любые другие файлы в корне проекта) установщик **не трогает**. Если хочешь, чтобы Codex автоматически подгружал скилы, дай ему знать сам — например, одной строкой в `AGENTS.md`: «следуй инструкциям из `.codex/skills/`».
+
+---
+
+## 🤝 Для кого это
+
+- Для тех, кто **постоянно** пишет код с AI-агентом и устал каждый раз заново объяснять, как делать ревью.
+- Для команд, где хочется единый стандарт работы с агентами — чтобы ревью у всех было пронумеровано и оценено, планы лежали в одной папке, а коммиты были по одному стилю.
+- Для разработчиков, которые любят **строгость**: максимально жёсткие правила, обязательные тесты, мета-проверки ревью несколькими моделями, кросс-проверка через соседний CLI.
+
+---
+
+## 📜 Лицензия
+
+MIT.
+
+Используй, форкай, переписывай под себя. Будет здорово, если поделишься улучшениями обратно.

package/bin/cli.js

@@ -0,0 +1,34 @@
+#!/usr/bin/env node
+import { init, update } from '../lib/install.js';
+
+const cmd = process.argv[2];
+
+const HELP = `eda — установка и обновление скилов eda-* для Claude Code и Codex CLI.
+
+Использование:
+  eda init     — выбрать целевые среды (Claude / Codex / обе) и установить скилы
+  eda update   — обновить уже установленные скилы в текущем проекте
+  eda --help   — показать эту справку
+`;
+
+try {
+  switch (cmd) {
+    case 'init':
+      await init({ cwd: process.cwd() });
+      break;
+    case 'update':
+      await update({ cwd: process.cwd() });
+      break;
+    case undefined:
+    case '-h':
+    case '--help':
+      process.stdout.write(HELP);
+      break;
+    default:
+      process.stderr.write(`Неизвестная команда: ${cmd}\n\n${HELP}`);
+      process.exit(1);
+  }
+} catch (err) {
+  process.stderr.write(`Ошибка: ${err.message}\n`);
+  process.exit(1);
+}

package/docs/skills/eda-automate.md

@@ -0,0 +1,108 @@
+---
+name: eda-automate
+description: Анализирует историю `docs/reviews/` и `docs/review-fixes/`, ищет повторяющиеся замечания и предлагает автоматизации — кастомные правила линтеров, статанализаторов, pre-commit-проверок. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет автоматизации — выдаёт приоритезированный список с черновиками правил. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Все вопросы — через AskUserQuestion.
+---
+
+# Скил: Автоматизатор (eda-automate)
+
+Читаешь историю ревью и фиксов, находишь повторяющиеся замечания, предлагаешь, какие из них можно поймать автоматически: кастомным правилом линтера, статанализатора, pre-commit-проверкой. Не внедряешь — только предлагаешь, с черновиком правила и оценкой стоимости.
+
+## Главные правила
+
+1. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть. Не предлагай то, что уже зафиксировано как автоматизированное правило.
+2. **Все вопросы — через `AskUserQuestion`** (в Codex — короткий нумерованный список).
+3. **Не внедряешь автоматизации.** Только отчёт с предложениями. Внедрение — `eda-plan` + `eda-execute`.
+4. **Предлагай только повторяющееся.** Минимум — паттерн встречается в 2+ разных ревью или в 3+ местах одного. Единичные замечания не автоматизируем.
+5. **Каждое предложение — с черновиком правила.** Не «надо бы что-то сделать», а конкретный фрагмент: имя инструмента, имя правила, псевдокод/skeleton.
+6. **Простой язык. Таблицы** для приоритезации.
+
+## Этапы
+
+### 1. Выбрать диапазон
+`AskUserQuestion`: какую историю анализировать.
+- Все ревью + фиксы (по умолчанию)
+- Последние N (5/10/20)
+- За период (последние N дней)
+- Конкретные файлы
+
+Получи список файлов из `docs/reviews/` и `docs/review-fixes/`.
+
+### 2. Прочитать контекст
+- Все выбранные ревью и отчёты о фиксах.
+- `docs/rules.md`, `docs/arch.md` (если есть).
+- Какие языки и фреймворки в проекте — определи сам.
+- Какие инструменты статанализа уже установлены и работают — определи по конфигам и зависимостям проекта.
+
+### 3. Найти повторяющиеся паттерны
+Сгруппируй замечания по сути (не по точному тексту). Примеры паттернов:
+- Запрещённые конструкции языка/фреймворка.
+- Нарушения архитектурных границ (импорты не из API соседнего модуля).
+- Забытое: error handling, validation, очистка ресурсов.
+- Стиль: имена, форматирование, порядок.
+
+Для каждого паттерна собери: где встречался (ссылки на ревью), сколько раз, в каких файлах.
+
+### 4. Предложить автоматизации
+Для каждого паттерна выбери подходящий инструмент. Логика выбора:
+
+1. Если в проекте **уже работает** инструмент, который умеет ловить этот класс паттернов — предлагай правило в нём.
+2. Если такого инструмента в проекте нет, но он стандартный для языка/фреймворка — предлагай его, явно отметив, что инструмент **новый** для проекта.
+3. **Не предлагай альтернативу уже установленному инструменту того же класса.** Если в проекте уже есть один статанализатор — не предлагай второй для тех же задач, даже если он мощнее.
+
+Каждое предложение содержит:
+- Что ловит (одна-две фразы простым языком).
+- Где встречалось (ссылки на 2–3 ревью).
+- Инструмент и тип правила. Если инструмент **новый** для проекта — пометка «требует установки».
+- **Черновик правила** — псевдокод или фрагмент конфигурации.
+- Польза: `low` / `medium` / `high` (по частоте паттерна и вреду от пропуска).
+
+### 5. Сохранить отчёт
+`docs/automations/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Slug — короткое описание набора (например, `php-strict-rules`).
+
+```markdown
+---
+date: <YYYY-MM-DD HH:MM>
+sources: [docs/reviews/..., docs/review-fixes/...]
+status: draft
+---
+
+# Предложения по автоматизации
+
+## Контекст
+- Проанализировано: N ревью + M фиксов
+- Стек проекта: <по конфигам>
+- Уже работающие инструменты: <список>
+
+## Предложения
+
+### 1. <название паттерна>
+- **Что ловит:** ...
+- **Встречалось в:** `docs/reviews/...` (×2), `docs/reviews/...` (×3)
+- **Инструмент:** <название> (если новый для проекта — пометка «требует установки»)
+- **Черновик правила:**
+  ```<язык>
+  <псевдокод/skeleton>
+  ```
+- **Польза:** low/medium/high
+
+### 2. ...
+
+## Приоритезация
+| # | Паттерн | Польза | Приоритет |
+|---|---------|--------|-----------|
+| 1 | ... | high | 1 |
+
+## Рекомендация
+<какие 1–3 внедрить первыми и почему — простыми словами>
+```
+
+### 6. Финал
+Короткое сообщение: путь к отчёту, сколько паттернов нашёл, топ-3 рекомендации простыми словами, подсказка дальше — «хочешь внедрить → `eda-plan` для плана, потом `eda-execute`».
+
+## Чего НЕ делать
+- Внедрять автоматизации (создавать конфиги, ставить пакеты, править pre-commit) — только предлагать.
+- Предлагать на основе единичных замечаний — иначе получится белый шум.
+- Игнорировать существующий стек и предлагать новый инструмент, когда уже есть подходящий.
+- Предлагать второй инструмент того же класса в дополнение к уже установленному.
+- Сохранять отчёт куда-либо кроме `docs/automations/`.
+- Дублировать в предложениях правила, которые уже зафиксированы в `docs/rules.md` как автоматизированные.

package/docs/skills/eda-commit.md

@@ -0,0 +1,71 @@
+---
+name: eda-commit
+description: Формирует коммит из незакоммиченных изменений в стиле проекта (по docs/rules.md или истории), коммитит без `--no-verify`. В конце спрашивает через AskUserQuestion: push (если есть remote) / merge в main + переключение + удаление ветки (если не в main) / ничего. Не правит логику кода, не пишет тесты — это `eda-execute` или `eda-fix-by-review`.
+---
+
+# Скил: Коммитер (eda-commit)
+
+Берёшь незакоммиченные изменения, делаешь один аккуратный коммит, спрашиваешь у пользователя что делать дальше с веткой и remote.
+
+## Главные правила
+
+1. **Все вопросы — через `AskUserQuestion`** (в Codex — короткий нумерованный список).
+2. **Не правишь логику кода и не пишешь тесты.** Если на этапе коммита что-то не работает (упал hook, обнаружились сырые правки) — спроси через `AskUserQuestion`, не «допиливай» молча.
+3. **Pre-commit / pre-push hooks не отключай.** Никаких `--no-verify`. Hook упал → правим причину → новый коммит (не `--amend`).
+4. **Один логический коммит за вызов.** Если в diff видишь явно разные изменения — спроси через `AskUserQuestion`, разделить на несколько коммитов или коммитить одним.
+5. **Простой язык** в сообщениях пользователю.
+
+## Этапы
+
+### 1. Посмотреть состояние
+`git status`, `git diff --stat`, `git log -5 --oneline` — определи стиль коммитов проекта по последним коммитам.
+
+Если незакоммиченных изменений нет — сообщи и выйди.
+
+### 2. Сформировать коммит
+Составь сообщение в стиле проекта: первая строка короткая (до ~70 символов), при необходимости — тело с пояснением «почему» (не «что» — это в diff).
+
+Закоммить через `git add` (точечно по файлам, не `-A`) и `git commit -m`. Не пуш, не `--amend`, не `--no-verify`.
+
+Если hook упал — прочитай вывод, исправь причину, повтори через **новый** коммит (не amend).
+
+### 3. Спросить про дальнейшее
+Определи:
+- `HAS_REMOTE` = есть ли удалённый репозиторий (`git remote -v`).
+- `CURRENT_BRANCH` = текущая ветка (`git rev-parse --abbrev-ref HEAD`).
+- Целевая ветка — `main` (если у проекта другая основная — определи по `git rev-parse --abbrev-ref origin/HEAD`).
+
+Собери варианты для `AskUserQuestion`:
+
+| Вариант | Когда показывать |
+|---|---|
+| **Push** | Если `HAS_REMOTE` |
+| **Merge в main + переключение + удаление текущей ветки** | Если `CURRENT_BRANCH != main` |
+| **Ничего больше** | Всегда, если показываются другие варианты (или multiSelect, если хочешь push **и** merge — выбирай) |
+
+Логика:
+- Оба варианта применимы → 3 опции в `AskUserQuestion`.
+- Только `push` → 2 опции (push / ничего).
+- Только `merge` → 2 опции (merge+switch+delete / ничего).
+- Ни тот ни другой (мы в main без remote) → **не задавать вопрос**, сразу финал.
+
+Действия по выбору:
+
+| Выбор | Команды |
+|---|---|
+| Push | `git push -u origin <branch>` (или просто `git push`, если upstream уже настроен) |
+| Merge + switch + delete | `git checkout main` → `git merge <branch>` → `git branch -d <branch>` (если merge без конфликтов; конфликт → остановись, `AskUserQuestion`) |
+| Ничего | пропустить |
+
+Если push требует force (например, ветка уже на remote и история разошлась) — **остановись** и спроси через `AskUserQuestion`. Никогда не push --force в main.
+
+### 4. Финал
+Короткое сообщение: хеш и заголовок коммита, что было сделано после (push / merge / ничего), текущая ветка после операции.
+
+## Чего НЕ делать
+- `--no-verify`, `--no-gpg-sign` — никогда.
+- `--amend` существующего коммита — создавай новый.
+- `git add -A` или `git add .` — добавляй файлы по имени.
+- Коммитить файлы с похожими на секреты именами (`.env`, `credentials*`) без явного подтверждения через `AskUserQuestion`.
+- Push --force в main или master.
+- Делать ревью или править логику кода — это другие скилы.

package/docs/skills/eda-docs.md

@@ -0,0 +1,146 @@
+---
+name: eda-docs
+description: Создаёт или обновляет три ключевых документа: `docs/rules.md` (максимально строгие правила для стека + предложения новых инструментов), `docs/arch.md` (архитектура проекта), `AGENTS.md` (описание проекта, стек, ссылки на документы и команды). Анализирует стек сам. Не правит код. Все вопросы — через AskUserQuestion.
+---
+
+# Скил: Документатор (eda-docs)
+
+Создаёшь или обновляешь три документа: `docs/rules.md`, `docs/arch.md` и шапку `AGENTS.md`. Правила — **максимально строгие** для стека проекта; смело предлагай инструменты, которых ещё нет, если они повышают строгость.
+
+## Главные правила
+
+1. **Все вопросы — через `AskUserQuestion`**.
+2. **Не правишь код**, не ставишь пакеты, не меняешь конфиги. Только документы.
+3. **Максимальная строгость по умолчанию.** Все доступные strict-флаги, запреты «гибких» конструкций, обязательные типы / тесты / обработка ошибок. Если правило бьёт по продуктивности — пометь, но не выкидывай.
+4. **Можно предлагать инструменты, которых ещё нет в проекте**, если они стандартные для стека и повышают строгость. Не предлагай дубль уже установленному того же класса.
+5. **Существующие документы** не переписываем молча. Если файл уже есть — `AskUserQuestion`: переписать / дополнить / создать рядом.
+7. **Простой язык.** В правилах объясняй *почему*, не только *что*. **Таблицы** для перечислений.
+
+## Этапы
+
+### 1. Проанализировать проект
+Определи сам: языки и фреймворки, тест-фреймворк, базы данных, инфраструктуру (контейнеры, CI), уже установленные линтеры/статанализаторы, главную ветку, стиль коммитов (по `git log`).
+
+### 2. Прочитать существующие docs
+`docs/rules.md`, `docs/arch.md`, `AGENTS.md` (если есть). Запомни, что в них уже зафиксировано — чтобы не дублировать и не противоречить.
+
+### 3. Уточнить, что обновляем
+`AskUserQuestion`: какие документы трогаем — все три / только rules / только arch / только AGENTS / выбрать несколько.
+
+Для каждого существующего файла — **отдельный** `AskUserQuestion`: переписать с нуля / дополнить / оставить как есть.
+
+### 4. Сгенерировать `docs/rules.md`
+Структура (примерная — адаптируй под стек):
+
+```markdown
+# Правила проекта
+
+## Зачем эти правила
+<2–3 предложения: что мы хотим от кода, какую боль закрываем>
+
+## Стиль кода
+<строгие настройки форматтера, имена, длина строк, импорты>
+
+## Типы
+<обязательные типы, запрет any/mixed, strict-режимы>
+
+## Тесты
+<минимальное покрытие, расположение, именование, что обязательно покрывать>
+
+## Обработка ошибок
+<запрет «глотания» ошибок, обязательное логирование, типы исключений>
+
+## Безопасность
+<секреты, валидация ввода, SQL, XSS, ...>
+
+## Производительность
+<запрет N+1, ограничения сложности, ...>
+
+## Коммиты и ветки
+<стиль сообщений, главная ветка, политика merge>
+
+## Инструменты
+| Инструмент | Установлен | Назначение | Конфиг (черновик) |
+|---|---|---|---|
+| ... | ✓/новый | ... | <фрагмент> |
+
+## Что предлагается добавить
+<список инструментов, которых нет, но стоит поставить — для каждого: чем закрывает, черновик минимального конфига>
+```
+
+Каждое правило — с короткой строкой «почему» (ссылка на типичную ошибку или класс багов).
+
+### 5. Сгенерировать `docs/arch.md`
+Структура:
+
+```markdown
+# Архитектура проекта
+
+## Картина целиком
+<2–4 абзаца простыми словами: что делает система, какие у неё границы>
+
+<Mermaid-диаграмма верхнего уровня — модули и потоки. Если архитектура линейная и схемы не нужно — одна строка про это>
+
+## Модули
+| Модуль | Назначение | Зависит от | API наружу |
+|---|---|---|---|
+
+## Потоки данных
+<ключевые сценарии — sequenceDiagram или текст>
+
+## Решения и ограничения
+<важные архитектурные решения с обоснованием — почему так, а не иначе>
+
+## Что вне области
+<что система осознанно НЕ делает>
+```
+
+### 6. Обновить `AGENTS.md`
+Если файл существует — `AskUserQuestion`: переписать / дополнить / оставить. Если нет — создай.
+
+Шаблон:
+
+```markdown
+# AGENTS.md
+
+Инструкции для AI-агентов в этом репозитории.
+
+## Проект
+- **Название:** ...
+- **Что делает:** <одно-два предложения>
+- **Стек:** <языки, фреймворки, БД, инфраструктура>
+- **Главная ветка:** <main|master|...>
+
+## Для агентов
+Рамка проекта — `docs/rules.md` и `docs/arch.md`. Перед любой правкой кода прочитай их. Если их нет — спроси пользователя, можно ли запустить `eda-docs` для генерации. Скилы серии eda-* лежат в `.claude/skills/` (для Claude Code) и `.codex/skills/` (для Codex CLI) — следуй им, когда пользователь просит выполнить одну из задач серии.
+
+## Где что хранится
+| Что | Где |
+|---|---|
+| Исследования | `docs/researches/` |
+| Планы | `docs/plans/` |
+| Журналы выполнения | `docs/executions/` |
+| Ревью | `docs/reviews/` |
+| Отчёты о фиксах | `docs/review-fixes/` |
+| Предложения по автоматизации | `docs/automations/` |
+| Правила проекта | `docs/rules.md` |
+| Архитектура | `docs/arch.md` |
+
+## Команды
+- Тесты: `<команда>`
+- Линтер: `<команда>`
+- Локальный запуск: `<команда>` (если применимо)
+
+## Стиль коммитов
+<определи по `git log -20 --oneline` или зафиксируй стандарт>
+```
+
+### 7. Финал
+Короткое сообщение: какие файлы созданы/обновлены, путь к каждому, ключевые предложения по новым инструментам списком, подсказка дальше — «прочитай файлы, скорректируй вручную, что не подходит».
+
+## Чего НЕ делать
+- Править код, ставить пакеты, менять конфиги — только документы.
+- Молча переписывать существующие документы — каждый раз `AskUserQuestion`.
+- Смягчать правила «потому что так удобнее» — стек строгий по умолчанию; послабления отдельно отмечай.
+- Предлагать второй инструмент того же класса в дополнение к уже установленному.
+- Добавлять разделы ради красоты — если для проекта раздел не релевантен, опусти его.

package/docs/skills/eda-execute.md

@@ -0,0 +1,111 @@
+---
+name: eda-execute
+description: Исполняет план из docs/plans/ — правит код, пишет тесты к изменениям внутри каждого шага, в конце прогоняет полный сьют тестов и линтеры. Прогресс — чекбоксы в файле плана + журнал в `docs/executions/`; в конец плана дописывается ссылка на журнал. Не коммитит (это `eda-commit`), не делает ревью (это `eda-review`). Все вопросы — через AskUserQuestion.
+---
+
+# Скил: Исполнитель (eda-execute)
+
+Берёшь готовый план из `docs/plans/`, выполняешь до конца, ведёшь журнал. Останавливаешься только при реальных проблемах.
+
+## Главные правила
+
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Это рамка проекта. Файлов нет — продолжай молча. Один раз в начале, не перечитывать на каждом шаге.
+2. **Все вопросы — через `AskUserQuestion`** (в Codex, если его нет — короткий нумерованный список).
+3. **Не переформулируй план.** Шаг непонятен — спроси, не «доразрабатывай» молча.
+4. **Не коммитить, не пушить, не делать ревью.** Это другие скилы.
+5. **Идти целиком**, не делать паузы «для подтверждения». Останавливайся только если: тест упал, шаг противоречив, есть риск потерять данные, рискованная операция вне плана.
+6. **Тесты — внутри шага.** Меняешь поведение → пишешь тесты к этому изменению в том же шаге, точечно прогоняешь только их. Полный сьют и линтеры — один раз в конце (этап 7), не на каждом шаге.
+7. **Простой язык** в сообщениях пользователю и вопросах. Термины — только если без них нельзя, и сразу с пояснением.
+8. **Таблицы для структурируемых данных** в журнале. Диаграммы — только если действительно есть что показать.
+
+## Этапы
+
+### 1. Выбрать план
+Если путь не передан — `AskUserQuestion` со списком последних файлов из `docs/plans/`. Запиши путь в `$PLAN_FILE`.
+
+### 2. Выбрать место выполнения
+`AskUserQuestion` с четырьмя вариантами:
+
+| Вариант | Что делает | Команда |
+|---|---|---|
+| Остаться в текущей ветке | Ничего | — |
+| Новая ветка от main | Переключиться на main, создать ветку от неё | `git checkout main && git checkout -b <slug>` |
+| Новая ветка от текущей ветки | Создать ветку прямо здесь | `git checkout -b <slug>` |
+| Worktree от main в соседней папке | Создать worktree → **остановиться**, дать пользователю инструкцию | см. ниже |
+
+`<slug>` бери из имени плана. Если в рабочей копии незакоммиченные изменения и `git checkout` упадёт — остановись и спроси через `AskUserQuestion`.
+
+**Если выбран worktree** — выполни:
+
+```bash
+git worktree add -b <slug> ../<repo-name>-<slug> main
+```
+
+Покажи пользователю **готовый bash-блок** для копирования (с подставленными именами):
+
+```bash
+cd ../<repo-name>-<slug>
+# затем в новой сессии запусти этот же скил:
+# eda-execute docs/plans/<план>.md
+```
+
+И **выйди из скила** — текущая сессия в эту папку не переедет, поэтому продолжать здесь нельзя. Сообщи пользователю, что ждёшь его в новой сессии.
+
+### 3. Прочитать контекст
+План + `docs/rules.md` и `docs/arch.md` (если есть). Тест-фреймворк проекта определи сам по конфигам/существующим тестам — этого хватит, чтобы писать тесты в нужном стиле.
+
+### 4. Инициализировать прогресс
+- Создай журнал `docs/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же, что у плана, или близкий).
+- В конец файла плана добавь раздел со ссылкой и чекбоксами прогресса:
+  ```markdown
+  ## Прогресс выполнения
+  Журнал: `docs/executions/{file}.md`
+
+  - [ ] Шаг 1: ...
+  - [ ] Шаг 2: ...
+  ```
+- Шаблон журнала:
+
+  ```markdown
+  ---
+  plan: <путь>
+  started: <YYYY-MM-DD HH:MM>
+  status: in_progress
+  ---
+
+  # Журнал: <заголовок>
+
+  ## Шаги
+  | # | Шаг | Файлы | Тесты | Статус |
+  |---|-----|-------|-------|--------|
+
+  ## Заметки
+  ## Изменения в docs
+  ```
+
+### 5. Выполнить план
+Идёшь по шагам. На каждом:
+1. Сделай правки.
+2. Если шаг меняет поведение — добавь тесты в этом же шаге, точечно прогони.
+3. Поставь `[x]` в файле плана и допиши строку в таблицу журнала.
+
+Останавливайся и спрашивай через `AskUserQuestion`, если: тесты к шагу упали и не правятся быстро / шаг противоречит коду / задевает рискованное вне плана. Архитектурное решение по ходу — записывай в «Изменения в docs», не блокируй.
+
+После последнего шага — `finished` и `status: done` в шапке журнала.
+
+### 6. Обновить docs
+Если в «Изменениях в docs» что-то накопилось — допиши в `docs/rules.md` или `docs/arch.md` минимально достаточно. Файлов нет — пропусти (создаёт `eda-docs`).
+
+### 7. Финальная проверка
+Прогони полный сьют тестов и линтеры на проекте. Команды — стандартные для стека; если непонятно — `AskUserQuestion` один раз. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`. Результат фиксируй разделом `## Финальная проверка` в журнале.
+
+### 8. Финал
+Короткое сообщение: пути к плану и журналу, сводка шагов, результат финальной проверки, состояние git («не закоммичено»), 1–3 главных «что важно знать», подсказка «дальше — `eda-review` или `eda-commit`».
+
+## Чего НЕ делать
+- Коммитить, пушить, делать кросс-ревью изменений.
+- Гонять полный сьют и линтеры на каждом шаге.
+- Пропускать финальную проверку.
+- Делать паузу после каждого шага «для подтверждения».
+- Пропускать обновление чекбоксов и журнала — иначе теряется состояние.
+- Делать рискованное (удаление файлов, миграции, секреты) без подтверждения, даже если упомянуто в плане.