code-review

name	code-review
description	当需要审查当前工作区代码改动时，必须立刻阅读我。我定义审查范围选择、git diff 获取方式、委托给下级部门的输出协议，以及最终结果应如何回填到工具结果批次。

Code Review

目标

• 审查当前工作区代码改动，而不是审查单条工具调用。
• 先拿到明确 diff，再做缺陷判断。
• 只报告真实、可复现、会影响正确性/稳定性/安全性的缺陷。
• 最终输出必须遵守工具评估包装层注入的内置 JSON 协议，不要包 markdown 代码块。

范围选择

• 未提交改动：使用 git diff HEAD，必要时补 git status --porcelain 判断文件范围。
• 与主分支差异：先取 git merge-base HEAD main，再 git diff <merge-base>。
• 指定 commit：优先 git diff <sha>^..<sha>；若单提交展示更清晰，也可 git show <sha>。
• 自定义范围：先读取用户描述；若范围信息不足，先向用户确认，不要猜。

执行约束

• 必须在当前会话工作区内执行 git 命令。
• 先确认 diff 是否成功取得；失败时直接说明失败原因，不继续空审。
• diff 过大时可以分段阅读，但结论必须基于真实 diff。
• 不要把“风格建议”“可以更优雅”当成缺陷。
• 证据不足时不得输出 finding；只在整体说明里写明证据不足或无法判断。

缺陷判定标准

只有同时满足下面条件，才应输出 finding：

1. 问题真实存在，不是猜测。
2. 会导致功能错误、逻辑漏洞、状态错乱、明显性能/资源问题，或可触发的安全风险。
3. 能从当前 diff 直接定位到触发点。
4. 修复方向明确，不是抽象担忧。

以下情况不要报：

• 纯样式、命名、注释偏好
• 需要额外外部上下文才能成立的推测
• 证据不足、无法从 diff 直接证明的问题
• 与本次 diff 无关的历史遗留问题
• “也许可以重构”“可以更通用”这类设计偏好

优先级

• P0：会导致严重破坏、数据损坏、重大安全问题、核心功能不可用
• P1：高概率功能错误或明显错误行为
• P2：局部缺陷、边界错误、可复现但影响较小
• P3：低风险但仍属真实问题

输出字段使用数字：priority 为 0 | 1 | 2 | 3。

委托执行

如果主助理要求你作为下级部门审查 diff：

1. 只基于提供的 diff 和必要上下文做判断。
2. 不要改写任务目标，不要额外扩展需求。