菜单
Convert any task to a check that fails before and passes after. "Add validation" → tests for invalid inputs. "Fix bug" → reproduction + assertion. Use before declaring work done, when planning multi-step work, or when the user says "make sure this works".
用 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 | verifiable-goal |
| description | Convert any task to a check that fails before and passes after. "Add validation" → tests for invalid inputs. "Fix bug" → reproduction + assertion. Use before declaring work done, when planning multi-step work, or when the user says "make sure this works". |
Source: CLAUDE.md "After Writing Code".
No work is done until a check proves it. Build green ≠ feature works. Define the check before coding, not after.
cargo sqlx prepare --check passes; an integration test runs against the migrated schema; .down.sql actually reverses (manual verification once).Break into steps. One verifiable checkpoint per step. Don't tee up "I'll verify all at the end" — that's when half of the steps are wrong and you have to rip them out together.
Example: adding a new captcha mode →
cargo test captcha::asset_loader::loads_picture_pick_v1.ChallengeKind enum variant + serde. Check: round-trip serde test.cargo fmt && cargo clippy --all-targets --all-features -- -D warnings && cargo test && cargo sqlx prepare --check. Use /server-check.bun run check && bun run typecheck && bun run build. Use /website-check.State it explicitly. Don't paper over it.
/start in the staging chat after deploy."tokio::time::timeout wraps the call."plan-before-code — defines the goal you're going to verify.code-review-self — last gate before push.verify-changes — run the canonical pipeline.