@bonesofspring/ai-rules 0.2.12 → 0.2.14

package/presets/cursor/svelte/rules/svelte-sveltekit-anti-hallucination.mdc

@@ -0,0 +1,69 @@
+---
+description: Svelte/SvelteKit anti-hallucination banlist — phantom imports, load/server APIs, stores/runes
+globs: "**/*.{svelte,ts,js},src/routes/**/*,src/lib/**/*"
+alwaysApply: false
+---
+
+# Svelte / SvelteKit anti-hallucination
+
+These rows **OVERRIDE** generation for the listed patterns. Before inventing an import, load helper, or store API: verify against `package.json` (installed majors), `svelte.config.*`, and sibling files. If unsure, mark `// VERIFY: lib.symbol @ version` and surface the uncertainty — do not silently stub.
+
+## 1. Phantom `$app/*` / Kit modules
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Invented `$app/foo`, `$app/router`, `$app/auth` | Real `$app/navigation`, `$app/stores`, `$app/forms`, `$app/environment`, `$app/paths`, `$app/state` **for installed major** |
+| Importing Next `next/navigation` / `next/link` | `$app/navigation`, `<a href>` |
+| `navigateTo`, `<NuxtLink>`, `#imports` auto-import phantoms | Kit APIs + explicit imports that exist in repo |
+| Invented `@sveltejs/kit` helpers not in docs/lockfile | Documented Kit exports for installed version |
+
+## 2. Load / page data signatures
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Invented `PageLoad` / `LayoutServerLoad` shapes from blogs | Types from `./$types` generated for the route; match siblings |
+| Returning random keys without `data` contract | Follow existing `+page(.server).ts` return shapes |
+| Calling React `getServerSideProps` / Nuxt `useAsyncData` in Kit | `load` / form actions / `$lib/api` |
+
+## 3. Form actions / enhance
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Phantom `enhance` option bags siblings never use | `$app/forms` `enhance` patterns from neighbors + Kit docs |
+| Invented `fail` / `redirect` import paths | `@sveltejs/kit` exports verified for major |
+| Posting secrets from client form without server action | `+page.server.ts` actions + `$env` discipline |
+
+## 4. `$env/*` misuse
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| `$env/static/private` / private dynamic env in `.svelte` client | Private env only in `.server.ts` / hooks / `+server.ts` |
+| Invented `$env/secret` | `$env/static/public`, `$env/static/private`, `$env/dynamic/*` as documented |
+
+## 5. Runes vs stores
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| `import { $state } from 'svelte/store'` (wrong) | Runes are language/runtime — follow Svelte 5 docs / neighbors |
+| Pinia `defineStore` / RTK `createSlice` | `store-svelte` — writable/derived/readable or runes modules |
+| Invented `createRuneStore` helpers | Patterns already in `src/lib/stores/**` |
+
+## 6. Cross-stack APIs (banned as defaults)
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| React hooks (`useEffect`, `useState` from `react`) | Svelte reactivity / runes / stores |
+| RSC / `next/navigation` / `next/image` | Kit routes + `$app/*` |
+| Vue/Nuxt: `ref`, `defineStore`, `useFetch`, `navigateTo` | Svelte / Kit equivalents above |
+
+## 7. Paths / gates / spreads
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| E2E under `app/__tests__/e2e` | `tests/e2e/**` |
+| Required script named `typecheck` / `type-check` | Package script **`check`** (`svelte-kit sync && svelte-check`) |
+| Unlimited `{...props}` / `$$restProps` as default | Explicit props (`no-rest-props-spread`) |
+| Server-only modules imported into client components | Keep private env / Node APIs in `.server.ts` |
+| Vue-style auto-import of missing symbols | Explicit `$lib` / `$app` imports that exist |
+
+When a row conflicts with a verified sibling pattern in this repo, **the sibling wins** — update this banlist in a preset PR rather than inventing a third path.

package/presets/cursor/svelte/rules/svelte-ui.mdc

@@ -0,0 +1,37 @@
+---
+description: Svelte SFC UI conventions (components, routes)
+globs: src/lib/components/**/*,src/routes/**/*
+alwaysApply: false
+---
+
+# Svelte UI (SvelteKit)
+
+- Предпочитать **`.svelte` SFC** с `<script lang="ts">` (`svelte-script-conventions`).
+- Явные props (`$props()` / typed props); без массового `{...props}` / `$$restProps` (`no-rest-props-spread`).
+- Svelte 5: snippets / `{@render …}` preferred for new code; legacy slots OK when following neighbors.
+- Стили: scoped `<style>` / tokens — как у соседей; порядок свойств — `css-property-order-stylelint`.
+- Данные: читать stores / runes / `load` data; **не** вызывать HTTP из `.svelte` — только через `$lib/api` / store actions.
+- Навигация: `<a href>`, `goto`, `invalidate`, `$app/navigation` — не `next/link`, не `<NuxtLink>`, не `navigateTo`.
+- A11y: `svelte-a11y-coding`.
+- Границы UI: `architecture-boundaries-ui` — no DTO in markup; map in `src/lib/api/**`.
+
+## Incorrect
+
+```svelte
+<script lang="ts">
+  const data = await fetch('/api/items').then((r) => r.json())
+</script>
+```
+
+## Correct
+
+```svelte
+<script lang="ts">
+  import { onMount } from 'svelte'
+  import { loadItems } from '$lib/stores/items'
+
+  onMount(() => {
+    void loadItems()
+  })
+</script>
+```

package/presets/cursor/svelte/rules/sveltekit-routing.mdc

@@ -0,0 +1,39 @@
+---
+description: SvelteKit file-based routing, layouts, load, form actions
+globs: src/routes/**/*,svelte.config.*
+alwaysApply: false
+---
+
+# SvelteKit routing
+
+Canonical layout: **SvelteKit `src/`** — `src/routes/**`.  
+Flat (no-`src/`) layouts exist; **do not** default globs/examples to them or to Next `app/src/**` / Nuxt `pages/**`.
+
+## Routing
+
+- File-based routes: `+page.svelte`, `+layout.svelte`, `+error.svelte`.
+- Load: `+page.ts` / `+page.server.ts` / `+layout.ts` / `+layout.server.ts` — verify signatures against installed `@sveltejs/kit`.
+- Form actions in `+page.server.ts`; progressive enhancement via `$app/forms` `enhance` when used in repo.
+- API / BFF: `+server.ts`; app hooks in `src/hooks.server.ts` / `src/hooks.client.ts` — see `security-sveltekit`.
+- Navigation: `<a href>`, `goto`, `invalidate`, `beforeNavigate`, `$app/navigation` — not `next/navigation`, not `navigateTo` / `<NuxtLink>`.
+
+## Data on pages
+
+- Prefer `$lib/api` services + mappers for domain mapping; `load` may use event `fetch` for same-origin SSR cookie forwarding.
+- Client orchestration via `store-svelte` (stores / runes).
+- Secrets only via `$env/static/private` / server modules — never `$env/static/private` in client components.
+
+## Incorrect
+
+```ts
+import { useRouter } from 'next/navigation'
+import { navigateTo } from '#app'
+```
+
+## Correct
+
+```ts
+import { goto } from '$app/navigation'
+
+await goto('/items')
+```

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

@@ -0,0 +1,16 @@
+---
+description: Роль агента для проведения технического ретроспективы (retro) команды / спринта. On-demand — предпочтительнее slash-команда /technical-retro.
+alwaysApply: false
+---
+
+<!-- shared-core: review/technical-retro.md -->
+
+# Техническое ретро — rule alias
+
+Полный сценарий (включая блок **«Работа агентов»** для slug из team tasks) — в slash-команде:
+
+**`commands/technical-retro.md`** → `/technical-retro`
+
+When a task has `metrics.json`, use the local aggregation script and state the cohort, sample size, incomplete artifacts, attribution confidence, active attempt duration, and human-gate wait separately. Do not score malformed artifacts or gate wait as agent work.
+
+Используй rule только если command недоступен. Не дублируй содержимое command в ответе — следуй command-файлу и skill `technical-retro`.

package/presets/cursor/svelte/rules/tests-e2e-structure.mdc

@@ -0,0 +1,51 @@
+---
+description: Структура e2e тестов и планов (Playwright)
+globs: tests/e2e/**/*
+alwaysApply: false
+---
+
+# Структура e2e в проекте
+
+- Папка e2e: `tests/e2e/**`.
+- Планы сценариев:
+  - `*.cases.md` файлы — **канонический источник сценариев**.
+- Тесты:
+  - `*.spec.ts` файлы — реализация сценариев на Playwright.
+- Общие утилиты и абстракции:
+  - `tests/e2e/_shared/**` — константы, fluent‑интерфейсы, хелперы.
+
+# Принципы
+
+- Каждый сценарий из `*.cases.md` должен иметь соответствующий тест (или набор тестов).
+- **Нельзя** ослаблять проверки в тестах, если это противоречит бизнес‑ожиданиям из планов.
+- Предпочтительно использовать:
+  - page‑objects (например, `OrderHistoryPage.ts`);
+  - общие хелперы из `_shared`.
+
+# Именование e2e‑тестов
+
+- Язык:
+  - все названия `test` / `it`, `describe`‑блоков и шагов в `*.cases.md` должны быть сформулированы **на русском языке**, описывая поведение и ожидаемый результат.
+- Формат заголовков e2e‑тестов (`test(...)` / `it(...)`):
+  - перед текстовым описанием сценария указывается **префикс с номером** в формате: `ПРЕФИКС-XXX Описание сценария`.
+  - `ПРЕФИКС` — аббревиатура из **первых букв слов** тестируемой сущности, записанная **латиницей в верхнем регистре**.
+    - пример: `OrderHistory` → `OH`, `BillingReport` → `BR`.
+  - `XXX` — порядковый номер теста **с тремя разрядами и лидирующими нулями**: `001`, `002`, `010`, `123` и т.д.
+  - пример полного названия e2e‑теста:
+    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })`
+  - внутри одной сущности (`ПРЕФИКС`) номера тестов должны образовывать **непротиворечивую последовательность**, без дубликатов номеров.
+
+# data-testid для e2e
+
+- **Приоритет селекторов:** `data-testid` для стабильных элементов; `getByRole` и `getByLabel` для форм и доступных элементов.
+- **Именование:** схема `{parent}__{element}` (например, `history-page__title`, `history-page__recognition-banner__attach-files-button`).
+- **Где добавлять:** на корневые контейнеры страниц и ключевые интерактивные элементы (кнопки, ссылки, поля), к которым обращаются page objects.
+- **При изменении UI:** обновлять data-testid в компонентах и соответствующие селекторы в page objects; сверять с `*.cases.md`.
+
+# Требование к агенту
+
+При добавлении/изменении e2e‑тестов:
+- Сначала смотреть соответствующий `*.cases.md` и синхронизировать названия сценариев.
+- Размещать спеки рядом с планами в той же директории.
+- Переиспользовать общие page‑objects и хелперы, а не копировать селекторы напрямую в каждый тест.
+

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

@@ -0,0 +1,42 @@
+---
+description: Unit tests — Vitest + Testing Library Svelte; colocated *.spec.ts
+globs:
+  - "**/*.{spec,test}.ts"
+alwaysApply: false
+impact: MEDIUM
+---
+
+# Общие правила тестирования
+
+- **Имена файлов:** новые тесты — **`*.spec.ts`**. Существующие `*.test.ts` не переименовывать без задачи.
+- **Runner:** Vitest (или как в проекте). Компоненты — **`@testing-library/svelte`** (не `@vue/test-utils`, не React Testing Library as default).
+- Проверять **поведение**, не внутренности.
+- **Именование** `describe` / `it`: формулировки **на русском**, каждое предложение с заглавной (как в ESLint `jest/valid-title` если включён).
+
+```typescript
+// ✅
+it('Возвращает пустой список. Пользователь не авторизован', () => {})
+
+// ❌
+it('Returns empty list when user is guest', () => {})
+```
+
+# Компоненты
+
+- `render` из `@testing-library/svelte`.
+- Взаимодействия: `userEvent` из `@testing-library/user-event` когда принято в репо.
+
+# Изоляция
+
+- Мокать `$lib/api` / stores по паттерну соседей.
+- Не мокать публичный контракт фичи без нужды.
+
+# HTTP / mappers
+
+- Изменения общего HTTP‑клиента — behavior‑тесты рядом с `src/lib/clients/**`.
+- Мапперы DTO→domain — unit‑тесты на edge‑кейсы.
+
+# Размещение
+
+- UI: соседний `*.spec.ts` (не обязательный `__tests__/` внутри компонента).
+- Другие модули — как у соседей.

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

@@ -0,0 +1,42 @@
+---
+description: Стиль JSDoc для доменных и транспортных типов в types
+globs: src/lib/types/**/*.ts
+alwaysApply: false
+---
+
+# Документация типов в `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/svelte/skills/README.md

@@ -0,0 +1,17 @@
+# `.cursor/skills` (preset svelte)
+
+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 |
+| `write-adr` | Author an Architecture Decision Record (context / decision / consequences) |
+| `svelte-performance` | Implementer checklist: bundle, SSR/payload/client, memo, waterfalls, CWV (not a perf audit agent) |
+
+Skills are copied to `.cursor/skills/` by `ai-rules init cursor --preset svelte`.

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

@@ -0,0 +1,36 @@
+---
+name: ci-investigation
+description: Investigates failing CI checks on PRs and branches — lint, typecheck, 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, typecheck, 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 repository root:
+   - `lint:js`, `lint:css`, `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/svelte/skills/code-review/SKILL.md

@@ -0,0 +1,38 @@
+---
+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. **Reuse lens:** flag new helpers that duplicate existing utilities; prefer adjacent shared modules over copy-paste.
+8. **Efficiency lens:** unnecessary work, sequential ops that should be parallel, hot-path bloat, no-op store updates, overly broad reads.
+9. Report validation gaps: lint, stylelint, typecheck, or relevant tests not run.
+
+## Output
+
+Lead with findings ordered by severity. Required shape (also in `code-review-mr`):
+
+- Each finding: **`path:line`** — problem — impact — concrete fix direction.
+- Severity: **`blocker` | `important` | `nit`** (list blocker → nit).
+- Vague («looks risky») is not a finding — cite evidence or ask for surrounding context.
+- End with a verdict line: **`Safe to merge | needs changes | reject`**.
+- 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`.
+
+## Design guidance
+
+- Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.

package/presets/cursor/svelte/skills/debug-investigation/SKILL.md

@@ -0,0 +1,32 @@
+---
+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.
+
+## Design guidance
+
+- Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.

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

@@ -0,0 +1,34 @@
+---
+name: feature-delivery
+description: Delivers SvelteKit 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`** and **`reference-features`** — follow layer order and mirror closest reference feature.
+3. Add or update focused tests for changed behavior.
+4. Validation from SvelteKit root: **invoke** **`post-change-lint`** after code edits (requestable, not always-on — but mandatory when code changed). Pipeline: scoped lint OK if next step is `build-verifier`.
+
+## Scope discipline
+
+Implement only the current AC / decomposition task. Clarify ambiguity before coding; do not add unrelated hardening, polish, or refactors. See `feature-developer` → **Zero improvisation**.
+
+## Handoff
+
+Summarize by layer, validation results, and known gaps. Agent team: update `.cursor/team/tasks/<slug>/status.json`.
+
+## Design guidance
+
+- Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.
+
+## Anti-hallucination
+
+- When editing Svelte/TS under `src/**`, load `svelte-sveltekit-anti-hallucination` (phantom Kit/Svelte/React/Vue imports).
+
+## Stack notes (SvelteKit)
+
+- Layers: `src/routes` / `src/lib/components` → facades → `src/lib/stores` (store-svelte) → `src/lib/api` → `src/lib/clients`; server via `+server.ts` / hooks.
+- Anti-hallucination: `svelte-sveltekit-anti-hallucination`.
+- Scripts cwd: SvelteKit root (`svelte.config.*`); gates: `lint:js`, `lint:css`, `check`.
+- E2E: `tests/e2e/` (Playwright).

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

@@ -0,0 +1,37 @@
+---
+name: playwright-e2e
+description: Plans, generates, and heals Playwright e2e tests using this preset's 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: `tests/e2e`.
+- Test plans: `*.cases.md` files under the matching feature folder.
+- Executable specs: `*.spec.ts` files in the same folder.
+- Seed/setup reference: `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.
+
+
+## Stack notes (SvelteKit)
+
+- E2E root: `tests/e2e/`.
+- Default baseURL `http://localhost:3000`; prefer `webServer` → `svelte dev` or `svelte preview`.

package/presets/cursor/svelte/skills/svelte-performance/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: svelte-performance
+description: SvelteKit performance checklist for implementers — bundle, lazy routes, dynamic import, load waterfalls, hydration, Core Web Vitals. Use while coding a svelte feature; not a substitute for the performance-auditor agent when the user asks for an audit report.
+---
+
+# Svelte performance (SvelteKit)
+
+On-demand checklist for **implementers** shipping SvelteKit UI. For a formal diff audit report, use the **`performance-auditor`** agent instead — this skill does not replace it.
+
+**No RSC model** — SvelteKit uses SSR/CSR/hydration; do not apply Next Server Component guidance. Do not apply Vue/Nuxt payload APIs as defaults.
+
+## Bundle
+
+- Prefer route-level code-splitting (file routes) and dynamic `import()` for heavy UI (charts, editors).
+- Avoid importing large libraries into root `+layout` that run globally; keep client entry points small.
+- Check that barrel files do not re-export heavy modules into every consumer.
+
+## Lazy routes & dynamic import
+
+- Heavy feature UI: lazy via dynamic `import()` or a separate route.
+- Do not eagerly import large optional widgets into the root layout.
+- Prefer patterns already used in the repo over inventing a second loader.
+
+## Load & data waterfalls
+
+- Avoid sequential `await` chains in `load` that could be parallel (`Promise.all`) when independent.
+- Prefer shared services/mappers in `$lib/api`; dedupe with existing keys/invalidation patterns.
+- Stores/runes for client-mutable state — do not invent a second cache layer.
+
+## Hydration
+
+- Keep SSR markup consistent with client first paint; avoid `window` in universal modules without client guards.
+- Prefer client-only mount patterns already in the repo for browser-only widgets.
+- Do not ship large client-only state into the critical SSR path without need.
+
+## Reactivity discipline
+
+- Do **not** add derived/memo wrappers by default for trivial state.
+- Prefer fixing state placement and `{#each}` keys over blanket memoization.
+- Follow Svelte 5 runes / store patterns used by neighbors (`store-svelte`).
+
+## Core Web Vitals (quick)
+
+| Metric | Implementer checks |
+|--------|--------------------|
+| LCP | Hero/media not blocked by unnecessary client JS; sensible image sizing |
+| INP | Click handlers lean; avoid long sync work on the main thread |
+| CLS | Reserve space for images/skeleton; stable fonts |
+
+## Handoff
+
+If the user asks for a **performance audit report** of a diff/deliverable, route to **`performance-auditor`** (readonly `perf-report.md`), not this skill alone.

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

@@ -0,0 +1,54 @@
+---
+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.
+
+## Wrong-turn taxonomy (optional)
+
+When artifacts or the user mention agent mistakes, tag incidents:
+
+| Kind | Signal |
+|------|--------|
+| `correction` | User pushback («no», «don't», «actually») |
+| `retry` | Same tool/approach 2+ times before success |
+| `waste` | Many searches before the right file |
+| `reversal` | Edit then revert / delete |
+| `dead-end` | Env/tool failure (missing binary, wrong path) |
+
+Severity: **high** (explicit correction / large waste) · **med** · **low**. Confidence 0–100 — be honest; low-confidence items are optional.
+
+## Preset feedback loop
+
+If the same issue appeared in **2+** tasks (or **3+** for packaging a new rule/skill — Rule of Three), add section **Preset updates**:
+
+- Proposed change to `.cursor/rules/`, `.cursor/agents/`, `.cursor/skills/`, or **`.cursor/team/conventions.md`** (prefer conventions for project gotchas)
+- One concrete snippet or file path
+- Whether it belongs in always-on vs globs vs skill vs conventions (see `PRESET-CONTRIBUTION` → Building blocks)
+
+Do not apply preset or conventions changes without user approval.

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

@@ -0,0 +1,32 @@
+---
+name: unit-testing
+description: Plans, generates, and heals unit tests for mappers, Svelte stores/runes actions, HTTP client behavior, and Svelte 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` next to the module under test.
+- Legacy `*.test.ts` — do not rename without a separate task.
+- Runner: Jest or Vitest as configured in the target repo; components use `@testing-library/svelte`.
+
+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, Svelte stores/runes actions, 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 repository root when feasible. Report command, pass/fail, and remaining gaps vs plan.