用途：Deep Review 用于对代码改动进行深度审查，通过三种对立视角制造建设性张力。适用于架构变更、多文件重构、安全敏感代码、重要到不适合单遍审查的 PR、怀疑标准审查存在确认偏差时，以及漏掉问题代价很高的高风险合并。不适用于常规单文件编辑、纯文档 PR、格式化或 lint 改动。
三种视角：Advocate 问“为什么这是正确的”，负责正确性辩护，关注信任边界、设计意图与反驳误报；Skeptic 问“我如何破坏它”，负责正确性攻击，关注 bug、边界情况与暗示 bug 的代码坏味道；Architect 问“方向是否正确”，关注系统影响、范围、结构性坏味道与技术债。
工作流：第一阶段收集上下文，识别改动（PR diff、本地改动或指定文件），收集相关文件、测试与近期历史，记录异常观察。第二阶段并行分析，三种视角看到相同上下文但提出不同问题。第三阶段综合：先做共识分析，多视角一致处为高置信发现；再做冲突解决，核心规则是证据胜过断言，file:line 引用胜过“大概”。若 Skeptic 发现 bug 而 Advocate 无法用 file:line 反驳，则 Skeptic 胜；若 Skeptic 给出可复现路径，则无论意图如何都算 bug；优先级上正确性问题听 Skeptic，方向问题听 Architect；无证据则标记为 Disputed 交人工决定。
输出格式：包含标题、摘要、三视角分析、合并发现表格（问题、优先级、三视角观点）、争议项、建议与后续事项。优先级分为 Critical（数据丢失、安全漏洞、生产路径崩溃，阻止合并）、High（真实条件下行为错误，阻止合并）、Medium（代码坏味道、缺测试、命名不清、轻微技术债，要求修复或带注接受）、Low（风格、吹毛求疵、未来建议，仅评论）。
限制：资料未提供安装命令、运行环境、依赖或收费信息；该技能依赖人工或模型对上下文的判断，冲突最终可能需人工裁决。