@gian-tiaga/eda 3.7.0 → 3.8.0

package/README.md

@@ -3,7 +3,7 @@
 > Поточная разработка с AI-агентами — на русском языке.
 > Пакет готовых скилов и специализированных агентов для **Claude Code** и **Codex CLI**, которые ведут тебя через весь цикл: от исследования до коммита.
 
-`eda` — это двадцать два скила и пакетные агенты для повторяемых ролей. Скил отвечает за пользовательский workflow и оркестрацию, агент — за изолированную работу с закреплённой моделью и ограничениями. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
+`eda` — это двадцать три скила и пакетные агенты для повторяемых ролей. Скил отвечает за пользовательский workflow и оркестрацию, агент — за изолированную работу с закреплённой моделью и ограничениями. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
 
 ---
 
@@ -52,6 +52,7 @@ eda update-all ~/Code
 | `eda-plan-review-fix` | Закрывает проваленные пункты чек-листа минимальным изменением плана с совпадающим SHA-256. План не растёт: сначала удаление и замена, прирост объёма за один заход не больше 3%. Новое ревью не делает и код не меняет | `docs/artifacts/plan-review-fixes/` |
 | `eda-plan-polish` | Оркестрирует изолированный цикл plan-review → plan-review-fix. Хранит снапшот лучшей версии плана: как только score перестаёт расти, останавливается и восстанавливает лучшую версию, а не последнюю. По умолчанию две review-итерации. Кросс-CLI strict не используется | `docs/artifacts/plan-reviews/`, `docs/artifacts/plan-review-fixes/` |
 | `eda-plan-execute` | Управляет выполнением плана по фазам в режиме `subagents`, `main` или `auto`. В `subagents` каждую фазу целиком выполняет отдельный изолированный субагент: он читает план, правила, архитектуру и только business/reference-карточки затронутого поведения и компонентов. Фазы проходят строго последовательно и принимаются независимыми проверяющими. В `main` весь план по тем же правилам выполняет и проверяет основной агент в одном контексте, а `auto` выбирает режим по плану. Отметки подтверждённых задач и журнал ведёт основной агент | `docs/artifacts/executions/` |
+| `eda-just-do-it` | Сразу выполняет задачу из текста рядом с вызовом: определяет scope, загружает только необходимые проектные инструкции, business/reference-карточки, код и тесты, вносит нужные изменения и проверяет результат. Не подменяет выполнение планом и не делает git- или внешние действия без прямого указания | `docs/artifacts/just-do-it/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или плану. Перед правками читает правила, архитектуру и только применимые карточки, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/artifacts/fixes/` |
 | `eda-review` | Оркестрирует отдельные read-only проверки корректности, архитектуры, правил, references, business-правил, плана, качества, тестов, безопасности, производительности, frontend/UI/UX, API, БД, документации и предыдущих ревью. Сохраняет только доказанные дефекты, которые обязательно исправить; косметические и спекулятивные предложения отбрасывает. Любая находка даёт `changes-required`, а чистое ревью — `clean` и 100/100. Без аргументов ревьюит `git diff HEAD` | `docs/artifacts/reviews/` |
 | `eda-fix-by-review` | Применяет все находки из ревью с учётом правил, архитектуры и применимых карточек. Спрашивает только при неоднозначности, конфликте, расширении scope или рискованном действии. В конце ссылается на отчёт прямо в файле ревью | `docs/artifacts/review-fixes/` |
@@ -466,7 +467,7 @@ discover-automations может запускаться от review, fix-by-revie
 
 `eda-manual-test` обычно ставится после `eda-plan-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API, базу, консольные команды, интерфейс и алгоритмы перед ревью или коммитом.
 
-Использовать всю цепочку не обязательно — каждый скил самодостаточен. Для полного прохода одной задачи можно вызвать `eda-orhestra automatic <задача>` или `eda-orhestra manual <задача>`. Разовые варианты: `eda-orhestra main <задача>`, `eda-orhestra main_propagated <задача>`, `eda-orhestra automatic без полировки плана <задача>`, `eda-orhestra полировка кода 2 итерации <задача>`, `eda-orhestra без ручных тестов <задача>`. Постоянный режим исполнения задаётся в `orhestra.execution`, порядок и аргументы — в `orhestra.steps`. Новый проект можно начать с `eda-new-project`; существующий — с `eda-prepare-ai`, `eda-roadmap`, `eda-explore`, или сразу с `eda-plan-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
+Использовать всю цепочку не обязательно — каждый скил самодостаточен. Для полного прохода одной задачи можно вызвать `eda-orhestra automatic <задача>` или `eda-orhestra manual <задача>`. Разовые варианты: `eda-orhestra main <задача>`, `eda-orhestra main_propagated <задача>`, `eda-orhestra automatic без полировки плана <задача>`, `eda-orhestra полировка кода 2 итерации <задача>`, `eda-orhestra без ручных тестов <задача>`. Постоянный режим исполнения задаётся в `orhestra.execution`, порядок и аргументы — в `orhestra.steps`. Для прямой задачи без отдельного процесса вызови `eda-just-do-it <задача>`: скил сам выберет необходимый контекст, выполнит работу и сохранит отчёт. Новый проект можно начать с `eda-new-project`; существующий — с `eda-prepare-ai`, `eda-roadmap`, `eda-explore`, или сразу с `eda-plan-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
 
 Вызов `eda-commit` без контекста охватывает все незакоммиченные tracked-изменения и содержательные untracked-файлы; очевидные кэши, временные и локальные служебные артефакты остаются вне коммитов. Executor сам делит полный состав на необходимое число логически цельных коммитов — один, три или больше. Например, запрос `eda-commit сразу отправь ветку, создай PR и дай ссылку` использует тот же полный состав и выполняет всю указанную цепочку без отдельного вопроса после серии коммитов.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "3.7.0",
+  "version": "3.8.0",
   "description": "Пакет скилов и специализированных агентов eda-* для Claude Code и Codex CLI",
   "type": "module",
   "bin": {

package/skills/eda-just-do-it/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: eda-just-do-it
+description: 'Прямо выполняет задачу, указанную пользователем рядом с вызовом скилла.'
+---
+
+# Скил: Просто сделай (eda-just-do-it)
+
+Сразу доведи задачу пользователя до проверяемого результата в текущем проекте. Не заменяй выполнение планом, исследованием или ревью, если пользователь не попросил именно такой результат.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: требуемый результат, scope, пути, ограничения и явно разрешённые внешние действия. Старое обсуждение используй только там, где пользователь прямо связал его с текущей задачей.
+
+Если входа достаточно, продолжай без подтверждения и без пересказа плана действий. `AskUserQuestion` задавай только когда отсутствует обязательный выбор, требования противоречат друг другу, есть несколько равнозначных целей или без ответа возникает существенный риск сделать не то.
+
+## Главные правила
+
+1. **Делай то, что попросили.** Сам выполни задачу в текущем контексте. Не отправляй пользователя к другому `eda-*`-скилу только потому, что существует более специализированный процесс. Другой скил применяй, только если пользователь явно включил его в задачу.
+2. **Не расширяй scope.** Выполняй необходимые сопутствующие изменения, но не добавляй улучшения, которые не нужны для заданного результата.
+3. **Загружай только нужный контекст.** Сначала определи scope, затем читай относящиеся к нему инструкции, документы, код и тесты. Не загружай все business- и reference-карточки на всякий случай.
+4. **Сохраняй пользовательскую работу.** Перед изменениями проверь текущее состояние рабочей директории и не перезаписывай несвязанные правки.
+5. **Проверяй результат.** Для изменений поведения добавь или обнови точечные тесты. Выполни применимые тесты, линтеры, typecheck, сборку или предметную проверку; не заявляй о том, что не запускалось.
+6. **Внешние и git-действия — только по запросу.** Не коммить, не пушь, не создавай PR, не публикуй и не деплой без прямого указания рядом с вызовом. Для необратимого или разрушительного действия нужен однозначный target; при неоднозначности спроси.
+7. **Артефакт обязателен.** Создай отчёт до первого содержательного изменения и поддерживай его в актуальном состоянии. Заверши отчёт даже при частичном результате, блокере или ошибке.
+
+## Как выбрать контекст
+
+1. Прочитай применимые `AGENTS.md` и другие проектные инструкции для затронутых путей.
+2. Прочитай файлы и артефакты, прямо названные пользователем.
+3. Если меняется проект, прочитай `docs/rules.md` и `docs/arch.md`, когда они существуют.
+4. Сначала определи затронутое поведение. Если есть `docs/business.md`, выбери по описаниям и прочитай только применимые business-карточки из `docs/business/`. Отсутствие подходящей карточки не блокирует работу.
+5. Если есть `docs/references.md`, выбери по индексу и прочитай только карточки затронутых компонентов из `docs/references/`.
+6. Найди минимальный набор исходников, тестов, конфигурации и документации, необходимый для выполнения и проверки задачи. Расширяй контекст только когда обнаруженная зависимость действительно влияет на результат.
+
+Если запрос противоречит проектной инструкции, business-правилу или архитектурному ограничению, не обходи их молча: зафиксируй конфликт в отчёте и запроси недостающее решение через `AskUserQuestion`.
+
+## Выполнение
+
+1. Сформулируй для себя проверяемый результат и границы задачи.
+2. Собери необходимый контекст по правилам выше и проверь текущее состояние проекта.
+3. Создай файл отчёта со статусом `in-progress`.
+4. Выполни задачу полностью. Исправляй ошибки, вызванные своими изменениями; несвязанные проблемы не маскируй и не чини без необходимости.
+5. Проверь фактический результат подходящими командами или наблюдаемым сценарием.
+6. Обнови отчёт только подтверждёнными действиями и результатами, поставь итоговый статус `done`, `partial`, `blocked` или `failed`.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, запиши вопрос и варианты в отчёт.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+## Артефакт
+
+Сохрани отчёт в `docs/artifacts/just-do-it/{YYYY-MM-DD}_{HH-MM}_{slug}.md`. Если имя занято, добавь числовой суффикс. Даже если задача завершилась до изменений, оказалась заблокирована или упала, отчёт должен существовать и честно описывать результат.
+
+```markdown
+---
+date: <YYYY-MM-DD HH:MM>
+status: in-progress
+---
+
+# Just do it: <краткий заголовок>
+
+## Запрос
+<что пользователь поручил сделать>
+
+## Учтённый контекст
+- `<путь>` — <зачем прочитан>
+
+## Что сделано
+| # | Действие или файл | Результат |
+|---|-------------------|-----------|
+| 1 | ... | ... |
+
+## Проверки
+| Команда или сценарий | Результат | Заметки |
+|----------------------|-----------|---------|
+| `<command>` | ✓ / ✗ / не запускалась | ... |
+
+## Осталось
+<«Ничего» либо конкретный остаток, блокер и требуемое решение>
+```
+
+Перед завершением замени `in-progress` на итоговый статус. Не включай в артефакт секреты, токены и лишний вывод команд.
+
+## Финал
+
+Коротко сообщи: что выполнено, чем проверено, что осталось и путь к обязательному отчёту. Если были git- или внешние действия, перечисли только фактически выполненные.