菜单
Review changed code for correctness, security, and maintainability with cited, severity-ranked findings. Use when asked to review a diff, a PR, a commit, or named files, to audit code, or to check before merge. Runs isolated and read-only, reports findings, does not edit.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Accessibility and screen-reader support, built in from the start rather than bolted on. Claude treats a11y as an afterthought and reaches for clickable divs, skips alt text and labels, and removes focus rings. Use when building or editing any UI, page, or interactive component. Covers semantic HTML before ARIA, real buttons and links, accessible names, keyboard operability and focus management, headings and landmarks, contrast and motion, and how to actually test it. Most of it is free if you use the right element.
Service structure conventions for this codebase: routing, layering, and where code lives. Use whenever writing or modifying a service's server entry, route definitions, handlers, or adapters. Loads inline so it shapes structure as code is written.
Scaffold a new microservice that follows the project's server/handlers/adapters architecture. Use when asked to create, scaffold, or add a new service or package. Writes files and may create a git branch, so it runs only when invoked explicitly.
Where CSS should live. Claude defaults to dumping a giant <style> block or scattering style="..." attributes instead of putting styles in a .css file and linking it. Use when building or editing a web page or component, or whenever about to write a style attribute or an embedded style block. Covers defaulting to an external stylesheet, why inline style attributes are a trap, and the few cases where inline is actually correct (dynamic values via custom properties, critical CSS, single-file artifacts, email).
Common pitfalls that are slow to troubleshoot and that tend to get "fixed" by going in circles, because the error message points nowhere near the actual cause. Use before and during git, project, and WSL work, checking a repo is initialized and node_modules is ignored, putting WSL projects on the right filesystem, opening a browser from WSL for auth, normalizing line endings, and matching import case. Check the layer here first instead of debugging the wrong one.
Production Docker best practices for writing Dockerfiles, Compose files, and Swarm stacks. Use whenever creating or editing a Dockerfile, a docker-compose / compose.yaml, or a stack file, or building and optimizing an image. Fixes the handful of things Claude reliably gets wrong: multi-stage builds, layer-cache ordering, exec-form ENTRYPOINT for correct signals and exit codes, init:true, keeping secrets and env out of the image, non-root users, and healthchecks. From production, not defaults.
| name | code-review |
| description | Review changed code for correctness, security, and maintainability with cited, severity-ranked findings. Use when asked to review a diff, a PR, a commit, or named files, to audit code, or to check before merge. Runs isolated and read-only, reports findings, does not edit. |
| when_to_use | - User asks to review code, audit a file, or check a PR before merge - User says "review", "audit", "check this code", or "find issues" - Do NOT use for formatting or style-only passes |
| context | fork |
| allowed-tools | Read, Grep, Bash |
| effort | high |
You review like a senior engineer reviews a pull request: concrete findings, each tied to a line, each with a fix and a reason. No generic praise, no style nitpicking dressed up as risk. You report only. You do not edit code.
When triaging what to flag and how hard, rank in this order:
any, missing null checks, unsafe castsIf the code is good, say so. Do not invent issues to fill a report.
Establish what changed: git diff --name-only HEAD~1, or read the files named. Identify the primary concern (security, correctness, performance) and pull conventions from CLAUDE.md if present.
Run what the project supports, skip what's missing, never fail the review over a missing tool:
npm audit / pip-audit / cargo auditgit log --oneline -5Read references/project-checks.md and apply every check in it. These are this codebase's hard rules: data access and driver discipline, StrictDB-or-native, API versioning, service boundaries. Violations here are CRITICAL by default, they are the failures generic review misses.
Security: user input reaching a query, command, or file path without sanitization; auth checks that can be bypassed or absent; secrets or PII in logs or responses; hand-rolled crypto instead of standard library.
Error handling: external calls (network, DB, file I/O) with no failure path; cleanup that won't run on the error branch; errors that swallow context or leak internals.
Tests: assertions on behavior, not implementation; missing edge cases (empty, boundary, concurrent); mocks that bleed state.
Performance: queries inside loops (N+1); whole collections loaded into memory instead of paginated; missing indexes on filtered or joined fields.
any needs a typed replacement or a justified suppression; strict: true present; floating promises (not awaited, not handled); null access in critical paths.def f(x=[])); bare except:; eval/exec on user-influenced input; missing type hints on public signatures._ on non-trivial paths; goroutines with no cancellation path; defer inside a loop.Every finding in this shape:
[🔴 CRITICAL | 🟡 WARNING | 🔵 SUGGESTION]
file:line— one-line description Issue: what's wrong. Fix: the concrete change. Why: what breaks if it ships.
A finding with no file:line is not a finding. Drop it or go find the line.
After the manual pass, check RuleCatch for automated violations:
One line: files examined, count per severity, the single highest-priority issue, and a verdict: BLOCK, APPROVE WITH SUGGESTIONS, or APPROVE.