@gian-tiaga/eda 0.6.1 → 0.7.0

package/skills/eda-fix-by-review.md

@@ -1,6 +1,6 @@
 ---
 name: eda-fix-by-review
-description: 'Применяет замечания из ревью (`docs/reviews/...`) или из текста рядом с вызовом к коду. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно; «не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью (это `eda-review`), не коммитит (это `eda-commit`). Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
+description: 'Применяет замечания из ревью (`docs/reviews/...`) или из текста рядом с вызовом к коду. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно, кроме явного режима `apply-optional`, где применяет их без вопроса. «Не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью и не коммитит.'
 ---
 
 # Скил: Исправитель по ревью (eda-fix-by-review)
@@ -13,16 +13,19 @@ description: 'Применяет замечания из ревью (`docs/revie
 
 Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
+## Режим запуска
+
+Обычный режим: «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
+
+Режим `apply-optional`: применяешь «Править обязательно» и «На усмотрение автора» без вопроса. Этот режим нужен для `eda-polish`, где пользователь заранее разрешил автоматическую доводку по optional-замечаниям. Пункты «Не править» всё равно пропускаешь.
+
 ## Главные правила
 
 1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Это рамка проекта. Один раз в начале.
 2. **Интерактивные вопросы** — по разделу ниже.
 3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
 4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
-5. **Логика по группам ревью:**
-   - «Править обязательно» — правишь сразу, без вопросов.
-   - «На усмотрение автора» — спроси через `AskUserQuestion` (объединяй до 4 пунктов за раунд: применить / пропустить / переформулировать).
-   - «Не править» — пропускаешь молча, в отчёте отметь как «осознанно не применено».
+5. **Логика по группам ревью:** «Править обязательно» — правишь сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`; «Не править» — пропускаешь и отмечаешь в отчёте.
 6. **Тесты — внутри той же правки.** Замечание касается поведения → правка кода + тесты к ней в одном шаге, точечно прогнал.
 7. **Финальный полный прогон тестов и линтеров — обязателен.** В конце, не на каждой правке.
 8. **Простой язык** в формулировках и сообщениях. **Таблицы** для отчёта о фиксах.
@@ -34,17 +37,12 @@ description: 'Применяет замечания из ревью (`docs/revie
 - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
 - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
 - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-- Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора», не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
+- Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
 
 ## Этапы
 
 ### 1. Выбрать ревью
-Сначала разбери текст рядом с вызовом:
-- если указан путь к ревью — используй его как `$REVIEW_FILE`;
-- если указано название ревью или часть названия — найди совпадение в `docs/reviews/`;
-- если написано «последнее ревью» — возьми самый новый файл из `docs/reviews/`;
-- если указаны номера замечаний — применяй только эти пункты, сохрани фильтр в отчёте;
-- если сами замечания вставлены в сообщение — используй режим `$REVIEW_SOURCE=review_text`, не выбирай файл ревью и сохрани отчёт с `review: text`.
+Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», номера замечаний или вставленный текст замечаний. Если замечания вставлены в сообщение — используй режим `$REVIEW_SOURCE=review_text`, не выбирай файл ревью и сохрани отчёт с `review: text`.
 
 Если найдено ровно одно ревью — используй режим `$REVIEW_SOURCE=review_file` и продолжай без вопроса. Если замечания даны текстом — используй режим `$REVIEW_SOURCE=review_text` и продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста и вход не содержит замечания — остановись с понятным вопросом или статусом `blocked: нужно ревью`.
 
@@ -58,7 +56,7 @@ description: 'Применяет замечания из ревью (`docs/revie
 ### 3. Применить замечания
 Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
 - **Править обязательно** → правишь сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
-- **На усмотрение автора** → собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя.
+- **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` применяй сразу без вопроса.
 - **Не править** → пропусти.
 
 Останавливайся и спрашивай, если: замечание непонятно / противоречит коду / задевает рискованное вне ревью (удаление, миграции, секреты).
@@ -107,7 +105,7 @@ status: done
 ## Чего НЕ делать
 - Делать само ревью — это `eda-review`.
 - Коммитить, пушить — это `eda-commit`.
-- Применять «на усмотрение» молча — только через `AskUserQuestion`.
+- Применять «на усмотрение» молча без явного режима `apply-optional`.
 - Игнорировать «не править» и пробовать «на всякий случай» — это нарушает решение ревью.
 - Гонять полный сьют и линтеры на каждой правке — только в конце.
 - Пропускать финальную проверку.

package/skills/eda-fix.md

@@ -7,13 +7,6 @@ description: 'Делает обычные фиксы по плану, файлу
 
 Делаешь конкретные исправления и сохраняешь отчёт, чтобы потом было понятно, что и почему правилось. Это не выполнение большого плана и не фиксы по ревью: вход может быть короткой строкой, баг-репортом, файлом плана или списком задач.
 
-## Режимы вызова
-
-| Режим | Запуск | Что делает |
-|---|---|---|
-| По контексту | `eda-fix <что исправить>` | Делает фиксы по тексту пользователя |
-| По плану | `eda-fix docs/plans/<file>.md` | Делает фиксы по указанному плану |
-
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
@@ -41,11 +34,7 @@ description: 'Делает обычные фиксы по плану, файлу
 ## Этапы
 
 ### 1. Определить задачу
-Определи `$FIX_CONTEXT`:
-- если передан путь к файлу — прочитай его;
-- если это план из `docs/plans/` — используй его как план фикса;
-- если передан текст — используй его как контекст;
-- если входа нет или он неоднозначен — спроси через `AskUserQuestion`.
+Определи `$FIX_CONTEXT`: путь к файлу прочитай, план из `docs/plans/` используй как план фикса, текст используй как контекст. Если входа нет или он неоднозначен — спроси через `AskUserQuestion`.
 
 ### 2. Прочитать рамку проекта
 Прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Если `$FIX_CONTEXT` ссылается на research, review, issue или другой файл — прочитай и его.

package/skills/eda-merge-worktree.md

@@ -7,14 +7,6 @@ description: 'Мержит ветку из соседнего git worktree `{nam
 
 Мержишь ветку из соседнего worktree в текущую ветку. Этот скил не чистит worktree после merge: папка и ветка остаются на месте.
 
-## Режимы вызова
-
-| Режим | Запуск | Что делает |
-|---|---|---|
-| По номеру | `eda-merge-worktree 1` | Мержит ветку из `{name}-work-1` |
-| По короткому имени | `eda-merge-worktree work-1` | Мержит ветку из `{name}-work-1` |
-| По полному имени | `eda-merge-worktree app-work-1` | Мержит ветку из указанного worktree |
-
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: номер worktree, короткое имя `work-<n>`, полное имя `{name}-work-<n>`, ограничения и прямые указания.
@@ -70,9 +62,7 @@ git rev-parse --abbrev-ref HEAD
 
 Из `git worktree list --porcelain` найди запись, у которой basename пути равен `$WORKTREE_NAME`.
 
-Для найденной записи определи:
-- `$SOURCE_WORKTREE_PATH`;
-- `$SOURCE_BRANCH` из строки `branch refs/heads/<name>`.
+Для найденной записи определи `$SOURCE_WORKTREE_PATH` и `$SOURCE_BRANCH` из строки `branch refs/heads/<name>`.
 
 Если worktree не найден — остановись и покажи доступные варианты. Если исходный worktree в detached HEAD или ветку определить нельзя — остановись: нечего безопасно мержить по имени ветки.
 
@@ -115,12 +105,7 @@ git merge "$SOURCE_BRANCH"
 
 ### 6. Финал
 
-Короткое сообщение:
-- какая ветка смержена;
-- в какую текущую ветку;
-- из какого worktree;
-- статус результата (`merged`, `already up to date` или `conflict`);
-- явно: worktree и исходная ветка не удалялись.
+Короткое сообщение: какая ветка смержена, в какую текущую ветку, из какого worktree, статус результата (`merged`, `already up to date` или `conflict`) и явно: worktree и исходная ветка не удалялись.
 
 ## Чего НЕ делать