菜单
Add a new spam-detection rule (text normalization → score → action). Wire into the cascade after dedup + CAS, with corpus tests under server/tests/spam_corpus/.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | spam-rule |
| description | Add a new spam-detection rule (text normalization → score → action). Wire into the cascade after dedup + CAS, with corpus tests under server/tests/spam_corpus/. |
Read first:
xxh3_64 of normalized text → spam_messages lookup.chat_config.spam_threshold.moderation_actions ledger.pub fn detect(normalized: &str, config: &ChatConfig) -> f32 in server/src/services/spam_{rule}.rs.spam_service.rs cascade (registered with a default weight).server/tests/spam_corpus/{rule}.yaml — ≥5 positive + ≥5 negative. No rule without corpus.chat_config.spam_weights JSONB schema.server/tests/spam_pipeline.rs.moderation_actions.reason JSON for explainability.server/docs/spam-detection.md rule table.spam_messages is bypassed for re-processed retries. Gate the action on the moderation_actions uniqueness key (chat_id, target_user_id, action, message_id) before issuing any ban/kick.i64 in any SQL the rule touches.cargo test spam_pipeline.cargo test --test spam_corpus_{rule} if you split the corpus into its own test file.add-migration — spam_weights JSONB schema bumps.transaction-discipline — ledger writes.tracing-spans — rule-by-rule timing.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.