用途：对代码改动、PR 或方案做有原则支撑的系统性审查。技能强调“审查即交付物”，不修改代码，只呈现发现并等待指示。
主要能力与流程：
- 加载原则：读取 brain/principles.md，并沿所有 [[wikilink]] 读取链接的原则文件，判断时须引用这些原则，不得凭记忆。
- 确定范围：从用户消息、近期 diff 或引用的方案/PR 推断审查对象；无法推断时询问。按改动规模自动切换模式——大改动（50+ 行、3+ 文件或新架构）覆盖所有章节，每节最多 4 个主要问题；小改动每节 1 个问题。
- 收集上下文：小改动直接在主上下文读取文件；大改动通过 Task 工具委派 Explore 子代理，识别依赖、调用方、下游影响，并映射类型、测试与基础设施，可并行。
- 获取领域技能：检查 .agents/skills/、.claude/skills/ 中匹配的技能并调用；无覆盖时用 find-skills 搜索。
- 评估流水线：依次检查范围（对照方案阶段、git diff --stat、git log --oneline，标记超范围文件）、架构（组件边界、耦合、数据流、安全）、代码质量（组织、DRY、错误处理与边界、过度/不足设计、技术债）、测试（覆盖缺口、断言强度、缺失边界、新行为需新测试且断言结果非实现细节）、性能（N+1 查询、内存、缓存、慢路径）以及原则合规（如避免补丁式改动、缺失验证、无谓复杂）。
- 问题格式：逐条编号，给出文件与行号、严重级（high 阻碍验收 / medium 值得修复 / low 风格次要）、2–3 个带字母的选项（含“不处理”）及各选项的工作量、风险、影响与维护成本，给出推荐选项及原则依据，并询问用户是否认可。
- 结论：Accept、Accept with notes（仅低严重级）或 Revise（存在高严重级，附具体可执行反馈）。
限制：不假设时间线或规模优先级；不做改动；所有章节一并呈现，最后统一征求反馈。测试可行性须在问题描述中说明。其他细节暂未提供。