菜单
Add or modify a captcha mode (digits, picture-pick, etc.) — atomic image render + DB row + sendPhoto + restrictChatMember; deterministic per challenge_id.
用 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 | captcha-pipeline |
| description | Add or modify a captcha mode (digits, picture-pick, etc.) — atomic image render + DB row + sendPhoto + restrictChatMember; deterministic per challenge_id. |
Read first:
seed = xxh3_64(challenge_id). Same challenge_id → same solution → same image.image + ab_glyph from assets in server/assets/captcha/. Run inside tokio::task::spawn_blocking — CPU-bound.INSERT INTO captcha_challenges (chat_id, user_id, challenge_id, solution, asset_version, expires_at, attempts_left).bot.send_photo(...) with inline keyboard, then bot.restrict_chat_member(...) with until_date = now + ttl.SELECT ... FOR UPDATE the challenge → verify → DELETE row → INSERT verified_users → lift restriction via bot.restrict_chat_member with full perms.Render twice with the same challenge_id and assert byte equality. Required for the deterministic-render test suite.
server/src/services/captcha_service.rs — solution gen + render.server/src/telegram/handlers/captcha.rs — issue + callback solve.server/tests/captcha_determinism.rs — byte-equality test.server/docs/captcha.md — mode table.server/assets/captcha/ are immutable. Never overwrite an existing TTF/PNG. New look = new file with version suffix (DejaVuSans-v2.ttf) + bumped asset_version selector.until_date for restrict_chat_member must be ≥ 30s in the future (or 0 for permanent in some contexts) — Telegram silently treats values too close to "now" as permanent.attempts_left decrement uses SELECT ... FOR UPDATE. Without the row lock, two concurrent CallbackQueries from a tap-spam can both see attempts_left = 1 and both decrement.kick, not ban. Kicked users can rejoin and try again; banned users can't, which is the wrong UX for a failed captcha.spawn_blocking. Don't render on the runtime's I/O threads.i64 in the schema (chat_id BIGINT, user_id BIGINT).cargo test captcha.cargo sqlx prepare --check./verify in dev chat, solve, re-issue with same input → identical image bytes.add-migration — captcha_challenges schema additions.add-telegram-handler — CallbackQuery answer-within-30s rule.transaction-discipline — SELECT ... FOR UPDATE patterns.