@gian-tiaga/eda 0.4.6 → 0.5.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.
- package/README.md +7 -6
- package/package.json +2 -2
- package/skills/eda-roadmap.md +142 -0
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
|
|
|
@@ -27,6 +27,7 @@ eda init
|
|
|
27
27
|
|
|
28
28
|
| Скил | Что делает | Куда складывает |
|
|
29
29
|
|---|---|---|
|
|
30
|
+
| `eda-roadmap` | Создаёт roadmap-файл: список будущих задач с короткими, понятными и недвусмысленными описаниями без деталей реализации, файлов, библиотек, API и пошагового плана | `docs/roadmaps/` |
|
|
30
31
|
| `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки, риски внутри решений и короткий выбранный вариант решения без плана. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
|
|
31
32
|
| `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. Подтягивает контекст из `docs/rules.md`, `docs/arch.md`, при желании — релевантное исследование. Затем три параллельных модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
|
|
32
33
|
| `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
|
|
@@ -103,15 +104,15 @@ review:
|
|
|
103
104
|
docs ───────────────┬───────────────┐
|
|
104
105
|
│ │
|
|
105
106
|
v v
|
|
106
|
-
explore
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
107
|
+
roadmap ────────> explore ─────> plan ───> execute ───┬──> review ───> fix-by-review ───┬──> send-review
|
|
108
|
+
│ │ │
|
|
109
|
+
└──────────────> plan v └──> commit
|
|
110
|
+
fix ─────────────> review
|
|
110
111
|
|
|
111
112
|
automate может запускаться от review, fix-by-review или fix.
|
|
112
113
|
```
|
|
113
114
|
|
|
114
|
-
Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны.
|
|
115
|
+
Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-roadmap`, `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны.
|
|
115
116
|
|
|
116
117
|
---
|
|
117
118
|
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@gian-tiaga/eda",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"description": "Набор скилов eda-* для Claude Code и Codex CLI: explore, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
|
|
3
|
+
"version": "0.5.0",
|
|
4
|
+
"description": "Набор скилов eda-* для Claude Code и Codex CLI: roadmap, explore, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
7
7
|
"eda": "bin/cli.js"
|
|
@@ -0,0 +1,142 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: eda-roadmap
|
|
3
|
+
description: 'Создаёт roadmap-файл по продуктовой или технической теме: собирает из сообщения пользователя цель, ограничения и список задач, формулирует задачи коротко, понятно и недвусмысленно, без деталей реализации, файлов, библиотек, API и пошагового плана. При необходимости читает docs/rules.md, docs/arch.md и существующие docs/roadmaps/. Задаёт вопросы только если без ответа нельзя составить корректный список задач. Итог сохраняет в docs/roadmaps/. Не исследует глубоко, не планирует реализацию и не меняет код.'
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Скил: Roadmap (eda-roadmap)
|
|
7
|
+
|
|
8
|
+
Создаёшь roadmap: список будущих задач по продуктовой или технической теме. Roadmap отвечает на вопрос «что нужно сделать и зачем», но не отвечает «как именно реализовывать».
|
|
9
|
+
|
|
10
|
+
## Режимы вызова
|
|
11
|
+
|
|
12
|
+
| Режим | Запуск | Что делает |
|
|
13
|
+
|---|---|---|
|
|
14
|
+
| Обычный | `eda-roadmap <тема>` | Создаёт roadmap-файл в `docs/roadmaps/`. |
|
|
15
|
+
| Из текста | `eda-roadmap <список идей или требований>` | Нормализует вход в ясный список задач без деталей реализации. |
|
|
16
|
+
|
|
17
|
+
## Вход из сообщения пользователя
|
|
18
|
+
|
|
19
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, цель, аудиторию, ограничения, примерный горизонт roadmap, уже названные задачи и прямые указания.
|
|
20
|
+
|
|
21
|
+
Если входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск составить roadmap не для той цели. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
22
|
+
|
|
23
|
+
## Главные правила
|
|
24
|
+
|
|
25
|
+
1. **Никаких правок кода.** Запись только в `docs/roadmaps/`.
|
|
26
|
+
2. **Roadmap — не план реализации.** Не указывай файлы, модули, библиотеки, API, миграции, команды, схемы данных, тесты и порядок технической реализации.
|
|
27
|
+
3. **Задачи формулируй как пользовательскую или проектную ценность.** Хорошо: «Аутентификация через email, ВК и Яндекс». Плохо: «Добавить OAuth-клиент, роуты callback и таблицу provider_accounts».
|
|
28
|
+
4. **Каждая задача короткая, но однозначная.** Читатель должен понять границы задачи без дополнительного созвона.
|
|
29
|
+
5. **Можно чуть подробнее, если это снимает двусмысленность.** Допускается одно короткое описание: что должно появиться, для кого и какой результат ожидается.
|
|
30
|
+
6. **Не выдумывай обязательства.** Если пользователь дал только направление, формулируй разумный черновик и явно помечай предположения.
|
|
31
|
+
7. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, чтобы не противоречить зафиксированным правилам и архитектурным ограничениям.
|
|
32
|
+
8. **Существующие roadmap-файлы учитывай только при явной необходимости.** Если пользователь просит продолжить, обновить или не дублировать прошлый roadmap — прочитай релевантные файлы из `docs/roadmaps/`.
|
|
33
|
+
|
|
34
|
+
## Интерактивные вопросы
|
|
35
|
+
|
|
36
|
+
Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
|
|
37
|
+
- Claude Code: используй `AskUserQuestion`.
|
|
38
|
+
- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
|
|
39
|
+
- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
|
|
40
|
+
- Не запускай команды, которые ждут интерактивного ввода в терминале.
|
|
41
|
+
|
|
42
|
+
## Этапы
|
|
43
|
+
|
|
44
|
+
### 1. Понять назначение roadmap
|
|
45
|
+
|
|
46
|
+
Определи:
|
|
47
|
+
- тему roadmap;
|
|
48
|
+
- для кого он нужен: продукт, команда разработки, владелец проекта, пользовательский сценарий;
|
|
49
|
+
- горизонт, если он указан: ближайший релиз, квартал, MVP, несколько этапов;
|
|
50
|
+
- уровень детализации: только список задач или задачи с короткими описаниями.
|
|
51
|
+
|
|
52
|
+
Если тема или назначение неясны — задай `AskUserQuestion` и остановись до ответа.
|
|
53
|
+
|
|
54
|
+
### 2. Собрать минимальный контекст
|
|
55
|
+
|
|
56
|
+
Прочитай `docs/rules.md` и `docs/arch.md`, если они есть. Не делай глубокое исследование кода, если пользователь прямо не просит привязать roadmap к текущему состоянию проекта.
|
|
57
|
+
|
|
58
|
+
Если пользователь просит продолжить или обновить существующий roadmap:
|
|
59
|
+
- найди релевантный файл по указанному пути или теме;
|
|
60
|
+
- если найдено несколько равных вариантов, спроси, какой использовать;
|
|
61
|
+
- не перезаписывай старый файл, если пользователь явно не попросил обновить именно его.
|
|
62
|
+
|
|
63
|
+
### 3. Сформировать задачи
|
|
64
|
+
|
|
65
|
+
Собери задачи в список. Для каждой задачи:
|
|
66
|
+
- дай короткое название;
|
|
67
|
+
- добавь 1–2 предложения описания, если без них задача может быть понята по-разному;
|
|
68
|
+
- опиши результат на уровне поведения или возможности, а не реализации;
|
|
69
|
+
- не добавляй подзадачи с техническими шагами;
|
|
70
|
+
- не добавляй оценки сроков, если пользователь не просил.
|
|
71
|
+
|
|
72
|
+
Хорошие формулировки:
|
|
73
|
+
- «Аутентификация через email, ВК и Яндекс. Пользователь может войти удобным способом и восстановить доступ без обращения в поддержку.»
|
|
74
|
+
- «Личный кабинет пользователя. Пользователь видит свои данные, статус подписки и основные действия по аккаунту в одном месте.»
|
|
75
|
+
- «Базовая модерация контента. Команда может скрывать спорные материалы и видеть причину модерационного решения.»
|
|
76
|
+
|
|
77
|
+
Плохие формулировки:
|
|
78
|
+
- «Подключить `passport-yandex`, добавить callback route и таблицу OAuth-профилей.»
|
|
79
|
+
- «Создать `auth.service.ts`, миграцию и e2e-тесты.»
|
|
80
|
+
- «Реализовать через Redis и очередь фоновых задач.»
|
|
81
|
+
|
|
82
|
+
### 4. Сохранить файл
|
|
83
|
+
|
|
84
|
+
Сохрани roadmap в `docs/roadmaps/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
|
|
85
|
+
|
|
86
|
+
Формат файла:
|
|
87
|
+
|
|
88
|
+
```markdown
|
|
89
|
+
---
|
|
90
|
+
title: <заголовок>
|
|
91
|
+
date: <YYYY-MM-DD HH:MM>
|
|
92
|
+
status: draft
|
|
93
|
+
sources:
|
|
94
|
+
rules: <путь или —>
|
|
95
|
+
arch: <путь или —>
|
|
96
|
+
previous_roadmap: <путь или —>
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
# <Заголовок>
|
|
100
|
+
|
|
101
|
+
## Контекст
|
|
102
|
+
|
|
103
|
+
Коротко: зачем нужен roadmap, для кого он и какой горизонт покрывает.
|
|
104
|
+
|
|
105
|
+
## Предположения
|
|
106
|
+
|
|
107
|
+
- <предположение, если было>
|
|
108
|
+
|
|
109
|
+
Если предположений нет: «Не требовались.»
|
|
110
|
+
|
|
111
|
+
## Задачи
|
|
112
|
+
|
|
113
|
+
| # | Задача | Описание |
|
|
114
|
+
|---|---|---|
|
|
115
|
+
| 1 | <короткая задача> | <понятное описание без деталей реализации> |
|
|
116
|
+
|
|
117
|
+
## Не входит
|
|
118
|
+
|
|
119
|
+
- <что явно не включаем, если это важно>
|
|
120
|
+
|
|
121
|
+
Если явных исключений нет: «Не зафиксировано.»
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
Quality gate перед сохранением:
|
|
125
|
+
- файл лежит в `docs/roadmaps/`;
|
|
126
|
+
- есть ровно один основной список задач в разделе `Задачи`;
|
|
127
|
+
- каждая задача имеет короткое название и понятное описание;
|
|
128
|
+
- задачи не содержат деталей реализации: файлов, библиотек, API, команд, миграций, схем таблиц, тестовых стратегий;
|
|
129
|
+
- roadmap можно использовать как вход для `eda-explore` или `eda-plan`, но сам он не является исследованием или планом реализации.
|
|
130
|
+
|
|
131
|
+
### 5. Финал
|
|
132
|
+
|
|
133
|
+
Короткое сообщение: путь к roadmap-файлу, количество задач, 3–5 самых важных задач простыми словами. Если были предположения — явно скажи, что они записаны в файл.
|
|
134
|
+
|
|
135
|
+
## Чего НЕ делать
|
|
136
|
+
|
|
137
|
+
- Править код, конфиги, зависимости или тесты.
|
|
138
|
+
- Писать план реализации по фазам.
|
|
139
|
+
- Делать техническое исследование вместо roadmap.
|
|
140
|
+
- Указывать конкретные библиотеки, файлы, API, миграции, команды или тестовые сценарии.
|
|
141
|
+
- Раздувать задачу до спецификации или ТЗ.
|
|
142
|
+
- Сохранять файл куда-либо кроме `docs/roadmaps/`.
|