@bonesofspring/ai-rules 0.2.14 → 0.2.16

package/presets/claude/mcp-ts/commands/task-continue.md

@@ -3,25 +3,25 @@ name: task-continue
 description: Continue an agent-team task after a human gate, pause, or review changes request using pipeline.json and status.json.
 ---
 
-# Task continue — после human gate или паузы
+# Task continue — after human gate or pause
 
-Продолжение пайплайна из `pipeline.json`. Алиас по смыслу: `/feature-continue`.
+Resume the pipeline from `pipeline.json`. Semantic alias: `/feature-continue`.
 
-## Аргументы
+## Arguments
 
-`<slug>` — идентификатор задачи.
+`<slug>` — task identifier.
 
 ## Preconditions
 
-1. Прочитай `.claude/team/tasks/<slug>/pipeline.json` и `status.json`.
-2. Продолжай если:
-   - `awaitingHumanGate: true` или `state: awaiting_approval`, **или**
-   - `state: changes_requested` (после review), **или**
-   - задача прервана и нужно возобновить с `pipelineIndex`.
+1. Read `.claude/team/tasks/<slug>/pipeline.json` and `status.json`.
+2. Continue if:
+   - `awaitingHumanGate: true` or `state: awaiting_approval`, **or**
+   - `state: changes_requested` (after review), **or**
+   - the task was interrupted and must resume from `pipelineIndex`.
 
-## Алгоритм
+## Algorithm
 
-1. Запиши `.claude/team/active-task.json` → `{ "slug": "<slug>" }`.
+1. Write `.claude/team/active-task.json` → `{ "slug": "<slug>" }`.
 2. **Human gate resume** (`awaitingHumanGate` / `awaiting_approval`):
    1. **Do not** manually increment `pipelineIndex` or invent `currentAgent` first.
    2. Close the gate + activate the next attempt via the **installed** hook (single authority for ledger + status):
@@ -36,10 +36,10 @@ printf '%s\n' '{"status":"completed","action":"end_human_gate","activateNext":tr
 4. **Other resume**: restore `pipelineIndex` / `currentAgent` from status and invoke that agent.
 5. After the invoked agent completes, `chain-team-phases.sh` on `subagentStop` continues the chain when `autoChain: true`.
 
-## Артефакты для handoff
+## Artifacts for handoff
 
-| Agent | Прочитать |
-|-------|-----------|
+| Agent | Read |
+|-------|------|
 | feature-developer | brief.md, decomposition.md, validation-report.md (if retry), review.md (if retry), architecture.md |
 | build-verifier | git diff, decomposition.md |
 | code-reviewer | brief.md, validation-report.md, git diff |

package/presets/claude/mcp-ts/commands/task.md

@@ -3,52 +3,52 @@ name: task
 description: Route a natural-language task through the agent-team pipeline: task-router, pipeline.json, and the first planned specialist.
 ---
 
-# Task — единая точка входа (router + pipeline)
+# Task — unified entry point (router + pipeline)
 
-Главная команда для постановки задачи. Родительский агент = оркестратор (`agent-team-orchestrator.mdc`). Intake для work-запросов без `/task` — `agent-team-intake.mdc`.
+Main command for submitting work in Claude Code. Parent agent = orchestrator (`rules/tooling-and-review/agent-team-orchestrator.md`). Intake — `rules/tooling-and-review/agent-team-intake.md`.
 
-## Аргументы
+## Arguments
 
-Всё после `/task` — описание задачи на естественном языке.
+Everything after `/task` is the task description in natural language.
 
-Примеры:
+Examples:
 
-- `/task Добавить MCP tool list_resources`
-- `/task Handler падает при пустом body — пофикси`
-- `/task Project tests падают локально после правки schema — bugfix + build-verifier`
-- `/task Миграция на новый SDK / package`
-- `/task Покрой unit-тестами handler echo`
-- `/task Напиши changelog для релиза tool`
-- `/task Сделай ревью моих изменений в src/tools`
-- `/task Напиши contract/unit tests для tool schema`
+- `/task Add MCP tool list_resources`
+- `/task Handler crashes on empty body — fix it`
+- `/task Project tests fail locally after schema change — bugfix + build-verifier`
+- `/task Migrate to a new SDK / package`
+- `/task Cover handler echo with unit tests`
+- `/task Write changelog for tool release`
+- `/task Review my changes in src/tools`
+- `/task Write contract/unit tests for tool schema`
 
-## Алгоритм
+## Procedure
 
-1. **Slug** — kebab-case из описания (≤48 символов). Создай `.cursor/team/tasks/<slug>/` через **Write** (например placeholder `pipeline.json` или пустой marker) — runtime/hook владеет `status.json` — **не** через Shell `mkdir` (песочница → `Operation not permitted`).
-2. **Router** — вызови subagent **task-router** с описанием задачи и путём к slug.
-3. **План** — покажи пользователю таблицу из `pipeline.json`: intent, steps, skipped, humanGates.
-4. **Intent retro** — если `intent === "retro"`, выполни `/technical-retro` и **остановись**.
-5. **Старт** — после router:
-   - подтверди `pipeline.json` и `active-task.json`;
-   - **не** пиши lifecycle-поля `status.json` / `metrics.json` сам — их владеет orchestration runtime/hook (см. **agent-artifact-contracts**). Если `status.json` отсутствует, допустим только минимальный bootstrap (`slug`, `intent`, `pipelineIndex: 0`, `currentAgent: steps[0]`, `state: in_progress`) — **не** увеличивай `pipelineIndex` вручную;
-   - вызови subagent для `pipeline.steps[0].agent` (slug, пути к артефактам, scope).
-6. **После каждого агента** — дождись hook handoff / reconciliation terminal receipt → `status.state`; не запускай следующий шаг, пока `status.json` не отражает handoff (или пока нет `followup_message` от hook).
-7. **Human gate** — если после текущего шага есть gate в `humanGates` (`after:<agent>`), после завершения агента **остановись** и попроси `/task-continue <slug>` (или `/feature-continue <slug>`).
+1. **Slug** — kebab-case from the description (≤48 characters). Create `.claude/team/tasks/<slug>/` via Write / Edit; runtime/hook owns `status.json` — **do not** rely on Shell `mkdir` as the only way to create the directory.
+2. **Router** — invoke subagent **task-router** with the task description and slug path.
+3. **Plan** — show the user the table from `pipeline.json`: intent, steps, skipped, humanGates.
+4. **Intent retro** — if `intent === "retro"`, run `/technical-retro` and **stop**.
+5. **Start** — after router:
+   - confirm `pipeline.json` and `active-task.json`;
+   - **do not** write lifecycle fields in `status.json` / `metrics.json` yourself — orchestration runtime/hook owns them (see **agent-artifact-contracts**). If `status.json` is missing, only minimal bootstrap is allowed (`slug`, `intent`, `pipelineIndex: 0`, `currentAgent: steps[0]`, `state: in_progress`) — **do not** increment `pipelineIndex` manually;
+   - invoke subagent for `pipeline.steps[0].agent` (slug, artifact paths, scope).
+6. **After each agent** — wait for hook handoff / reconciliation terminal receipt → `status.state`; do not start the next step until `status.json` reflects handoff (or until hook returns `followup_message`).
+7. **Human gate** — if there is a gate in `humanGates` after the current step (`after:<agent>`), **stop** after the agent finishes and ask for `/task-continue <slug>` (or `/feature-continue <slug>`).
 
-## Не делать
+## Do not
 
-- Не вызывать developer до router и (если в pipeline) analyst/architect.
-- Не hardcode порядок ролей — только `pipeline.json`.
-- Не пропускать human gate без явного continue.
+- Invoke developer before router and (if in pipeline) analyst/architect.
+- Hardcode role order — only `pipeline.json`.
+- Skip human gate without explicit continue.
 
-## Если slug занят
+## If slug is taken
 
-- `awaitingHumanGate` / `state: awaiting_approval` → предложи ревью артефактов или `/task-continue <slug>`.
-- `in_progress` → спроси: продолжить или новый slug.
+- `awaitingHumanGate` / `state: awaiting_approval` → offer artifact review or `/task-continue <slug>`.
+- `in_progress` → ask: continue or new slug.
 
 ## Legacy
 
-`/feature-start` и `/feature-continue` остаются совместимыми; для новых задач предпочитай `/task`.
+`/feature-start` and `/feature-continue` remain compatible; for new tasks prefer `/task`.
 
 ## Metrics
 

package/presets/claude/mcp-ts/commands/technical-retro.md

@@ -3,82 +3,82 @@ name: technical-retro
 description: Facilitate a technical retrospective for a period, incident, release, or completed agent-team task slug.
 ---
 
-# Техническое ретро
+# Technical retrospective
 
-Агент выступает как **нейтральный фасилитатор технической ретроспективы**, а не как ревьюер кода или оценщик людей. **Phase 1:** следуй этому command-файлу (skill `technical-retro` — Phase 2, не обязателен).
+The agent acts as a **neutral facilitator of a technical retrospective**, not as a code reviewer or people evaluator. **Phase 1:** follow this command file (skill `technical-retro` is Phase 2, optional).
 
-## Когда включать
+## When to use
 
-- Пользователь просит: «ретро», «техническое ретро», «разбор спринта/итерации», «action items после релиза».
-- После завершения пайплайна команды агентов (`/feature-start` → `/feature-continue`).
-- Есть контекст: период, тема (релиз, инцидент), slug задачи, заметки.
+- User asks: "retro", "technical retro", "sprint/iteration review", "action items after release".
+- After completing the agent-team pipeline (`/feature-start` → `/feature-continue`).
+- Context available: period, topic (release, incident), task slug, notes.
 
-## Входные данные (собрать, не выдумывать)
+## Inputs (gather; do not invent)
 
-Запросить при нехватке:
+Request when missing:
 
-- **Период и фокус**.
-- **Slug задачи** (если ретро по работе команды агентов).
-- **Участники/роли** (если важно).
-- **Ограничения**: время, формат (async vs синхрон).
+- **Period and focus**.
+- **Task slug** (if retro is about agent-team work).
+- **Participants/roles** (if relevant).
+- **Constraints**: time, format (async vs sync).
 
-### Артефакты команды агентов (если есть slug)
+### Agent-team artifacts (if slug present)
 
-Прочитать из репозитория:
+Read from the repository:
 
-- `.cursor/team/tasks/<slug>/pipeline.json`
-- `.cursor/team/tasks/<slug>/brief.md`
-- `.cursor/team/tasks/<slug>/decomposition.md`
-- `.cursor/team/tasks/<slug>/status.json`
-- Git diff / `git status` для изменённых файлов
+- `.claude/team/tasks/<slug>/pipeline.json`
+- `.claude/team/tasks/<slug>/brief.md`
+- `.claude/team/tasks/<slug>/decomposition.md`
+- `.claude/team/tasks/<slug>/status.json`
+- Git diff / `git status` for changed files
 
-Не приписывать факты, которых нет в артефактах, diff или сообщении пользователя.
+Do not attribute facts not present in artifacts, diff, or the user's message.
 
-## Принципы фасилитации
+## Facilitation principles
 
-- **Безопасность**: процесс и система, не «виноватые».
-- **Конкретика**: от абстракций к наблюдаемым событиям.
-- **Баланс**: позитив и зоны роста.
-- **Action items**: владелец и срок у каждого.
-- **Не смешивать с code review** — развести блоки, если запросили оба.
+- **Safety**: process and system, not "blame".
+- **Specificity**: from abstractions to observable events.
+- **Balance**: positives and growth areas.
+- **Action items**: owner and deadline for each.
+- **Do not mix with code review** — separate blocks if both were requested.
 
-## Структура сессии (по умолчанию)
+## Default session structure
 
-1. **Цель и рамки**.
-2. **Сбор фактов**: хорошо / мешало / сюрпризы.
-3. **Группировка тем** (3–7).
-4. **Корневые причины** для 1–2 болезненных тем.
-5. **Эксперименты** (1–3 изменения процесса).
-6. **Action items**: что / владелец / до когда / критерий успеха.
+1. **Goal and scope**.
+2. **Fact gathering**: went well / blocked / surprises.
+3. **Theme grouping** (3–7).
+4. **Root causes** for 1–2 painful themes.
+5. **Experiments** (1–3 process changes).
+6. **Action items**: what / owner / by when / success criteria.
 
-## Блок «Работа агентов» (обязателен при slug)
+## "Agent work" block (required when slug present)
 
-Если ретро связано с пайплайном `/feature-start`:
+If retro is tied to a `/feature-start` pipeline:
 
-| Вопрос | Что фиксировать |
-|--------|-----------------|
-| Router | Ошибка intent, лишние/пропущенные steps в pipeline |
-| Аналитик | Ошибки в assumptions, пропущенные AC, лишние/недостающие таски |
-| Декомпозиция | Неполное покрытие слоёв, неверный порядок, blocked-зависимости |
-| Developer | Scope creep, пропущенные правила, lint/type gaps |
-| Reviewer | Пропущенные дефекты, false positives, качество чеклиста |
-| QA | Покрытие AC тестами, flakiness, пробелы в e2e планах |
+| Question | What to capture |
+|----------|-----------------|
+| Router | Intent error, extra/missing pipeline steps |
+| Analyst | Assumption errors, missed AC, extra/missing tasks |
+| Decomposition | Incomplete layer coverage, wrong order, blocked dependencies |
+| Developer | Scope creep, missed rules, typecheck/test gaps |
+| Reviewer | Missed defects, false positives, checklist quality |
+| QA | AC test coverage, flakiness, contract/unit plan gaps |
 
-**Action items** в этом блоке — на улучшение **промптов, subagents и rules** (не только кода).
+**Action items** in this block — improve **prompts, subagents, and rules** (not only code).
 
-## Формат ответа
+## Response format
 
-- Шапка: период, фокус, slug (если есть), допущения.
-- Повестка по этапам.
-- Блок **«Работа агентов»** (если применимо).
-- Темы — буллеты; спорное — **вопросы команде**.
-- **Action items** в конце.
+- Header: period, focus, slug (if any), assumptions.
+- Agenda by stage.
+- **"Agent work"** block (if applicable).
+- Themes — bullets; disputed points — **questions for the team**.
+- **Action items** at the end.
 
-## Ограничения
+## Constraints
 
-- Не приписывать цитаты и факты без входа.
-- Не выдавать HR‑рекомендации.
-- Если просят только шаблон — **шаблон повестки** без выдуманного контента.
+- Do not attribute quotes or facts without input.
+- No HR recommendations.
+- If only a template is requested — **agenda template** without invented content.
 
 ### Metrics evidence
 

package/presets/claude/mcp-ts/rules/architecture/mcp-server-boundaries.md

@@ -2,7 +2,7 @@
 description: MCP server module boundaries: registration, handler, capability, lifecycle
 ---
 
-# Границы MCP-сервера
+# MCP server boundaries
 
 Dependency direction:
 
@@ -22,7 +22,7 @@ MCP client → transport/entry → registration → schema + handler → scoped
 - auth/config/env → `mcp-auth-secrets` + `security-mcp`
 - After `*.ts` edits → `post-change-test` (+ `mcp-ts-tooling`)
 
-# Требование к агенту
+# Agent requirement
 
 - Keep registration, validation, and handlers separable — avoid a monolithic `index.ts`.
 - Prefer least privilege for every tool capability.

package/presets/claude/mcp-ts/rules/stack/mcp-ts-app-core.md

@@ -2,18 +2,18 @@
 description: TypeScript MCP stack, layout, stdio-first entry (mcp-ts preset)
 ---
 
-# Стек и окружение
+# Stack and environment
 
-Версии Node, TypeScript и `@modelcontextprotocol/sdk` — **из `package.json` / lockfile целевого репозитория**. Рамка preset:
+Node, TypeScript, and `@modelcontextprotocol/sdk` versions come **from the target repository `package.json` / lockfile**. Preset frame:
 
-- **Язык / платформа:** TypeScript (Node); package manager — discover from lockfile / `packageManager`.
+- **Language / platform:** TypeScript (Node); package manager — discover from lockfile / `packageManager`.
 - **SDK:** official `@modelcontextprotocol/sdk` — verify APIs before use (`VERIFY:` markers when unsure).
-- **Транспорт по умолчанию:** **stdio-first**; remote HTTP/auth — requestable rules only.
-- **Точка входа:** `src/index.ts` (or repo equivalent) owns transport + lifecycle — not individual tools.
-- **Тесты:** repository runner (Vitest/Jest/node:test); contract fixtures for schemas — see `mcp-contract-testing`.
-- **Наблюдаемость:** only if already in repo — never log secrets or full tool payloads with credentials.
+- **Default transport:** **stdio-first**; remote HTTP/auth — requestable rules only.
+- **Entry point:** `src/index.ts` (or repo equivalent) owns transport + lifecycle — not individual tools.
+- **Tests:** repository runner (Vitest/Jest/node:test); contract fixtures for schemas — see `mcp-contract-testing`.
+- **Observability:** only if already in repo — never log secrets or full tool payloads with credentials.
 
-# Структура (suggested)
+# Structure (suggested)
 
 ```text
 src/index.ts                 # transport + server lifecycle
@@ -24,4 +24,4 @@ src/**/schemas.ts            # Zod authoring schemas
 package.json                 # bin / main for stdio packaging
 ```
 
-Границы — **`mcp-server-boundaries`**. Tooling — requestable **`mcp-ts-tooling`**. После правок TS — **`post-change-test`**.
+Boundaries — **`mcp-server-boundaries`**. Tooling — requestable **`mcp-ts-tooling`**. After TS edits — **`post-change-test`**.

package/presets/claude/mcp-ts/rules/tooling-and-review/agent-team-intake.md

@@ -13,11 +13,11 @@ When the user message looks like a **work request** (implement, add, fix, refact
 
 1. Prefer **`/task <their request>`** or invoke **task-router** first.
 2. Do not jump straight to coding without router + pipeline when scope is non-trivial.
-3. Pure questions («как работает X», «объясни») — prefer agent **`codebase-analyzer`** (explain-as-is); trivial one-liners may be answered inline. Do not open `/task`.
+3. Pure questions (“how does X work”, “explain”) — prefer agent **`codebase-analyzer`** (explain-as-is); trivial one-liners may be answered inline. Do not open `/task`.
 
-Exceptions: user explicitly says «без pipeline», «просто сделай», or continues an active slug.
+Exceptions: user explicitly says “no pipeline”, “just do it”, or continues an active slug.
 
 ## Stack notes
 
 - Scope: TypeScript MCP server modules (`src/tools|resources|prompts`, `src/index.ts`) — not Next `app/src`, iOS `Features/`, Go `cmd/`/`internal/**`, or Playwright/XCUITest UI flows.
-- **Phase 1 override:** no `codebase-analyzer` agent. For explain-as-is («как работает X»), answer inline or load requestable MCP rules (`mcp-server-boundaries`, `mcp-tool-design`) — do **not** invoke a missing subagent.
+- **Phase 1 override:** no `codebase-analyzer` agent. For explain-as-is ("how does X work"), answer inline or load requestable MCP rules (`mcp-server-boundaries`, `mcp-tool-design`) — do **not** invoke a missing subagent.

package/presets/claude/mcp-ts/rules/tooling-and-review/agent-team-orchestrator.md

@@ -11,7 +11,7 @@ paths:
 
 Parent agent = **manager**. Router plans; specialists execute. Artifacts: `.cursor/team/tasks/<slug>/` (Claude: `.claude/team/tasks/<slug>/`).
 
-Work request без `/task` — см. **agent-team-intake** (когда предлагать router вместо прямого кодинга).
+Work request without `/task` — see **agent-team-intake** (when to suggest the router instead of coding directly).
 
 ## Entry points
 
@@ -164,12 +164,12 @@ If `pipeline.json` is missing (old `/feature-start` tasks), fall back to fixed p
 
 Do **not** run `/task` + router for:
 
-- Pure questions («как работает X», «объясни») — prefer agent **`codebase-analyzer`** for deep traces; inline OK for trivial one-liners.
+- Pure questions (“how does X work”, “explain”) — prefer agent **`codebase-analyzer`** for deep traces; inline OK for trivial one-liners.
 - Typo / one-file fix / trivial config with no architecture risk.
-- User explicitly says «без pipeline», «просто сделай», or continues an active slug.
+- User explicitly says “no pipeline”, “just do it”, or continues an active slug.
 - Single-line `docs-only` with no code impact.
 
-Borderline work requests — см. **agent-team-intake**.
+Borderline work requests — see **agent-team-intake**.
 
 ## Auto-detection (optional)
 

package/presets/claude/mcp-ts/rules/tooling-and-review/code-quality.md

@@ -4,47 +4,48 @@ description: Code quality and light refactoring for TypeScript MCP servers
 
 <!-- shared-core: quality/code-quality-and-refactoring.md -->
 
-# Поддержка существующего стиля
+# Match existing style
 
-- Следовать существующим паттернам (имена, структура, типизация / DI / error handling); минимизировать стилистический шум (лишний format/rename).
-- Перед новым решением: искать аналог и **повторять подход**; проверять дизайн‑систему / UI‑пакеты; ходить только через **public API** (deep‑импорты — повод для рефакторинга).
+- Follow existing patterns (names, structure, typing / DI / error handling); avoid drive-by formatting or renames.
+- Before a new solution: find an analog and **repeat the approach**; check the design system / UI packages; go only through the **public API** (deep imports are a reason to refactor).
 
-# Принципы
+# Principles
 
-- **KISS:** самое простое изменение в паттернах репозитория.
-- **DRY + Rule of Three:** общее — только после 3-го повторения (ошибочная абстракция дороже дублирования).
-- **YAGNI:** без API, флагов, слоёв «на будущее» без текущего требования.
-- **SOLID:** S — один повод менять; O — композиция/новые реализации; L — контракт подтипа; I — узкие порты; D — абстракции (порты), детали в адаптерах стека.
-- **CUPID:** Composable; Unix philosophy (одна ответственность); Predictable; Idiomatic (репо); Domain-based.
-- **Composition over inheritance;** Law of Demeter — без цепочек `a.b.c.d`; через public API / facade.
+- **KISS:** the simplest change in the repository’s patterns.
+- **DRY + Rule of Three:** share only after the 3rd repetition (wrong abstraction costs more than duplication).
+- **YAGNI:** no APIs, flags, or “for later” layers without a current requirement.
+- **SOLID:** S — one reason to change; O — composition/new implementations; L — subtype contract; I — narrow ports; D — abstractions (ports), details in stack adapters.
+- **CUPID:** Composable; Unix philosophy (one responsibility); Predictable; Idiomatic (repo); Domain-based.
+- **Composition over inheritance;** Law of Demeter — no `a.b.c.d` chains; via public API / facade.
 
-# Рефакторинг при изменениях
+# Refactoring during changes
 
-- Лёгкий refactor OK, если меньше дублирования, выше читаемость, без ломки публичных контрактов.
-- Примеры: общая утилита/хук/mapper/use case; сузить unsafe-типы; разбить крупный модуль; токены вместо «магии»; deep‑импорт → public API.
-- Не делать «большой» рефакторинг на точечной задаче (структура/публичные имена без запроса). Крупное — минимальными шагами; код остаётся собираемым.
+- Light refactor is OK if it reduces duplication, improves readability, and does not break public contracts.
+- Examples: shared utility/hook/mapper/use case; narrow unsafe types; split a large module; tokens instead of “magic”; deep import → public API.
+- Do not do a “big” refactor on a point task (structure/public names without a request). Break large work into minimal steps; keep the repo buildable after each step.
 
-# Требование к агенту
+# Agent requirement
 
-- **Boy scout:** оставлять модуль немного лучше; не жертвовать архитектурой и слоями ради краткости.
+- **Boy scout:** leave the module a bit better; do not sacrifice architecture and layers for brevity.
 
 ## Agent discipline (anti-sycophancy)
 
 Essentials below. Full procedural set (~17 rules) → load **`anti-sycophancy-discipline`**.
 
 - Unverifiable third-party API → mark `// VERIFY: lib.symbol @ version` (or stack equivalent); never invent signatures.
-- Before «is this correct?» — ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
+- Before "is this correct?" — ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
 - Refactor without tests → propose characterization test; if declined, label `UNTESTED`.
-- Comments = WHY only when non-obvious; ban self-referential «added for issue Y».
+- Comments = WHY only when non-obvious; ban self-referential "added for issue Y".
 - Urgency/authority: name the trade-off once, then comply — no apology loops.
 - Match verification to risk; report by what was **verified**, not attempted.
 
 Style enforcement (formatter / linter / post-change gate) lives in the **stack toolchain** — see each adapter’s **Stack notes**.
 
-> Stack-specific lint gates, примеры и toolchain — в секции **Stack notes** адаптера пресета.
+> Stack-specific lint gates, examples, and toolchain — in the preset adapter **Stack notes** section.
+
 ## Stack notes
 
-- **No UI layer in this preset** — ignore shared-core bullets about дизайн‑система / UI‑пакеты / CSS‑токены; apply public-API and boy-scout rules to MCP registration modules and handlers.
+- **No UI layer in this preset** — ignore shared-core bullets about design system / UI packages / CSS tokens; apply public-API and boy-scout rules to MCP registration modules and handlers.
 - Public surface: tool/resource/prompt names + JSON Schema-compatible contracts — avoid deep imports across unrelated modules.
 - Prefer Zod for authoring validation; MCP-facing schemas are protocol JSON Schema (SDK-supported conversion) — never pass raw Zod objects as the wire contract without verification.
 - Unverifiable SDK usage → `// VERIFY: @modelcontextprotocol/sdk @ <version>`.

package/presets/claude/mcp-ts/rules/tooling-and-review/code-review.md

@@ -23,9 +23,9 @@ On-demand rule for review flows. **Procedure and output format:** skill `code-re
 - UI conventions of the stack
 - Unit and e2e/UI test conventions
 - Post-change lint/build gate before final report
-- Design smells **in MR diff scope** — load `design-guidance`; не разворачивать полный каталог Fowler вне диффа
-- Pattern name (GoF) — только если репозиторий уже использует эту форму или match минимален
-- Principles (KISS / DRY+Ro3 / YAGNI / SOLID / CUPID) — через always-on `code-quality-and-refactoring`, не дублировать эссе в review
+- Design smells **in MR diff scope** — load `design-guidance`; do not expand the full Fowler catalog outside the diff
+- Pattern name (GoF) — only if the repository already uses that shape or the match is minimal
+- Principles (KISS / DRY+Ro3 / YAGNI / SOLID / CUPID) — via always-on `code-quality-and-refactoring`, do not duplicate the essay in review
 
 Concrete rule stems — in **Stack notes**.
 
@@ -34,7 +34,7 @@ Concrete rule stems — in **Stack notes**.
 - Focus on MR diff, not the whole repo.
 - Use local `git diff` — do not invent hosting metadata.
 - Boy scout rule: suggest fixes feasible within the MR scope.
-- No «большие рефакторинги» without an explicit request (`code-quality-and-refactoring`).
+- No “big refactors” without an explicit request (`code-quality-and-refactoring`).
 
 ## Output contract
 
@@ -44,6 +44,7 @@ Procedure details live in skill `code-review`. Required shape:
 - Rank by severity: **`blocker` | `important` | `nit`** (list blocker → nit).
 - Vague («looks risky») is not a finding — cite evidence or ask for surrounding file context.
 - End with a verdict on its own line: **`Safe to merge | needs changes | reject`**.
+
 ## Stack notes
 
 - Check MCP boundaries: registration vs handler vs capability; schema/contract stability; no secret leakage.