@gian-tiaga/eda 0.8.6 → 1.0.0

package/skills/{eda-send-review.md → eda-send-review/SKILL.md}

@@ -1,15 +1,27 @@
 ---
 name: eda-send-review
-description: 'Отправляет ревью из `docs/reviews/...`, выбранное по тексту рядом с вызовом, на GitHub PR через `gh` — всегда в едином формате: общий комментарий-сводка плюс комментарии к строкам кода (inline). Тип отправки (`comment`/`approve`/`request-changes`) задаёт только статус review, но не структуру вывода. По умолчанию отправляет все пункты; если в тексте указано подмножество — только его. Перед отправкой читает `docs/rules.md` и `docs/arch.md` и строго следует им. Целевой PR определяется из текста или по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку. Не правит код, не делает само ревью. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
+description: 'Отправляет готовое ревью из `docs/reviews/...` на GitHub PR через `gh`: сводку в теле review и замечания комментариями к строкам. Явный `comment`/`approve`/`request-changes` берёт из контекста текущего вызова, без него сразу использует `comment` независимо от score. По умолчанию отправляет все пункты, а по контексту — указанное подмножество. Настройка `send-review.close_previous_reviews` позволяет после успешной отправки скрыть предыдущие сводки eda-send-review и зарезолвить связанные inline-треды; текущий запрос может её переопределить. PR определяет из текста или текущей ветки, после отправки дописывает ссылку в файл. Не правит код и не делает новое ревью.'
 ---
 
 # Скил: Отправитель ревью (eda-send-review)
 
 Берёшь готовое ревью из `docs/reviews/`, отправляешь его на GitHub PR через `gh`. Отправляешь **всегда в одном формате**: общий комментарий-сводка плюс комментарии к строкам кода. В конец файла ревью дописываешь, куда отправил.
 
+## Режим запуска
+
+Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настройки.
+
+Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолт: `send-review.close_previous_reviews: false`.
+
+| Настройка | Значения | Аргументы в сообщении |
+|---|---|---|
+| `send-review.close_previous_reviews` | `true`, `false` | `close_previous_reviews=true/false`, `send-review.close_previous_reviews=true/false`; включение: «закрой предыдущие ревью», «скрой старые комментарии»; выключение: «не закрывай предыдущие ревью», `keep previous reviews` |
+
+Вычисли `$CLOSE_PREVIOUS_REVIEWS` один раз до отправки. Настройку в файле не меняй.
+
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения, какие пункты отправлять и прямые указания.
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, статус отправки, ограничение по пунктам, режим закрытия предыдущих ревью и прямые указания.
 
 Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
@@ -20,8 +32,9 @@ description: 'Отправляет ревью из `docs/reviews/...`, выбр
 3. **Интерактивные вопросы** — по разделу ниже.
 4. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе способа отправки и финальной отметке.
 5. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
-6. **Никаких самостоятельных оценок.** Статус review определяется по оценке ревью и тексту пользователя. `approve` и `request-changes` всегда подтверждаются пользователем.
-7. **Простой язык.** В сообщениях пользователю и комментариях PR без лишних терминов.
+6. **По умолчанию — `COMMENT`.** Статус review определяется только по явному указанию в контексте текущего вызова. Если статуса нет, отправляй `COMMENT` без вопроса. Оценка ревью не меняет event.
+7. **Закрывай только свои предыдущие отправки.** При включённой настройке скрывай только более ранние сводки `eda-send-review`, созданные текущим GitHub-пользователем в целевом PR, и резолви только связанные с ними inline-треды. Чужие комментарии и обсуждения не трогай.
+8. **Простой язык.** В сообщениях пользователю и комментариях PR без лишних терминов.
 
 ## Интерактивные вопросы
 
@@ -30,7 +43,7 @@ description: 'Отправляет ревью из `docs/reviews/...`, выбр
 - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
 - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
 - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для отправки ревью это правило важнее продолжения: не создавай PR, не отправляй approve/request-changes и не меняй статус отправки вместо ответа пользователя.
+- Для отправки ревью это правило важнее продолжения: не создавай PR и не угадывай статус при противоречивых прямых указаниях вместо ответа пользователя. Одно явно указанное действие `approve` или `request-changes` уже является достаточным разрешением и повторного подтверждения не требует.
 
 ## Этапы
 
@@ -38,9 +51,9 @@ description: 'Отправляет ревью из `docs/reviews/...`, выбр
 `gh --version` + `gh auth status`. Если `gh` отсутствует или не авторизован — остановись, сообщи и выйди (это пользователю нужно решить).
 
 ### 2. Выбрать ревью и что отправлять
-Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`) и статус отправки (`comment`, `review-comment`, `approve`, `request-changes`).
+Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`), статус отправки (`comment`, `review-comment`, `approve`, `request-changes`) и указание закрыть или сохранить предыдущие ревью.
 
-Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: оценку, замечания, рекомендации.
+Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: оценку, замечания, рекомендации. Отсутствие статуса отправки само по себе не считается недостатком входа и не требует вопроса.
 
 **Что отправлять.** По умолчанию — все замечания. Если в тексте указано подмножество, отправь только его. Синтаксис свободный, распознавай по смыслу: по номерам («пункты 1, 3, 5»), по обязательности («только обязательные» → раздел «Править обязательно»), по типу («только security» → замечания с этим `Тип`). Выбор влияет и на сводку, и на комментарии к строкам.
 
@@ -50,15 +63,17 @@ description: 'Отправляет ревью из `docs/reviews/...`, выбр
 Если PR нет — `AskUserQuestion`: «PR ещё нет: создать PR из текущей ветки / указать номер существующего PR / прервать». При создании используй `gh pr create` (заголовок и тело — по последним коммитам ветки).
 
 ### 4. Выбрать статус review
+
 Review отправляется всегда; здесь выбирается только его статус (`event`).
 
-| Условие | event | Подтверждение |
+| Контекст текущего вызова | event | Вопрос |
 |---|---|---|
-| score ≥ 80 (или в тексте `approve`) | `APPROVE` | всегда `AskUserQuestion` |
-| score < 50 (или в тексте `request-changes`) | `REQUEST_CHANGES` | всегда `AskUserQuestion` |
-| иначе (или в тексте `comment` / `review-comment`) | `COMMENT` | без подтверждения |
+| явно указано `approve` | `APPROVE` | не задавать |
+| явно указано `request-changes` / «запросить изменения» | `REQUEST_CHANGES` | не задавать |
+| явно указано `comment` / `review-comment` | `COMMENT` | не задавать |
+| статус не указан | `COMMENT` | не задавать |
 
-`comment` и `review-comment` означают review без статуса (`event=COMMENT`) — обычный комментарий-ревью, который тоже несёт сводку и комментарии к строкам. `approve` и `request-changes` подтверждай через `AskUserQuestion` всегда, даже если указаны в тексте. Если предложенный статус противоречит ревью — `AskUserQuestion`: подтвердить / выбрать другой.
+`comment` и `review-comment` означают review без решения о принятии изменений (`event=COMMENT`) — обычный комментарий-ревью, который тоже несёт сводку и комментарии к строкам. Явно приложенный или названный пользователем контекст текущего вызова учитывай наравне с текстом рядом со скиллом. Не выводи статус из score, раздела рекомендаций, не связанного с вызовом старого обсуждения или предыдущих запусков. Если в текущем контексте одновременно указаны несовместимые статусы и приоритет неясен — `AskUserQuestion` с тремя вариантами.
 
 ### 5. Собрать сводку и комментарии к строкам
 Из выбранных пунктов собери две части.
@@ -80,15 +95,26 @@ Review отправляется всегда; здесь выбирается т
 1. **[тип]** `path/file.py:42` — <что не так>. → <что предлагаешь>
 
 _Сгенерировано из `<путь к docs/reviews/...>`_
+<!-- eda-send-review -->
 ```
 
 Раздел «Замечания вне diff» добавляй только если такие пункты есть (см. ниже); иначе опусти его.
 
-**Комментарии к строкам** — по одному на каждое отправляемое замечание, чьё `Где: path:line` входит в diff PR. Для каждого: `{ "path": "<path>", "line": <line>, "side": "RIGHT", "body": "<суть простым языком + рекомендация + как исправить>" }`. Для замечания об удалённой строке используй `"side": "LEFT"`.
+**Комментарии к строкам** — по одному на каждое отправляемое замечание, чьё `Где: path:line` входит в diff PR. Для каждого: `{ "path": "<path>", "line": <line>, "side": "RIGHT", "body": "<суть простым языком + рекомендация + как исправить>\n\n<!-- eda-send-review -->" }`. Для замечания об удалённой строке используй `"side": "LEFT"`.
 
 Какие строки входят в diff — определи по `gh pr diff <num>`. Замечания, чьи строки в diff не попали (или без `path:line`), в комментарии к строкам **не** клади — перенеси их в раздел «Замечания вне diff» сводки, чтобы ничего не потерялось.
 
-### 6. Отправить
+### 6. Зафиксировать предыдущие отправки и отправить
+
+Если `$CLOSE_PREVIOUS_REVIEWS=false`, не запрашивай старые комментарии и переходи сразу к отправке.
+
+Если `$CLOSE_PREVIOUS_REVIEWS=true`, **до новой отправки** получи через `gh api graphql` все страницы `reviews`, `comments` и `reviewThreads` целевого PR. Сохрани два списка:
+
+- `$PREVIOUS_SUMMARY_IDS` — Node ID неминимизированных `PullRequestReview` и fallback-`IssueComment`, у которых `viewerDidAuthor=true`, `viewerCanMinimize=true`, а тело содержит `<!-- eda-send-review -->` или старую метку `_Сгенерировано из \`docs/reviews/...\`_`;
+- `$PREVIOUS_THREAD_IDS` — Node ID незарезолвленных тредов с `viewerCanResolve=true`, у которых корневой комментарий относится через `pullRequestReview.id` к одному из найденных предыдущих review.
+
+Не выбирай предыдущие отправки только по автору: метка `eda-send-review` обязательна. Не включай комментарии других пользователей, немаркированные ручные review и треды, не связанные с найденными review. Обработай пагинацию до `hasNextPage=false`. Поскольку снимок сделан до POST, новая отправка в эти списки не попадёт.
+
 Тело сводки и комментарии собери в один JSON через `mktemp`:
 
 ```json
@@ -105,9 +131,27 @@ gh api "repos/$OWNER_REPO/pulls/<num>/reviews" --method POST --input <payload.js
 Fallback'ы:
 - API упал с `422` из-за конкретных строк — перенеси эти пункты в раздел «Замечания вне diff» сводки и переотправь без них.
 - У цели нет diff/строк PR вовсе (нечего привязывать) — отправь только сводку обычным комментарием: `gh pr comment <num> --body-file <tmpfile>`.
-- Другая ошибка — покажи вывод пользователю и спроси через `AskUserQuestion` (повторить / другой статус / прервать).
+- Другая ошибка — покажи вывод пользователю и спроси через `AskUserQuestion` (повторить / прервать). Не меняй event без нового прямого указания пользователя.
+
+### 7. Закрыть предыдущие отправки
+
+Выполняй этот этап только после успешной новой отправки и только при `$CLOSE_PREVIOUS_REVIEWS=true`.
+
+Каждую старую сводку из `$PREVIOUS_SUMMARY_IDS` скрой как устаревшую — это действие **Hide** в интерфейсе GitHub:
+
+```bash
+gh api graphql -f query='mutation($id: ID!) { minimizeComment(input: {subjectId: $id, classifier: OUTDATED}) { minimizedComment { isMinimized } } }' -F id="$SUMMARY_ID"
+```
+
+Каждый связанный старый тред из `$PREVIOUS_THREAD_IDS` зарезолви:
+
+```bash
+gh api graphql -f query='mutation($id: ID!) { resolveReviewThread(input: {threadId: $id}) { thread { isResolved } } }' -F id="$THREAD_ID"
+```
+
+Обрабатывай все элементы, даже если отдельная мутация упала. Ошибка очистки не отменяет уже отправленное новое ревью и не должна приводить к повторной отправке. Сохрани количества успешных и неуспешных Hide/Resolve для финала.
 
-### 7. Дописать ссылку в файл ревью
+### 8. Дописать ссылку в файл ревью
 В конец `$REVIEW_FILE` добавь:
 
 ```markdown
@@ -115,17 +159,20 @@ Fallback'ы:
 - PR: <URL из ответа gh>
 - Статус: <comment | approve | request-changes>
 - Отправлено пунктов: <сколько / inline + сколько в сводке>
+- Предыдущие ревью: <не закрывались | скрыто N сводок, зарезолвлено M тредов | частично: скрыто N, зарезолвлено M, ошибок K>
 - Дата: <YYYY-MM-DD HH:MM>
 ```
 
-### 8. Финал
-Короткое сообщение: PR-номер и URL, статус отправки, сколько пунктов ушло комментариями к строкам и сколько в сводку, путь к файлу ревью.
+### 9. Финал
+Короткое сообщение: PR-номер и URL, статус отправки, сколько пунктов ушло комментариями к строкам и сколько в сводку, результат закрытия предыдущих ревью и путь к файлу ревью.
 
 ## Чего НЕ делать
 - Делать само ревью или править замечания — это `eda-review` / `eda-fix-by-review`.
 - Отправлять всё одним обычным комментарием PR, когда строки можно привязать к diff — обычный комментарий только fallback при отсутствии diff.
 - Терять замечания вне diff — они идут в сводку отдельным разделом.
-- Отправлять `approve` или `request-changes` без явного подтверждения через `AskUserQuestion`, даже если оценка ≥ 80.
+- Выводить `approve` или `request-changes` из score, рекомендаций или не связанного с вызовом старого контекста — без явного статуса в контексте текущего вызова всегда `COMMENT`.
+- Скрывать или резолвить чужие, ручные или не связанные с предыдущими отправками `eda-send-review` комментарии.
+- Закрывать предыдущие отправки до успешной публикации нового ревью.
 - Передавать тело через `-b "..."` со спецсимволами — только `--input` (Reviews API) или `--body-file` (fallback).
 - Создавать PR молча, если его нет — только через `AskUserQuestion`.
 - Сохранять копии отправленного в отдельные файлы — связь через ссылку в файле ревью.

package/skills/eda-send-review/skill.json

@@ -0,0 +1,7 @@
+{
+  "schemaVersion": 1,
+  "models": {
+    "claude": "sonnet",
+    "codex": "gpt-5.6-terra"
+  }
+}

package/skills/eda-worktree/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: eda-worktree
+description: 'Оркестрирует создание нового git worktree через пакетного агента на `haiku` / `gpt-5.6-luna`. Worktree создаётся рядом с основным проектом в папке `{name}-work-{n}` с одноимённой веткой. Базовую ветку берёт из текста рядом с вызовом, если она указана, иначе спрашивает интерактивно. Не правит код, не коммитит и не мержит обратно.'
+---
+
+# Скил: Создатель worktree (eda-worktree)
+
+Работай как лёгкий оркестратор установленного агента `eda-worktree-executor`. Сам не исследуй git-состояние, не выбирай имя или базу и не выполняй команды.
+
+## Вход из сообщения пользователя
+
+Сохрани весь текст текущего сообщения дословно в `$USER_REQUEST`. Это главный вход: базовая ветка или ref, ограничения и прямые указания.
+
+Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно. При последующем ответе на вопрос сохрани исходный `$USER_REQUEST` и передай ответ отдельно.
+
+## Агент
+
+| Агент | Claude Code | Codex | Доступ |
+|---|---|---|---|
+| `eda-worktree-executor` | `haiku` | `gpt-5.6-luna` | git-write |
+
+- В Claude Code запускай установленный custom agent через `Agent` tool по имени.
+- В Codex запускай установленный custom agent через `spawn_agent` или аналог по имени.
+- Не копируй в task-сообщение системный prompt агента: он уже установлен в `.claude/agents/` или `.codex/agents/`.
+- Передавай агенту только рабочую директорию, данные текущего запуска и требуемый формат результата.
+- Если custom agent или инструмент субагентов недоступен, остановись: `blocked: нужен установленный агент eda-worktree-executor`. Не выполняй его роль основным агентом и не заменяй отдельным CLI-процессом.
+
+## Интерактивные вопросы
+
+Когда агент вернул `blocked`, задай его один конкретный вопрос пользователю через общий паттерн `AskUserQuestion`.
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 1–3 вариантами и остановись до ответа.
+- Codex exec / неинтерактивный запуск: не читай stdin; заверши со статусом `blocked: нужен ответ пользователя`, перечисли вопрос и варианты.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+После ответа продолжи того же агента, если хост это поддерживает. Иначе запусти `eda-worktree-executor` заново с исходным запросом, полным предыдущим результатом и ответом пользователя.
+
+## Процесс
+
+Запусти `eda-worktree-executor` и передай:
+
+```text
+Рабочая директория: <cwd>
+USER_REQUEST:
+<полный дословный запрос>
+
+Верни результат строго по YAML-контракту агента.
+```
+
+Обработай `status`:
+
+- `created` — переходи к финалу;
+- `blocked` — задай вопрос агента и продолжи после ответа;
+- `failed` — коротко сообщи фактическую ошибку и безопасный следующий шаг.
+
+## Финал
+
+Для `created` коротко сообщи из результата агента:
+
+- созданный путь worktree;
+- имя ветки;
+- выбранную базу;
+- предупреждение о незакоммиченных изменениях, если оно есть;
+- команду `cd "<worktree_path>"`;
+- что обратный merge выполняет `eda-merge-worktree <n>` или `eda-merge-worktree work-<n>`.
+
+## Чего НЕ делать
+
+- Выполнять работу `eda-worktree-executor` основным агентом.
+- Править код, docs, конфиги или зависимости.
+- Коммитить, пушить, мержить или удалять worktree и ветки.
+- Терять исходный `$USER_REQUEST` после интерактивного ответа.

package/skills/eda-worktree/skill.json

@@ -0,0 +1,7 @@
+{
+  "schemaVersion": 1,
+  "models": {
+    "claude": "haiku",
+    "codex": "gpt-5.6-luna"
+  }
+}

package/skills/eda-automate.md

@@ -1,185 +0,0 @@
----
-name: eda-automate
-description: 'Анализирует историю `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`; по запросу или `automate.include_plans: true` добавляет `docs/plans/`. Ищет повторяющиеся ошибки и ручные правки, в первую очередь предлагает автоматизации на уровне языка и тулчейна: правила линтера/статанализатора, проверки типов, тесты, pre-commit/CI-скрипты. Если кодовая проверка не закрывает класс проблем, предлагает точечные дополнения к `docs/rules.md`, `docs/arch.md`, MCP-серверы, агентные проверки или новые eda-скилы без дублей с уже установленными инструментами. Не внедряет изменения — сохраняет отчёт в `docs/automations/` с приоритетами и черновиками.'
----
-
-# Скил: Автоматизатор (eda-automate)
-
-Читаешь историю ревью и фиксов, находишь повторяющиеся ошибки, ручные правки и недостающие проверки. Главная цель — предложить автоматизации на уровне языка программирования и тулчейна: правила линтера, статанализатора, typecheck, тесты, pre-commit/CI-проверки, валидаторы планов и скрипты качества. `docs/rules.md`, `docs/arch.md`, MCP-серверы, агентные проверки и новые eda-скилы предлагаешь только как дополнение, когда они реально закрывают повторяющийся класс ошибок и не подменяют проверку кода. Не внедряешь — только сохраняешь отчёт с черновиками и оценкой стоимости.
-
-## Режим запуска
-
-Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
-
-Дефолт: `automate.include_plans: false`.
-
-| Настройка | Значения | Аргументы в сообщении |
-|---|---|---|
-| `automate.include_plans` | `true`, `false` | `plans`, «с планами»; выключение: `normal`, «без планов» |
-
-Обычный режим анализирует `docs/reviews/`, `docs/review-fixes/`, `docs/fixes/`. Режим с планами добавляет `docs/plans/`.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им. Не предлагай то, что уже зафиксировано как автоматизированное правило или архитектурное решение.
-2. **Интерактивные вопросы** — по разделу ниже.
-3. **Не внедряешь изменения.** Только отчёт с предложениями. Внедрение автоматизаций, MCP-серверов, новых скилов или правок `docs/rules.md`/`docs/arch.md` — через `eda-plan` + `eda-execute`.
-4. **Предлагай только повторяющееся.** Минимум — паттерн встречается в 2+ разных ревью или в 3+ местах одного. Единичные замечания не автоматизируем.
-5. **Сначала программная проверка.** Для каждого паттерна сначала оцени, можно ли поймать его линтером, статанализатором, typecheck, тестом, pre-commit/CI-скриптом или валидатором. Агентные решения предлагай только если программная проверка невозможна, слишком дорогая или требует лучшего контекста для AI-агента.
-6. **Каждое предложение — с черновиком.** Не «надо бы что-то сделать», а конкретный фрагмент: правило линтера, псевдокод/skeleton, тестовый сценарий, CI-шаг, конфиг MCP, описание нового скила, текст для `docs/rules.md` или патч для `docs/arch.md`.
-7. **Простой язык. Таблицы** для приоритезации.
-8. **Планы анализируй только когда режим с планами включён.** Режим включают аргумент `plans`, явная просьба пользователя или `automate.include_plans: true` в `docs/settings.yaml`. Если пользователь явно написал `normal` / «без планов», не читай `docs/plans/`.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-
-## Этапы
-
-### 1. Выбрать диапазон
-Определи режим и диапазон по текущему сообщению и `docs/settings.yaml`. Без вопроса используй вход, если он задаёт `plans` / `normal`, последние N, период или конкретные файлы/папки. Если диапазон не указан, но источники есть, используй все ревью + фиксы по ревью + обычные фиксы по умолчанию.
-
-Если вход неоднозначен — `AskUserQuestion`: все ревью и фиксы / все ревью, фиксы и планы / последние N / период / конкретные файлы.
-
-Получи список файлов из `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`. Если нужные папки отсутствуют или пусты, не продолжай с пустым списком: сообщи, каких источников нет; если не осталось ни одного источника, остановись с понятным вопросом или статусом `blocked: нет источников для анализа`.
-
-### 2. Прочитать контекст
-- Все выбранные ревью, отчёты о фиксах по ревью и обычные фиксы.
-- В режиме `plans`: все выбранные планы из `docs/plans/`.
-- `docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
-- Какие языки и фреймворки в проекте — определи сам.
-- Какие инструменты качества уже установлены и работают: линтеры, форматтеры, статанализаторы, typecheck, тесты, coverage, pre-commit, CI, npm/composer/make-скрипты.
-- Какие агентные усиления уже есть: `.claude/skills/`, `.codex/skills/`, MCP-конфиги, локальные скилы, команды для ревью/планирования. Не предлагай дубль уже установленному.
-
-### 3. Найти повторяющиеся паттерны
-Сгруппируй замечания по сути (не по точному тексту). Примеры паттернов:
-- Запрещённые конструкции языка/фреймворка.
-- Нарушения архитектурных границ (импорты не из API соседнего модуля).
-- Забытое: error handling, validation, очистка ресурсов.
-- Пробелы тестов: повторяющиеся регрессии без unit/integration/contract-теста, нет фикстур, нет проверки edge cases.
-- Пробелы тулчейна: нет typecheck, schema validation, coverage threshold, dependency audit, forbidden imports, проверок миграций.
-- Стиль: имена, форматирование, порядок.
-- Для обычных фиксов: повторяющиеся причины правок, одинаковые классы багов, места где агент регулярно вручную добавляет проверки/валидацию/guard clauses.
-- Для планов: пропущенные тесты, отсутствующая проверка после шага, слишком крупные шаги, шаги без файлов/модулей, противоречие `docs/rules.md` или `docs/arch.md`, нет критерия готовности, рискованные действия без rollback/backup.
-- Для агентного процесса: агент регулярно не читает нужный источник, забывает запускать одинаковую команду, не видит контракт из внешней системы, путает формат артефакта или повторяет одну и ту же ошибку в планах/ревью.
-
-Для каждого паттерна собери: где встречался (ссылки на источники), сколько раз, в каких файлах.
-
-### 4. Предложить автоматизации и правки docs
-Для каждого паттерна выбери 1–2 реакции: `automation`, `tests`, `tooling`, `agent`, `rules`, `architecture`.
-
-Приоритет реакций:
-1. `automation` — правило линтера, статанализатора, typecheck, custom validator, pre-commit/CI/check-скрипт.
-2. `tests` — конкретный unit/integration/contract/e2e/regression-тест или тестовый helper, который ловит повторяющийся баг.
-3. `tooling` — новый или донастроенный инструмент качества, если в проекте нет подходящего и инструмент стандартный для стека.
-4. `agent` — MCP-сервер, новая/обновлённая eda-инструкция, специализированная агентная проверка или обязательный источник контекста. Предлагай только когда это закрывает повторяющуюся ошибку AI-процесса или даёт агенту данные, которые нельзя надёжно получить из кода.
-5. `rules` / `architecture` — текстовые правила и архитектурные уточнения, если проблема связана с договорённостью, границей модулей или ownership.
-
-Предпочитай уже установленный инструмент, если он ловит этот класс проблем. Новый инструмент предлагай только если он не дублирует инструмент того же класса. Для проблем из планов предлагай проверку `docs/plans/*.md`, а не runtime-линтер кода. Если правило или архитектура уже зафиксированы, не дублируй текст; предложи только уточнение, которое закрывает повторяющийся случай.
-
-Каждое предложение содержит:
-- Тип: `automation` / `tests` / `tooling` / `agent` / `rules` / `architecture`.
-- Что ловит (одна-две фразы простым языком).
-- Где встречалось (ссылки на 2–3 источника: ревью, фиксы или планы).
-- Для `automation`: инструмент, тип правила и место запуска (`lint`, `test`, `pre-commit`, `CI`, локальный скрипт). Если инструмент **новый** для проекта — пометка «требует установки».
-- Для `tests`: уровень теста, сценарий, фикстуры/данные и команда проверки.
-- Для `tooling`: какой инструмент добавить или донастроить, почему существующие не закрывают проблему.
-- Для `agent`: MCP-сервер, скил или агентная проверка, какие данные/ошибки закрывает, где подключать.
-- Для `rules`: целевой раздел `docs/rules.md` и черновик текста правила.
-- Для `architecture`: целевой раздел `docs/arch.md` и черновик текста или diff-блок.
-- **Черновик** — псевдокод, фрагмент конфигурации или markdown-текст.
-- Польза: `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/..., docs/fixes/...]
-mode: <normal | plans>
-status: draft
----
-
-# Предложения по автоматизации
-
-## Контекст
-- Проанализировано: N ревью + M фиксов по ревью + F обычных фиксов + K планов
-- Стек проекта: <по конфигам>
-- Уже работающие инструменты: <список>
-- Уже найденные скилы/MCP/агентные проверки: <список или «не найдены»>
-
-## Проверки кода и тесты
-
-### 1. <название паттерна>
-- **Тип:** automation / tests / tooling
-- **Что ловит:** ...
-- **Встречалось в:** `docs/reviews/...` (×2), `docs/reviews/...` (×3)
-- **Инструмент:** <название или текущий test runner> (если новый для проекта — пометка «требует установки»)
-- **Где запускать:** lint / test / pre-commit / CI / локальный скрипт
-- **Черновик:**
-  ```<язык>
-  <псевдокод/skeleton>
-  ```
-- **Польза:** low/medium/high
-
-### 2. ...
-
-## Агентные усиления
-
-### 1. <название паттерна>
-- **Тип:** agent
-- **Что закрывает:** <какую повторяющуюся ошибку процесса или нехватку контекста>
-- **Встречалось в:** `docs/reviews/...` (×2), `docs/fixes/...` (×1)
-- **Предложение:** MCP-сервер / новый eda-скил / правка существующего скила / специализированная агентная проверка
-- **Черновик:**
-  ```markdown
-  <конфиг, описание скила или инструкция агентной проверки>
-  ```
-- **Польза:** low/medium/high
-
-## Правила и архитектура
-
-### 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 | automation | ... | high | 1 |
-
-## Рекомендация
-<какие 1–3 внедрить первыми и почему — простыми словами>
-```
-
-### 6. Финал
-Короткое сообщение: путь к отчёту, сколько паттернов нашёл, сколько предложений по проверкам кода/тестам, сколько по агентным усилениям и сколько по `docs/rules.md`/`docs/arch.md`, топ-3 рекомендации простыми словами, подсказка дальше — «хочешь внедрить → `eda-plan` для плана, потом `eda-execute`».
-
-## Чего НЕ делать
-- Внедрять автоматизации, ставить MCP-серверы, создавать скилы или править `docs/rules.md`/`docs/arch.md` — только предлагать.
-- Предлагать на основе единичных замечаний — иначе получится белый шум.
-- Игнорировать существующий стек и предлагать новый инструмент, когда уже есть подходящий.
-- Предлагать второй инструмент того же класса в дополнение к уже установленному.
-- Подменять линтер, статанализатор или тест MCP-сервером/скилом, если ошибку можно надёжно поймать программной проверкой.
-- Предлагать MCP-сервер или новый скил без повторяющегося процесса, нехватки контекста или явной ошибки AI-агента.
-- Сохранять отчёт куда-либо кроме `docs/automations/`.
-- Дублировать в предложениях правила или архитектурные тезисы, которые уже зафиксированы в `docs/rules.md` или `docs/arch.md`.
-- В обычном режиме без `plans` смешивать проблемы планирования с ревью и фиксами.

package/skills/eda-commit.md

@@ -1,91 +0,0 @@
----
-name: eda-commit
-description: 'Формирует коммит из незакоммиченных изменений с учётом текста рядом с вызовом: файлы, сообщение коммита и намерение push. Читает docs/rules.md и docs/arch.md, строго следует им и истории коммитов, включая связанные артефакты из `docs/**`, которые создали скилы. Коммитит без `--no-verify`. После коммита спрашивает интерактивно про push / merge в main + переключение + удаление ветки / ничего; inline push не обходит подтверждение. Не правит логику кода, не пишет тесты — это `eda-execute`, `eda-fix` или `eda-fix-by-review`.'
----
-
-# Скил: Коммитер (eda-commit)
-
-Берёшь незакоммиченные изменения, делаешь один аккуратный коммит, спрашиваешь у пользователя что делать дальше с веткой и remote.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Интерактивные вопросы** — по разделу ниже.
-2. **Не правишь логику кода и не пишешь тесты.** Если на этапе коммита что-то не работает (упал hook, обнаружились сырые правки) — спроси через `AskUserQuestion`, не «допиливай» молча.
-3. **Pre-commit / pre-push hooks не отключай.** Никаких `--no-verify`. Hook упал → правим причину → новый коммит (не `--amend`).
-4. **Один логический коммит за вызов.** Если в diff видишь явно разные изменения — спроси через `AskUserQuestion`, разделить на несколько коммитов или коммитить одним.
-5. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе файлов, сообщении коммита и дальнейших действиях.
-6. **Не пропускай `docs/**`.** Планы, исследования, журналы, ревью, отчёты о фиксах, автоматизации, `docs/rules.md` и `docs/arch.md`, созданные или обновлённые скилами, — часть изменения. Если они относятся к текущей задаче, добавляй их в коммит вместе с кодом.
-7. **Простой язык** в сообщениях пользователю.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для коммита это правило важнее требования довести операцию до конца: не делай push, merge, force-push, удаление ветки или исправление вне задачи вместо ответа пользователя.
-
-## Этапы
-
-### 1. Посмотреть состояние
-`git status`, `git diff --stat`, `git log -5 --oneline`, `docs/rules.md`, `docs/arch.md` (если есть) — определи стиль коммитов проекта и строго следуй правилам/архитектуре. Смотри и tracked, и untracked файлы.
-
-Если незакоммиченных изменений нет — сообщи и выйди.
-
-Разбери текст рядом с вызовом: он может задавать конкретные файлы для коммита, черновик сообщения коммита или намерение `push`. Используй список файлов и сообщение, если они не противоречат diff и правилам проекта. Inline `push` считай намерением для этапа 3, но не разрешением обойти обязательный вопрос после коммита. Merge, force-push, удаление ветки, спорные файлы и файлы с признаками секретов всё равно требуют подтверждения по правилам ниже.
-
-### 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).
-
-### 3. Спросить про дальнейшее
-Определи `HAS_REMOTE` (`git remote -v`), `CURRENT_BRANCH` (`git rev-parse --abbrev-ref HEAD`) и целевую ветку: `main` или основную ветку из `origin/HEAD`.
-
-Собери варианты для `AskUserQuestion`:
-
-| Вариант | Когда показывать |
-|---|---|
-| **Push** | Если `HAS_REMOTE` |
-| **Merge в main + переключение + удаление текущей ветки** | Если `CURRENT_BRANCH != main` |
-| **Ничего больше** | Всегда, если показываются другие варианты (или multiSelect, если хочешь push **и** merge — выбирай) |
-
-Показывай только применимые варианты. Если мы в 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 .` — добавляй файлы по имени.
-- Пропускать связанные файлы из `docs/**` только потому, что это документация или артефакты скилов.
-- Коммитить файлы с похожими на секреты именами (`.env`, `credentials*`) без явного подтверждения через `AskUserQuestion`.
-- Push --force в main или master.
-- Делать ревью или править логику кода — это другие скилы.