Turn 1 — read

Turn 1 — read

One tool call: read the unified diff (git diff @{upstream}...HEAD; git diff HEAD to cover both committed and uncommitted changes, or git diff main...HEAD / the target passed as an argument). Skip test/fixture hunks (test/, spec/, __tests__/, *_test.*, *.test.*, fixtures/, testdata/) — test-file changes are not reviewed at this level. No subagents, no full-file reads.

### 3.1 diff 获取命令

模板给出的取数方式是**单次工具调用**读取统一 diff，具体命令为：

```bash
git diff @{upstream}...HEAD; git diff HEAD

其中：

• git diff @{upstream}...HEAD 覆盖已提交到 HEAD 的变更（三点语法取与上游分叉点之后的差异）；
• git diff HEAD 补上尚未提交的工作区变更——两者合用才能保证「已提交 + 未提交」全都在审查范围内。README 与 high.md 的 Phase 0 也都强调同一动机：审查常常发生在 commit 之前；
• 备选方案是 git diff main...HEAD，或直接使用作为参数传入的 target（PR 编号 / 分支 / 路径）。

3.2 测试与 fixture hunk 的跳过清单

low 档明确不审查测试文件变更，跳过清单为以下路径模式：

模式	覆盖对象
test/	位于 test 目录下的文件
spec/	spec 风格测试目录
__tests__/	Jest 等常用测试目录
*_test.*	Go、Python 等后缀式测试文件
*.test.*	前端生态常用的 .test.ts/.test.js
fixtures/	测试数据目录
testdata/	测试数据目录（如 Go 惯例）

原文的表述是 "test-file changes are not reviewed at this level"——注意这是一个档位级约束：不是 low 档认为测试文件不重要，而是该成本档位下明确不做这部分工作。对比来看，xhigh.md / max.md 在候选去重时还专门要求「指向同一行/同一机制的候选只留一个」，而 low 档连这个去重步骤都没有，只保留了输出上限。

3.3 「No subagents, no full-file reads」

这两个 no 是 low 档成本模型的核心：

• No subagents：medium 及以上档位均要求「Run N independent finder angles via the Agent tool」，并在 Agent 工具不可用时降级为「自己在本上下文里顺序执行每个角度（及每次验证）」；low 档从根上就不涉及该路径；
• No full-file reads：high 档的 Angle A 要求逐行读 diff 后再 Read 每个 hunk 所包裹的整个函数（"bugs in unchanged lines of a touched function are in scope"），low 档则连这一步都不做——后续 Turn 2 的判定边界正是由这一条推导出来的（见下一节）。

四、Turn 2 — findings：只在 hunk 可见范围内判定「运行期正确性缺陷」

low.md 的 Turn 2 原文如下（完整继承）：

## Turn 2 — findings

Flag runtime-correctness bugs visible from the hunk alone: inverted/wrong
condition, off-by-one, null/undefined deref where adjacent lines show the value
can be absent, removed guard, falsy-zero check, missing `await`,
wrong-variable copy-paste, error swallowed in a catch that should propagate.
Also flag — still from the hunk alone — new code that duplicates an existing
helper visible in the diff context, and dead code the diff leaves behind.

Do **not** flag style, naming, perf, missing tests, or anything outside the
hunk.

Output at most **4 findings**, most-severe first, one line each:
`path/to/file.ext:123 — what's wrong and the concrete failure`. If nothing
qualifies, output exactly `(none)`. Do not call the
ReportFindings tool even if it is available.

4.1 应标记的缺陷类型（全部要求「hunk 可见」）

判定前提是一个短语：visible from the hunk alone——缺陷必须仅凭 diff 片段本身就能看出。这是 Turn 1「不读整文件」的直接后果：既然没有全文件与跨文件上下文，任何需要外部信息才能成立的结论都不允许输出。在此前提下，模板枚举了两类共 10 个具体缺陷模式：

第一类：运行期正确性 bug（8 种）

1. inverted/wrong condition —— 条件写反或写错（如 if (a < b) 实为 if (a > b)）；
2. off-by-one —— 边界差一错误；
3. null/undefined deref —— 且限定为「相邻行显示该值可能缺席」时才算，即 diff 上下文里能看到取值路径存在缺省可能；
4. removed guard —— 防护被删除（如 if (!x) return 被删掉但没有别处重建该不变量）；
5. falsy-zero check —— 用 truthiness 判断把合法的 0/"" 当作缺失值；
6. missing await —— 异步调用漏掉 await；
7. wrong-variable copy-paste —— 复制粘贴后用了错误变量；
8. error swallowed in a catch that should propagate —— 本应向上抛出的错误被 catch 吞掉。

值得注意的是，这份清单与 high.md Angle A（line-by-line diff scan）的查找清单高度同源（后者额外多了 unescaped regex metachars 且范围扩大到被触碰函数的全部行），可以推断 low 档本质上就是把 high 档的「Angle A 单角度」压缩成无回读文件版本。

第二类：hunk 可见范围内的清理项（2 种）

• 新代码重复实现了 diff 上下文里可见的既有 helper——注意限定是 "visible in the diff context"，即不要求去 grep 共享工具模块（那是 high 档 Reuse 角度" Grep shared/utility modules and files adjacent to the change"的工作）；
• diff 遗留的死代码（dead code the diff leaves behind）。

4.2 明确不标记的负面清单

Do **not** flag style, naming, perf, missing tests, or anything outside the hunk.

负面清单包含五类：风格、命名、性能、缺失测试，以及一切超出 hunk 范围的问题。这条规则与档位定位一致：

• 性能问题属于 high/xhigh/max 档 Efficiency 角度的职责（该角度会标记冗余计算、重复 I/O、独立操作串行执行、热路径阻塞，以及由闭包捕获整个环境导致的内存泄漏）；
• 「缺失测试」在 low 档被整体排除，因为 Turn 1 连测试 hunk 都跳过了；
• 「anything outside the hunk」从制度上封堵了「推测性发现」：没有验证阶段兜底的档位，靠输入边界自律来控制误报。

五、输出契约：至多 4 行、单行格式，或恰好 (none)

low 档的输出契约有三条硬约束：

1. 数量：至多 4 条发现，most-severe first（严重度降序）；

2. 格式：每条一行，格式为

   path/to/file.ext:123 — what's wrong and the concrete failure
   

   即「文件路径:行号 — 问题是什么 + 具体失败形态」。要求给出 "the concrete failure"，而不是笼统地说「这里可能有问题」；

3. 空结果：没有任何发现时，恰好输出 (none)——不是空消息，也不是自由发挥的「看起来不错」。

这与 medium 及以上档位的结构化输出契约形成对照：medium.md 与 high.md 要求返回至多 8 / 10 个对象的 JSON 数组，每个对象含 file、line、summary、failure_scenario 四个字段，并在结尾同样声明「即使 ReportFindings 工具可用也不要调用——本审查的输出契约就是上面的 JSON 块」。low 档则进一步把输出从 JSON 降为纯文本单行列表，省掉序列化成本，适合在终端里一眼扫完。

六、与 ReportFindings 工具的关系：明确禁止走结构化通道

low.md 最后一句 "Do not call the ReportFindings tool even if it is available" 值得单独说明。仓库中的 report-findings-tool.md 记录了 ReportFindings 工具的完整描述与 JSON Schema：它是宿主 UI 需要渲染类型化发现列表时挂载的替代输出通道，单次调用即完成上报、不再以文本重复打印发现，其 schema 关键约束包括：

• level 枚举为 low / medium / high / xhigh / max；
• findings 数组 maxItems: 32，每项必填 file、summary、failure_scenario（1 起始行号、单句缺陷陈述、具体失败场景）；
• 可选字段含 short_summary（≤60 字符的压缩标签）、category（kebab-case 分类 slug）、verdict（仅在跑过验证阶段时设置，枚举 CONFIRMED / PLAUSIBLE）、outcome（仅在应用修复后重新上报时设置，枚举 fixed / skipped / no_change_needed）。

该工具自身也声明「仅当当前生效的 code-review 指示要求用它上报时才能使用」。low 档的指示是纯文本行输出，所以即使会话里挂了 ReportFindings，也必须忽略它——因为该工具的 verdict 字段「inline-only 的审查不存在」，而 low 档恰是没有任何 verify pass 的 inline 审查。

七、模型路由：low 档并非所有模型拿到同一份文件

README 指出，effort 只是路由键的一半，模型家族是另一半。本文精读的 low.md 是路由矩阵中的 default 列，实际存在差异化单元格：

模型家族	与 default 不同的 low 档行为
claude-sonnet-5	low 档使用变体：发现上限改为 min(files, 4)（受文件数限制）而非固定封顶 4
claude-opus-4-8	拥有自己的 o48-low/med/high/xhigh 提示词（max 仍用共享版）
claude-opus-5	medium 与 high 坍缩为同一个「极简提示 → 单遍 careful diff → ≤15 findings 经 ReportFindings 上报」单元格；low 与 max 用共享版

此外，每一档都配有 无 Agent 工具的降级路径（角度在本上下文内联顺序执行、跳过子代理验证）——low 档因为本来就不依赖 Agent 工具，天然不受此影响。二进制中还包含未收录在此仓库的兄弟变体：经 ReportFindings 上报的输出模式、把发现渲染为可分享 HTML 页的 artifact 发布步骤，以及 high/xhigh/max 启用 workflow 时的编排（每个正确性角度一个 finder、一个合并的清理 finder、每个 distinct file:line 一个验证器、最后综合）。

八、实战用法与档位选择建议

结合 README.md 的用法说明，low 档的典型用法是：

/code-review low
/code-review low <PR编号|分支|ref区间|路径>