القائمة
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 المهني
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 | 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.