メニュー
Run the correct validation pipeline (server and/or website) before declaring work done. Use before reporting task completion, when the user asks to "check", "validate", "make sure it builds", or when preparing a commit.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Bump the patch version in server/Cargo.toml or website/package.json after completing a major change. Use when the user asks to bump/release a version, or when CLAUDE.md's rule about version bumps after major changes applies.
Before a non-trivial change, list affected systems — DB schema, API contract, Telegram handlers, jobs, TS types, docs. Catch ripple effects upfront, not after CI fails. Use when planning a feature, migration, refactor, or any cross-module touch.
Self-review before push — read the diff as a reader, scan for vixen footguns (token leaks, PII, idempotency, captcha asset overwrites), run validation pipeline, no surprise files. Use before "git push", before opening a PR, or when the user says "ready to commit".
Write a git commit message for vixen-rs following the project's Conventional Commits convention. Use when the user asks to commit, create a commit, or write a commit message.
Reproduce → bisect → root cause → fix → verify. Don't speculate, don't "add more error handling" as a guess. Use when something is broken, when a test fails intermittently, when the user says "this isn't working" or "investigate why".
Write small, fast, reproducible Dockerfiles for the vixen-rs server (Rust) and website (bun) using multi-stage builds, cache mounts, distroless/alpine runtime images, and non-root users. Use when editing server/Dockerfile, website/Dockerfile, docker-compose.yml, or when the user asks to shrink an image or speed up a Docker build.
| name | verify-changes |
| description | Run the correct validation pipeline (server and/or website) before declaring work done. Use before reporting task completion, when the user asks to "check", "validate", "make sure it builds", or when preparing a commit. |
CLAUDE.md is explicit: do not consider a task done until verified. This skill picks the right checks based on what changed.
Check git status and git diff --name-only (or the list of files just edited):
| Touched paths | Run |
|---|---|
server/** (any Rust, SQL, config) | /server-check |
server/migrations/** | /db-migrate first (refreshes .sqlx/), then /server-check |
website/** (any TS/TSX, CSS, JSON) | /website-check |
website/i18n/** | /website-check plus a manual diff that the same key appears in every locale file |
| Both areas | both check commands, server first |
docker/**, .github/**, root-level docs only | skip — no validation pipeline for these |
cargo sqlx prepare --check for server)./website-check is green, sanity-check the flow manually (Playwright is not yet wired into this repo).server-check: OK with a one-line test/warning count.website-check: OK with a bundle size line.cargo test alone is not sufficient — the slash command intentionally also runs fmt --check, clippy -D warnings, and sqlx prepare --check.bun run typecheck passing does not mean the UI works — for behavior changes, exercise the flow manually..sqlx/ changed, add it to the commit or CI with SQLX_OFFLINE=true will fail.cd server && cargo sqlx prepare --check: if it failed, run /db-migrate (which regenerates .sqlx/), confirm the new files are STAGED, and re-run the check before commit. Missing .sqlx/ updates → CI fails with SQLX_OFFLINE=true cannot find query.tokio::select!), cargo test alone is insufficient — also stress-test by manually triggering concurrent calls or shutdown mid-iteration; tokio_test and loom (for non-async lock testing) are the next levels of rigor.