@gian-tiaga/eda 0.6.2 → 0.8.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (20) hide show
  1. package/README.md +49 -13
  2. package/bin/cli.js +5 -1
  3. package/lib/install.js +158 -6
  4. package/package.json +2 -2
  5. package/skills/eda-automate.md +61 -52
  6. package/skills/eda-commit.md +2 -9
  7. package/skills/eda-docs.md +7 -18
  8. package/skills/eda-execute.md +10 -11
  9. package/skills/eda-explore.md +17 -49
  10. package/skills/eda-fix-by-review.md +12 -14
  11. package/skills/eda-fix.md +1 -12
  12. package/skills/eda-merge-worktree.md +2 -17
  13. package/skills/eda-plan.md +120 -338
  14. package/skills/eda-polish.md +113 -0
  15. package/skills/eda-review-check.md +149 -0
  16. package/skills/eda-review.md +36 -114
  17. package/skills/eda-roadmap.md +3 -23
  18. package/skills/eda-send-review.md +2 -10
  19. package/skills/eda-start.md +226 -0
  20. package/skills/eda-worktree.md +2 -15
package/skills/eda-automate.md CHANGED
@@ -1,20 +1,23 @@
1
1
  ---
2
2
  name: eda-automate
3
- description: 'Анализирует историю `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`, а по тексту рядом с вызовом или настройке `automate.include_plans: true` в `docs/settings.yaml` может включать `docs/plans/`, последние N, период или конкретные файлы. Ищет повторяющиеся замечания, фиксы и проблемы планирования, предлагает автоматизации, а также черновики дополнений для `docs/rules.md` и `docs/arch.md`. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет изменения — выдаёт приоритезированный список с черновиками правил, проверок и правок документации. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
3
+ 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/` с приоритетами и черновиками.'
4
4
  ---
5
5
 
6
6
  # Скил: Автоматизатор (eda-automate)
7
7
 
8
- Читаешь историю ревью и фиксов, находишь повторяющиеся замечания и исправления, предлагаешь, какие из них можно поймать автоматически: кастомным правилом линтера, статанализатора, pre-commit-проверкой. Также предлагаешь, что стоит дописать в `docs/rules.md` или `docs/arch.md`, если повторяющийся паттерн лучше закрепить правилом проекта или архитектурным описанием. Если передан аргумент `plans`, дополнительно читаешь планы из `docs/plans/` и ищешь повторяющиеся проблемы планирования, которые можно ловить автоматической проверкой плана. Не внедряешь — только предлагаешь, с черновиками и оценкой стоимости.
8
+ Читаешь историю ревью и фиксов, находишь повторяющиеся ошибки, ручные правки и недостающие проверки. Главная цель — предложить автоматизации на уровне языка программирования и тулчейна: правила линтера, статанализатора, typecheck, тесты, pre-commit/CI-проверки, валидаторы планов и скрипты качества. `docs/rules.md`, `docs/arch.md`, MCP-серверы, агентные проверки и новые eda-скилы предлагаешь только как дополнение, когда они реально закрывают повторяющийся класс ошибок и не подменяют проверку кода. Не внедряешь — только сохраняешь отчёт с черновиками и оценкой стоимости.
9
9
 
10
- ## Режимы вызова
10
+ ## Режим запуска
11
11
 
12
- | Режим | Запуск | Что анализирует |
12
+ Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
13
+
14
+ Дефолт: `automate.include_plans: false`.
15
+
16
+ | Настройка | Значения | Аргументы в сообщении |
13
17
  |---|---|---|
14
- | Обычный | `eda-automate` | `docs/reviews/` + `docs/review-fixes/` + `docs/fixes/` |
15
- | С планами | `eda-automate plans` | `docs/reviews/` + `docs/review-fixes/` + `docs/fixes/` + `docs/plans/` |
18
+ | `automate.include_plans` | `true`, `false` | `plans`, «с планами»; выключение: `normal`, «без планов» |
16
19
 
17
- Если в `docs/settings.yaml` указано `automate.include_plans: true`, режим с планами включён по умолчанию. Явное указание пользователя в текущем сообщении важнее настройки: `plans` / «с планами» включает планы, `normal` / «без планов» выключает их для текущего запуска.
20
+ Обычный режим анализирует `docs/reviews/`, `docs/review-fixes/`, `docs/fixes/`. Режим с планами добавляет `docs/plans/`.
18
21
 
19
22
  ## Вход из сообщения пользователя
20
23
 
@@ -22,24 +25,16 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
22
25
 
23
26
  Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
24
27
 
25
- ## Настройки проекта
26
-
27
- Перед выбором режима прочитай `docs/settings.yaml`, если файл есть.
28
-
29
- Если файла нет — используй значение по умолчанию:
30
- - `automate.include_plans: false`
31
-
32
- Прямое указание пользователя в текущем сообщении важнее `docs/settings.yaml`.
33
-
34
28
  ## Главные правила
35
29
 
36
30
  1. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им. Не предлагай то, что уже зафиксировано как автоматизированное правило или архитектурное решение.
37
31
  2. **Интерактивные вопросы** — по разделу ниже.
38
- 3. **Не внедряешь изменения.** Только отчёт с предложениями. Внедрение автоматизаций или правок `docs/rules.md`/`docs/arch.md` — через `eda-plan` + `eda-execute`.
32
+ 3. **Не внедряешь изменения.** Только отчёт с предложениями. Внедрение автоматизаций, MCP-серверов, новых скилов или правок `docs/rules.md`/`docs/arch.md` — через `eda-plan` + `eda-execute`.
39
33
  4. **Предлагай только повторяющееся.** Минимум — паттерн встречается в 2+ разных ревью или в 3+ местах одного. Единичные замечания не автоматизируем.
40
- 5. **Каждое предложение — с черновиком.** Не «надо бы что-то сделать», а конкретный фрагмент: правило линтера, псевдокод/skeleton, текст для `docs/rules.md` или патч для `docs/arch.md`.
41
- 6. **Простой язык. Таблицы** для приоритезации.
42
- 7. **Планы анализируй только когда режим с планами включён.** Режим включают аргумент `plans`, явная просьба пользователя или `automate.include_plans: true` в `docs/settings.yaml`. Если пользователь явно написал `normal` / «без планов», не читай `docs/plans/`.
34
+ 5. **Сначала программная проверка.** Для каждого паттерна сначала оцени, можно ли поймать его линтером, статанализатором, typecheck, тестом, pre-commit/CI-скриптом или валидатором. Агентные решения предлагай только если программная проверка невозможна, слишком дорогая или требует лучшего контекста для AI-агента.
35
+ 6. **Каждое предложение — с черновиком.** Не «надо бы что-то сделать», а конкретный фрагмент: правило линтера, псевдокод/skeleton, тестовый сценарий, CI-шаг, конфиг MCP, описание нового скила, текст для `docs/rules.md` или патч для `docs/arch.md`.
36
+ 7. **Простой язык. Таблицы** для приоритезации.
37
+ 8. **Планы анализируй только когда режим с планами включён.** Режим включают аргумент `plans`, явная просьба пользователя или `automate.include_plans: true` в `docs/settings.yaml`. Если пользователь явно написал `normal` / «без планов», не читай `docs/plans/`.
43
38
 
44
39
  ## Интерактивные вопросы
45
40
 
@@ -52,21 +47,9 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
52
47
  ## Этапы
53
48
 
54
49
  ### 1. Выбрать диапазон
55
- Определи режим и диапазон по тексту рядом с вызовом и `docs/settings.yaml`. Если передан `plans`, указаны файлы из `docs/plans/`, пользователь явно просит анализ планов или `automate.include_plans: true` — включи планы в источники без отдельного вопроса. Если пользователь явно просит `normal` / «без планов» — не включай планы, даже если настройка включена.
56
-
57
- Без вопроса используй вход, если он задаёт:
58
- - `plans` / анализ планов;
59
- - `normal` / без планов;
60
- - последние N (`последние 5`, `last 10`);
61
- - период (`за 30 дней`, `с YYYY-MM-DD по YYYY-MM-DD`);
62
- - конкретные файлы или папки.
63
-
64
- Если диапазон не указан, но источники есть, используй все ревью + фиксы по ревью + обычные фиксы по умолчанию. Если вход неоднозначен — `AskUserQuestion`: какую историю анализировать.
65
- - Все ревью + фиксы по ревью + обычные фиксы
66
- - Все ревью + фиксы по ревью + обычные фиксы + планы
67
- - Последние N (5/10/20)
68
- - За период (последние N дней)
69
- - Конкретные файлы
50
+ Определи режим и диапазон по текущему сообщению и `docs/settings.yaml`. Без вопроса используй вход, если он задаёт `plans` / `normal`, последние N, период или конкретные файлы/папки. Если диапазон не указан, но источники есть, используй все ревью + фиксы по ревью + обычные фиксы по умолчанию.
51
+
52
+ Если вход неоднозначен — `AskUserQuestion`: все ревью и фиксы / все ревью, фиксы и планы / последние N / период / конкретные файлы.
70
53
 
71
54
  Получи список файлов из `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`. Если нужные папки отсутствуют или пусты, не продолжай с пустым списком: сообщи, каких источников нет; если не осталось ни одного источника, остановись с понятным вопросом или статусом `blocked: нет источников для анализа`.
72
55
 
@@ -75,35 +58,43 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
75
58
  - В режиме `plans`: все выбранные планы из `docs/plans/`.
76
59
  - `docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
77
60
  - Какие языки и фреймворки в проекте — определи сам.
78
- - Какие инструменты статанализа уже установлены и работают — определи по конфигам и зависимостям проекта.
61
+ - Какие инструменты качества уже установлены и работают: линтеры, форматтеры, статанализаторы, typecheck, тесты, coverage, pre-commit, CI, npm/composer/make-скрипты.
62
+ - Какие агентные усиления уже есть: `.claude/skills/`, `.codex/skills/`, MCP-конфиги, локальные скилы, команды для ревью/планирования. Не предлагай дубль уже установленному.
79
63
 
80
64
  ### 3. Найти повторяющиеся паттерны
81
65
  Сгруппируй замечания по сути (не по точному тексту). Примеры паттернов:
82
66
  - Запрещённые конструкции языка/фреймворка.
83
67
  - Нарушения архитектурных границ (импорты не из API соседнего модуля).
84
68
  - Забытое: error handling, validation, очистка ресурсов.
69
+ - Пробелы тестов: повторяющиеся регрессии без unit/integration/contract-теста, нет фикстур, нет проверки edge cases.
70
+ - Пробелы тулчейна: нет typecheck, schema validation, coverage threshold, dependency audit, forbidden imports, проверок миграций.
85
71
  - Стиль: имена, форматирование, порядок.
86
72
  - Для обычных фиксов: повторяющиеся причины правок, одинаковые классы багов, места где агент регулярно вручную добавляет проверки/валидацию/guard clauses.
87
73
  - Для планов: пропущенные тесты, отсутствующая проверка после шага, слишком крупные шаги, шаги без файлов/модулей, противоречие `docs/rules.md` или `docs/arch.md`, нет критерия готовности, рискованные действия без rollback/backup.
74
+ - Для агентного процесса: агент регулярно не читает нужный источник, забывает запускать одинаковую команду, не видит контракт из внешней системы, путает формат артефакта или повторяет одну и ту же ошибку в планах/ревью.
88
75
 
89
76
  Для каждого паттерна собери: где встречался (ссылки на источники), сколько раз, в каких файлах.
90
77
 
91
78
  ### 4. Предложить автоматизации и правки docs
92
- Для каждого паттерна выбери подходящий тип реакции. Один паттерн может дать 1–2 предложения, если нужны и правило в docs, и автоматическая проверка.
79
+ Для каждого паттерна выбери 1–2 реакции: `automation`, `tests`, `tooling`, `agent`, `rules`, `architecture`.
93
80
 
94
- 1. Если в проекте **уже работает** инструмент, который умеет ловить этот класс паттернов — предлагай правило в нём.
95
- 2. Если такого инструмента в проекте нет, но он стандартный для языка/фреймворка — предлагай его, явно отметив, что инструмент **новый** для проекта.
96
- 3. **Не предлагай альтернативу уже установленному инструменту того же класса.** Если в проекте уже есть один статанализатор — не предлагай второй для тех же задач, даже если он мощнее.
97
- 4. Для паттернов из планов предлагай проверку плана: скрипт, markdownlint-правило, pre-commit/check, CI-check или custom validator для `docs/plans/*.md`. Не притворяйся, что runtime-линтер кода поймает проблему, которая живёт только в тексте плана.
98
- 5. Если паттерн повторяется потому, что правило проекта отсутствует, расплывчатое или противоречит практике — предложи дополнение к `docs/rules.md`.
99
- 6. Если паттерн повторяется из-за неясной границы модулей, слоя, API, ownership, потоков данных или зависимостей — предложи правку `docs/arch.md`.
100
- 7. Если правило уже есть в `docs/rules.md` или архитектура уже описана в `docs/arch.md`, не дублируй текст. Предлагай только уточнение, если текущая формулировка реально не закрывает повторяющийся случай.
81
+ Приоритет реакций:
82
+ 1. `automation` — правило линтера, статанализатора, typecheck, custom validator, pre-commit/CI/check-скрипт.
83
+ 2. `tests` — конкретный unit/integration/contract/e2e/regression-тест или тестовый helper, который ловит повторяющийся баг.
84
+ 3. `tooling` — новый или донастроенный инструмент качества, если в проекте нет подходящего и инструмент стандартный для стека.
85
+ 4. `agent` — MCP-сервер, новая/обновлённая eda-инструкция, специализированная агентная проверка или обязательный источник контекста. Предлагай только когда это закрывает повторяющуюся ошибку AI-процесса или даёт агенту данные, которые нельзя надёжно получить из кода.
86
+ 5. `rules` / `architecture` — текстовые правила и архитектурные уточнения, если проблема связана с договорённостью, границей модулей или ownership.
87
+
88
+ Предпочитай уже установленный инструмент, если он ловит этот класс проблем. Новый инструмент предлагай только если он не дублирует инструмент того же класса. Для проблем из планов предлагай проверку `docs/plans/*.md`, а не runtime-линтер кода. Если правило или архитектура уже зафиксированы, не дублируй текст; предложи только уточнение, которое закрывает повторяющийся случай.
101
89
 
102
90
  Каждое предложение содержит:
103
- - Тип: `automation` / `rules` / `architecture`.
91
+ - Тип: `automation` / `tests` / `tooling` / `agent` / `rules` / `architecture`.
104
92
  - Что ловит (одна-две фразы простым языком).
105
93
  - Где встречалось (ссылки на 2–3 источника: ревью, фиксы или планы).
106
- - Для `automation`: инструмент и тип правила. Если инструмент **новый** для проекта — пометка «требует установки».
94
+ - Для `automation`: инструмент, тип правила и место запуска (`lint`, `test`, `pre-commit`, `CI`, локальный скрипт). Если инструмент **новый** для проекта — пометка «требует установки».
95
+ - Для `tests`: уровень теста, сценарий, фикстуры/данные и команда проверки.
96
+ - Для `tooling`: какой инструмент добавить или донастроить, почему существующие не закрывают проблему.
97
+ - Для `agent`: MCP-сервер, скил или агентная проверка, какие данные/ошибки закрывает, где подключать.
107
98
  - Для `rules`: целевой раздел `docs/rules.md` и черновик текста правила.
108
99
  - Для `architecture`: целевой раздел `docs/arch.md` и черновик текста или diff-блок.
109
100
  - **Черновик** — псевдокод, фрагмент конфигурации или markdown-текст.
@@ -120,20 +111,23 @@ mode: <normal | plans>
120
111
  status: draft
121
112
  ---
122
113
 
123
- # Предложения по автоматизации и правилам
114
+ # Предложения по автоматизации
124
115
 
125
116
  ## Контекст
126
117
  - Проанализировано: N ревью + M фиксов по ревью + F обычных фиксов + K планов
127
118
  - Стек проекта: <по конфигам>
128
119
  - Уже работающие инструменты: <список>
120
+ - Уже найденные скилы/MCP/агентные проверки: <список или «не найдены»>
129
121
 
130
- ## Автоматизации
122
+ ## Проверки кода и тесты
131
123
 
132
124
  ### 1. <название паттерна>
125
+ - **Тип:** automation / tests / tooling
133
126
  - **Что ловит:** ...
134
127
  - **Встречалось в:** `docs/reviews/...` (×2), `docs/reviews/...` (×3)
135
- - **Инструмент:** <название> (если новый для проекта — пометка «требует установки»)
136
- - **Черновик правила:**
128
+ - **Инструмент:** <название или текущий test runner> (если новый для проекта — пометка «требует установки»)
129
+ - **Где запускать:** lint / test / pre-commit / CI / локальный скрипт
130
+ - **Черновик:**
137
131
  ```<язык>
138
132
  <псевдокод/skeleton>
139
133
  ```
@@ -141,6 +135,19 @@ status: draft
141
135
 
142
136
  ### 2. ...
143
137
 
138
+ ## Агентные усиления
139
+
140
+ ### 1. <название паттерна>
141
+ - **Тип:** agent
142
+ - **Что закрывает:** <какую повторяющуюся ошибку процесса или нехватку контекста>
143
+ - **Встречалось в:** `docs/reviews/...` (×2), `docs/fixes/...` (×1)
144
+ - **Предложение:** MCP-сервер / новый eda-скил / правка существующего скила / специализированная агентная проверка
145
+ - **Черновик:**
146
+ ```markdown
147
+ <конфиг, описание скила или инструкция агентной проверки>
148
+ ```
149
+ - **Польза:** low/medium/high
150
+
144
151
  ## Правила и архитектура
145
152
 
146
153
  ### 1. <название паттерна>
@@ -164,13 +171,15 @@ status: draft
164
171
  ```
165
172
 
166
173
  ### 6. Финал
167
- Короткое сообщение: путь к отчёту, сколько паттернов нашёл, сколько предложений по автоматизациям и сколько по `docs/rules.md`/`docs/arch.md`, топ-3 рекомендации простыми словами, подсказка дальше — «хочешь внедрить → `eda-plan` для плана, потом `eda-execute`».
174
+ Короткое сообщение: путь к отчёту, сколько паттернов нашёл, сколько предложений по проверкам кода/тестам, сколько по агентным усилениям и сколько по `docs/rules.md`/`docs/arch.md`, топ-3 рекомендации простыми словами, подсказка дальше — «хочешь внедрить → `eda-plan` для плана, потом `eda-execute`».
168
175
 
169
176
  ## Чего НЕ делать
170
- - Внедрять автоматизации или править `docs/rules.md`/`docs/arch.md` — только предлагать.
177
+ - Внедрять автоматизации, ставить MCP-серверы, создавать скилы или править `docs/rules.md`/`docs/arch.md` — только предлагать.
171
178
  - Предлагать на основе единичных замечаний — иначе получится белый шум.
172
179
  - Игнорировать существующий стек и предлагать новый инструмент, когда уже есть подходящий.
173
180
  - Предлагать второй инструмент того же класса в дополнение к уже установленному.
181
+ - Подменять линтер, статанализатор или тест MCP-сервером/скилом, если ошибку можно надёжно поймать программной проверкой.
182
+ - Предлагать MCP-сервер или новый скил без повторяющегося процесса, нехватки контекста или явной ошибки AI-агента.
174
183
  - Сохранять отчёт куда-либо кроме `docs/automations/`.
175
184
  - Дублировать в предложениях правила или архитектурные тезисы, которые уже зафиксированы в `docs/rules.md` или `docs/arch.md`.
176
185
  - В обычном режиме без `plans` смешивать проблемы планирования с ревью и фиксами.
package/skills/eda-commit.md CHANGED
@@ -56,10 +56,7 @@ description: 'Формирует коммит из незакоммиченны
56
56
  Если hook упал — прочитай вывод, исправь причину, повтори через **новый** коммит (не amend).
57
57
 
58
58
  ### 3. Спросить про дальнейшее
59
- Определи:
60
- - `HAS_REMOTE` = есть ли удалённый репозиторий (`git remote -v`).
61
- - `CURRENT_BRANCH` = текущая ветка (`git rev-parse --abbrev-ref HEAD`).
62
- - Целевая ветка — `main` (если у проекта другая основная — определи по `git rev-parse --abbrev-ref origin/HEAD`).
59
+ Определи `HAS_REMOTE` (`git remote -v`), `CURRENT_BRANCH` (`git rev-parse --abbrev-ref HEAD`) и целевую ветку: `main` или основную ветку из `origin/HEAD`.
63
60
 
64
61
  Собери варианты для `AskUserQuestion`:
65
62
 
@@ -69,11 +66,7 @@ description: 'Формирует коммит из незакоммиченны
69
66
  | **Merge в main + переключение + удаление текущей ветки** | Если `CURRENT_BRANCH != main` |
70
67
  | **Ничего больше** | Всегда, если показываются другие варианты (или multiSelect, если хочешь push **и** merge — выбирай) |
71
68
 
72
- Логика:
73
- - Оба варианта применимы → 3 опции в `AskUserQuestion`.
74
- - Только `push` → 2 опции (push / ничего).
75
- - Только `merge` → 2 опции (merge+switch+delete / ничего).
76
- - Ни тот ни другой (мы в main без remote) → **не задавать вопрос**, сразу финал.
69
+ Показывай только применимые варианты. Если мы в main без remote — не задавай вопрос, сразу финал.
77
70
 
78
71
  Действия по выбору:
79
72
 
package/skills/eda-docs.md CHANGED
@@ -18,10 +18,9 @@ description: 'Создаёт или обновляет документы, ук
18
18
  1. **Интерактивные вопросы** — по разделу ниже.
19
19
  2. **Не правишь код**, не ставишь пакеты, не меняешь конфиги. Только документы.
20
20
  3. **Подстройка под проект.** Не генерируй универсальный шаблон. Каждое правило и архитектурное описание должны опираться на найденные файлы, стек, текущие команды, зависимости, структуру директорий, существующие docs и контекст пользователя.
21
- 4. **Строгость только там, где она уместна для проекта.** Правила должны помогать поддерживать проект, а не превращаться в список всех возможных best practices. Если предлагаешь усиление строгости — объясни, какую реальную проблему проекта оно закрывает.
22
- 5. **Можно предлагать инструменты, которых ещё нет в проекте**, если они стандартные для стека и закрывают найденную проблему. Не предлагай дубль уже установленному того же класса. Предложение нового инструмента не становится правилом, пока пользователь не согласовал его.
23
- 6. **Существующие документы** не переписываем молча. Если файл уже есть — `AskUserQuestion`: переписать / дополнить / создать рядом.
24
- 7. **Простой язык.** Сначала объясняй простыми словами, зачем правило или архитектурный блок нужен проекту. Потом формулируй конкретику.
21
+ 4. **Строгость только там, где она уместна для проекта.** Если предлагаешь усиление строгости или новый инструмент, объясни реальную проблему проекта; не предлагай дубль уже установленному инструменту того же класса.
22
+ 5. **Существующие документы** не переписываем молча. Если файл уже есть — `AskUserQuestion`: переписать / дополнить / создать рядом.
23
+ 6. **Простой язык.** Сначала объясняй простыми словами, зачем правило или архитектурный блок нужен проекту. Потом формулируй конкретику.
25
24
 
26
25
  ## Интерактивные вопросы
27
26
 
@@ -40,20 +39,14 @@ description: 'Создаёт или обновляет документы, ук
40
39
  `docs/rules.md`, `docs/arch.md`, `AGENTS.md` (если есть). Прочитай их и строго следуй уже зафиксированной рамке, если задача не требует её изменить. Запомни, что в них уже зафиксировано — чтобы не дублировать и не противоречить.
41
40
 
42
41
  ### 3. Уточнить, что обновляем
43
- Сначала разбери текст рядом с вызовом. Если пользователь указал `rules`, `docs/rules.md`, `arch`, `docs/arch.md`, `AGENTS.md` или «все» — используй этот список без вопроса. Если список документов не указан или неоднозначен — `AskUserQuestion`: какие документы трогаем — все три / только rules / только arch / только AGENTS / выбрать несколько.
42
+ Если пользователь указал `rules`, `docs/rules.md`, `arch`, `docs/arch.md`, `AGENTS.md` или «все» — используй этот список без вопроса. Если список документов не указан или неоднозначен — `AskUserQuestion`: все три / только rules / только arch / только AGENTS / выбрать несколько.
44
43
 
45
- Для каждого существующего файла — **отдельный** `AskUserQuestion`: переписать с нуля / дополнить / оставить как есть.
44
+ Для каждого существующего файла задай отдельный `AskUserQuestion`: переписать с нуля / дополнить / оставить как есть.
46
45
 
47
46
  ### 4. Сформировать план `docs/rules.md`
48
47
  Не используй фиксированный шаблон разделов. Сначала на основе анализа проекта и контекста пользователя предложи набор правил, которые действительно нужны этому проекту.
49
48
 
50
- Перед записью файла задай `AskUserQuestion` с коротким планом правил:
51
- - 5–12 предлагаемых правил или групп правил.
52
- - Для каждого пункта: короткое название и 1–2 простых предложения, зачем это нужно именно этому проекту.
53
- - Отдельно пометь, какие пункты основаны на уже существующих практиках проекта, а какие являются предложениями.
54
- - Спроси, с чем пользователь согласен, что убрать, что изменить и какой дополнительный контекст учесть.
55
-
56
- Если пользователь передал контекст заранее, используй его как основной источник намерения, но всё равно сверяй с реальным стеком и файлами проекта. Не добавляй правило только потому, что оно типично для языка или фреймворка; добавляй его, если оно помогает этому проекту.
49
+ Перед записью файла задай `AskUserQuestion` с коротким планом: 5–12 правил или групп правил, зачем каждое нужно проекту, что подтверждено практикой, а что является предложением. Если пользователь передал контекст заранее, используй его как основной источник намерения, но сверяй с реальным стеком и файлами.
57
50
 
58
51
  Из ответа пользователя сформируй план `docs/rules.md`, а затем сам документ. Формат документа выбирай под проект: разделы, таблицы, списки и примеры должны помогать читать и применять правила, а не соответствовать заранее заданной форме.
59
52
 
@@ -67,11 +60,7 @@ description: 'Создаёт или обновляет документы, ук
67
60
  ### 5. Сформировать план `docs/arch.md`
68
61
  Не используй фиксированный шаблон архитектуры. Архитектурный документ должен описывать фактическую форму проекта: модули, границы, потоки данных, внешние зависимости и решения, которые реально видны в коде или переданы пользователем.
69
62
 
70
- Перед записью файла задай `AskUserQuestion` с коротким планом архитектурного описания:
71
- - 4–10 предлагаемых архитектурных блоков.
72
- - Для каждого блока: короткое название и 1–2 простых предложения, зачем этот блок нужен читателю.
73
- - Отдельно пометь, что подтверждено кодом, что является выводом из структуры, а что требует подтверждения пользователя.
74
- - Спроси, с чем пользователь согласен, что убрать, что изменить и какой дополнительный контекст учесть.
63
+ Перед записью файла задай `AskUserQuestion` с коротким планом: 4–10 архитектурных блоков, зачем каждый нужен читателю, что подтверждено кодом, что является выводом из структуры, а что требует подтверждения пользователя.
75
64
 
76
65
  Из ответа пользователя сформируй план `docs/arch.md`, а затем сам документ. Формат выбирай под проект. Если схему, таблицу модулей или список потоков данных полезно читать — добавь. Если они создают шум — не добавляй.
77
66
 
package/skills/eda-execute.md CHANGED
@@ -15,14 +15,13 @@ description: 'Исполняет план из docs/plans/ по пути или
15
15
 
16
16
  ## Главные правила
17
17
 
18
- 1. **`docs/rules.md` и `docs/arch.md` обязательны к исполнению.** Перед правками прочитай план, `docs/rules.md` и `docs/arch.md`, если они есть. Выполняй план только в той форме, которая строго следует правилам и архитектуре проекта. Если шаг плана противоречит `docs/rules.md` или `docs/arch.md`, не исполняй его молча и не выбирай обходной путь сам. Остановись и задай `AskUserQuestion`: адаптировать выполнение под правила/архитектуру, вернуться к `eda-plan` для исправления плана или изменить правила/архитектуру отдельной задачей.
19
- 2. **Интерактивные вопросы** — по разделу ниже.
20
- 3. **Не переформулируй план.** Шаг непонятен — спроси, не «доразрабатывай» молча.
21
- 4. **Не коммитить, не пушить, не делать ревью.** Это другие скилы.
22
- 5. **Идти целиком**, не делать паузы «для подтверждения». Останавливайся только если: тест упал, шаг противоречив, есть риск потерять данные, рискованная операция вне плана, шаг плана противоречит `docs/rules.md` или `docs/arch.md`.
23
- 6. **Проверки нельзя подавлять.** Не отключай линтеры, тесты, typecheck, static analysis и другие проверки; не добавляй игноры, исключения из проверок, ослабление правил или изменение команд так, чтобы проверка перестала запускаться. Пиши и правь код так, чтобы проверки проходили по сути.
24
- 7. **Простой язык** в сообщениях пользователю и вопросах. Термины — только если без них нельзя, и сразу с пояснением.
25
- 8. **Таблицы для структурируемых данных** в журнале. Диаграммы — только если действительно есть что показать.
18
+ 1. **План, `docs/rules.md` и `docs/arch.md` — обязательная рамка исполнения.** Перед правками прочитай план, `docs/rules.md` и `docs/arch.md`, если они есть. `docs/rules.md` и `docs/arch.md` обязательны к исполнению, а не просто к прочтению. Выполняй план только в той форме, которая строго следует правилам и архитектуре проекта.
19
+ 2. **Конфликт блокирует выполнение.** Если шаг плана противоречит коду, `docs/rules.md` или `docs/arch.md`, не исполняй его молча и не выбирай обходной путь сам. Спроси: адаптировать выполнение под правила/архитектуру, вернуться к `eda-plan` для исправления плана или изменить правила/архитектуру отдельной задачей.
20
+ 3. **Не додумывай план.** Шаг непонятен — спроси через `AskUserQuestion`, не «доразрабатывай» молча.
21
+ 4. **Иди целиком.** Не делай паузы «для подтверждения» после каждого шага; останавливайся только при конфликте, падении проверки, риске потери данных или рискованной операции вне плана.
22
+ 5. **Проверки нельзя подавлять.** Не отключай линтеры, тесты, typecheck, static analysis и другие проверки; не добавляй игноры, исключения из проверок, ослабление правил или изменение команд так, чтобы проверка перестала запускаться. Пиши и правь код так, чтобы проверки проходили по сути.
23
+ 6. **Не коммить, не пушь, не делай ревью.** Это другие скилы.
24
+ 7. **Пиши просто.** В сообщениях, вопросах и журнале используй простой язык; таблицы — для структурированных данных.
26
25
 
27
26
  ## Интерактивные вопросы
28
27
 
@@ -73,9 +72,9 @@ cd ../<repo-name>-<slug>
73
72
  И **выйди из скила** — текущая сессия в эту папку не переедет, поэтому продолжать здесь нельзя. Сообщи пользователю, что ждёшь его в новой сессии.
74
73
 
75
74
  ### 3. Прочитать контекст
76
- План + `docs/rules.md` и `docs/arch.md` (если есть). `docs/rules.md` и `docs/arch.md` обязательны к исполнению, а не просто к прочтению. Выполняй план только в той форме, которая строго следует правилам и архитектуре проекта. Тест-фреймворк проекта определи сам по конфигам/существующим тестам.
75
+ Прочитай план, `docs/rules.md` и `docs/arch.md` (если есть). Тест-фреймворк проекта определи сам по конфигам и существующим тестам.
77
76
 
78
- Перед выполнением проверь, нет ли в плане шагов, зависимостей, API, миграций, границ модулей, команд проверки или решений, которые противоречат `docs/rules.md` или `docs/arch.md`. Если конфликт есть — остановись и задай `AskUserQuestion`: адаптировать выполнение под правила/архитектуру, вернуться к `eda-plan` для исправления плана или изменить правила/архитектуру отдельной задачей.
77
+ Перед выполнением проверь, нет ли в плане шагов, зависимостей, API, миграций, границ модулей, команд проверки или решений, которые противоречат правилам или архитектуре. Если конфликт есть — остановись и задай `AskUserQuestion` по варианту из главных правил.
79
78
 
80
79
  ### 4. Инициализировать прогресс
81
80
  - Создай журнал `docs/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же, что у плана, или близкий).
@@ -115,7 +114,7 @@ cd ../<repo-name>-<slug>
115
114
  5. Выполни проверки, если они прямо указаны в шаге.
116
115
  6. Поставь `[x]` в файле плана и допиши строку в таблицу журнала.
117
116
 
118
- Останавливайся и спрашивай через `AskUserQuestion`, если: тесты к шагу упали и не правятся быстро / шаг противоречит коду / шаг противоречит `docs/rules.md` или `docs/arch.md` / задевает рискованное вне плана. Архитектурное решение по ходу — записывай в «Изменения в docs», но не меняй зафиксированную архитектуру молча.
117
+ Останавливайся и спрашивай через `AskUserQuestion`, если тесты к шагу упали и не правятся быстро, шаг противоречит коду, `docs/rules.md` или `docs/arch.md`, либо задевает рискованное вне плана. Архитектурное решение по ходу — записывай в «Изменения в docs», но не меняй зафиксированную архитектуру молча.
119
118
 
120
119
  После последнего шага — `finished` и `status: done` в шапке журнала.
121
120
 
package/skills/eda-explore.md CHANGED
@@ -7,14 +7,18 @@ description: 'Исследует тему или задачу до конкре
7
7
 
8
8
  Проводишь исследование так, чтобы на выходе была не подборка рассуждений, а конкретная рамка для следующего шага: что за проблема, как устроена релевантная архитектура, какие решения приняты, какие риски учтены в этих решениях и какой вариант решения выбран.
9
9
 
10
- ## Режимы вызова
10
+ ## Режим запуска
11
11
 
12
- | Режим | Запуск | Что делает |
12
+ Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
13
+
14
+ Дефолты: `defaults.strict: false`, `defaults.decision_mode: recommend_and_ask`.
15
+
16
+ | Настройка | Значения | Аргументы в сообщении |
13
17
  |---|---|---|
14
- | Обычный | `eda-explore <тема>` | Исследование + вопросы + конкретный итоговый отчёт. |
15
- | Строгий | `eda-explore strict <тема>` | Обычный режим + кросс-ревью соседним агентом + допил отчёта. |
18
+ | `defaults.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
19
+ | `defaults.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
16
20
 
17
- Если в `docs/settings.yaml` указано `defaults.strict: true`, строгий режим включён по умолчанию. Явное указание пользователя в текущем сообщении важнее настройки: `strict` включает строгий режим, `normal` / `без strict` / `без строгого режима` выключает его для текущего запуска.
21
+ Если значение из настроек отсутствует или неизвестно, используй дефолт. `strict` добавляет кросс-ревью соседним агентом; обычный режим сохраняет отчёт без кросс-ревью.
18
22
 
19
23
  ## Вход из сообщения пользователя
20
24
 
@@ -22,43 +26,21 @@ description: 'Исследует тему или задачу до конкре
22
26
 
23
27
  Если входа достаточно, не спрашивай подтверждение самой темы. `AskUserQuestion` на этом этапе задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск исследовать не то. Это не отменяет обязательные вопросы по исследовательским развилкам ниже. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
24
28
 
25
- ## Настройки проекта
26
-
27
- Перед выбором режима прочитай `docs/settings.yaml`, если файл есть.
28
-
29
- Если файла нет — используй значение по умолчанию:
30
- - `defaults.strict: false`
31
- - `defaults.decision_mode: recommend_and_ask`
32
-
33
- Прямое указание пользователя в текущем сообщении важнее `docs/settings.yaml`.
29
+ ## Вопросы и решения
34
30
 
35
- Поддерживаемые режимы принятия решений:
31
+ `decision_mode`: `autonomous` — выбирай сам и записывай причину; `recommend_and_ask` — собирай факты, рекомендуй вариант; агент спрашивает пользователя по каждой значимой развилке исследования; `ask_each_time` — спрашивай по каждой развилке, которая влияет на направление исследования или итоговый выбор.
36
32
 
37
- | Ключ | Значения | Что значит |
38
- |---|---|---|
39
- | `defaults.decision_mode` | `autonomous` | Агент сам выбирает по коду, правилам, архитектуре, источникам и рискам, затем записывает причину. |
40
- | `defaults.decision_mode` | `recommend_and_ask` | Дефолт. Агент сам собирает факты, рекомендует вариант и спрашивает пользователя по каждой значимой развилке исследования до финализации. |
41
- | `defaults.decision_mode` | `ask_each_time` | Агент спрашивает по каждой развилке, которая влияет на направление исследования или итоговый выбор, даже если есть сильная рекомендация. |
42
-
43
- Если `defaults.decision_mode` отсутствует или неизвестен, считай его `recommend_and_ask`.
33
+ Значимая исследовательская развилка — это выбор, который меняет итоговую рекомендацию, границы задачи, архитектуру, зависимости, стоимость, безопасность, эксплуатацию, совместимость или будущую миграцию. Не спрашивай о фактах, которые можно выяснить через код, документы или источники.
44
34
 
45
- Значимая исследовательская развилка — это выбор, который меняет направление исследования, итоговую рекомендацию, границы задачи, архитектуру, зависимости, стоимость, безопасность, эксплуатацию, совместимость или будущую миграцию проекта. Не спрашивай о фактах, которые можно выяснить через код, документы или источники; спрашивай о выборе, предпочтении или компромиссе.
35
+ Всегда значимые развилки: новые зависимости и сервисы; БД/ORM/очереди/кэш/storage/search/background jobs; миграции и формат хранения; auth/permissions/payments/secrets/персональные данные; cloud/provider/cost/lock-in/SLA; архитектурные паттерны и публичные контракты; продуктовые компромиссы скорости, качества, UX, стоимости, срока или объёма; выбор, который влияет на то, какой результат будет передан в `eda-plan`.
46
36
 
47
- Всегда считай значимыми:
48
- - выбор нового пакета, библиотеки, фреймворка, SDK, CLI или сервиса;
49
- - выбор базы данных, ORM/query builder, очереди, кэша, storage, search, background jobs;
50
- - миграции данных, изменение схемы, формат хранения или стратегия совместимости;
51
- - auth, permissions, payments, crypto, secrets, персональные данные и другие security-sensitive решения;
52
- - cloud/provider choices, managed services, лицензии, cost/lock-in и SLA;
53
- - архитектурные паттерны, затрагивающие несколько модулей или публичные контракты.
54
- - продуктовый компромисс между скоростью, качеством, UX, стоимостью, сроком или объёмом;
55
- - выбор, который влияет на то, какой результат будет передан в `eda-plan`.
37
+ Не начинай с вопросов, если можно сначала быстро собрать факты. После первичного контекста сгруппируй близкие развилки в пакет из 1–3 вопросов. Если выбрать нельзя без пользовательского решения, задай `AskUserQuestion` и не продолжай финализацию.
56
38
 
57
39
  ## Главные правила
58
40
 
59
41
  1. **Никаких правок кода.** Запись только в `docs/researches/`.
60
42
  2. **Итог — конкретика.** Нельзя заканчивать абстрактными описаниями, списком возможностей или «можно выбрать один из вариантов».
61
- 3. **Развилки закрывай по `decision_mode`.** В `recommend_and_ask` значимые развилки исследования подтверждай у пользователя до финализации: сначала собери факты, затем дай рекомендацию и варианты. В `ask_each_time` спрашивай ещё чаще: по каждой развилке, которая влияет на ход исследования или итоговый выбор. В `autonomous` выбирай сам, если выбор можно обосновать кодом, правилами, архитектурой, источниками и рисками. Мелкие локальные решения, которые не меняют смысл исследования и легко обратимы, выбирай сам и не создавай шум.
43
+ 3. **Развилки закрывай по `decision_mode`.** Значимые развилки подтверждай до финализации, мелкие локальные решения выбирай сам и не создавай шум.
62
44
  4. **Риски вплетай в исследование.** Не создавай отдельный обязательный раздел или этап рисков. Если риск влияет на выбор, источник, ограничение или будущую проверку, фиксируй его рядом с соответствующим решением: что может пойти не так и как это учитывается — снимаем, принимаем или выносим за рамки.
63
45
  5. **Версии проверяй.** Если речь о пакетах, библиотеках, CLI, сервисах или другом ПО, а версия не задана контекстом, проверь последнюю стабильную версию через context7, если он доступен, или через web search по официальным источникам.
64
46
  6. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и используй их как рамку.
@@ -98,23 +80,9 @@ description: 'Исследует тему или задачу до конкре
98
80
 
99
81
  ### 3. Закрыть развилки
100
82
 
101
- Собери все значимые развилки: архитектурные, продуктовые, технические, миграционные, по зависимостям и совместимости.
102
-
103
- Не начинай с вопросов, если можно сначала быстро собрать факты. После первичного контекста сгруппируй близкие развилки в пакет из 1–3 вопросов, чтобы пользователь принимал решения осознанно, а диалог не распадался на мелочи.
104
-
105
- Для каждой развилки:
106
- - перечисли варианты;
107
- - выбери один вариант или подготовь рекомендацию;
108
- - запиши источник и причину выбора;
109
- - если у варианта есть важный риск, опиши его здесь же и сразу зафиксируй, как он влияет на выбранное решение;
110
- - если развилка значимая и `decision_mode: recommend_and_ask` — задай `AskUserQuestion`: 2–3 варианта, первым рекомендованный, короткая причина рекомендации, вариант «свой вариант», фраза «Я продолжу только после ответа.»;
111
- - если развилка влияет на ход исследования или итоговый выбор и `decision_mode: ask_each_time` — задай `AskUserQuestion` даже при сильной рекомендации;
112
- - если `decision_mode: autonomous` и выбор можно обосновать кодом, правилами, архитектурой, источниками и рисками — выбери сам и запиши почему;
113
- - если выбрать нельзя без пользовательского решения — задай `AskUserQuestion` и не продолжай финализацию.
114
-
115
- Не прячь значимый выбор внутри текста. Например, если нужен пакет для базы данных, сначала сравни 2–3 подходящих варианта, затем в `recommend_and_ask` спроси подтверждение выбора пакета/БД до записи финального решения.
83
+ Собери значимые развилки: архитектурные, продуктовые, технические, миграционные, по зависимостям и совместимости. Для каждой дай варианты, выбранный вариант или рекомендацию, источник, причину и важные риски рядом с решением.
116
84
 
117
- Если по ходу исследования находится высокий риск без понятного решения, это блокер: задай `AskUserQuestion` или заверши со статусом `blocked`. Не выноси риски в отдельную секцию ради формы; они должны естественно лежать в `Решении`, причинах выбора, ограничениях, проверках версий или итоговом выводе.
85
+ Не прячь значимый выбор внутри текста: если нужен пакет, БД или другой ключевой компонент, сначала сравни 2–3 подходящих варианта, затем закрой выбор по `decision_mode`. Если появляется высокий риск без понятного решения, это блокер: задай `AskUserQuestion` или заверши со статусом `blocked`. Не выноси риски в отдельную секцию ради формы; они должны лежать в `Решении`, причинах выбора, ограничениях, проверках версий или итоговом выводе.
118
86
 
119
87
  ### 4. Собрать отчёт
120
88
 
package/skills/eda-fix-by-review.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: eda-fix-by-review
3
- description: 'Применяет замечания из ревью (`docs/reviews/...`) или из текста рядом с вызовом к коду. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно; «не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью (это `eda-review`), не коммитит (это `eda-commit`). Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
3
+ description: 'Применяет замечания из ревью (`docs/reviews/...`) или из текста рядом с вызовом к коду. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно, кроме явного режима `apply-optional`, где применяет их без вопроса. «Не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью и не коммитит.'
4
4
  ---
5
5
 
6
6
  # Скил: Исправитель по ревью (eda-fix-by-review)
@@ -13,16 +13,19 @@ description: 'Применяет замечания из ревью (`docs/revie
13
13
 
14
14
  Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
15
15
 
16
+ ## Режим запуска
17
+
18
+ Обычный режим: «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
19
+
20
+ Режим `apply-optional`: применяешь «Править обязательно» и «На усмотрение автора» без вопроса. Этот режим нужен для `eda-polish`, где пользователь заранее разрешил автоматическую доводку по optional-замечаниям. Пункты «Не править» всё равно пропускаешь.
21
+
16
22
  ## Главные правила
17
23
 
18
24
  1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Это рамка проекта. Один раз в начале.
19
25
  2. **Интерактивные вопросы** — по разделу ниже.
20
26
  3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
21
27
  4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
22
- 5. **Логика по группам ревью:**
23
- - «Править обязательно» — правишь сразу, без вопросов.
24
- - «На усмотрение автора» — спроси через `AskUserQuestion` (объединяй до 4 пунктов за раунд: применить / пропустить / переформулировать).
25
- - «Не править» — пропускаешь молча, в отчёте отметь как «осознанно не применено».
28
+ 5. **Логика по группам ревью:** «Править обязательно» — правишь сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`; «Не править» — пропускаешь и отмечаешь в отчёте.
26
29
  6. **Тесты — внутри той же правки.** Замечание касается поведения → правка кода + тесты к ней в одном шаге, точечно прогнал.
27
30
  7. **Финальный полный прогон тестов и линтеров — обязателен.** В конце, не на каждой правке.
28
31
  8. **Простой язык** в формулировках и сообщениях. **Таблицы** для отчёта о фиксах.
@@ -34,17 +37,12 @@ description: 'Применяет замечания из ревью (`docs/revie
34
37
  - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
35
38
  - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
36
39
  - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
37
- - Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора», не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
40
+ - Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
38
41
 
39
42
  ## Этапы
40
43
 
41
44
  ### 1. Выбрать ревью
42
- Сначала разбери текст рядом с вызовом:
43
- - если указан путь к ревью — используй его как `$REVIEW_FILE`;
44
- - если указано название ревью или часть названия — найди совпадение в `docs/reviews/`;
45
- - если написано «последнее ревью» — возьми самый новый файл из `docs/reviews/`;
46
- - если указаны номера замечаний — применяй только эти пункты, сохрани фильтр в отчёте;
47
- - если сами замечания вставлены в сообщение — используй режим `$REVIEW_SOURCE=review_text`, не выбирай файл ревью и сохрани отчёт с `review: text`.
45
+ Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», номера замечаний или вставленный текст замечаний. Если замечания вставлены в сообщение — используй режим `$REVIEW_SOURCE=review_text`, не выбирай файл ревью и сохрани отчёт с `review: text`.
48
46
 
49
47
  Если найдено ровно одно ревью — используй режим `$REVIEW_SOURCE=review_file` и продолжай без вопроса. Если замечания даны текстом — используй режим `$REVIEW_SOURCE=review_text` и продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста и вход не содержит замечания — остановись с понятным вопросом или статусом `blocked: нужно ревью`.
50
48
 
@@ -58,7 +56,7 @@ description: 'Применяет замечания из ревью (`docs/revie
58
56
  ### 3. Применить замечания
59
57
  Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
60
58
  - **Править обязательно** → правишь сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
61
- - **На усмотрение автора** → собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя.
59
+ - **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` применяй сразу без вопроса.
62
60
  - **Не править** → пропусти.
63
61
 
64
62
  Останавливайся и спрашивай, если: замечание непонятно / противоречит коду / задевает рискованное вне ревью (удаление, миграции, секреты).
@@ -107,7 +105,7 @@ status: done
107
105
  ## Чего НЕ делать
108
106
  - Делать само ревью — это `eda-review`.
109
107
  - Коммитить, пушить — это `eda-commit`.
110
- - Применять «на усмотрение» молча — только через `AskUserQuestion`.
108
+ - Применять «на усмотрение» молча без явного режима `apply-optional`.
111
109
  - Игнорировать «не править» и пробовать «на всякий случай» — это нарушает решение ревью.
112
110
  - Гонять полный сьют и линтеры на каждой правке — только в конце.
113
111
  - Пропускать финальную проверку.