@bonesofspring/ai-rules 0.2.2 → 0.2.4

package/presets/cursor/next/rules/react-ui.mdc

@@ -1,6 +1,6 @@
 ---
 description: Паттерны React/Next UI и стилей (preset)
-globs: src/ui/**/*.tsx
+globs: app/src/ui/**/*.tsx,app/src/ui/**/*.ts
 alwaysApply: false
 ---
 
@@ -22,14 +22,43 @@ alwaysApply: false
 - `styles.ts` или соседний модуль стилей — по конвенции репозитория (CSS Modules, CSS-in-JS, и т.д.).
 - `index.ts` — реэкспорт (если нужно наружу).
 
+## Дочерние компоненты (`./components`)
+
+- Локальные подкомпоненты, используемые только этим блоком, выносятся в **`./components/<ComponentName>/`** относительно папки родительского компонента (не оставлять крупные куски JSX и «внутренние» компоненты в том же файле, что и родитель).
+- У каждого такого подкомпонента — **своя** папка с тем же именем, что и публичное имя компонента:
+  - `ComponentName.tsx` — разметка и композиция;
+  - `styles.ts` — только стили этого подкомпонента (не тянуть `styles` соседних компонентов — см. § Стили ниже);
+  - при необходимости — `ComponentName.data.ts`, `ComponentName.utils.ts`, `ComponentName.hooks.ts` по тем же правилам префикса, что и у родителя;
+  - опционально `index.ts` с реэкспортом.
+- Родитель импортирует подкомпонент из `./components/...`, а не держит его реализацию inline.
+
 Для переиспользуемого компонента:
 - Папка с именем компонента:
   - `ComponentName.tsx`
   - файлы стилей по принятой схеме;
-  - опционально: `types.ts`, `hooks.ts`.
+  - опционально: `types.ts`, `ComponentName.hooks.ts` (см. ниже про префикс).
+
+## Вспомогательные модули рядом с компонентом (именование)
+
+**Префикс имени файла = публичное имя компонента** (как у `ComponentName.tsx` в этой папке), в **PascalCase**. Не вводить отдельные «говорящие» имена файлов по смыслу содержимого (`analysisPreparationIconMap.ts`, `buildAnalysisIdToNameMap.ts` и т.п.) — так теряется связь с компонентом и плодятся одноразовые названия.
+
+**Суффикс по роли:**
+
+| Суффикс | Назначение | Примеры содержимого |
+|--------|------------|---------------------|
+| `ComponentName.data.ts` | Статические данные и конфигурация для UI | мапы `id → иконка/лейбл`, константы списков, таблицы соответствий для отображения |
+| `ComponentName.utils.ts` | Чистые функции без React | форматирование, предобработка пропсов/данных для рендера, `build…`/`map…`‑хелперы |
+| `ComponentName.hooks.ts` | Хуки, используемые только этим блоком | локальные `use…` (если не вынесены в `src/ui/hooks/**`) |
+
+- Несколько констант/мапов или несколько функций — **по-прежнему один** `.data.ts` и один `.utils.ts`, не дробить по «темам» отдельными файлами без веской причины (размер, разные зоны ответственности на уровне подкомпонентов).
+- Если логика принадлежит **подкомпоненту** в подпапке (`components/Child/Child.tsx`), те же правила применяются к **`Child.data.ts`**, **`Child.utils.ts`** относительно этого подкомпонента.
+- Тесты для утилит и данных — рядом в `__tests__/` или с суффиксом `.test.ts`, согласно `tests-unit.mdc`, с тем же префиксом (`RequestForAnalysisRecommendations.utils.test.ts` и т.д.).
 
 # Стили и дизайн‑токены
 
+- **Корневой** styled в соседнем `styles` — экспорт **`Root`**; в JSX: `<s.Root>` при `import * as s from './styles'`. Вложенные — `Title`, `List` и т.д. Не `Container`/`Wrapper` для единственной обёртки.
+- **Запрещено** импортировать `styles` другого компонента (`../Other/styles`, `../../styles`). Разрешено: `./styles`, общие примитивы из `@/ui/components/...` или пакетов дизайн-системы.
+- Порядок CSS / `styled` — Stylelint idiomatic-order: `css-property-order-stylelint.mdc` (грузится на `styles.ts` / `.css`).
 - Для визуала использовать **тот стек стилей и токенов, который уже в проекте** (переменные, тема, общие классы, дизайн‑пакет).
 - Избегать:
   - inline‑стилей, кроме простых случаев;
@@ -39,10 +68,11 @@ alwaysApply: false
 
 # Пропсы и типизация
 
+- **Не передавать пропы в компоненты через spread** (`<Foo {...x} />`). Только явные атрибуты; подробности и исключения — `no-props-spread.mdc` (в `app/src/ui` это дополнительно ловит ESLint).
 - Описывать пропсы через `type Props = { ... }` или `interface Props { ... }`.
 - Не использовать `any`; при необходимости:
   - обобщения (`<T>`), `unknown`, тип‑предикаты и user‑defined type guards.
-- Для доменных сущностей использовать типы из `@/types/**`, а не описывать их заново.
+- Для доменных сущностей использовать типы из `@/types` (и enum из `@/types/enums`), а не описывать их заново (`public-imports.mdc`).
 
 # Логика и side effects
 

package/presets/cursor/next/rules/reference-features.mdc

@@ -0,0 +1,39 @@
+---
+description: Эталонные фичи репозитория — копировать структуру при реализации новых задач. Заполните пути после init в целевом репо.
+globs:
+  - app/src/ui/**/*
+  - app/src/store/**/*
+  - app/src/api/**/*
+  - app/src/types/**/*
+alwaysApply: false
+---
+
+# Эталонные фичи (reference features)
+
+Перед реализацией найди фичу того же типа и **повтори её структуру**, не изобретая новую организацию файлов.
+
+## Таблица эталонов
+
+Замени **TBD** на реальные пути после договорённости в команде (или при `ai-rules init` в целевом репо):
+
+| Слой | Эталон | Что копировать |
+|------|--------|----------------|
+| UI page | **TBD** `app/src/ui/pages/<Example>/` | `components/`, `*.data.ts`, `styles.ts`, barrel |
+| Store slice | **TBD** `app/src/store/slices/<example>/` | slice, thunks, selectors, types |
+| API service | **TBD** `app/src/api/services/<example>/` | service, mappers, barrel |
+| Types module | **TBD** `app/src/types/<example>/` | domain types, JSDoc, barrel export |
+| Unit tests | **TBD** рядом с эталонным mapper/service | `*.spec.ts`, describe/it naming |
+| E2E area | **TBD** `app/__tests__/e2e/<Area>/` | `*.cases.md`, page objects, `_shared/` |
+
+## Как использовать
+
+1. Определи затронутые слои из `decomposition.md` или задачи.
+2. Открой эталон из таблицы (после заполнения путей).
+3. Зеркаль именование, порядок файлов, паттерны импортов и тестов.
+4. Если эталона нет — выбери **самую близкую** существующую фичу того же слоя и зафиксируй выбор в handoff.
+
+## Связанные правила
+
+- `code-quality-and-refactoring.mdc` — повторять паттерны, не deep-import.
+- `feature-delivery-workflow.mdc` — порядок слоёв.
+- skill `feature-delivery` — end-to-end сценарий.

package/presets/cursor/next/rules/store-rtk.mdc

@@ -1,6 +1,6 @@
 ---
 description: Redux Toolkit и состояние приложения
-globs: src/store/**/*.ts
+globs: app/src/store/**/*.ts
 alwaysApply: false
 ---
 
@@ -16,7 +16,7 @@ alwaysApply: false
 
 # Структура слайсов
 
-- Каждый доменный модуль — свой слайс в `src/store/slices/**`.
+- Каждый доменный модуль — свой слайс в `app/src/store/slices/**`.
 - Слайс экспортирует:
   - `reducer` по умолчанию;
   - `actions` именованным экспортом;
@@ -30,17 +30,23 @@ alwaysApply: false
 - Асинхронные запросы:
   - через `createAsyncThunk` или RTK Query.
   - внутри thunk:
-    - вызывать API через сервисы из `@/api/services/**`;
-    - не вызывать HTTP‑клиент напрямую — только через сервисы `@/api/services/**`.
+    - вызывать API через сервисы, импортированные из `@/api` (**`public-imports.mdc`**);
+    - не вызывать HTTP‑клиент напрямую — только через эти сервисы.
 - Сайд‑эффекты (логирование, аналитика, работа с файлами):
-  - выносить в middleware (`src/store/middleware/**`) или специализированные слайсы.
+  - выносить в middleware (`app/src/store/middleware/**`) или специализированные слайсы.
 
 # Типизация
 
 - Использовать `RootState`, `AppDispatch` и типизированные хуки `useAppDispatch`, `useAppSelector` (если есть).
+- **HTTP и ошибки API**:
+  - не импортировать типы **сторонних HTTP‑библиотек**, которых нет в актуальных зависимостях и существующих слайсах (ориентир — **`package.json`** и соседние файлы);
+  - когда сервис возвращает **обёртку ответа** прикладного клиента — использовать **соответствующий тип из `@/types`** (как в barrel и в аналогичных thunk’ах);
+  - при ошибках после вызова сервиса — опираться на **тот же класс/контракт ошибки транспорта**, что использует общий клиент (из `@/types`), и разбирать тело/статус **по полям текущей реализации**, а не по воображаемому API;
+  - в **`catch`** предпочитать **`instanceof`** на класс ошибки транспорта из `@/types` (если он есть в коде) вместо голого `as`, когда это выразимо без шума (см. `no-type-assertion-as-import-export.mdc`).
 - Для сущностей:
-  - доменные типы (включая вычисляемые поля) определять в `@/types/**` и импортировать в слайсы как **источник правды** для структуры данных;
+  - доменные типы (включая вычисляемые поля) определять в `app/src/types/**`, экспортировать через barrel и импортировать в слайсы из `@/types` как **источник правды** для структуры данных (`public-imports.mdc`);
   - избегать дублирования описаний сущностей в нескольких местах.
+- **Граница домена**: в **state** хранить доменные модели; тип **обёртки ответа клиента** допустим как тип **возвращаемого значения thunk** или промежуточно до маппинга — без дублирования DTO в полях state без нужды (согласовано с `api-services.mdc` и `http-client.mdc`).
 
 # Тестирование слайсов
 
@@ -56,4 +62,5 @@ alwaysApply: false
 - Не класть логику API внутрь редюсеров/компонентов.
 - Строго типизировать state и actions.
 - Использовать единый стиль именования actions и селекторов, как в существующих слайсах.
+- При работе с ошибками и ответами HTTP опираться на **`http-client.mdc`** и контракты из `@/types`, а не на типы внешних HTTP‑библиотек вне зависимостей проекта.
 

package/presets/cursor/next/rules/technical-retro.mdc

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

package/presets/cursor/next/rules/tests-unit.mdc

@@ -1,17 +1,31 @@
 ---
 description: Unit и интеграционные тесты (Testing Library и runner проекта)
-globs: src/**/*.test.{ts,tsx}
+globs:
+  - app/src/**/*.spec.{ts,tsx}
+  - app/src/**/*.test.{ts,tsx}
 alwaysApply: false
 ---
 
 # Общие правила тестирования
 
+- **Имена файлов:** для **новых** тестов использовать суффикс **`*.spec.ts` / `*.spec.tsx`**. Существующие **`*.test.ts` / `*.test.tsx`** не переименовывать без отдельной задачи (легаси).
 - **Runner и матчеры** — как в проекте (часто Jest или Vitest); для компонентов — **@testing-library/react**.
 - Основная цель тестов:
   - проверять **поведение и бизнес‑правила**, а не реализацию или внутренние детали.
- - Именование:
-  - названия `describe` / `it` / `test` и любые человекочитаемые описания в тестах **должны быть на русском языке**, формулироваться как понятные бизнес‑фразы (что именно ожидается от системы).
-  - строки в `describe` / `it` / `test` **должны начинаться с заглавной буквы**.
+- **Именование unit‑тестов** (строки в `describe` / `it` / `test`):
+  - формулировки **только на русском языке** — понятные бизнес‑фразы (что проверяется и какой ожидается результат);
+  - **каждое предложение** в названии **начинается с заглавной буквы** (в том числе после `.`, `!`, `?` и при нескольких предложениях в одной строке); первая буква всей строки — тоже заглавная.
+  - **Проверка в CI:** ESLint (`jest/valid-title` в `app/eslint.config.mjs`) требует, чтобы строка начиналась с русской заглавной (А–Я, Ё), и запрещает пробел после точки, за которым сразу идёт строчная буква (типичный случай нарушения «с заглавной после точки»).
+
+```typescript
+// ✅ Хорошо
+it('Возвращает пустой список. Пользователь не авторизован', () => {})
+it('При ошибке сети показывается сообщение об ошибке', () => {})
+
+// ❌ Плохо (не с заглавной после точки; или не русский)
+it('Возвращает пустой список. пользователь не авторизован', () => {})
+it('Returns empty list when user is guest', () => {})
+```
 
 # Тесты компонентов
 
@@ -27,6 +41,11 @@ alwaysApply: false
   - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
 - Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
 
+# HTTP‑клиент
+
+- При изменении **реализации общего HTTP‑клиента** (разбор тел, заголовки, ветки ошибок, 401/refresh, `FormData`, `blob` и т.п.) — **обновить или добавить behavior‑тесты** рядом с модулем клиента в `app/src/lib/clients/**` (предпочтительно `*.spec.ts`; легаси `*.test.ts` — не трогать без задачи).
+- Проверять смысловые ветки: успешный JSON, HTTP‑ошибка, сеть, релевантные для проекта сценарии авторизации.
+
 # Мапперы и преобразование данных
 
 - Функции маппинга данных (DTO -> доменная модель и обратно), особенно содержащие вычисляемые поля и ветвления, должны быть покрыты unit‑тестами.
@@ -35,12 +54,13 @@ alwaysApply: false
 # Требование к агенту
 
 При добавлении тестов:
-- Следовать существующей структуре и паттернам тестов в `src/**/__tests__/**` или рядом с компонентом.
+- Следовать существующей структуре и паттернам тестов в репозитории: файл `*.spec.ts(x)` рядом с модулем или в общем каталоге тестов — как в соседних фичах.
 - Добавлять тесты для критичных веток логики и edge‑кейсов.
  - При работе с данными:
-   - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types/**`, не дублировать интерфейсы в тестах;
-   - по возможности опираться на данные и обработчики из `src/mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
- - При написании unit‑тестов рядом с компонентом или модулем:
-   - **не создавать** поддиректорию `__tests__` внутри папки компонента;
-   - именовать файлы тестов с суффиксом `*.spec.ts` / `*.spec.tsx`, а не `*.test.ts` / `*.test.tsx`.
+   - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types`, не дублировать интерфейсы в тестах;
+   - по возможности опираться на данные и обработчики из `app/src/mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
+ - Размещение:
+   - для **компонентов UI** — **не создавать** поддиректорию `__tests__` внутри папки компонента; тест — соседний `*.spec.tsx`.
+   - в **других модулях** (например `api/services`) допустима уже существующая схема с `__tests__` — не ломать ради единообразия с UI.
+   - **новые** файлы — `*.spec.ts` / `*.spec.tsx` (см. блок «Имена файлов» выше).
 

package/presets/cursor/next/rules/types-jsdoc.mdc

@@ -0,0 +1,42 @@
+---
+description: Стиль JSDoc для доменных и транспортных типов в app/src/types
+globs: app/src/types/**/*.ts
+alwaysApply: false
+---
+
+# Документация типов в `app/src/types`
+
+При добавлении или существенном изменении типов в этом слое **следовать уже принятому в репозитории стилю JSDoc** (см. примеры: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
+
+## Язык и форма
+
+- Текст комментариев — **на русском**, кратко и по делу: что означает тип или поле в предметной области или в контракте с API.
+- **Не опираться** на теги в духе `@param`, `@returns`, `@see`, `@deprecated` для описания типов — в этом слое они **не используются**; достаточно обычного текста в `/** … */`.
+
+## Экспортируемый `type` / `interface`
+
+- Сразу **перед объявлением** — блок `/** … */`.
+- Если нужно пояснить источник данных, ограничения или неочевидности — **второй абзац** в том же блоке (в JSDoc для абзаца — пустая строка между строками текста).
+- Для **вложенных** объектов в том же файле каждый такой тип документируется отдельным блоком над своим объявлением.
+
+## Поля
+
+- У **каждого** публичного свойства — **однострочный** `/** … */` на строке непосредственно **над** полем.
+- Если поле **не приходит с бэкенда «как есть»**, а вычисляется или дополняется на фронте (маппер, селектор, UI) — начать описание с префикса **`[computed]`** (как в `TUserProfile`, типах плана лечения).
+- Для форматов данных указывать это **в тексте**: например дата `YYYY-MM-DD`, пример отображаемой строки в кавычках.
+
+## Классы и прочие объявления
+
+- Для **классов** (например ошибки транспорта) при изменении публичного API — краткий блок над классом и **комментарии к публичным полям** по тем же правилам, что у свойств интерфейса.
+
+## `enum`
+
+- В `enums.ts` исторически часто **без JSDoc** на каждом члене; для новых enum допустимо короткое описание **над самим enum**, если назначение неочевидно из имени. Подписи для UI — как принято, через объекты `*Names` рядом с enum.
+
+## Практика для агента
+
+- Добавляя новый тип или поле, **не оставлять** новые публичные поля без пояснения, если смысл не равен имени на 100%.
+- Правя файл, где уже есть такие комментарии, **поддерживать тот же стиль**, а не смешивать с англоязычными или «теговыми» блоками.
+- Не раздувать комментарии: одна-две фразы на тип, одна строка на поле — норма; исключение — действительно сложная доменная оговорка.
+
+См. также импорты и barrel: `public-imports.mdc`.

package/presets/cursor/next/skills/README.md

@@ -0,0 +1,15 @@
+# `.cursor/skills` (preset next)
+
+Project skills for Cursor. They keep long workflows out of always-on rules while preserving the same team conventions as the Claude preset.
+
+| Skill | When to use |
+|-------|-------------|
+| `feature-delivery` | End-to-end feature work across types, API, store, UI, tests |
+| `code-review` | MR/diff review using project architecture and test standards |
+| `debug-investigation` | Reproducing and fixing bugs with root-cause evidence |
+| `ci-investigation` | Diagnosing and fixing failing CI checks on PRs/branches |
+| `unit-testing` | Planning, generating, or healing unit test coverage |
+| `playwright-e2e` | Planning, generating, or healing Playwright e2e coverage |
+| `technical-retro` | Technical retrospective for a task, sprint, incident, or agent pipeline |
+
+Skills are copied to `.cursor/skills/` by `ai-rules init cursor --preset next`.

package/presets/cursor/next/skills/ci-investigation/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: ci-investigation
+description: Investigates failing CI checks on PRs and branches — lint, type-check, unit, e2e — with local reproduction and minimal fixes. Use when CI is red or for ci-fix pipeline tasks.
+---
+
+# CI Investigation
+
+## Workflow
+
+1. Identify the **first failing check** (lint, type-check, unit, e2e, build).
+2. Capture error output — ignore cascading failures until root cause is found.
+3. Reproduce locally with the same commands CI uses from `app/`:
+   - `lint:js`, `lint:css`, `type-check`
+   - targeted unit test file or suite
+   - affected Playwright spec if e2e 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:
+
+- Failed check name and link/log excerpt
+- Root cause classification
+- Fix applied (or handoff to feature-developer)
+- 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 e2e → prefer `playwright-test-healer` after ci-investigator identifies the spec.
+
+## Validation
+
+Always re-run the failing command locally before marking complete. If environment blocks execution, state the exact command and blocker.

package/presets/cursor/next/skills/code-review/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: code-review
+description: Reviews pull requests, merge requests, git diffs, and branch changes using the preset's architecture, import, UI, API, and testing standards. Use when the user asks for review or when code-reviewer runs in an agent pipeline.
+---
+
+# Code Review
+
+## 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 layers.
+2. Check correctness and regressions first.
+3. Verify architecture boundaries: UI does not know DTO/transport, store does not depend on UI, API services do not pull UI/store.
+4. Check public imports through `@/types` and `@/api`, plus barrel updates for new public symbols.
+5. Review UI consistency, styling conventions, and prop shape.
+6. Check tests: unit for mapper/domain logic, behavior tests for HTTP client changes, e2e plan/spec updates for user flows.
+7. Report validation gaps: lint, stylelint, type-check, or relevant tests not run.
+
+## 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/next/skills/debug-investigation/SKILL.md

@@ -0,0 +1,28 @@
+---
+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
+
+## Process
+
+1. Reproduce the issue or collect the closest available evidence: error output, failing test, browser snapshot, logs, or user steps.
+2. Define expected vs actual behavior in one sentence.
+3. Trace the failing path through the smallest relevant slice of the codebase.
+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 test when the behavior is user-facing or likely to recur.
+7. Run the narrow failing check first, then relevant lint/type/test validation.
+
+## Artifacts
+
+For agent team tasks, write `.cursor/team/tasks/<slug>/debug-report.md` with:
+
+- Reproduction steps or evidence source.
+- Root cause.
+- Fix scope.
+- Regression coverage.
+- Remaining risk.
+
+Update `status.json` when complete.

package/presets/cursor/next/skills/feature-delivery/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: feature-delivery
+description: Delivers Next.js frontend features end-to-end across domain types, API services, store, UI, mocks, tests, and validation. Use when implementing or extending a feature, especially through /task or feature-developer.
+---
+
+# Feature Delivery
+
+1. Read task brief, acceptance criteria, and decomposition if present.
+2. Read **`feature-delivery-workflow.mdc`** and **`reference-features.mdc`** — follow layer order and mirror closest reference feature.
+3. Add or update focused tests for changed behavior.
+4. Validation from `app/`: **invoke** **`post-change-lint.mdc`** after code edits (requestable, not always-on — but mandatory when code changed). Pipeline: scoped lint OK if next step is `build-verifier`.
+
+## Handoff
+
+Summarize by layer, validation results, and known gaps. Agent team: update `.cursor/team/tasks/<slug>/status.json`.

package/presets/cursor/next/skills/playwright-e2e/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: playwright-e2e
+description: Plans, generates, and heals Playwright e2e tests using this preset's app/__tests__/e2e layout, *.cases.md plans, page objects, and shared helpers. Use for e2e planning, test generation, or fixing failing browser tests.
+---
+
+# Playwright E2E
+
+## Project Layout
+
+- Test root: `app/__tests__/e2e`.
+- Test plans: `*.cases.md` files under the matching feature folder.
+- Executable specs: `*.spec.ts` files in the same folder.
+- Seed/setup reference: `app/__tests__/e2e/seed.spec.ts`.
+
+Do not introduce top-level `specs/` or `tests/` folders for real coverage unless the user explicitly asks for a sandbox.
+
+## Planner
+
+Create or update the relevant `*.cases.md` file. Each scenario should include title, preconditions, steps, and expected result. Cover happy path, important edge cases, validation, and error states.
+
+## Generator
+
+Generate specs from `*.cases.md` into the same folder. Reuse existing page objects and `_shared/` helpers. Keep test names aligned with scenario names.
+
+## Healer
+
+Fix selectors, waits, setup, or page-object details without weakening business assertions. Use the matching `*.cases.md` file as the behavior contract.
+
+## Validation
+
+Run the affected spec when feasible. If the environment blocks execution, report the command that should be run and the blocker.

package/presets/cursor/next/skills/technical-retro/SKILL.md

@@ -0,0 +1,40 @@
+---
+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
+
+## Inputs
+
+Ask for missing period, focus, task slug, participants, or format constraints. If a slug is provided, read `.cursor/team/tasks/<slug>/` artifacts and local git status/diff. Do not invent facts not present in artifacts or the user's message.
+
+## Facilitation Principles
+
+- Focus on process and system behavior, not blame.
+- Separate facts, interpretations, and proposed actions.
+- Balance what worked with what slowed delivery.
+- Keep action items concrete, owned, and measurable.
+
+## Default Structure
+
+1. Goal and scope.
+2. Timeline or factual observations.
+3. What worked.
+4. What hurt quality, speed, or confidence.
+5. Root causes for the top one or two issues.
+6. Experiments and action items.
+
+## Agent Team Block
+
+For `/task` pipelines, include router, analyst, developer, **build-verifier**, reviewer, QA/e2e, hooks, and rules.
+
+## Preset feedback loop
+
+If the same issue appeared in 2+ tasks, add section **Preset updates**:
+
+- Proposed change to `.cursor/rules/`, `.cursor/agents/`, or `.cursor/skills/`
+- One concrete diff or file path to update
+- Whether it belongs in always-on rules vs globs vs skill
+
+Do not apply preset changes without user approval.

package/presets/cursor/next/skills/unit-testing/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: unit-testing
+description: Plans, generates, and heals unit tests for mappers, thunks, HTTP client behavior, and React components using colocated *.spec.ts files and tests-unit rules. Use for unit test planning, generation, or fixing failing unit tests.
+---
+
+# Unit Testing
+
+## Project Layout
+
+- Specs colocated with source: `*.spec.ts` / `*.spec.tsx` next to the module under test.
+- Legacy `*.test.ts` / `*.test.tsx` — do not rename without a separate task.
+- Runner: Jest or Vitest as configured in the target repo; components use `@testing-library/react`.
+
+Follow **`tests-unit.mdc`** (Cursor) or **`rules/testing/tests-unit.md`** (Claude).
+
+## Planner
+
+Write or update `.cursor/team/tasks/<slug>/unit-test-plan.md` (or `.claude/team/...`).
+
+Each scenario needs a Russian `it()` title (capital letter after each sentence). Cover mappers, thunks, client behavior branches, and component interactions per AC.
+
+## Generator
+
+Implement specs from `unit-test-plan.md`. Reuse project test-store, HTTP mocks, and existing test utilities. Do not change production code.
+
+## Healer
+
+Fix mocks, async timing, selectors, and setup — preserve business assertions. Use `unit-test-plan.md` and `brief.md` as the behavior contract.
+
+## Validation
+
+Run affected unit tests from `app/` when feasible. Report command, pass/fail, and remaining gaps vs plan.

package/presets/cursor/next/team/README.md

@@ -0,0 +1,109 @@
+# Agent team artifacts
+
+Каталог артефактов пайплайна «команда агентов» Cursor.
+
+## Layout
+
+```
+.cursor/team/
+  active-task.json
+  fixtures/                  # pipeline profile examples (feature-full, feature-light, bugfix-standard)
+  tasks/
+    <slug>/
+      pipeline.json
+      status.json
+      brief.md
+      decomposition.md
+      debug-report.md          # fixApplied: true/false
+      validation-report.md     # build-verifier: PASS | FAIL
+      architecture.md
+      migration-plan.md
+      ci-report.md
+      a11y-review.md
+      perf-report.md
+      security-review.md
+      api-contract-review.md
+      unit-test-plan.md
+      documentation.md
+      review.md
+```
+
+## pipeline.json schema
+
+```json
+{
+  "slug": "order-history-date-filter",
+  "intent": "feature",
+  "summary": "Add date filter to Order History",
+  "steps": [
+    { "agent": "task-analyst", "label": "Clarify and decompose" },
+    { "agent": "feature-developer", "label": "Implement + unit tests", "scope": "unit-in-dev" },
+    { "agent": "build-verifier", "label": "Validation gate" },
+    { "agent": "code-reviewer", "label": "Code review" },
+    { "agent": "qa-tester", "label": "E2E", "scope": "e2e-only" }
+  ],
+  "humanGates": ["after:task-analyst"],
+  "autoChain": true,
+  "skipped": []
+}
+```
+
+### Step fields
+
+| Field | Description |
+|-------|-------------|
+| `agent` | kebab-case name or array when `parallel: true` |
+| `label` | Human-readable step name |
+| `scope` | Passed to agents (e.g. `unit-in-dev`, `e2e-only`) |
+| `skipIf` | `debugger.fixed` \| `ci-investigator.resolved` |
+| `parallel` | Invoke all `agent` values in one parent turn |
+
+## status.json (pipeline mode)
+
+```json
+{
+  "slug": "order-history-date-filter",
+  "intent": "feature",
+  "pipelineIndex": 0,
+  "currentAgent": "task-analyst",
+  "phase": "executing",
+  "state": "in_progress",
+  "awaitingHumanGate": false,
+  "parallelCompleted": [],
+  "retryAfterFix": null,
+  "updatedAt": "2026-05-29T12:00:00.000Z"
+}
+```
+
+### phase
+
+Prefer **`executing`** for pipeline mode. Legacy: `analysis`, `development`, `review`, `testing`, `done`.
+
+### state
+
+| Value | Description |
+|-------|-------------|
+| `in_progress` | Current step running |
+| `completed` | Current step finished |
+| `awaiting_approval` | Human gate; use `/task-continue` |
+| `changes_requested` | Reviewer requires fixes |
+| `validation_failed` | build-verifier failed |
+| `approved` | Legacy continue |
+
+## Workflow entry
+
+```bash
+/task <описание задачи>
+/task-continue <slug>
+/technical-retro <slug>
+```
+
+Legacy: `/feature-start`, `/feature-continue`.
+
+## Creating task dirs
+
+Bootstrap `<slug>/` by **writing** `pipeline.json` / `status.json` (Write tool). Do **not** use Shell `mkdir -p` — Cursor’s default sandbox returns `Operation not permitted` (especially for repos on macOS Desktop/Documents).
+
+## Git
+
+Commit task artifacts if you want them to survive `ai-rules clean cursor`. Or copy finished tasks to `docs/agent-workflow/tasks/<slug>/`.