메뉴
Review a pull request (or uncommitted diff) against vixen-rs conventions — server rules in server/docs/rules/ and website rules in website/docs/rules/. Use when the user asks to review a PR, review changes, or asks "what do you think of this diff".
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 | review-pr |
| description | Review a pull request (or uncommitted diff) against vixen-rs conventions — server rules in server/docs/rules/ and website rules in website/docs/rules/. Use when the user asks to review a PR, review changes, or asks "what do you think of this diff". |
Review focuses on correctness and convention adherence, not style nits (Biome and cargo fmt handle formatting).
master: git diff master...HEAD and git log master..HEAD --oneline.gh pr view <n> --json title,body,files + gh pr diff <n>.mcp__github__get_pull_request_files for a structured file list.Before commenting, skim the rules that apply to the changed files:
server/**.rs → server/CLAUDE.md, server/docs/rules/rust.md.server/migrations/**.sql → server/docs/rules/migrations.md.server/src/api/routes_*.rs → server/docs/rules/api-routes.md.server/src/telegram/** → server/docs/rules/telegram-handlers.md.server/src/jobs/** → server/docs/rules/background-jobs.md.server/src/** error types → server/docs/rules/error-handling.md.website/src/**/*.tsx → website/docs/rules/solidjs.md + components.md.website/src/**/*.ts → website/docs/rules/typescript.md.server/docs/{api,database}.md and a fresh .sqlx/.server/docs/api.md and decorated with #[utoipa::path(...)].server/docs/bot.md's slash-command table, and respect the watched-chats filter.CancellationToken, and have an info_span!("job", name=...) wrapper.useEffect, <Show>/<For>/<Switch> used.any, no TS enums, kebab-case filenames, named exports (except pages/)..down.sql, are idempotent where the rule requires it, use BIGINT for Telegram IDs.tracing::*!.*token, bot_token, TELEGRAM_BOT_TOKEN. Tokens go through RedactedToken.server/tests/spam_corpus/<rule>.yaml (positive + negative samples).server/assets/captcha/. Adding a new look = new file + bumped selector.Structure the review as:
file:line refs.Be direct. Call out bad ideas. Silence on a flaw is worse than bluntness.