@gian-tiaga/eda 0.2.10 → 0.3.1

package/docs/skills/eda-automate.md

@@ -16,7 +16,7 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
 
 ## Главные правила
 
-1. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть. Не предлагай то, что уже зафиксировано как автоматизированное правило.
+1. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им. Не предлагай то, что уже зафиксировано как автоматизированное правило или архитектурное решение.
 2. **Интерактивные вопросы** — по разделу ниже.
 3. **Не внедряешь изменения.** Только отчёт с предложениями. Внедрение автоматизаций или правок `docs/rules.md`/`docs/arch.md` — через `eda-plan` + `eda-execute`.
 4. **Предлагай только повторяющееся.** Минимум — паттерн встречается в 2+ разных ревью или в 3+ местах одного. Единичные замечания не автоматизируем.
@@ -49,7 +49,7 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
 ### 2. Прочитать контекст
 - Все выбранные ревью, отчёты о фиксах по ревью и обычные фиксы.
 - В режиме `plans`: все выбранные планы из `docs/plans/`.
-- `docs/rules.md`, `docs/arch.md` (если есть).
+- `docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им.
 - Какие языки и фреймворки в проекте — определи сам.
 - Какие инструменты статанализа уже установлены и работают — определи по конфигам и зависимостям проекта.
 

package/docs/skills/eda-commit.md

@@ -1,6 +1,6 @@
 ---
 name: eda-commit
-description: 'Формирует коммит из незакоммиченных изменений в стиле проекта (по docs/rules.md или истории), включая связанные артефакты из `docs/**`, которые создали скилы. Коммитит без `--no-verify`. В конце спрашивает интерактивно: push (если есть remote) / merge в main + переключение + удаление ветки (если не в main) / ничего. Не правит логику кода, не пишет тесты — это `eda-execute`, `eda-fix` или `eda-fix-by-review`.'
+description: 'Формирует коммит из незакоммиченных изменений в стиле проекта: читает docs/rules.md и docs/arch.md, строго следует им и истории коммитов, включая связанные артефакты из `docs/**`, которые создали скилы. Коммитит без `--no-verify`. В конце спрашивает интерактивно: push (если есть remote) / merge в main + переключение + удаление ветки (если не в main) / ничего. Не правит логику кода, не пишет тесты — это `eda-execute`, `eda-fix` или `eda-fix-by-review`.'
 ---
 
 # Скил: Коммитер (eda-commit)
@@ -13,8 +13,9 @@ description: 'Формирует коммит из незакоммиченны
 2. **Не правишь логику кода и не пишешь тесты.** Если на этапе коммита что-то не работает (упал hook, обнаружились сырые правки) — спроси через `AskUserQuestion`, не «допиливай» молча.
 3. **Pre-commit / pre-push hooks не отключай.** Никаких `--no-verify`. Hook упал → правим причину → новый коммит (не `--amend`).
 4. **Один логический коммит за вызов.** Если в diff видишь явно разные изменения — спроси через `AskUserQuestion`, разделить на несколько коммитов или коммитить одним.
-5. **Не пропускай `docs/**`.** Планы, исследования, журналы, ревью, отчёты о фиксах, автоматизации, `docs/rules.md` и `docs/arch.md`, созданные или обновлённые скилами, — часть изменения. Если они относятся к текущей задаче, добавляй их в коммит вместе с кодом.
-6. **Простой язык** в сообщениях пользователю.
+5. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе файлов, сообщении коммита и дальнейших действиях.
+6. **Не пропускай `docs/**`.** Планы, исследования, журналы, ревью, отчёты о фиксах, автоматизации, `docs/rules.md` и `docs/arch.md`, созданные или обновлённые скилами, — часть изменения. Если они относятся к текущей задаче, добавляй их в коммит вместе с кодом.
+7. **Простой язык** в сообщениях пользователю.
 
 ## Интерактивные вопросы
 
@@ -28,7 +29,7 @@ description: 'Формирует коммит из незакоммиченны
 ## Этапы
 
 ### 1. Посмотреть состояние
-`git status`, `git diff --stat`, `git log -5 --oneline` — определи стиль коммитов проекта по последним коммитам. Смотри и tracked, и untracked файлы.
+`git status`, `git diff --stat`, `git log -5 --oneline`, `docs/rules.md`, `docs/arch.md` (если есть) — определи стиль коммитов проекта и строго следуй правилам/архитектуре. Смотри и tracked, и untracked файлы.
 
 Если незакоммиченных изменений нет — сообщи и выйди.
 

package/docs/skills/eda-docs.md

@@ -30,7 +30,7 @@ description: 'Создаёт или обновляет три ключевых
 Определи сам: языки и фреймворки, тест-фреймворк, базы данных, инфраструктуру (контейнеры, CI), уже установленные линтеры/статанализаторы, главную ветку, стиль коммитов (по `git log`).
 
 ### 2. Прочитать существующие docs
-`docs/rules.md`, `docs/arch.md`, `AGENTS.md` (если есть). Запомни, что в них уже зафиксировано — чтобы не дублировать и не противоречить.
+`docs/rules.md`, `docs/arch.md`, `AGENTS.md` (если есть). Прочитай их и строго следуй уже зафиксированной рамке, если задача не требует её изменить. Запомни, что в них уже зафиксировано — чтобы не дублировать и не противоречить.
 
 ### 3. Уточнить, что обновляем
 `AskUserQuestion`: какие документы трогаем — все три / только rules / только arch / только AGENTS / выбрать несколько.
@@ -120,7 +120,7 @@ description: 'Создаёт или обновляет три ключевых
 - **Главная ветка:** <main|master|...>
 
 ## Для агентов
-Рамка проекта — `docs/rules.md` и `docs/arch.md`. Перед любой правкой кода прочитай их. Если их нет — спроси пользователя, можно ли запустить `eda-docs` для генерации. Скилы серии eda-* лежат в `.claude/skills/` (для Claude Code) и `.codex/skills/` (для Codex CLI) — следуй им, когда пользователь просит выполнить одну из задач серии.
+Рамка проекта — `docs/rules.md` и `docs/arch.md`. Перед любой правкой кода прочитай их и строго следуй им. Если их нет — спроси пользователя, можно ли запустить `eda-docs` для генерации. Скилы серии eda-* лежат в `.claude/skills/` (для Claude Code) и `.codex/skills/` (для Codex CLI) — следуй им, когда пользователь просит выполнить одну из задач серии.
 
 ## Где что хранится
 | Что | Где |

package/docs/skills/eda-execute.md

@@ -1,6 +1,6 @@
 ---
 name: eda-execute
-description: 'Исполняет план из docs/plans/ — правит код, пишет тесты к изменениям внутри каждого шага, в конце прогоняет полный сьют тестов и линтеры. Прогресс — чекбоксы в файле плана + журнал в `docs/executions/`; в конец плана дописывается ссылка на журнал. Не коммитит (это `eda-commit`), не делает ревью (это `eda-review`). Все вопросы — через интерактивный вопрос.'
+description: 'Исполняет план из docs/plans/ — перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им, правит код, пишет тесты к изменениям внутри каждого шага, в конце прогоняет полный сьют тестов и линтеры. Прогресс — чекбоксы в файле плана + журнал в `docs/executions/`; в конец плана дописывается ссылка на журнал. Не коммитит (это `eda-commit`), не делает ревью (это `eda-review`). Все вопросы — через интерактивный вопрос.'
 ---
 
 # Скил: Исполнитель (eda-execute)
@@ -9,7 +9,7 @@ description: 'Исполняет план из docs/plans/ — правит ко
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Это рамка проекта. Файлов нет — продолжай молча. Один раз в начале, не перечитывать на каждом шаге.
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Это рамка проекта. Файлов нет — продолжай молча. Один раз в начале, не перечитывать на каждом шаге.
 2. **Интерактивные вопросы** — по разделу ниже.
 3. **Не переформулируй план.** Шаг непонятен — спроси, не «доразрабатывай» молча.
 4. **Не коммитить, не пушить, не делать ревью.** Это другие скилы.
@@ -61,7 +61,7 @@ cd ../<repo-name>-<slug>
 И **выйди из скила** — текущая сессия в эту папку не переедет, поэтому продолжать здесь нельзя. Сообщи пользователю, что ждёшь его в новой сессии.
 
 ### 3. Прочитать контекст
-План + `docs/rules.md` и `docs/arch.md` (если есть). Тест-фреймворк проекта определи сам по конфигам/существующим тестам — этого хватит, чтобы писать тесты в нужном стиле.
+План + `docs/rules.md` и `docs/arch.md` (если есть). Правилам и архитектуре строго следуй при каждой правке. Тест-фреймворк проекта определи сам по конфигам/существующим тестам — этого хватит, чтобы писать тесты в нужном стиле.
 
 ### 4. Инициализировать прогресс
 - Создай журнал `docs/executions/{YYYY-MM-DD}_{HH-MM}_{slug}.md` (slug — тот же, что у плана, или близкий).

package/docs/skills/eda-fix-by-review.md

@@ -1,6 +1,6 @@
 ---
 name: eda-fix-by-review
-description: 'Применяет замечания из ревью (`docs/reviews/...`) к коду. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно; «не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью (это `eda-review`), не коммитит (это `eda-commit`). Все вопросы — через интерактивный вопрос.'
+description: 'Применяет замечания из ревью (`docs/reviews/...`) к коду. Перед правками читает `docs/rules.md` и `docs/arch.md` и строго следует им. Бесспорные («править обязательно») — правит сразу; «на усмотрение» — спрашивает интерактивно; «не править» — пропускает. После всех правок — полный прогон тестов и линтеров. Отчёт сохраняется в `docs/review-fixes/`. Не делает само ревью (это `eda-review`), не коммитит (это `eda-commit`). Все вопросы — через интерактивный вопрос.'
 ---
 
 # Скил: Исправитель по ревью (eda-fix-by-review)
@@ -9,7 +9,7 @@ description: 'Применяет замечания из ревью (`docs/revie
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Это рамка проекта. Один раз в начале.
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Это рамка проекта. Один раз в начале.
 2. **Интерактивные вопросы** — по разделу ниже.
 3. **Не переформулируй замечания.** Применяй то, что написано в ревью. Если непонятно — спроси через `AskUserQuestion`.
 4. **Не делаешь само ревью и не коммитишь.** Только применяешь замечания и пишешь отчёт.
@@ -36,7 +36,7 @@ description: 'Применяет замечания из ревью (`docs/revie
 Если путь не передан — `AskUserQuestion` со списком последних файлов из `docs/reviews/`. Получи `$REVIEW_FILE`.
 
 ### 2. Прочитать контекст
-`docs/rules.md`, `docs/arch.md` (если есть). Сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
+`docs/rules.md`, `docs/arch.md` (если есть) — прочитай и строго следуй им. Сам файл ревью. Если ревью ссылается на план/research — прочитай и их.
 
 ### 3. Применить замечания
 Раздели пункты ревью по группам (берёшь из раздела «Рекомендации»):

package/docs/skills/eda-fix.md

@@ -1,6 +1,6 @@
 ---
 name: eda-fix
-description: 'Делает обычные фиксы по плану, файлу плана или короткому текстовому контексту. Перед правками читает `docs/rules.md` и `docs/arch.md`, если есть. Правит код, добавляет нужные тесты, прогоняет проверки и сохраняет историю в `docs/fixes/`. Не делает ревью и не коммитит.'
+description: 'Делает обычные фиксы по плану, файлу плана или короткому текстовому контексту. Перед правками читает `docs/rules.md` и `docs/arch.md`, если есть, и строго следует им. Правит код, добавляет нужные тесты, прогоняет проверки и сохраняет историю в `docs/fixes/`. Не делает ревью и не коммитит.'
 ---
 
 # Скил: Фиксер (eda-fix)
@@ -16,7 +16,7 @@ description: 'Делает обычные фиксы по плану, файлу
 
 ## Главные правила
 
-1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Файлов нет — продолжай.
+1. **Перед правкой кода** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Файлов нет — продолжай.
 2. **Вход обязателен.** Если не передан план, файл или понятный текст задачи — спроси через интерактивный вопрос.
 3. **Делай только указанные фиксы.** Не расширяй задачу до рефакторинга и не чини соседние проблемы без необходимости.
 4. **Тесты рядом с правкой.** Меняешь поведение — добавь или обнови точечный тест.
@@ -42,7 +42,7 @@ description: 'Делает обычные фиксы по плану, файлу
 - если входа нет или он неоднозначен — спроси через `AskUserQuestion`.
 
 ### 2. Прочитать рамку проекта
-Прочитай `docs/rules.md` и `docs/arch.md`, если есть. Если `$FIX_CONTEXT` ссылается на research, review, issue или другой файл — прочитай и его.
+Прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Если `$FIX_CONTEXT` ссылается на research, review, issue или другой файл — прочитай и его.
 
 ### 3. Сделать фикс
 Найди релевантный код и внеси минимальные правки. Если задача состоит из нескольких пунктов, иди по ним последовательно. Останавливайся и спрашивай, если пункт противоречит коду, требует продуктового решения, рискованной операции, миграции, удаления данных или затрагивает секреты.

package/docs/skills/eda-plan.md

@@ -21,7 +21,7 @@ description: 'Написание плана реализации через ст
 3. **Plan Mode — главный инструмент.** Он даёт содержательный черновик, но финальный файл обязан быть нормализован в формат этого скилла.
 4. **Не переформулируй запрос пользователя** перед Plan Mode. Уйдёт оригинал + ответы на уточнения. Своя цель/критерии разводят смысл.
 5. **План сохраняется в файл до любой верификации** — иначе ревьюеру нечего читать.
-6. **Простой язык** в сообщениях, вопросах, шапке плана. Термины — только если без них нельзя, и сразу с пояснением.
+6. **Максимально простой язык.** Пиши план так, чтобы его понял человек без глубокого погружения в код. Избегай жаргона, сокращений и внутренних названий без необходимости. Термины используй только когда без них нельзя точно донести смысл, и сразу объясняй их простыми словами.
 7. **Диаграммы — желательно, не любой ценой.** Линейный план — диаграмма не нужна.
 8. **Таблицы > сплошной текст** для структурируемых данных.
 9. **Финальный план — не исследование.** Исследовательские факты идут в контекст, выбранные подходы — в решения, исполнимые шаги — в фазы.
@@ -125,6 +125,7 @@ sources:
 - фазы идут в реалистичном порядке реализации;
 - у каждой фазы есть цель, результат и проверка;
 - нет неразрешённых формулировок «выбрать», «решить», «можно так или так», «предпочтительно», «при необходимости»;
+- текст написан простым языком: без лишнего жаргона, непояснённых сокращений и тяжёлых терминов;
 - мета-уровень не смешан с шагами исполнения;
 - тесты связаны с ключевыми сценариями и рисками;
 - план можно передать в `eda-execute` без нового исследования.

package/docs/skills/eda-research.md

@@ -18,10 +18,11 @@ description: 'Глубокое исследование темы или зада
 
 1. **Никаких правок кода.** Запись только в `docs/researches/`.
 2. **Интерактивные вопросы** — по разделу ниже.
-3. **Простой язык.** Термины — только когда без них нельзя, сразу с пояснением.
-4. **Каждое утверждение — со ссылкой** (`file.ext:42`, URL, коммит). Без ссылки — помечай как «гипотеза».
-5. **Диаграммы — желательно, не любой ценой.** Тема плоская — не выдумывай.
-6. **Таблицы > сплошной текст** для структурируемых данных.
+3. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им как рамке исследования.
+4. **Простой язык.** Термины — только когда без них нельзя, сразу с пояснением.
+5. **Каждое утверждение — со ссылкой** (`file.ext:42`, URL, коммит). Без ссылки — помечай как «гипотеза».
+6. **Диаграммы — желательно, не любой ценой.** Тема плоская — не выдумывай.
+7. **Таблицы > сплошной текст** для структурируемых данных.
 
 ## Интерактивные вопросы
 
@@ -37,7 +38,7 @@ description: 'Глубокое исследование темы или зада
 Прочитай запрос. Сформулируй цель и 3–7 конкретных вопросов. Неясности — задай через `AskUserQuestion`. Не уходи дальше, пока цель не подтверждена.
 
 ### 2. Собрать материал
-Работай в read-only режиме: читай файлы, ищи по проекту, смотри историю и запускай только команды, которые не меняют рабочее дерево. Код, конфиги и зависимости не правь. Запись разрешена только на этапе 4 при сохранении итогового отчёта в `docs/researches/`.
+Работай в read-only режиме: читай файлы, ищи по проекту, смотри историю и запускай только команды, которые не меняют рабочее дерево. Прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Код, конфиги и зависимости не правь. Запись разрешена только на этапе 4 при сохранении итогового отчёта в `docs/researches/`.
 
 ### 3. Диаграммы (если уместно)
 Есть поток / связи / состояния / последовательность шагов — нарисуй 1–3 Mermaid-диаграммы. Подписи на русском. Если показывать нечего — в разделе диаграмм отчёта одна строка: «Не требуется — тема не имеет графовой структуры.»

package/docs/skills/eda-review.md

@@ -1,6 +1,6 @@
 ---
 name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл). Если контекст ревью понятен из запроса или репозитория, не задаёт уточняющий вопрос и сразу выбирает цель. Формирует пронумерованные замечания, оценку 0–100, рекомендации «править / на усмотрение / не править». Сохраняет в docs/reviews/. Всегда проверяет своё же ревью тремя параллельными моделями (Sonnet, Haiku, Opus); кросс-CLI (Claude ↔ Codex) включается только флагом `strict`. После каждой проверки сам корректирует ревью. Не правит код — это `eda-fix-by-review`. Вопросы — только когда без ответа нельзя безопасно продолжать.'
+description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл). Если контекст ревью понятен из запроса или репозитория, не задаёт уточняющий вопрос и сразу выбирает цель. Перед ревью читает `docs/rules.md` и `docs/arch.md` и строго следует им. Формирует пронумерованные замечания, оценку 0–100, рекомендации «править / на усмотрение / не править». Сохраняет в docs/reviews/. Всегда проверяет своё же ревью тремя параллельными моделями (Sonnet, Haiku, Opus); кросс-CLI (Claude ↔ Codex) включается только флагом `strict`. После каждой проверки сам корректирует ревью. Не правит код — это `eda-fix-by-review`. Вопросы — только когда без ответа нельзя безопасно продолжать.'
 ---
 
 # Скил: Ревьюер (eda-review)
@@ -16,7 +16,7 @@ description: 'Ревью изменений (незакоммиченный diff
 
 ## Главные правила
 
-1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть. Замечания должны опираться на правила проекта, а не на твои общие представления.
+1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Замечания должны опираться на правила и архитектуру проекта, а не на твои общие представления.
 2. **Интерактивные вопросы** — по разделу ниже. Если контекст понятен, не спрашивай.
 3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
 4. **Мета-ревью тремя моделями — обязательно**, без флага. Кросс-CLI — только в `strict`.
@@ -46,7 +46,7 @@ description: 'Ревью изменений (незакоммиченный diff
 - если незакоммиченных изменений нет, но текущая ветка не `main`/`master` и отличается от базовой ветки — используй `git diff <base>...HEAD`, где `<base>` выбери из существующих `main`, `master`, `origin/main`, `origin/master`;
 - если цель всё ещё неоднозначна или diff пустой — только тогда через `AskUserQuestion` спроси, что ревьюим: незакоммиченный diff (`git diff HEAD`) / diff ветки от main (`git diff main...HEAD`) / конкретный файл или папка / номер PR.
 
-Получи diff/исходник в `$TARGET`. Прочитай `docs/rules.md`, `docs/arch.md`. Если в diff видно отсылки к плану из `docs/plans/` или исследованию из `docs/researches/` — прочитай их тоже.
+Получи diff/исходник в `$TARGET`. Прочитай `docs/rules.md`, `docs/arch.md` и строго следуй им. Если в diff видно отсылки к плану из `docs/plans/` или исследованию из `docs/researches/` — прочитай их тоже.
 
 ### 2. Сделать первичное ревью и сохранить
 Пройдись по изменениям. Замечания группируй по типу: bug / архитектура / стиль / тесты / безопасность / производительность / документация. Каждое — с локацией (`file:line`) и предложением «что сделать». Поставь оценку 0–100 (100 — идеально, 0 — переделывать).

package/docs/skills/eda-send-review.md

@@ -1,6 +1,6 @@
 ---
 name: eda-send-review
-description: 'Отправляет ревью из `docs/reviews/...` на GitHub PR через `gh` — как review (comment/approve/request-changes) или как обычный комментарий. Целевой PR определяется автоматически по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку на PR-комментарий. Не правит код, не делает само ревью. Все вопросы — через интерактивный вопрос.'
+description: 'Отправляет ревью из `docs/reviews/...` на GitHub PR через `gh` — как review (comment/approve/request-changes) или как обычный комментарий. Перед отправкой читает `docs/rules.md` и `docs/arch.md` и строго следует им. Целевой PR определяется автоматически по текущей ветке; если PR нет — предлагает создать. После отправки в конец файла ревью дописывает ссылку на PR-комментарий. Не правит код, не делает само ревью. Все вопросы — через интерактивный вопрос.'
 ---
 
 # Скил: Отправитель ревью (eda-send-review)
@@ -10,9 +10,10 @@ description: 'Отправляет ревью из `docs/reviews/...` на GitHu
 ## Главные правила
 
 1. **Интерактивные вопросы** — по разделу ниже.
-2. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
-3. **Никаких самостоятельных оценок.** Тип отправки (comment / approve / request-changes) определяется на основе ревью + подтверждается пользователем.
-4. **Простой язык.** В сообщениях пользователю и комментарии PR без лишних терминов.
+2. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им при выборе способа отправки и финальной отметке.
+3. **Не правишь код, не делаешь само ревью.** Только переупаковка и отправка.
+4. **Никаких самостоятельных оценок.** Тип отправки (comment / approve / request-changes) определяется на основе ревью + подтверждается пользователем.
+5. **Простой язык.** В сообщениях пользователю и комментарии PR без лишних терминов.
 
 ## Интерактивные вопросы
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.2.10",
+  "version": "0.3.1",
   "description": "Набор скилов eda-* для Claude Code и Codex CLI: research, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
   "type": "module",
   "bin": {