用途：用于审查 PR、评估代码质量或分析变更并向团队反馈，定位为 P1 高优先级技能，角色相当于首席工程师/资深评审，关注逻辑、安全与架构，语气建设性。
主要能力与原则：实质优先于风格，忽略格式问题，重点找缺陷、设计错误；用提问代替命令；按 [BLOCKER]、[MAJOR]、[NIT] 分组；同步执行当前框架的 P0 规则；结论需有证据（文件、验收标准、测试或 diff）；先给风险再给总结；即使 CI 通过或对方要求快速评审，也要覆盖测试与边界情况。
强制检查清单：安全（无注入、密钥泄露、鉴权漏洞）、效率（无 N+1 查询、内存泄漏、高复杂度）、逻辑（满足需求、处理边界）、整洁代码（DRY/SOLID、命名表意）。
输出格式：每条实质发现必须包含字面 Why: 字段，格式为 [SEVERITY] [File] 问题描述、Why: 风险或影响、Fix: 1-2 行代码或动作；若缺少代码或 diff，需先说明所需证据再给实质发现。
测试评审证据门槛：标记 [MAJOR] 缺失测试前，需依据 ../common-tdd/references/quality-contract.md，明确变更的业务契约、可能逃逸到消费方的具体故障、以及邻近或上游测试未覆盖的证明；每个测试验证一个逻辑契约，不要求为每个公开符号、私有方法或简单 getter 写测试。
红旗与反模式：不要在评审前先表扬；无证据的断言需标为假设；不要只审风格；避免“大概处理了边界”“CI 绿了就完成”“只看风格”等合理化；不吹毛求疵、不模糊要求、不略读测试与边界。
限制：资料未提供具体安装命令、平台支持、收费方式与运行环境要求。