@gian-tiaga/eda 0.8.6 → 1.0.1

package/skills/eda-docs.md

@@ -1,123 +0,0 @@
----
-name: eda-docs
-description: 'Создаёт или обновляет документы, указанные рядом с вызовом: `docs/rules.md` (правила, подстроенные под реальный проект), `docs/arch.md` (архитектура проекта), `AGENTS.md` (описание проекта, стек, ссылки на документы и команды) или все три. Анализирует стек сам, учитывает переданный контекст и уже существующие практики. Не правит код.'
----
-
-# Скил: Документатор (eda-docs)
-
-Создаёшь или обновляешь три документа: `docs/rules.md`, `docs/arch.md` и шапку `AGENTS.md`. Документы должны быть подстроены под конкретный проект: его стек, текущую структуру, уже установленные инструменты, стиль кода, тесты, инфраструктуру и контекст, который передал пользователь.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения, прямые указания и дополнительный контекст о том, какие правила, архитектурные решения или боли проекта пользователь хочет зафиксировать.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Интерактивные вопросы** — по разделу ниже.
-2. **Не правишь код**, не ставишь пакеты, не меняешь конфиги. Только документы.
-3. **Подстройка под проект.** Не генерируй универсальный шаблон. Каждое правило и архитектурное описание должны опираться на найденные файлы, стек, текущие команды, зависимости, структуру директорий, существующие docs и контекст пользователя.
-4. **Строгость только там, где она уместна для проекта.** Если предлагаешь усиление строгости или новый инструмент, объясни реальную проблему проекта; не предлагай дубль уже установленному инструменту того же класса.
-5. **Существующие документы** не переписываем молча. Если файл уже есть — `AskUserQuestion`: переписать / дополнить / создать рядом.
-6. **Простой язык.** Сначала объясняй простыми словами, зачем правило или архитектурный блок нужен проекту. Потом формулируй конкретику.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-
-## Этапы
-
-### 1. Проанализировать проект
-Определи сам: языки и фреймворки, тест-фреймворк, базы данных, инфраструктуру (контейнеры, CI), уже установленные линтеры/статанализаторы, главную ветку, стиль коммитов (по `git log`).
-
-### 2. Прочитать существующие docs
-`docs/rules.md`, `docs/arch.md`, `AGENTS.md` (если есть). Прочитай их и строго следуй уже зафиксированной рамке, если задача не требует её изменить. Запомни, что в них уже зафиксировано — чтобы не дублировать и не противоречить.
-
-### 3. Уточнить, что обновляем
-Если пользователь указал `rules`, `docs/rules.md`, `arch`, `docs/arch.md`, `AGENTS.md` или «все» — используй этот список без вопроса. Если список документов не указан или неоднозначен — `AskUserQuestion`: все три / только rules / только arch / только AGENTS / выбрать несколько.
-
-Для каждого существующего файла задай отдельный `AskUserQuestion`: переписать с нуля / дополнить / оставить как есть.
-
-### 4. Сформировать план `docs/rules.md`
-Не используй фиксированный шаблон разделов. Сначала на основе анализа проекта и контекста пользователя предложи набор правил, которые действительно нужны этому проекту.
-
-Перед записью файла задай `AskUserQuestion` с коротким планом: 5–12 правил или групп правил, зачем каждое нужно проекту, что подтверждено практикой, а что является предложением. Если пользователь передал контекст заранее, используй его как основной источник намерения, но сверяй с реальным стеком и файлами.
-
-Из ответа пользователя сформируй план `docs/rules.md`, а затем сам документ. Формат документа выбирай под проект: разделы, таблицы, списки и примеры должны помогать читать и применять правила, а не соответствовать заранее заданной форме.
-
-В готовом `docs/rules.md` обязательно должны быть:
-- краткое объяснение, зачем документ нужен;
-- правила, привязанные к текущему стеку, структуре и командам проекта;
-- объяснение простым языком, зачем нужно каждое важное правило;
-- команды проверки, если они реально есть в проекте;
-- отдельный блок предложений, если есть полезные идеи, которые ещё не приняты или не настроены.
-
-### 5. Сформировать план `docs/arch.md`
-Не используй фиксированный шаблон архитектуры. Архитектурный документ должен описывать фактическую форму проекта: модули, границы, потоки данных, внешние зависимости и решения, которые реально видны в коде или переданы пользователем.
-
-Перед записью файла задай `AskUserQuestion` с коротким планом: 4–10 архитектурных блоков, зачем каждый нужен читателю, что подтверждено кодом, что является выводом из структуры, а что требует подтверждения пользователя.
-
-Из ответа пользователя сформируй план `docs/arch.md`, а затем сам документ. Формат выбирай под проект. Если схему, таблицу модулей или список потоков данных полезно читать — добавь. Если они создают шум — не добавляй.
-
-В готовом `docs/arch.md` обязательно должны быть:
-- простое описание, что делает система и где её границы;
-- описание ключевых частей проекта на языке текущего стека;
-- зависимости между важными частями;
-- фактические команды, входные точки или runtime-компоненты, если они есть;
-- явное разделение подтверждённых фактов, выводов из кода и предположений, если уверенности недостаточно.
-
-### 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/skills/eda-execute.md

@@ -1,140 +0,0 @@
----
-name: eda-execute
-description: 'Исполняет план из docs/plans/ по пути или описанию рядом с вызовом. Перед правками читает план, `docs/rules.md` и `docs/arch.md`; правила и архитектура обязательны к исполнению. Если шаг плана им противоречит, останавливается и спрашивает пользователя. Правит код, в конце прогоняет полный сьют тестов и линтеры. Прогресс — чекбоксы в файле плана + журнал в `docs/executions/`; в конец плана дописывается ссылка на журнал. Не коммитит (это `eda-commit`), не делает ревью (это `eda-review`).'
----
-
-# Скил: Исполнитель (eda-execute)
-
-Берёшь готовый план из `docs/plans/`, выполняешь до конца, ведёшь журнал. Останавливаешься только при реальных проблемах.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **План, `docs/rules.md` и `docs/arch.md` — обязательная рамка исполнения.** Перед правками прочитай план, `docs/rules.md` и `docs/arch.md`, если они есть. `docs/rules.md` и `docs/arch.md` обязательны к исполнению, а не просто к прочтению. Выполняй план только в той форме, которая строго следует правилам и архитектуре проекта.
-2. **Конфликт блокирует выполнение.** Если шаг плана противоречит коду, `docs/rules.md` или `docs/arch.md`, не исполняй его молча и не выбирай обходной путь сам. Спроси: адаптировать выполнение под правила/архитектуру, вернуться к `eda-plan` для исправления плана или изменить правила/архитектуру отдельной задачей.
-3. **Не додумывай план.** Шаг непонятен — спроси через `AskUserQuestion`, не «доразрабатывай» молча.
-4. **Иди целиком.** Не делай паузы «для подтверждения» после каждого шага; останавливайся только при конфликте, падении проверки, риске потери данных или рискованной операции вне плана.
-5. **Проверки нельзя подавлять.** Не отключай линтеры, тесты, typecheck, static analysis и другие проверки; не добавляй игноры, исключения из проверок, ослабление правил или изменение команд так, чтобы проверка перестала запускаться. Пиши и правь код так, чтобы проверки проходили по сути.
-6. **Не коммить, не пушь, не делай ревью.** Это другие скилы.
-7. **Пиши просто.** В сообщениях, вопросах и журнале используй простой язык; таблицы — для структурированных данных.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для выполнения кода это правило важнее требования идти целиком: не додумывай план, не исполняй шаги вопреки `docs/rules.md` или `docs/arch.md`, не делай рискованные операции и не правь чужие/несвязанные поломки вместо ответа пользователя.
-
-## Этапы
-
-### 1. Выбрать план
-Сначала разбери текст рядом с вызовом:
-- если указан путь к плану — используй его как `$PLAN_FILE`;
-- если указано название плана или часть названия — найди совпадение в `docs/plans/`;
-- если написано «последний план» — возьми самый новый файл из `docs/plans/`;
-- если вставлен текст плана — используй его как план выполнения и при инициализации прогресса сохрани/привяжи к файлу в `docs/plans/`, если это безопасно и однозначно.
-
-Если найден ровно один план — продолжай без вопроса. Если найдено несколько одинаково подходящих планов — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/plans/`. Если `docs/plans/` отсутствует или пуста и вход не содержит план — остановись с понятным вопросом или статусом `blocked: нужен план`. Запиши путь в `$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` (если есть). Тест-фреймворк проекта определи сам по конфигам и существующим тестам.
-
-Перед выполнением проверь, нет ли в плане шагов, зависимостей, API, миграций, границ модулей, команд проверки или решений, которые противоречат правилам или архитектуре. Если конфликт есть — остановись и задай `AskUserQuestion` по варианту из главных правил.
-
-### 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. Перед правкой сверяешь действие с `docs/rules.md` и `docs/arch.md`.
-2. Если правила или архитектура задают способ реализации, границы модулей, команды проверки, требования к тестам, миграциям, API, безопасности или документации — следуй им даже тогда, когда план описан менее строго.
-3. Если есть конфликт с правилами или архитектурой — не правь код, задай `AskUserQuestion`.
-4. Сделай правки.
-5. Выполни проверки, если они прямо указаны в шаге.
-6. Поставь `[x]` в файле плана и допиши строку в таблицу журнала.
-
-Останавливайся и спрашивай через `AskUserQuestion`, если тесты к шагу упали и не правятся быстро, шаг противоречит коду, `docs/rules.md` или `docs/arch.md`, либо задевает рискованное вне плана. Архитектурное решение по ходу — записывай в «Изменения в 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`».
-
-## Чего НЕ делать
-- Коммитить, пушить, делать кросс-ревью изменений.
-- Гонять полный сьют и линтеры на каждом шаге.
-- Пропускать финальную проверку.
-- Делать паузу после каждого шага «для подтверждения».
-- Пропускать обновление чекбоксов и журнала — иначе теряется состояние.
-- Делать рискованное (удаление файлов, миграции, секреты) без подтверждения, даже если упомянуто в плане.
-- Подавлять ошибки линтеров, тестов, typecheck или других проверок вместо исправления кода.
-- Считать `docs/rules.md` и `docs/arch.md` просто контекстом для ознакомления.
-- Исполнять план, который противоречит правилам или архитектуре проекта.
-- Обходить правило или архитектурное ограничение без явного решения пользователя.

package/skills/eda-merge-worktree.md

@@ -1,116 +0,0 @@
----
-name: eda-merge-worktree
-description: 'Мержит ветку из соседнего git worktree `{name}-work-{n}` в текущую ветку. Аргумент принимает как номер `1`, короткое имя `work-1` или полное имя `{name}-work-1`. Перед merge проверяет текущий worktree и исходный worktree на незакоммиченные изменения. После успешного merge не удаляет worktree и ветку.'
----
-
-# Скил: Merge из worktree (eda-merge-worktree)
-
-Мержишь ветку из соседнего worktree в текущую ветку. Этот скил не чистит worktree после merge: папка и ветка остаются на месте.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: номер worktree, короткое имя `work-<n>`, полное имя `{name}-work-<n>`, ограничения и прямые указания.
-
-Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если аргумент не указан, он противоречивый, найдено несколько равных вариантов или есть риск смержить не ту ветку. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Merge только в текущую ветку.** Не переключайся на другую целевую ветку без явного указания пользователя.
-2. **Аргумент worktree обязателен.** Принимай `1`, `work-1` или полное имя `{name}-work-1`.
-3. **Не удаляй worktree и ветку после merge.** Даже при успешном merge cleanup не выполняется.
-4. **Не правь код вручную.** Если merge дал конфликт, остановись и покажи, какие файлы требуют ручного решения.
-5. **Не коммить и не пушь.** Merge-коммит создаёт только сам `git merge`, если Git решит, что он нужен.
-6. **Простой язык** в сообщениях пользователю.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале.
-
-## Этапы
-
-### 1. Проверить git-репозиторий
-
-Выполни:
-
-```bash
-git rev-parse --show-toplevel
-git worktree list --porcelain
-git rev-parse --abbrev-ref HEAD
-```
-
-Если это не git-репозиторий — остановись и сообщи. Если текущий worktree в detached HEAD — остановись: merge должен идти в именованную ветку.
-
-Определи основной worktree по первой записи `worktree <path>` из `git worktree list --porcelain`. Из его basename получи `$PROJECT_NAME`.
-
-### 2. Нормализовать аргумент
-
-Пусть `$ARG` — значение рядом с вызовом.
-
-Правила:
-- `1` → `$WORKTREE_NAME=$PROJECT_NAME-work-1`;
-- `work-1` → `$WORKTREE_NAME=$PROJECT_NAME-work-1`;
-- `$PROJECT_NAME-work-1` → `$WORKTREE_NAME=$ARG`;
-- другое значение → попробуй найти worktree с basename `$ARG`; если не найден — остановись и покажи доступные worktree.
-
-Если `$ARG` не указан, спроси через `AskUserQuestion` и предложи найденные worktree с именами по шаблону `$PROJECT_NAME-work-<n>`.
-
-### 3. Найти исходный worktree и ветку
-
-Из `git worktree list --porcelain` найди запись, у которой basename пути равен `$WORKTREE_NAME`.
-
-Для найденной записи определи `$SOURCE_WORKTREE_PATH` и `$SOURCE_BRANCH` из строки `branch refs/heads/<name>`.
-
-Если worktree не найден — остановись и покажи доступные варианты. Если исходный worktree в detached HEAD или ветку определить нельзя — остановись: нечего безопасно мержить по имени ветки.
-
-Если `$SOURCE_WORKTREE_PATH` совпадает с текущим worktree — остановись: нужно запускать merge из целевого worktree, а не из исходного.
-
-### 4. Проверить чистоту
-
-Проверь текущий worktree:
-
-```bash
-git status --porcelain
-```
-
-Проверь исходный worktree:
-
-```bash
-git -C "$SOURCE_WORKTREE_PATH" status --porcelain
-```
-
-Если где-то есть незакоммиченные изменения — остановись и объясни, где именно. Нельзя мержить, пока изменения не закоммичены, не застешены или не убраны пользователем.
-
-Если текущая ветка уже содержит `$SOURCE_BRANCH`, сообщи, что merge не нужен, и выйди без действий.
-
-### 5. Выполнить merge
-
-Выполни:
-
-```bash
-git merge "$SOURCE_BRANCH"
-```
-
-Если Git сообщает `Already up to date`, это успешный результат.
-
-Если появились конфликты, остановись. Покажи:
-- что merge начат и требует ручного решения;
-- список конфликтных файлов из `git status --short`;
-- что пользователь должен разрешить конфликты и завершить merge вручную.
-
-Не пытайся автоматически разрешать конфликты.
-
-### 6. Финал
-
-Короткое сообщение: какая ветка смержена, в какую текущую ветку, из какого worktree, статус результата (`merged`, `already up to date` или `conflict`) и явно: worktree и исходная ветка не удалялись.
-
-## Чего НЕ делать
-
-- Удалять worktree через `git worktree remove`.
-- Удалять исходную ветку через `git branch -d` или `git branch -D`.
-- Делать push.
-- Править файлы для решения конфликтов.
-- Мержить грязный исходный worktree, потому что незакоммиченные изменения не попадут в merge.

package/skills/eda-polish.md

@@ -1,113 +0,0 @@
----
-name: eda-polish
-description: 'Автономно доводит изменения до заданной оценки ревью: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional`, и повторяет цикл до порога качества или лимита итераций. Все обязательные замечания чинятся, optional-замечания fix-агент применяет или отклоняет сам с обоснованием. По умолчанию цель — 95/100, лимит — 5 итераций; порог можно переопределить в сообщении (`до 90`, `threshold 90`). Каждый шаг запускается в изолированном субагенте или отдельном CLI-процессе. Не коммитит и не отправляет ревью.'
----
-
-# Скил: Доводка по ревью (eda-polish)
-
-Оркестрируешь цикл проверки и исправления: черновое ревью, проверка ревью, применение замечаний, новое ревью. Сам не пишешь ревью и не правишь код в основном агенте — каждый шаг запускаешь в изолированном субагенте или отдельном CLI-процессе.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: target для ревью, путь к плану, PR/ветку/diff/файл, желаемый порог, лимит итераций, ограничения и прямые указания.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск полировать не те изменения. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Режим запуска
-
-Порог качества по умолчанию — `95`. Пользователь может переопределить его в текущем сообщении: `до 90`, `threshold 90`, `цель 90`. Допустимые значения — от `1` до `100`.
-
-Лимит по умолчанию — `5` итераций. Пользователь может явно задать меньший или больший лимит словами `лимит 3`, `max iterations 3`, `не больше 3 кругов`.
-
-`strict` или `normal` передавай в `eda-review-check` только если пользователь явно указал режим. Если режима нет, запускай `eda-review-check` без режима: он сам прочитает `docs/settings.yaml`. `eda-review draft` всегда остаётся draft без субагентов.
-
-## Главные правила
-
-1. **Изоляция шагов обязательна.** `eda-review draft`, `eda-review-check` и `eda-fix-by-review apply-optional` запускаются отдельными субагентами или отдельными CLI-процессами. Главный агент только управляет циклом и читает артефакты.
-2. **Не коммитишь и не отправляешь ревью.** Это работа `eda-commit` и `eda-send-review`.
-3. **Не обходишь границы скилов.** Ревью делает `eda-review draft`, проверку ревью делает `eda-review-check`, правки делает `eda-fix-by-review apply-optional`.
-4. **Цель цикла — score из проверенного ревью.** Сравнивай порог только с ревью после `eda-review-check`, не с draft.
-5. **Обязательные замечания исправляются все.** Для шага фиксов всегда передавай `apply-optional`, чтобы `eda-fix-by-review` не спрашивал пользователя в цикле: все пункты «править обязательно» он обязан исправить, а по пунктам «на усмотрение автора» сам решает, применить или отклонить с причиной.
-6. **Останавливайся на блокерах.** Если любой субагент завершился `blocked`, проверки не проходят из-за нерешённой причины, нет применимых замечаний или score не растёт два круга подряд — останови цикл и объясни причину.
-7. **Не скрывай неудачную сходимость.** Если лимит достигнут, финал должен прямо сказать, какая оценка получилась и какие ревью/фиксы были последними.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-
-## Запуск субагентов
-
-Каждый запуск должен получать полный, самодостаточный prompt: какой скилл выполнить, какой target или файл использовать, что считать успехом, где искать артефакт результата. Передавай только текущий вход и пути к созданным файлам, а не длинную историю чата.
-
-- Claude Code: запускай шаги через `Agent` tool, по одному шагу за раз. Для каждого шага проси агента использовать нужный скилл и вернуть путь к созданному или обновлённому файлу.
-- Codex interactive: если доступен инструмент субагентов (`spawn_agent` или аналог), запускай шаги через него. Не делай ревью или фиксы основным агентом, когда субагенты доступны.
-- Codex exec / неинтерактивный fallback: запускай каждый шаг отдельным `codex exec` с явной инструкцией использовать нужный скилл. Следующий шаг стартует только после чтения артефакта предыдущего.
-- Если нет ни субагентов, ни CLI-fallback, остановись со статусом `blocked: нужен инструмент изолированного запуска`.
-
-## Этапы
-
-### 1. Подготовить цель и параметры
-
-Определи `$TARGET_CONTEXT` так же, как это делает `eda-review`: указанный файл/папка/PR/ветка, незакоммиченный diff или diff текущей ветки от base. Если план указан — сохрани путь и передавай его в каждый `eda-review draft`. Если план нужен, но не указан и не определяется однозначно, вопрос задаст субагент `eda-review draft`; при его `blocked` останови весь цикл.
-
-Создай внутренний журнал итераций в сообщении агента: номер, review file, checked score, fix report, причина перехода к следующему кругу. Отдельный файл журнала не нужен.
-
-### 2. Итерационный цикл
-
-Повторяй до достижения порога или лимита:
-
-1. Запусти изолированный шаг:
-
-   ```text
-   Используй скилл eda-review draft. Сделай черновое ревью для: <TARGET_CONTEXT>. Если есть план: <PLAN_FILE>. Сохрани ревью в docs/reviews/ и верни только путь к файлу и score.
-   ```
-
-2. Получи `$REVIEW_FILE` из ответа или найди самый новый файл, созданный после старта шага. Если файл не найден — остановись `blocked: review file не создан`.
-
-3. Запусти изолированный шаг:
-
-   ```text
-   Используй скилл eda-review-check <режим, только если пользователь указал strict или normal>. Проверь ревью: <REVIEW_FILE>. Верни путь к ревью, итоговый score, статус и список meta_reviewers.
-   ```
-
-4. Прочитай `$REVIEW_FILE` после проверки и извлеки `score`. Если `score >= threshold`, останови цикл как успешный.
-
-5. Если score ниже порога, проверь, есть ли в ревью пункты «править обязательно» или «на усмотрение автора». Если применимых пунктов нет — остановись `blocked: нет применимых замечаний для повышения оценки`.
-
-6. Запусти изолированный шаг:
-
-   ```text
-   Используй скилл eda-fix-by-review apply-optional. Разбери замечания из ревью: <REVIEW_FILE>. Все пункты «править обязательно» исправь. По каждому пункту «на усмотрение автора» сам реши, применять ли его; отклонённые optional-пункты запиши с причиной в отчёт и ссылку в ревью, чтобы следующие ревьюеры не повторяли их без новых аргументов. Сохрани отчёт в docs/review-fixes/ и верни путь к отчёту, результат финальных проверок и состояние git.
-   ```
-
-7. Если фикс завершился `blocked`, с ошибкой проверок или без применённых правок — останови цикл и покажи причину.
-
-8. Перейди к следующей итерации на обновлённом рабочем дереве.
-
-Если score не растёт два проверенных круга подряд, остановись раньше лимита: дальнейший цикл, скорее всего, повторит те же замечания.
-
-### 3. Финал
-
-Короткое сообщение:
-- результат: `достигнут порог`, `достигнут лимит`, `blocked`, `нет применимых замечаний`, `score не растёт`;
-- итоговая оценка и порог;
-- сколько итераций выполнено;
-- путь к последнему ревью;
-- путь к последнему отчёту фиксов, если он был;
-- результат финальной проверки из последнего `eda-fix-by-review`;
-- состояние git («не закоммичено»).
-
-Если порог достигнут — предложи дальше `eda-commit`. Если остановка неуспешная — назови следующий конкретный шаг: ручное решение блокера, изменение порога или отдельный `eda-review strict`.
-
-## Чего НЕ делать
-
-- Делать ревью, проверку ревью или фиксы основным агентом вместо запуска скилов.
-- Запускать следующий шаг, не прочитав артефакт предыдущего.
-- Сравнивать порог с draft-оценкой до `eda-review-check`.
-- Продолжать после `blocked` или красных финальных проверок.
-- Коммитить, пушить или отправлять ревью.
-- Переписывать `docs/settings.yaml` или менять правила проекта ради достижения оценки.