Write Vitest unit tests for the AllerLeih SvelteKit frontend, following this repo's conventions (co-located *.test.ts, mocked PocketBase, testing server functions and +page.server.ts load/actions). Use whenever the user asks to write, add, or improve tests, increase coverage, or "test this" for any server-side function, form action, or load function — even if they don't say "Vitest". Reach for it before merging logic that isn't covered.
Drive a single issue through the full AllerLeih delivery pipeline as an interactive orchestrator: plan → code → review → fix-loop → test → manual-test gate → commit + PR. Each stage runs as a dedicated sub-agent and MUST consult the applicable project skills and CLAUDE.md guardrails. TRIGGERS: "address issue", "fix issue", "work on issue", "implement issue", or any GitHub issue number or URL handed over for delivery — invoke this skill immediately, before any research or coding. Two human gates: plan approval and manual-test OK.
Multi-role review of the current AllerLeih change: four specialised reviewers (security & data protection, code quality, accessibility, conventions) run in parallel against the diff, then the findings are consolidated, deduped and fixed directly — with a change log that records what/where/ why for each fix. Use when a change should be reviewed from all angles and the findings fixed in one go, without opening a PR. Not for GitHub PR reviews (use /review for those) and without a browser test (use /review-and-test for that).
Review-and-verify workflow for AllerLeih: review the current change for security & project correctness, and verify it end-to-end in a real browser — then report. Runs four specialised reviewer roles in parallel (security & data protection, code quality, accessibility, conventions) plus allerleih-tester for the browser + test drive via the Chrome DevTools MCP, and produces one consolidated report. READ-ONLY: it changes no code, runs no fix-loop, opens no PR. Use when you have a change on a feature branch (or uncommitted) and want it reviewed and browser-tested without shipping it.
Scaffold a new SvelteKit route in AllerLeih the way this repo does it — +page.server.ts (load + form actions), +page.svelte (Svelte 5 runes, no data destructuring), a co-located test, and German strings in texts.ts — with the project's PocketBase guardrails baked in. Use whenever the user wants to add a new page, screen, or route, build a CRUD/form page, or "make a page for X", so the route lands consistent and isn't missing pb.filter, trust filtering, or server-side permission checks.
Coordinate a PocketBase schema change across both AllerLeih repos so nothing drifts — the backend migration (delegated to new-migration), the frontend TypeScript types, the data-model docs, and a public-view leak check. Use whenever the user adds/changes/removes a field on a collection, adds a collection, or changes a `*_public` view — anything that touches the schema. The point is to stop the frontend types, docs, and the privacy views from falling out of sync with the database.
Create a new deterministic seed scenario for AllerLeih's local PocketBase (a file under scripts/seed/scenarios/) so reviewers and you can populate a running instance with realistic test data for a feature. Use whenever the user asks to add seed data, create a seed scenario, set up test data for a PR/feature, or "make some data to click through" — anything about populating the local DB to exercise a flow, not about Vitest unit tests.
Audit and update this repo's own .claude/skills against the current codebase, fixing drifted file paths, function signatures, texts.ts keys, route paths, and command names so the skills don't rot. Use whenever the user asks to refresh, audit, update, or check the skills, after a change that touches code the skills reference (a renamed helper, a changed signature, a moved route), or when a skill turns out to be inaccurate. Run it before relying on a skill you haven't used in a while.