@bonesofspring/ai-rules 0.2.13 → 0.2.15

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)
+
+- Prefer **`.svelte` SFC** with `<script lang="ts">` (`svelte-script-conventions`).
+- Explicit props (`$props()` / typed props); no mass `{...props}` / `$$restProps` (`no-rest-props-spread`).
+- Svelte 5: snippets / `{@render …}` preferred for new code; legacy slots OK when following neighbors.
+- Styles: scoped `<style>` / tokens — as neighbors do; property order — `css-property-order-stylelint`.
+- Data: read stores / runes / `load` data; **do not** call HTTP from `.svelte` — only via `$lib/api` / store actions.
+- Navigation: `<a href>`, `goto`, `invalidate`, `$app/navigation` — not `next/link`, not `<NuxtLink>`, not `navigateTo`.
+- A11y: `svelte-a11y-coding`.
+- UI boundaries: `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: Agent role for a team/sprint technical retrospective (retro). On-demand — prefer the /technical-retro slash command.
+alwaysApply: false
+---
+
+<!-- shared-core: review/technical-retro.md -->
+
+# Technical retro — rule alias
+
+Full scenario (including the **“Agent work”** block for a slug from team tasks) lives in the slash command:
+
+**`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.
+
+Use this rule only if the command is unavailable. Do not duplicate the command contents in the response — follow the command file and skill `technical-retro`.

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

@@ -0,0 +1,50 @@
+---
+description: Structure of e2e tests and plans (Playwright)
+globs: tests/e2e/**/*
+alwaysApply: false
+---
+
+# E2E structure in the project
+
+- E2E folder: `tests/e2e/**`.
+- Scenario plans:
+  - `*.cases.md` files — **canonical source of scenarios**.
+- Tests:
+  - `*.spec.ts` files — Playwright scenario implementation.
+- Shared utilities and abstractions:
+  - `tests/e2e/_shared/**` — constants, fluent interfaces, helpers.
+
+# Principles
+
+- Every scenario from `*.cases.md` must have a matching test (or set of tests).
+- **Do not** weaken assertions in tests if that contradicts business expectations from the plans.
+- Prefer:
+  - page objects (e.g. `OrderHistoryPage.ts`);
+  - shared helpers from `_shared`.
+
+# E2E test naming
+
+- Language:
+  - all `test` / `it` names, `describe` blocks, and steps in `*.cases.md` must be formulated **in Russian**, describing behavior and the expected result. <!-- i18n-keep: E5 -->
+- E2E title format (`test(...)` / `it(...)`):
+  - before the scenario description, put a **numbered prefix** in the form: `PREFIX-XXX Scenario description`.
+  - `PREFIX` — abbreviation from the **first letters of the words** of the entity under test, written in **Latin uppercase**.
+    - example: `OrderHistory` → `OH`, `BillingReport` → `BR`.
+  - `XXX` — sequential test number **with three digits and leading zeros**: `001`, `002`, `010`, `123`, etc.
+  - full e2e title example:
+    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })` <!-- i18n-keep: E5 -->
+  - within one entity (`PREFIX`), test numbers must form a **consistent sequence** without duplicate numbers.
+
+# data-testid for e2e
+
+- **Selector priority:** `data-testid` for stable elements; `getByRole` and `getByLabel` for forms and accessible elements.
+- **Naming:** scheme `{parent}__{element}` (e.g. `history-page__title`, `history-page__recognition-banner__attach-files-button`).
+- **Where to add:** on page root containers and key interactive elements (buttons, links, fields) that page objects target.
+- **When UI changes:** update data-testid in components and matching selectors in page objects; align with `*.cases.md`.
+
+# Agent requirement
+
+When adding/changing e2e tests:
+- First look at the matching `*.cases.md` and sync scenario names.
+- Place specs next to plans in the same directory.
+- Reuse shared page objects and helpers; do not copy selectors into every test.

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
+---
+
+# Shared testing rules
+
+- **File names:** new tests — **`*.spec.ts`**. Do not rename existing `*.test.ts` without a task.
+- **Runner:** Vitest (or as in the project). Components — **`@testing-library/svelte`** (not `@vue/test-utils`, not React Testing Library as default).
+- Assert **behavior**, not internals.
+- **`describe` / `it` naming:** formulate titles **in Russian**, each sentence capitalized (as with ESLint `jest/valid-title` if enabled). <!-- i18n-keep: E5 -->
+
+```typescript
+// ✅
+it('Возвращает пустой список. Пользователь не авторизован', () => {}) // <!-- i18n-keep: E5 -->
+
+// ❌
+it('Returns empty list when user is guest', () => {})
+```
+
+# Components
+
+- `render` from `@testing-library/svelte`.
+- Interactions: `userEvent` from `@testing-library/user-event` when that is the repo convention.
+
+# Isolation
+
+- Mock `$lib/api` / stores per neighbor patterns.
+- Do not mock the feature’s public contract without need.
+
+# HTTP / mappers
+
+- Changes to the shared HTTP client — behavior tests next to `src/lib/clients/**`.
+- DTO→domain mappers — unit tests for edge cases.
+
+# Placement
+
+- UI: neighboring `*.spec.ts` (no required `__tests__/` inside the component).
+- Other modules — as neighbors do.

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

@@ -0,0 +1,42 @@
+---
+description: JSDoc style for domain and transport types under types
+globs: src/lib/types/**/*.ts
+alwaysApply: false
+---
+
+# Type documentation in `types`
+
+When adding or substantially changing types in this layer **follow the JSDoc style already used in the repository** (see examples: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
+
+## Language and form
+
+- Comment text — **in Russian**, short and to the point: what the type or field means in the domain or API contract.
+- **Do not rely** on tags like `@param`, `@returns`, `@see`, `@deprecated` for type descriptions — they are **not used** in this layer; plain `/** … */` text is enough.
+
+## Exported `type` / `interface`
+
+- Immediately **before the declaration** — a `/** … */` block.
+- If you need to explain data source, constraints, or non-obvious bits — a **second paragraph** in the same block (blank line between paragraphs in JSDoc).
+- For **nested** objects in the same file, each such type gets its own block above its declaration.
+
+## Fields
+
+- Every **public** property — a **one-line** `/** … */` on the line immediately **above** the field.
+- If a field **does not come from the backend “as is”** but is computed or enriched on the frontend (mapper, selector, UI) — start the description with the **`[computed]`** prefix (as in `TUserProfile`, treatment-plan types).
+- For data formats, state that **in the text**: e.g. date `YYYY-MM-DD`, example display string in quotes.
+
+## Classes and other declarations
+
+- For **classes** (e.g. transport errors), when changing the public API — a short block above the class and **comments on public fields** by the same rules as interface properties.
+
+## `enum`
+
+- In `enums.ts` historically often **without JSDoc** on each member; for new enums a short description **above the enum itself** is OK if purpose is not obvious from the name. UI labels — as usual, via `*Names` objects next to the enum.
+
+## Agent practice
+
+- When adding a new type or field, **do not leave** new public fields unexplained if the meaning is not 100% equal to the name.
+- When editing a file that already has such comments, **keep the same style**, do not mix with English or “tag-style” blocks.
+- Do not inflate comments: one–two phrases per type, one line per field — normal; exception — a truly complex domain caveat.
+
+See also imports and 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 **must** 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.