用途：对 PR、提交范围或未提交改动做代码审查，输出一份简短、高置信度的问题清单，每条问题都是资深工程师会为之阻止合并的级别。审查围绕三个问题展开：代码是否清晰实现其声称的行为；有哪些内容可以删除、合并或重构掉；有哪些边界情况被遗漏。原则是精确优先于覆盖，每条细枝末节的挑剔都会消耗真正问题所需的信任。
主要能力与硬性规则：只输出高置信度问题——一条问题只有在独立校验器尝试反驳且未能反驳后才发布，“可能有问题”不算问题。它不做 linter，编译器、类型检查器、格式化器或 linter 能发现的问题，以及命名偏好、排序、措辞等品味问题一律不出。倾向删除与合并，但不越过必需行为。全程只读，绝不编辑、暂存、提交或以其他方式改动工作树；修复是报告之后单独且经批准的步骤。子代理自行获取事实，派发时只带指针：brief 路径、BASE SHA、带未跟踪文件列表的 diff 命令，以及查找器的视角或校验器的单个候选（file:line 与查找器原话表述的主张），不加入评分标准文本、对 diff 的转述或对某条问题的辩护。
流程：第一步确定 diff 范围，从参数中固定一个 BASE SHA 和一个 diff 命令，覆盖 PR、提交范围/分支对 main、未提交改动三种形态；用 git log <BASE>..HEAD --oneline 取一次提交列表。第二步查找，按视角生成标准层级的查找器，默认视角为正确性与契约、简洁性与删除。第三步校验，为每个候选生成校验器，分波启动，仅代码依据充分的 CONFIRMED 才保留。第四步与既往评审对账：走查提交列表标记振荡（新 diff 反转近期提交），并用 git show <sha> 读取两个提交确认；PR 目标下读取既往评审，按 resolved/unresolved 处置每条线程，已解决则关闭并丢弃被其覆盖的残留问题，未解决则丢弃与之呼应的残留问题，唯一例外是当前 diff 仍未解决的严重或阻塞评论。第五步按固定结构输出报告：Review — <target>，Findings 按严重度排序，Oscillation 列出反转，Refuted 列出被校验或 PR 线程移除的项，最后建议运行 /crank plan 把残留问题转成修复计划。
适用场景：需要高质量、低噪音的合并前审查，尤其是 PR、提交区间或带未提交改动的工作分支。限制：只读不修复；不出 linter 级或品味类问题；校验依赖独立上下文，小 diff 也需派发子代理；未提供的部署方式、收费、价格、平台支持等信息暂未提供。