@gian-tiaga/eda 0.3.1 → 0.3.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.
- package/docs/skills/eda-automate.md +18 -6
- package/docs/skills/eda-commit.md +9 -1
- package/docs/skills/eda-docs.md +8 -2
- package/docs/skills/eda-execute.md +19 -5
- package/docs/skills/eda-fix-by-review.md +24 -5
- package/docs/skills/eda-fix.md +6 -0
- package/docs/skills/eda-plan.md +17 -2
- package/docs/skills/eda-research.md +8 -2
- package/docs/skills/eda-review.md +6 -0
- package/docs/skills/eda-send-review.md +19 -6
- package/package.json +1 -1
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: eda-automate
|
|
3
|
-
description: 'Анализирует историю `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`, а с
|
|
3
|
+
description: 'Анализирует историю `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`, а по тексту рядом с вызовом может включать `docs/plans/`, последние N, период или конкретные файлы. Ищет повторяющиеся замечания, фиксы и проблемы планирования, предлагает автоматизации, а также черновики дополнений для `docs/rules.md` и `docs/arch.md`. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет изменения — выдаёт приоритезированный список с черновиками правил, проверок и правок документации. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Скил: Автоматизатор (eda-automate)
|
|
@@ -14,6 +14,12 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
|
|
|
14
14
|
| Обычный | `eda-automate` | `docs/reviews/` + `docs/review-fixes/` + `docs/fixes/` |
|
|
15
15
|
| С планами | `eda-automate plans` | `docs/reviews/` + `docs/review-fixes/` + `docs/fixes/` + `docs/plans/` |
|
|
16
16
|
|
|
17
|
+
## Вход из сообщения пользователя
|
|
18
|
+
|
|
19
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
20
|
+
|
|
21
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
22
|
+
|
|
17
23
|
## Главные правила
|
|
18
24
|
|
|
19
25
|
1. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им. Не предлагай то, что уже зафиксировано как автоматизированное правило или архитектурное решение.
|
|
@@ -35,16 +41,22 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
|
|
|
35
41
|
## Этапы
|
|
36
42
|
|
|
37
43
|
### 1. Выбрать диапазон
|
|
38
|
-
Определи режим по
|
|
44
|
+
Определи режим и диапазон по тексту рядом с вызовом. Если передан `plans`, указаны файлы из `docs/plans/` или пользователь явно просит анализ планов — включи планы в источники без отдельного вопроса.
|
|
45
|
+
|
|
46
|
+
Без вопроса используй вход, если он задаёт:
|
|
47
|
+
- `plans` / анализ планов;
|
|
48
|
+
- последние N (`последние 5`, `last 10`);
|
|
49
|
+
- период (`за 30 дней`, `с YYYY-MM-DD по YYYY-MM-DD`);
|
|
50
|
+
- конкретные файлы или папки.
|
|
39
51
|
|
|
40
|
-
`AskUserQuestion`: какую историю анализировать.
|
|
41
|
-
- Все ревью + фиксы по ревью + обычные фиксы
|
|
42
|
-
- Все ревью + фиксы по ревью + обычные фиксы + планы
|
|
52
|
+
Если диапазон не указан, но источники есть, используй все ревью + фиксы по ревью + обычные фиксы по умолчанию. Если вход неоднозначен — `AskUserQuestion`: какую историю анализировать.
|
|
53
|
+
- Все ревью + фиксы по ревью + обычные фиксы
|
|
54
|
+
- Все ревью + фиксы по ревью + обычные фиксы + планы
|
|
43
55
|
- Последние N (5/10/20)
|
|
44
56
|
- За период (последние N дней)
|
|
45
57
|
- Конкретные файлы
|
|
46
58
|
|
|
47
|
-
Получи список файлов из `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`.
|
|
59
|
+
Получи список файлов из `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`. В режиме `plans` дополнительно получи список файлов из `docs/plans/`. Если нужные папки отсутствуют или пусты, не продолжай с пустым списком: сообщи, каких источников нет; если не осталось ни одного источника, остановись с понятным вопросом или статусом `blocked: нет источников для анализа`.
|
|
48
60
|
|
|
49
61
|
### 2. Прочитать контекст
|
|
50
62
|
- Все выбранные ревью, отчёты о фиксах по ревью и обычные фиксы.
|
|
@@ -1,12 +1,18 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: eda-commit
|
|
3
|
-
description: 'Формирует коммит из незакоммиченных изменений
|
|
3
|
+
description: 'Формирует коммит из незакоммиченных изменений с учётом текста рядом с вызовом: файлы, сообщение коммита и намерение push. Читает docs/rules.md и docs/arch.md, строго следует им и истории коммитов, включая связанные артефакты из `docs/**`, которые создали скилы. Коммитит без `--no-verify`. После коммита спрашивает интерактивно про push / merge в main + переключение + удаление ветки / ничего; inline push не обходит подтверждение. Не правит логику кода, не пишет тесты — это `eda-execute`, `eda-fix` или `eda-fix-by-review`.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Скил: Коммитер (eda-commit)
|
|
7
7
|
|
|
8
8
|
Берёшь незакоммиченные изменения, делаешь один аккуратный коммит, спрашиваешь у пользователя что делать дальше с веткой и remote.
|
|
9
9
|
|
|
10
|
+
## Вход из сообщения пользователя
|
|
11
|
+
|
|
12
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
13
|
+
|
|
14
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
15
|
+
|
|
10
16
|
## Главные правила
|
|
11
17
|
|
|
12
18
|
1. **Интерактивные вопросы** — по разделу ниже.
|
|
@@ -33,6 +39,8 @@ description: 'Формирует коммит из незакоммиченны
|
|
|
33
39
|
|
|
34
40
|
Если незакоммиченных изменений нет — сообщи и выйди.
|
|
35
41
|
|
|
42
|
+
Разбери текст рядом с вызовом: он может задавать конкретные файлы для коммита, черновик сообщения коммита или намерение `push`. Используй список файлов и сообщение, если они не противоречат diff и правилам проекта. Inline `push` считай намерением для этапа 3, но не разрешением обойти обязательный вопрос после коммита. Merge, force-push, удаление ветки, спорные файлы и файлы с признаками секретов всё равно требуют подтверждения по правилам ниже.
|
|
43
|
+
|
|
36
44
|
### 2. Сформировать коммит
|
|
37
45
|
Составь сообщение в стиле проекта: первая строка короткая (до ~70 символов), при необходимости — тело с пояснением «почему» (не «что» — это в diff).
|
|
38
46
|
|
package/docs/skills/eda-docs.md
CHANGED
|
@@ -1,12 +1,18 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: eda-docs
|
|
3
|
-
description: 'Создаёт или обновляет
|
|
3
|
+
description: 'Создаёт или обновляет документы, указанные рядом с вызовом: `docs/rules.md` (максимально строгие правила для стека + предложения новых инструментов), `docs/arch.md` (архитектура проекта), `AGENTS.md` (описание проекта, стек, ссылки на документы и команды) или все три. Анализирует стек сам. Не правит код. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Скил: Документатор (eda-docs)
|
|
7
7
|
|
|
8
8
|
Создаёшь или обновляешь три документа: `docs/rules.md`, `docs/arch.md` и шапку `AGENTS.md`. Правила — **максимально строгие** для стека проекта; смело предлагай инструменты, которых ещё нет, если они повышают строгость.
|
|
9
9
|
|
|
10
|
+
## Вход из сообщения пользователя
|
|
11
|
+
|
|
12
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
13
|
+
|
|
14
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
15
|
+
|
|
10
16
|
## Главные правила
|
|
11
17
|
|
|
12
18
|
1. **Интерактивные вопросы** — по разделу ниже.
|
|
@@ -33,7 +39,7 @@ description: 'Создаёт или обновляет три ключевых
|
|
|
33
39
|
`docs/rules.md`, `docs/arch.md`, `AGENTS.md` (если есть). Прочитай их и строго следуй уже зафиксированной рамке, если задача не требует её изменить. Запомни, что в них уже зафиксировано — чтобы не дублировать и не противоречить.
|
|
34
40
|
|
|
35
41
|
### 3. Уточнить, что обновляем
|
|
36
|
-
`AskUserQuestion`: какие документы трогаем — все три / только rules / только arch / только AGENTS / выбрать несколько.
|
|
42
|
+
Сначала разбери текст рядом с вызовом. Если пользователь указал `rules`, `docs/rules.md`, `arch`, `docs/arch.md`, `AGENTS.md` или «все» — используй этот список без вопроса. Если список документов не указан или неоднозначен — `AskUserQuestion`: какие документы трогаем — все три / только rules / только arch / только AGENTS / выбрать несколько.
|
|
37
43
|
|
|
38
44
|
Для каждого существующего файла — **отдельный** `AskUserQuestion`: переписать с нуля / дополнить / оставить как есть.
|
|
39
45
|
|
|
@@ -1,12 +1,18 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: eda-execute
|
|
3
|
-
description: 'Исполняет план из docs/plans/
|
|
3
|
+
description: 'Исполняет план из docs/plans/ по пути или описанию рядом с вызовом. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им, правит код, пишет тесты к изменениям внутри каждого шага, в конце прогоняет полный сьют тестов и линтеры. Прогресс — чекбоксы в файле плана + журнал в `docs/executions/`; в конец плана дописывается ссылка на журнал. Не коммитит (это `eda-commit`), не делает ревью (это `eda-review`). Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Скил: Исполнитель (eda-execute)
|
|
7
7
|
|
|
8
8
|
Берёшь готовый план из `docs/plans/`, выполняешь до конца, ведёшь журнал. Останавливаешься только при реальных проблемах.
|
|
9
9
|
|
|
10
|
+
## Вход из сообщения пользователя
|
|
11
|
+
|
|
12
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
13
|
+
|
|
14
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
15
|
+
|
|
10
16
|
## Главные правила
|
|
11
17
|
|
|
12
18
|
1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Это рамка проекта. Файлов нет — продолжай молча. Один раз в начале, не перечитывать на каждом шаге.
|
|
@@ -15,8 +21,9 @@ description: 'Исполняет план из docs/plans/ — перед пра
|
|
|
15
21
|
4. **Не коммитить, не пушить, не делать ревью.** Это другие скилы.
|
|
16
22
|
5. **Идти целиком**, не делать паузы «для подтверждения». Останавливайся только если: тест упал, шаг противоречив, есть риск потерять данные, рискованная операция вне плана.
|
|
17
23
|
6. **Тесты — внутри шага.** Меняешь поведение → пишешь тесты к этому изменению в том же шаге, точечно прогоняешь только их. Полный сьют и линтеры — один раз в конце (этап 7), не на каждом шаге.
|
|
18
|
-
7.
|
|
19
|
-
8.
|
|
24
|
+
7. **Проверки нельзя подавлять.** Не отключай линтеры, тесты, typecheck, static analysis и другие проверки; не добавляй игноры, исключения из проверок, ослабление правил или изменение команд так, чтобы проверка перестала запускаться. Пиши и правь код так, чтобы проверки проходили по сути.
|
|
25
|
+
8. **Простой язык** в сообщениях пользователю и вопросах. Термины — только если без них нельзя, и сразу с пояснением.
|
|
26
|
+
9. **Таблицы для структурируемых данных** в журнале. Диаграммы — только если действительно есть что показать.
|
|
20
27
|
|
|
21
28
|
## Интерактивные вопросы
|
|
22
29
|
|
|
@@ -30,7 +37,13 @@ description: 'Исполняет план из docs/plans/ — перед пра
|
|
|
30
37
|
## Этапы
|
|
31
38
|
|
|
32
39
|
### 1. Выбрать план
|
|
33
|
-
|
|
40
|
+
Сначала разбери текст рядом с вызовом:
|
|
41
|
+
- если указан путь к плану — используй его как `$PLAN_FILE`;
|
|
42
|
+
- если указано название плана или часть названия — найди совпадение в `docs/plans/`;
|
|
43
|
+
- если написано «последний план» — возьми самый новый файл из `docs/plans/`;
|
|
44
|
+
- если вставлен текст плана — используй его как план выполнения и при инициализации прогресса сохрани/привяжи к файлу в `docs/plans/`, если это безопасно и однозначно.
|
|
45
|
+
|
|
46
|
+
Если найден ровно один план — продолжай без вопроса. Если найдено несколько одинаково подходящих планов — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/plans/`. Если `docs/plans/` отсутствует или пуста и вход не содержит план — остановись с понятным вопросом или статусом `blocked: нужен план`. Запиши путь в `$PLAN_FILE`.
|
|
34
47
|
|
|
35
48
|
### 2. Выбрать место выполнения
|
|
36
49
|
`AskUserQuestion` с четырьмя вариантами:
|
|
@@ -106,7 +119,7 @@ cd ../<repo-name>-<slug>
|
|
|
106
119
|
Если в «Изменениях в docs» что-то накопилось — допиши в `docs/rules.md` или `docs/arch.md` минимально достаточно. Файлов нет — пропусти (создаёт `eda-docs`).
|
|
107
120
|
|
|
108
121
|
### 7. Финальная проверка
|
|
109
|
-
Прогони полный сьют тестов и линтеры на проекте. Команды — стандартные для стека; если непонятно — `AskUserQuestion` один раз. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`. Результат фиксируй разделом `## Финальная проверка` в журнале.
|
|
122
|
+
Прогони полный сьют тестов и линтеры на проекте. Команды — стандартные для стека; если непонятно — `AskUserQuestion` один раз. Свои поломки — правишь причину и повторяешь. Запрещено делать проверки зелёными через подавление ошибок, отключение правил, исключение файлов, ослабление конфигов или изменение команд проверки. Чужие/несвязанные — `AskUserQuestion`. Результат фиксируй разделом `## Финальная проверка` в журнале.
|
|
110
123
|
|
|
111
124
|
### 8. Финал
|
|
112
125
|
Короткое сообщение: пути к плану и журналу, сводка шагов, результат финальной проверки, состояние git («не закоммичено»), 1–3 главных «что важно знать», подсказка «дальше — `eda-review` или `eda-commit`».
|
|
@@ -118,3 +131,4 @@ cd ../<repo-name>-<slug>
|
|
|
118
131
|
- Делать паузу после каждого шага «для подтверждения».
|
|
119
132
|
- Пропускать обновление чекбоксов и журнала — иначе теряется состояние.
|
|
120
133
|
- Делать рискованное (удаление файлов, миграции, секреты) без подтверждения, даже если упомянуто в плане.
|
|
134
|
+
- Подавлять ошибки линтеров, тестов, typecheck или других проверок вместо исправления кода.
|
|
@@ -1,12 +1,18 @@
|
|
|
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` и строго следует им. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно; «не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью (это `eda-review`), не коммитит (это `eda-commit`). Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Скил: Исправитель по ревью (eda-fix-by-review)
|
|
7
7
|
|
|
8
8
|
Берёшь готовое ревью из `docs/reviews/`, применяешь замечания к коду, сохраняешь отчёт о фиксах в `docs/review-fixes/`. После всех правок — полный прогон тестов и линтеров.
|
|
9
9
|
|
|
10
|
+
## Вход из сообщения пользователя
|
|
11
|
+
|
|
12
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
13
|
+
|
|
14
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
15
|
+
|
|
10
16
|
## Главные правила
|
|
11
17
|
|
|
12
18
|
1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Это рамка проекта. Один раз в начале.
|
|
@@ -33,10 +39,21 @@ description: 'Применяет замечания из ревью (`docs/revie
|
|
|
33
39
|
## Этапы
|
|
34
40
|
|
|
35
41
|
### 1. Выбрать ревью
|
|
36
|
-
|
|
42
|
+
Сначала разбери текст рядом с вызовом:
|
|
43
|
+
- если указан путь к ревью — используй его как `$REVIEW_FILE`;
|
|
44
|
+
- если указано название ревью или часть названия — найди совпадение в `docs/reviews/`;
|
|
45
|
+
- если написано «последнее ревью» — возьми самый новый файл из `docs/reviews/`;
|
|
46
|
+
- если указаны номера замечаний — применяй только эти пункты, сохрани фильтр в отчёте;
|
|
47
|
+
- если сами замечания вставлены в сообщение — используй режим `$REVIEW_SOURCE=review_text`, не выбирай файл ревью и сохрани отчёт с `review: text`.
|
|
48
|
+
|
|
49
|
+
Если найдено ровно одно ревью — используй режим `$REVIEW_SOURCE=review_file` и продолжай без вопроса. Если замечания даны текстом — используй режим `$REVIEW_SOURCE=review_text` и продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста и вход не содержит замечания — остановись с понятным вопросом или статусом `blocked: нужно ревью`.
|
|
37
50
|
|
|
38
51
|
### 2. Прочитать контекст
|
|
39
|
-
`docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
|
|
52
|
+
`docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
|
|
53
|
+
|
|
54
|
+
Если `$REVIEW_SOURCE=review_file`, прочитай сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
|
|
55
|
+
|
|
56
|
+
Если `$REVIEW_SOURCE=review_text`, работай по замечаниям из текущего сообщения пользователя. Файла ревью нет: не пытайся читать `$REVIEW_FILE` и не ищи связанные plan/research, если они не указаны в тексте.
|
|
40
57
|
|
|
41
58
|
### 3. Применить замечания
|
|
42
59
|
Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):
|
|
@@ -50,13 +67,15 @@ description: 'Применяет замечания из ревью (`docs/revie
|
|
|
50
67
|
Прогони полный сьют тестов и линтеры. Команды — стандартные для стека; непонятно — `AskUserQuestion`. Свои поломки — правишь и повторяешь. Чужие/несвязанные — `AskUserQuestion`.
|
|
51
68
|
|
|
52
69
|
### 5. Сохранить отчёт о фиксах и связать с ревью
|
|
53
|
-
Сохрани отчёт в `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же что у ревью или близкий).
|
|
70
|
+
Сохрани отчёт в `docs/review-fixes/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же что у ревью или близкий). Если `$REVIEW_SOURCE=review_file`, затем **допиши в конец файла ревью** (`$REVIEW_FILE`) раздел со ссылкой:
|
|
54
71
|
|
|
55
72
|
```markdown
|
|
56
73
|
## Применённые фиксы
|
|
57
74
|
Отчёт: `docs/review-fixes/{file}.md`
|
|
58
75
|
```
|
|
59
76
|
|
|
77
|
+
Если `$REVIEW_SOURCE=review_text`, не дописывай ссылку в исходное ревью: такого файла нет. В отчёте укажи `review: text`.
|
|
78
|
+
|
|
60
79
|
Шаблон отчёта:
|
|
61
80
|
|
|
62
81
|
```markdown
|
|
@@ -83,7 +102,7 @@ status: done
|
|
|
83
102
|
```
|
|
84
103
|
|
|
85
104
|
### 6. Финал
|
|
86
|
-
Короткое сообщение: путь к
|
|
105
|
+
Короткое сообщение: путь к ревью или «источник: текст из сообщения», путь к отчёту о фиксах, сколько применено / пропущено / отклонено, результат финальной проверки, состояние git («не закоммичено»). Подсказка дальше — `eda-commit`.
|
|
87
106
|
|
|
88
107
|
## Чего НЕ делать
|
|
89
108
|
- Делать само ревью — это `eda-review`.
|
package/docs/skills/eda-fix.md
CHANGED
|
@@ -14,6 +14,12 @@ description: 'Делает обычные фиксы по плану, файлу
|
|
|
14
14
|
| По контексту | `eda-fix <что исправить>` | Делает фиксы по тексту пользователя |
|
|
15
15
|
| По плану | `eda-fix docs/plans/<file>.md` | Делает фиксы по указанному плану |
|
|
16
16
|
|
|
17
|
+
## Вход из сообщения пользователя
|
|
18
|
+
|
|
19
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
20
|
+
|
|
21
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
22
|
+
|
|
17
23
|
## Главные правила
|
|
18
24
|
|
|
19
25
|
1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Файлов нет — продолжай.
|
package/docs/skills/eda-plan.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: eda-plan
|
|
3
|
-
description: '
|
|
3
|
+
description: 'Пишет план реализации по тексту рядом с вызовом или указанному research-файлу через стандартный Plan Mode (Claude Code / Codex). Перед планированием читает docs/rules.md, docs/arch.md и строго следует им; research подтягивает без вопроса, если он указан или явно нужен. Нормализует результат в исполнимый план с целевым алгоритмом, фазами, проверками и без неразрешённых альтернатив. Согласованный план сохраняется в docs/plans/. Всегда проверяет план тремя параллельными моделями (слабая, средняя, мощная) на реалистичность, пропущенные шаги, нарушения правил и риски. В `strict` — ещё и кросс-CLI (Claude ↔ Codex). Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Скил: Планировщик (eda-plan)
|
|
@@ -14,6 +14,12 @@ description: 'Написание плана реализации через ст
|
|
|
14
14
|
| Обычный | `eda-plan <тема>` | Этапы 1–6 + финал. Кросс-CLI не запускается. |
|
|
15
15
|
| Строгий | `eda-plan strict <тема>` | + кросс-CLI соседним агентом + допил. |
|
|
16
16
|
|
|
17
|
+
## Вход из сообщения пользователя
|
|
18
|
+
|
|
19
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
20
|
+
|
|
21
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
22
|
+
|
|
17
23
|
## Главные правила
|
|
18
24
|
|
|
19
25
|
1. **Никаких правок кода.** Запись только в `docs/plans/`.
|
|
@@ -38,7 +44,16 @@ description: 'Написание плана реализации через ст
|
|
|
38
44
|
## Этапы
|
|
39
45
|
|
|
40
46
|
### 1. Подтянуть контекст
|
|
41
|
-
|
|
47
|
+
Разбери текст текущего сообщения рядом с вызовом скилла и сохрани его как исходный запрос для Plan Mode.
|
|
48
|
+
|
|
49
|
+
Прочитай `docs/rules.md`, `docs/arch.md` (если есть) и строго следуй им при планировании.
|
|
50
|
+
|
|
51
|
+
Research подтягивай так:
|
|
52
|
+
- если в сообщении указан путь к `docs/researches/...` или другой research-файл — прочитай его без вопроса;
|
|
53
|
+
- если в сообщении есть описание задачи без research-файла — используй описание как контекст и не спрашивай research автоматически;
|
|
54
|
+
- если пользователь явно просит использовать research, но файл не указал — через `AskUserQuestion` выбери из последних файлов `docs/researches/` + опция «нет»;
|
|
55
|
+
- если `docs/researches/` отсутствует или пуста, а research явно нужен — сообщи об этом и продолжай без research, если задачи достаточно; если без research нельзя безопасно планировать, задай один блокирующий вопрос;
|
|
56
|
+
- если текста задачи нет совсем — спроси через `AskUserQuestion`, что нужно планировать.
|
|
42
57
|
|
|
43
58
|
### 2. Уточнить, если есть неясность
|
|
44
59
|
Не переформулируй запрос. Если есть конкретная неясность, без которой планировать нельзя — задай 1–4 точечных вопроса через `AskUserQuestion`. Не задавай «на всякий случай». Пары «вопрос → ответ» сохрани — они идут в Plan Mode.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: eda-research
|
|
3
|
-
description: 'Глубокое исследование темы или задачи в read-only режиме. Без правки кода.
|
|
3
|
+
description: 'Глубокое исследование темы или задачи из текста рядом с вызовом в read-only режиме. Без правки кода. Вопросы задаёт только когда без ответа нельзя безопасно продолжать. Mermaid-диаграммы и markdown-таблицы — там где это даёт ясность. Итог сохраняется в docs/researches/. По умолчанию без кросс-ревью; кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict`.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Скил: Исследователь (eda-research)
|
|
@@ -14,6 +14,12 @@ description: 'Глубокое исследование темы или зада
|
|
|
14
14
|
| Обычный | `eda-research <тема>` | Этапы 1–4 + финал. |
|
|
15
15
|
| Строгий | `eda-research strict <тема>` | + кросс-ревью соседним агентом + допил. |
|
|
16
16
|
|
|
17
|
+
## Вход из сообщения пользователя
|
|
18
|
+
|
|
19
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
20
|
+
|
|
21
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
22
|
+
|
|
17
23
|
## Главные правила
|
|
18
24
|
|
|
19
25
|
1. **Никаких правок кода.** Запись только в `docs/researches/`.
|
|
@@ -35,7 +41,7 @@ description: 'Глубокое исследование темы или зада
|
|
|
35
41
|
## Этапы
|
|
36
42
|
|
|
37
43
|
### 1. Понять задачу
|
|
38
|
-
Прочитай
|
|
44
|
+
Прочитай текст рядом с вызовом. Если тема и цель понятны, сформулируй цель и 3–7 конкретных вопросов для отчёта и продолжай без отдельного подтверждения. Если темы нет или она неоднозначна — задай `AskUserQuestion` и не уходи дальше без ответа.
|
|
39
45
|
|
|
40
46
|
### 2. Собрать материал
|
|
41
47
|
Работай в read-only режиме: читай файлы, ищи по проекту, смотри историю и запускай только команды, которые не меняют рабочее дерево. Прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Код, конфиги и зависимости не правь. Запись разрешена только на этапе 4 при сохранении итогового отчёта в `docs/researches/`.
|
|
@@ -14,6 +14,12 @@ description: 'Ревью изменений (незакоммиченный diff
|
|
|
14
14
|
| Обычный | `eda-review` | Этапы 1–3 + финал. Кросс-CLI не запускается. |
|
|
15
15
|
| Строгий | `eda-review strict` | + кросс-CLI соседним агентом + допил. |
|
|
16
16
|
|
|
17
|
+
## Вход из сообщения пользователя
|
|
18
|
+
|
|
19
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
20
|
+
|
|
21
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
22
|
+
|
|
17
23
|
## Главные правила
|
|
18
24
|
|
|
19
25
|
1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Замечания должны опираться на правила и архитектуру проекта, а не на твои общие представления.
|
|
@@ -1,18 +1,24 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: eda-send-review
|
|
3
|
-
description: 'Отправляет ревью из `docs/reviews
|
|
3
|
+
description: 'Отправляет ревью из `docs/reviews/...`, выбранное по тексту рядом с вызовом, на GitHub PR через `gh` — как review (comment/approve/request-changes) или как обычный комментарий. Перед отправкой читает `docs/rules.md` и `docs/arch.md` и строго следует им. Целевой PR определяется из текста или автоматически по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку на PR-комментарий. Не правит код, не делает само ревью. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Скил: Отправитель ревью (eda-send-review)
|
|
7
7
|
|
|
8
8
|
Берёшь готовое ревью из `docs/reviews/`, отправляешь его на GitHub PR через `gh`. В конец файла ревью дописываешь, куда отправил.
|
|
9
9
|
|
|
10
|
+
## Вход из сообщения пользователя
|
|
11
|
+
|
|
12
|
+
Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
|
|
13
|
+
|
|
14
|
+
Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
|
|
15
|
+
|
|
10
16
|
## Главные правила
|
|
11
17
|
|
|
12
18
|
1. **Интерактивные вопросы** — по разделу ниже.
|
|
13
19
|
2. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе способа отправки и финальной отметке.
|
|
14
20
|
3. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
|
|
15
|
-
4. **Никаких самостоятельных оценок.** Тип отправки
|
|
21
|
+
4. **Никаких самостоятельных оценок.** Тип отправки определяется на основе ревью и текста пользователя. `comment` означает обычный комментарий PR, `review-comment` — review без статуса. `approve` и `request-changes` всегда подтверждаются пользователем.
|
|
16
22
|
5. **Простой язык.** В сообщениях пользователю и комментарии PR без лишних терминов.
|
|
17
23
|
|
|
18
24
|
## Интерактивные вопросы
|
|
@@ -30,10 +36,17 @@ description: 'Отправляет ревью из `docs/reviews/...` на GitHu
|
|
|
30
36
|
`gh --version` + `gh auth status`. Если `gh` отсутствует или не авторизован — остановись, сообщи и выйди (это пользователю нужно решить).
|
|
31
37
|
|
|
32
38
|
### 2. Выбрать ревью
|
|
33
|
-
|
|
39
|
+
Сначала разбери текст рядом с вызовом:
|
|
40
|
+
- если указан путь к ревью — используй его как `$REVIEW_FILE`;
|
|
41
|
+
- если указано название ревью или часть названия — найди совпадение в `docs/reviews/`;
|
|
42
|
+
- если написано «последнее ревью» — возьми самый новый файл из `docs/reviews/`;
|
|
43
|
+
- если указан PR (`PR 12`, `#12`) — сохрани номер как целевой PR;
|
|
44
|
+
- если указан тип отправки (`comment`, `review-comment`, `approve`, `request-changes`) — сохрани его как намерение.
|
|
45
|
+
|
|
46
|
+
Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: оценку, замечания, рекомендации.
|
|
34
47
|
|
|
35
48
|
### 3. Найти целевой PR
|
|
36
|
-
|
|
49
|
+
Если номер PR указан в тексте пользователя — используй его. Иначе попробуй `gh pr view --json number,url,headRefName` — если у текущей ветки уже есть PR, возьми его номер.
|
|
37
50
|
|
|
38
51
|
Если PR нет — `AskUserQuestion`: «PR ещё нет: создать PR из текущей ветки / указать номер существующего PR / прервать». При создании используй `gh pr create` (заголовок и тело — по последним коммитам ветки).
|
|
39
52
|
|
|
@@ -41,9 +54,9 @@ description: 'Отправляет ревью из `docs/reviews/...` на GitHu
|
|
|
41
54
|
Предложи вариант на основе оценки в ревью:
|
|
42
55
|
- score ≥ 80 → предложить **approve** (с комментарием).
|
|
43
56
|
- score < 50 → предложить **request-changes**.
|
|
44
|
-
- иначе → **comment** (review без статуса).
|
|
57
|
+
- иначе → **review-comment** (review без статуса).
|
|
45
58
|
|
|
46
|
-
`AskUserQuestion`: подтвердить предложенный тип / выбрать другой / отправить как обычный комментарий PR (вне review).
|
|
59
|
+
Если тип отправки указан в тексте и это `comment` или `review-comment`, используй его без дополнительного выбора, если нет противоречий с ревью. `approve` и `request-changes` всегда подтверждай через `AskUserQuestion`, даже если они указаны inline. Если тип не указан или противоречит ревью — `AskUserQuestion`: подтвердить предложенный тип / выбрать другой / отправить как обычный комментарий PR (вне review).
|
|
47
60
|
|
|
48
61
|
### 5. Сформировать тело
|
|
49
62
|
Структура комментария:
|
package/package.json
CHANGED