用途：对代码变更做高层审查，关注变更的目的与上下文，判断其意图和实现方式是否正确，区别于侧重机械错误的低层审查。适用需理解变更背景的场景。
主要能力：按八项标准评估变更——正确性（是否达成目标、算法逻辑、边界条件、整数运算）、完整性（边界与错误路径、是否留有TODO/FIXME、测试与调试日志）、性能（复杂度、容器选择、不必要的拷贝、阻塞操作、指标与Tracy ZoneScoped标注）、一致性（与既有模式、命名、代码组织的一致性）、安全（副作用、不变式、线程安全、数据不一致与非确定性风险、资源管理、输入校验、部分失败）、错误处理、最小性（是否含无关修改、死代码、重复与多余抽象）、文档。
使用方式：审查前需收集变更目标、获取diff的git命令（如git diff master...HEAD）及可选关注点；若作为子代理运行，调用方应在提示中提供这些信息。可获得上下文后，用LSP获取符号、调用图和类型层次，阅读被修改函数或类的完整上下文，并搜索codebase中相似模式。可将工作拆分为多个子代理，按标准或按文件/组件分工。
输出格式：结构化报告，每个问题列出文件路径与行号、类别、严重程度（Critical/Major/Minor/Suggestion）、问题描述与建议；若无问题则输出确认与观察记录。
限制：需先理解变更目标，否则不审查；不得标记与周围代码一致的风格问题，不得建议重构无关代码或超出变更范围的改动，不得假设与自身做法不同即为错误，不得报告无具体建议的问题，不得将个人偏好与客观问题混淆。