@gian-tiaga/eda 0.8.5 → 1.0.0

package/skills/eda-start.md

@@ -1,233 +0,0 @@
----
-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. **Версии пакетов проверяй всегда.** Если предлагаешь npm/pip/gem/cargo/go/composer-пакет или пакет из другой экосистемы, найди последнюю стабильную версию через context7, если он доступен, или через web search по официальной документации, registry, release notes или репозиторию проекта. Не пиши `latest` без конкретной версии и источника. Если пользователь явно зафиксировал другую версию, не меняй её молча: покажи текущую стабильную, зафиксированную пользователем и причину расхождения.
-8. **Версии ПО тоже проверяй.** Если предлагаешь CLI, фреймворки, сервисы или MCP-серверы, а версия не зафиксирована пользователем, проверь актуальную стабильную версию через context7, если он доступен, или через web search по официальным источникам.
-9. **Архитектура должна быть объяснима.** Выбранная архитектура обязана соответствовать масштабу MVP, рискам, команде и будущему росту. Не предлагай сложность без причины.
-10. **Правила должны быть применимы.** Каждое правило должно отвечать на конкретный риск проекта и иметь понятную проверку: автоматическую, ревью-проверку или договорённость в `docs/rules.md`.
-11. **Простой язык. Таблицы** используй для сравнений стека, инструментов, 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, контейнеры и ключевые сервисы.
-
-Для каждого выбранного пакета отдельно зафиксируй:
-- последнюю стабильную версию;
-- источник версии и дату проверки;
-- если версия зафиксирована пользователем и отличается от последней стабильной — обе версии и причину, почему остаёмся на pinned-версии или почему предлагаем обновление.
-
-### 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

@@ -1,113 +0,0 @@
----
-name: eda-worktree
-description: 'Создаёт новый git worktree рядом с основным проектом в папке `{name}-work-{n}` и одноимённую ветку. Базовую ветку берёт из текста рядом с вызовом, если она указана, иначе спрашивает интерактивно. Не правит код, не коммитит, не мержит обратно. В финале показывает путь worktree, имя ветки и команду перехода в новую папку.'
----
-
-# Скил: Создатель worktree (eda-worktree)
-
-Создаёшь отдельный git worktree для параллельной работы. Worktree всегда появляется рядом с основным проектом, а имя выбирается автоматически.
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: базовую ветку или ref, ограничения и прямые указания.
-
-Если вход содержит ветку, tag, commit hash или выражение вроде `от main` / `from main` / `base main`, используй это как `$BASE_REF`. Если входа нет или база не указана, спроси через `AskUserQuestion`. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Только git worktree.** Не правь код, docs, конфиги и зависимости.
-2. **Имя строго по шаблону.** Папка и ветка называются `{name}-work-{n}`, где `{name}` — имя папки основного worktree проекта, а `{n}` — первый свободный положительный номер.
-3. **Папка рядом с основным проектом.** Если основной worktree лежит в `/path/app`, новый путь: `/path/app-work-1`, `/path/app-work-2` и так далее.
-4. **Базу не додумывай молча.** Если пользователь не указал `$BASE_REF`, спроси интерактивно.
-5. **Не удаляй и не мержь.** Этот скил только создаёт worktree. Обратный merge — `eda-merge-worktree`.
-6. **Простой язык** в сообщениях пользователю.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале.
-
-## Этапы
-
-### 1. Проверить git-репозиторий
-
-Выполни:
-
-```bash
-git rev-parse --show-toplevel
-git worktree list --porcelain
-```
-
-Если это не git-репозиторий — остановись и сообщи. Основной worktree бери из первой записи `worktree <path>` в `git worktree list --porcelain`. Если список не удалось прочитать, используй `git rev-parse --show-toplevel`.
-
-Определи `$MAIN_WORKTREE` — путь основного worktree, `$PROJECT_NAME` — basename от него, `$PROJECT_PARENT` — родительская папка.
-
-### 2. Выбрать базу
-
-Если `$BASE_REF` указан в сообщении пользователя, проверь его:
-
-```bash
-git rev-parse --verify "$BASE_REF^{commit}"
-```
-
-Если ref не найден — остановись и сообщи, что база не существует.
-
-Если `$BASE_REF` не указан, спроси через `AskUserQuestion`, откуда создавать worktree. Предлагай реальные варианты:
-- текущая ветка или `HEAD`;
-- default branch из `origin/HEAD`, если она есть;
-- `main` или `master`, если такая ветка существует.
-
-Если пользователь выбирает свой ref, проверь его через `git rev-parse --verify "$BASE_REF^{commit}"`.
-
-Если текущий worktree содержит незакоммиченные изменения, коротко предупреди: они не попадут в новый worktree. Это не блокер, если база выбрана явно или подтверждена через вопрос.
-
-### 3. Найти свободное имя
-
-Начиная с `n = 1`, найди первый номер, для которого одновременно свободны:
-- соседняя папка `$PROJECT_PARENT/$PROJECT_NAME-work-$n`;
-- локальная ветка `$PROJECT_NAME-work-$n`.
-
-Проверяй ветку так:
-
-```bash
-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`.
-
-Если папка уже есть, не перезаписывай её и не удаляй. Просто бери следующий номер.
-
-### 4. Создать worktree
-
-Выполни:
-
-```bash
-git worktree add -b "$BRANCH_NAME" "$WORKTREE_PATH" "$BASE_REF"
-```
-
-Если команда упала, покажи понятную причину и не пытайся чистить вручную. Если ошибка говорит, что ветка или папка уже существует, вернись к шагу 3 и выбери следующий номер.
-
-### 5. Финал
-
-Короткое сообщение:
-- созданный путь worktree;
-- имя ветки;
-- выбранная база;
-- готовая команда:
-
-```bash
-cd "$WORKTREE_PATH"
-```
-
-Напомни, что обратный merge выполняет `eda-merge-worktree <n>` или `eda-merge-worktree work-<n>`.
-
-## Чего НЕ делать
-
-- Править файлы проекта.
-- Создавать docs-артефакты.
-- Коммитить, пушить, мержить.
-- Удалять существующие worktree, ветки или папки.
-- Создавать worktree внутри текущего проекта вместо соседней папки.