用途：在 ship 云代理推送分支之后、打开任何拉取请求之前，对草稿工作进行对抗式审查；只有本轮审查干净后才允许开 PR。
执行方式：由项目 crewmate 启动一个全新的子代理，不得复用旧的审查子代理。子代理从空白开始，派发信息必须包含仓库、源码控制 CLI、分支、基线和完整提示词。子代理看不到云代理 VM，只能在共享的 Grok Bot 计算机上通过项目记录的源码控制 CLI（gh、glab 或记录的 forge）或 git 读取分支。
审查范围：基线与推送末端之间的分支变更。任务要求自行阅读相关历史与 diff，聚焦变更代码引入的风险，必要时检查周边代码、调用点、共享辅助函数、测试与不变量以理解根因；审查期间不运行测试。分析缺陷、风险与代码简化机会，简化指通过非功能性重构降低复杂度，不是删功能或改产品行为。安全、性能回退、破坏性变更与错误处理不足都视为风险。必须完成完整一轮再返回，不能发现第一个有效问题就停止。
规则：发现尽量锚定到变更代码的具体文件与从 1 开始的行号；severity 为 error 时不得合并，warning 可作为后续项，info 为可选；简洁可执行，不给“多加测试”这类泛泛建议；不报告样式、格式、lint、编译或类型检查问题；若变更干净则返回空 findings 数组。每条发现需设置 action：ask-user（功能需求、产品行为或作者有意意图，拿不准就用它）、auto-fix（非功能性、用户不可见，如正确性、错误处理、安全、性能、机械质量，无需讨论意图即可修复）、no-op（信息性）。所有发现之后给出风险评级：low 表示边界清晰直接，medium 表示有改进空间但可先提出，high 表示未经明确人工批准不应提出。返回 JSON，包含 findings 数组（severity、action、file、line、description）以及 risk_level 与 risk_rationale。
循环：auto-fix 时回复同一云代理，然后启动新的审查子代理；ask-user 时由 Firstmate 向 captain 提交一张决策卡，不得提出；error 时不得提出。空发现、仅 info 或已答复的 ask-user 时，crewmate 可以打开拉取请求。采用 fix-forward，不得回退作者有意的首次提交来消除发现。禁止为了审查可见而开 PR，禁止在 scout 任务上运行。