reviewkit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

reviewkit

Review code an AI agent just wrote, for the failure modes that are specific to AI-generated changes. A generic "find bugs" pass misses the three things agents get wrong most: writing code that is correct in a vacuum but wrong for this repo, padding a change with plausible-looking cruft nobody asked for, and quietly leaving part of the job undone. reviewkit runs those checks first, then a correctness pass, and reports findings ranked by severity. It does not fix anything. Fixing is the human's call, or a handoff to an implement-style skill.

This is a reviewer, not an editor. It reads the change and judges it; it never edits source. Its one optional artifact is a review report the user can save to feed a PR description.

专门针对AI Agent刚编写的代码进行评审，聚焦AI生成变更特有的失效模式。通用的“查找bug”评审会忽略Agent最常犯的三类错误：编写在孤立环境中正确但不符合当前仓库要求的代码、添加看似合理但无人要求的冗余内容、悄悄遗漏部分任务。reviewkit会先运行这三类检查，再进行正确性检查，并按严重程度排序报告发现的问题。它不会修复任何问题，修复工作由人工决定，或转交给实现类技能处理。

这是一个评审工具，而非编辑工具。它仅读取变更并作出判断，绝不会编辑源代码。它唯一的可选产出是一份评审报告，用户可保存后用于PR描述。

Review with fresh eyes

以全新视角评审

The reviewer should not be the agent that wrote the change. reviewkit usually fires in the same session that just produced the code, which means the reviewer arrives carrying every rationalization it made while writing: the shortcut it already justified, the edge case it already decided didn't matter. That is the single biggest way this review turns into a rubber stamp.

So when you have a subagent tool, delegate the passes to a fresh subagent: hand it the diff, the stated intent, and the passes below, and let it report back with no memory of the implementation session. Review its findings, then present them. When no subagent tool is available, run the passes yourself but say plainly in the report that this was a self-review, because the user needs to know how much weight the verdict carries. Never quietly self-review a change you just wrote.

The one thing that survives either mode: judge the code that is actually on disk, not the code you remember intending to write.

评审者不应是编写该变更的Agent。reviewkit通常在刚生成代码的同一会话中启动，这意味着评审者会带着编写代码时的所有合理化解释：已经找借口的捷径、已经判定不重要的边缘案例。这是导致评审沦为走过场的最大原因。

因此，如果你拥有子Agent工具，请将评审步骤委托给全新的子Agent：向它提供差异内容、明确的目标以及以下评审步骤，让它在不记得实现过程的情况下返回评审结果。你再对这些结果进行审核后呈现给用户。当没有子Agent工具可用时，你可以自行执行评审步骤，但需在报告中明确说明这是自我评审，因为用户需要知道评审结论的可信度。绝不要悄悄对自己刚编写的变更进行自我评审。

无论采用哪种模式，都要遵循一个原则：评判磁盘上实际存在的代码，而非你记忆中想要编写的代码。

When this fires

触发场景

After an agent (or the user) finishes a chunk of work and wants it judged before it ships: "review this", "review my changes", "review the diff", "check this code", "self-review before I commit", "/reviewkit", or a bare "does this look right" after a coding session. It reviews uncommitted work or a branch's diff, not a line-by-line audit of the whole codebase.

It is distinct from a generic correctness linter: reviewkit leads with convention-fit and agent-slop passes that a bug-focused review skips. If the user only wants correctness bugs, say so and run just that pass; don't pad the report with the other two.

当Agent（或用户）完成一段工作并希望在发布前进行评判时：比如“review this”“review my changes”“review the diff”“check this code”“提交前自我评审”“/reviewkit”，或者编码会话结束后简单询问“这看起来没问题吧”。它评审的是未提交的工作或分支差异，而非对整个代码库进行逐行审计。

它与通用正确性检查工具不同：reviewkit首先进行规范符合性和Agent冗余特征检查，而这些是聚焦bug的评审会跳过的内容。如果用户只想要检查正确性bug，请明确说明并仅运行该步骤，不要在报告中添加另外两类检查的内容。

Procedure

流程

1. Pick the review target

1. 选择评审目标

Ground the review in an actual diff, because reviewing from memory is worthless. Detect the target from git state, then state your pick and let the user override:

Uncommitted changes present (
```
git status --porcelain
```
is non-empty) → review the working tree:
```
git diff HEAD
```
(include staged with
```
git diff --staged
```
). This is the default after a fresh coding session. git diff
does not show untracked files, so a brand-new file an agent never staged is invisible to it, and a whole new module silently escaping review is the worst possible miss. List them with
```
git status --porcelain
```
(the
```
??
```
entries) or
```
git ls-files --others --exclude-standard
```
, and
```
Read
```
each one in full as part of the change: every untracked source file, no exceptions. The only untracked files you may skip are ones nobody wrote: lockfiles, build output, vendored dependencies, compiled assets, snapshots. Note them as generated, spot-check that they're actually generated rather than hand-edited, and move on.
Clean tree, branch ahead of its base → review the branch diff. Get the base branch from gitkit, which owns that resolution. Don't assume
```
main
```
, and don't re-derive it here; a wrong base silently yields an empty diff or one containing half the repo's history, and both look like a real review target. Then run
```
git diff <base>...HEAD
```
and
```
git log <base>..HEAD --oneline
```
for intent.
If the invocation names a target ("review the branch", "review my staged changes") → honor it directly, skip detection.

Say which target you chose and why in one line, then proceed. If neither applies (clean tree, no branch ahead), ask what to review rather than guessing.

Validate before reviewing. Confirm the target resolves (

git rev-parse <ref>

for a named base) and the diff is actually non-empty. If the ref doesn't resolve or the diff is empty, stop and say so, because reviewing a bad or empty range produces fabricated findings, not a review.

Read the diff in full before judging anything, once. The four passes below are four questions asked of one reading, not four readings; don't re-run

git diff

at the top of each pass. If a pass needs a detail you didn't retain, pull that hunk (

git diff HEAD -- <path>

), not the whole diff again. The same applies to the neighboring code you compare against in Convention-fit: read the sibling that establishes the pattern, not every file in the directory.

Note the change's stated intent, from the commit messages, the branch name, the plan or issue it references, or the user's own words, because half the review is asking "did it do what was asked, all of it, and only that?" Capture that intent concretely: it's the spec both Requirement-completeness and the scope-creep check in Agent-slop signatures measure against.

Ground rules for every pass. Apply these throughout; they are what separate a real review from noise:

Skip what tooling already enforces. Don't report formatting, import order, or lint rules a formatter/linter/CI catches on its own. The whole value of this review is what machines miss. Spend it there.
Every finding needs evidence. Quote the offending hunk and name what it violates: a specific line of a repo convention doc, the stated intent, a real API signature, or the concrete failing input. A finding you can't back with a quote is a guess; drop it. This is the primary guard against inventing findings.
Hold each finding to a confidence bar before it ships. Ask what would have to be true for this to be wrong, and report it only when the answer is confirmed by the code, a reproduction, or a test run, or strongly supported with no credible innocent explanation. "Probably a problem, but I couldn't check the runtime behavior" clears the bar only if you say which part you couldn't check. Anything weaker is not a finding. It is an unverified area, and it belongs in the coverage note in Report the findings rather than in the findings list. Downgrading a hunch to "unverified" is a real result; dressing it up as a bug wastes the reader's time and burns their trust in the whole report.
Track what you could not judge. As you go, keep a running list of areas the review didn't genuinely cover: a concurrency path you can't reason about statically, a security boundary whose auth model lives outside the diff, generated files you spot-checked rather than read, a dependency whose real API you couldn't verify offline. Silence reads as "clean," so an unexamined area must be named, not omitted.

评审必须基于实际的差异内容，基于记忆的评审毫无价值。从git状态中检测评审目标，然后说明你的选择并允许用户覆盖：

存在未提交变更（
```
git status --porcelain
```
输出非空）→ 评审工作树：
```
git diff HEAD
```
（若包含暂存内容则使用
```
git diff --staged
```
）。这是刚完成编码会话后的默认选项。git diff
不会显示未跟踪文件，因此Agent从未暂存的全新文件对它来说是不可见的，而整个新模块悄悄逃过评审是最糟糕的遗漏情况。使用
```
git status --porcelain
```
（
```
??
```
条目）或
```
git ls-files --others --exclude-standard
```
列出这些文件，并将每个文件完整读取作为变更的一部分：所有未跟踪的源文件，无一例外。唯一可以跳过的未跟踪文件是自动生成的文件：锁文件、构建输出、第三方依赖包、编译后的资源、快照。标注它们为自动生成文件，抽查确认它们确实是自动生成而非手动编辑的，然后继续评审。
工作树干净，分支领先于基准分支→ 评审分支差异。从gitkit获取基准分支，该工具负责解析基准分支。不要默认假设是
```
main
```
分支，也不要在此处重新推导；错误的基准分支会悄无声息地产生空差异或包含半个仓库历史的差异，这两种情况看起来都像是真实的评审目标。然后运行
```
git diff <base>...HEAD
```
和
```
git log <base>..HEAD --oneline
```
以了解变更意图。
如果调用指令指定了目标（比如“评审该分支”“评审我的暂存变更”）→ 直接遵循指令，跳过自动检测。

用一句话说明你选择的目标及原因，然后继续。如果两种情况都不适用（工作树干净，分支未领先），请询问用户要评审的内容，不要猜测。

评审前验证。确认目标可解析（对命名基准使用

git rev-parse <ref>

）且差异非空。如果引用无法解析或差异为空，请停止评审并告知用户，因为评审错误或空的范围会产生虚假的评审结果，而非真实的评审。

在进行任何评判前，完整阅读一次差异内容。以下四个步骤是针对同一次阅读提出的四个问题，而非四次阅读；不要在每个步骤开头重新运行

git diff

。如果某个步骤需要你没记住的细节，提取对应的代码块（

git diff HEAD -- <path>

），而非再次读取整个差异。在规范符合性检查中与相邻代码对比时也同样如此：读取确立模式的同级代码，而非目录中的所有文件。

记录变更的明确意图，来自提交信息、分支名称、引用的计划或问题，或用户自己的表述，因为评审的一半内容是在问“它是否完成了要求的所有内容，且仅完成了要求的内容？”要具体捕捉该意图：这是需求完整性检查和Agent冗余特征检查中范围蔓延检查的衡量标准。

每个步骤的基本规则。全程遵循这些规则，它们是区分真实评审与无效噪声的关键：

跳过工具已强制执行的内容。不要报告格式化、导入顺序或格式化工具/检查工具/CI已捕获的规则问题。本次评审的全部价值在于发现机器遗漏的问题。把时间花在这些地方。
每个发现都需要证据。引用有问题的代码块，并说明它违反了什么：仓库规范文档的特定条款、明确的意图、真实的API签名，或具体的失败输入。无法提供引用证据的发现只是猜测，请舍弃。这是防止生成虚假发现的主要保障。
每个发现都要达到置信度标准才能报告。询问什么情况下该发现会是错误的，仅当答案是由代码、复现案例或测试运行确认，或有强有力的支持且没有可信的无辜解释时才报告。“可能是问题，但我无法检查运行时行为”只有在说明无法检查的部分时才符合标准。任何更弱的情况都不是发现，而是未验证区域，应放在报告发现的覆盖说明中，而非发现列表里。把直觉降级为“未验证”是真实的结果；把它伪装成bug会浪费读者的时间，并损害他们对整个报告的信任。
记录无法评判的内容。在评审过程中，不断记录评审未真正覆盖的区域：无法静态分析的并发路径、位于差异之外的安全边界认证模型、仅抽查而非完整读取的生成文件、无法离线验证真实API的依赖项。沉默会被解读为“无问题”，因此未检查的区域必须明确标注，而非省略。

2. Pass 1: Convention-fit

2. 步骤1：规范符合性检查

Does the change look like the rest of this repository wrote it? Agents default to generically-correct code that ignores local idiom. For each changed file, compare against its neighbors, because the surrounding code is the spec:

Naming & structure. Do new names, file layout, and module boundaries match sibling files? An agent that names a helper
```
getUserData
```
in a repo full of
```
fetch_user
```
stands out.
Established patterns. Does the repo already have a way to do this (an HTTP client, an error type, a logging helper, a test factory) that the change reinvents instead of reusing? Grep for prior art before accepting a new abstraction.
Idiom & style. Error handling, async style, imports, formatting conventions the linter doesn't catch. Match what's there, not what's "best practice" in the abstract.
Dependencies. Did it add a library for something the repo already solves, or that the project's conventions forbid? Check the manifest and existing imports.
Stated conventions. If the repo documents its conventions (a
```
CLAUDE.md
```
, an agent-guide file, a
```
CONTRIBUTING.md
```
, or a style guide), read it and hold the change to it. A documented repo rule always overrides a general "best practice."

Named smells that show up here (Fowler's vocabulary, so use the label when it fits, since it's sharper than a paragraph): Mysterious Name (unclear naming), Shotgun Surgery (one logical change smeared across many files), Divergent Change (one module edited for several unrelated reasons).

变更看起来像是当前仓库的其他代码编写的吗？Agent默认生成通用正确但忽略本地习惯的代码。对于每个变更文件，与它的同级文件对比，因为周围的代码就是规范：

命名与结构。新的命名、文件布局和模块边界是否与同级文件匹配？在一个满是
```
fetch_user
```
的仓库中，Agent命名的
```
getUserData
```
助手会显得格格不入。
已确立的模式。仓库是否已有实现该功能的方式（HTTP客户端、错误类型、日志助手、测试工厂），而变更却重新实现而非复用？在接受新的抽象前，先搜索已有实现。
习惯用法与风格。错误处理、异步风格、导入方式、格式化工具未捕获的格式规范。匹配现有代码，而非抽象意义上的“最佳实践”。
依赖项。它是否为仓库已解决的问题添加了库，或违反了项目的规范？检查清单文件和现有导入。
明确的规范。如果仓库有文档化的规范（
```
CLAUDE.md
```
、Agent指南文件、
```
CONTRIBUTING.md
```
或风格指南），请阅读并以此评判变更。文档化的仓库规则始终优先于通用的“最佳实践”。

此处常见的代码异味（使用Fowler的术语，合适时使用标签，比段落更清晰）：Mysterious Name（命名不清晰）、Shotgun Surgery（一个逻辑变更分散到多个文件中）、Divergent Change（一个模块因多个不相关原因被修改）。

3. Pass 2: Agent-slop signatures

3. 步骤2：Agent冗余特征检查

Hunt the tells of machine-generated code, the padding that looks productive but earns its keep nowhere:

Over-engineering. Abstraction for a single caller, config knobs nothing sets, layers of indirection a direct call would replace, "future-proofing" for requirements that don't exist.
Dead & unreachable code. Helpers never called, branches that can't execute, exports nothing imports, variables assigned and never read.
Hallucinated or wrong APIs. Calls to methods, flags, or fields that don't exist on the real type; a plausible-sounding function from the wrong library version. Verify against the actual dependency, not the model's guess.
Redundant comments. Narration that restates the code (
```
// increment i
```
), docstrings that add nothing, commented-out code left behind.
Scope creep. Changes outside what was asked: unrelated refactors, reformatting untouched lines, drive-by renames, version bumps nobody requested. Flag anything the stated intent doesn't justify.
Fake robustness. try/catch that swallows errors, defaults that hide failures, tests that assert nothing or are tautological,
```
TODO
```
s standing in for real handling.

Named smells that show up here: Speculative Generality (abstraction for needs that don't exist, so delete it and inline until a real second caller appears), Duplicated Code (the same logic pasted across hunks instead of shared), Primitive Obsession (a bare string/int standing in for a domain concept), Middle Man / Message Chains (layers that only delegate, or

a.b().c().d()

navigation). Speculative Generality especially is the signature agent smell.

寻找机器生成代码的特征，即看似有用但实则无用的冗余内容：

过度设计。只为单个调用者设计的抽象、无人设置的配置项、可用直接调用替代的多层间接调用、针对不存在需求的“未来兼容”设计。
死代码与不可达代码。从未被调用的助手函数、无法执行的分支、无人导入的导出、已赋值但从未使用的变量。
虚构或错误的API。调用真实类型上不存在的方法、标志或字段；来自错误库版本的看似合理的函数。请根据实际依赖项验证，而非模型的猜测。
冗余注释。重复代码内容的叙述（如
```
// increment i
```
）、无实质内容的文档字符串、遗留的注释代码。
范围蔓延。超出要求的变更：不相关的重构、格式化未修改的代码、顺带重命名、无人要求的版本升级。标记任何明确意图未涵盖的内容。
虚假健壮性。吞噬错误的try/catch、隐藏失败的默认值、无实际断言或同义反复的测试、用
```
TODO
```
替代真实处理的代码。

此处常见的代码异味：Speculative Generality（针对不存在需求的抽象，因此应删除并内联，直到出现真正的第二个调用者）、Duplicated Code（相同逻辑复制到多个代码块而非共享）、Primitive Obsession（用原始字符串/整数替代领域概念）、Middle Man / Message Chains（仅做委托的层，或

a.b().c().d()

式的链式调用）。Speculative Generality尤其是Agent生成代码的标志性异味。

4. Pass 3: Requirement-completeness

4. 步骤3：需求完整性检查

Agents under-deliver as often as they over-deliver: they stub a branch, skip an edge of the ask, or solve the easy 80% and leave the rest silently unfinished. Measure the change against the intent captured in Pick the review target, meaning the plan, issue, or user's words, and report the gaps:

Missing requirements. Something the ask called for that the diff doesn't do at all.
Partial implementation. A requirement handled for the happy path only, one case of several, or the interface without the behavior.
Stubs & placeholders left in.
```
TODO
```
/
```
FIXME
```
/
```
throw new Error("not implemented")
```
/
```
pass
```
/empty handlers presented as if the work were done.
Wrong interpretation. The change does something, but not the thing that was asked; it solved a nearby, easier problem.

If there's no captured intent to measure against (no plan, issue, or clear request), say so and skip this pass rather than inventing a spec. Don't guess at requirements the user never stated.

Agent交付不足的情况与交付过度一样常见：它们会存根分支、跳过需求的边缘部分，或解决简单的80%内容，而将剩余部分悄悄留空。根据选择评审目标中捕捉的意图（即计划、问题或用户的表述）衡量变更，并报告差距：

缺失的需求。要求中提到但差异未实现的内容。
部分实现。仅处理了正常路径的需求、多个案例中的一个，或仅实现了接口而未实现行为。
遗留的存根与占位符。
```
TODO
```
/
```
FIXME
```
/
```
throw new Error("not implemented")
```
/
```
pass
```
/空处理函数被当作已完成的工作提交。
错误的解读。变更实现了某些内容，但并非要求的内容；它解决了一个相近但更简单的问题。

如果没有可衡量的明确意图（没有计划、问题或清晰的请求），请说明并跳过此步骤，不要臆造规范。不要猜测用户未明确说明的需求。

5. Pass 4: Correctness

5. 步骤4：正确性检查

Now the classic review, on what survives the earlier passes:

Logic errors. Off-by-one, inverted conditions, wrong operator, mishandled return values.
Edge cases. Empty/null/missing input, boundary values, unicode, large payloads, the error path as well as the happy path.
State & concurrency. Race conditions, mutation of shared state, ordering assumptions, idempotency, resource cleanup (files, connections, locks).
Security. Injection, missing authz/ownership checks, secrets in code or logs, unsafe deserialization, unvalidated input crossing a trust boundary.
Tests. Do the changed tests actually exercise the change, and do they pass? Run the repo's test command if one is obvious and cheap; report what you ran and what happened.

A passing test suite is not evidence of a tested change, because agents write tests that pass because they assert nothing that could fail. Hold each new or changed test to these:

Would it fail against a broken implementation? Mentally invert the logic it covers, or break a boundary value. If the test still passes, it's decoration. This is the single sharpest test-quality question.
Does it assert observable behavior, or does it re-implement the production logic in the assertion and compare the code to itself?
Is the scenario visible in the test, or buried in setup/fixtures/mocks so thoroughly that the test proves the mock works and nothing else?
Does it cover the failure paths the change introduced, not just the happy path the feature demo walks?
Does it prove the stated requirement, or an easier neighbor of it?

现在进行经典的评审，针对通过前面步骤的内容：

逻辑错误。差一错误、条件反转、错误的运算符、处理不当的返回值。
边缘案例。空/空值/缺失输入、边界值、Unicode、大负载、错误路径与正常路径。
状态与并发。竞态条件、共享状态的修改、顺序假设、幂等性、资源清理（文件、连接、锁）。
安全性。注入攻击、缺失的授权/所有权检查、代码或日志中的机密信息、不安全的反序列化、跨信任边界的未验证输入。
测试。变更后的测试是否真正覆盖了变更内容，且能否通过？如果有明显且低成本的仓库测试命令，请运行并报告运行内容和结果。

通过测试套件并不意味着变更已被测试，因为Agent编写的测试会通过是因为它们没有断言任何可能失败的内容。请对每个新增或修改的测试进行以下检查：

如果实现出现问题，它会失败吗？ 在脑中反转它覆盖的逻辑，或破坏一个边界值。如果测试仍然通过，那它只是装饰。这是判断测试质量最尖锐的问题。
它是否断言可观察的行为，还是在断言中重新实现了生产逻辑并将代码与自身进行比较？
场景是否在测试中可见，还是被完全隐藏在设置/夹具/模拟中，导致测试仅证明模拟有效而无其他作用？
它是否覆盖了变更引入的失败路径，而非仅覆盖功能演示的正常路径？
它是否证明了明确的需求，还是证明了一个更简单的相近需求？

6. Report the findings

6. 报告发现

Print the review inline, findings ranked by severity so the reader triages at a glance. Tag each:

🔴 Blocker. Must fix before this ships; a real bug, security hole, missing requirement, or broken convention that will bite.
🟡 Should-fix. A genuine problem worth addressing, not release-blocking.
🟢 Nit. Polish, style, minor slop; take it or leave it.

For each finding give, in this order: the location as

file:line

(clickable), which pass caught it (convention / slop / completeness / correctness), a quote of the offending hunk and what it violates (the convention doc line, the stated requirement, the real API, or the failing input, per the evidence ground rules in Pick the review target), what's wrong in one sentence, and the concrete fix. If a pass found nothing, say so; a clean pass is a real result. Never invent findings to look thorough. If you can't quote the evidence, it's not a finding. An empty report on a clean diff is the honest outcome.

Structure the report as: the verdict line, the findings most severe first, then the coverage note.

The verdict follows from the findings; it is not a vibe. Pick it mechanically so a reader can trust it without re-reading the list:

needs-work. One or more 🔴 Blockers.
ready-with-fixes. No Blockers, but at least one 🟡 Should-fix.
ready. Nothing above 🟢 Nits. Nits never hold up a change.

Never soften a verdict because the change is mostly good or the author worked hard on it; never harden one to look rigorous. If a Blocker is real, the change needs work even if everything else is excellent.

Close with the coverage note: one short paragraph naming what this review did not verify, meaning the unverified areas collected during the passes, plus whether you ran the tests and whether this was a fresh-eyes review or a self-review (per Review with fresh eyes). A reader who knows the concurrency path went unexamined can go look; a reader who assumes it was covered cannot. When a gap is serious enough that a real problem could be hiding in it (an unreviewed security boundary, a migration nobody can validate here), say the change is blocked on outside review rather than issuing a verdict the evidence doesn't support.

Do not edit source or apply fixes. If the user wants the fixes made, hand off: they run an implement-style skill, or fix by hand and re-run reviewkit.

内联打印评审结果，发现的问题按严重程度排序，以便读者快速分类处理。为每个问题标记：

🔴 阻塞问题。发布前必须修复；真实的bug、安全漏洞、缺失的需求或会造成影响的违反规范问题。
🟡 建议修复。真正的问题，值得解决，但不影响发布。
🟢 小问题。 polish、风格、轻微冗余；可修复也可不修复。

每个发现按以下顺序呈现：位置（

文件:行号

，可点击）、发现该问题的步骤（规范/冗余/完整性/正确性）、有问题的代码块引用及违反的内容（规范文档条款、明确需求、真实API或失败输入，遵循选择评审目标中的证据基本规则）、一句话说明问题所在，以及具体的修复方案。如果某个步骤未发现任何问题，请说明；无问题的步骤是真实的结果。绝不要为了显得全面而编造发现。如果无法提供引用证据，那就不是发现。干净差异的空报告是诚实的结果。

报告结构：结论行，最严重的发现在前，然后是覆盖说明。

结论由发现的问题得出；不是主观感觉。机械地选择结论，以便读者无需重新阅读列表就能信任它：

需要修改。存在一个或多个🔴阻塞问题。
修复后可发布。无阻塞问题，但至少存在一个🟡建议修复问题。
可发布。无高于🟢小问题的内容。小问题绝不会阻碍变更发布。

不要因为变更整体良好或作者付出了努力而软化结论；也不要为了显得严谨而强化结论。如果阻塞问题真实存在，即使其他一切都很优秀，变更也需要修改。

最后附上覆盖说明：简短的段落，说明本次评审未验证的内容，即评审过程中记录的未验证区域，以及是否运行了测试、是全新视角评审还是自我评审（遵循以全新视角评审）。知道并发路径未被检查的读者可以自行查看；而假设它已被覆盖的读者则无法做到。如果某个差距严重到可能隐藏真实问题（未评审的安全边界、无人能在此验证的迁移），请说明变更需外部评审后才能推进，而非发布证据不支持的结论。

不要编辑源代码或应用修复。如果用户想要修复，请转交：他们可以运行实现类技能，或手动修复后重新运行reviewkit。

7. Optional: save the report

7. 可选：保存报告

After showing the review, offer to save it (don't save unprompted). If the user wants a durable copy, e.g. to paste into a PR description, write it to

docs/reviews/review-<branch-or-feature-slug>-YYYY-MM-DD.md

, using a short lowercase kebab-case slug and the review's ISO creation date (for example,

review-auth-refactor-2026-07-23.md

). Keep that date stable if the same report is edited. For a genuine same-day collision between distinct reviews, make the slug more specific; only as a last resort insert a sequence immediately before the date (

review-auth-refactor-02-2026-07-23.md

). Create

docs/reviews/

if needed. Keep the saved file identical to what you printed, with a one-line header noting the date and the reviewed range. If there's no filesystem, skip this step and leave the inline report as the deliverable.

展示评审结果后，主动提供保存选项（不要未经提示就保存）。如果用户需要持久化副本，比如粘贴到PR描述中，请将其写入

docs/reviews/review-<分支或功能slug>-YYYY-MM-DD.md

，使用简短的小写短横线命名slug和评审的ISO创建日期（例如

review-auth-refactor-2026-07-23.md

）。如果同一报告被编辑，日期保持不变。如果同一天有不同评审出现重名，请将slug改得更具体；万不得已时才在日期前插入序号（

review-auth-refactor-02-2026-07-23.md

）。如果

docs/reviews/

不存在则创建它。保存的文件需与打印的内容完全一致，添加一行标题注明日期和评审范围。如果没有文件系统，请跳过此步骤，以内联报告作为交付物。

Notes

注意事项

Read-only by contract. reviewkit runs git and read/search commands to understand the change, and at most the repo's own test command to check correctness. It never edits source, never commits, never pushes. Its only write is the optional report file in Optional: save the report, and only when the user asks for it.
Skill
is in the tool list for gitkit, and for nothing else. reviewkit calls gitkit to resolve the base ref when it reviews a branch diff, because a wrong base yields an empty diff or half the repo's history, and both look like a real review target. The implement-style skill named in the findings hand-off is routed to, never invoked.
Scale to the diff. A one-line fix gets a quick pass-through and a one-line verdict; a large feature branch gets the full treatment. Don't pad a small change with ceremony.
Not a substitute for tests or CI. It's a judgment pass on top of them, tuned for how agent-written code fails. Report what the automated gates already cover as covered; spend the review on what they miss. This is the same reason the review-target ground rules skip tooling-enforced rules.
No shell or git? Ask the user to paste the diff and the original ask, then run the four passes on what they provide and print the report as a codeblock for them to save themselves.

只读约定。reviewkit运行git和读取/搜索命令以理解变更，最多运行仓库自身的测试命令以检查正确性。它绝不会编辑源代码、提交或推送。唯一的写入操作是可选：保存报告中的可选报告文件，且仅在用户要求时执行。
Skill
仅在gitkit的工具列表中使用，无其他用途。当评审分支差异时，reviewkit会调用gitkit来解析基准引用，因为错误的基准会产生空差异或包含半个仓库历史的差异，这两种情况看起来都像是真实的评审目标。发现中提到的实现类技能仅用于转交，绝不会被调用。
根据差异规模调整评审。一行代码的修复只需快速检查和一行结论；大型功能分支则需要完整的评审流程。不要为小变更添加不必要的仪式。
不能替代测试或CI。它是在测试和CI之上的判断步骤，针对Agent编写代码的失效模式进行优化。报告自动化流程已覆盖的内容为已覆盖；把评审时间花在它们遗漏的地方。这也是评审目标基本规则跳过工具强制执行规则的原因。
没有shell或git？ 请用户粘贴差异内容及原始需求，然后对提供的内容运行四个步骤，并将报告作为代码块打印出来供用户自行保存。",