用途：对方案或代码变更做深入、交互式的审查，审查结果本身就是交付物，技能明确要求不直接改动代码。触发词包括 review 等。
主要能力：按四个部分组织审查——架构（系统设计与组件边界、依赖与耦合、数据流与瓶颈、扩展性与单点故障、安全架构）、代码质量（模块结构、DRY 违规、错误处理与边界情况、技术债、过度或不足设计）、测试（覆盖率缺口、断言强度、边界用例、未测试的失败路径）、性能（N+1 查询、内存、缓存机会、慢路径）。每个问题编号，给出 2–3 个带字母的选项（含“不做处理”），并说明实现成本、风险、对其他代码的影响与维护负担，最后给出推荐选项及理由。
使用方式：先读取 brain/principles.md 并跟进其中的 [[wikilink]] 原则文件；再从上下文推断审查范围，按变更规模自动选择模式（50 行以上、3 个以上文件或新架构为大变更，每部分最多 4 个问题；否则每部分 1 个问题）；小变更直接在主上下文读文件，大变更用 Task 工具派 Explore 子代理并行探查依赖、调用方、类型与测试；随后检查 .claude/skills/ 中匹配领域的技能（如前端 UI 对应 frontend-design、Codex 委派对应 codex），未列出领域用 find-skills 搜索。用 TaskCreate/TaskUpdate/TaskList 跟踪各步骤进度。
自主会话模式：在非交互式 Noodle 执行会话（如 Cook、Oops、Repair）中不使用 AskUserQuestion，直接给出推荐动作；把结论写入 brain/audits/review-<date>-<subject>.md，高严重度问题用 /todo 技能记入 brain/todos.md，低严重度只写报告；最后提交审查报告，不等待指示。
限制：不修改代码，只呈现发现并等待方向；不假设时间线或规模优先级；所有部分一次性呈现，最后统一征求反馈；若确实无法从上下文推断审查对象则询问。资料未提供安装命令、收费与平台信息。