@gian-tiaga/eda 0.4.5 → 0.5.0

package/README.md

@@ -3,7 +3,7 @@
 > Поточная разработка с AI-агентами — на русском языке.
 > Набор готовых скилов для **Claude Code** и **Codex CLI**, которые ведут тебя через весь цикл: от исследования до коммита.
 
-`eda` — это десять скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
+`eda` — это одиннадцать скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
 
 ---
 
@@ -27,11 +27,12 @@ eda init
 
 | Скил | Что делает | Куда складывает |
 |---|---|---|
+| `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/roadmaps/` |
 | `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
 | `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. Подтягивает контекст из `docs/rules.md`, `docs/arch.md`, при желании — релевантное исследование. Затем три параллельных модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
 | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
-| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ. Замечания пишет блоками: сначала контекст и риск, потом конкретные файлы/строки и шаги исправления. Затем параллельные специализированные агенты проверяют выполнение плана, архитектуру, правила и при включённой настройке качество кода. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
+| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ, но в файл пишет только проблемы: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Не перечисляет выполненную работу. Затем параллельные специализированные агенты проверяют выполнение плана, архитектуру, правила и при включённой настройке качество кода. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
 | `eda-fix-by-review` | Применяет замечания из ревью. Обязательные — сразу. Спорные — спрашивает. В конце ссылается на отчёт прямо в файле ревью | `docs/review-fixes/` |
 | `eda-send-review` | Отправляет ревью на GitHub PR через `gh` — как комментарий, review, approve или request-changes. Сам определяет PR по текущей ветке | (комментарий в PR) |
 | `eda-commit` | Делает один аккуратный коммит в стиле проекта. В конце спрашивает: push, merge в main + удалить ветку, или ничего | (git) |
@@ -103,15 +104,15 @@ review:
 docs ───────────────┬───────────────┐
                     │               │
                     v               v
-explore ─────────> plan ────────> execute ───┬──> review ───> fix-by-review ───┬──> send-review
-                                             │                                  │
-                                             v                                  └──> commit
-                                            fix ─────────────> review
+roadmap ────────> explore ─────> plan ───> execute ───┬──> review ───> fix-by-review ───┬──> send-review
+                    │                                  │                                  │
+                    └──────────────> plan              v                                  └──> commit
+                                                      fix ─────────────> review
 
 automate может запускаться от review, fix-by-review или fix.
 ```
 
-Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны.
+Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-roadmap`, `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны.
 
 ---
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.4.5",
-  "description": "Набор скилов eda-* для Claude Code и Codex CLI: explore, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
+  "version": "0.5.0",
+  "description": "Набор скилов eda-* для Claude Code и Codex CLI: roadmap, explore, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
   "type": "module",
   "bin": {
     "eda": "bin/cli.js"

package/skills/eda-review.md

@@ -1,11 +1,11 @@
 ---
 name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью по Markdown-шаблону из этапа 2: с блоками «контекст», «риск», «где», «детали», «как исправить» и пустой строкой между каждым блоком. Сохраняет в docs/reviews/. Всегда запускает параллельные специализированные проверки: выполнение плана, следование архитектуре, следование правилам; проверка качества кода включается настройкой `review.include_code_quality: true` в `docs/settings.yaml`. Кросс-CLI (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true`. Не правит код — это `eda-fix-by-review`.'
+description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью только по проблемам: ошибки, недоделки, неточности, нарушения правил/архитектуры, риски и недостающие тесты. Не перечисляет выполненную работу. Сохраняет в docs/reviews/. Всегда запускает параллельные специализированные проверки: выполнение плана, следование архитектуре, следование правилам; проверка качества кода включается настройкой `review.include_code_quality: true` в `docs/settings.yaml`. Кросс-CLI (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true`. Не правит код — это `eda-fix-by-review`.'
 ---
 
 # Скил: Ревьюер (eda-review)
 
-Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь замечания, ставишь оценку, сохраняешь файл. Затем проверяешь ревью параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
+Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь только найденные проблемы, ставишь оценку, сохраняешь файл. Не перечисляешь, что выполнено хорошо или без замечаний. Затем проверяешь ревью параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
 
 ## Режимы вызова
 
@@ -39,8 +39,9 @@ description: 'Ревью изменений (незакоммиченный diff
 5. **Мета-ревью специализированными агентами — обязательно**, без флага: проверка выполнения плана, проверка архитектуры, проверка правил. Если включена проверка качества кода — добавь `quality-check` тем же batch. Кросс-CLI — только в `strict`.
 6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
 7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
-8. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Сверку с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Между заголовком блока, статусом/типом, контекстом, риском, локациями, деталями и исправлением всегда оставляй одну пустую строку.
-9. **В каждом замечании сначала объясняй контекст без привязки к коду**, чтобы читатель понял проблему и риск. Только после этого давай конкретные файлы/строки. Исправление оформляй так же: сначала общий подход, затем конкретные шаги по коду.
+8. **Ревью содержит только проблемы.** Не пиши отчёт о выполненной работе, список успешно сделанных пунктов, похвалу или нейтральное перечисление изменений. В файл попадают только ошибки, недоделки, неточности, спорные решения, нарушения правил/архитектуры, риски и недостающие проверки. Если проблем нет, напиши коротко: «Явных проблем не найдено», без пересказа diff.
+9. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Проблемы сверки с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Между заголовком блока, статусом/типом, контекстом, риском, локациями, деталями и исправлением всегда оставляй одну пустую строку.
+10. **В каждом замечании сначала объясняй контекст без привязки к коду**, чтобы читатель понял проблему и риск. Только после этого давай конкретные файлы/строки. Исправление оформляй так же: сначала общий подход, затем конкретные шаги по коду.
 
 ## Интерактивные вопросы
 
@@ -75,11 +76,11 @@ description: 'Ревью изменений (незакоммиченный diff
 Если в diff видно отсылки к исследованию из `docs/researches/` — прочитай его тоже.
 
 ### 2. Сделать первичное ревью и сохранить
-Пройдись по изменениям. Сначала проверь, выполнен ли `$PLAN_FILE`: что сделано, что сделано частично, что не сделано, какие отклонения создают риск. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию. Если `review.include_code_quality: true` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
+Пройдись по изменениям. Сначала проверь, выполнен ли `$PLAN_FILE`, но в ревью выноси только проблемы: что сделано частично, что не сделано, какие отклонения создают риск, какие проверки отсутствуют. Не перечисляй выполненные пункты плана. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию. Если `review.include_code_quality: true` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
 
 Каждое замечание должно быть самостоятельным блоком:
 - заголовок с номером и коротким смыслом;
-- тип и рекомендация: `править обязательно`, `на усмотрение автора` или `не править`;
+- тип и рекомендация: `править обязательно` или `на усмотрение автора`;
 - контекст: объяснение проблемы без привязки к конкретному коду;
 - риск: почему это важно для поведения, сопровождения, денег, безопасности или эксплуатации;
 - где: конкретные файлы/строки;
@@ -108,24 +109,31 @@ meta_reviewers: []
 
 **<N>/100.** <одно-два предложения почему>
 
-## Сверка с планом
+## Проблемы сверки с планом
 
-### 1. <пункт или этап плана>
+<Если проблем по плану нет: «Явных проблем по плану не найдено.»>
 
-Статус: <выполнено | частично | не выполнено | не проверялось>
+### 1. <недоделка, отклонение или непроверенный пункт>
+
+Статус: <частично | не выполнено | не проверялось | отклонение>
 
 Контекст:
 <что требовал план простыми словами, без привязки к коду>
 
-Итог:
-<что фактически сделано или не сделано>
+Проблема:
+<что не сделано, сделано неточно или не подтверждено>
 
-Конкретика:
+Риск:
+<почему это важно>
 
-- `<path/file.ts:42>` — <короткое подтверждение>
+Где:
+
+- `<path/file.ts:42>` — <что смотреть>
 
 ## Замечания
 
+<Если замечаний нет: «Явных проблем в коде не найдено.»>
+
 ### 1. <короткий заголовок проблемы>
 
 Тип: `bug`
@@ -157,7 +165,6 @@ meta_reviewers: []
 
 - **Править обязательно:** <номера>
 - **На усмотрение автора:** <номера>
-- **Не править:** <номера или —>
 
 ## Изменения после мета-ревью
 
@@ -183,14 +190,14 @@ meta_reviewers: []
 Каждому дай путь к файлу ревью, `$TARGET`, `$PLAN_FILE`, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, связанный research при наличии. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
 
 Формат ответа агентов:
-- `+` что добавить в ревью;
+- `+` какую проблему добавить в ревью;
 - `−` что убрать как неверное или недоказанное;
 - `~` что переформулировать;
 - `?` что невозможно проверить и почему.
 
 Для `plan-check` добавь явную инструкцию: «Если `$PLAN_FILE` не передан или файл не найден, верни только `? план не проверен: нужен путь к файлу`; не пытайся угадывать план.»
 
-Когда все агенты ответили: прочитай ответы, **сам реши**, что применять. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
+Когда все агенты ответили: прочитай ответы, **сам реши**, что применять. Добавляй только подтверждённые проблемы; предложения вида «добавить, что пункт выполнен» отклоняй как неформат ревью. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
 
 ```markdown
 ### После plan-check / architecture-check / rules-check / quality-check
@@ -208,13 +215,13 @@ meta_reviewers: []
 В `strict`: отдай файл соседнему агенту через `Bash`. Если ты в Claude Code — запускай Codex CLI:
 
 ```bash
-codex exec "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: что добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
+codex exec "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: какие проблемы добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Не предлагай перечислять выполненную работу. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
 ```
 
 Если ты в Codex — запускай Claude CLI с теми же требованиями глубины:
 
 ```bash
-claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: что добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
+claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, docs/arch.md, связанный research при наличии. Затем глубоко проверь ревью по плану, правилам, архитектуре и релевантному коду: открой файлы, модули, API и тесты, которые следуют из diff и замечаний, и оцени фактическую корректность. Мета-ревью на русском: какие проблемы добавить, убрать, переформулировать; какие баги, риски для смежного кода и недостающие тесты пропущены. Не предлагай перечислять выполненную работу. Формат: '+', '−', '~', '?'." > "${REVIEW_FILE%.md}_cli_meta.md"
 ```
 
 Соседней CLI нет — `AskUserQuestion`: завершить как есть или прервать.
@@ -231,7 +238,7 @@ claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, do
 Добавь в `meta_reviewers` имя CLI. `status: meta-reviewed` → `final`.
 
 ### 5. Финал
-Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение» / «не править». Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review strict`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
+Короткое сообщение: режим (`normal` или `strict`), путь к файлу ревью, итоговая оценка, сколько пунктов «править обязательно» / «на усмотрение». Не пересказывай выполненную работу. Если режим был обычный — добавь строку «кросс-CLI не запускался; для проверки соседним агентом — `eda-review strict`». Что предлагаешь дальше — `eda-fix-by-review` для применения или `eda-commit` если оценка приемлема.
 
 ## Чего НЕ делать
 - Править код. Это `eda-fix-by-review`.
@@ -242,3 +249,4 @@ claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, do
 - Задавать вопросы без блокировки и продолжать работу до ответа.
 - Сохранять ревью куда-либо кроме `docs/reviews/`.
 - Оформлять замечания без контекста перед конкретикой.
+- Перечислять выполненные пункты плана или давать общий отчёт о проделанной работе.

package/skills/eda-roadmap.md

@@ -0,0 +1,142 @@
+---
+name: eda-roadmap
+description: 'Создаёт roadmap-файл по продуктовой или технической теме: собирает из сообщения пользователя цель, ограничения и список задач, формулирует задачи коротко, понятно и недвусмысленно, без деталей реализации, файлов, библиотек, API и пошагового плана. При необходимости читает docs/rules.md, docs/arch.md и существующие docs/roadmaps/. Задаёт вопросы только если без ответа нельзя составить корректный список задач. Итог сохраняет в docs/roadmaps/. Не исследует глубоко, не планирует реализацию и не меняет код.'
+---
+
+# Скил: Roadmap (eda-roadmap)
+
+Создаёшь roadmap: список будущих задач по продуктовой или технической теме. Roadmap отвечает на вопрос «что нужно сделать и зачем», но не отвечает «как именно реализовывать».
+
+## Режимы вызова
+
+| Режим | Запуск | Что делает |
+|---|---|---|
+| Обычный | `eda-roadmap <тема>` | Создаёт roadmap-файл в `docs/roadmaps/`. |
+| Из текста | `eda-roadmap <список идей или требований>` | Нормализует вход в ясный список задач без деталей реализации. |
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, цель, аудиторию, ограничения, примерный горизонт roadmap, уже названные задачи и прямые указания.
+
+Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск составить roadmap не для той цели. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Никаких правок кода.** Запись только в `docs/roadmaps/`.
+2. **Roadmap — не план реализации.** Не указывай файлы, модули, библиотеки, API, миграции, команды, схемы данных, тесты и порядок технической реализации.
+3. **Задачи формулируй как пользовательскую или проектную ценность.** Хорошо: «Аутентификация через email, ВК и Яндекс». Плохо: «Добавить OAuth-клиент, роуты callback и таблицу provider_accounts».
+4. **Каждая задача короткая, но однозначная.** Читатель должен понять границы задачи без дополнительного созвона.
+5. **Можно чуть подробнее, если это снимает двусмысленность.** Допускается одно короткое описание: что должно появиться, для кого и какой результат ожидается.
+6. **Не выдумывай обязательства.** Если пользователь дал только направление, формулируй разумный черновик и явно помечай предположения.
+7. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, чтобы не противоречить зафиксированным правилам и архитектурным ограничениям.
+8. **Существующие roadmap-файлы учитывай только при явной необходимости.** Если пользователь просит продолжить, обновить или не дублировать прошлый roadmap — прочитай релевантные файлы из `docs/roadmaps/`.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+## Этапы
+
+### 1. Понять назначение roadmap
+
+Определи:
+- тему roadmap;
+- для кого он нужен: продукт, команда разработки, владелец проекта, пользовательский сценарий;
+- горизонт, если он указан: ближайший релиз, квартал, MVP, несколько этапов;
+- уровень детализации: только список задач или задачи с короткими описаниями.
+
+Если тема или назначение неясны — задай `AskUserQuestion` и остановись до ответа.
+
+### 2. Собрать минимальный контекст
+
+Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Не делай глубокое исследование кода, если пользователь прямо не просит привязать roadmap к текущему состоянию проекта.
+
+Если пользователь просит продолжить или обновить существующий roadmap:
+- найди релевантный файл по указанному пути или теме;
+- если найдено несколько равных вариантов, спроси, какой использовать;
+- не перезаписывай старый файл, если пользователь явно не попросил обновить именно его.
+
+### 3. Сформировать задачи
+
+Собери задачи в список. Для каждой задачи:
+- дай короткое название;
+- добавь 1–2 предложения описания, если без них задача может быть понята по-разному;
+- опиши результат на уровне поведения или возможности, а не реализации;
+- не добавляй подзадачи с техническими шагами;
+- не добавляй оценки сроков, если пользователь не просил.
+
+Хорошие формулировки:
+- «Аутентификация через email, ВК и Яндекс. Пользователь может войти удобным способом и восстановить доступ без обращения в поддержку.»
+- «Личный кабинет пользователя. Пользователь видит свои данные, статус подписки и основные действия по аккаунту в одном месте.»
+- «Базовая модерация контента. Команда может скрывать спорные материалы и видеть причину модерационного решения.»
+
+Плохие формулировки:
+- «Подключить `passport-yandex`, добавить callback route и таблицу OAuth-профилей.»
+- «Создать `auth.service.ts`, миграцию и e2e-тесты.»
+- «Реализовать через Redis и очередь фоновых задач.»
+
+### 4. Сохранить файл
+
+Сохрани roadmap в `docs/roadmaps/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+
+Формат файла:
+
+```markdown
+---
+title: <заголовок>
+date: <YYYY-MM-DD HH:MM>
+status: draft
+sources:
+  rules: <путь или —>
+  arch: <путь или —>
+  previous_roadmap: <путь или —>
+---
+
+# <Заголовок>
+
+## Контекст
+
+Коротко: зачем нужен roadmap, для кого он и какой горизонт покрывает.
+
+## Предположения
+
+- <предположение, если было>
+
+Если предположений нет: «Не требовались.»
+
+## Задачи
+
+| # | Задача | Описание |
+|---|---|---|
+| 1 | <короткая задача> | <понятное описание без деталей реализации> |
+
+## Не входит
+
+- <что явно не включаем, если это важно>
+
+Если явных исключений нет: «Не зафиксировано.»
+```
+
+Quality gate перед сохранением:
+- файл лежит в `docs/roadmaps/`;
+- есть ровно один основной список задач в разделе `Задачи`;
+- каждая задача имеет короткое название и понятное описание;
+- задачи не содержат деталей реализации: файлов, библиотек, API, команд, миграций, схем таблиц, тестовых стратегий;
+- roadmap можно использовать как вход для `eda-explore` или `eda-plan`, но сам он не является исследованием или планом реализации.
+
+### 5. Финал
+
+Короткое сообщение: путь к roadmap-файлу, количество задач, 3–5 самых важных задач простыми словами. Если были предположения — явно скажи, что они записаны в файл.
+
+## Чего НЕ делать
+
+- Править код, конфиги, зависимости или тесты.
+- Писать план реализации по фазам.
+- Делать техническое исследование вместо roadmap.
+- Указывать конкретные библиотеки, файлы, API, миграции, команды или тестовые сценарии.
+- Раздувать задачу до спецификации или ТЗ.
+- Сохранять файл куда-либо кроме `docs/roadmaps/`.