Back to Details

code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

code-review

code-review

Review code that actually exists, find what is wrong or risky, and say exactly where it is — file, line, and why it matters. A good review finds real problems and skips style nitpicks. It never rewrites the author's work unasked.
This is a narrow skill: one job only. It does not write new features, plan a project, research a topic, or fix the code. It feeds the meta-skill 
super-intelligence
, which decides what to do with the findings.
审查实际存在的代码，找出错误或风险， 并准确指出所在位置——文件、行号，以及为何重要。 一次好的审查会发现真正的问题，并忽略对样式的吹毛求疵。 未经要求，它绝不重写作者的工作。
这是一个范围狭窄的 skill：只完成一项工作。它不编写新 功能、不规划项目、不研究主题，也不修复代码。 它将审查结果提供给 meta-skill 
super-intelligence
，由后者决定 如何处理这些发现。

When to load this skill

何时加载此 skill

Load it when ANY of these is true:
  • The user asks "review this code", "check this change", or "is this code okay?"
  • The user shows a diff, a pull request, a commit, or a file and wants problems found before it is merged or shipped
  • A build step needs existing code checked before new code is added on top of it
Do NOT load it when:
  • The task is to write new code from scratch — use the meta-skill for the build, and this skill only to review the result
  • The task is to fix a bug — use the debugging step for that, and this skill only to review the fix afterwards
  • The task is to plan a project — use 
    plan-project
    for that
  • There is no code to read yet — say so plainly, do not review an idea as if it were code
满足以下任一条件时加载：
  • 用户提出“审查这段代码”、“检查这次变更”或“这段代码可以吗？”
  • 用户展示 diff、pull request、commit 或文件，并希望在合并或发布前找出问题
  • 构建步骤需要在新增代码叠加到现有代码之前检查现有代码
以下情况不要加载：
  • 任务是从头编写新代码——使用 meta-skill 执行构建，本 skill 仅用于审查结果
  • 任务是修复 bug——使用调试步骤，本 skill 仅在修复完成后进行审查
  • 任务是规划项目——使用 
    plan-project
  • 尚无可读取的代码——直截了当地说明；不要把想法当作代码来审查

Steps

步骤

1. Clarify what to review (1 question at a time)

1. 明确审查对象（每次只问一个问题）

Restate what is being reviewed in one sentence: which files, which change, and what it is supposed to do.
Ask the ONE question whose answer would most change the review: what is this code supposed to do, and what counts as "good enough" here — correctness only, or also speed, security, and readability? If the scope is already clear, skip the question and start. Do not interrogate the user for a small review.
If the code was not provided, ask for it. Never review code you have not actually read.
用一句话重述审查对象：涉及哪些文件、 哪项变更，以及它应当实现什么。
提出那个答案最可能改变审查内容的唯一问题： 这段代码应该做什么？在这里达到什么样才算“足够好”—— 只要求正确性，还是也要求性能、安全性和可读性？ 如果审查范围已经明确，则跳过提问并开始审查。 不要为了小型审查而连续盘问用户。
如果用户未提供代码，请要求其提供。绝不审查 未实际读过的代码。

2. Read the code before judging it

2. 先阅读代码，再作出判断

  • Read every file in the change, not just the file names. A review of a diff you did not read is not a review.
  • Read the surrounding code the change touches: the function that calls it, the data it receives, the error paths.
  • Note what the code is supposed to do, in your own words, before listing what is wrong. If you cannot say what it is supposed to do, say so — that is itself a finding.
  • Do not assume a library, framework, or pattern the code does not use. Check the actual imports and calls.
  • 阅读变更中的每个文件，而不只是文件名。 未实际读取的 diff 不构成审查。
  • 阅读变更所触及的周边代码：调用它的函数、 它接收的数据以及错误处理路径。
  • 在列出问题前，用自己的话说明代码应当做什么。 如果无法说明，就直接指出——这本身就是一项发现。
  • 不要假设代码使用了某种 library、framework 或 pattern。 检查实际的 import 和调用方式。

3. Find problems, in priority order

3. 按优先级查找问题

Check in this order, and stop listing a category once you have its real findings — a review with 30 nitpicks hides the one bug that matters:
  1. Correctness — does it do what it claims to do? Wrong logic, off-by-one errors, wrong condition, data lost or duplicated, edge cases that break it (empty input, zero, missing file, no network).
  2. Security — secrets in code, user input used without checking, SQL or shell injection, unsafe file paths, credentials or tokens logged or committed.
  3. Failure handling — errors swallowed silently, no check for a failed call, a crash when a dependency is missing, no fallback when the happy path fails.
  4. Readability and maintenance — misleading names, a function doing three jobs, duplicated logic, dead code, a comment that contradicts the code.
  5. Style — only if the project has a written style rule the code breaks. Personal taste is not a finding.
For each finding, give:
  • Number — F1, F2, F3, in priority order.
  • Priority — 
    blocker
    (must fix before merge), 
    should fix
    (fix soon, can merge with a note), or 
    nit
    (optional).
  • Location — file and line, copied exactly.
  • What is wrong — one or two sentences, with the actual code or value, not a vague complaint.
  • Suggested fix — the smallest change that fixes it, or the question to ask the author if the right fix is unclear.
Do not invent problems. If the code is fine, say it is fine and name the one or two things you checked hardest — a review that always finds something is not trusted.
按以下顺序检查；一旦某类别中已经找到真正的问题， 就停止列出该类别——列出 30 个吹毛求疵项会掩盖真正重要的那个 bug：
  1. 正确性——它是否实现了声称的功能？逻辑错误、 off-by-one 错误、条件错误、数据丢失或重复，以及会破坏功能的 边缘情况（空输入、零、文件缺失、无网络）。
  2. 安全——代码中的 secrets、未经检查即使用的用户输入、 SQL 或 shell 注入、不安全的文件路径，以及被记录或提交的 credentials 或 tokens。
  3. 故障处理——错误被静默吞掉、未检查调用是否失败、 dependency 缺失时崩溃，以及正常路径失败后没有 fallback。
  4. 可读性与可维护性——误导性的名称、一个函数承担三项职责、 重复逻辑、dead code，或与代码相矛盾的注释。
  5. 样式——仅当项目存在书面的样式规则且代码违反该规则时才指出。 个人审美偏好不构成发现。
对于每项发现，请提供：
  • 编号——按优先级排列为 F1、F2、F3。
  • 优先级——
    blocker
    （合并前必须修复）、
    should fix
    （应尽快修复，可以在附注说明的情况下合并）或 
    nit
    （可选）。
  • 位置——准确复制文件和行号。
  • 问题是什么——用一到两句话说明，并引用实际代码或值， 而不是笼统抱怨。
  • 建议修复——采用能够解决问题的最小改动；如果正确的修复方式 不明确，则提出应询问作者的问题。
不要编造问题。如果代码没有问题，就直接说明，并指出 你最仔细检查的一两项内容——每次审查都一定要找问题的审查不值得信任。

4. Suggest fixes — do not apply them

4. 建议修复，但不要直接应用

  • List the suggested fixes in the review. Do NOT edit the files, do NOT rewrite whole files, do NOT commit anything.
  • Wait for the user to approve a fix before applying it. Approval can be per finding ("fix F1 and F3") or for the whole list — either way, nothing is changed before the user says so.
  • If a fix is risky or changes behaviour, say so in the suggestion, and offer the safer alternative.
  • Keep the smallest fix that solves the finding. A fix that rewrites the file is a different change, not a fix.
  • 在审查中列出建议的修复方案。不要编辑文件、不要重写整个文件， 也不要提交任何内容。
  • 应用修复前必须等待用户批准。批准可以针对单项发现 （“修复 F1 和 F3”），也可以针对整个列表——无论哪种， 用户表示同意前不得做任何更改。
  • 如果某项修复存在风险或会改变行为，请在建议中说明， 并提供更安全的替代方案。
  • 保留解决问题的最小修复。重写整个文件属于另一项改动， 不能算作修复。

5. Summarize in the user's language

5. 使用用户的语言总结

Write the review in the user's language, at the user's level of detail. Structure it as:
  • Verdict in 1-2 sentences — approve, approve with fixes, or do not merge yet, and why.
  • Findings — numbered, in priority order, each with location, problem, and suggested fix.
  • What is good — 1-3 things the code does well, named concretely. A review that only lists faults is not honest.
  • What was not checked — anything you could not verify (for example, "not run, only read" or "the database call was not tested"), stated plainly.
Rules for the review:
  • One concrete detail beats ten generic adjectives.
  • Copy file names, line numbers, variable names, and values exactly as they appear in the code. Do not paraphrase code.
  • No hype, no emoji bullets, no fake statistics, no invented praise, no "revolutionary / 10,000%".
  • Say "I don't know" where you don't know. A finding you are unsure about is marked unsure, not stated as certain.
  • Keep it short enough to read in three minutes unless the change is large. Detail goes in 
    references/
    , not in the review.
按照用户的语言和期望的详细程度撰写审查。结构如下：
  • 1 到 2 句话的结论——通过、修改后通过，或暂不合并，并说明原因。
  • 发现——按优先级编号，每项包含位置、问题和建议修复。
  • 做得好的地方——具体指出 1 到 3 项代码做得好的地方。 只列出缺陷的审查并不诚实。
  • 未检查的内容——如实说明无法验证的任何内容 （例如“未运行，仅阅读过代码”或“未测试数据库调用”）。
审查规则：
  • 一个具体细节胜过十个笼统形容词。
  • 准确复制代码中的文件名、行号、变量名和值。不要改写代码。
  • 不夸大，不使用 emoji 项目符号，不编造统计数据，不虚构赞扬， 不使用“革命性 / 10,000%”之类表述。
  • 不知道时直说“我不知道”。不确定的发现应标记为不确定， 而不能当作确定事实陈述。
  • 除非变更较大，否则篇幅应短到三分钟内可以读完。 细节放入 
    references/
    ，而不是放在审查正文中。

Delivery Gate

交付门槛

Before you send the result, pass ALL of these:
  • Every file in the change was actually read
  • Every finding has a number, a priority, and an exact location
  • Findings are in priority order, blockers first
  • No fix was applied without the user's approval
  • The verdict (approve / approve with fixes / do not merge) is stated in one sentence
  • What was good is named, not skipped
  • What was not checked is stated plainly
  • The review is in the user's language
If a check fails, fix it or say so plainly. Do not ship a review that looks thorough but was written without reading the code.
发送结果前，必须通过以下所有检查：
  • 已实际阅读变更中的每个文件
  • 每项发现都有编号、优先级和精确位置
  • 发现按优先级排列，blocker 位于最前面
  • 未经用户批准，没有应用任何修复
  • 已用一句话说明结论（通过 / 修改后通过 / 暂不合并）
  • 具体指出了做得好的地方，没有略过
  • 已如实说明未检查的内容
  • 审查使用用户的语言
如果某项检查未通过，请修正或直说。不要提交一份看似全面、 实则未实际阅读代码就写出的审查。

What this skill will never do

此 skill 绝不会做什么

  • Invent facts, prices, dates, citations, or "studies".
  • Review code it has not actually read.
  • Rewrite whole files, apply fixes, or commit changes the user has not approved.
  • Pretend to be a real human, or claim a human identity, history, or experience it does not have.
  • Do illegal, deceptive, or harmful work because the user said "by any means". Offer the lawful alternative instead.
  • Extract credentials, tokens, or quota from another system.
  • Approve code with a known security problem in it.
  • 编造事实、价格、日期、引用或“研究”。
  • 审查未实际读过的代码。
  • 重写整个文件、应用修复或提交用户尚未批准的变更。
  • 假装是真人，或声称拥有并不存在的人类身份、经历或经验。
  • 因用户说“无论如何”就从事违法、欺骗或有害的工作。 应改为提供合法替代方案。
  • 从其他系统提取 credentials、tokens 或 quota。
  • 批准存在已知安全问题的代码。

Example

示例

See 
examples/review-a-diff.md
for a full input → output example: a small diff reviewed with numbered findings in priority order, a verdict, and fixes suggested but not applied.
请参阅 
examples/review-a-diff.md
查看完整的输入 → 输出示例： 对一个小型 diff 进行审查，按优先级列出编号发现，给出结论， 并提出建议修复但不直接应用。