メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | create-pr |
| description | 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. |
Open a clean, CI-ready pull request from the current branch to main.
git status and ask whether to commit them first (don't commit silently).git branch --show-current.
main: stop. Offer to create a feature branch (suggest a name derived from
the change, e.g. fix/trusted-item-image) and move the commits there. Do not push to main..env, secrets, or coverage output.Run the same gates CI enforces and report results plainly. Stop and surface failures rather than opening a broken PR:
npm run lint
npm run check
npx vitest run
npm run build
If npm run lint fails on autofixable issues, offer npm run lint:fix + npm run format.
If a step fails, fix it or ask the user how to proceed — do not continue to PR creation.
git log --oneline main..HEAD and git diff --stat main...HEAD.431-... → Closes #431).git push -u origin HEAD # if the branch isn't pushed yet
gh pr create --base main --title "<title>" --body "<body>"
End the PR body with:
🤖 Generated with [Claude Code](https://claude.com/claude-code)
.github/workflows/vitest.yaml will run npm run build + npx vitest run --coverage
on the PR and post a coverage comment. Merging to main triggers the Uberspace deploy
(.github/workflows/deploy-to-uberspace.yaml).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.