用途：审查分支、PR、提交范围或工作区改动。核心是使用 review_run 冻结单一审查目标，并分别运行 Standards 与 Spec 任务，结果分开呈现。若 review_run 不可用，应报告该工作流不可用，不要用 agent_run 或通用智能体替代。
流程：一、确定 Review Target，先定位前后状态。分支或标签以来的已提交改动，用 git merge-base <fixed-point> HEAD 求合并基点，将完整提交作为 committed.from，HEAD 作为 committed.to；若给出两个明确端点，各自解析后传入。含暂存、未暂存或未忽略未跟踪文件时用 workingTree.from，分支工作用合并基点，仅进行中改动用 HEAD。状态审计用 mode: "state" 并省略 from。端点和范围必须解析为提交，不要把 Git 范围语法传给 review_run；既非状态审计也非进行中审查且无固定基点时，应询问用户。
二、确定 Spec 来源，按顺序查找：提交信息中的 issue 引用（有仓库 issue 工作流则用）；用户提供的路径或 issue；docs/、specs/ 或 .scratch/ 下与分支或改动匹配的规格；都没有时询问用户；确认无 Spec 则省略 spec 任务并在报告中说明。每个权威来源记录为 criteriaSources 项。
三、确定 Standards 来源：仓库说明文件、贡献指南、编码规范和相关包级指南。审查者不接收环境上下文文件，须把必要规则放入任务说明或在 criteriaSources 中指明仓库文件。以下气味基线作为建议性标准，仓库明文规则优先，每条匹配按判断而非硬性违规报告，自动化工具已覆盖的检查跳过：神秘命名、重复代码、依恋情结、数据泥团、基本类型偏执、重复 switch、散弹式修改、发散式变化、夸夸其谈通用性、消息链、中间人、被拒绝的遗赠。
四、运行审查：创建一次 review_run 调用，最多两个任务，standards 传适用 Standards 来源与气味基线，spec 传权威 Spec 来源与需求摘要。前后对比用 mode: "change"，仅当用户要求评估后状态且不追溯变化时用 mode: "state"。任务说明须自包含，sharedContext 只放对所有任务都适用的上下文，顶层路径仅作建议性关注点。
五、报告结果：按任务顺序分别呈现 ## Standards 与 ## Spec，不合并、不跨任务重排发现。若存在 Review Output Artifact，先调用 review_output 读取剩余页面再出最终报告。每个任务结尾给出发现数量与最严重问题；若有 Post-Review Policy，在报告后执行，用户对发现的直接指示可覆盖该策略。限制：端点必须解析为提交，不传 Git 范围语法；review_run 不可用时该工作流不可用。