@gian-tiaga/eda 0.8.0 → 0.8.3

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 (7) hide show
  1. package/README.md +14 -9
  2. package/package.json +2 -2
  3. package/skills/eda-fix-by-review.md +15 -9
  4. package/skills/eda-manual-test.md +135 -0
  5. package/skills/eda-plan-polish.md +173 -0
  6. package/skills/eda-polish.md +3 -3
  7. package/skills/eda-start.md +13 -6
package/README.md CHANGED
@@ -3,7 +3,7 @@
3
3
  > Поточная разработка с AI-агентами — на русском языке.
4
4
  > Набор готовых скилов для **Claude Code** и **Codex CLI**, которые ведут тебя через весь цикл: от исследования до коммита.
5
5
 
6
- `eda` — это шестнадцать скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
6
+ `eda` — это восемнадцать скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
7
7
 
8
8
  ---
9
9
 
@@ -35,16 +35,18 @@ eda update-all ~/Code
35
35
 
36
36
  | Скил | Что делает | Куда складывает |
37
37
  |---|---|---|
38
- | `eda-start` | Помогает стартовать новый проект: собирает требования, вместе с пользователем выбирает стек, архитектуру, инструменты качества кода, AI-скилы, агентные инструкции, MCP-серверы и правила проекта. Не пишет код и не ставит зависимости; сохраняет согласованные стартовые решения и по подтверждению создаёт черновики правил/архитектуры/AGENTS | `docs/project-starts/`, опционально `docs/rules.md`, `docs/arch.md`, `AGENTS.md` |
38
+ | `eda-start` | Помогает стартовать новый проект: собирает требования, вместе с пользователем выбирает стек, архитектуру, инструменты качества кода, AI-скилы, агентные инструкции, MCP-серверы и правила проекта. Для выбранных пакетов всегда ищет последние стабильные версии по официальным источникам. Не пишет код и не ставит зависимости; сохраняет согласованные стартовые решения и по подтверждению создаёт черновики правил/архитектуры/AGENTS | `docs/project-starts/`, опционально `docs/rules.md`, `docs/arch.md`, `AGENTS.md` |
39
39
  | `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/roadmaps/` |
40
40
  | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. В дефолтном режиме ведёт исследование как диалог: факты собирает сам, а значимые развилки выносит тебе с рекомендацией. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
41
41
  | `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. `docs/rules.md` и `docs/arch.md` использует как обязательную рамку, а не справочный контекст: план должен строго следовать правилам и архитектуре. В плане явно фиксирует контракты БД/API, если задача их затрагивает. Затем три параллельных субагента/модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
42
+ | `eda-plan-polish` | Полирует уже готовый план до оценки 95/100 или заданного порога. Каждая итерация сразу запускает три изолированных параллельных агента на быстрой, кодовой и флагманской моделях. Все агенты получают один общий промпт и проверяют весь план целиком. Основной агент после их ответов выставляет оценку, анализирует предложения, правит только файл плана при оценке ниже порога и не запускает проверки проекта | `docs/plans/` |
42
43
  | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Перед правками читает план, `docs/rules.md` и `docs/arch.md`; правила и архитектура обязательны к исполнению. Если шаг плана им противоречит, останавливается и спрашивает. Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
43
44
  | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
44
45
  | `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ, но в файл пишет только проблемы: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Если запущен без аргументов, ревьюит незакоммиченный `git diff HEAD` без проверки плана. Не перечисляет выполненную работу. В обычном режиме после черновика передаёт файл в `eda-review-check`; с флагом `draft` сохраняет только первичное ревью без субагентов | `docs/reviews/` |
45
46
  | `eda-review-check` | Проверяет готовое ревью из `docs/reviews/` специализированными субагентами: архитектуру, правила, выполнение плана при указанном plan-файле и при включённой настройке качество кода. В строгом режиме добавляет кросс-ревью между Claude и Codex. Сам применяет подтверждённые замечания к файлу ревью, но не правит код | `docs/reviews/` |
46
- | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
47
- | `eda-polish` | Оркестрирует доводку изменений: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional` и повторяет цикл до оценки 95/100 или лимита 5 итераций. Каждый шаг идёт в изолированном субагенте или отдельном CLI-процессе. Не коммитит | `docs/reviews/`, `docs/review-fixes/` |
47
+ | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — все сразу. Optional-пункты в обычном режиме спрашивает, а в `apply-optional` сам решает: применяет полезные, отклонённые обосновывает в отчёте. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
48
+ | `eda-manual-test` | Делает ручную smoke/acceptance-проверку после изменений: API прогоняет через `curl`/HTTP-запросы, фронт — через Playwright или доступную browser automation. Сам строит чеклист из входа, плана или diff, запускает очевидные dev/API-серверы и сохраняет QA-отчёт. Не правит код, не пишет автотесты и не коммитит | `docs/manual-tests/` |
49
+ | `eda-polish` | Оркестрирует доводку изменений: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional` и повторяет цикл до оценки 95/100 или лимита 5 итераций. Обязательные замечания чинятся все, optional-пункты fix-агент применяет или отклоняет сам с обоснованием. Каждый шаг идёт в изолированном субагенте или отдельном CLI-процессе. Не коммитит | `docs/reviews/`, `docs/review-fixes/` |
48
50
  | `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
49
51
  | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
50
52
  | `eda-worktree` | Создаёт git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базу берёт из аргумента или спрашивает | соседняя папка `{name}-work-{n}` |
@@ -67,7 +69,7 @@ eda update-all ~/Code
67
69
  | `eda-review` | `draft` | Сохраняет первичное ревью со статусом `draft` и не запускает `eda-review-check`, субагентов и кросс-CLI | Когда ревью нужно как черновик для внешней оркестрации, например `eda-polish` |
68
70
  | `eda-review` | `strict` | После draft-ревью запускает `eda-review-check strict`: специализированные субагенты плюс соседний CLI; доправляет ревью по подтверждённым замечаниям | Ревью важных PR; когда нужен максимальный охват |
69
71
  | `eda-review-check` | `strict` | Проверяет уже готовое ревью специализированными субагентами и затем отдаёт его соседнему CLI на дополнительный круг проверки | Когда черновик ревью уже есть и нужно усилить только проверку ревью |
70
- | `eda-fix-by-review` | `apply-optional` | Применяет не только обязательные, но и пункты «на усмотрение автора» без дополнительного вопроса | Для заранее согласованной автоматической доводки, прежде всего внутри `eda-polish` |
72
+ | `eda-fix-by-review` | `apply-optional` | Применяет все обязательные пункты, а пункты «на усмотрение автора» разбирает без вопроса: применяет выбранные и отклоняет нецелесообразные с причиной | Для автономной доводки, прежде всего внутри `eda-polish` |
71
73
 
72
74
  ---
73
75
 
@@ -127,10 +129,10 @@ review:
127
129
  start ─────────────> docs ───────────────┬───────────────┐
128
130
  │ │ │
129
131
  v v v
130
- roadmap ────────> explore ─────> plan ───> execute ───┬──> review ───> review-check ───> fix-by-review ───┬──> send-review
132
+ roadmap ────────> explore ─────> plan ───> plan-polish ───> execute ───┬──> manual-test ───> review ───> review-check ───> fix-by-review ───┬──> send-review
131
133
  │ │ │
132
134
  └────────────> plan v └──> commit
133
- fix ─────────────> review
135
+ fix ─────────────> manual-test
134
136
  ```
135
137
 
136
138
  Если проект уже существует, можно начинать без `eda-start`:
@@ -139,16 +141,19 @@ start ─────────────> docs ─────────
139
141
  docs ───────────────┬───────────────┐
140
142
  │ │
141
143
  v v
142
- roadmap ────────> explore ─────> plan ───> execute ───┬──> review ───> review-check ───> fix-by-review ───┬──> send-review
144
+ roadmap ────────> explore ─────> plan ───> plan-polish ───> execute ───┬──> manual-test ───> review ───> review-check ───> fix-by-review ───┬──> send-review
143
145
  │ │ │
144
146
  └──────────────> plan v └──> commit
145
- fix ─────────────> review
147
+ fix ─────────────> manual-test
146
148
 
147
149
  polish = review draft ─> review-check ─> fix-by-review apply-optional ─> повтор до нужной оценки
150
+ plan-polish = 3 полных ревью плана разными моделями ─> оценка ─> правка плана ─> повтор до 95/100
148
151
 
149
152
  automate может запускаться от review, fix-by-review или fix.
150
153
  ```
151
154
 
155
+ `eda-manual-test` обычно ставится после `eda-execute`, `eda-fix` или `eda-fix-by-review`, чтобы руками проверить API/UI перед ревью или коммитом.
156
+
152
157
  Использовать всю цепочку не обязательно — каждый скил самодостаточен. Новый проект можно начать с `eda-start`; существующий — с `eda-roadmap`, `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны. Для параллельной работы есть `eda-worktree`, а для возврата ветки из worktree в текущую ветку — `eda-merge-worktree`.
153
158
 
154
159
  ---
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@gian-tiaga/eda",
3
- "version": "0.8.0",
4
- "description": "Набор скилов eda-* для Claude Code и Codex CLI: start, roadmap, explore, plan, execute, fix, review, review-check, fix-by-review, polish, send-review, commit, worktree, merge-worktree, docs, automate",
3
+ "version": "0.8.3",
4
+ "description": "Набор скилов eda-* для Claude Code и Codex CLI: start, roadmap, explore, plan, plan-polish, execute, fix, review, review-check, fix-by-review, manual-test, polish, send-review, commit, worktree, merge-worktree, docs, automate",
5
5
  "type": "module",
6
6
  "bin": {
7
7
  "eda": "bin/cli.js"
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` и строго следует им. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно, кроме явного режима `apply-optional`, где применяет их без вопроса. «Не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью и не коммитит.'
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)
@@ -15,9 +15,9 @@ description: 'Применяет замечания из ревью (`docs/revie
15
15
 
16
16
  ## Режим запуска
17
17
 
18
- Обычный режим: «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
18
+ Обычный режим: все пункты «Править обязательно» применяешь сразу, «На усмотрение автора» выносишь через `AskUserQuestion`, «Не править» пропускаешь.
19
19
 
20
- Режим `apply-optional`: применяешь «Править обязательно» и «На усмотрение автора» без вопроса. Этот режим нужен для `eda-polish`, где пользователь заранее разрешил автоматическую доводку по optional-замечаниям. Пункты «Не править» всё равно пропускаешь.
20
+ Режим `apply-optional`: все пункты «Править обязательно» применяешь без исключений. По каждому пункту «На усмотрение автора» сам принимаешь решение без вопроса: применяешь, если правка явно улучшает качество, снижает риск или стоит дёшево; отклоняешь, если польза спорная, правка расширяет scope, создаёт риск регрессии, конфликтует с правилами/архитектурой или требует продуктового решения. Название режима означает «разобрать optional без вопроса», а не «механически применить все optional». Пункты «Не править» всё равно пропускаешь.
21
21
 
22
22
  ## Главные правила
23
23
 
@@ -25,7 +25,7 @@ description: 'Применяет замечания из ревью (`docs/revie
25
25
  2. **Интерактивные вопросы** — по разделу ниже.
26
26
  3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
27
27
  4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
28
- 5. **Логика по группам ревью:** «Править обязательно» — правишь сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`; «Не править» — пропускаешь и отмечаешь в отчёте.
28
+ 5. **Логика по группам ревью:** «Править обязательно» — правишь все сразу; «На усмотрение автора» — спроси через `AskUserQuestion`, кроме режима `apply-optional`, где сам решаешь применить или отклонить; «Не править» — пропускаешь и отмечаешь в отчёте.
29
29
  6. **Тесты — внутри той же правки.** Замечание касается поведения → правка кода + тесты к ней в одном шаге, точечно прогнал.
30
30
  7. **Финальный полный прогон тестов и линтеров — обязателен.** В конце, не на каждой правке.
31
31
  8. **Простой язык** в формулировках и сообщениях. **Таблицы** для отчёта о фиксах.
@@ -37,7 +37,7 @@ description: 'Применяет замечания из ревью (`docs/revie
37
37
  - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
38
38
  - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
39
39
  - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
40
- - Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
40
+ - Для исправления кода это правило важнее требования довести фиксы до конца: не применяй пункты «на усмотрение автора» без ответа пользователя, кроме явного режима `apply-optional`, где решение принимает сам агент; не переформулируй замечания и не правь чужие/несвязанные поломки вместо ответа пользователя.
41
41
 
42
42
  ## Этапы
43
43
 
@@ -55,8 +55,8 @@ description: 'Применяет замечания из ревью (`docs/revie
55
55
 
56
56
  ### 3. Применить замечания
57
57
  Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
58
- - **Править обязательно** → правишь сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
59
- - **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` применяй сразу без вопроса.
58
+ - **Править обязательно** → правишь все пункты сразу. Если меняешь поведение — добавь точечный тест в этой же правке.
59
+ - **На усмотрение автора** → в обычном режиме собери в один-два раунда `AskUserQuestion`, применяй по решению пользователя; в режиме `apply-optional` сам реши по каждому пункту, применяй только принятые решения без вопроса, а отклонённые фиксируй с причиной.
60
60
  - **Не править** → пропусти.
61
61
 
62
62
  Останавливайся и спрашивай, если: замечание непонятно / противоречит коду / задевает рискованное вне ревью (удаление, миграции, секреты).
@@ -90,22 +90,28 @@ status: done
90
90
  |---|-----------|-------|-------|--------|
91
91
  | 1 | <кратко из ревью> | `path/a.py` | `path/test_a.py` (2 ✓) | ✓ применено |
92
92
  | 2 | ... | ... | — | ✓ применено |
93
- | 3 | ... | — | — | ✗ пропущено (на усмотрение, пользователь отклонил) |
93
+ | 3 | ... | — | — | ✗ отклонено (на усмотрение, причина: <короткое обоснование>) |
94
94
  | 4 | ... | — | — | — не править (по решению ревью) |
95
95
 
96
+ ## Решения по optional
97
+ - **Принято:** <номера и коротко почему>
98
+ - **Отклонено:** <номера и коротко почему, чтобы следующие ревьюеры не повторяли это как открытое замечание>
99
+
96
100
  ## Финальная проверка
97
101
  - **Тесты:** `<команда>` — ✓ / ✗
98
102
  - **Линтер:** `<команда>` — ✓ / ✗
99
103
  - **Заметки:** <если что-то осталось не зелёным — почему>
100
104
  ```
101
105
 
106
+ Если `$REVIEW_SOURCE=review_file` и в режиме `apply-optional` отклонены пункты «На усмотрение автора», в добавляемом в ревью разделе `## Применённые фиксы` после ссылки на отчёт добавь короткий список `Отклонённые optional-решения` с причинами. Это нужно, чтобы следующие ревьюеры видели уже принятое решение и не повторяли тот же optional-пункт без новых аргументов.
107
+
102
108
  ### 6. Финал
103
109
  Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к отчёту о фиксах, сколько применено / пропущено / отклонено, результат финальной проверки, состояние git («не закоммичено»). Подсказка дальше — `eda-commit`.
104
110
 
105
111
  ## Чего НЕ делать
106
112
  - Делать само ревью — это `eda-review`.
107
113
  - Коммитить, пушить — это `eda-commit`.
108
- - Применять «на усмотрение» молча без явного режима `apply-optional`.
114
+ - Применять или отклонять «на усмотрение» молча без явного режима `apply-optional` или ответа пользователя.
109
115
  - Игнорировать «не править» и пробовать «на всякий случай» — это нарушает решение ревью.
110
116
  - Гонять полный сьют и линтеры на каждой правке — только в конце.
111
117
  - Пропускать финальную проверку.
package/skills/eda-manual-test.md ADDED
@@ -0,0 +1,135 @@
1
+ ---
2
+ name: eda-manual-test
3
+ description: 'Делает ручную smoke/acceptance-проверку после изменений: сам строит чеклист из входа пользователя, плана или незакоммиченного diff; для API выполняет curl/HTTP-запросы, для фронта использует Playwright или доступную browser automation. Сам запускает очевидные dev/API-серверы, фиксирует фактическое поведение и сохраняет QA-отчёт в docs/manual-tests/. Не правит код, не пишет автотесты, не ставит зависимости, не коммитит.'
4
+ ---
5
+
6
+ # Скил: Ручное тестирование (eda-manual-test)
7
+
8
+ Делаешь ручную smoke/acceptance-проверку уже сделанных изменений. Проверяешь не «что тесты зелёные», а что пользовательский или API-сценарий реально работает: страница открывается, действие проходит, endpoint отвечает, ошибки выглядят ожидаемо. Сохраняешь QA-отчёт. Код не правишь.
9
+
10
+ ## Вход из сообщения пользователя
11
+
12
+ Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: URL, endpoint, сценарий, план, ревью, issue, ветку, ограничение по окружению, логин/роль без секретов и прямые указания.
13
+
14
+ Если входа достаточно, продолжай без вопроса. Если входа нет, построй минимальный smoke-чеклист по незакоммиченному `git diff HEAD`, релевантному коду и документации проекта. `AskUserQuestion` задавай только если цель противоречива, найдено несколько равных окружений/URL, нужна авторизация без доступных тестовых данных или есть риск выполнить разрушительное действие. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
15
+
16
+ ## Главные правила
17
+
18
+ 1. **Ручная проверка, не разработка.** Не правь код, не пиши и не обновляй автотесты, не меняй конфиги, не коммить и не пушь.
19
+ 2. **Smoke по умолчанию.** Проверь запуск, основной happy path изменённой области и 1–2 негативных или edge-сценария, которые естественно следуют из задачи.
20
+ 3. **API проверяй запросами.** Используй `curl`, встроенный HTTP-клиент, Node `fetch` или проектные scripts. Фиксируй method, URL, важные headers без секретов, body, status code и ключевые поля ответа.
21
+ 4. **Фронт проверяй браузером.** Если в проекте есть Playwright — используй Playwright. Если Playwright не установлен, используй доступную browser automation хост-агента. Если браузерной автоматизации нет — спроси через `AskUserQuestion`; не устанавливай зависимости молча.
22
+ 5. **Серверы поднимай сам, если это очевидно.** Определи команды по `package.json`, README, docker compose, Makefile или локальным инструкциям. Останавливай только процессы, которые сам запустил.
23
+ 6. **Секреты не трогай.** Используй только уже доступные локальные `.env`, тестовые аккаунты и настройки. Не проси пользователя прислать секреты в чат и не печатай токены, cookies, passwords, API keys или Authorization headers в отчёт.
24
+ 7. **Разрушительное подтверждай.** Реальные платежи, удаление данных, отправку email/SMS/push, изменение production/staging-данных, миграции, очистку БД и похожие действия выполняй только после `AskUserQuestion`.
25
+ 8. **Проверяй фактическое поведение.** Не ограничивайся чтением кода. Если сценарий нельзя выполнить, зафиксируй `blocked` и конкретную причину.
26
+ 9. **Отчёт обязателен.** Сохрани результат в `docs/manual-tests/`, даже если проверка заблокирована или нашла баги.
27
+
28
+ ## Интерактивные вопросы
29
+
30
+ Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
31
+ - Claude Code: используй `AskUserQuestion`.
32
+ - Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
33
+ - Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
34
+ - Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
35
+
36
+ ## Этапы
37
+
38
+ ### 1. Определить цель проверки
39
+ Разбери вход пользователя. Если указан файл плана, ревью, research, issue или другой артефакт — прочитай его. Если входа нет, изучи `git diff HEAD`, изменённые файлы, README и релевантные роуты/страницы/компоненты.
40
+
41
+ Определи `$TEST_TARGET`: `api`, `frontend`, `fullstack` или `other`. Если цель всё ещё неоднозначна и можно проверить не то окружение или не тот сценарий — спроси через `AskUserQuestion`.
42
+
43
+ ### 2. Прочитать рамку проекта
44
+ Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Найди команды запуска, тестовые URL, API-контракты, seed/test users и ограничения окружения в README, package scripts, docker compose, Makefile, OpenAPI/Swagger/Postman-файлах и существующих e2e-тестах.
45
+
46
+ Не устанавливай Playwright, браузеры, пакеты, docker images или системные зависимости молча. Если без этого проверка невозможна — спроси через `AskUserQuestion` или зафиксируй `blocked` в неинтерактивном режиме.
47
+
48
+ ### 3. Составить smoke-чеклист
49
+ Составь короткий чеклист:
50
+ - запуск приложения или API;
51
+ - основной happy path изменённой области;
52
+ - 1–2 негативных или edge-сценария;
53
+ - явные acceptance criteria из плана или входа пользователя;
54
+ - для фронта: console errors, network errors и видимые regressions на основной странице;
55
+ - для API: status code, схема/ключевые поля ответа, обработка неверного ввода или прав доступа, если это относится к задаче.
56
+
57
+ Не расширяй проверку до полного exploratory QA, если пользователь не попросил.
58
+
59
+ ### 4. Запустить окружение
60
+ Если приложение ещё не запущено и команды очевидны, запусти нужные dev/API-серверы. Дождись готовности по логам, healthcheck, открытому порту или успешному запросу. Если порт занят, проверь, подходит ли уже запущенный сервис; если нет — спроси или выбери очевидный альтернативный порт только когда проект это поддерживает.
61
+
62
+ Фиксируй команды запуска в черновике отчёта. Не заверши свой ответ, пока запущенные тобой процессы, нужные только для проверки, ещё работают.
63
+
64
+ ### 5. Проверить API
65
+ Для API-сценариев выполни реальные запросы. Предпочитай воспроизводимые команды `curl`, но можно использовать Node `fetch` или проектный HTTP-клиент, если так безопаснее.
66
+
67
+ Проверяй:
68
+ - успешный status code и ключевые поля ответа;
69
+ - корректную ошибку для неверного ввода, отсутствующих прав или несуществующей сущности, если это относится к задаче;
70
+ - отсутствие явных server errors, stack traces и утечек секретов в ответе.
71
+
72
+ Секретные headers и cookies в отчёт не вставляй: пиши `<redacted>`.
73
+
74
+ ### 6. Проверить фронт
75
+ Для фронтовых сценариев открой страницу в браузере. Если доступен Playwright, используй его для навигации, кликов, ввода и проверок. Если доступен browser plugin или другой инструмент браузерной автоматизации — используй его. Проверяй фактический UI, а не только DOM-текст.
76
+
77
+ Проверяй:
78
+ - страница загружается без критических console/network errors;
79
+ - основной сценарий пользователя проходит до ожидаемого результата;
80
+ - видимые состояния ошибок, пустых данных или невалидного ввода, если они относятся к задаче;
81
+ - текст и элементы управления не ломаются на очевидном desktop/mobile viewport, если менялась вёрстка.
82
+
83
+ Скриншоты сохраняй только если инструмент это поддерживает и они помогают подтвердить результат или баг. Складывай их рядом с отчётом или в подпапку `docs/manual-tests/assets/`.
84
+
85
+ ### 7. Сохранить отчёт
86
+ Сохрани отчёт в `docs/manual-tests/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
87
+
88
+ ```markdown
89
+ ---
90
+ date: <YYYY-MM-DD HH:MM>
91
+ source: <text | git diff HEAD | docs/plans/... | docs/reviews/...>
92
+ target: <api | frontend | fullstack | other>
93
+ status: <passed | failed | blocked>
94
+ ---
95
+
96
+ # Ручная проверка: <краткий заголовок>
97
+
98
+ ## Контекст
99
+ <что проверялось и откуда взяты сценарии>
100
+
101
+ ## Окружение
102
+ | Что | Значение |
103
+ |---|---|
104
+ | Команды запуска | `<command>` |
105
+ | URL / endpoint | `<url или endpoint>` |
106
+ | Авторизация | `<не нужна | тестовый пользователь | уже настроена | blocked>` |
107
+
108
+ ## Чеклист
109
+ | # | Сценарий | Способ проверки | Результат | Заметки |
110
+ |---|----------|-----------------|-----------|---------|
111
+ | 1 | ... | `curl ...` / Playwright / browser | ✓ / ✗ / ? | ... |
112
+
113
+ ## Найденные проблемы
114
+ <если нет — «Явных проблем не найдено»; если есть — список с воспроизведением и фактическим/ожидаемым результатом>
115
+
116
+ ## Артефакты
117
+ <ссылки на скриншоты, логи или «Нет»>
118
+
119
+ ## Итог
120
+ <passed / failed / blocked и короткое объяснение>
121
+ ```
122
+
123
+ Если найден баг, статус отчёта `failed`. Если проверка невозможна из-за окружения, авторизации, отсутствующих зависимостей или непонятного риска, статус `blocked`.
124
+
125
+ ### 8. Финал
126
+ Короткое сообщение: путь к отчёту, итог `passed` / `failed` / `blocked`, какие сценарии реально проверены, какие процессы остановлены, состояние git («не закоммичено»). Если итог `failed` или `blocked` — предложи дальше `eda-fix`. Если итог `passed` — предложи дальше `eda-review` или `eda-commit`.
127
+
128
+ ## Чего НЕ делать
129
+ - Править код, конфиги, миграции, seed-данные или документацию проекта, кроме отчёта в `docs/manual-tests/`.
130
+ - Писать или обновлять unit/e2e/autotests. Это работа `eda-fix`, `eda-execute` или отдельной задачи.
131
+ - Устанавливать Playwright, браузеры, npm-пакеты, docker images или системные зависимости без явного подтверждения.
132
+ - Подменять ручную проверку запуском `npm test` без фактического прохождения API/UI-сценария.
133
+ - Проверять production или staging с изменением данных без подтверждения пользователя.
134
+ - Сохранять секреты, cookies, токены или passwords в отчёт.
135
+ - Коммитить, пушить, создавать PR или отправлять ревью.
package/skills/eda-plan-polish.md ADDED
@@ -0,0 +1,173 @@
1
+ ---
2
+ name: eda-plan-polish
3
+ description: 'Полирует готовый план из `docs/plans/...` до оценки 95/100 или заданного порога. Каждая итерация начинается с трёх изолированных параллельных агентов на быстрой, кодовой и флагманской моделях. Все агенты получают один общий промпт и проверяют весь план целиком. Основной агент читает их результаты, выставляет итоговую оценку, принимает или отклоняет предложения, правит только файл плана, не меняет код и не запускает проверки.'
4
+ ---
5
+
6
+ # Скил: Полировка плана (eda-plan-polish)
7
+
8
+ Берёшь готовый план из `docs/plans/` и доводишь его до состояния, когда его можно передать в `eda-execute`. Порог по умолчанию — `95`, лимит по умолчанию — `5` итераций.
9
+
10
+ Каждая итерация начинается с трёх независимых моделей с одним и тем же промптом. Основной агент не ставит предварительную оценку сам: он оценивает план только после ответов агентов, принимает или отклоняет предложения, правит план при оценке ниже порога и запускает новую итерацию.
11
+
12
+ ## Вход из сообщения пользователя
13
+
14
+ Текст рядом с вызовом скилла — главный вход. Разбери путь к плану, название или часть названия, «последний план», порог, лимит итераций, ограничения и прямые запреты.
15
+
16
+ Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, найдено несколько равных вариантов или есть риск полировать не тот план. Старую историю не считай входом, если пользователь не связал её с текущим вызовом явно.
17
+
18
+ ## Настройки
19
+
20
+ - Порог качества по умолчанию — `95`, можно переопределить словами `до 90`, `threshold 90`, `цель 90`.
21
+ - Лимит по умолчанию — `5` итераций, можно переопределить словами `лимит 3`, `max iterations 3`, `не больше 3 кругов`.
22
+ - Оценка `95–100` означает готовность к исполнению; `80–94` — нужно уточнить; `60–79` — рискованный план; ниже `60` — нужен серьёзный переплан или вопросы пользователю.
23
+
24
+ ## Жёсткие правила
25
+
26
+ 1. Работай только с готовым файлом плана в `docs/plans/`.
27
+ 2. Не правишь код. Менять можно только выбранный файл плана; миграции, конфиги, зависимости и lock-файлы не трогай.
28
+ 3. Не запускай проверки и исполняющие команды: `test`, `lint`, `build`, `typecheck`, `check`, `dev`, `start`, миграции, seed, smoke-тесты, браузерные проверки и API-запросы. При полировке плана можно читать файлы и искать по коду, но нельзя проверять проект выполнением команд.
29
+ 4. Не ставь предварительную оценку без агентов. Сразу запускай три изолированных агента параллельно, одним batch, до чтения любого результата.
30
+ 5. Итоговую оценку 0–100 выставляй только после чтения результатов всех трёх агентов.
31
+ 6. У всех трёх агентов один общий промпт: каждый проверяет весь план целиком, а не отдельную роль.
32
+ 7. Не добавляй неподтверждённые существенные решения: БД/API-контракты, зависимости, архитектурные развилки, auth/permissions/payments/secrets/персональные данные и миграции.
33
+ 8. Сохраняй структуру `eda-plan`: `Целевой алгоритм`, `Контракты реализации`, `Фазы выполнения`, `Тесты`, `Логирование`, если эти разделы есть или должны быть по формату.
34
+ 9. Если качество не растёт два круга подряд, достигнут лимит или нужен ответ пользователя, остановись и честно назови причину.
35
+
36
+ ## Интерактивные вопросы
37
+
38
+ Когда инструкция говорит `AskUserQuestion`, это блокирующий вопрос:
39
+ - Claude Code: используй `AskUserQuestion`.
40
+ - Codex interactive: если доступен `request_user_input`, используй его; иначе задай один короткий вопрос в чат с вариантами 1–3 и остановись до ответа.
41
+ - Codex exec / non-interactive: не читай stdin; если без ответа нельзя безопасно продолжать, заверши со статусом `blocked: нужен ответ пользователя`.
42
+
43
+ ## Процесс
44
+
45
+ ### 1. Выбрать план
46
+
47
+ Определи `$PLAN_FILE`:
48
+ - указан путь — используй его;
49
+ - указано название или часть названия — найди совпадение в `docs/plans/`;
50
+ - сказано «последний план» — возьми самый новый файл из `docs/plans/`;
51
+ - входа нет — спроси, показав несколько последних планов;
52
+ - `docs/plans/` нет или она пуста — остановись: `blocked: нужен готовый план`.
53
+
54
+ Прочитай план целиком. По front matter извлеки `status`, `mode`, `plan_size`, `test_strategy`, `logging_strategy`, `sources.rules`, `sources.arch`, `sources.research`, `meta_reviewers`.
55
+
56
+ Прочитай `docs/rules.md`, `docs/arch.md` и `sources.research`, если они есть. Если план ссылается на конкретные файлы, модули, API, миграции или тесты, открой только нужные файлы для понимания. Не запускай проверки.
57
+
58
+ ### 2. Запустить три модели
59
+
60
+ В каждой итерации, включая первую, запускай в одном batch три изолированных агента:
61
+
62
+ | Уровень | Claude Code (`Agent` tool) | Codex interactive (`spawn_agent`) | Codex exec / non-interactive fallback |
63
+ |---|---|---|---|
64
+ | Быстрая модель | `haiku` | `gpt-5.4-mini` | `gpt-5.4-mini` |
65
+ | Кодовая модель | `sonnet` | `gpt-5.3-codex` | `gpt-5.3-codex` |
66
+ | Флагманская модель | `opus` | `gpt-5.5` | `gpt-5.5` |
67
+
68
+ - Claude Code: используй `Agent` tool с моделями из таблицы.
69
+ - Codex interactive: если доступен `spawn_agent` или аналог, используй субагентов с моделями из таблицы. Не используй отдельные `codex exec`, когда субагенты доступны.
70
+ - Codex exec / non-interactive fallback: если субагентов нет, запусти три `codex exec --model <id>` параллельно одной Bash-командой с `&` и общим `wait`.
71
+ - Если модель недоступна, возьми ближайшую code-capable модель того же уровня. Не заменяй три уровня одной моделью.
72
+
73
+ Общий промпт каждому агенту:
74
+
75
+ ```text
76
+ Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, sources.research при наличии и релевантные файлы, на которые ссылается план.
77
+
78
+ Проверь весь план целиком: исполнимость, соответствие правилам и архитектуре, полноту целевого алгоритма, БД/API/внешние контракты, фазы, тестовые сценарии, логирование, неподтверждённые решения, скрытые риски и места, где eda-execute не сможет продолжить без нового исследования.
79
+
80
+ Не правь файлы и не запускай проверки, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы. Можно только читать файлы.
81
+
82
+ Ответь кратко:
83
+ score: <0–100>
84
+ + Принять: <конкретная правка и куда встроить>
85
+ ~ Уточнить: <что переформулировать>
86
+ -- Убрать: <что неверно, лишнее или противоречит контексту>
87
+ ? Вопрос: <что нельзя безопасно решить без пользователя>
88
+ ```
89
+
90
+ ### 3. Оценить результаты
91
+
92
+ Когда все три агента ответили, прочитай их замечания и оценки. После этого основной агент выставляет итоговый `$SCORE` по шкале 0–100.
93
+
94
+ Оцени:
95
+ - план следует `docs/rules.md` и `docs/arch.md`;
96
+ - нет неподтверждённых существенных решений;
97
+ - `Целевой алгоритм` описывает сквозное поведение;
98
+ - `Контракты реализации` конкретны, особенно БД/API/внешние контракты;
99
+ - фазы имеют цель, шаги, результат, сценарии тестирования и проверку;
100
+ - `test_strategy` и `logging_strategy` отражены в фазах и разделах;
101
+ - нет альтернатив вида «выбрать», «решить», «уточнить позже»;
102
+ - план можно передать в `eda-execute` без нового исследования.
103
+
104
+ Если `$SCORE >= threshold`, не вноси содержательные правки ради формы. Только добавь или обнови:
105
+
106
+ ```markdown
107
+ ## Оценка plan-polish
108
+ - **Итоговая оценка:** <score>/100
109
+ - **Порог:** <threshold>/100
110
+ - **Итерации:** <N>
111
+ - **Модели:** <фактически запущенные модели>
112
+ - **Решение:** план готов к исполнению.
113
+ ```
114
+
115
+ На этом остановись.
116
+
117
+ ### 4. Отредактировать план
118
+
119
+ Если `$SCORE < threshold`, сгруппируй замечания:
120
+ - **Принять** — подтверждено планом, правилами, архитектурой, research или кодом и улучшает исполнимость без новой развилки.
121
+ - **Отклонить** — противоречит контексту, дублирует уже закрытое, расширяет задачу или требует неподтверждённого решения.
122
+ - **Спросить** — полезно, но требует выбора пользователя или меняет подтверждённое решение.
123
+
124
+ Если есть вопросы класса **Спросить**, задай один сгруппированный `AskUserQuestion` и не редактируй план до ответа. Если предложение можно безопасно отклонить как расширение задачи, отклони его и продолжай.
125
+
126
+ Принятые замечания встраивай в основные разделы плана. Журнал в конце держи коротким:
127
+
128
+ ```markdown
129
+ ## Изменения после plan-polish
130
+
131
+ ### Итерация <N>
132
+ - **Оценка после проверки:** <score>/100
133
+ - **Модели:** <фактически запущенные модели>
134
+ - **+ Добавлено:** <3–7 главных изменений>
135
+ - **~ Уточнено:** <1–5 важных уточнений>
136
+ - **− Убрано:** <если удалено>
137
+ - **Отклонено:** <существенные отклонённые предложения и причина>
138
+ - **Вопросы пользователя:** <если были, кратко решение>
139
+ ```
140
+
141
+ В `meta_reviewers`, если поле есть, добавь фактически запущенные модели. Если `status: draft` и открытых вопросов не осталось, поменяй на `status: meta-reviewed`; `meta-reviewed` и `reviewed` не понижай.
142
+
143
+ ### 5. Продолжить или остановиться
144
+
145
+ После правок обнови:
146
+
147
+ ```markdown
148
+ ## Оценка plan-polish
149
+ - **Итоговая оценка:** <score>/100
150
+ - **Порог:** <threshold>/100
151
+ - **Итерации:** <N>
152
+ - **Модели:** <фактически запущенные модели>
153
+ - **Решение:** <готов к исполнению | нужен следующий круг | blocked | достигнут лимит>
154
+ ```
155
+
156
+ Если оценка ниже порога и лимит не достигнут, запускай новую итерацию с тремя агентами. Если оценка не выросла два круга подряд — остановись `blocked: score не растёт`. Если лимит достигнут — остановись и явно скажи, что порог не достигнут.
157
+
158
+ ## Финал
159
+
160
+ Сообщи кратко: путь к плану, итоговую оценку и порог, число итераций, какие модели запускались, главные принятые изменения, существенные отклонения, причину остановки и следующий шаг `eda-execute <PLAN_FILE>` при успехе.
161
+
162
+ ## Чего НЕ делать
163
+
164
+ - Создавать новый план вместо полировки существующего.
165
+ - Править код, миграции, конфиги, lock-файлы или зависимости.
166
+ - Запускать любые проверки проекта, тесты, линтеры, билды, typecheck, dev-серверы, миграции, браузерные проверки или API-запросы.
167
+ - Ставить предварительную оценку без трёх агентных проверок.
168
+ - Запускать агентов последовательно или давать им разные промпты.
169
+ - Запускать все три прохода на одной модели.
170
+ - Вставлять предложения агентов без анализа.
171
+ - Добавлять существенные решения без подтверждения пользователя.
172
+ - Превращать план в длинный отчёт о ревью.
173
+ - Коммитить, пушить или запускать `eda-execute`.
package/skills/eda-polish.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: eda-polish
3
- description: 'Автономно доводит изменения до заданной оценки ревью: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional`, и повторяет цикл до порога качества или лимита итераций. По умолчанию цель — 95/100, лимит — 5 итераций; порог можно переопределить в сообщении (`до 90`, `threshold 90`). Каждый шаг запускается в изолированном субагенте или отдельном CLI-процессе. Не коммитит и не отправляет ревью.'
3
+ description: 'Автономно доводит изменения до заданной оценки ревью: запускает `eda-review draft`, затем `eda-review-check`, затем `eda-fix-by-review apply-optional`, и повторяет цикл до порога качества или лимита итераций. Все обязательные замечания чинятся, optional-замечания fix-агент применяет или отклоняет сам с обоснованием. По умолчанию цель — 95/100, лимит — 5 итераций; порог можно переопределить в сообщении (`до 90`, `threshold 90`). Каждый шаг запускается в изолированном субагенте или отдельном CLI-процессе. Не коммитит и не отправляет ревью.'
4
4
  ---
5
5
 
6
6
  # Скил: Доводка по ревью (eda-polish)
@@ -27,7 +27,7 @@ description: 'Автономно доводит изменения до зада
27
27
  2. **Не коммитишь и не отправляешь ревью.** Это работа `eda-commit` и `eda-send-review`.
28
28
  3. **Не обходишь границы скилов.** Ревью делает `eda-review draft`, проверку ревью делает `eda-review-check`, правки делает `eda-fix-by-review apply-optional`.
29
29
  4. **Цель цикла — score из проверенного ревью.** Сравнивай порог только с ревью после `eda-review-check`, не с draft.
30
- 5. **Optional-замечания применяются автоматически.** Для шага фиксов всегда передавай `apply-optional`, чтобы `eda-fix-by-review` применил пункты «на усмотрение автора» без вопроса.
30
+ 5. **Обязательные замечания исправляются все.** Для шага фиксов всегда передавай `apply-optional`, чтобы `eda-fix-by-review` не спрашивал пользователя в цикле: все пункты «править обязательно» он обязан исправить, а по пунктам «на усмотрение автора» сам решает, применить или отклонить с причиной.
31
31
  6. **Останавливайся на блокерах.** Если любой субагент завершился `blocked`, проверки не проходят из-за нерешённой причины, нет применимых замечаний или score не растёт два круга подряд — останови цикл и объясни причину.
32
32
  7. **Не скрывай неудачную сходимость.** Если лимит достигнут, финал должен прямо сказать, какая оценка получилась и какие ревью/фиксы были последними.
33
33
 
@@ -81,7 +81,7 @@ description: 'Автономно доводит изменения до зада
81
81
  6. Запусти изолированный шаг:
82
82
 
83
83
  ```text
84
- Используй скилл eda-fix-by-review apply-optional. Примени замечания из ревью: <REVIEW_FILE>. Применяй пункты «править обязательно» и «на усмотрение автора». Сохрани отчёт в docs/review-fixes/ и верни путь к отчёту, результат финальных проверок и состояние git.
84
+ Используй скилл eda-fix-by-review apply-optional. Разбери замечания из ревью: <REVIEW_FILE>. Все пункты «править обязательно» исправь. По каждому пункту «на усмотрение автора» сам реши, применять ли его; отклонённые optional-пункты запиши с причиной в отчёт и ссылку в ревью, чтобы следующие ревьюеры не повторяли их без новых аргументов. Сохрани отчёт в docs/review-fixes/ и верни путь к отчёту, результат финальных проверок и состояние git.
85
85
  ```
86
86
 
87
87
  7. Если фикс завершился `blocked`, с ошибкой проверок или без применённых правок — останови цикл и покажи причину.
package/skills/eda-start.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: eda-start
3
- description: 'Помогает стартовать новый проект: собирает требования, критерии MVP, ограничения и риски; вместе с пользователем выбирает стек, архитектуру, инструменты качества кода, AI-скилы, агентные инструкции, MCP-серверы и правила проекта. Для библиотек, CLI, сервисов и MCP проверяет актуальные стабильные версии по официальным источникам, если они не заданы. Не пишет код и не устанавливает зависимости: сохраняет согласованный стартовый документ в docs/project-starts/ и черновики docs/rules.md / docs/arch.md / AGENTS.md, если пользователь это подтвердил.'
3
+ description: 'Помогает стартовать новый проект: собирает требования, критерии MVP, ограничения и риски; вместе с пользователем выбирает стек, архитектуру, инструменты качества кода, AI-скилы, агентные инструкции, MCP-серверы и правила проекта. Для пакетов всегда ищет последние стабильные версии по официальным источникам; для библиотек, CLI, сервисов и MCP проверяет актуальные стабильные версии, если они не заданы. Не пишет код и не устанавливает зависимости: сохраняет согласованный стартовый документ в docs/project-starts/ и черновики docs/rules.md / docs/arch.md / AGENTS.md, если пользователь это подтвердил.'
4
4
  ---
5
5
 
6
6
  # Скил: Старт проекта (eda-start)
@@ -21,10 +21,11 @@ description: 'Помогает стартовать новый проект: с
21
21
  4. **Стек подбирается под задачу.** Не навязывай любимые технологии. Для каждого ключевого выбора дай 2–3 реалистичных варианта, рекомендацию и причину.
22
22
  5. **Инструменты качества обязательны для выбранного стека.** Подбери форматтер, линтер, статанализатор/typecheck, тестовый стек, coverage, dependency/security audit, pre-commit и CI-проверки, если они есть и уместны в выбранной экосистеме.
23
23
  6. **MCP и скилы — только по делу.** Рекомендуй MCP-сервер или скил, когда он закрывает реальную нехватку контекста, интеграцию, повторяемый процесс или качество агентной работы.
24
- 7. **Версии проверяй.** Если предлагаешь пакеты, CLI, фреймворки, сервисы или MCP-серверы, а версия не зафиксирована пользователем, проверь актуальную стабильную версию через context7, если он доступен, или через web search по официальным источникам.
25
- 8. **Архитектура должна быть объяснима.** Выбранная архитектура обязана соответствовать масштабу MVP, рискам, команде и будущему росту. Не предлагай сложность без причины.
26
- 9. **Правила должны быть применимы.** Каждое правило должно отвечать на конкретный риск проекта и иметь понятную проверку: автоматическую, ревью-проверку или договорённость в `docs/rules.md`.
27
- 10. **Простой язык. Таблицы** используй для сравнений стека, инструментов, MCP, скилов, правил и архитектурных вариантов.
24
+ 7. **Версии пакетов проверяй всегда.** Если предлагаешь npm/pip/gem/cargo/go/composer-пакет или пакет из другой экосистемы, найди последнюю стабильную версию через context7, если он доступен, или через web search по официальной документации, registry, release notes или репозиторию проекта. Не пиши `latest` без конкретной версии и источника. Если пользователь явно зафиксировал другую версию, не меняй её молча: покажи текущую стабильную, зафиксированную пользователем и причину расхождения.
25
+ 8. **Версии ПО тоже проверяй.** Если предлагаешь CLI, фреймворки, сервисы или MCP-серверы, а версия не зафиксирована пользователем, проверь актуальную стабильную версию через context7, если он доступен, или через web search по официальным источникам.
26
+ 9. **Архитектура должна быть объяснима.** Выбранная архитектура обязана соответствовать масштабу MVP, рискам, команде и будущему росту. Не предлагай сложность без причины.
27
+ 10. **Правила должны быть применимы.** Каждое правило должно отвечать на конкретный риск проекта и иметь понятную проверку: автоматическую, ревью-проверку или договорённость в `docs/rules.md`.
28
+ 11. **Простой язык. Таблицы** используй для сравнений стека, инструментов, MCP, скилов, правил и архитектурных вариантов.
28
29
 
29
30
  ## Интерактивные вопросы
30
31
 
@@ -65,6 +66,11 @@ description: 'Помогает стартовать новый проект: с
65
66
 
66
67
  Для выбранного стека зафиксируй конкретные версии основных компонентов или источник версии: runtime, framework, БД, ORM, тестовый фреймворк, build tool, package manager, контейнеры и ключевые сервисы.
67
68
 
69
+ Для каждого выбранного пакета отдельно зафиксируй:
70
+ - последнюю стабильную версию;
71
+ - источник версии и дату проверки;
72
+ - если версия зафиксирована пользователем и отличается от последней стабильной — обе версии и причину, почему остаёмся на pinned-версии или почему предлагаем обновление.
73
+
68
74
  ### 3. Подобрать инструменты качества
69
75
 
70
76
  Для выбранного стека подбери инструменты с обоснованием:
@@ -195,7 +201,8 @@ Quality gate перед сохранением:
195
201
  - есть список AI-скилов, агентных инструкций или ролей с назначением, источником и артефактом, подобранный под выбранную архитектуру и правила;
196
202
  - MCP-серверы имеют обоснование, права и риски, связанные с выбранной архитектурой, данными и интеграциями;
197
203
  - все значимые решения имеют подтверждение пользователя или явно помечены как автономная рекомендация;
198
- - версии пакетов/ПО проверены или объяснено, почему это не требуется.
204
+ - для каждого выбранного пакета указана последняя стабильная версия и источник; если используется не последняя стабильная версия, причина явно записана;
205
+ - версии другого ПО проверены или объяснено, почему это не требуется.
199
206
 
200
207
  ### 8. Создать черновики правил и архитектуры
201
208