@bonesofspring/ai-rules 0.2.13 → 0.2.15

package/presets/cursor/nuxt/rules/store-pinia.mdc

@@ -0,0 +1,68 @@
+---
+description: Pinia stores and client application state (Nuxt)
+globs: stores/**/*.ts,stores/**/*.js
+alwaysApply: false
+impact: HIGH
+---
+
+# General principles
+
+- Use **Pinia** (`defineStore`) — setup or options store, as neighbors do in the repo.
+- Module: `@pinia/nuxt` (or the installed equivalent) — check `package.json` / `nuxt.config`.
+- Store **domain models**, not raw API DTOs.
+- DTO → domain mapping — in `api/**` (or server mappers) **before** writing to the store.
+- Separate server state (API data) from local UI state (filters/flags) — UI-only may live in a composable/`ref` on the page if that is the repo convention.
+
+# Forbidden in this preset
+
+- RTK / Redux: `createSlice`, `createAsyncThunk`, RTK Query, `useDispatch` / `useSelector`, stem `store-rtk`.
+- Raw `$fetch` / `fetch` from the store bypassing `~/api` / `@/api` services (except narrow documented repo exceptions).
+
+# Structure
+
+- One domain module — its own file under `stores/**` (e.g. `stores/profile.ts`).
+- Export: `useXStore` via `defineStore('x', …)`.
+- State: explicit type; careful initialization.
+- Getters — derived from domain state; actions call services from `~/api` / `@/api` (`public-imports`).
+
+# Async
+
+```ts
+// Incorrect — raw HTTP + DTO in state
+export const useProfileStore = defineStore('profile', {
+  actions: {
+    async load() {
+      this.profile = await $fetch('/api/profile')
+    },
+  },
+})
+
+// Correct
+import { profileApi } from '~/api'
+
+export const useProfileStore = defineStore('profile', {
+  state: (): { profile: Profile | null } => ({ profile: null }),
+  actions: {
+    async load() {
+      this.profile = await profileApi.getProfile()
+    },
+  },
+})
+```
+
+# Typing and errors
+
+- Domain types from `~/types` / `@/types`.
+- Transport errors — contracts from `@/types` / the accepted client error class (`http-client`), not invented axios shapes.
+- In UI: `storeToRefs` for state; call actions directly on the store.
+
+# Testing
+
+- Cover important stores (init, transitions, actions with mocked API).
+- Unit: Vitest; mock `~/api` services.
+
+# Agent requirement
+
+- Do not put HTTP/transport in components.
+- Strictly type state/actions.
+- Follow neighboring store style.

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

@@ -0,0 +1,16 @@
+---
+description: Agent role for running a technical retrospective (retro) for a team / sprint. 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/nuxt/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/nuxt/rules/tests-unit.mdc

@@ -0,0 +1,77 @@
+---
+description: Unit and integration tests (Testing Library and project runner)
+globs:
+  - **/*.spec.{ts,tsx}
+  - **/*.test.{ts,tsx}
+alwaysApply: false
+impact: MEDIUM
+---
+
+# General testing rules
+
+- **File names:** for **new** tests use the **`*.spec.ts` / `*.spec.ts`** suffix. Do not rename existing **`*.test.ts` / `*.test.tsx`** without a separate task (legacy).
+- **Runner and matchers** — as in the project (often Jest or Vitest); for components — **@vue/test-utils**.
+- Primary goal of tests:
+  - verify **behavior and business rules**, not implementation or internal details.
+- **Unit test naming** (strings in `describe` / `it` / `test`):
+  - consumer apps **may use Russian locale** for titles — clear business phrases (what is checked and expected outcome);
+  - when ESLint enforces Russian (see below), each sentence in the title **must start with a capital letter** (including after `.`, `!`, `?` and with multiple sentences on one line); the first letter of the whole string is capitalized too.
+  - **CI check (when configured):** ESLint (`jest/valid-title` in `eslint.config.mjs`) may require titles to start with a Russian capital letter and forbid a space after `.` followed immediately by a lowercase letter (typical "capital after period" violation).
+
+Good (Russian locale in consumer app):
+
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 --> (Returns empty list. User is not authorized)
+- `it('При ошибке сети показывается сообщение об ошибке', () => {})` <!-- i18n-keep: E5 --> (On network error, an error message is shown)
+
+Bad (no capital after period; or wrong locale for configured ESLint):
+
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+- `it('Returns empty list when user is guest', () => {})`
+
+# Component tests
+
+- Use `render` from `@vue/test-utils`.
+- Assertions:
+  - DOM matchers for Testing Library as wired in the project (`toBeInTheDocument`, `toHaveTextContent`, etc.).
+- Interactions:
+  - `userEvent` from `@testing-library/user-event`.
+
+# Isolation and mocks
+
+- For API/store work:
+  - mock the store (via test-store) or use the project's accepted HTTP/API mock approach.
+- Do not mock what is part of the feature's public contract if that breaks the test's meaning.
+
+# HTTP client
+
+- When changing the **shared HTTP client implementation** (body parsing, headers, error branches, 401/refresh, `FormData`, `blob`, etc.) — **update or add behavior tests** next to the client module in `lib/clients/**` (prefer `*.spec.ts`; legacy `*.test.ts` — do not touch without a task).
+- Cover meaningful branches: successful JSON, HTTP error, network, auth scenarios relevant to the project.
+
+# Mappers and data transformation
+
+- Data mapping functions (DTO → domain model and back), especially with computed fields and branches, must have unit tests.
+- In mapper tests, pay special attention to edge cases and business-rule regression (for example, boundary values, missing fields, unexpected value combinations).
+
+# Agent requirement
+
+When adding tests:
+- Follow existing test structure and patterns in the repository: `*.spec.ts(x)` next to the module or in a shared test directory — as in neighboring features.
+- Add tests for critical logic branches and edge cases.
+ - When working with data:
+   - use **response types** from the API (DTO types) and **target domain types** from `@/types`; do not duplicate interfaces in tests;
+   - when possible, rely on data and handlers from `mocks/**` (or repo equivalent), not ad-hoc random test data.
+ - Placement:
+   - for **UI components** — **do not create** a `__tests__` subdirectory inside the component folder; the test is a sibling `*.spec.ts`.
+   - in **other modules** (for example `api/services`) an existing `__tests__` layout is acceptable — do not break it for UI uniformity.
+   - **new** files — `*.spec.ts` / `*.spec.ts` (see "File names" above).
+## Incorrect
+
+```ts
+it('returns empty list when guest', () => {})
+```
+
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+
+## Correct
+
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->

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

@@ -0,0 +1,42 @@
+---
+description: JSDoc style for domain and transport types under types
+globs: 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/nuxt/rules/vue-a11y-coding.mdc

@@ -0,0 +1,15 @@
+---
+description: Accessibility coding standards for Vue/Nuxt UI
+globs: components/**/*.{vue,ts},pages/**/*.{vue,ts},layouts/**/*.{vue,ts}
+alwaysApply: false
+---
+
+# Vue accessibility
+
+- Semantic HTML first (`button`, `nav`, `main`, headings hierarchy).
+- Interactive controls keyboard-reachable; visible focus.
+- Images: meaningful `alt` (or empty alt for decorative).
+- Forms: label association; error text linked via `aria-describedby` / native validation patterns used in repo.
+- Prefer project a11y eslint (`eslint-plugin-vuejs-accessibility` when present) over inventing ARIA.
+- Modals/dialogs: focus trap + Escape — follow existing component patterns.
+- Do not rely on color alone for status.

package/presets/cursor/nuxt/rules/vue-nuxt-anti-hallucination.mdc

@@ -0,0 +1,68 @@
+---
+description: Vue/Nuxt/Pinia anti-hallucination banlist — phantom imports, deprecated APIs, store phantoms
+globs: "**/*.{vue,ts,js},pages/**/*,components/**/*,composables/**/*,stores/**/*,server/**/*"
+alwaysApply: false
+---
+
+# Vue / Nuxt / Pinia anti-hallucination
+
+These rows **OVERRIDE** generation for the listed patterns. Before inventing an import, composable, or store helper: verify against `package.json` (installed majors), `nuxt.config.*`, and sibling files. If unsure, mark `// VERIFY: lib.symbol @ version` and surface the uncertainty — do not silently stub.
+
+Routing-specific rows stay in **`nuxt-pages-routing`**. This rule covers broader Vue / Nuxt / Pinia phantoms across the app tree.
+
+## 1. Phantom / wrong Nuxt imports
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| `import { useRouter } from 'next/navigation'` / `next/router` | Nuxt auto-import `useRouter` / `useRoute` / `navigateTo` |
+| `import Link from 'next/link'` / `<Link>` from Next | `<NuxtLink>` |
+| `import Image from 'next/image'` | `<NuxtImg>` / project image helper (check `@nuxt/image`) |
+| Invented: `nuxt/app/router`, `nuxt/server-only`, `nuxt/auth` | Real `#app` / `#imports` / documented Nuxt APIs for **installed** major |
+| `defineNuxtConfig` options copied from blogs without checking major | Match installed Nuxt + existing `nuxt.config.*` |
+| Pages Router Next APIs (`getServerSideProps`) in Nuxt | `useAsyncData` / `useFetch` / server routes / Pinia — mirror siblings |
+
+## 2. SSR / client boundary
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Reading secrets via `useRuntimeConfig().apiSecret` in client-only UI blindly | Private keys under `runtimeConfig` (server); public under `runtimeConfig.public` |
+| Using `window` / `document` in setup without client guards | `onMounted`, `import.meta.client`, `<ClientOnly>` |
+| Pinia stores that assume browser storage during SSR without pattern | Persist plugins / cookie patterns already in repo; guard client APIs |
+| Importing Node-only modules into universal SFC setup | Keep in `server/**` or server-only utils |
+
+## 3. Vue patterns
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| React hooks in Vue SFCs (`useState`/`useEffect` from `react`) | `ref` / `reactive` / `computed` / `watch` / lifecycle (`onMounted`, …) |
+| `import { useEffectEvent } from 'vue'` (phantom) | Real Vue APIs for installed major; else local pattern + `VERIFY` |
+| Options API churn in a `<script setup>` codebase | Follow neighbor SFCs (`script-setup-conventions`) |
+| Phantom packages: `@vue/nonexistent`, invented `~/composables/useServerQuery` | Only lockfile packages + composables that exist |
+
+## 4. Pinia phantoms
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| RTK APIs: `createSlice`, `createAsyncThunk`, `useDispatch` | `defineStore` + actions (`store-pinia`) |
+| Invented helpers: `definePiniaApi`, `store.injectEndpoints` | Documented Pinia + patterns from existing `stores/**` |
+| Deep imports breaking public API: `~/stores/foo/internal` | Public store module / naming used by siblings |
+| Storing raw transport DTOs in state | Domain models from `~/types` after mapper in `api/**` |
+
+## 5. Navigation / data / fetch
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Raw `$fetch` / `fetch` from SFC bypassing `~/api` | Services via `~/api` / `@/api` (`api-services`, `http-client`) |
+| Invented `useFetch` option names siblings never use | Copy from sibling; verify Nuxt data-fetching docs for installed major |
+| Axios error shapes when the client is ofetch/`$fetch` | Transport errors from project types / ofetch patterns |
+| Assuming `baseURL` without checking Nitro / runtimeConfig | Match `lib/clients` / existing client wrapper |
+
+## 6. Version drift / auto-imports
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Bleeding-edge Nuxt/Vue APIs without checking `package.json` | Confirm majors; copy a compiling sibling |
+| Inventing `#imports` symbols that are not generated | Check `.nuxt/imports` / docs; explicit import if missing |
+| Mixing Vue 2 Options-only APIs into Vue 3 Nuxt 3 apps | Vue 3 idioms used in repo |
+
+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/nuxt/rules/vue-ui.mdc

@@ -0,0 +1,33 @@
+---
+description: Vue 3 SFC UI conventions for Nuxt (components, pages, layouts)
+globs: components/**/*.{vue,ts},pages/**/*.{vue,ts},layouts/**/*.{vue,ts}
+alwaysApply: false
+---
+
+# Vue UI (Nuxt)
+
+- Prefer **SFC** with `<script setup lang="ts">` (`script-setup-conventions`).
+- Explicit `defineProps` / `defineEmits` (typed); no bulk `v-bind="object"` (`no-v-bind-spread`).
+- Styles: scoped / CSS modules / design tokens — as neighbors; property order — `css-property-order-stylelint`.
+- Data: read Pinia / composables; **do not** call HTTP from SFC — only via `~/api` / store actions.
+- Navigation: `<NuxtLink>`, `navigateTo`, `useRouter` / `useRoute` — not `next/link` / `next/navigation`.
+- A11y: `vue-a11y-coding`.
+- UI boundaries: `architecture-boundaries-ui` — no DTO in templates; map in `api/**`.
+
+## Incorrect
+
+```vue
+<script setup lang="ts">
+const data = await $fetch('/api/items')
+</script>
+```
+
+## Correct
+
+```vue
+<script setup lang="ts">
+import { useItemsStore } from '~/stores/items'
+const store = useItemsStore()
+onMounted(() => { void store.load() })
+</script>
+```

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

@@ -0,0 +1,17 @@
+# `.cursor/skills` (preset nuxt)
+
+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) |
+| `vue-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 nuxt`.

package/presets/cursor/nuxt/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`, `typecheck`
+   - 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/nuxt/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/nuxt/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/nuxt/skills/feature-delivery/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: feature-delivery
+description: Delivers Nuxt 3 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 repository root: **invoke** **`post-change-lint.mdc`** 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 app TS/TSX, load `vue-nuxt-anti-hallucination` (phantom Next/React/RTK imports).
+
+
+## Stack notes (Nuxt)
+
+- Layers: pages/components → composables → stores (Pinia) → api → http; server/api Nitro.
+- Anti-hallucination: `vue-nuxt-anti-hallucination`.
+- Scripts cwd: repository root; gates: `lint:js`, `lint:css`, `typecheck`.

package/presets/cursor/nuxt/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 (Nuxt)
+
+- E2E root: `tests/e2e/`.
+- Default baseURL `http://localhost:3000`; prefer `webServer` → `nuxt dev` or `nuxt preview`.

package/presets/cursor/nuxt/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.