share-mvp

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.

Bring up the local AllerLeih stack and drive the running app in a browser via the Playwright MCP — to click through a flow, verify a change end-to-end, take screenshots, or reproduce a bug in the real UI (not just tests). Use whenever the user wants to "open the app", "click through", "see it in the browser", "verify it works", or manually exercise a page. Handles this machine's stack-startup and Playwright-MCP gotchas so it works on the first try.

Wire up a new notification type end-to-end in AllerLeih (the NotificationType union, the German body string, the trigger site that creates + pushes it, and the in-app list routing/icon). Use whenever the user wants to add, send, or notify about a new event — e.g. "notify the owner when X happens", "add a notification for Y", "send a push when Z" — so the notification isn't half-wired (a created record with no push, or a push that links to a dead page).

Audit the project's changed Svelte components for accessibility issues (aria labels, decorative SVGs, label associations, live regions, German alt text, keyboard reachability) following AllerLeih's existing a11y patterns. Use when the user asks for an a11y/accessibility review of UI changes. Reports findings; does not edit code unless asked.

Open a pull request to main for the AllerLeih repo. Runs the lint/check/test/build preflight, drafts a title and body from the branch diff, and creates the PR with gh. Use when the user asks to open/create a PR, raise a pull request, or "ship" the current branch.