@bonesofspring/ai-rules 0.2.1 → 0.2.3

package/presets/cursor/ios-swift/rules/post-change-build.mdc

@@ -0,0 +1,32 @@
+---
+description: Сборка и lint после изменений Swift/iOS кода. Use after editing iOS/Swift sources, Xcode targets, or Package.swift.
+alwaysApply: false
+---
+
+# Сборка и lint после изменений
+
+## Когда применять
+
+После изменений исходников Swift / проектных файлов Xcode / `Package.swift`, влияющих на компиляцию или стиль.
+
+Исключения: только документация, README, `.cursor/rules/**` без правок app-кода.
+
+**Pipeline:** если следующий шаг — отдельный verifier/CI-агент, достаточно затронутых таргетов; в single-agent режиме — полный разумный прогон как в репо.
+
+## Как определить команды
+
+1. Схемы / таргеты — из `.xcodeproj` / `.xcworkspace` / `Package.swift` (как в CI или соседних скриптах).
+2. Lint — `SwiftLint` / `.swiftlint.yml`, если есть.
+3. Format — `SwiftFormat` / конфиг, если принято в репо.
+4. Тесты — XCTest или Swift Testing — только если задача их затрагивает.
+
+Не угадывать чужой toolchain: копировать флаги/`xcodebuild` из Makefile, scripts, CI.
+
+## Алгоритм
+
+1. Завершить правки.
+2. Собрать **затронутые** таргеты (`xcodebuild` / `swift build` — как в репо).
+3. Прогнать lint/format при наличии конфигов; исправить ошибки в файлах задачи.
+4. Повторить до чистой сборки или зафиксировать блокер пользователю.
+
+**Errors** — обязательно; warnings в файлах задачи — по возможности до нуля.

package/presets/cursor/ios-swift/rules/reference-features.mdc

@@ -0,0 +1,53 @@
+---
+description: Эталонные Feature-модули репозитория — копировать структуру при реализации. Заполните пути после init в целевом iOS-репо.
+globs:
+  - Features/**/*
+  - "**/Presentation/**/*"
+  - "**/Domain/**/*"
+  - "**/Data/**/*"
+  - "**/DesignSystem/**/*"
+alwaysApply: false
+---
+
+# Эталонные фичи (reference features)
+
+Перед реализацией найди Feature того же типа и **повтори её структуру**, не изобретая новую организацию файлов.
+
+## Таблица эталонов
+
+После `ai-rules init` замени примеры на **реальные** пути consumer-репо. Ниже — conventional placeholders для greenfield / dogfood.
+
+| Слой | Эталон (пример → заменить) | Conventional glob / path |
+|------|----------------------------|--------------------------|
+| Feature module | `Features/Orders/` | `Features/**` |
+| Presentation / UI | `Features/Orders/Presentation/` | `**/Presentation/**`, `**/DesignSystem/**` |
+| Domain | `Features/Orders/Domain/` | `**/Domain/**` |
+| Data / Network | `Features/Orders/Data/` | `**/Data/**`, `**/Network*/**` |
+| Persistence | `Features/Orders/Data/Persistence/` | `**/Persistence/**`, `**/Keychain/**` |
+| Unit tests | `Features/OrdersTests/` или `*Tests` рядом | `**/*Tests/**/*.swift` |
+| UI tests | `OrdersUITests/` | `**/*UITests/**/*.swift` |
+
+Если в репо другая раскладка (`Modules/`, `Sources/`) — перепиши таблицу один раз и держи её SoT для агентов.
+
+## Как использовать
+
+1. Определи затронутые слои из `decomposition.md` или задачи.
+2. Открой эталон из таблицы (после заполнения путей).
+3. Зеркаль именование, порядок файлов, DI, паттерны тестов.
+4. Если эталона нет — выбери **самую близкую** существующую фичу того же слоя и зафиксируй выбор в handoff.
+
+## Dogfood checklist (5 сценариев)
+
+Прогон после init пресета (ручной smoke для агентов):
+
+1. `/task` новая фича в `Features/<Name>` — analyst → developer → build-verifier (xcodebuild).
+2. Баг в ViewModel — debugger → fix → unit test.
+3. Mapper DTO↔domain — unit-test-planner/generator.
+4. UI flow — `xcuitest-test-planner` → generator (accessibilityIdentifier).
+5. Auth/Keychain touch — security-reviewer + `security-ios.mdc`.
+
+## Связанные правила
+
+- `code-quality-and-refactoring.mdc` — повторять паттерны.
+- `feature-delivery-workflow.mdc` — порядок слоёв.
+- skill `feature-delivery` — end-to-end сценарий.

package/presets/cursor/ios-swift/rules/security-ios.mdc

@@ -0,0 +1,35 @@
+---
+description: ATS, Keychain, PII, секреты, безопасное логирование iOS
+globs:
+  - "**/*Keychain*.swift"
+  - "**/*Auth*.swift"
+  - "**/*Token*.swift"
+  - "**/*Credential*.swift"
+  - "**/Info.plist"
+alwaysApply: false
+---
+
+# Security (iOS)
+
+## Секреты и конфиг
+
+- Нет API keys / tokens в исходниках и git; использовать Keychain, xcconfig (не в VCS), CI secrets.
+- Debug-only bypass ATS / SSL — только `#if DEBUG` и никогда в Release.
+
+## ATS и сеть
+
+- ATS exceptions в Info.plist — минимальные, с обоснованием; предпочитать HTTPS.
+- Certificate pinning — только если уже принято в репо.
+
+## PII и логи
+
+- Не логировать токены, пароли, полные номера карт/документов.
+- Crash/APM: scrub PII по политике репо.
+
+## Keychain / биометрия
+
+- Accessible уровни и `kSecAttrAccessible` — осознанно; Face ID/Touch ID — через LocalAuthentication как в репо.
+
+## Требование к агенту
+
+При auth/формах/платежах — сверить с этим правилом и `code-review-mr.mdc`. Security-reviewer подключать для чувствительных фич.

package/presets/cursor/ios-swift/rules/state-and-viewmodels.mdc

@@ -0,0 +1,43 @@
+---
+description: ViewModels, состояние экрана и domain flow
+globs: "**/{Presentation,Domain}/**/*ViewModel*.swift"
+alwaysApply: false
+---
+
+# Общие принципы
+
+- ViewModel — **единственная точка** orchestration для экрана: load, submit, validation, navigation intents.
+- Хранить и отдавать во View **domain models** и UI-specific state (loading, error message, selected tab).
+- `@MainActor` на ViewModel; тяжёлую работу — в use case / repository (`async`), не блокировать main thread.
+- Unidirectional flow: View → intent → ViewModel → use case → state update → View.
+
+# State
+
+- Явный enum или struct для UI state где уместно:
+  - `idle`, `loading`, `loaded(Data)`, `failed(Error)` — или аналог из репо.
+- Избегать множества несинхронизированных `@Published` флагов, если один enum покрывает сценарий.
+- `@Observable` / `ObservableObject` — как в проекте; не смешивать стили в одной фиче без причины.
+
+# Use cases и repositories
+
+- ViewModel зависит от **протоколов** (`LoadOrdersUseCase`, `OrderRepository`), не от `*RepositoryImpl`.
+- Один use case — одна бизнес-операция; не раздувать ViewModel сотнями строк — выносить use cases в Domain.
+- Кэширование и offline — в repository/Data, не во ViewModel.
+
+# Side effects
+
+- Analytics, haptics, deep links — через injected services или middleware-паттерн, не hardcode синглтонов.
+- `Task` в ViewModel: отмена при `deinit` / `onDisappear` где нужно (`task(id:)`, хранение `Task?` с cancel).
+
+# Тестируемость
+
+- Инициализатор ViewModel принимает протоколы (DI); без скрытых singleton для сети/БД.
+- Бизнес-ветки покрывать unit-тестами с mock use cases.
+
+# Требование к агенту
+
+При создании ViewModel:
+- Не вызывать `URLSession` / API client напрямую.
+- Не парсить JSON и не объявлять DTO во ViewModel.
+- Именование: `FeatureViewModel`, методы — глаголы (`loadOrders()`, `submitOrder()`).
+- Следовать стилю существующих ViewModels в той же фиче.

package/presets/cursor/ios-swift/rules/swift-conventions.mdc

@@ -0,0 +1,51 @@
+---
+description: Swift language conventions and safety (preset)
+globs: "**/*.swift"
+alwaysApply: false
+---
+
+# Naming and API design
+
+- Types: `UpperCamelCase`; methods, properties, enum cases: `lowerCamelCase`.
+- Protocols, описывающие capability: `-able`, `-ing`, или `Protocol` суффикс — как в репо.
+- Избегать аббревиатур в именах, кроме общепринятых (URL, ID, HTTP).
+
+# Optionals and errors
+
+```swift
+// ❌ Плохо
+let name = user!.name
+
+// ✅ Хорошо
+guard let name = user?.name else { return }
+```
+
+- `throws` + typed errors вместо `Result` там, где так принято в слое; быть консistent внутри модуля.
+- `guard` для early exit; не вкладывать глубокие `if let` pyramids.
+
+# Concurrency
+
+- UI types — `@MainActor`.
+- Shared mutable state — `actor` или isolation через queue; document thread expectations.
+- `Task { }` в ViewModel: учитывать cancellation; `[weak self]` в escaping closures при retain cycles.
+- Prefer `async/await` over completion handlers для нового кода.
+
+# Access control
+
+- Минимально необходимый уровень: `private` / `fileprivate` по умолчанию для implementation details.
+- Public API фичи — явные types и protocols; не экспортировать DTO наружу модуля.
+
+# Value semantics
+
+- Предпочитать `struct` для models и state где нет identity semantics.
+- `class` — когда нужен identity, inheritance, или Objective-C interop.
+
+# Extensions
+
+- Группировать extensions по типу; не складывать unrelated helpers в один `Extensions.swift` без структуры.
+- Protocol extensions для shared default behavior.
+
+# Требование к агенту
+
+- Не добавлять `// swiftlint:disable` без явной причины.
+- Новый код — Swift Concurrency-ready (`Sendable` где требует компилятор/линтер проекта).

package/presets/cursor/ios-swift/rules/swiftui-ui.mdc

@@ -0,0 +1,61 @@
+---
+description: Паттерны SwiftUI, View и Design System (preset)
+globs: "**/{Presentation,DesignSystem}/**/*.swift"
+alwaysApply: false
+---
+
+# Общие правила View
+
+- **SwiftUI** — приоритет; UIKit — только по конвенции репо (wrapper, legacy).
+- View должна быть **тонкой**:
+  - отображает state из ViewModel;
+  - делегирует действия через методы/closures ViewModel;
+  - не содержит бизнес-логики, маппинга DTO, сетевых вызовов.
+- Перед новым кастомным контролом — искать компонент в `DesignSystem/` или существующих фичах.
+- Повторяемую UI-логику выносить в `ViewModifier`, `@ViewBuilder` helpers или subviews.
+
+# ViewModel и binding
+
+- ViewModel — `@MainActor`, `@Observable` (iOS 17+) или `ObservableObject` — как принято в проекте.
+- View читает state и вызывает **явные методы** ViewModel (`submit()`, `load()`), а не мутирует внутреннее состояние напрямую.
+- Для навигации — coordinator/router или enum route в ViewModel, не размазанные `NavigationLink` с бизнес-условиями в View.
+
+# Структура файлов
+
+Для экрана фичи:
+- `FeatureView.swift` — композиция subviews.
+- `FeatureViewModel.swift` — state + intents.
+- `FeatureView+Subviews.swift` — при большом дереве (опционально).
+- `FeatureRoute.swift` — навигация (если используется).
+
+Для компонента Design System:
+- Папка `ComponentName/`:
+  - `ComponentName.swift`
+  - `ComponentName+Preview.swift` (опционально)
+  - `ComponentNameStyle.swift` — стили/варианты (опционально)
+
+# Стили и Design System
+
+- Цвета, шрифты, отступы — из **токенов/Theme** проекта (`DesignSystem`, `Assets`, generated tokens).
+- Избегать:
+  - «магических» литералов (`.padding(17)`, `Color(red: 0.2, ...)`), если есть токены;
+  - дублирования стилей, уже закрытых примитивами.
+- `Preview` — для компонентов и экранов с mock ViewModel.
+
+# Accessibility
+
+- Интерактивные элементы: осмысленные `accessibilityLabel`, `accessibilityHint` где нужно.
+- Для UI-тестов — стабильные `accessibilityIdentifier` на ключевых элементах (согласовать с `tests-ui.mdc`).
+- Поддерживать Dynamic Type и контраст, не ломать layout при крупном шрифте.
+
+# Previews и локализация
+
+- Строки UI — через `String(localized:)` / `LocalizedStringKey`, не hardcoded в production без причины.
+- `#Preview` с реалистичными mock-данными; для ViewModel — stub use cases.
+
+# Требование к агенту
+
+При создании/изменении UI:
+- Следовать существующим экранам и компонентам как эталону.
+- Не импортировать Data-слой во View/ViewModel.
+- Subview выделять, когда body превышает ~40–60 строк или повторяется.

package/presets/cursor/ios-swift/rules/technical-retro.mdc

@@ -0,0 +1,12 @@
+---
+description: Роль агента для проведения технического ретроспективы (retro) команды / спринта. On-demand — предпочтительнее slash-команда /technical-retro.
+alwaysApply: false
+---
+
+# Техническое ретро — rule alias
+
+Полный сценарий (включая блок **«Работа агентов»** для slug из `.cursor/team/tasks/`) — в slash-команде:
+
+**`.cursor/commands/technical-retro.md`** → `/technical-retro`
+
+Используй rule только если command недоступен. Не дублируй содержимое command в ответе — следуй command-файлу и skill `technical-retro`.

package/presets/cursor/ios-swift/rules/tests-ui.mdc

@@ -0,0 +1,42 @@
+---
+description: UI-тесты XCUITest и accessibility identifiers
+globs: "**/*UITests/**/*.swift"
+alwaysApply: false
+---
+
+# Структура UI-тестов
+
+- UI Test target: `*UITests/` — сценарии пользовательских потоков.
+- Page Object (или Screen Object) — класс на экран: селекторы + действия (`LoginScreen`, `OrderHistoryScreen`).
+- Общие хелперы — `UITestSupport/`, base classes, launch arguments.
+
+# Селекторы и стабильность
+
+- **Приоритет:** `accessibilityIdentifier` для ключевых элементов; затем label/trait где устойчиво.
+- Идентификаторы согласовать с Presentation-слоем (`swiftui-ui.mdc`): `{screen}__{element}`.
+  - Пример: `order-history__submit-button`, `login__email-field`.
+- Избегать привязки к абсолютным координатам и хрупким XPath-подобным цепочкам.
+
+# Сценарии и именование
+
+- Названия тестов — **на русском**, с префиксом сущности:
+  - `OH-001 Отображается список заказов` (префикс — первые буквы сущности, номер — три цифры).
+- Один тест — один пользовательский сценарий; не объединять несвязанные проверки.
+
+# Launch и окружение
+
+- `-UITesting`, mock server URL, сброс state — через `launchArguments` / `launchEnvironment`, как в репо.
+- Не зависеть от прод-backend в CI; использовать staging/mock.
+
+# Синхронизация с UI
+
+- При изменении UI обновлять identifiers в View и селекторы в page objects.
+- Не ослаблять assertions против бизнес-ожиданий ради «зелёного» CI.
+
+# Требование к агенту
+
+При добавлении UI-тестов:
+- Переиспользовать page objects, не дублировать query в каждом тесте.
+- Добавлять `accessibilityIdentifier` в SwiftUI через `.accessibilityIdentifier(...)` для новых интерактивных элементов.
+- Следовать существующим UITest files как эталону.
+- Планирование / генерация / heal — agents `xcuitest-test-{planner,generator,healer}` и skill `xcuitest-e2e` (не Playwright).

package/presets/cursor/ios-swift/rules/tests-unit.mdc

@@ -0,0 +1,41 @@
+---
+description: Unit и integration тесты (XCTest / Swift Testing)
+globs: "**/*Tests/**/*.swift"
+alwaysApply: false
+---
+
+# Общие правила тестирования
+
+- **Framework** — XCTest или Swift Testing, как в проекте.
+- Цель: проверять **поведение и бизнес-правила**, не детали реализации и private API.
+- Именование:
+  - `test` / `@Test` descriptions и `XCTContext` — **на русском**, как понятные бизнес-фразы.
+  - Описания **с заглавной буквы**.
+
+# ViewModel и use case
+
+- Mock протоколов repositories / use cases; не поднимать реальную сеть.
+- Проверять переходы state: loading → success/failure, validation errors, edge cases.
+- `@MainActor` ViewModel тестировать с `@MainActor` test methods или `await MainActor.run`.
+
+# Mappers и domain
+
+- Mapper functions — unit-тесты с таблицами кейсов: nil fields, empty arrays, граничные значения.
+- Regression на бизнес-правила (скидки, статусы, форматирование дат).
+
+# Изоляция
+
+- Не мокать то, что является предметом теста (например, сам mapper при тесте mapper).
+- Fixtures — в `TestSupport/`, `Mocks/` или рядом по конвенции репо; не дублировать большие JSON inline без нужды.
+
+# Структура файлов
+
+- `FeatureViewModelTests.swift`, `OrderMapperTests.swift` — суффикс `Tests` в имени типа/файла по стилю Xcode.
+- Не создавать глубокую вложенность `Tests/Tests/`; следовать target structure проекта.
+
+# Требование к агенту
+
+При добавлении тестов:
+- Копировать паттерны из существующих test files в репо.
+- Добавлять тесты для новых веток логики и регрессий.
+- Использовать DTO fixtures из Data layer и domain types из Domain, не дублировать типы в тестах.

package/presets/cursor/ios-swift/rules/xcode-tooling.mdc

@@ -0,0 +1,20 @@
+---
+description: Перед xcodebuild / SwiftLint / SwiftFormat определять toolchain и схемы репозитория и использовать только их
+alwaysApply: false
+---
+
+# Xcode tooling (терминал)
+
+Перед **`xcodebuild` / `swift build` / `swift test` / SwiftLint / SwiftFormat / `simctl`** определи toolchain репозитория и **используй только его**.
+
+## Как определить
+
+1. **Workspace / project:** `.xcworkspace` (CocoaPods) → workspace; иначе `.xcodeproj`; SPM-only — `Package.swift`.
+2. **Scheme / destination:** как в CI, `Makefile`, `fastlane`, `scripts/` — не угадывать.
+3. **Lint:** `.swiftlint.yml` / `SwiftLint` в PATH или Mint/mise — если конфига нет, не запускать «чужой» lint.
+4. **Format:** `.swiftformat` / SwiftFormat — только если принято в репо.
+5. **Simulator:** `xcrun simctl list` + destination из CI; не хардкодить UDID.
+
+Примеры: `xcodebuild -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' build`, `swiftlint lint --quiet`, `swiftformat . --lint`.
+
+Долгие сборки и DerivedData — нормальны; не блокировать `xcodebuild`/`simctl`/`xcrun` shell-guard’ом.

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

@@ -0,0 +1,13 @@
+# `.cursor/skills` (preset ios-swift)
+
+| Skill | Назначение |
+|-------|------------|
+| `feature-delivery` | Domain → Data → VM → View → tests → post-change-build |
+| `code-review` | iOS MR checklist |
+| `unit-testing` | XCTest / Swift Testing |
+| `xcuitest-e2e` | XCUITest plan/generate/heal (← next `playwright-e2e`) |
+| `debug-investigation` | Runtime evidence before fix |
+| `ci-investigation` | iOS CI red |
+| `technical-retro` | Retro facilitation |
+
+Копируется в `.cursor/skills/` при init.

package/presets/cursor/ios-swift/skills/ci-investigation/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: ci-investigation
+description: Investigates failing CI checks on PRs and branches — xcodebuild, SwiftLint, unit, XCUITest — with local reproduction and minimal fixes. Use when CI is red or for ci-fix pipeline tasks.
+---
+
+# CI Investigation (iOS)
+
+## Workflow
+
+1. Identify the **first failing check** (compile, lint, unit, XCUITest, signing, SPM).
+2. Capture error output — ignore cascading failures until root cause is found.
+3. Reproduce locally with the same scheme/destination CI uses (`xcode-tooling.mdc`):
+   - `xcodebuild build` / `xcodebuild test`
+   - SwiftLint / SwiftFormat scripts as in repo CI
+   - affected XCUITest if UI job failed
+4. Inspect git diff for changed files related to the failure.
+5. Apply **minimal fix** — no unrelated refactors.
+
+## Artifact
+
+Write `ci-report.md` under the task slug folder (`.cursor/team/tasks/<slug>/`):
+
+- Failed check name and log excerpt
+- Root cause classification
+- Fix applied (or handoff to feature-developer)
+- `resolved: true|false`
+- Validation commands and results
+
+## Handoff Rules
+
+- Config-only or one-line fixes → fix in place, re-run check.
+- Missing tests or architecture work → document and route to `feature-developer` or `qa-tester`.
+- Flaky XCUITest → prefer `xcuitest-test-healer` after ci-investigator identifies the case.
+
+## Validation
+
+Always re-run the failing command locally before marking complete. If environment blocks execution (no simulator), state the exact command and blocker.
+
+Never run yarn/`lint:js`/Playwright — wrong stack.

package/presets/cursor/ios-swift/skills/code-review/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: code-review
+description: Reviews pull requests, merge requests, git diffs, and branch changes using iOS architecture, SwiftUI, networking, and testing standards. Use when the user asks for review or when code-reviewer runs in an agent pipeline.
+---
+
+# Code Review (iOS)
+
+## Inputs
+
+Use the local repository as the source of truth: `git status`, `git diff`, task artifacts under `.cursor/team/tasks/<slug>/` when present, and opened files. Do not invent hosting metadata such as labels, CI status, or reviewers.
+
+## Review Order
+
+1. Understand the intent and affected Feature layers (Presentation / Domain / Data).
+2. Check correctness and regressions first.
+3. Verify architecture boundaries (`architecture-boundaries.mdc`): View ≠ API/DTO; ViewModel ≠ Data impl; Domain ≠ SwiftUI; Data ≠ Presentation.
+4. Check DI composition in `App/`, SPM public API (`module-public-api.mdc`), and no deep-imports across Features.
+5. Review Swift concurrency and conventions (`swift-conventions.mdc`): `@MainActor`, typed errors, force unwrap.
+6. Review SwiftUI thinness, Design System usage, accessibility identifiers (`swiftui-ui.mdc`).
+7. Check tests: unit for mapper/domain/VM (`tests-unit.mdc`); XCUITest for user flows (`tests-ui.mdc`).
+8. Report validation gaps: `xcodebuild`, SwiftLint, or relevant tests not run (`xcode-tooling.mdc`, `post-change-build.mdc`).
+
+## Output
+
+Lead with findings ordered by severity. Each finding should include the file, the problem, impact, and a concrete fix direction. If there are no findings, say so and call out remaining test or validation risk.
+
+For agent team tasks, write `.cursor/team/tasks/<slug>/review.md` and set `status.json` to `completed` or `changes_requested`.

package/presets/cursor/ios-swift/skills/debug-investigation/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: debug-investigation
+description: Investigates bugs, failing tests, crashes, and incorrect behavior with runtime evidence before applying minimal fixes. Use for bugfix tasks, debugger agent runs, regressions, and flaky test diagnosis.
+---
+
+# Debug Investigation (iOS)
+
+## Process
+
+1. Reproduce the issue or collect the closest available evidence: Xcode console, lldb backtrace, crash log, failing XCTest/XCUITest output, Instruments note, or user steps.
+2. Define expected vs actual behavior in one sentence.
+3. Trace the failing path through the smallest relevant Feature slice (Presentation → Domain → Data).
+4. Identify the root cause before editing. Avoid broad refactors during bugfixes.
+5. Apply the smallest fix that preserves existing architecture and public contracts.
+6. Add or update a regression XCTest when the behavior is domain/VM logic or likely to recur.
+7. Run the narrow failing check first (`xcodebuild test` for the affected target), then broader build validation if needed (`xcode-tooling.mdc`).
+
+## Artifacts
+
+For agent team tasks, write `.cursor/team/tasks/<slug>/debug-report.md` with:
+
+- Reproduction steps or evidence source.
+- Root cause.
+- Fix scope (`fixApplied`).
+- Regression coverage.
+- Remaining risk.
+
+Update `status.json` when complete.
+
+Do not use browser/Playwright tooling — this is an Xcode stack.

package/presets/cursor/ios-swift/skills/feature-delivery/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: feature-delivery
+description: Delivers iOS Swift/SwiftUI features end-to-end across Domain, Data, ViewModels, Views, tests, and post-change-build validation. Use when implementing or extending a feature, especially through /task or feature-developer.
+---
+
+# Feature Delivery (iOS)
+
+1. Read task brief, acceptance criteria, and decomposition if present.
+2. Read `feature-delivery-workflow.mdc` and `reference-features.mdc` — Domain → Data → ViewModel → View → tests; mirror the closest Feature.
+3. Wire DI in `App/` composition root; keep Views thin; keep DTOs out of ViewModels.
+4. Add or update focused XCTest for mappers / use cases / ViewModels (`tests-unit.mdc`).
+5. After Swift edits: **invoke** `post-change-build.mdc` (+ `xcode-tooling.mdc`). Pipeline: scoped build OK if next step is `build-verifier`.
+
+## Do / Don't
+
+- **Do** follow existing Feature folder layout and public module APIs.
+- **Do** add `accessibilityIdentifier`s for new interactive UI when UI tests are in scope.
+- **Don't** introduce TCA/SwiftData/etc. unless the repo already uses them.
+- **Don't** use yarn, Playwright, or `app/src` paths — wrong stack.
+
+## Preset packaging note
+
+When editing **ai-rules ios-swift preset** sources (agents, hooks, rules) rather than an app Feature: keep Cursor and Claude trees in sync where applicable, and **fork / verify hook handoffs** (`hooks/chain-team-phases.sh`, guard scripts, team path conventions) so Cursor (`.cursor/team`) and Claude (`.claude/team`) do not regress against each other or against the next preset templates.
+
+## Handoff
+
+Summarize by layer, validation results, and known gaps. Agent team: update `.cursor/team/tasks/<slug>/status.json`.

package/presets/cursor/ios-swift/skills/technical-retro/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: technical-retro
+description: Facilitates technical retrospectives for tasks, sprints, incidents, releases, and agent-team pipelines. Use when the user asks for retro, postmortem, process review, or action items after delivery.
+---
+
+# Technical Retro
+
+Same structure as next technical-retro skill. For `/task` pipelines include router, analyst, developer, **build-verifier** (xcodebuild), reviewer, QA/XCUITest, hooks, rules.
+
+Preset feedback: propose updates to `.cursor/rules|agents|skills` — do not apply without approval.

package/presets/cursor/ios-swift/skills/unit-testing/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: unit-testing
+description: Plans, generates, and heals XCTest / Swift Testing for mappers, use cases, and ViewModels using *Tests targets and tests-unit rules. Use for unit test planning, generation, or fixing failing unit tests.
+---
+
+# Unit Testing (iOS)
+
+## Project Layout
+
+- Unit targets: `*Tests/` colocated or parallel to Feature — **as in the Xcode project**.
+- Framework: XCTest or Swift Testing per project convention.
+- Do **not** create Jest/Vitest `*.spec.ts` files.
+
+Follow `tests-unit.mdc` (Cursor `.mdc` / Claude `testing/unit.md` depending on preset).
+
+## Planner
+
+Write or update `.cursor/team/tasks/<slug>/unit-test-plan.md`.
+
+Each scenario needs a Russian `test` / `@Test` title (capital letter after each sentence). Cover mappers, use cases, ViewModel state branches, and mocked client/repository behavior per AC.
+
+## Generator
+
+Implement tests from `unit-test-plan.md` into the correct `*Tests` target. Reuse TestSupport / protocol mocks. Do not change production code.
+
+## Healer
+
+Fix mocks, async/MainActor timing, and fixtures — preserve business assertions. Use `unit-test-plan.md` and `brief.md` as the behavior contract.
+
+## Validation
+
+Run affected unit tests via `xcodebuild test` (`xcode-tooling.mdc`) when feasible. Report command, pass/fail, and remaining gaps vs plan.

package/presets/cursor/ios-swift/skills/xcuitest-e2e/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: xcuitest-e2e
+description: Plans, generates, and heals XCUITest UI tests using *UITests targets, accessibility identifiers, and screen objects. Use for UI test planning, generation, or fixing flaky XCUITest.
+---
+
+# XCUITest E2E
+
+## Project Layout
+
+- UI Test target: `*UITests/` (as in the Xcode project).
+- Optional plans: `*.cases.md` if the repo uses them.
+- Screen/Page objects keyed by `accessibilityIdentifier` (`{screen}__{element}`).
+- Shared helpers: `UITestSupport/` or equivalent — follow existing patterns.
+
+Follow `tests-ui.mdc`. Agents: `xcuitest-test-{planner,generator,healer}`.
+
+**Never Playwright** and never `app/__tests__/e2e`.
+
+## Planner
+
+Create or update the relevant plan (`*.cases.md` or team notes). Each scenario should include title, preconditions, steps, and expected result. Cover happy path, important edge cases, validation, and error states. Russian titles with entity prefix when that is repo convention.
+
+## Generator
+
+Generate XCUITest from plans into the UITests target. Reuse screen objects. Keep test names aligned with scenario names. Prefer identifiers over coordinates.
+
+## Healer
+
+Fix waits, launch arguments, identifiers, or screen-object details without weakening business assertions. Use the matching plan / AC as the behavior contract.
+
+## Validation
+
+Run affected UI tests via `xcodebuild test` (`xcode-tooling.mdc`) when a simulator is available. If blocked, report the exact command and blocker.

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

@@ -0,0 +1,27 @@
+# Agent team artifacts (ios-swift)
+
+Каталог артефактов пайплайна «команда агентов» для iOS.
+
+## Layout
+
+```
+.cursor/team/   # Claude: .claude/team/
+  active-task.json
+  fixtures/
+  tasks/<slug>/
+    pipeline.json
+    status.json
+    brief.md
+    decomposition.md
+    …
+```
+
+## Fixtures
+
+| Fixture | Notes |
+|---------|-------|
+| `feature-full.json` | Full profile; QA scope `e2e-only` = **XCUITest**; Playwright stems in `skipped` |
+| `feature-light.json` | developer → build-verifier |
+| `bugfix-standard.json` | debugger → developer (skipIf) → verifier → reviewer |
+
+**Never** schedule Playwright-only steps without skip rationale. Use `xcuitest-test-*` for UI-test-only intents.