@gian-tiaga/eda 0.3.5 → 0.4.1

package/skills/eda-review.md

@@ -1,30 +1,42 @@
 ---
 name: eda-review
-description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью по Markdown-шаблону из этапа 2: с блоками «контекст», «риск», «где», «детали», «как исправить» и пустой строкой между каждым блоком. Сохраняет в docs/reviews/. Всегда запускает параллельные специализированные проверки: выполнение плана, следование архитектуре, следование правилам. Кросс-CLI (Claude ↔ Codex) включается только флагом `strict`. Не правит код — это `eda-fix-by-review`.'
+description: 'Ревью изменений (незакоммиченный diff, ветка, PR, папка/файл) с обязательной сверкой с планом работ из `docs/plans/`. Если план не указан и его нельзя однозначно определить, спрашивает путь к плану до ревью. Перед ревью читает `docs/rules.md` и `docs/arch.md`. Формирует ревью по Markdown-шаблону из этапа 2: с блоками «контекст», «риск», «где», «детали», «как исправить» и пустой строкой между каждым блоком. Сохраняет в docs/reviews/. Всегда запускает параллельные специализированные проверки: выполнение плана, следование архитектуре, следование правилам; проверка качества кода включается настройкой `review.include_code_quality: true` в `docs/settings.yaml`. Кросс-CLI (Claude ↔ Codex) включается флагом `strict` или настройкой `defaults.strict: true`. Не правит код — это `eda-fix-by-review`.'
 ---
 
 # Скил: Ревьюер (eda-review)
 
-Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь замечания, ставишь оценку, сохраняешь файл. Затем проверяешь ревью тремя параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
+Делаешь ревью изменений: сверяешь diff с планом работ, правилами и архитектурой, пишешь замечания, ставишь оценку, сохраняешь файл. Затем проверяешь ревью параллельными специализированными агентами; в `strict` — ещё и через соседний CLI. После каждой проверки **сам корректируешь** своё ревью: что-то добавляешь, что-то убираешь, что-то переформулируешь.
 
 ## Режимы вызова
 
 - Обычный: `eda-review` — этапы 1–3 + финал. Кросс-CLI не запускается.
 - Строгий: `eda-review strict` — обычный режим + кросс-CLI соседним агентом + допил.
 
+Если в `docs/settings.yaml` указано `defaults.strict: true`, строгий режим включён по умолчанию. Явное указание пользователя в текущем сообщении важнее настройки: `strict` включает строгий режим, `normal` / `без strict` / `без строгого режима` выключает его для текущего запуска.
+
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
 
 Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
+## Настройки проекта
+
+Перед выбором режима и набора проверок прочитай `docs/settings.yaml`, если файл есть.
+
+Если файла нет — используй значения по умолчанию:
+- `defaults.strict: false`
+- `review.include_code_quality: true`
+
+Прямое указание пользователя в текущем сообщении важнее `docs/settings.yaml`: `strict` включает строгий режим, `normal` / `без strict` выключает его; «проверь качество кода» включает quality-проверку, «без quality» / «без проверки качества» выключает её для текущего запуска.
+
 ## Главные правила
 
 1. **Перед ревью** прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Замечания должны опираться на правила и архитектуру проекта, а не на твои общие представления.
 2. **Интерактивные вопросы** — по разделу ниже. Если контекст понятен, не спрашивай.
 3. **Не правишь код.** Только ревью. Запись только в `docs/reviews/`.
 4. **План работ обязателен для ревью выполненных изменений.** Если путь к плану не указан в запросе и его нельзя однозначно определить из diff/ссылок, спроси путь к файлу плана и остановись до ответа. Не подставляй «последний план» наугад.
-5. **Мета-ревью тремя специализированными агентами — обязательно**, без флага: проверка выполнения плана, проверка архитектуры, проверка правил. Кросс-CLI — только в `strict`.
+5. **Мета-ревью специализированными агентами — обязательно**, без флага: проверка выполнения плана, проверка архитектуры, проверка правил. Если включена проверка качества кода — добавь `quality-check` тем же batch. Кросс-CLI — только в `strict`.
 6. **Главный ревьюер — ты.** Мета-ревьюеры дают подсказки; решение — добавить, убрать или оставить пункт — за тобой. Не вставляй чужие пункты механически.
 7. **Простой язык** в формулировках замечаний и рекомендаций. Технические термины — только если без них нельзя, и сразу с пояснением.
 8. **Формат файла ревью — Markdown-блоки по шаблону из этапа 2.** Сверку с планом, каждое замечание и рекомендации пиши отдельными блоками с подзаголовками. Между заголовком блока, статусом/типом, контекстом, риском, локациями, деталями и исправлением всегда оставляй одну пустую строку.
@@ -63,7 +75,7 @@ description: 'Ревью изменений (незакоммиченный diff
 Если в diff видно отсылки к исследованию из `docs/researches/` — прочитай его тоже.
 
 ### 2. Сделать первичное ревью и сохранить
-Пройдись по изменениям. Сначала проверь, выполнен ли `$PLAN_FILE`: что сделано, что сделано частично, что не сделано, какие отклонения создают риск. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию.
+Пройдись по изменениям. Сначала проверь, выполнен ли `$PLAN_FILE`: что сделано, что сделано частично, что не сделано, какие отклонения создают риск. Затем проверь нарушения правил, архитектуры, баги, тестовые пробелы, безопасность, производительность и документацию. Если `review.include_code_quality: true` или пользователь явно попросил качество кода, отдельно проверь качество реализации: читаемость, сложность, дублирование, имена, границы ответственности, связность модулей, поддерживаемость и соответствие стилю уже существующего кода.
 
 Каждое замечание должно быть самостоятельным блоком:
 - заголовок с номером и коротким смыслом;
@@ -154,20 +166,21 @@ meta_reviewers: []
 
 Покажи путь.
 
-### 3. Мета-ревью тремя специализированными агентами (параллельно)
-Запусти **в одном сообщении и одним batch** трёх агентов с разными ролями. Не запускай сначала одного-двух, не жди их ответы и не запускай третьего позже: все три проверки должны стартовать до чтения любого результата.
+### 3. Мета-ревью специализированными агентами (параллельно)
+Запусти **в одном сообщении и одним batch** агентов с разными ролями. Базовые три роли обязательны всегда. Если включена проверка качества кода, в тот же batch добавь четвёртого агента `quality-check`. Не запускай сначала часть агентов, не жди их ответы и не запускай остальных позже: все проверки должны стартовать до чтения любого результата.
 
 Роли агентов:
 - `plan-check`: проверяет, что реализация действительно выполнила `$PLAN_FILE`, включая частичные пункты, пропущенные требования, лишние отклонения и недостающие проверки.
 - `architecture-check`: проверяет следование `docs/arch.md`, границы модулей, контракты, зависимости и соответствие существующим архитектурным решениям.
 - `rules-check`: проверяет следование `docs/rules.md`, локальным запретам, обязательным командам, требованиям к тестам, миграциям, документации и процессу.
+- `quality-check`: запускай только если `review.include_code_quality: true` или пользователь явно попросил качество кода. Проверяет качество реализации: читаемость, сложность, дублирование, имена, размер и ответственность функций/классов, сцепление модулей, поддерживаемость и соответствие локальному стилю. Quality-замечания помечай типом `quality`; по умолчанию рекомендация `на усмотрение автора`, кроме случаев, где сложность, дублирование или неясная структура реально создают риск багов, тестовых пробелов или дорогого сопровождения.
 
 Модели:
-- Claude Code: запускай все три роли на `model: "sonnet"`.
-- Codex: запускай все три роли на `gpt-5.3-codex`.
-- Если нужный идентификатор недоступен, возьми ближайшую code-capable модель того же уровня. Не используй быструю слабую модель для этих трёх проверок: они должны читать diff, план, правила, архитектуру и релевантный код.
+- Claude Code: запускай все роли на `model: "sonnet"`.
+- Codex: запускай все роли на `gpt-5.3-codex`.
+- Если нужный идентификатор недоступен, возьми ближайшую code-capable модель того же уровня. Не используй быструю слабую модель для этих проверок: они должны читать diff, план, правила, архитектуру и релевантный код.
 
-Каждому дай путь к файлу ревью, `$TARGET`, `$PLAN_FILE`, `docs/rules.md`, `docs/arch.md`, связанный research при наличии. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
+Каждому дай путь к файлу ревью, `$TARGET`, `$PLAN_FILE`, `docs/rules.md`, `docs/arch.md`, `docs/settings.yaml`, связанный research при наличии. Каждый агент должен читать не только ревью, но и фактический diff/код, достаточный для проверки своей роли.
 
 Формат ответа агентов:
 - `+` что добавить в ревью;
@@ -177,17 +190,17 @@ meta_reviewers: []
 
 Для `plan-check` добавь явную инструкцию: «Если `$PLAN_FILE` не передан или файл не найден, верни только `? план не проверен: нужен путь к файлу`; не пытайся угадывать план.»
 
-Когда все три ответили: прочитай ответы, **сам реши**, что применять. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
+Когда все агенты ответили: прочитай ответы, **сам реши**, что применять. Внеси правки в файл ревью. В разделе `## Изменения после мета-ревью` запиши:
 
 ```markdown
-### После plan-check / architecture-check / rules-check
+### После plan-check / architecture-check / rules-check / quality-check
 - **+ Добавлено:** <короткий список>
 - **~ Изменено:** <короткий список>
 - **− Убрано:** <короткий список>
 - **Отклонено:** <короткий список с причиной>
 ```
 
-Поменяй `status: draft` → `meta-reviewed`, в `meta_reviewers` добавь `plan-check`, `architecture-check`, `rules-check` и фактические модели, например `gpt-5.3-codex` или `sonnet`. Если оценка после корректировок изменилась — обнови `score`.
+Поменяй `status: draft` → `meta-reviewed`, в `meta_reviewers` добавь `plan-check`, `architecture-check`, `rules-check`, а если запускался — `quality-check`, и фактические модели, например `gpt-5.3-codex` или `sonnet`. Если оценка после корректировок изменилась — обнови `score`.
 
 ### 4. Кросс-CLI: отдать соседнему агенту — только в `strict`
 Обычный режим — пропусти этап 4, иди на финал. `status: meta-reviewed` оставь как есть.
@@ -222,8 +235,8 @@ claude -p "Прочитай $REVIEW_FILE, $TARGET, $PLAN_FILE, docs/rules.md, do
 
 ## Чего НЕ делать
 - Править код. Это `eda-fix-by-review`.
-- Пропускать мета-ревью тремя специализированными агентами (это часть обычного режима, не под флагом).
-- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом третьего. Все три стартуют сразу.
+- Пропускать мета-ревью специализированными агентами (это часть обычного режима, не под флагом).
+- Запускать мета-ревьюеров частями: сначала 1–2 агента, потом остальных. Все обязательные проверки стартуют сразу.
 - Пропускать кросс-CLI молча в `strict` (если соседней CLI нет — спроси через `AskUserQuestion`).
 - Вставлять чужие предложения механически — каждое решение принимай ты.
 - Задавать вопросы без блокировки и продолжать работу до ответа.

package/skills/eda-research.md

@@ -1,119 +0,0 @@
----
-name: eda-research
-description: 'Глубокое исследование темы или задачи из текста рядом с вызовом в read-only режиме. Без правки кода. Вопросы задаёт только когда без ответа нельзя безопасно продолжать. Mermaid-диаграммы и markdown-таблицы — там где это даёт ясность. Итог сохраняется в docs/researches/. По умолчанию без кросс-ревью; кросс-ревью соседним агентом (Claude ↔ Codex) включается флагом `strict`.'
----
-
-# Скил: Исследователь (eda-research)
-
-Разбираешься в теме, собираешь понятный отчёт. Не правишь код, не торопишься с выводами.
-
-## Режимы вызова
-
-| Режим | Запуск | Что делает |
-|---|---|---|
-| Обычный | `eda-research <тема>` | Этапы 1–4 + финал. |
-| Строгий | `eda-research strict <тема>` | + кросс-ревью соседним агентом + допил. |
-
-## Вход из сообщения пользователя
-
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
-
-Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
-
-## Главные правила
-
-1. **Никаких правок кода.** Запись только в `docs/researches/`.
-2. **Интерактивные вопросы** — по разделу ниже.
-3. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им как рамке исследования.
-4. **Простой язык.** Термины — только когда без них нельзя, сразу с пояснением.
-5. **Каждое утверждение — со ссылкой** (`file.ext:42`, URL, коммит). Без ссылки — помечай как «гипотеза».
-6. **Диаграммы — желательно, не любой ценой.** Тема плоская — не выдумывай.
-7. **Таблицы > сплошной текст** для структурируемых данных.
-
-## Интерактивные вопросы
-
-Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
-- Claude Code: используй `AskUserQuestion`.
-- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
-- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
-- Не запускай команды, которые ждут интерактивного ввода в терминале; перед такими командами спроси в хост-интерфейсе или остановись с `blocked`.
-
-## Этапы
-
-### 1. Понять задачу
-Прочитай текст рядом с вызовом. Если тема и цель понятны, сформулируй цель и 3–7 конкретных вопросов для отчёта и продолжай без отдельного подтверждения. Если темы нет или она неоднозначна — задай `AskUserQuestion` и не уходи дальше без ответа.
-
-### 2. Собрать материал
-Работай в read-only режиме: читай файлы, ищи по проекту, смотри историю и запускай только команды, которые не меняют рабочее дерево. Прочитай `docs/rules.md` и `docs/arch.md`, если есть, и строго следуй им. Код, конфиги и зависимости не правь. Запись разрешена только на этапе 4 при сохранении итогового отчёта в `docs/researches/`.
-
-### 3. Диаграммы (если уместно)
-Есть поток / связи / состояния / последовательность шагов — нарисуй 1–3 Mermaid-диаграммы. Подписи на русском. Если показывать нечего — в разделе диаграмм отчёта одна строка: «Не требуется — тема не имеет графовой структуры.»
-
-### 4. Собрать отчёт
-`docs/researches/{YYYY-MM-DD}_{HH-MM}_{slug}.md`.
-
-```markdown
----
-title: <заголовок>
-date: <YYYY-MM-DD HH:MM>
-mode: <normal | strict>
-status: <draft | reviewed>
-reviewer: <pending | none | claude | codex>
----
-
-# <Заголовок>
-
-## 1. Цель и вопросы
-**Цель:** ...
-**Вопросы:** 1) ... 2) ...
-
-## 2. Диаграммы
-<Mermaid или строка про «не требуется»>
-
-## 3. Находки
-| # | Факт | Источник | Что это значит |
-|---|------|----------|-----------------|
-
-## 4. Риски и открытые вопросы
-| Риск/неясность | Почему важно | Что предлагаешь |
-|----------------|---------------|------------------|
-
-## 5. Итог
-<3–7 предложений простыми словами>
-```
-
-Покажи путь.
-
-### 5. Кросс-ревью — только в `strict`
-Обычный режим — пропусти этапы 5–6, иди на финал. `reviewer: none`, `status: draft`.
-
-В `strict`: отдай файл соседнему агенту через `Bash` и сформулируй задание как глубокую проверку исследования по коду, документам и источникам.
-
-Если ты в Claude Code — запускай Codex CLI:
-
-```bash
-codex exec "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md при наличии и все источники, на которые ссылается исследование. Затем глубоко проверь исследование по релевантному коду и документам: открой файлы, модули, API, тесты и внешние источники, которые нужны для проверки фактов. Критическое ревью на русском: фактические ошибки, пропущенные риски, неподтверждённые утверждения, неточности диаграмм, неверные выводы, риски для будущего плана/реализации. Список '- [тип] описание — что предлагаешь'." > "${RESEARCH_FILE%.md}_review.md"
-```
-
-Если ты в Codex — запускай Claude CLI с теми же требованиями глубины:
-
-```bash
-claude -p "Прочитай $RESEARCH_FILE, docs/rules.md, docs/arch.md при наличии и все источники, на которые ссылается исследование. Затем глубоко проверь исследование по релевантному коду и документам: открой файлы, модули, API, тесты и внешние источники, которые нужны для проверки фактов. Критическое ревью на русском: фактические ошибки, пропущенные риски, неподтверждённые утверждения, неточности диаграмм, неверные выводы, риски для будущего плана/реализации. Список '- [тип] описание — что предлагаешь'." > "${RESEARCH_FILE%.md}_review.md"
-```
-
-CLI нет — `AskUserQuestion`: продолжать без ревью или прервать.
-
-### 6. Допилить по ревью — только в `strict`
-Бесспорные → правишь. Спорные → `AskUserQuestion`. Отклонённые → оставляешь с причиной. В конец отчёта раздел `## 6. Реакция на ревью` (Принято / Отклонено / Спорное). `status: reviewed`. Покажи дифф.
-
-### 7. Финал
-Короткое сообщение: режим, путь к отчёту, путь к ревью (если `strict`), 3–5 главных выводов простыми словами, что предлагаешь дальше (но не делай — это работа другого скила).
-
-## Чего НЕ делать
-- Править код, запускать миграции, менять конфиги.
-- Задавать вопросы без блокировки и продолжать работу до ответа.
-- Делать выводы без ссылок на источник.
-- Пропускать кросс-ревью молча в `strict`.
-- Сохранять отчёт куда-либо кроме `docs/researches/`.
-- Рисовать диаграмму ради галочки.
-- Оформлять структурируемые данные сплошным текстом.