review

审查

对比 HEAD 与固定基点进行多维度审查——默认情况下，固定基点为 PR 的目标分支（见步骤 1）。每个维度都会由一个独立的并行子 Agent负责，以免彼此的上下文受到干扰。随后会核实发现是否存在误报，并分别汇总各个维度，不将它们合并——用户可以分别评估每个维度。

四个维度：

• 标准——代码是否遵循仓库文档中规定的标准？这些标准本身是否合理，还是存在值得指出的技术债？
• 规范——代码是否忠实地实现了原始工单或规范？
• 架构——变更的代码中是否存在深化架构的机会？（从 /improve-codebase-architecture 的视角审视）
• 差异方案——对于每项变更，在 PR 的范围内，考虑其他方案后，这是否是最佳选择？

流程

1. 确定固定基点

固定基点是 PR 的目标分支——这项工作将合并到的分支。不要询问；自行确定：

• 如果该分支有关联的 PR，读取其目标分支：gh pr view --json baseRefName -q .baseRefName。
• 如果没有 PR，则使用仓库的默认分支：gh repo view --json defaultBranchRef -q .defaultBranchRef.name（通常是 main）。
• 只有在用户明确指定了其他固定基点（提交 SHA、标签、HEAD~5 等）时才使用它，并原样传入。

记录一次差异命令：git diff <fixed-point>...HEAD（三点语法，基于合并基点）——这就是要审查的内容。使用 git log <fixed-point>..HEAD --oneline 记录提交列表；它是理解变更和查找规范的上下文，不是审查目标。审查范围限于差异中的代码，而不包括提交消息、PR 标题／描述或分支名称。

2. 确定规范来源

按以下顺序查找原始规范：

1. 提交消息中的工单引用（#123、Closes #45）——通过项目的工单跟踪系统获取。
2. 用户作为参数传入的路径。
3. docs/、specs/ 或 .scratch/ 下与分支或功能相匹配的规范文件。
4. 如果找不到任何内容，则询问用户。如果没有规范，规范维度跳过审查并报告“无可用规范”。

3. 确定标准来源

任何规定代码编写方式的文档：CLAUDE.md、AGENTS.md、CONTRIBUTING.md、CONTEXT.md／CONTEXT-MAP.md、docs/adr/、STYLE.md／STANDARDS.md 以及配置文件（eslint.config.*、biome.json、tsconfig.json——记录这些文件，但不要重复检查工具已强制执行的内容）。收集文件列表，由标准子 Agent 阅读。跳过规定提交消息或 PR 惯例而非代码规范的文档（例如 commit-style.md）——审查范围限于代码。

4. 先分流，再并行启动各个维度的子 Agent

**先分流（只需判断一次，不用公式）：**是否有实质性内容需要推理？

• 明确只是表面改动——仅文档、注释、格式调整、版本升级或生成文件变更 → 只运行 Standards + Spec；跳过 Architecture 和 Divergent。请在报告中注明这一点。
• 明显是自动化变更或空操作（例如 CI 已把关的 dependabot 升级）→ 跳过审查，并用一句话说明“没有实质性内容需要审查”。
• 其他情况或任何疑问 → 运行全部四个。倾向于多运行：一行改动也可能举足轻重（安全检查的调整正是 isV4 的案例）。只有明显只是表面改动时才合并处理。

然后发送一条消息，为每个适用维度调用一个 Agent（所有调用都使用 general-purpose 子 Agent）。不要自行阅读差异或文档——只做轻量调度。告诉每个子 Agent 阅读并遵循自己的简述文件，只传递差异命令、提交列表（仅供参考，不是审查目标）以及所需的源文件路径：

• Standards → axes/standards.md（以及第 3 步中列出的标准源文件路径）
• Spec → axes/spec.md（以及规范路径）——如果不存在规范则跳过；并在报告中注明
• Architecture → axes/architecture.md
• Divergent → axes/divergent.md

每份简述都遵循共享的发现条目规范（axes/_contract.md）——上限约 400 字；每条发现都须包含按维度区分的判定（正确性维度提供置信度评分；Architecture/Divergent 提供推理是否成立的判断）以及证据——这样第 5 步的筛选才有依据。

5. 核实每条发现是否为误报

收集各维度 Agent 返回的发现，并在汇总前依照 FILTER.md 进行筛选：对正确性维度（Standards/Spec）逐条独立核实，按文件和行号去重，并对每个维度作出处置，只保留符合条件的发现。判断维度（Architecture/Divergent）不设核实环节——筛选规则已包含在各自的维度简述中，因此协调者直接采纳其结果，只进行去重并应用始终丢弃列表。正是这一筛选机制确保自主发布安全——作者驳回一条发现所损失的可信度，比漏掉一处小问题更大。关于具体流程、评分标准、阈值和始终丢弃列表，FILTER.md 是唯一准则；请遵循其中说明，不要在此重新推导。

6. 汇总

将每条保留的发现按维度标题列出（## Standards、## Spec、## Architecture、## Divergent），并稍作润色。不要跨维度合并或重新排序——分开呈现正是重点（第 5 步中按文件和行号去重是唯一的跨维度合并）。最后用一行总结：各维度保留的发现数量、最严重的问题，以及低于阈值而被丢弃的数量（不得静默截断）。

7. （可选）作为 PR 评论发布

仅当用户要求发布时才执行。发布一条批量的完整行内审查评论——每条保留的发现都必须锚定到对应行，绝不发布未锚定的 gh pr comment。如果没有保留任何发现，请如实说明，不要凭空制造小问题。 如果此工具已审查过该 PR，只发布差异，绝不重复发布。 跳过已关闭、已合并或草稿状态的 PR。有关流程、置信度显示、跨主题处理、格式、标签、AI 免责声明、空审查处理和重新审查逻辑，请参阅 COMMENTS.md，不要在此重新推导。

为什么要分开不同维度

一项变更可能通过一个维度的审查，却未通过另一个维度：

• 符合所有标准，但实现了错误的功能 → Standards 通过，Spec 不通过。
• 完全按工单要求实现，但破坏了惯例 → Spec 通过，Standards 不通过。
• 实现正确且符合惯例，但模块过于浅薄，或选择劣于其他方案 → 只有 Architecture / Divergent 能发现。

分开报告可以避免一个维度掩盖另一个维度的问题。