@bonesofspring/ai-rules 0.2.13 → 0.2.15

package/presets/cursor/ios-swift/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 retro
 
-Агент выступает как **нейтральный фасилитатор технической ретроспективы**, а не как ревьюер кода или оценщик людей. Используй skill **`technical-retro`** как основной сценарий.
+Act as a **neutral technical retrospective facilitator**, not a code reviewer or people evaluator. Use skill **`technical-retro`** as the primary playbook.
 
-## Когда включать
+## When to run
 
-- Пользователь просит: «ретро», «техническое ретро», «разбор спринта/итерации», «action items после релиза».
-- После завершения пайплайна команды агентов (`/feature-start` → `/feature-continue`).
-- Есть контекст: период, тема (релиз, инцидент), slug задачи, заметки.
+- User asks for: “retro”, “technical retro”, “sprint/iteration review”, “action items after release”.
+- After an agent-team pipeline completes (`/feature-start` → `/feature-continue`).
+- Context exists: period, topic (release, incident), task slug, notes.
 
-## Входные данные (собрать, не выдумывать)
+## Inputs (collect, do not invent)
 
-Запросить при нехватке:
+Ask when missing:
 
-- **Период и фокус**.
-- **Slug задачи** (если ретро по работе команды агентов).
-- **Участники/роли** (если важно).
-- **Ограничения**: время, формат (async vs синхрон).
+- **Period and focus**.
+- **Task slug** (if the retro covers agent-team work).
+- **Participants/roles** (when relevant).
+- **Constraints**: time, format (async vs sync).
 
-### Артефакты команды агентов (если есть slug)
+### Agent-team artifacts (when there is a slug)
 
-Прочитать из репозитория:
+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` для изменённых файлов
+- Git diff / `git status` for changed files
 
-Не приписывать факты, которых нет в артефактах, diff или сообщении пользователя.
+Do not attribute facts that are not in artifacts, the diff, or the user message.
 
-## Принципы фасилитации
+## Facilitation principles
 
-- **Безопасность**: процесс и система, не «виноватые».
-- **Конкретика**: от абстракций к наблюдаемым событиям.
-- **Баланс**: позитив и зоны роста.
-- **Action items**: владелец и срок у каждого.
-- **Не смешивать с code review** — развести блоки, если запросили оба.
+- **Safety**: process and system, not “blame”.
+- **Specifics**: from abstractions to observable events.
+- **Balance**: positives and growth areas.
+- **Action items**: owner and due date for each.
+- **Do not mix with code review** — keep blocks separate if both are requested.
 
-## Структура сессии (по умолчанию)
+## Default session structure
 
-1. **Цель и рамки**.
-2. **Сбор фактов**: хорошо / мешало / сюрпризы.
-3. **Группировка тем** (3–7).
-4. **Корневые причины** для 1–2 болезненных тем.
-5. **Эксперименты** (1–3 изменения процесса).
-6. **Action items**: что / владелец / до когда / критерий успеха.
+1. **Goal and frame**.
+2. **Gather facts**: went well / got in the way / surprises.
+3. **Theme clustering** (3–7).
+4. **Root causes** for 1–2 painful themes.
+5. **Experiments** (1–3 process changes).
+6. **Action items**: what / owner / by when / success criterion.
 
-## Блок «Работа агентов» (обязателен при slug)
+## “Agent work” block (required when there is a slug)
 
-Если ретро связано с пайплайном `/feature-start`:
+If the retro relates 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 | Wrong intent, extra/missing steps in pipeline |
+| Analyst | Bad assumptions, missed AC, extra/missing tasks |
+| Decomposition | Incomplete layer coverage, wrong order, blocked dependencies |
+| Developer | Scope creep, missed rules, lint/type gaps |
+| Reviewer | Missed defects, false positives, checklist quality |
+| QA | AC coverage by tests, flakiness, gaps in e2e plans |
 
-**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 stages.
+- **“Agent work”** block (when applicable).
+- Themes — bullets; disputed items — **questions for the team**.
+- **Action items** at the end.
 
-## Ограничения
+## Constraints
 
-- Не приписывать цитаты и факты без входа.
-- Не выдавать HR‑рекомендации.
-- Если просят только шаблон — **шаблон повестки** без выдуманного контента.
+- Do not invent quotes and facts without input.
+- Do not give HR recommendations.
+- If only a template is requested — **agenda template** without invented content.
 
 ### Metrics evidence
 

package/presets/cursor/ios-swift/rules/README.md

@@ -1,34 +1,34 @@
-### Разница .mdc и .md в .cursor/rules
+### Difference between .mdc and .md in .cursor/rules
 
 #### .md
-Обычный markdown‑файл. Cursor видит его как документацию/контент, но не как правило, которое нужно автоматически применять.
+Ordinary markdown. Cursor treats it as documentation/content, not as a rule to apply automatically.
 
 #### .mdc
-Специальный формат Cursor Rule:
-- сверху обязателен YAML‑frontmatter с полями вроде description, globs, alwaysApply;
-- файл лежит в .cursor/rules/;
-- Cursor интерпретирует его как конфигурацию поведения ассистента для этого репо (автоматически подмешивает содержимое в контекст, когда правило подходит).
+Cursor Rule format:
+- YAML frontmatter at the top with fields such as description, globs, alwaysApply;
+- lives under `.cursor/rules/`;
+- Cursor treats it as assistant behavior configuration for this repo (injects content when the rule matches).
 
-- То есть .mdc = “markdown + config для Cursor”, .md = просто текст без управляющего смысла для ассистента.
+- So `.mdc` = “markdown + Cursor config”; `.md` = plain text with no control meaning for the assistant.
 
-### Пресет ios-swift — карта правил
+### Preset ios-swift — rule map
 
-**alwaysApply budget:** **≤3** always-on правила и **≤140** строк тела (после YAML) суммарно (stretch ≤120). Новые alwaysApply только вместе с сокращением существующего бюджета.
+**alwaysApply budget:** **≤3** always-on rules and **≤140** body lines (after YAML) total (stretch ≤120). New alwaysApply only together with shrinking the existing budget.
 
-| Файл | Скоуп | Тема |
+| File | Scope | Topic |
 |------|--------|------|
-| `ios-app-core.mdc` | **always** | Стек, структура, tips (+ pointers на tooling/build) |
-| `architecture-boundaries.mdc` | **always** | Границы Presentation / Domain / Data, DI |
-| `code-quality-and-refactoring.mdc` | **always** | Качество и лёгкий refactor |
+| `ios-app-core.mdc` | **always** | Stack, structure, tips (+ pointers to tooling/build) |
+| `architecture-boundaries.mdc` | **always** | Presentation / Domain / Data boundaries, DI |
+| `code-quality-and-refactoring.mdc` | **always** | Quality and light refactor |
 | `anti-sycophancy-discipline.mdc` | requestable | Full VERIFY/anti-sycophancy discipline (~17 rules) |
 | `design-guidance.mdc` | requestable | Smells/GoF (Fowler≤12, GoF≤8) |
-| `xcode-tooling.mdc` | requestable | Схемы, xcodebuild, SwiftLint/Format |
-| `post-change-build.mdc` | requestable | Сборка/lint после Swift edits (**обязателен** после code edits) |
-| `agent-team-intake.mdc` | requestable | Подсказка `/task` |
+| `xcode-tooling.mdc` | requestable | Schemes, xcodebuild, SwiftLint/Format |
+| `post-change-build.mdc` | requestable | Build/lint after Swift edits (**required** after code edits) |
+| `agent-team-intake.mdc` | requestable | `/task` hint |
 | `agent-team-orchestrator.mdc` | requestable | Pipeline, gates, build-verifier |
-| `feature-delivery-workflow.mdc` | requestable | Чеклист доставки фичи |
-| `code-review-mr.mdc` | requestable | Ревью MR/diff |
-| `reference-features.mdc` | globs Features/** | Эталоны Feature + dogfood |
+| `feature-delivery-workflow.mdc` | requestable | Feature delivery checklist |
+| `code-review-mr.mdc` | requestable | MR/diff review |
+| `reference-features.mdc` | globs Features/** | Reference Features + dogfood |
 | `technical-retro.mdc` | requestable | Alias → `/technical-retro` |
 | `preset-layering.mdc` (+ `preset-*`) | globs presets/** | Author meta (never alwaysApply) |
 | `swiftui-ui.mdc` | Presentation, DesignSystem | SwiftUI, a11y |
@@ -42,9 +42,9 @@
 | `tests-unit.mdc` | `*Tests` | Unit |
 | `tests-ui.mdc` | `*UITests` | XCUITest (+ pointer to xcuitest agents/skill) |
 
-**Всего topic `.mdc`:** 22 domain + 5 preset-meta (без README).
+**Topic `.mdc` total:** 22 domain + 5 preset-meta (excluding README).
 
-**Twin depth (Cursor↔Claude):** domain rules ≥15 body lines. Thin requestable **aliases** (`agent-team-intake`, `technical-retro`) могут быть короче — как в next (soft AC-19).
+**Twin depth (Cursor↔Claude):** domain rules ≥15 body lines. Thin requestable **aliases** (`agent-team-intake`, `technical-retro`) may be shorter — as in next (soft AC-19).
 
 ### Shared core → stack mapping
 
@@ -67,7 +67,7 @@ Claude map: `presets/claude/ios-swift/rules/README.md`. Taxonomy: `presets/_shar
 
 ### Presentation edit bundle
 
-При правке `**/Presentation/**` или `**/DesignSystem/**`: грузить `swiftui-ui` + `state-and-viewmodels` (+ `navigation-coordinators` при правке навигации). Не подмешивать orchestrator.
+When editing `**/Presentation/**` or `**/DesignSystem/**`: load `swiftui-ui` + `state-and-viewmodels` (+ `navigation-coordinators` when editing navigation). Do not pull in the orchestrator.
 
 ### Loading strategy
 
@@ -85,7 +85,7 @@ globs
      security, modules, conventions, tests-*
 ```
 
-Установка: `npx @bonesofspring/ai-rules init cursor --preset ios-swift`
+Install: `npx @bonesofspring/ai-rules init cursor --preset ios-swift`
 
 ## Metrics policy mapping
 

package/presets/cursor/ios-swift/rules/agent-team-intake.mdc

@@ -11,6 +11,6 @@ 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.

package/presets/cursor/ios-swift/rules/agent-team-orchestrator.mdc

@@ -9,7 +9,7 @@ alwaysApply: false
 
 Parent agent = **manager**. Router plans; specialists execute. Artifacts: `.cursor/team/tasks/<slug>/`.
 
-Work request без `/task` — см. **`agent-team-intake.mdc`**.
+Work request without `/task` — see **`agent-team-intake.mdc`**.
 
 ## Entry points
 
@@ -119,6 +119,6 @@ Honor optional `steps[i].model` (`cheap` \| `standard` \| `strong`); else agent
 
 ## Skip pipeline when
 
-- Pure questions («как работает X») — prefer **`codebase-analyzer`**; typo / one-file trivial fix; user «без pipeline»; single-line docs-only.
+- Pure questions (“how does X work?”) — prefer **`codebase-analyzer`**; typo / one-file trivial fix; user “no pipeline”; single-line docs-only.
 
 Borderline — **`agent-team-intake.mdc`**.

package/presets/cursor/ios-swift/rules/architecture-boundaries.mdc

@@ -1,34 +1,34 @@
 ---
-description: Архитектурные границы и правила зависимостей iOS приложения
+description: Architectural boundaries and dependency rules for an iOS app
 alwaysApply: true
 ---
 
-# Границы между слоями
+# Layer boundaries
 
 - **Presentation** (Views, ViewModels, DesignSystem):
-  - Может: Domain (entities, use case protocols), DesignSystem, Core (без UI).
-  - Не должен: импортировать Data (репозитории, DTO, API-клиенты); знать HTTP/Codable/эндпоинты; маппить DTO → domain.
+  - May: Domain (entities, use case protocols), DesignSystem, Core (non-UI).
+  - Must not: import Data (repositories, DTOs, API clients); know HTTP/Codable/endpoints; map DTO → domain.
 - **Domain**:
-  - Может: Core (базовые типы, протоколы).
-  - Не должен: импортировать SwiftUI, UIKit, сеть; знать конкретные реализации репозиториев.
+  - May: Core (base types, protocols).
+  - Must not: import SwiftUI, UIKit, networking; know concrete repository implementations.
 - **Data**:
-  - Может: Domain (протоколы, entities), Core.
-  - Не должен: импортировать SwiftUI/UIKit; зависеть от View/ViewModel.
+  - May: Domain (protocols, entities), Core.
+  - Must not: import SwiftUI/UIKit; depend on View/ViewModel.
 
-# Зависимости и модули
+# Dependencies and modules
 
-- Направление: **Presentation → Domain ← Data**.
-- Переиспользуемое — в Core / DesignSystem; к другой фиче — только **public API** (протокол, facade, coordinator), не deep-import.
-- SPM: Domain не линкуется с Data; реализации Data подключаются через DI в `App/`.
-- Раскладка фичи — как в `ios-app-core.mdc` / соседних `Features/*` репо (Presentation / Domain / Data + тесты).
+- Direction: **Presentation → Domain ← Data**.
+- Shared code — in Core / DesignSystem; to another feature — only **public API** (protocol, facade, coordinator), not deep-import.
+- SPM: Domain does not link Data; Data implementations are wired via DI in `App/`.
+- Feature layout — as in `ios-app-core.mdc` / neighboring `Features/*` in the repo (Presentation / Domain / Data + tests).
 
-# DI и composition root
+# DI and composition root
 
-- Сборка графа — в `App/` (или `DI/` / CompositionRoot), не во View.
-- ViewModel получает **протоколы** (use case / repository), не конкретные Data-типы.
-- Preview и тесты — mock/stub реализаций.
+- Graph assembly — in `App/` (or `DI/` / CompositionRoot), not in the View.
+- ViewModel receives **protocols** (use case / repository), not concrete Data types.
+- Previews and tests — mock/stub implementations.
 
-# Требование к агенту
+# Agent requirement
 
-- Файлы — в соответствующих слоях; протоколы репозиториев в Domain, реализации в Data.
-- Не «коротить» слои (API из View «ради скорости»).
+- Place files in the matching layers; repository protocols in Domain, implementations in Data.
+- Do not “short-circuit” layers (API from a View “for speed”).

package/presets/cursor/ios-swift/rules/code-quality-and-refactoring.mdc

@@ -1,52 +1,53 @@
 ---
-description: Поддержка и улучшение качества кода и архитектуры iOS
+description: Maintain and improve iOS code quality and architecture
 alwaysApply: true
 ---
 
 <!-- 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
 
-- Перед новым UI‑контролом проверять DesignSystem и существующие компоненты.
-- Public API: протоколы и facades между фичами.
-- Допустимые примеры: общий mapper/validation; заменить force unwrap; разбить перегруженный ViewModel на use cases; design tokens вместо magic numbers/colors; убрать прямую зависимость View от Data в пользу протокола.
-- Post-change gate: **`post-change-build.mdc`** + `xcode-tooling.mdc` (не yarn lint).
+- Before adding a new UI control, check DesignSystem and existing components.
+- Public API: protocols and facades between features.
+- Acceptable examples: shared mapper/validation; replace force unwrap; split an overloaded ViewModel into use cases; design tokens instead of magic numbers/colors; remove a direct View→Data dependency in favor of a protocol.
+- Post-change gate: **`post-change-build.mdc`** + `xcode-tooling.mdc` (not yarn lint).
 - Style: **SwiftLint** (+ SwiftFormat when configured) — authoritative style gate; do not duplicate linter rules in prose.

package/presets/cursor/ios-swift/rules/code-review-mr.mdc

@@ -1,5 +1,5 @@
 ---
-description: Требования к code review для iOS merge requests. Use when reviewing MR/diff/PR, evaluating a branch, or when the user asks for code review.
+description: Code review requirements for iOS merge requests. Use when reviewing MR/diff/PR, evaluating a branch, or when the user asks for code review.
 alwaysApply: false
 ---
 
@@ -22,9 +22,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**.
 
@@ -33,7 +33,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
 
@@ -46,39 +46,39 @@ Procedure details live in skill `code-review`. Required shape:
 
 ## Stack notes
 
-On-demand правило для review-потоков (не always-on).
-
-- **Когда применять**
-  - Запросы: «проведи ревью», «оцени MR/ветку/дифф», «посмотри изменения».
-  - Опираться на локальный репозиторий: ветка, `git diff`, открытые файлы.
-
-- **Что обязан проверить агент**
-  - **Архитектура и слои** (`architecture-boundaries.mdc`, `ios-app-core.mdc`):
-    - View не вызывает API и не знает DTO.
-    - ViewModel не зависит от Data-реализаций напрямую.
-    - Domain не импортирует SwiftUI/UIKit.
-    - Data не тянет Presentation.
-  - **Зависимости и модули**:
-    - DI через протоколы; composition root в App.
-    - Нет deep-import между фичами.
-    - Файлы в правильных слоях (`Presentation`, `Domain`, `Data`, `DesignSystem`).
-  - **Swift и concurrency** (`swift-conventions.mdc`):
-    - `@MainActor` на UI; нет необоснованных force unwrap.
-    - Typed errors; корректная отмена Task где нужно.
+On-demand rule for review flows (not always-on).
+
+- **When to apply**
+  - Requests: “review this”, “evaluate the MR/branch/diff”, “look at the changes”.
+  - Rely on the local repository: branch, `git diff`, open files.
+
+- **What the agent must check**
+  - **Architecture and layers** (`architecture-boundaries.mdc`, `ios-app-core.mdc`):
+    - View does not call APIs and does not know DTOs.
+    - ViewModel does not depend on Data implementations directly.
+    - Domain does not import SwiftUI/UIKit.
+    - Data does not pull Presentation.
+  - **Dependencies and modules**:
+    - DI via protocols; composition root in App.
+    - No deep-import between features.
+    - Files in the correct layers (`Presentation`, `Domain`, `Data`, `DesignSystem`).
+  - **Swift and concurrency** (`swift-conventions.mdc`):
+    - `@MainActor` on UI; no unjustified force unwraps.
+    - Typed errors; correct Task cancellation where needed.
   - **UI** (`swiftui-ui.mdc`):
-    - Тонкие Views; Design System tokens; accessibility identifiers для тестируемых элементов.
-  - **Сеть и data** (`networking-services.mdc`):
-    - DTO отделены от domain; mappers покрывают edge cases.
-  - **Тесты**:
-    - Нетривиальная логика — unit (`tests-unit.mdc`); пользовательские потоки — UI (`tests-ui.mdc`).
-    - Указать, какие тесты добавить или обновить.
-
-- **Глубина и формат**
-  - Фокус на **диффе MR**, не на всём проекте.
-  - Сначала обзор (цель MR, риски), затем конкретные комментарии с файлом и предложением fix по паттернам репо.
-  - Без «больших рефакторингов» без запроса (`code-quality-and-refactoring.mdc`).
-
-- **Ограничения**
-  - Не выдумывать метаданные CI/MR с хостинга без локальных данных.
-  - Boy scout rule в рамках MR.
-  - BUGBOT automated review — см. корневой `BUGBOT.md` (Cursor).
+    - Thin Views; Design System tokens; accessibility identifiers for testable elements.
+  - **Networking and data** (`networking-services.mdc`):
+    - DTOs separated from domain; mappers cover edge cases.
+  - **Tests**:
+    - Non-trivial logic — unit (`tests-unit.mdc`); user flows — UI (`tests-ui.mdc`).
+    - State which tests to add or update.
+
+- **Depth and format**
+  - Focus on the **MR diff**, not the whole project.
+  - Overview first (MR goal, risks), then concrete comments with file and a fix suggestion matching repo patterns.
+  - No “big refactors” without a request (`code-quality-and-refactoring.mdc`).
+
+- **Constraints**
+  - Do not invent CI/MR hosting metadata without local data.
+  - Boy scout rule within the MR.
+  - BUGBOT automated review — see root `BUGBOT.md` (Cursor).