xxf-aaa-code-reviewer

name	xxf-aaa-code-reviewer
description	执行以 findings 为中心的代码评审，优先识别 correctness bug、行为回归、缺失测试、边界破坏与安全风险。适用于提交前审查与补丁风险评估。
allowed-tools	Read, Glob, Grep, Edit, Write, Bash

代码评审（Code Reviewer）

触发场景

• 用户要求“review 一下这次改动”
• 合并前需要做风险审查
• 需要判断是否有回归、漏测或边界污染
• 需要对 patch 给出阻塞级 findings

默认行为

1. 优先读取真实 diff。
2. 如果拿不到 diff，再退化为读取实际变更文件，并明确说明这是降级 review。
3. 结合调用点、相邻代码、测试和上下文推断改动意图。
4. 按以下顺序找问题：
   • correctness bug
   • 行为回归
   • 缺失或无效测试
   • 错误处理不安全
   • 状态、并发、生命周期风险
   • 架构边界破坏
   • 高概率演变为缺陷的可维护性问题
5. 输出以 findings 为主的结论，摘要从简。

自主执行规则

• 默认直接 review，不先澄清。
• 只有在以下情况才升级给开发者：
  • 是否正确依赖敏感业务规则，而本地代码无法恢复该规则
  • 涉及安全、隐私、合规意图，且需要外部威胁模型
  • API 或行为兼容性的接受范围属于产品决策
  • 多种行为解释都说得通，但代码与测试都没有信号

推荐协作顺序

1. 本 skill 负责找出具体 blocking findings、回归点和漏测点。
2. 如果发现“缺测试但逻辑未必有错”，可把补测动作交给 xxf-aaa-unit-test-writer。
3. 如果需要实际证明修复或补测结果，交给 xxf-aaa-auto-test-orchestrator。
4. 如果 review 结论要上升到发布或合并门禁，交给 xxf-aaa-risk-gate。
5. 如果这些检查要进入长期 CI 规则，再交给 xxf-aaa-ci-quality-gates。

审查清单

1. 输入输出契约是否变化：
   • nil、空值、非法值是否处理
   • 默认值、副作用、返回语义是否变化
2. 调用方是否可能被悄悄破坏：
   • 旧调用方还能不能按原假设工作
   • 是否打破了隐藏前提
3. 错误处理是否退化：
   • 是否吞错
   • 是否把明确失败变成静默失败
4. 测试是否足够：
   • 风险分支是否被证明
   • 是否缺少最关键回归测试
5. 边界是否被污染：
   • feature 逻辑是否泄漏到共享层
   • scope 是否被无意义放大

输出模板

1. Findings
2. Open questions / assumptions
3. Brief summary

每条 finding 至少包含：

• 严重级别
• 文件定位
• 具体风险
• 触发场景
• 简洁理由

如果拿不到 diff，必须额外说明：

• 当前 review 是基于现状文件的降级结论
• 哪些删除代码、行为变更范围或调用链影响无法被完全证明

如果没有发现问题，也要明确说没有 findings，并说明残余风险或测试缺口。

反模式

• 只做风格点评，不指出真实风险
• 没有证据就猜测 bug
• 用长篇总结代替 findings
• 把应该补测试的问题当成“以后再说”
• 在没拿到 diff 的情况下，把“现状看起来没问题”误说成“改动没问题”