@gian-tiaga/eda 0.2.5 → 0.2.7

package/docs/skills/eda-automate.md

@@ -1,11 +1,18 @@
 ---
 name: eda-automate
-description: 'Анализирует историю `docs/reviews/` и `docs/review-fixes/`, ищет повторяющиеся замечания и предлагает автоматизации — кастомные правила линтеров, статанализаторов, pre-commit-проверок. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет автоматизации — выдаёт приоритезированный список с черновиками правил. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Все вопросы — через интерактивный вопрос.'
+description: 'Анализирует историю `docs/reviews/` и `docs/review-fixes/`, а с аргументом `plans` ещё и `docs/plans/`. Ищет повторяющиеся замечания и проблемы планирования, предлагает автоматизации — кастомные правила линтеров, статанализаторов, pre-commit-проверок или checks для планов. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет автоматизации — выдаёт приоритезированный список с черновиками правил. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Все вопросы — через интерактивный вопрос.'
 ---
 
 # Скил: Автоматизатор (eda-automate)
 
-Читаешь историю ревью и фиксов, находишь повторяющиеся замечания, предлагаешь, какие из них можно поймать автоматически: кастомным правилом линтера, статанализатора, pre-commit-проверкой. Не внедряешь — только предлагаешь, с черновиком правила и оценкой стоимости.
+Читаешь историю ревью и фиксов, находишь повторяющиеся замечания, предлагаешь, какие из них можно поймать автоматически: кастомным правилом линтера, статанализатора, pre-commit-проверкой. Если передан аргумент `plans`, дополнительно читаешь планы из `docs/plans/` и ищешь повторяющиеся проблемы планирования, которые можно ловить автоматической проверкой плана. Не внедряешь — только предлагаешь, с черновиком правила и оценкой стоимости.
+
+## Режимы вызова
+
+| Режим | Запуск | Что анализирует |
+|---|---|---|
+| Обычный | `eda-automate` | `docs/reviews/` + `docs/review-fixes/` |
+| С планами | `eda-automate plans` | `docs/reviews/` + `docs/review-fixes/` + `docs/plans/` |
 
 ## Главные правила
 
@@ -15,6 +22,7 @@ description: 'Анализирует историю `docs/reviews/` и `docs/rev
 4. **Предлагай только повторяющееся.** Минимум — паттерн встречается в 2+ разных ревью или в 3+ местах одного. Единичные замечания не автоматизируем.
 5. **Каждое предложение — с черновиком правила.** Не «надо бы что-то сделать», а конкретный фрагмент: имя инструмента, имя правила, псевдокод/skeleton.
 6. **Простой язык. Таблицы** для приоритезации.
+7. **Планы анализируй только с аргументом `plans`.** Без него не читай `docs/plans/`, если пользователь не указал конкретные файлы планов.
 
 ## Интерактивные вопросы
 
@@ -27,16 +35,20 @@ description: 'Анализирует историю `docs/reviews/` и `docs/rev
 ## Этапы
 
 ### 1. Выбрать диапазон
+Определи режим по аргументам вызова. Если передан `plans`, включи планы в источники без отдельного вопроса.
+
 `AskUserQuestion`: какую историю анализировать.
 - Все ревью + фиксы (по умолчанию)
+- Все ревью + фиксы + планы (если передан `plans`)
 - Последние N (5/10/20)
 - За период (последние N дней)
 - Конкретные файлы
 
-Получи список файлов из `docs/reviews/` и `docs/review-fixes/`.
+Получи список файлов из `docs/reviews/` и `docs/review-fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`.
 
 ### 2. Прочитать контекст
 - Все выбранные ревью и отчёты о фиксах.
+- В режиме `plans`: все выбранные планы из `docs/plans/`.
 - `docs/rules.md`, `docs/arch.md` (если есть).
 - Какие языки и фреймворки в проекте — определи сам.
 - Какие инструменты статанализа уже установлены и работают — определи по конфигам и зависимостям проекта.
@@ -47,6 +59,7 @@ description: 'Анализирует историю `docs/reviews/` и `docs/rev
 - Нарушения архитектурных границ (импорты не из API соседнего модуля).
 - Забытое: error handling, validation, очистка ресурсов.
 - Стиль: имена, форматирование, порядок.
+- Для планов: пропущенные тесты, отсутствующая проверка после шага, слишком крупные шаги, шаги без файлов/модулей, противоречие `docs/rules.md` или `docs/arch.md`, нет критерия готовности, рискованные действия без rollback/backup.
 
 Для каждого паттерна собери: где встречался (ссылки на ревью), сколько раз, в каких файлах.
 
@@ -56,10 +69,11 @@ description: 'Анализирует историю `docs/reviews/` и `docs/rev
 1. Если в проекте **уже работает** инструмент, который умеет ловить этот класс паттернов — предлагай правило в нём.
 2. Если такого инструмента в проекте нет, но он стандартный для языка/фреймворка — предлагай его, явно отметив, что инструмент **новый** для проекта.
 3. **Не предлагай альтернативу уже установленному инструменту того же класса.** Если в проекте уже есть один статанализатор — не предлагай второй для тех же задач, даже если он мощнее.
+4. Для паттернов из планов предлагай проверку плана: скрипт, markdownlint-правило, pre-commit/check, CI-check или custom validator для `docs/plans/*.md`. Не притворяйся, что runtime-линтер кода поймает проблему, которая живёт только в тексте плана.
 
 Каждое предложение содержит:
 - Что ловит (одна-две фразы простым языком).
-- Где встречалось (ссылки на 2–3 ревью).
+- Где встречалось (ссылки на 2–3 источника: ревью, фиксы или планы).
 - Инструмент и тип правила. Если инструмент **новый** для проекта — пометка «требует установки».
 - **Черновик правила** — псевдокод или фрагмент конфигурации.
 - Польза: `low` / `medium` / `high` (по частоте паттерна и вреду от пропуска).
@@ -71,13 +85,14 @@ description: 'Анализирует историю `docs/reviews/` и `docs/rev
 ---
 date: <YYYY-MM-DD HH:MM>
 sources: [docs/reviews/..., docs/review-fixes/...]
+mode: <normal | plans>
 status: draft
 ---
 
 # Предложения по автоматизации
 
 ## Контекст
-- Проанализировано: N ревью + M фиксов
+- Проанализировано: N ревью + M фиксов + K планов
 - Стек проекта: <по конфигам>
 - Уже работающие инструменты: <список>
 
@@ -114,3 +129,4 @@ status: draft
 - Предлагать второй инструмент того же класса в дополнение к уже установленному.
 - Сохранять отчёт куда-либо кроме `docs/automations/`.
 - Дублировать в предложениях правила, которые уже зафиксированы в `docs/rules.md` как автоматизированные.
+- В обычном режиме без `plans` смешивать проблемы планирования с ревью и фиксами.

package/docs/skills/eda-review.md

@@ -1,6 +1,6 @@
 ---
 name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл). Формирует пронумерованные замечания, оценку 0–100, рекомендации «править / на усмотрение / не править». Сохраняет в docs/reviews/. Всегда проверяет своё же ревью тремя параллельными моделями (Sonnet, Haiku, Opus); кросс-CLI (Claude ↔ Codex) включается только флагом `strict`. После каждой проверки сам корректирует ревью. Не правит код — это `eda-fix-by-review`. Все вопросы — через интерактивный вопрос.'
+description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл). Если контекст ревью понятен из запроса или репозитория, не задаёт уточняющий вопрос и сразу выбирает цель. Формирует пронумерованные замечания, оценку 0–100, рекомендации «править / на усмотрение / не править». Сохраняет в docs/reviews/. Всегда проверяет своё же ревью тремя параллельными моделями (Sonnet, Haiku, Opus); кросс-CLI (Claude ↔ Codex) включается только флагом `strict`. После каждой проверки сам корректирует ревью. Не правит код — это `eda-fix-by-review`. Вопросы — только когда без ответа нельзя безопасно продолжать.'
 ---
 
 # Скил: Ревьюер (eda-review)
@@ -17,7 +17,7 @@ description: 'Ревью изменений (незакоммиченный diff
 ## Главные правила
 
 1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Замечания должны опираться на правила проекта, а не на твои общие представления.
-2. **Интерактивные вопросы** — по разделу ниже.
+2. **Интерактивные вопросы** — по разделу ниже. Если контекст понятен, не спрашивай.
 3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
 4. **Мета-ревью тремя моделями — обязательно**, без флага. Кросс-CLI — только в `strict`.
 5. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
@@ -26,6 +26,11 @@ description: 'Ревью изменений (незакоммиченный diff
 
 ## Интерактивные вопросы
 
+Если цель ревью понятна из запроса или текущего состояния репозитория, **не задавай вопрос**. Примеры понятного контекста:
+- пользователь указал файл, папку, PR, ветку или тип diff;
+- в запросе есть «ревью незакоммиченных изменений», «ревью текущей ветки», «проверь PR #N»;
+- в рабочем дереве есть незакоммиченные изменения и пользователь просит «сделай ревью» без других целей.
+
 Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
 - Claude Code: используй `AskUserQuestion`.
 - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
@@ -35,7 +40,13 @@ description: 'Ревью изменений (незакоммиченный diff
 ## Этапы
 
 ### 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/` — прочитай их тоже.
+Сначала попробуй определить цель ревью без вопроса:
+- если пользователь указал файл, папку, 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`. Если в diff видно отсылки к плану из `docs/plans/` или исследованию из `docs/researches/` — прочитай их тоже.
 
 ### 2. Сделать первичное ревью и сохранить
 Пройдись по изменениям. Замечания группируй по типу: bug / архитектура / стиль / тесты / безопасность / производительность / документация. Каждое — с локацией (`file:line`) и предложением «что сделать». Поставь оценку 0–100 (100 — идеально, 0 — переделывать).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.2.5",
+  "version": "0.2.7",
   "description": "Набор скилов eda-* для Claude Code и Codex CLI: research, plan, execute, review, fix, send-review, commit, docs, automate",
   "type": "module",
   "bin": {