@gian-tiaga/eda 0.6.2 → 0.8.0

package/skills/eda-roadmap.md

@@ -7,13 +7,6 @@ description: 'Создаёт roadmap-файл по продуктовой или
 
 Создаёшь roadmap: список будущих задач по продуктовой или технической теме. Roadmap отвечает на вопрос «что нужно сделать и зачем», но не отвечает «как именно реализовывать».
 
-## Режимы вызова
-
-| Режим | Запуск | Что делает |
-|---|---|---|
-| Обычный | `eda-roadmap <тема>` | Создаёт roadmap-файл в `docs/roadmaps/`. |
-| Из текста | `eda-roadmap <список идей или требований>` | Нормализует вход в ясный список задач без деталей реализации. |
-
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, цель, аудиторию, ограничения, примерный горизонт roadmap, уже названные задачи и прямые указания.
@@ -62,22 +55,9 @@ description: 'Создаёт roadmap-файл по продуктовой или
 
 ### 3. Сформировать задачи
 
-Собери задачи в список. Для каждой задачи:
-- дай короткое название;
-- добавь 1–2 предложения описания, если без них задача может быть понята по-разному;
-- опиши результат на уровне поведения или возможности, а не реализации;
-- не добавляй подзадачи с техническими шагами;
-- не добавляй оценки сроков, если пользователь не просил.
-
-Хорошие формулировки:
-- «Аутентификация через email, ВК и Яндекс. Пользователь может войти удобным способом и восстановить доступ без обращения в поддержку.»
-- «Личный кабинет пользователя. Пользователь видит свои данные, статус подписки и основные действия по аккаунту в одном месте.»
-- «Базовая модерация контента. Команда может скрывать спорные материалы и видеть причину модерационного решения.»
-
-Плохие формулировки:
-- «Подключить `passport-yandex`, добавить callback route и таблицу OAuth-профилей.»
-- «Создать `auth.service.ts`, миграцию и e2e-тесты.»
-- «Реализовать через Redis и очередь фоновых задач.»
+Собери список задач. Для каждой дай короткое название, 1–2 предложения описания при необходимости и результат на уровне поведения или возможности, а не реализации. Не добавляй технические подзадачи и оценки сроков, если пользователь не просил.
+
+Хорошо: «Аутентификация через email, ВК и Яндекс. Пользователь может войти удобным способом и восстановить доступ без обращения в поддержку.» Плохо: «Подключить `passport-yandex`, добавить callback route и таблицу OAuth-профилей.»
 
 ### 4. Сохранить файл
 

package/skills/eda-send-review.md

@@ -36,12 +36,7 @@ description: 'Отправляет ревью из `docs/reviews/...`, выбр
 `gh --version` + `gh auth status`. Если `gh` отсутствует или не авторизован — остановись, сообщи и выйди (это пользователю нужно решить).
 
 ### 2. Выбрать ревью
-Сначала разбери текст рядом с вызовом:
-- если указан путь к ревью — используй его как `$REVIEW_FILE`;
-- если указано название ревью или часть названия — найди совпадение в `docs/reviews/`;
-- если написано «последнее ревью» — возьми самый новый файл из `docs/reviews/`;
-- если указан PR (`PR 12`, `#12`) — сохрани номер как целевой PR;
-- если указан тип отправки (`comment`, `review-comment`, `approve`, `request-changes`) — сохрани его как намерение.
+Сначала разбери текст рядом с вызовом: путь к ревью, название или часть названия, «последнее ревью», PR (`PR 12`, `#12`) и тип отправки (`comment`, `review-comment`, `approve`, `request-changes`).
 
 Если найдено ровно одно ревью — продолжай без вопроса. Если найдено несколько одинаково подходящих ревью — `AskUserQuestion` со списком вариантов. Если входа нет — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Если `docs/reviews/` отсутствует или пуста — остановись с понятным вопросом или статусом `blocked: нужно ревью`. Прочитай файл целиком: оценку, замечания, рекомендации.
 
@@ -51,10 +46,7 @@ description: 'Отправляет ревью из `docs/reviews/...`, выбр
 Если PR нет — `AskUserQuestion`: «PR ещё нет: создать PR из текущей ветки / указать номер существующего PR / прервать». При создании используй `gh pr create` (заголовок и тело — по последним коммитам ветки).
 
 ### 4. Выбрать тип отправки
-Предложи вариант на основе оценки в ревью:
-- score ≥ 80 → предложить **approve** (с комментарием).
-- score < 50 → предложить **request-changes**.
-- иначе → **review-comment** (review без статуса).
+Предложи вариант по оценке: score ≥ 80 → **approve** с комментарием; score < 50 → **request-changes**; иначе → **review-comment**.
 
 Если тип отправки указан в тексте и это `comment` или `review-comment`, используй его без дополнительного выбора, если нет противоречий с ревью. `approve` и `request-changes` всегда подтверждай через `AskUserQuestion`, даже если они указаны inline. Если тип не указан или противоречит ревью — `AskUserQuestion`: подтвердить предложенный тип / выбрать другой / отправить как обычный комментарий PR (вне review).
 

package/skills/eda-start.md

@@ -0,0 +1,226 @@
+---
+name: eda-start
+description: 'Помогает стартовать новый проект: собирает требования, критерии MVP, ограничения и риски; вместе с пользователем выбирает стек, архитектуру, инструменты качества кода, AI-скилы, агентные инструкции, MCP-серверы и правила проекта. Для библиотек, CLI, сервисов и MCP проверяет актуальные стабильные версии по официальным источникам, если они не заданы. Не пишет код и не устанавливает зависимости: сохраняет согласованный стартовый документ в docs/project-starts/ и черновики docs/rules.md / docs/arch.md / AGENTS.md, если пользователь это подтвердил.'
+---
+
+# Скил: Старт проекта (eda-start)
+
+Помогаешь начать новый проект с понятной рамкой: что делаем, для кого, на каком стеке, с какой архитектурой, какими проверками качества, какими AI-скилами и MCP-серверами, и какие правила сразу внедряем. Работаешь как технический партнёр: сначала собираешь факты, затем рекомендуешь варианты и принимаешь решения вместе с пользователем.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: идею проекта, продуктовую цель, аудиторию, ограничения, сроки, предпочтения по стеку, инфраструктуре, бюджету, команде, требованиям к качеству, безопасности и эксплуатации.
+
+Если входа достаточно для первого анализа, не спрашивай подтверждение самой темы, но всё равно задай вопросы по значимым стартовым решениям. `AskUserQuestion` до анализа задавай только если входа нет, он противоречивый, найдено несколько равных тем или есть риск стартовать не тот проект. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Интерактивное совместное решение обязательно.** Нельзя молча выбрать стек, архитектуру, правила, MCP или инструменты качества, если это значимо влияет на проект.
+2. **Не пишешь код и не ставишь пакеты.** Запись только в `docs/project-starts/` и, после явного подтверждения пользователя, в `docs/rules.md`, `docs/arch.md`, `AGENTS.md`.
+3. **Требования раньше стека.** Сначала выясни продукт, пользователей, MVP, ограничения, данные, интеграции, безопасность, эксплуатацию и команду. Только после этого выбирай стек.
+4. **Стек подбирается под задачу.** Не навязывай любимые технологии. Для каждого ключевого выбора дай 2–3 реалистичных варианта, рекомендацию и причину.
+5. **Инструменты качества обязательны для выбранного стека.** Подбери форматтер, линтер, статанализатор/typecheck, тестовый стек, coverage, dependency/security audit, pre-commit и CI-проверки, если они есть и уместны в выбранной экосистеме.
+6. **MCP и скилы — только по делу.** Рекомендуй MCP-сервер или скил, когда он закрывает реальную нехватку контекста, интеграцию, повторяемый процесс или качество агентной работы.
+7. **Версии проверяй.** Если предлагаешь пакеты, CLI, фреймворки, сервисы или MCP-серверы, а версия не зафиксирована пользователем, проверь актуальную стабильную версию через context7, если он доступен, или через web search по официальным источникам.
+8. **Архитектура должна быть объяснима.** Выбранная архитектура обязана соответствовать масштабу MVP, рискам, команде и будущему росту. Не предлагай сложность без причины.
+9. **Правила должны быть применимы.** Каждое правило должно отвечать на конкретный риск проекта и иметь понятную проверку: автоматическую, ревью-проверку или договорённость в `docs/rules.md`.
+10. **Простой язык. Таблицы** используй для сравнений стека, инструментов, MCP, скилов, правил и архитектурных вариантов.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+Вопросы задавай пакетами по 1–3 за раз. Сначала спрашивай только то, без чего следующий шаг будет гаданием. После каждого пакета используй ответ, обновляй рекомендацию и продолжай.
+
+## Этапы
+
+### 1. Собрать требования
+
+Собери и зафиксируй:
+- цель проекта и аудиторию;
+- MVP и что точно не входит в первую версию;
+- основные пользовательские сценарии;
+- типы данных, чувствительные данные, персональные данные и требования к хранению;
+- интеграции, платежи, auth, уведомления, файлы, поиск, аналитика, админку;
+- нагрузку, SLA, бюджет, сроки, размер команды и опыт команды;
+- платформы: web, mobile, desktop, API, CLI, bot, internal tool;
+- ограничения по хостингу, лицензиям, vendor lock-in, compliance и региону.
+
+Если не хватает критичных требований, задай `AskUserQuestion` и остановись до ответа.
+
+### 2. Выбрать стек
+
+Сравни 2–3 подходящих варианта стека. Для каждого укажи:
+- где он силён для этого проекта;
+- главный риск;
+- стоимость внедрения и поддержки;
+- зрелость экосистемы;
+- совместимость с командой и MVP.
+
+Рекомендуй один вариант. Если пользователь не дал режим «сам выбирай», задай `AskUserQuestion`: принять рекомендацию / выбрать альтернативу / сузить требования и пересчитать выбор.
+
+Для выбранного стека зафиксируй конкретные версии основных компонентов или источник версии: runtime, framework, БД, ORM, тестовый фреймворк, build tool, package manager, контейнеры и ключевые сервисы.
+
+### 3. Подобрать инструменты качества
+
+Для выбранного стека подбери инструменты с обоснованием:
+- форматирование кода;
+- линтеры;
+- статический анализ и typecheck;
+- unit/integration/e2e/contract-тесты;
+- coverage;
+- dependency audit и security scan;
+- schema/API validation;
+- миграции БД и проверки миграций;
+- pre-commit hooks;
+- CI pipeline;
+- генераторы типов или клиентов, если API/схемы это требуют.
+
+Не предлагай инструмент, если он дублирует уже выбранный инструмент того же класса без явной пользы. Если в экосистеме есть несколько нормальных вариантов, сравни их и выбери один.
+
+### 4. Выбрать архитектуру
+
+Предложи 2–3 архитектурных варианта, соответствующих выбранному стеку и масштабу:
+- простой монолит / modular monolith;
+- API + frontend;
+- event-driven части;
+- serverless;
+- mobile-first / offline-first;
+- plugin/module architecture;
+- другой вариант, если он лучше подходит.
+
+Для каждого варианта покажи границы модулей, поток данных, риски и что будет сложно менять позже. Рекомендуй один вариант и задай `AskUserQuestion`, если выбор влияет на стоимость, сроки, масштабирование, данные или команду.
+
+### 5. Решить правила проекта
+
+Сформируй набор правил, которые стоит внедрить с первого дня:
+- структура проекта и границы модулей;
+- стиль кода и naming;
+- работа с ошибками и логированием;
+- тестовая стратегия;
+- миграции и данные;
+- API-контракты;
+- безопасность и секреты;
+- доступность и UX, если есть UI;
+- observability;
+- работа с AI-агентами, планами, ревью и коммитами;
+- политика зависимостей и обновлений.
+
+Для каждого правила укажи: какой риск оно закрывает, как проверяется, где будет зафиксировано. Затем спроси пользователя, какие правила принять сейчас, какие оставить предложениями и какие убрать.
+
+### 6. Подобрать AI-скилы, агентные инструкции и MCP
+
+Подбирай рабочий набор AI-инструментов только после требований, стека, инструментов качества, архитектуры и правил. Эти решения задают контекст: какие источники нужны агенту, какие проверки уже закрыты кодовыми инструментами, где нужны отдельные роли и какие права доступа допустимы.
+
+Подбери:
+- какие AI-скилы, slash-команды, агентные инструкции или специализированные роли нужны сразу: старт проекта, продуктовый discovery, планирование, исполнение задач, ревью, security review, проверка доступности, работа с документацией, релизный процесс, domain-expert по предметной области;
+- какие готовые скилы можно взять из доступных наборов, включая `eda-*`, Claude/Codex skills, командные инструкции репозитория или публичные каталоги, если они подходят;
+- какие проектные скилы стоит написать специально под этот проект: например для доменной модели, архитектурных границ, API-контрактов, миграций, дизайн-системы, ревью UI, работы с данными или внутренними интеграциями;
+- какие скилы и агентные роли отложить до появления кода, команды или повторяющейся проблемы;
+- какие MCP-серверы помогут агенту: файловая система, GitHub/GitLab, Postgres/SQLite, браузер, Playwright, Figma, документация, API-клиенты, issue tracker, cloud provider;
+- какие MCP не нужны, потому что выбранная архитектура, правила или инструменты качества уже закрывают задачу.
+
+Для каждого скила или агентной инструкции укажи: какую работу закрывает, кто запускает, на каких источниках должен основываться, какой артефакт создаёт, чем проверять результат и почему обычного промпта недостаточно. Не ограничивайся `eda-*`: они только один из возможных источников.
+
+Для каждого MCP укажи: зачем он нужен именно при выбранной архитектуре и правилах, какие данные откроет агенту, риски доступа, минимальные права и когда подключать. MCP с доступом к продакшену, секретам, платежам или персональным данным не включай по умолчанию: вынеси на отдельное подтверждение.
+
+### 7. Сохранить стартовый документ
+
+Сохрани стартовый документ в `docs/project-starts/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
+
+Формат:
+
+```markdown
+---
+title: <заголовок>
+date: <YYYY-MM-DD HH:MM>
+status: draft
+sources:
+  existing_rules: <путь или —>
+  existing_arch: <путь или —>
+---
+
+# Старт проекта
+
+## Требования
+<цель, аудитория, MVP, ограничения, не входит>
+
+## Принятые решения
+| Область | Решение | Почему | Подтверждение |
+|---|---|---|---|
+| Стек | ... | ... | ответ пользователя / рекомендация принята |
+
+## Стек
+| Компонент | Выбор | Версия / источник | Обоснование |
+|---|---|---|---|
+
+## Инструменты качества
+| Класс | Инструмент | Где запускать | Почему |
+|---|---|---|---|
+
+## Архитектура
+<выбранный вариант, границы модулей, поток данных, важные ограничения>
+
+## Правила
+| Правило | Риск | Проверка | Статус |
+|---|---|---|---|
+
+## AI-скилы и агентные инструкции
+| Скил / инструкция | Источник | Когда использовать | Артефакт | Почему |
+|---|---|---|---|---|
+
+## MCP
+| MCP | Когда подключать | Права доступа | Риски |
+|---|---|---|---|
+
+## Открытые вопросы
+- <если есть>
+
+## Следующие шаги
+1. <создать/обновить docs/rules.md>
+2. <создать/обновить docs/arch.md>
+3. <запустить eda-plan для первого инкремента>
+```
+
+Quality gate перед сохранением:
+- есть требования и границы MVP;
+- выбран один основной стек, а не список равных вариантов;
+- инструменты качества покрывают форматирование, lint/static analysis/typecheck, тесты и CI или объясняют, почему часть не нужна;
+- выбрана архитектура и описаны границы;
+- правила имеют риск и способ проверки;
+- есть список AI-скилов, агентных инструкций или ролей с назначением, источником и артефактом, подобранный под выбранную архитектуру и правила;
+- MCP-серверы имеют обоснование, права и риски, связанные с выбранной архитектурой, данными и интеграциями;
+- все значимые решения имеют подтверждение пользователя или явно помечены как автономная рекомендация;
+- версии пакетов/ПО проверены или объяснено, почему это не требуется.
+
+### 8. Создать черновики правил и архитектуры
+
+После сохранения стартового документа спроси `AskUserQuestion`: создать черновики `docs/rules.md`, `docs/arch.md` и `AGENTS.md` сейчас / только стартовый документ / выбрать отдельные документы.
+
+Если пользователь подтвердил:
+- не перезаписывай существующие файлы молча;
+- для каждого существующего файла спроси: дополнить / создать рядом / оставить как есть;
+- в `docs/rules.md` перенеси только принятые правила, а предложения оставь отдельным разделом;
+- в `docs/arch.md` перенеси выбранную архитектуру, границы модулей, поток данных, данные и интеграции;
+- в `AGENTS.md` добавь краткую карту проекта и ссылки на `docs/rules.md`, `docs/arch.md`, стартовый документ и команды проверки.
+
+Если пользователь отказался, не создавай эти файлы и запиши отказ в финале.
+
+### 9. Финал
+
+Короткое сообщение: путь к стартовому документу, какие решения приняты, какие документы созданы или не созданы, какие вопросы остались открытыми, какой следующий скил логично использовать (`eda-plan` для первого инкремента или `eda-docs` для доработки правил и архитектуры).
+
+## Чего НЕ делать
+
+- Создавать приложение, писать код, миграции, конфиги, CI или устанавливать зависимости.
+- Выбирать стек до требований.
+- Давать один вариант без объяснения альтернатив, если решение значимое.
+- Ставить MCP по умолчанию с широкими правами доступа.
+- Подменять линтеры, статанализаторы, typecheck и тесты агентными проверками.
+- Внедрять правила без согласия пользователя.
+- Перезаписывать существующие `docs/rules.md`, `docs/arch.md` или `AGENTS.md` без отдельного подтверждения.
+- Сохранять стартовый документ куда-либо кроме `docs/project-starts/`.

package/skills/eda-worktree.md

@@ -7,13 +7,6 @@ description: 'Создаёт новый git worktree рядом с основн
 
 Создаёшь отдельный git worktree для параллельной работы. Worktree всегда появляется рядом с основным проектом, а имя выбирается автоматически.
 
-## Режимы вызова
-
-| Режим | Запуск | Что делает |
-|---|---|---|
-| С выбранной базой | `eda-worktree main` | Создаёт worktree от указанной ветки, тега или commit-ref |
-| С вопросом | `eda-worktree` | Спрашивает, от какой базы создать worktree |
-
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: базовую ветку или ref, ограничения и прямые указания.
@@ -50,10 +43,7 @@ git worktree list --porcelain
 
 Если это не git-репозиторий — остановись и сообщи. Основной worktree бери из первой записи `worktree <path>` в `git worktree list --porcelain`. Если список не удалось прочитать, используй `git rev-parse --show-toplevel`.
 
-Определи:
-- `$MAIN_WORKTREE` — путь основного worktree;
-- `$PROJECT_NAME` — basename от `$MAIN_WORKTREE`;
-- `$PROJECT_PARENT` — родительская папка `$MAIN_WORKTREE`.
+Определи `$MAIN_WORKTREE` — путь основного worktree, `$PROJECT_NAME` — basename от него, `$PROJECT_PARENT` — родительская папка.
 
 ### 2. Выбрать базу
 
@@ -86,10 +76,7 @@ git rev-parse --verify "$BASE_REF^{commit}"
 git show-ref --verify --quiet "refs/heads/$BRANCH_NAME"
 ```
 
-Результат:
-- `$WORKTREE_NAME=$PROJECT_NAME-work-$n`;
-- `$BRANCH_NAME=$WORKTREE_NAME`;
-- `$WORKTREE_PATH=$PROJECT_PARENT/$WORKTREE_NAME`.
+Результат: `$WORKTREE_NAME=$PROJECT_NAME-work-$n`, `$BRANCH_NAME=$WORKTREE_NAME`, `$WORKTREE_PATH=$PROJECT_PARENT/$WORKTREE_NAME`.
 
 Если папка уже есть, не перезаписывай её и не удаляй. Просто бери следующий номер.