Run any Skill in Manus with one click

review-pr

Stars3

Forks1

UpdatedMay 1, 2026 at 22:05

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".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

PlugFox

PlugFox/vixen-rs

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

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".

PR Review (Vixen)

Scope

Review focuses on correctness and convention adherence, not style nits (Biome and cargo fmt handle formatting).

Gather the diff

Current branch vs master: git diff master...HEAD and git log master..HEAD --oneline.
Specific PR: gh pr view <n> --json title,body,files + gh pr diff <n>.
MCP GitHub: mcp__github__get_pull_request_files for a structured file list.

Read the rules first

Before commenting, skim the rules that apply to the changed files:

Any 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.
Any UI text → verify i18n keys exist in website/i18n/messages/ for every locale.

Checklist

Title & commits follow Conventional Commits.
Schema changes come with a matching update in server/docs/{api,database}.md and a fresh .sqlx/.
New API routes are listed in server/docs/api.md and decorated with #[utoipa::path(...)].
New Telegram handlers are registered in the dispatcher, documented in server/docs/bot.md's slash-command table, and respect the watched-chats filter.
New background jobs are idempotent, respect CancellationToken, and have an info_span!("job", name=...) wrapper.
SolidJS: no prop destructuring, no useEffect, <Show>/<For>/<Switch> used.
TypeScript: no any, no TS enums, kebab-case filenames, named exports (except pages/).
No hardcoded user-facing text — all strings come from i18n; every locale has the new key.
Migrations: have a .down.sql, are idempotent where the rule requires it, use BIGINT for Telegram IDs.

Vixen-specific extras (must check)

No bot token in any added log statement. Search the diff for tracing::*!.*token, bot_token, TELEGRAM_BOT_TOKEN. Tokens go through RedactedToken.
No raw initData logged at info+. initData carries user PII; only debug-level logs may include it.
No raw user PII in logs. Phone numbers, full names, message bodies — opt-in only.
New spam rule has corpus tests under server/tests/spam_corpus/<rule>.yaml (positive + negative samples).
Captcha asset paths never overwrite an existing file in server/assets/captcha/. Adding a new look = new file + bumped selector.
Per-chat config writes are wrapped in a transaction.

Output format

Structure the review as:

Summary (1–2 sentences): what the PR does and overall verdict.
Must fix: blocking issues with file:line refs.
Should fix: non-blocking improvements.
Nits: optional style/polish.

Be direct. Call out bad ideas. Silence on a flaw is worse than bluntness.

More from this repository

same repository

bump-version

PlugFox/vixen-rs

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.

2026-05-013

change-impact-assessment

PlugFox/vixen-rs

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.

2026-05-013

code-review-self

PlugFox/vixen-rs

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".

2026-05-013

commit-message

PlugFox/vixen-rs

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.

2026-05-013

debug-systematically

PlugFox/vixen-rs

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".

2026-05-013

docker-multi-stage

PlugFox/vixen-rs

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.

2026-05-013

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".

PR Review (Vixen)

Scope

Review focuses on correctness and convention adherence, not style nits (Biome and cargo fmt handle formatting).

Gather the diff

Current branch vs master: git diff master...HEAD and git log master..HEAD --oneline.
Specific PR: gh pr view <n> --json title,body,files + gh pr diff <n>.
MCP GitHub: mcp__github__get_pull_request_files for a structured file list.

Read the rules first

Before commenting, skim the rules that apply to the changed files:

Any 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.
Any UI text → verify i18n keys exist in website/i18n/messages/ for every locale.

Checklist

Title & commits follow Conventional Commits.
Schema changes come with a matching update in server/docs/{api,database}.md and a fresh .sqlx/.
New API routes are listed in server/docs/api.md and decorated with #[utoipa::path(...)].
New Telegram handlers are registered in the dispatcher, documented in server/docs/bot.md's slash-command table, and respect the watched-chats filter.
New background jobs are idempotent, respect CancellationToken, and have an info_span!("job", name=...) wrapper.
SolidJS: no prop destructuring, no useEffect, <Show>/<For>/<Switch> used.
TypeScript: no any, no TS enums, kebab-case filenames, named exports (except pages/).
No hardcoded user-facing text — all strings come from i18n; every locale has the new key.
Migrations: have a .down.sql, are idempotent where the rule requires it, use BIGINT for Telegram IDs.

Vixen-specific extras (must check)

No bot token in any added log statement. Search the diff for tracing::*!.*token, bot_token, TELEGRAM_BOT_TOKEN. Tokens go through RedactedToken.
No raw initData logged at info+. initData carries user PII; only debug-level logs may include it.
No raw user PII in logs. Phone numbers, full names, message bodies — opt-in only.
New spam rule has corpus tests under server/tests/spam_corpus/<rule>.yaml (positive + negative samples).
Captcha asset paths never overwrite an existing file in server/assets/captcha/. Adding a new look = new file + bumped selector.
Per-chat config writes are wrapped in a transaction.

Output format

Structure the review as:

Summary (1–2 sentences): what the PR does and overall verdict.
Must fix: blocking issues with file:line refs.
Should fix: non-blocking improvements.
Nits: optional style/polish.

Be direct. Call out bad ideas. Silence on a flaw is worse than bluntness.