Back to Details

code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review Skill

代码审查技能

Overview

概述

Structured code review from git diffs. Analyzes changes for correctness, security, complexity, maintainability, and language-specific best practices, then presents findings either inline or as a persistent report.
Core principle: Diff in → severity-tagged findings out, scoped strictly to what changed.
Announce at start: "I'm using the code-review skill to review the requested changes."
基于git diff的结构化代码审查。分析变更的正确性、安全性、复杂度、可维护性以及语言特定最佳实践，然后以内联形式或持久化报告呈现结果。
核心原则： 输入diff → 输出带严重程度标签的审查结果，严格限定在变更范围内。
启动提示： "我将使用代码审查技能来审查您请求的变更。"

Commands

命令

CommandSkillOutputWhen to use
/code-review
(or implicit trigger)
code-review
Findings shown in conversation; no fileQuick interactive review
/code-review-md
code-review-md
Markdown file at 
.reviews/<date>_<sha>.md
Persistent record, share via git
/code-review-html
code-review-html
Markdown file + self-contained HTMLBrowser-readable report with badges, syntax highlighting, sidebar nav
命令技能输出使用场景
/code-review
（或隐式触发）
code-review
审查结果显示在对话中；不生成文件快速交互式审查
/code-review-md
code-review-md
Markdown文件存储于 
.reviews/<date>_<sha>.md
持久化记录，可通过git共享
/code-review-html
code-review-html
Markdown文件 + 独立HTML文件带徽章、语法高亮、侧边导航的浏览器可读报告

Command Examples

命令示例

/code-review
— interactive

/code-review
— 交互式审查

User: review my changes
→ git diff && git diff --staged
→ Analyze
→ Print findings in conversation; write nothing
User: 마지막 커밋 코드 리뷰해줘
→ git diff HEAD~1..HEAD
→ Analyze; output narrative in Korean (section headings translated)
→ Print findings in conversation
用户：review my changes
→ 执行 git diff && git diff --staged
→ 分析变更
→ 在对话中打印审查结果；不写入任何文件
用户：마지막 커밋 코드 리뷰해줘
→ 执行 git diff HEAD~1..HEAD
→ 分析；以韩语输出审查内容（章节标题翻译为韩语）
→ 在对话中打印审查结果

/code-review-md
— markdown report

/code-review-md
— Markdown报告

User: /code-review-md review staged changes
→ git diff --staged
→ Analyze
→ mkdir -p .reviews/
→ Write .reviews/2026-05-03_staged.md
→ Print 1-3 top findings + path to report
→ Suggest adding `.reviews/` to .gitignore (do NOT modify it)
用户：/code-review-md review staged changes
→ 执行 git diff --staged
→ 分析变更
→ 执行 mkdir -p .reviews/
→ 写入文件 .reviews/2026-05-03_staged.md
→ 打印1-3项核心审查结果 + 报告路径
→ 建议将 `.reviews/` 添加到 .gitignore（请勿自动修改）

/code-review-html
— HTML + markdown

/code-review-html
— HTML + Markdown报告

User: /code-review-html review PR #42
→ gh pr diff 42
→ diff_stats.py reports has_security_sensitive_files: true
→ Load python.md + common-vulnerabilities.md
→ Analyze; find SQL injection (CRITICAL)
→ Write .reviews/2026-05-03_a1b2c3d.md
→ python <skill-path>/scripts/generate_html_report.py .reviews/2026-05-03_a1b2c3d.md
→ open .reviews/2026-05-03_a1b2c3d.html
→ Print summary in conversation
用户：/code-review-html review PR #42
→ 执行 gh pr diff 42
→ diff_stats.py 报告 has_security_sensitive_files: true
→ 加载 python.md + common-vulnerabilities.md
→ 分析；发现SQL注入（CRITICAL）
→ 写入文件 .reviews/2026-05-03_a1b2c3d.md
→ 执行 python <skill-path>/scripts/generate_html_report.py .reviews/2026-05-03_a1b2c3d.md
→ 执行 open .reviews/2026-05-03_a1b2c3d.html
→ 在对话中打印审查摘要

Determining Review Scope

确定审查范围

Parse the user's request to figure out what code to review, then run the matching git command:
User intentGit command
"review my changes" / no specific scope
git diff
(unstaged) + 
git diff --staged
(staged)
"review staged changes"
git diff --staged
"review last commit"
git diff HEAD~1..HEAD
"review commit 
<sha>
"
git diff <sha>~1..<sha>
"review last N commits"
git diff HEAD~N..HEAD
"review branch X" / "compare to main"
git diff main...<branch>
(three-dot merge-base)
"review PR #N"
gh pr diff N
If the user's intent is ambiguous, default to reviewing staged + unstaged changes. If there are no changes at all, tell the user and suggest possible causes (forgot to stage? wrong branch?).
Get the short SHA for the report filename:
  • For a specific commit: use that commit's short SHA
  • For a range: use the latest commit's short SHA
  • For staged/unstaged changes with no commit: use 
    staged
    or 
    working
解析用户请求以明确审查对象，然后执行匹配的git命令：
用户意图Git命令
"review my changes" / 无特定范围
git diff
（未暂存） + 
git diff --staged
（已暂存）
"review staged changes"
git diff --staged
"review last commit"
git diff HEAD~1..HEAD
"review commit 
<sha>
"
git diff <sha>~1..<sha>
"review last N commits"
git diff HEAD~N..HEAD
"review branch X" / "compare to main"
git diff main...<branch>
（三点合并基准）
"review PR #N"
gh pr diff N
如果用户意图不明确，默认审查已暂存+未暂存的变更。如果没有任何变更，请告知用户并建议可能的原因（忘记暂存？分支错误？）。
为报告文件名获取短SHA：
  • 特定提交：使用该提交的短SHA
  • 提交范围：使用最新提交的短SHA
  • 无提交的暂存/未暂存变更：使用 
    staged
    或 
    working

Review Process

审查流程

Follow these steps in order:
按以下顺序执行步骤：

1. Gather context

1. 收集上下文

Run the appropriate git diff command. Then run the diff stats helper to get a machine-readable summary:
bash
git diff [range] --numstat | python <skill-path>/scripts/diff_stats.py
This outputs JSON with files changed, languages detected, and whether security-sensitive files were touched.
执行合适的git diff命令。然后运行diff统计助手获取机器可读的摘要：
bash
git diff [range] --numstat | python <skill-path>/scripts/diff_stats.py
该命令输出包含变更文件、检测到的语言以及是否涉及敏感安全文件的JSON数据。

2. Load references

2. 加载参考文件

Based on the languages detected by 
diff_stats.py
, read the relevant reference files. Only load what's needed — never read all of them at once:
  • .py
    files → read 
    references/python.md
  • .js
    , 
    .ts
    , 
    .jsx
    , 
    .tsx
    files → read 
    references/javascript-typescript.md
  • .go
    files → read 
    references/go.md
    (if it exists)
  • .rs
    files → read 
    references/rust.md
    (if it exists)
  • .java
    , 
    .kt
    files → read 
    references/java.md
    (if it exists)
Always read 
references/review-criteria.md
for the review framework and severity definitions.
If 
diff_stats.py
reports 
has_security_sensitive_files: true
, also read 
references/common-vulnerabilities.md
.
根据
diff_stats.py
检测到的语言，读取相关参考文件。仅加载所需文件——切勿一次性读取所有文件：
  • .py
    文件 → 读取 
    references/python.md
  • .js
    , 
    .ts
    , 
    .jsx
    , 
    .tsx
    文件 → 读取 
    references/javascript-typescript.md
  • .go
    文件 → 读取 
    references/go.md
    （如果存在）
  • .rs
    文件 → 读取 
    references/rust.md
    （如果存在）
  • .java
    , 
    .kt
    文件 → 读取 
    references/java.md
    （如果存在）
始终读取 
references/review-criteria.md
获取审查框架和严重程度定义。
如果
diff_stats.py
报告
has_security_sensitive_files: true
，还需读取
references/common-vulnerabilities.md
。

3. Analyze the diff

3. 分析diff

Read each changed file's diff and analyze against five dimensions:
  1. Correctness — Does the code do what the author intended? Logic errors, edge cases, type mismatches, error handling gaps.
  2. Security — Injection risks, auth gaps, sensitive data exposure, insecure crypto, input validation.
  3. Complexity & Consistency — Does this increase cognitive load? Does it break existing patterns or naming conventions?
  4. Maintainability — Will future developers understand this? Tight coupling, missing docs for public APIs, magic values, testability.
  5. Best Practices — Language/framework-specific idioms and anti-patterns (guided by the loaded reference files).
For each finding, assign a severity:
SeverityMeaningAction required
CRITICALData loss, security breach, or crash in productionMust fix before merge
HIGHBug, vulnerability, or serious design flawShould fix before merge
MEDIUMCode smell, inconsistency, moderate riskRecommended fix
LOWStyle, naming, minor improvementNice to have
INFOPositive observation or contextual noteNo action needed
Every finding must reference a specific file and line range. Show the problematic code and a suggested fix. If uncertain about something, use INFO severity and frame it as a question rather than asserting a problem that may not exist.
读取每个变更文件的diff，并从五个维度进行分析：
  1. 正确性 — 代码是否实现了作者的意图？逻辑错误、边缘情况、类型不匹配、错误处理缺失。
  2. 安全性 — 注入风险、认证漏洞、敏感数据暴露、不安全加密、输入验证。
  3. 复杂度与一致性 — 是否增加认知负担？是否破坏现有模式或命名规范？
  4. 可维护性 — 未来开发者能否理解？紧耦合、公共API缺少文档、魔法值、可测试性。
  5. 最佳实践 — 语言/框架特定的惯用写法与反模式（由加载的参考文件指导）。
为每个审查结果分配严重程度：
严重程度含义所需操作
CRITICAL生产环境中可能导致数据丢失、安全漏洞或崩溃合并前必须修复
HIGH存在bug、漏洞或严重设计缺陷合并前应修复
MEDIUM代码异味、不一致性、中等风险建议修复
LOW样式、命名、微小改进可选修复
INFO正面观察或上下文说明无需操作
每个审查结果必须引用特定文件和行范围。展示问题代码并给出建议修复方案。如果对某些内容不确定，使用INFO严重程度并以问题形式表述，而非断言可能不存在的问题。

4. Present findings or write the markdown report

4. 呈现审查结果或编写Markdown报告

Default (bare 
/code-review
or implicit trigger): Present the review using the template format below directly in the conversation. Do NOT write any files.
When invoked via the 
code-review-md
or 
code-review-html
skill (
/code-review-md
/ 
/code-review-html
): Create the 
.reviews/
directory in the repository root if it doesn't exist. Write the report file following this exact template:
markdown
undefined
默认情况（仅
/code-review
或隐式触发）： 直接在对话中使用以下模板格式呈现审查结果。请勿写入任何文件。
当通过
code-review-md
或
code-review-html
技能调用时（
/code-review-md
/ 
/code-review-html
）： 如果仓库根目录不存在
.reviews/
目录则创建该目录。按照以下精确模板编写报告文件：
markdown
undefined

Code Review Report

代码审查报告

Date: YYYY-MM-DD Reviewer: Claude (automated) Scope: [e.g., "Staged changes", "Commits a1b2c3d..f4e5d6a on branch feature-auth"] Repository: [repo name]
日期： YYYY-MM-DD 审查者： Claude（自动化） 范围： [例如："已暂存变更", "分支feature-auth上的提交a1b2c3d..f4e5d6a"] 仓库： [仓库名称]

Executive Summary

执行摘要

MetricValue
Files changedN
Lines added+N
Lines removed-N
LanguagesPython, TypeScript
FindingsN critical, N high, N medium, N low
Overall riskLOW / MEDIUM / HIGH / CRITICAL
[2-3 sentence summary of the overall quality and the most important observations.]
指标数值
变更文件数N
添加行数+N
删除行数-N
涉及语言Python, TypeScript
审查结果数N个CRITICAL, N个HIGH, N个MEDIUM, N个LOW
整体风险LOW / MEDIUM / HIGH / CRITICAL
[2-3句话总结整体代码质量和最重要的观察结果。]

Findings

审查结果

CRITICAL

CRITICAL

[CR-001] Short title describing the finding

[CR-001] 描述审查结果的简短标题

File: 
path/to/file.py
(lines 42-58) Category: Security | Correctness | Complexity | Maintainability | Best Practice
[Description of the issue, why it matters, and what the risk is.]
Current code: ```python
文件： 
path/to/file.py
（第42-58行） 分类： 安全 | 正确性 | 复杂度 | 可维护性 | 最佳实践
[问题描述、影响以及风险说明。]
当前代码： ```python

the problematic code

存在问题的代码

```
Suggested fix: ```python
```
建议修复： ```python

the recommended approach

推荐方案

```
[Continue with HIGH, MEDIUM, LOW sections using the same structure. Omit any severity section that has zero findings.]
```
[继续使用相同结构展示HIGH、MEDIUM、LOW级别的结果。 省略没有结果的严重程度章节。]

Positive Observations

正面观察

  • [Things the code does well — good patterns, clean abstractions, thorough testing, etc.]
  • [代码的优点——良好模式、清晰抽象、全面测试等。]

File-by-File Summary

文件逐份总结

FileStatusFindingsRisk
src/auth.py
ModifiedCR-001 (CRITICAL), CR-003 (MEDIUM)HIGH
tests/test_auth.py
ModifiedNoneLOW
Generated by code-review skill · YYYY-MM-DD HH:MM UTC

Save to: `.reviews/<YYYY-MM-DD>_<short-sha>.md`
文件状态审查结果风险
src/auth.py
修改CR-001（CRITICAL）, CR-003（MEDIUM）HIGH
tests/test_auth.py
修改无LOW
由代码审查技能生成 · YYYY-MM-DD HH:MM UTC

保存至：`.reviews/<YYYY-MM-DD>_<short-sha>.md`

5. Generate HTML (
/code-review-html
only)

5. 生成HTML报告（仅
/code-review-html
）

Only when invoked via the 
code-review-html
skill / 
/code-review-html
. Run:
bash
python <skill-path>/scripts/generate_html_report.py .reviews/<report>.md
This produces a self-contained 
.html
file next to the markdown, with severity badges, collapsible sections, and a sidebar navigation. Then open it:
bash
open .reviews/<report>.html
仅当通过
code-review-html
技能/
/code-review-html
调用时执行：
bash
python <skill-path>/scripts/generate_html_report.py .reviews/<report>.md
此命令会在Markdown文件旁生成一个独立的
.html
文件，包含严重程度徽章、可折叠章节和侧边导航。然后打开该文件：
bash
open .reviews/<report>.html

6. Present summary

6. 呈现摘要

After completing the review, show the user a brief conversation summary:
  • Total findings by severity
  • Overall risk assessment
  • Path to the report file(s) (if files were generated)
  • The top 1-3 most important findings inline (so they get the critical stuff without opening the file)
完成审查后，向用户展示简短的对话摘要：
  • 各严重级别的结果总数
  • 整体风险评估
  • 报告文件路径（如果生成了文件）
  • 1-3项最重要的内联审查结果（让用户无需打开文件即可了解关键问题）

Report Language

报告语言

Write the report in the same language as the user's prompt. If the user writes in Korean, the report should be in Korean. If in English, write in English. Default to English when the language is ambiguous.
What to translate:
  • Section headings (e.g., "Executive Summary" → "요약", "Findings" → "발견 사항")
  • Finding descriptions, summaries, and the overall narrative
  • Table headers and metadata labels
What stays in English always:
  • Finding IDs: 
    CR-001
    , 
    CR-002
    , etc.
  • Severity labels: 
    CRITICAL
    , 
    HIGH
    , 
    MEDIUM
    , 
    LOW
    , 
    INFO
  • Code snippets (code is code)
  • File paths and technical identifiers
Add a 
**Language:**
field in the report metadata header so the HTML generator can set the correct 
lang
attribute:
markdown
**Language:** ko
Use the BCP 47 language tag: 
en
, 
ko
, 
ja
, 
zh
, etc.
报告使用与用户提示相同的语言。如果用户使用韩语，报告应为韩语；如果使用英语，报告应为英语。语言不明确时默认使用英语。
需要翻译的内容：
  • 章节标题（例如："Executive Summary" → "요약", "Findings" → "발견 사항"）
  • 审查结果描述、摘要和整体叙述
  • 表格表头和元数据标签
始终保留英文的内容：
  • 结果ID：
    CR-001
    , 
    CR-002
    等
  • 严重程度标签：
    CRITICAL
    , 
    HIGH
    , 
    MEDIUM
    , 
    LOW
    , 
    INFO
  • 代码片段（代码保持原样）
  • 文件路径和技术标识符
在报告元数据头部添加
**Language:**
字段，以便HTML生成器设置正确的
lang
属性：
markdown
**Language:** ko
使用BCP 47语言标签：
en
, 
ko
, 
ja
, 
zh
等。

Quick Reference

快速参考

Filename convention:
  • Commit-based: 
    .reviews/2026-04-08_a1b2c3d.md
  • Staged: 
    .reviews/2026-04-08_staged.md
  • Working tree: 
    .reviews/2026-04-08_working.md
Report language: Match the user's prompt language. Translate section headings + narrative; keep finding IDs (
CR-001
), severity labels, code, and file paths in English. Add 
**Language:** <bcp47>
field so the HTML generator sets 
lang
correctly.
Large diffs (>1000 lines): Focus on CRITICAL/HIGH. Group similar MEDIUM/LOW findings by pattern ("12 instances of unused imports") rather than listing each one separately.
文件名约定：
  • 基于提交：
    .reviews/2026-04-08_a1b2c3d.md
  • 已暂存变更：
    .reviews/2026-04-08_staged.md
  • 工作区变更：
    .reviews/2026-04-08_working.md
报告语言： 匹配用户提示语言。翻译章节标题和叙述内容；结果ID（
CR-001
）、严重程度标签、代码和文件路径保留英文。添加
**Language:** <bcp47>
字段，以便HTML生成器正确设置
lang
属性。
大型diff（>1000行）： 重点关注CRITICAL/HIGH级别的结果。将相似的MEDIUM/LOW级别结果按模式分组（"12处未使用导入"），而非逐个列出。

Common Mistakes

常见错误

Generic findings without location
  • Problem: "Consider adding error handling" with no file/line
  • Fix: Every finding cites file + line range, shows current code, suggests fix
Reviewing unchanged code
  • Problem: Comment on code outside the diff
  • Fix: Scope is the diff. Don't expand to the whole repo.
Manufactured findings on trivial diffs
  • Problem: Inventing issues for whitespace/version-bump-only diffs
  • Fix: Call it trivial in 2-3 lines. Don't pad.
Loading every reference file
  • Problem: Reading 
    python.md
    when the diff is JS-only
  • Fix: Only load references for languages reported by 
    diff_stats.py
False positives stated as facts
  • Problem: "This is a bug" when you cannot verify
  • Fix: Use INFO + a question: "This might cause X under Y conditions — worth verifying?"
Missing positive observations
  • Problem: Only listing issues; reviewers tune out
  • Fix: Always include the Positive Observations section, even on small diffs
无位置信息的通用结果
  • 问题： "考虑添加错误处理"但未指定文件/行
  • 修复： 每个结果都必须引用文件+行范围，展示当前代码并给出修复建议
审查未变更代码
  • 问题： 对diff之外的代码发表评论
  • 修复： 审查范围仅限diff，不要扩展到整个仓库
对微小diff生成无意义结果
  • 问题： 对仅包含空格/版本号变更的diff编造问题
  • 修复： 用2-3句话说明这是微小变更，不要凑内容
加载所有参考文件
  • 问题： 当diff仅涉及JS时读取
    python.md
  • 修复： 仅加载
    diff_stats.py
    报告的语言对应的参考文件
将误报表述为事实
  • 问题： "这是一个bug"但无法验证
  • 修复： 使用INFO级别+问题形式："在Y条件下这可能导致X——值得验证吗？"
缺少正面观察
  • 问题： 仅列出问题；审查者会忽略
  • 修复： 始终包含正面观察章节，即使是小diff

Red Flags

注意事项

Never:
  • Write files for bare 
    /code-review
    (conversation only)
  • Modify 
    .gitignore
    automatically (suggest, don't apply)
  • Comment on code outside the diff
  • Skip the Positive Observations section
  • Manufacture findings to fill space
Always:
  • Cite file + line range in every finding
  • Show before/after code
  • Default to INFO severity when uncertain
  • Match the user's prompt language for narrative
  • Suggest adding 
    .reviews/
    to 
    .gitignore
    if absent
禁止操作：
  • 仅使用
    /code-review
    时写入文件（仅在对话中展示）
  • 自动修改
    .gitignore
    （仅建议，不执行）
  • 对diff之外的代码发表评论
  • 跳过正面观察章节
  • 编造结果填充内容
必须操作：
  • 每个结果都引用文件+行范围
  • 展示前后代码
  • 不确定时默认使用INFO严重程度
  • 报告叙述匹配用户提示语言
  • 如果
    .reviews/
    不在.gitignore中，建议添加

Integration

集成

Pairs with:
  • conventional-commit — Review before committing for a final quality gate
  • Triggers via plugin commands; runs against any 
    git diff
    output, so works on any repo with git history
搭配使用：
  • conventional-commit — 提交前进行审查，作为最终质量关卡
  • 通过插件命令触发；可针对任何
    git diff
    输出运行，因此适用于任何有git历史的仓库