Поточная разработка с AI-агентами — на русском языке. Набор готовых скилов для Claude Code и Codex CLI, которые ведут тебя через весь цикл: от исследования до коммита.
eda — это тринадцать скилов, каждый отвечает за свой кусок работы. Вместо того чтобы каждый раз объяснять модели, как делать ревью или как исполнять план, ты говоришь одно слово — и она следует чёткой инструкции на русском, со всеми правилами, проверками и артефактами в нужных папках.
npm install -g @gian-tiaga/edaВ корне твоего проекта:
eda initУстановщик покажет чекбоксы: стрелками выбираешь среду, пробелом отмечаешь, Enter продолжает. Можно поставить Claude Code, Codex CLI или обе среды сразу. Если docs/settings.yaml ещё нет, установщик также предложит выбрать настройки скилов и создаст этот файл. В конце 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, при желании — релевантное исследование. В плане явно фиксирует контракты БД/API, если задача их затрагивает. Затем три параллельных субагента/модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить |
docs/plans/ |
eda-execute |
Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | docs/executions/ |
eda-fix |
Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | docs/fixes/ |
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) |
eda-worktree |
Создаёт git worktree рядом с основным проектом в папке {name}-work-{n} и одноимённую ветку. Базу берёт из аргумента или спрашивает |
соседняя папка {name}-work-{n} |
eda-merge-worktree |
Мержит ветку из соседнего worktree в текущую ветку. Принимает номер 1, короткое имя work-1 или полное имя {name}-work-1. Worktree и ветку после merge не удаляет |
(git) |
eda-docs |
Создаёт или обновляет docs/rules.md (максимально строгие правила для твоего стека), docs/arch.md (архитектура проекта) и шапку AGENTS.md. Может предлагать инструменты, которых ещё нет в проекте |
docs/rules.md, docs/arch.md, AGENTS.md |
eda-automate |
Анализирует историю ревью и фиксов. Если какое-то замечание встречается раз за разом — предлагает кастомное правило линтера или статанализатора, чтобы ловить это автоматически | docs/automations/ |
У некоторых скилов есть флаг strict — он включает дополнительные тяжёлые проверки. Передаётся как часть запроса агенту, например: eda-explore strict <тема> или просто сделай ревью этого PR в strict-режиме. Также strict можно включить по умолчанию через defaults.strict: true в docs/settings.yaml.
Скилы, которых нет в таблице ниже, флагов не поддерживают — у них всё включено по умолчанию.
| Скил | Флаг | Что включает | Когда стоит использовать |
|---|---|---|---|
eda-explore |
strict |
После сохранения отчёта отдаёт его соседнему CLI (Claude → Codex или наоборот) на критическое ревью конкретности, фактов, развилок, рисков и версий; затем доправляет отчёт по замечаниям | Серьёзные исследования, которые лягут в основу больших решений; когда хочется второго мнения от другой модели/среды |
eda-plan |
strict |
После обычного мета-ревью трёх субагентов/моделей отдаёт план соседнему CLI на дополнительный круг проверки; доправляет план | Большие или ответственные планы, особенно затрагивающие смежные системы |
eda-review |
strict |
После обычного мета-ревью специализированными субагентами отдаёт ревью соседнему CLI на дополнительный круг проверки; доправляет ревью по его замечаниям | Ревью важных PR; когда нужен максимальный охват |
Скилы читают docs/settings.yaml, если файл есть. Прямое указание в текущем запросе важнее настроек: например, strict включает строгий режим для одного запуска, а normal / без strict выключает его. Для eda-plan явный short включает короткий план, а normal / обычный план — обычный.
Файл по умолчанию:
version: 1
defaults:
# Включает strict-режим по умолчанию для eda-explore, eda-plan и eda-review.
# true | false
strict: false
# Задаёт размер плана по умолчанию для eda-plan.
# normal | short | ask_each_time
plan_size: normal
# Определяет, как eda-explore ведёт исследовательские развилки, а eda-plan принимает существенные решения.
# autonomous | recommend_and_ask | ask_each_time
decision_mode: recommend_and_ask
# Задаёт стратегию тестов по умолчанию для eda-plan.
# after_each_phase | tdd_each_phase | end_of_plan | ask_each_time
test_strategy: ask_each_time
# Задаёт стратегию логирования по умолчанию для eda-plan.
# debug_precise | standard | ask_each_time
logging_strategy: ask_each_time
automate:
# Добавляет docs/plans/ в обычный запуск eda-automate.
# true | false
include_plans: false
review:
# Добавляет в eda-review проверку качества кода и meta-reviewer quality-check.
# true | false
include_code_quality: trueЧто означают настройки:
defaults.strict— включает strict-режим по умолчанию дляeda-explore,eda-planиeda-review.defaults.plan_size— размер плана дляeda-plan:normal,shortилиask_each_time.defaults.decision_mode— какeda-exploreведёт исследовательские развилки, аeda-planпринимает существенные решения:autonomousвыбирает сам,recommend_and_askрекомендует и спрашивает по значимым развилкам,ask_each_timeспрашивает по каждой развилке, которая влияет на ход работы или итоговый выбор.defaults.test_strategy— стратегия тестов дляeda-plan:after_each_phase,tdd_each_phase,end_of_planилиask_each_time.defaults.logging_strategy— стратегия логирования дляeda-plan:debug_precise,standardилиask_each_time.automate.include_plans— добавляетdocs/plans/в обычный запускeda-automate.review.include_code_quality— добавляет вeda-reviewпроверку качества кода и отдельного мета-ревьюераquality-check.
eda init и eda update создают docs/settings.yaml, только если файла ещё нет. Существующий файл не перезаписывается.
docs ───────────────┬───────────────┐
│ │
v v
roadmap ────────> explore ─────> plan ───> execute ───┬──> review ───> fix-by-review ───┬──> send-review
│ │ │
└──────────────> plan v └──> commit
fix ─────────────> review
automate может запускаться от review, fix-by-review или fix.
Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с eda-roadmap, eda-explore, или сразу с eda-execute на готовом плане, или просто eda-commit, когда правки уже сделаны. Для параллельной работы есть eda-worktree, а для возврата ветки из worktree в текущую ветку — eda-merge-worktree.
- Простой язык. Скилы общаются с тобой так, чтобы понял человек без глубоких знаний предмета. Термины — только когда без них нельзя.
- Все вопросы — интерактивно. В Claude Code — через
AskUserQuestion; в интерактивном Codex — черезrequest_user_inputили блокирующий вопрос в чат. Вcodex execи других неинтерактивных запусках скил не имитирует диалог: если без ответа нельзя безопасно продолжать, он завершает работу со статусомblocked: нужен ответ пользователя. - Мета-проверки — через субагентов. В интерактивном Codex обычные проверки планов и ревью запускаются через
spawn_agentили аналогичный инструмент субагентов. Отдельныйcodex execостаётся fallback для неинтерактивного режима и механизмом strict-кросс-проверки соседним CLI. - Артефакты по папкам. Исследования отдельно, планы отдельно, ревью отдельно. Между файлами — ссылки. Через месяц легко найти, кто что когда решал.
- Границы между скилами жёсткие.
executeне коммитит — это работаcommit.reviewне правит код — этоfix-by-review. Никаких размытых ответственностей. - Доверие модели. Скилы короткие. Они говорят «что» и «почему», а «как именно» — модель разбирается сама.
eda init # выбрать Claude Code / Codex / обе среды и установить скилы
eda update # обновить скилы, показать реально изменившиеся и создать docs/settings.yaml, если его ещё нет
eda --version # показать версию установленного пакета
eda --help # справкаКогда выходит новая версия пакета:
npm update -g @gian-tiaga/eda # подтянуть новый код
eda update # синхронизировать скилы в текущем проектеИсходники скилов в этом пакете лежат в skills/. Установщик читает именно эту папку и копирует каждый <skill>.md в формат <skill>/SKILL.md для выбранной среды.
| Среда | Куда |
|---|---|
| Claude Code | <project>/.claude/skills/<skill>/SKILL.md — отдельная папка на каждый скил |
| Codex CLI | <project>/.codex/skills/<skill>/SKILL.md — отдельная папка на каждый скил |
eda update идемпотентно перезаписывает файлы в обеих папках и в конце пишет только те скилы, содержимое которых реально изменилось относительно установленной копии. При обновлении старые файлы Codex-формата <project>/.codex/skills/<skill>.md, созданные версиями eda до этой структуры, удаляются. Если ты хочешь подправить скил локально — лучше копию сделай рядом, а не прямо в .claude/skills/ или .codex/skills/, иначе при следующем update твои правки потеряются.
AGENTS.md (как и любые другие файлы в корне проекта) установщик не трогает. Если хочешь, чтобы Codex автоматически подгружал скилы, дай ему знать сам — например, одной строкой в AGENTS.md: «следуй инструкциям из .codex/skills/».
- Для тех, кто постоянно пишет код с AI-агентом и устал каждый раз заново объяснять, как делать ревью.
- Для команд, где хочется единый стандарт работы с агентами — чтобы ревью у всех было пронумеровано и оценено, планы лежали в одной папке, а коммиты были по одному стилю.
- Для разработчиков, которые любят строгость: максимально жёсткие правила, обязательные тесты, мета-проверки ревью несколькими моделями, кросс-проверка через соседний CLI.
MIT.
Используй, форкай, переписывай под себя. Будет здорово, если поделишься улучшениями обратно.