Requesting code review

请求审查

概述

对代码、计划、设计或项目方案进行系统和彻底的审查。

核心原则： 不验证需求的审查是不完整的。不阅读全部代码的审查是不诚实的。

审查类型

本技能支持四种审查类型。根据工作产物选择正确的类型：

审查类型	何时使用	审查重点	上游依赖
代码审查 (code)	Feature分支完成、PR就绪、复杂逻辑需要第二双眼睛	实现质量+功能完整性+安全性+可交付性	brainstorming输出的spec作为需求基线
计划审查 (plan)	实现计划写完、准备开始编码前	任务分解合理性+可行性+spec对齐+文件结构	writing-plans输出的plan文档
设计审查 (design)	设计文档完成、架构决策做出后	架构合理性+权衡分析+领域一致性+ADR对齐	brainstorming输出的design文档
项目审查 (project)	大型项目方案完成、多子系统协调	范围边界+风险评估+依赖分析+分解建议	brainstorming的项目级输出

各类型特定的审查维度权重

五维度在不同审查类型中的权重不同：

维度	代码审查	计划审查	设计审查	项目审查
完整性	★★★	★★★	★★☆	★★★
正确性	★★★	★★☆	★☆☆	★☆☆
一致性	★★☆	★★★	★★★	★★☆
安全性	★★★	★★☆	★★☆	★☆☆
可交付性	★★☆	★★★	★☆☆	★★★

详细的五维度定义见 agents/code-reviewer.md，这是所有审查的权威维度定义。

审查流程

1. 准备上下文

根据审查类型准备输入：

# 代码审查
BASE_SHA=$(git rev-parse origin/main)  # 或其他基线
HEAD_SHA=$(git rev-parse HEAD)

对于代码审查，需要 diff 范围。对于计划/设计/项目审查，需要文档路径。

2. 调用审查 Agent

使用 Agent 工具调用 code-reviewer agent，填充 code-reviewer.md 模板：

• {REVIEW_TYPE} — code | plan | design | project
• {WHAT_IS_UNDER_REVIEW} — 被审查的内容描述
• {REQUIREMENTS_SOURCE} — spec/plan/PR描述的链接或内联内容
• {BASE_SHA} 和 {HEAD_SHA} — 仅代码审查需要
• {DESCRIPTION} — 简要总结

3. 解读审查结果

审查Agent返回结构化报告：

• 需求覆盖矩阵 — 每个需求追溯到实现，标注状态
• 问题按严重度 — Critical / Important / Minor
• 安全性评估 — 漏洞或明确无关注点
• 测试覆盖评估 — 覆盖缺口
• 明确裁决 — 可以合并 / 修复后 / 否

4. 处理结果

• Critical 问题：合并前必须修复
• Important 问题：合并前修复或合并后立即修复
• Minor 问题：记录但不阻塞

如果审查遗漏了重要问题：用技术依据回推。

与其他 Skills 的联动

brainstorming (需求澄清)
    ↓ 输出：spec文档（= 审查的需求基线）
writing-plans (实现计划)
    ↓ 输出：plan文档（= 计划审查的输入）
requesting-code-review (本技能)
    ↓ 调用 code-reviewer agent
    ↓ 输出：审查报告（覆盖矩阵+问题+裁决）
receiving-code-review (处理反馈)
    ↓ 修复 → verification-before-completion (验证)

触发时机

审查在以下时机是合适的：

• Feature分支完成
• PR准备提交
• 一个逻辑工作块完成，继续之前希望验证
• 准备合并到受保护分支
• 复杂逻辑需要第二双眼睛
• 计划文档写完，需要验证可行性
• 设计文档完成，需要验证架构合理性

红线

绝对不要：

• 因为"太简单"而跳过审查 — 简单的代码也有 bug
• 忽略 Critical 问题
• 未解决 Important 问题就合并
• 接受不包含需求覆盖矩阵的审查
• 接受审查者明显没完整阅读代码的审查

如果审查看起来有问题：

• 用技术推理回推
• 展示证明审查关注点已被解决的代码/测试
• 对不清楚的发现要求澄清