@gian-tiaga/eda 0.3.4 → 0.4.0

package/README.md

@@ -19,7 +19,7 @@ npm install -g @gian-tiaga/eda
 eda init
 ```
 
-Установщик покажет чекбоксы: стрелками выбираешь среду, пробелом отмечаешь, Enter продолжает. Можно поставить Claude Code, Codex CLI или обе среды сразу.
+Установщик покажет чекбоксы: стрелками выбираешь среду, пробелом отмечаешь, Enter продолжает. Можно поставить Claude Code, Codex CLI или обе среды сразу. Если `docs/settings.yaml` ещё нет, установщик также предложит выбрать настройки скилов и создаст этот файл.
 
 ---
 
@@ -27,11 +27,11 @@ eda init
 
 | Скил | Что делает | Куда складывает |
 |---|---|---|
-| `eda-research` | Глубоко изучает тему или задачу. Без правок кода. Все вопросы — через интерактивный диалог. На выходе — понятный отчёт со ссылками на источники, диаграммами и таблицами | `docs/researches/` |
+| `eda-explore` | Исследует тему до конкретного результата: описание проблемы, релевантная архитектура, закрытые развилки и риски, короткий выбранный вариант решения без плана. Если нужны пакеты или ПО — проверяет актуальные стабильные версии через context7 или web search | `docs/researches/` |
 | `eda-plan` | Пишет план реализации через стандартный Plan Mode хост-агента. Подтягивает контекст из `docs/rules.md`, `docs/arch.md`, при желании — релевантное исследование. Затем три параллельных модели (слабая, средняя, мощная) проверяют план на реалистичность, пропущенные шаги и нарушения правил — главный планировщик сам решает, что применить | `docs/plans/` |
 | `eda-execute` | Выполняет план. Спрашивает, где работать (текущая ветка, новая ветка, отдельный worktree). Тесты пишет внутри каждого шага. В конце — полный прогон тестов и линтеров | `docs/executions/` |
 | `eda-fix` | Делает обычные фиксы по короткому контексту, баг-репорту или файлу плана. Перед правками читает правила и архитектуру, добавляет нужные тесты, прогоняет проверки и сохраняет историю правок | `docs/fixes/` |
-| `eda-review` | Делает код-ревью с оценкой 0–100 и сверкой с планом работ. Замечания пишет блоками: сначала контекст и риск, потом конкретные файлы/строки и шаги исправления. Затем три параллельных специализированных агента проверяют выполнение плана, архитектуру и правила. В строгом режиме — ещё и кросс-ревью между Claude и Codex | `docs/reviews/` |
+| `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) |
@@ -42,38 +42,63 @@ eda init
 
 ## 🚩 Флаги скилов
 
-У некоторых скилов есть флаг `strict` — он включает дополнительные тяжёлые проверки. Передаётся как часть запроса агенту, например: `eda-research strict <тема>` или просто `сделай ревью этого PR в strict-режиме`.
+У некоторых скилов есть флаг `strict` — он включает дополнительные тяжёлые проверки. Передаётся как часть запроса агенту, например: `eda-explore strict <тема>` или просто `сделай ревью этого PR в strict-режиме`. Также strict можно включить по умолчанию через `defaults.strict: true` в `docs/settings.yaml`.
 
 Скилы, которых нет в таблице ниже, флагов не поддерживают — у них всё включено по умолчанию.
 
 | Скил | Флаг | Что включает | Когда стоит использовать |
 |---|---|---|---|
-| `eda-research` | `strict` | После сохранения отчёта отдаёт его соседнему CLI (Claude → Codex или наоборот) на критическое ревью; затем доправляет отчёт по их замечаниям | Серьёзные исследования, которые лягут в основу больших решений; когда хочется второго мнения от другой модели/среды |
+| `eda-explore` | `strict` | После сохранения отчёта отдаёт его соседнему CLI (Claude → Codex или наоборот) на критическое ревью конкретности, фактов, развилок, рисков и версий; затем доправляет отчёт по замечаниям | Серьёзные исследования, которые лягут в основу больших решений; когда хочется второго мнения от другой модели/среды |
 | `eda-plan` | `strict` | После мета-ревью трёх моделей (это есть всегда) отдаёт план соседнему CLI на дополнительный круг проверки; доправляет план | Большие или ответственные планы, особенно затрагивающие смежные системы |
-| `eda-review` | `strict` | После мета-ревью тремя специализированными агентами отдаёт ревью соседнему CLI на дополнительный круг проверки; доправляет ревью по его замечаниям | Ревью важных PR; когда нужен максимальный охват |
+| `eda-review` | `strict` | После мета-ревью специализированными агентами отдаёт ревью соседнему CLI на дополнительный круг проверки; доправляет ревью по его замечаниям | Ревью важных PR; когда нужен максимальный охват |
+
+---
+
+## ⚙️ Настройки проекта
+
+Скилы читают `docs/settings.yaml`, если файл есть. Прямое указание в текущем запросе важнее настроек: например, `strict` включает строгий режим для одного запуска, а `normal` / `без strict` выключает его. Для `eda-plan` явный `short` включает короткий план, а `normal` / `обычный план` — обычный.
+
+Файл по умолчанию:
+
+```yaml
+version: 1
+
+defaults:
+  strict: false
+  plan_size: normal
+
+automate:
+  include_plans: false
+
+review:
+  include_code_quality: true
+```
+
+Что означают настройки:
+- `defaults.strict` — включает strict-режим по умолчанию для `eda-explore`, `eda-plan` и `eda-review`.
+- `defaults.plan_size` — размер плана для `eda-plan`: `normal`, `short` или `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`, только если файла ещё нет. Существующий файл не перезаписывается.
 
 ---
 
 ## 🔄 Воркфлоу
 
-```mermaid
-flowchart LR
-    R[🔍 research] --> P[📝 plan]
-    P --> E[⚙️ execute]
-    E --> X[🛠️ fix]
-    X --> V[🧐 review]
-    E --> V
-    V --> F[🛠️ fix-by-review]
-    F --> S[📤 send-review]
-    F --> C[💾 commit]
-    V -.-> A[⚡ automate]
-    F -.-> A
-    X -.-> A
-    D[📚 docs] -.-> P
-    D -.-> E
+```text
+docs ───────────────┬───────────────┐
+                    │               │
+                    v               v
+explore ─────────> plan ────────> execute ───┬──> review ───> fix-by-review ───┬──> send-review
+                                             │                                  │
+                                             v                                  └──> commit
+                                            fix ─────────────> review
+
+automate может запускаться от review, fix-by-review или fix.
 ```
 
-Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-research`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны.
+Использовать всю цепочку не обязательно — каждый скил самодостаточен. Можно начать с `eda-explore`, или сразу с `eda-execute` на готовом плане, или просто `eda-commit`, когда правки уже сделаны.
 
 ---
 
@@ -91,7 +116,7 @@ flowchart LR
 
 ```bash
 eda init      # выбрать Claude Code / Codex / обе среды и установить скилы
-eda update    # обновить уже установленные скилы из текущей версии пакета
+eda update    # обновить скилы и создать docs/settings.yaml, если его ещё нет
 eda --help    # справка
 ```
 

package/lib/install.js

@@ -1,4 +1,5 @@
 import checkbox from '@inquirer/checkbox';
+import select from '@inquirer/select';
 import fs from 'node:fs/promises';
 import path from 'node:path';
 import { fileURLToPath } from 'node:url';
@@ -7,10 +8,49 @@ const __filename = fileURLToPath(import.meta.url);
 const __dirname = path.dirname(__filename);
 const PACKAGE_ROOT = path.resolve(__dirname, '..');
 const SKILLS_SRC = path.join(PACKAGE_ROOT, 'skills');
+const SETTINGS_RELATIVE_PATH = 'docs/settings.yaml';
 const TARGET_CHOICES = [
   { value: 'claude', label: 'Claude Code', dir: '.claude/skills/' },
   { value: 'codex', label: 'Codex CLI', dir: '.codex/skills/' }
 ];
+const RETIRED_SKILLS = ['eda-research'];
+const DEFAULT_SETTINGS = {
+  strict: false,
+  planSize: 'normal',
+  includePlans: false,
+  includeCodeQuality: true
+};
+const SETTINGS_CHOICES = [
+  {
+    value: 'strict',
+    name: 'Strict по умолчанию для explore / plan / review',
+    checked: DEFAULT_SETTINGS.strict
+  },
+  {
+    value: 'includePlans',
+    name: 'Анализировать планы в eda-automate по умолчанию',
+    checked: DEFAULT_SETTINGS.includePlans
+  },
+  {
+    value: 'includeCodeQuality',
+    name: 'Проверять качество кода в eda-review',
+    checked: DEFAULT_SETTINGS.includeCodeQuality
+  }
+];
+const PLAN_SIZE_CHOICES = [
+  {
+    value: 'normal',
+    name: 'Обычный план по умолчанию'
+  },
+  {
+    value: 'short',
+    name: 'Короткий plan short по умолчанию'
+  },
+  {
+    value: 'ask_each_time',
+    name: 'Спрашивать размер плана каждый раз'
+  }
+];
 
 export async function init({ cwd, input = process.stdin, output = process.stdout }) {
   const targets = await askTargets({ input, output });
@@ -18,17 +58,19 @@ export async function init({ cwd, input = process.stdin, output = process.stdout
     output.write('Ничего не выбрано — выходим.\n');
     return;
   }
-  await syncSkills(cwd, targets);
+  await ensureSettings(cwd, { input, output });
+  await syncSkills(cwd, targets, output);
 }
 
-export async function update({ cwd }) {
+export async function update({ cwd, input = process.stdin, output = process.stdout }) {
   const targets = await detectTargets(cwd);
   if (targets.length === 0) {
-    process.stdout.write('Не нашёл установленных скилов в этом проекте. Запусти `eda init`.\n');
+    output.write('Не нашёл установленных скилов в этом проекте. Запусти `eda init`.\n');
     return;
   }
-  process.stdout.write(`Найдены установленные среды: ${targets.join(', ')}\n`);
-  await syncSkills(cwd, targets);
+  output.write(`Найдены установленные среды: ${targets.join(', ')}\n`);
+  await ensureSettings(cwd, { input, output });
+  await syncSkills(cwd, targets, output);
 }
 
 export async function askTargets({ input = process.stdin, output = process.stdout } = {}) {
@@ -51,6 +93,38 @@ export async function askTargets({ input = process.stdin, output = process.stdou
   });
 }
 
+export async function askSettings({ input = process.stdin, output = process.stdout } = {}) {
+  if (!input.isTTY || !output.isTTY) {
+    output.write(`Нет интерактивного терминала — создаю ${SETTINGS_RELATIVE_PATH} с настройками по умолчанию.\n`);
+    return { ...DEFAULT_SETTINGS };
+  }
+
+  const selected = await checkbox({
+    message: 'Какие настройки включить?',
+    instructions: 'Стрелки — выбрать, Space — отметить, Enter — продолжить',
+    choices: SETTINGS_CHOICES
+  }, {
+    input,
+    output
+  });
+
+  const planSize = await select({
+    message: 'Какой размер плана eda-plan использовать по умолчанию?',
+    choices: PLAN_SIZE_CHOICES,
+    default: DEFAULT_SETTINGS.planSize
+  }, {
+    input,
+    output
+  });
+
+  return {
+    strict: selected.includes('strict'),
+    planSize,
+    includePlans: selected.includes('includePlans'),
+    includeCodeQuality: selected.includes('includeCodeQuality')
+  };
+}
+
 async function detectTargets(cwd) {
   const targets = [];
   if (await dirExists(path.join(cwd, '.claude/skills'))) targets.push('claude');
@@ -58,17 +132,18 @@ async function detectTargets(cwd) {
   return targets;
 }
 
-async function syncSkills(cwd, targets) {
+async function syncSkills(cwd, targets, output = process.stdout) {
   const skills = await listSkills();
   if (skills.length === 0) {
     throw new Error(`В пакете нет скилов (искал в ${SKILLS_SRC}).`);
   }
-  process.stdout.write(`Скилы для установки: ${skills.map(s => s.name).join(', ')}\n`);
+  output.write(`Скилы для установки: ${skills.map(s => s.name).join(', ')}\n`);
 
-  if (targets.includes('claude')) await installToClaude(cwd, skills);
-  if (targets.includes('codex')) await installToCodex(cwd, skills);
+  if (targets.includes('claude')) await installToClaude(cwd, skills, output);
+  if (targets.includes('codex')) await installToCodex(cwd, skills, output);
+  await removeRetiredSkills(cwd, targets);
 
-  process.stdout.write('\nГотово.\n');
+  output.write('\nГотово.\n');
 }
 
 async function listSkills() {
@@ -79,7 +154,35 @@ async function listSkills() {
     .sort((a, b) => a.name.localeCompare(b.name));
 }
 
-async function installToClaude(cwd, skills) {
+async function ensureSettings(cwd, { input = process.stdin, output = process.stdout } = {}) {
+  const settingsPath = path.join(cwd, SETTINGS_RELATIVE_PATH);
+  if (await fileExists(settingsPath)) {
+    output.write(`Настройки уже есть: ${SETTINGS_RELATIVE_PATH}\n`);
+    return;
+  }
+
+  const settings = await askSettings({ input, output });
+  await fs.mkdir(path.dirname(settingsPath), { recursive: true });
+  await fs.writeFile(settingsPath, formatSettings(settings));
+  output.write(`Создан файл настроек: ${SETTINGS_RELATIVE_PATH}\n`);
+}
+
+function formatSettings(settings) {
+  return `version: 1
+
+defaults:
+  strict: ${settings.strict ? 'true' : 'false'}
+  plan_size: ${settings.planSize}
+
+automate:
+  include_plans: ${settings.includePlans ? 'true' : 'false'}
+
+review:
+  include_code_quality: ${settings.includeCodeQuality ? 'true' : 'false'}
+`;
+}
+
+async function installToClaude(cwd, skills, output = process.stdout) {
   const dst = path.join(cwd, '.claude/skills');
   await fs.mkdir(dst, { recursive: true });
   for (const skill of skills) {
@@ -88,10 +191,10 @@ async function installToClaude(cwd, skills) {
     const content = await fs.readFile(skill.path, 'utf-8');
     await fs.writeFile(path.join(skillDir, 'SKILL.md'), content);
   }
-  process.stdout.write(`  ✓ Claude Code: ${dst}\n`);
+  output.write(`  ✓ Claude Code: ${dst}\n`);
 }
 
-async function installToCodex(cwd, skills) {
+async function installToCodex(cwd, skills, output = process.stdout) {
   const dst = path.join(cwd, '.codex/skills');
   await fs.mkdir(dst, { recursive: true });
   for (const skill of skills) {
@@ -101,7 +204,7 @@ async function installToCodex(cwd, skills) {
     await fs.writeFile(path.join(skillDir, 'SKILL.md'), content);
     await removeObsoleteCodexFile(dst, skill.name);
   }
-  process.stdout.write(`  ✓ Codex CLI: ${dst}\n`);
+  output.write(`  ✓ Codex CLI: ${dst}\n`);
 }
 
 async function removeObsoleteCodexFile(dst, skillName) {
@@ -112,6 +215,23 @@ async function removeObsoleteCodexFile(dst, skillName) {
   }
 }
 
+async function removeRetiredSkills(cwd, targets) {
+  const targetDirs = {
+    claude: path.join(cwd, '.claude/skills'),
+    codex: path.join(cwd, '.codex/skills')
+  };
+
+  for (const target of targets) {
+    const dst = targetDirs[target];
+    if (!dst) continue;
+
+    for (const skillName of RETIRED_SKILLS) {
+      await fs.rm(path.join(dst, skillName), { recursive: true, force: true });
+      await fs.rm(path.join(dst, `${skillName}.md`), { force: true });
+    }
+  }
+}
+
 async function dirExists(p) {
   try {
     const st = await fs.stat(p);
@@ -120,3 +240,12 @@ async function dirExists(p) {
     return false;
   }
 }
+
+async function fileExists(p) {
+  try {
+    const st = await fs.stat(p);
+    return st.isFile();
+  } catch {
+    return false;
+  }
+}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@gian-tiaga/eda",
-  "version": "0.3.4",
-  "description": "Набор скилов eda-* для Claude Code и Codex CLI: research, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
+  "version": "0.4.0",
+  "description": "Набор скилов eda-* для Claude Code и Codex CLI: explore, plan, execute, fix, review, fix-by-review, send-review, commit, docs, automate",
   "type": "module",
   "bin": {
     "eda": "bin/cli.js"
@@ -37,6 +37,7 @@
     "url": "https://github.com/falur/eda/issues"
   },
   "dependencies": {
-    "@inquirer/checkbox": "^4.3.2"
+    "@inquirer/checkbox": "^4.3.2",
+    "@inquirer/select": "^5.1.5"
   }
 }

package/skills/eda-automate.md

@@ -1,6 +1,6 @@
 ---
 name: eda-automate
-description: 'Анализирует историю `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`, а по тексту рядом с вызовом может включать `docs/plans/`, последние N, период или конкретные файлы. Ищет повторяющиеся замечания, фиксы и проблемы планирования, предлагает автоматизации, а также черновики дополнений для `docs/rules.md` и `docs/arch.md`. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет изменения — выдаёт приоритезированный список с черновиками правил, проверок и правок документации. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
+description: 'Анализирует историю `docs/reviews/`, `docs/review-fixes/` и `docs/fixes/`, а по тексту рядом с вызовом или настройке `automate.include_plans: true` в `docs/settings.yaml` может включать `docs/plans/`, последние N, период или конкретные файлы. Ищет повторяющиеся замечания, фиксы и проблемы планирования, предлагает автоматизации, а также черновики дополнений для `docs/rules.md` и `docs/arch.md`. Опирается на инструменты, которые уже работают в проекте; если ничего не подходит — предлагает новый, без дублей с уже установленными. Не внедряет изменения — выдаёт приоритезированный список с черновиками правил, проверок и правок документации. Внедрение — отдельная задача через `eda-plan` + `eda-execute`. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
 ---
 
 # Скил: Автоматизатор (eda-automate)
@@ -14,12 +14,23 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
 | Обычный | `eda-automate` | `docs/reviews/` + `docs/review-fixes/` + `docs/fixes/` |
 | С планами | `eda-automate plans` | `docs/reviews/` + `docs/review-fixes/` + `docs/fixes/` + `docs/plans/` |
 
+Если в `docs/settings.yaml` указано `automate.include_plans: true`, режим с планами включён по умолчанию. Явное указание пользователя в текущем сообщении важнее настройки: `plans` / «с планами» включает планы, `normal` / «без планов» выключает их для текущего запуска.
+
 ## Вход из сообщения пользователя
 
 Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
 
 Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
+## Настройки проекта
+
+Перед выбором режима прочитай `docs/settings.yaml`, если файл есть.
+
+Если файла нет — используй значение по умолчанию:
+- `automate.include_plans: false`
+
+Прямое указание пользователя в текущем сообщении важнее `docs/settings.yaml`.
+
 ## Главные правила
 
 1. **Прочитай `docs/rules.md` и `docs/arch.md`**, если есть, и строго следуй им. Не предлагай то, что уже зафиксировано как автоматизированное правило или архитектурное решение.
@@ -28,7 +39,7 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
 4. **Предлагай только повторяющееся.** Минимум — паттерн встречается в 2+ разных ревью или в 3+ местах одного. Единичные замечания не автоматизируем.
 5. **Каждое предложение — с черновиком.** Не «надо бы что-то сделать», а конкретный фрагмент: правило линтера, псевдокод/skeleton, текст для `docs/rules.md` или патч для `docs/arch.md`.
 6. **Простой язык. Таблицы** для приоритезации.
-7. **Планы анализируй только с аргументом `plans`.** Без него не читай `docs/plans/`, если пользователь не указал конкретные файлы планов.
+7. **Планы анализируй только когда режим с планами включён.** Режим включают аргумент `plans`, явная просьба пользователя или `automate.include_plans: true` в `docs/settings.yaml`. Если пользователь явно написал `normal` / «без планов», не читай `docs/plans/`.
 
 ## Интерактивные вопросы
 
@@ -41,10 +52,11 @@ description: 'Анализирует историю `docs/reviews/`, `docs/revie
 ## Этапы
 
 ### 1. Выбрать диапазон
-Определи режим и диапазон по тексту рядом с вызовом. Если передан `plans`, указаны файлы из `docs/plans/` или пользователь явно просит анализ планов — включи планы в источники без отдельного вопроса.
+Определи режим и диапазон по тексту рядом с вызовом и `docs/settings.yaml`. Если передан `plans`, указаны файлы из `docs/plans/`, пользователь явно просит анализ планов или `automate.include_plans: true` — включи планы в источники без отдельного вопроса. Если пользователь явно просит `normal` / «без планов» — не включай планы, даже если настройка включена.
 
 Без вопроса используй вход, если он задаёт:
 - `plans` / анализ планов;
+- `normal` / без планов;
 - последние N (`последние 5`, `last 10`);
 - период (`за 30 дней`, `с YYYY-MM-DD по YYYY-MM-DD`);
 - конкретные файлы или папки.

package/skills/eda-docs.md

@@ -1,15 +1,15 @@
 ---
 name: eda-docs
-description: 'Создаёт или обновляет документы, указанные рядом с вызовом: `docs/rules.md` (максимально строгие правила для стека + предложения новых инструментов), `docs/arch.md` (архитектура проекта), `AGENTS.md` (описание проекта, стек, ссылки на документы и команды) или все три. Анализирует стек сам. Не правит код. Вопросы задаёт только когда без ответа нельзя безопасно продолжать.'
+description: 'Создаёт или обновляет документы, указанные рядом с вызовом: `docs/rules.md` (правила, подстроенные под реальный проект), `docs/arch.md` (архитектура проекта), `AGENTS.md` (описание проекта, стек, ссылки на документы и команды) или все три. Анализирует стек сам, учитывает переданный контекст и уже существующие практики. Не правит код.'
 ---
 
 # Скил: Документатор (eda-docs)
 
-Создаёшь или обновляешь три документа: `docs/rules.md`, `docs/arch.md` и шапку `AGENTS.md`. Правила — **максимально строгие** для стека проекта; смело предлагай инструменты, которых ещё нет, если они повышают строгость.
+Создаёшь или обновляешь три документа: `docs/rules.md`, `docs/arch.md` и шапку `AGENTS.md`. Документы должны быть подстроены под конкретный проект: его стек, текущую структуру, уже установленные инструменты, стиль кода, тесты, инфраструктуру и контекст, который передал пользователь.
 
 ## Вход из сообщения пользователя
 
-Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения и прямые указания.
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: тему, задачу, путь к файлу, режим, ограничения, прямые указания и дополнительный контекст о том, какие правила, архитектурные решения или боли проекта пользователь хочет зафиксировать.
 
 Если этого входа достаточно, продолжай без вопроса. `AskUserQuestion` задавай только если входа нет, он противоречивый, найдено несколько равных вариантов или есть риск выполнить не ту задачу. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
 
@@ -17,10 +17,11 @@ description: 'Создаёт или обновляет документы, ук
 
 1. **Интерактивные вопросы** — по разделу ниже.
 2. **Не правишь код**, не ставишь пакеты, не меняешь конфиги. Только документы.
-3. **Максимальная строгость по умолчанию.** Все доступные strict-флаги, запреты «гибких» конструкций, обязательные типы / тесты / обработка ошибок. Если правило бьёт по продуктивности — пометь, но не выкидывай.
-4. **Можно предлагать инструменты, которых ещё нет в проекте**, если они стандартные для стека и повышают строгость. Не предлагай дубль уже установленному того же класса.
-5. **Существующие документы** не переписываем молча. Если файл уже есть — `AskUserQuestion`: переписать / дополнить / создать рядом.
-7. **Простой язык.** В правилах объясняй *почему*, не только *что*. **Таблицы** для перечислений.
+3. **Подстройка под проект.** Не генерируй универсальный шаблон. Каждое правило и архитектурное описание должны опираться на найденные файлы, стек, текущие команды, зависимости, структуру директорий, существующие docs и контекст пользователя.
+4. **Строгость только там, где она уместна для проекта.** Правила должны помогать поддерживать проект, а не превращаться в список всех возможных best practices. Если предлагаешь усиление строгости — объясни, какую реальную проблему проекта оно закрывает.
+5. **Можно предлагать инструменты, которых ещё нет в проекте**, если они стандартные для стека и закрывают найденную проблему. Не предлагай дубль уже установленному того же класса. Предложение нового инструмента не становится правилом, пока пользователь не согласовал его.
+6. **Существующие документы** не переписываем молча. Если файл уже есть — `AskUserQuestion`: переписать / дополнить / создать рядом.
+7. **Простой язык.** Сначала объясняй простыми словами, зачем правило или архитектурный блок нужен проекту. Потом формулируй конкретику.
 
 ## Интерактивные вопросы
 
@@ -43,71 +44,43 @@ description: 'Создаёт или обновляет документы, ук
 
 Для каждого существующего файла — **отдельный** `AskUserQuestion`: переписать с нуля / дополнить / оставить как есть.
 
-### 4. Сгенерировать `docs/rules.md`
-Структура (примерная — адаптируй под стек):
+### 4. Сформировать план `docs/rules.md`
+Не используй фиксированный шаблон разделов. Сначала на основе анализа проекта и контекста пользователя предложи набор правил, которые действительно нужны этому проекту.
 
-```markdown
-# Правила проекта
-
-## Зачем эти правила
-<2–3 предложения: что мы хотим от кода, какую боль закрываем>
-
-## Стиль кода
-<строгие настройки форматтера, имена, длина строк, импорты>
-
-## Типы
-<обязательные типы, запрет any/mixed, strict-режимы>
-
-## Тесты
-<минимальное покрытие, расположение, именование, что обязательно покрывать>
-
-## Обработка ошибок
-<запрет «глотания» ошибок, обязательное логирование, типы исключений>
-
-## Безопасность
-<секреты, валидация ввода, SQL, XSS, ...>
-
-## Производительность
-<запрет N+1, ограничения сложности, ...>
+Перед записью файла задай `AskUserQuestion` с коротким планом правил:
+- 5–12 предлагаемых правил или групп правил.
+- Для каждого пункта: короткое название и 1–2 простых предложения, зачем это нужно именно этому проекту.
+- Отдельно пометь, какие пункты основаны на уже существующих практиках проекта, а какие являются предложениями.
+- Спроси, с чем пользователь согласен, что убрать, что изменить и какой дополнительный контекст учесть.
 
-## Коммиты и ветки
-<стиль сообщений, главная ветка, политика merge>
+Если пользователь передал контекст заранее, используй его как основной источник намерения, но всё равно сверяй с реальным стеком и файлами проекта. Не добавляй правило только потому, что оно типично для языка или фреймворка; добавляй его, если оно помогает этому проекту.
 
-## Инструменты
-| Инструмент | Установлен | Назначение | Конфиг (черновик) |
-|---|---|---|---|
-| ... | ✓/новый | ... | <фрагмент> |
+Из ответа пользователя сформируй план `docs/rules.md`, а затем сам документ. Формат документа выбирай под проект: разделы, таблицы, списки и примеры должны помогать читать и применять правила, а не соответствовать заранее заданной форме.
 
-## Что предлагается добавить
-<список инструментов, которых нет, но стоит поставить — для каждого: чем закрывает, черновик минимального конфига>
-```
-
-Каждое правило — с короткой строкой «почему» (ссылка на типичную ошибку или класс багов).
-
-### 5. Сгенерировать `docs/arch.md`
-Структура:
-
-```markdown
-# Архитектура проекта
-
-## Картина целиком
-<2–4 абзаца простыми словами: что делает система, какие у неё границы>
+В готовом `docs/rules.md` обязательно должны быть:
+- краткое объяснение, зачем документ нужен;
+- правила, привязанные к текущему стеку, структуре и командам проекта;
+- объяснение простым языком, зачем нужно каждое важное правило;
+- команды проверки, если они реально есть в проекте;
+- отдельный блок предложений, если есть полезные идеи, которые ещё не приняты или не настроены.
 
-<Mermaid-диаграмма верхнего уровня — модули и потоки. Если архитектура линейная и схемы не нужно — одна строка про это>
+### 5. Сформировать план `docs/arch.md`
+Не используй фиксированный шаблон архитектуры. Архитектурный документ должен описывать фактическую форму проекта: модули, границы, потоки данных, внешние зависимости и решения, которые реально видны в коде или переданы пользователем.
 
-## Модули
-| Модуль | Назначение | Зависит от | API наружу |
-|---|---|---|---|
+Перед записью файла задай `AskUserQuestion` с коротким планом архитектурного описания:
+- 4–10 предлагаемых архитектурных блоков.
+- Для каждого блока: короткое название и 1–2 простых предложения, зачем этот блок нужен читателю.
+- Отдельно пометь, что подтверждено кодом, что является выводом из структуры, а что требует подтверждения пользователя.
+- Спроси, с чем пользователь согласен, что убрать, что изменить и какой дополнительный контекст учесть.
 
-## Потоки данных
-<ключевые сценарии — sequenceDiagram или текст>
+Из ответа пользователя сформируй план `docs/arch.md`, а затем сам документ. Формат выбирай под проект. Если схему, таблицу модулей или список потоков данных полезно читать — добавь. Если они создают шум — не добавляй.
 
-## Решения и ограничения
-<важные архитектурные решения с обоснованием — почему так, а не иначе>
-
-## Что вне области
-<что система осознанно НЕ делает>
-```
+В готовом `docs/arch.md` обязательно должны быть:
+- простое описание, что делает система и где её границы;
+- описание ключевых частей проекта на языке текущего стека;
+- зависимости между важными частями;
+- фактические команды, входные точки или runtime-компоненты, если они есть;
+- явное разделение подтверждённых фактов, выводов из кода и предположений, если уверенности недостаточно.
 
 ### 6. Обновить `AGENTS.md`
 Если файл существует — `AskUserQuestion`: переписать / дополнить / оставить. Если нет — создай.
@@ -150,11 +123,12 @@ description: 'Создаёт или обновляет документы, ук
 ```
 
 ### 7. Финал
-Короткое сообщение: какие файлы созданы/обновлены, путь к каждому, ключевые предложения по новым инструментам списком, подсказка дальше — «прочитай файлы, скорректируй вручную, что не подходит».
+Короткое сообщение: какие файлы созданы/обновлены, путь к каждому, какие предложения остались непринятыми или требуют отдельного решения, подсказка дальше — «прочитай файлы, скорректируй вручную, что не подходит».
 
 ## Чего НЕ делать
 - Править код, ставить пакеты, менять конфиги — только документы.
 - Молча переписывать существующие документы — каждый раз `AskUserQuestion`.
-- Смягчать правила «потому что так удобнее» — стек строгий по умолчанию; послабления отдельно отмечай.
+- Генерировать универсальные правила без связи с реальным проектом, стеком и контекстом пользователя.
+- Превращать предложения в правила без согласия пользователя.
 - Предлагать второй инструмент того же класса в дополнение к уже установленному.
 - Добавлять разделы ради красоты — если для проекта раздел не релевантен, опусти его.