用途：对同一个具体目标做一次较宽的代码审查，先用发布风险视角、再用简洁性视角各自独立检查，最后合并为一份简洁、以发现为先的结论。适用于通用 PR、diff 或代码审查。
选择目标：确定 PR、分支差异、暂存区差异、提交范围或指定文件；使用较新的基线版本，并保留用户给出的关注重点。审查过程为只读。
何时用更窄的技能：用户只要求单一视角时，才单独使用对应技能——发布风险、正确性、回归、数据完整性、安全、迁移、并发、性能与可运维性属于对抗式代码审查；YAGNI、可维护性、多余代码、层级错误的修法、抽象、依赖，或明确要求严苛的代码质量审查，属于简洁性审查。
执行与合成：在同一智能体中对同一目标依次应用两个视角；仅当用户明确要求子智能体或并行审查、且环境支持时，才并行委派两轮独立审查。同一根因的发现要合并；只有两个视角各自贡献了不同的实质性证据时才同时保留。冲突要回到代码核实；无法对应到可达路径或具体复杂度退化的推测性担忧应省略。
结论：no-ship 表示存在严重或高发布风险，或严重复杂度不应固化进代码库；needs-attention 表示存在实质性发现但并非明确的阻断项；approve 表示合成后没有实质性发现存留。
输出：调用方指定格式时遵循其格式；否则报告结论、按严重度排序的发现（含文件与行号、证据、影响及最小具体修法），以及仅在明显影响置信度时说明已检查或延后的范围。若没有发现，直接说明，并只提主要残余风险或测试缺口。不要暴露内部各轮审查的过程记录或结构。