ce:review

代码审查

使用动态选定的审查者角色审查代码变更。并行启动多个子 Agent，让它们返回结构化 JSON，然后合并并去重所有发现，生成一份报告。

适用场景

• 创建 PR 前
• 迭代实现过程中完成一项任务后
• 需要针对任何代码变更获取反馈时
• 可单独调用
• 可在更大型的工作流中作为只读审查步骤或自动修复步骤运行

参数解析

解析 $ARGUMENTS 中的以下可选标记。在将剩余内容解释为 PR 编号、GitHub URL 或分支名称之前，先移除所有已识别的标记。

标记	示例	效果
mode:autofix	mode:autofix	选择自动修复模式（参见下方的模式检测）
mode:report-only	mode:report-only	选择仅报告模式
mode:headless	mode:headless	为程序化调用方选择无交互模式（参见下方的模式检测）
base:<sha-or-ref>	base:abc1234 或 base:origin/main	跳过范围检测，直接将其用作 diff 基准
plan:<path>	plan:docs/plans/2026-03-25-001-feat-foo-plan.md	加载此计划，用于验证需求

所有标记均为可选项。每提供一个标记，就少一项内容需要推断。未提供时，该阶段沿用现有行为。

冲突的模式标记： 如果参数中出现多个模式标记，立即停止，不要分派 Agent。如果冲突的标记中包含 mode:headless，则输出无交互错误封装：Review failed (headless mode). Reason: conflicting mode flags — <mode_a> and <mode_b> cannot be combined. 否则输出通用格式：Review failed. Reason: conflicting mode flags — <mode_a> and <mode_b> cannot be combined.

模式检测

模式	适用情况	行为
交互式（默认）	未提供模式标记	执行审查，自动应用 safe_auto 修复，展示发现，针对需要策略决策的受限／手动处理项征求意见，并可选择继续执行修复、推送或创建 PR 等后续步骤
自动修复	参数中包含 mode:autofix	不与用户交互。执行审查，仅应用策略允许的 safe_auto 修复，在有限轮次内重新审查，写入运行产物，并在需要时输出剩余的下游工作
仅报告	参数中包含 mode:report-only	严格只读。仅执行审查并报告，然后停止；不进行编辑，不创建产物或待办事项，也不执行提交、推送或 PR 操作
无交互	参数中包含 mode:headless	用于技能间调用的程序化模式。静默应用 safe_auto 修复（单轮），将其他所有发现作为结构化文本输出，写入运行产物，跳过待办事项，并返回“Review complete”信号。不显示交互式提示。

自动修复模式规则

• 跳过所有用户提问。 确定范围后，绝不暂停以请求批准或澄清。
• 仅应用 safe_auto -> review-fixer 发现。 将 gated_auto、manual、human 和 release 工作保留为未解决状态。
• 在 .context/compound-engineering/ce-review/<run-id>/ 下写入运行产物，总结发现、已应用的修复、剩余的可操作工作和建议输出。
• 仅针对最终所有者为 downstream-resolver 的未解决可操作发现，创建持久待办文件。 加载 todo-create 技能，以获取规范目录路径和命名约定。
• 自动修复模式下绝不提交、推送或创建 PR。 这些决策由父工作流负责。

仅报告模式规则

• 跳过所有用户问题。 如果差异元数据不够充分，请保守推断意图。
• 绝不编辑文件或将工作外置。 不要写入 .context/compound-engineering/ce-review/<run-id>/，不要创建待办文件，也不要提交、推送或创建 PR。
• 可安全地并行进行只读验证。 mode:report-only 是唯一可以与浏览器测试在同一检出目录中并发运行的模式。
• 不要切换共享检出目录。 如果调用方传入了明确的 PR 或分支目标，mode:report-only 必须在隔离的检出目录/工作树中运行，否则应停止，而不是运行 gh pr checkout / git checkout。
• 不要在同一检出目录中并发执行会修改内容的审查和浏览器测试。 如果后续编排器需要修复，请在浏览器测试后执行会修改内容的审查阶段，或在隔离的检出目录/工作树中执行。

无头模式规则

• 跳过所有用户问题。 绝不使用平台提问工具（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）或其他交互式提示。如果差异元数据不够充分，请保守推断意图。
• 必须能确定差异范围。 如果无头模式无法确定差异范围（无需用户交互即可确定分支、PR 或 base: 引用），则输出 Review failed (headless mode). Reason: no diff scope detected. Re-invoke with a branch name, PR number, or base:<ref>. 并停止，不要分派 Agent。
• 仅在单轮中应用 safe_auto -> review-fixer 发现的问题。 不进行有界的复审轮次。让 gated_auto、manual、human 和 release 工作保持未解决状态，并在结构化输出中返回。
• 以结构化文本输出返回所有非自动修复发现的问题。 使用无头输出封装格式（见下文第 6 阶段），保留每个问题的 severity、autofix_class、owner、requires_verification、confidence、pre_existing 和 suggested_fix。根据磁盘上的 Agent 产物文件补充 detail-tier 字段（why_it_matters、evidence[]）（见第 6 阶段的详细信息补充）。
• 写入运行产物，保存到 .context/compound-engineering/ce-review/<run-id>/，总结发现的问题、已应用的修复和建议输出。在结构化输出中包含产物路径。
• 不要创建待办文件。 调用方会收到结构化发现结果，并自行将其分派给下游工作。
• 不要切换共享检出目录。 如果调用方传入了明确的 PR 或分支目标，mode:headless 必须在隔离的检出目录/工作树中运行，否则应停止，而不是运行 gh pr checkout / git checkout。停止时，输出 Review failed (headless mode). Reason: cannot switch shared checkout. Re-invoke with base:<ref> to review the current checkout, or run from an isolated worktree.
• 不适合在共享检出目录中并发使用。 与 mode:report-only 不同，无头模式会修改文件（应用 safe_auto 修复）。调用方不得在同一检出目录中并发运行无头模式和其他会修改内容的操作。
• 无头模式绝不提交、推送或创建 PR。 这些决定由调用方负责。
• 以 "Review complete" 作为终止信号。 如果所有审查器都失败或超时，则输出 Code review degraded (headless mode). Reason: 0 of N reviewers returned results.，然后输出 "Review complete"。

严重性等级

所有审查器均使用 P0-P3：

等级	含义	操作
P0	严重故障、可利用的漏洞、数据丢失/损坏	合并前必须修复
P1	影响重大、可能在正常使用中触发的缺陷，或违反契约	应修复
P2	有明显负面影响的中等问题（边缘情况、性能回退、可维护性陷阱）	如果修复直接明了，则应修复
P3	影响较小、范围有限的小幅改进	由用户决定

操作路由

严重性回答的是紧急程度。路由回答的是下一步由谁采取行动，以及此技能是否可以修改检出内容。

autofix_class	默认负责人	含义
safe_auto	review-fixer	本地、确定性的修复；当当前模式允许修改时，适合由技能内修复器处理
gated_auto	downstream-resolver 或 human	存在明确的修复方案，但会改变行为、契约、权限或其他敏感边界，默认不应自动应用
manual	downstream-resolver 或 human	可执行的工作，应移交处理，而不是在技能内修复
advisory	human 或 release	仅报告的输出，例如经验总结、发布说明或残余风险

路由规则：

• 综合阶段负责最终路由。 Persona 提供的路由元数据只是输入，并非最终结论。
• 发生分歧时，选择更保守的路由。 合并后的发现可以从 safe_auto 调整为 gated_auto 或 manual，但没有更有力的证据时，不得反向调整。
• 只有 safe_auto -> review-fixer 会自动进入技能内修复器队列。
• requires_verification: true 表示修复必须经过针对性测试、重点复审或运行验证才能算完成。

审查者

包含 17 种采用分层条件机制的审查者角色，以及 CE 专用 Agent。完整目录请参见下方包含的角色目录。

始终启用（每次审查）：

Agent	关注点
compound-engineering:review:correctness-reviewer	逻辑错误、边界情况、状态错误、错误传播
compound-engineering:review:testing-reviewer	覆盖率缺口、断言薄弱、脆弱的测试
compound-engineering:review:maintainability-reviewer	耦合、复杂度、命名、死代码、抽象债务
compound-engineering:review:project-standards-reviewer	是否遵循 CLAUDE.md 和 AGENTS.md —— frontmatter、引用、命名、可移植性
compound-engineering:review:agent-native-reviewer	验证新功能是否可供 Agent 使用
compound-engineering:research:learnings-researcher	搜索 docs/solutions/，查找与此 PR 相关的过往问题

跨领域条件角色（根据差异选取）：

Agent	在差异涉及以下内容时选取……
compound-engineering:review:security-reviewer	身份验证、公共端点、用户输入、权限
compound-engineering:review:performance-reviewer	数据库查询、数据转换、缓存、异步处理
compound-engineering:review:api-contract-reviewer	路由、序列化器、类型签名、版本控制
compound-engineering:review:data-migrations-reviewer	迁移、架构变更、回填
compound-engineering:review:reliability-reviewer	错误处理、重试、超时、后台任务
compound-engineering:review:adversarial-reviewer	变更行数 ≥50 行（不含测试、生成文件和锁文件），或涉及身份验证、支付、数据变更、外部 API
compound-engineering:review:cli-readiness-reviewer	CLI 命令定义、参数解析、CLI 框架使用、命令处理器实现
compound-engineering:review:previous-comments-reviewer	审查已有评审评论或讨论串的 PR

技术栈专用条件角色（根据差异选取）：

Agent	在差异涉及以下内容时选取……
compound-engineering:review:dhh-rails-reviewer	Rails 架构、服务对象、会话/身份验证方案，或 Hotwire 与 SPA 的边界
compound-engineering:review:kieran-rails-reviewer	涉及约定、命名和可维护性的 Rails 应用代码
compound-engineering:review:kieran-python-reviewer	Python 模块、端点、脚本或服务
compound-engineering:review:kieran-typescript-reviewer	TypeScript 组件、服务、钩子、工具函数或共享类型
compound-engineering:review:julik-frontend-races-reviewer	Stimulus/Turbo 控制器、DOM 事件、计时器、动画或异步 UI 流程

CE 条件角色（仅限迁移）：

Agent	在差异中包含迁移文件时选取……
compound-engineering:review:schema-drift-detector	交叉核对 schema.rb 与所含迁移
compound-engineering:review:deployment-verification-agent	生成包含 SQL 验证查询的部署检查清单

审查范围

每次审查都会启动全部 4 种始终启用的角色和 2 个 CE 始终启用的 Agent，然后根据差异添加符合条件的跨领域和技术栈专用角色。模型会自然地按需调整规模：小型配置变更不会触发任何条件角色，共有 6 名审查者；Rails 身份验证功能可能触发 security + reliability + kieran-rails + dhh-rails，共有 10 名审查者。

受保护的产物

以下路径是 compound-engineering 流水线产物，任何审查者都不得将其标记为待删除、移除或加入 gitignore：

• docs/brainstorms/* -- 由 ce:brainstorm 创建的需求文档
• docs/plans/*.md -- 由 ce:plan 创建的计划文件（带有进度复选框的持续更新文档）
• docs/solutions/*.md -- 在流水线期间创建的解决方案文档

如果审查者将这些目录中的任何文件标记为待清理或移除，请在综合审查结果时舍弃该发现。

如何运行

阶段 1：确定范围

计算差异范围、文件列表和差异内容。尽可能合并命令，以减少权限提示。

如果提供了 base: 参数（快速路径）：

调用方已知差异基准。跳过所有基准分支检测、远程解析和 merge-base 计算。直接使用提供的值：

BASE_ARG="{base_arg}"
BASE=$(git merge-base HEAD "$BASE_ARG" 2>/dev/null) || BASE="$BASE_ARG"

然后生成与其他路径相同的输出：

echo "BASE:$BASE" && echo "FILES:" && git diff --name-only $BASE && echo "DIFF:" && git diff -U10 $BASE && echo "UNTRACKED:" && git ls-files --others --exclude-standard

此路径适用于任何引用——SHA、origin/main、分支名称。自动化调用方（ce:work、lfg、slfg）应优先使用此路径，以避免检测开销。**不要将 base: 与 PR 编号或分支目标同时使用。**如果两者都存在，则报错并停止："Cannot use base: with a PR number or branch target — base: implies the current checkout is already the correct branch. Pass base: alone, or pass the target alone and let scope detection resolve the base." 这样可避免差异基准来自一个来源，而代码和元数据来自另一个来源，导致范围与意图不匹配。

如果参数中提供了 PR 编号或 GitHub URL：

如果启用了 mode:report-only 或 mode:headless，则不要在共享工作区运行 gh pr checkout <number-or-url>。对于 mode:report-only，告知调用方："mode:report-only cannot switch the shared checkout to review a PR target. Run it from an isolated worktree/checkout for that PR, or run report-only with no target argument on the already checked out branch." 对于 mode:headless，输出 Review failed (headless mode). Reason: cannot switch shared checkout. Re-invoke with base:<ref> to review the current checkout, or run from an isolated worktree. 除非审查已在隔离的检出目录中运行，否则在此处停止。

首先，确认切换分支前工作区是干净的：

git status --porcelain

如果输出不为空，告知用户："You have uncommitted changes on the current branch. Stash or commit them before reviewing a PR, or use standalone mode (no argument) to review the current branch as-is." 在工作区干净之前，不要继续检出。

然后检出 PR 分支，以便 Agent 能够读取实际代码（而非当前检出内容）：

gh pr checkout <number-or-url>

然后获取 PR 元数据。记录基准分支名称和 PR 基准仓库标识，而不只是分支名称：

gh pr view <number-or-url> --json title,body,baseRefName,headRefName,url

将返回的 PR URL 中的仓库部分用作 <base-repo>（例如，从 https://github.com/EveryInc/compound-engineering-plugin/pull/348 中获取 EveryInc/compound-engineering-plugin）。

然后针对 PR 的基准分支计算本地差异，以便重新审查时也包含本地修复提交和未提交的编辑。替换元数据中的 PR 基准分支（此处显示为 <base>）以及从 PR URL 派生的 PR 基准仓库标识（此处显示为 <base-repo>）。从 PR 的实际基准仓库解析基准引用，不要假定 origin 指向该仓库：

PR_BASE_REMOTE=$(git remote -v | awk 'index($2, "github.com:<base-repo>") || index($2, "github.com/<base-repo>") {print $1; exit}')
if [ -n "$PR_BASE_REMOTE" ]; then PR_BASE_REMOTE_REF="$PR_BASE_REMOTE/<base>"; else PR_BASE_REMOTE_REF=""; fi
PR_BASE_REF=$(git rev-parse --verify "$PR_BASE_REMOTE_REF" 2>/dev/null || git rev-parse --verify <base> 2>/dev/null || true)
if [ -z "$PR_BASE_REF" ]; then
  if [ -n "$PR_BASE_REMOTE_REF" ]; then
    git fetch --no-tags "$PR_BASE_REMOTE" <base>:refs/remotes/"$PR_BASE_REMOTE"/<base> 2>/dev/null || git fetch --no-tags "$PR_BASE_REMOTE" <base> 2>/dev/null || true
    PR_BASE_REF=$(git rev-parse --verify "$PR_BASE_REMOTE_REF" 2>/dev/null || git rev-parse --verify <base> 2>/dev/null || true)
  else
    if git fetch --no-tags https://github.com/<base-repo>.git <base> 2>/dev/null; then
      PR_BASE_REF=$(git rev-parse --verify FETCH_HEAD 2>/dev/null || true)
    fi
    if [ -z "$PR_BASE_REF" ]; then PR_BASE_REF=$(git rev-parse --verify <base> 2>/dev/null || true); fi
  fi
fi
if [ -n "$PR_BASE_REF" ]; then BASE=$(git merge-base HEAD "$PR_BASE_REF" 2>/dev/null) || BASE=""; else BASE=""; fi

if [ -n "$BASE" ]; then echo "BASE:$BASE" && echo "FILES:" && git diff --name-only $BASE && echo "DIFF:" && git diff -U10 $BASE && echo "UNTRACKED:" && git ls-files --others --exclude-standard; else echo "ERROR: Unable to resolve PR base branch <base> locally. Fetch the base branch and rerun so the review scope stays aligned with the PR."; fi

从 gh pr view 提取 PR 标题/正文、基准分支和 PR URL，然后从本地命令中提取基准标记、文件列表、差异内容和 UNTRACKED: 列表。检出后不要使用 gh pr diff 作为审查范围——它只反映远程 PR 状态，在本地修复提交推送之前会遗漏这些提交。如果尝试获取后仍无法从 PR 的实际基准仓库解析基准引用，则停止，不要回退到 git diff HEAD；缺少 PR 基准分支的 PR 审查并不完整。 如果将分支名称作为参数提供：

切换到指定分支，然后将其与基准分支进行差异比较。将提供的分支名称（此处显示为 <branch>）代入。

如果启用了 mode:report-only 或 mode:headless，请勿在共享检出目录中运行 git checkout <branch>。对于 mode:report-only，告知调用方："mode:report-only cannot switch the shared checkout to review another branch. Run it from an isolated worktree/checkout for <branch>, or run report-only on the current checkout with no target argument." 对于 mode:headless，输出 Review failed (headless mode). Reason: cannot switch shared checkout. Re-invoke with base:<ref> to review the current checkout, or run from an isolated worktree. 除非审查已在隔离检出目录中运行，否则在此停止。

首先，在切换分支前确认工作树干净：

git status --porcelain

如果输出非空，告知用户："You have uncommitted changes on the current branch. Stash or commit them before reviewing another branch, or provide a PR number instead." 在工作树干净前，不要继续切换分支。

git checkout <branch>

然后检测审查基准分支并计算合并基点。运行 references/resolve-base.sh 脚本，该脚本会通过多重回退检测安全地解析分叉仓库的远程来源（PR 元数据 -> origin/HEAD -> gh repo view -> 常见分支名称）：

RESOLVE_OUT=$(bash references/resolve-base.sh) || { echo "ERROR: resolve-base.sh failed"; exit 1; }
if [ -z "$RESOLVE_OUT" ] || echo "$RESOLVE_OUT" | grep -q '^ERROR:'; then echo "${RESOLVE_OUT:-ERROR: resolve-base.sh produced no output}"; exit 1; fi
BASE=$(echo "$RESOLVE_OUT" | sed 's/^BASE://')

如果脚本输出错误，请停止，不要回退到 git diff HEAD；没有基准分支的分支审查只会显示未提交的更改，并会悄然漏掉所有已提交的工作。

成功后，生成差异：

echo "BASE:$BASE" && echo "FILES:" && git diff --name-only $BASE && echo "DIFF:" && git diff -U10 $BASE && echo "UNTRACKED:" && git ls-files --others --exclude-standard

你仍可通过 gh pr view 获取其他 PR 元数据，例如标题、正文和关联议题；但如果不存在 PR，不要因此失败。

如果没有参数（在当前分支上独立运行）：

使用与分支模式相同的 references/resolve-base.sh 脚本检测审查基准分支并计算合并基点：

RESOLVE_OUT=$(bash references/resolve-base.sh) || { echo "ERROR: resolve-base.sh failed"; exit 1; }
if [ -z "$RESOLVE_OUT" ] || echo "$RESOLVE_OUT" | grep -q '^ERROR:'; then echo "${RESOLVE_OUT:-ERROR: resolve-base.sh produced no output}"; exit 1; fi
BASE=$(echo "$RESOLVE_OUT" | sed 's/^BASE://')

如果脚本输出错误，请停止，不要回退到 git diff HEAD；没有基准分支的独立审查只会显示未提交的更改，并会悄然漏掉分支上的所有已提交工作。

成功后，生成差异：

echo "BASE:$BASE" && echo "FILES:" && git diff --name-only $BASE && echo "DIFF:" && git diff -U10 $BASE && echo "UNTRACKED:" && git ls-files --others --exclude-standard

使用 git diff $BASE（不带 ..HEAD）会比较合并基点与工作树，其中会一并包含已提交、已暂存和未暂存的更改。

未跟踪文件处理： 始终检查 UNTRACKED: 列表，即使 FILES:/DIFF: 非空也是如此。未跟踪文件在暂存前不属于审查范围。如果列表非空，告知用户哪些文件被排除。如果其中任何文件需要审查，请停止并告知用户先运行 git add，然后重新运行。只有当用户明确只审查已跟踪的更改时，才继续。在 mode:headless 或 mode:autofix 下，不要停下来询问——仅处理已跟踪的更改，并在输出的 Coverage 部分注明被排除的未跟踪文件。

阶段 2：意图发现

了解此次更改旨在实现什么。意图来源取决于阶段 1 采用的路径：

PR/URL 模式： 使用 gh pr view 元数据中的 PR 标题、正文和关联议题。如果正文内容较少，则参考 PR 中的提交消息。

分支模式： 使用阶段 1 中解析出的合并基点运行 git log --oneline ${BASE}..<branch>。

独立模式（当前分支）： 运行：

echo "BRANCH:" && git rev-parse --abbrev-ref HEAD && echo "COMMITS:" && git log --oneline ${BASE}..HEAD

结合对话上下文（计划章节摘要、PR 描述），撰写 2-3 行意图摘要：

Intent: Simplify tax calculation by replacing the multi-tier rate lookup
with a flat-rate computation. Must not regress edge cases in tax-exempt handling.

在生成提示词时，将此摘要传递给每位审查者。意图会影响每位审查者审查的力度，而非决定选择哪些审查者。

意图不明确时：

• 交互模式： 使用平台的交互式提问工具提一个问题（Claude Code 中使用 AskUserQuestion，Codex 中使用 request_user_input）：“这些更改的主要目标是什么？”在明确意图之前，不要启动审查者。
• 自动修复／仅报告／无头模式： 根据分支名称、差异、PR 元数据和调用方上下文，谨慎推断意图。在 Coverage 或 Verdict 的推理中注明不确定性，不要因此阻塞流程。

阶段 2b：计划发现（需求验证）

定位计划文档，以便阶段 6 验证需求是否完整。按以下优先顺序检查这些来源，找到首个匹配项后停止：

1. plan: 参数。 如果调用方传入了计划路径，直接使用该路径。读取文件以确认其存在。
2. PR 正文。 如果阶段 1 已获取 PR 元数据，扫描正文，查找匹配 docs/plans/*.md 的路径。如果找到且仅找到一个匹配项，并且文件存在，则将其用作 plan_source: explicit。如果出现多个计划路径，则视为有歧义：将其降级为 plan_source: inferred，选择磁盘上存在的最新匹配项；如果没有匹配项，或没有任何匹配项明显与 PR 标题／意图相关，则跳过。使用前务必确认所选文件存在；PR 描述中常有过期或复制而来的计划链接。
3. 自动发现。 从分支名称中提取 2-3 个关键词（例如，feat/onboarding-skill -> onboarding、skill）。对 docs/plans/* 执行 Glob，并筛选文件名中包含这些关键词的文件。如果恰好有一个匹配项，则使用它。如果有多个匹配项，或匹配结果看起来有歧义（例如 review、fix、update 等可能匹配多个计划的通用关键词），则跳过自动发现——选错计划比没有计划更糟。如果没有匹配项，则跳过。

置信度标记： 记录计划的发现方式：

• plan: 参数 -> plan_source: explicit（高置信度）
• PR 正文中单个且明确无歧义的匹配项 -> plan_source: explicit（高置信度）
• PR 正文中多个／有歧义的匹配项 -> plan_source: inferred（较低置信度）
• 自动发现中单个且明确无歧义的匹配项 -> plan_source: inferred（较低置信度）

如果找到计划，读取其中的需求追踪（R1、R2 等）和实现单元（复选框条目）。保存提取出的需求列表和 plan_source，供阶段 6 使用。如果未找到计划，不要阻塞审查——需求验证是附加项，并非必需。

阶段 3：选择审查者

阅读阶段 1 中的差异和文件列表。4 个始终启用的角色和 2 个 CE 始终启用的 Agent 会自动参与。对于下方角色目录中的每个跨领域和特定技术栈的条件角色，判断差异是否需要它参与。这需要 Agent 作出判断，而不是进行关键词匹配。

**选择条件角色时考虑文件类型：**说明性文本文件（Markdown 技能定义、JSON 架构、配置文件）属于产品代码，但不适合由侧重运行时的审查者审查。对抗式审查者使用的技术（竞态条件、级联故障、滥用场景）针对的是可执行代码的行为。对于仅更改说明性文本文件的差异，跳过对抗式审查者，除非文本描述了身份验证、支付或数据变更行为。计算行数阈值时，只计入可执行代码行。

previous-comments 仅适用于 PR。 仅当阶段 1 收集了 PR 元数据（作为参数提供了 PR 编号或 URL，或者 gh pr view 返回了当前分支的元数据）时，才选择此角色。对于没有关联 PR 的独立分支审查，完全跳过此角色——无需检查之前的评论。

特定技术栈的角色可叠加。Rails UI 变更可能需要 kieran-rails 和 julik-frontend-races；TypeScript API 差异可能需要 kieran-typescript、api-contract 和 reliability。

对于 CE 条件 Agent，检查差异是否包含与 db/migrate/*.rb、db/schema.rb 或数据回填脚本匹配的文件。

启动子 Agent 前，先宣布团队：

Review team:
- correctness (always)
- testing (always)
- maintainability (always)
- project-standards (always)
- agent-native-reviewer (always)
- learnings-researcher (always)
- security -- new endpoint in routes.rb accepts user-provided redirect URL
- kieran-rails -- controller and Turbo flow changed in app/controllers and app/views
- dhh-rails -- diff adds service objects around ordinary Rails CRUD
- data-migrations -- adds migration 20260303_add_index_to_orders
- schema-drift-detector -- migration files present

这是进度报告，不是需要等待确认的请求。

阶段 3b：发现项目规范文件路径

启动子 Agent 前，查找 project-standards 角色相关规范文件的路径（而非内容）。使用原生文件搜索／glob 工具定位：

1. 使用原生文件搜索工具（例如 Claude Code 中的 Glob），查找仓库中所有 **/CLAUDE.md 和 **/AGENTS.md。
2. 筛选其所在目录是至少一个已更改文件的祖先目录的文件。规范文件适用于其目录下的所有文件（例如，plugins/compound-engineering/AGENTS.md 适用于 plugins/compound-engineering/ 下的所有内容）。

将得到的路径列表放入 project-standards 角色审查上下文中的 <standards-paths> 块内（见阶段 4）。该角色会自行读取文件，仅关注与已更改文件类型相关的章节。这样可以减少协调器的工作量（只需发现路径），并避免在子 Agent 提示词中塞入审查者可能不需要的内容。

阶段 4：启动子 Agent

模型分级

角色子 Agent 执行范围明确的专项工作，应使用快速的中端模型，以降低成本和延迟，同时不牺牲审查质量。协调器本身继续使用默认（能力最强）模型。

所有角色和 CE 子 Agent 均使用平台的中端模型。在 Claude Code 中，在 Agent 工具调用中传入 model: "sonnet"。在其他平台上，使用对应的中端模型（例如 Codex 中的 gpt-4o）。如果平台不支持模型覆盖机制，或可用模型名称未知，则省略模型参数，让 Agent 继承默认模型——使用父级模型完成审查，总比因模型名称不受识别而导致任务无法派发要好。

CE 始终启用的 Agent（agent-native-reviewer、learnings-researcher）和 CE 条件 Agent（schema-drift-detector、deployment-verification-agent）也使用中端模型，因为它们执行的是范围明确的专项工作。

协调器（即此技能）继续使用默认模型，因为它负责发现意图、选择审查者、合并和去重问题，以及综合审查结果——这些任务都受益于更强的推理能力。

运行 ID

派发任何 Agent 之前，先生成唯一的运行标识符。该 ID 用于将所有 Agent 产物文件和审查后的运行产物限定在同一目录中。

RUN_ID=$(date +%Y%m%d-%H%M%S)-$(head -c4 /dev/urandom | od -An -tx1 | tr -d ' ')
mkdir -p ".context/compound-engineering/ce-review/$RUN_ID"

将 {run_id} 传递给每个角色子 Agent，以便它们将完整分析写入 .context/compound-engineering/ce-review/{run_id}/{reviewer_name}.json。

**仅报告模式：**跳过运行 ID 生成和目录创建。不要向 Agent 传递 {run_id}。Agent 仅返回精简 JSON，不写入文件，遵循仅报告模式不写入的约定。

派发

派发子 Agent 时省略 mode 参数，以应用用户配置的权限设置。不要传递 mode: "auto"。

使用下方的子 Agent 模板，将每位选定的角色审查者作为并行子 Agent 派发。每位角色子 Agent 会收到：

1. 其角色文件内容（身份、故障模式、校准方式、抑制条件）
2. 下方差异范围参考中列出的共享差异范围规则
3. 下方发现项架构中列出的 JSON 输出约定
4. PR 元数据：审查 PR 时提供标题、正文和 URL；否则为空字符串。将其放入 <pr-context> 块中，以便审查者根据所述意图核对代码
5. 审查上下文：意图摘要、文件列表、差异
6. 用于产物文件路径的运行 ID 和审查者名称
7. **仅适用于 project-standards：**第 3b 阶段的标准文件路径列表，以 <standards-paths> 块包裹，并附加到审查上下文中

角色子 Agent 对项目具有只读权限：它们负责审查并返回结构化 JSON，不会编辑项目文件或提出重构建议。唯一允许的写入操作是按照输出约定，将完整分析保存到 .context/ 产物路径。

这里的只读指不修改内容，而不是“不能访问 shell”。审查者子 Agent 可在需要时使用不会修改内容的检查命令来收集证据或核实范围，包括读取型 git / gh 命令，例如 git diff、git show、git blame、git log 和 gh pr view。它们不得编辑项目文件、切换分支、提交、推送、创建 PR，或以其他方式修改检出内容或仓库状态。

每位角色子 Agent 都会将完整 JSON（包含所有架构字段）写入 .context/compound-engineering/ce-review/{run_id}/{reviewer_name}.json，并仅返回包含合并层级字段的精简 JSON：

{
  "reviewer": "security",
  "findings": [
    {
      "title": "User-supplied ID in account lookup without ownership check",
      "severity": "P0",
      "file": "orders_controller.rb",
      "line": 42,
      "confidence": 0.92,
      "autofix_class": "gated_auto",
      "owner": "downstream-resolver",
      "requires_verification": true,
      "pre_existing": false,
      "suggested_fix": "Add current_user.owns?(account) guard before lookup"
    }
  ],
  "residual_risks": [...],
  "testing_gaps": [...]
}

详细层级字段（why_it_matters、evidence）仅写入产物文件。suggested_fix 在两个层级中均为可选项；若存在，则在精简返回中一并提供，以便编排器判断是否自动应用修复。如果写入文件失败，精简返回仍会提供合并所需的全部内容。

CE 始终运行的 Agent（agent-native-reviewer、learnings-researcher）会作为标准 Agent 调用，与角色 Agent 并行派发。向它们提供与角色 Agent 相同的审查上下文包：入口模式、第 1 阶段收集的任何 PR 元数据、意图摘要、已知时的审查基准分支名称、BASE: 标记、文件列表、差异以及 UNTRACKED: 范围说明。不要使用泛泛的“审查此内容”提示来调用它们。它们的输出不采用结构化格式，并会在第 6 阶段单独汇总。

CE 条件运行的 Agent（schema-drift-detector、deployment-verification-agent）也会在适用时作为标准 Agent 调用。向它们提供相同的审查上下文包，并附上适用原因（例如，触发该 Agent 的迁移文件）。对于 schema-drift-detector，务必明确传递解析后的审查基准分支，避免它默认使用 main。它们的输出不采用结构化格式，必须像 CE 始终运行的 Agent 输出一样保留，以供第 6 阶段汇总。

阶段 5：合并发现项

将多位审查者返回的精简 JSON 转换为一个去重并经过置信度门槛筛选的发现项集合。精简返回包含合并层级字段（title、severity、file、line、confidence、autofix_class、owner、requires_verification、pre_existing）以及可选的 suggested_fix。详细层级字段（why_it_matters、evidence）保存在每位 Agent 的工件文件中，此阶段不会加载。

1. 验证。 检查每个精简返回是否包含必需的顶层字段和每条发现项的字段，并检查值是否符合约束。丢弃格式错误的返回或发现项，并记录丢弃数量。
   • 必需的顶层字段： reviewer（字符串）、findings（数组）、residual_risks（数组）、testing_gaps（数组）。如果缺失任何字段或类型不正确，则丢弃整个返回。
   • 每条发现项的必需字段： title、severity、file、line、confidence、autofix_class、owner、requires_verification、pre_existing
   • 值约束：
     • severity：P0 | P1 | P2 | P3
     • autofix_class：safe_auto | gated_auto | manual | advisory
     • owner：review-fixer | downstream-resolver | human | release
     • confidence：数值，范围为 0.0-1.0
     • line：正整数
     • pre_existing、requires_verification：布尔值
   • 此处不要依据完整架构进行验证——完整架构（包括 why_it_matters 和 evidence）适用于磁盘上的工件文件，而非精简返回。
2. 置信度门槛。 抑制置信度低于 0.60 的发现项。例外：置信度达到 0.50 及以上的 P0 发现项可通过门槛——绝不能悄然丢弃关键但不确定的问题。记录被抑制的数量。这与角色说明及架构的置信度阈值一致。
3. 去重。 计算指纹：normalize(file) + line_bucket(line, +/-3) + normalize(title)。指纹相同时，进行合并：保留最高严重性和最高置信度，并注明指出该问题的审查者。
4. 跨审查者一致性。 当 2 位或更多独立审查者指出同一问题（指纹相同）时，将合并后的置信度提高 0.10（上限为 1.0）。跨审查者一致性是强有力的信号——独立审查者得出相同结论，比单个审查者的置信度更可靠。在输出的 Reviewer 列中注明一致性（例如，“security, correctness”）。
5. 分离既有问题。 将 pre_existing: true 的发现项单独提取到一个列表中。
6. 解决分歧。 当审查者针对同一代码区域给出不同的严重性、autofix_class 或 owner 时，在 Reviewer 列中注明分歧（例如，“security (P0), correctness (P1) -- kept P0”）。这种透明度有助于用户理解发现项的处理路径。
7. 规范化路由。 为每条合并后的发现项设置最终的 autofix_class、owner 和 requires_verification。如果审查者意见不一，采用最保守的处理路径。综合时可以将发现项从 safe_auto 收紧为 gated_auto 或 manual，但没有新证据时不得放宽。
8. 划分工作。 构建三个集合：
   • 技能内修复队列：仅包含 safe_auto -> review-fixer
   • 剩余可操作队列：未解决的 gated_auto 或 manual 发现项，且其 owner 为 downstream-resolver
   • 仅报告队列：advisory 发现项，以及 owner 为 human 或 release 的任何发现项
9. 排序。 按严重性排序（P0 优先）-> 置信度（降序）-> 文件路径 -> 行号。
10. 收集覆盖数据。 合并各审查者的 residual_risks 和 testing_gaps。
11. 保留 CE Agent 工件。 将 learnings、agent-native、schema-drift 和 deployment-verification 输出与合并后的发现项集合一并保留。不要仅仅因为非结构化 Agent 输出不符合角色 JSON 架构就将其丢弃。

第 6 阶段：综合并呈现

使用下方审查输出模板中的管道符分隔的 Markdown 表格汇总最终报告中的发现。交互模式下，发现项必须使用表格格式——不得将发现项写成自由格式的文本块或用水平分隔线隔开的散文。其他报告部分（已应用的修复、经验总结、覆盖情况等）使用项目符号列表，并在结论前使用 --- 分隔符，如模板所示。

1. 标题。 范围、意图、模式、审查团队及每项条件判断的理由。
2. 发现项。 按严重程度分组，以管道符分隔的表格呈现（### P0 -- 严重、### P1 -- 高、### P2 -- 中、### P3 -- 低）。每行发现项显示 #、文件、问题、审查者、置信度和综合处理方案。省略空的严重程度级别。不得将发现项写成自由格式的文本块或编号列表。
3. 需求完整性。 仅在第 2b 阶段找到计划时包含。对于计划中的每项需求（R1、R2 等）和实施单元，报告差异中是否体现了相应工作。使用简单的核对清单：已满足／未处理／部分满足。处理方式取决于 plan_source：
   • explicit（调用方提供或 PR 正文中给出）：将未处理的需求标记为 P1 发现项，设置 autofix_class: manual、owner: downstream-resolver。这些项会进入剩余待处理队列，并可转为待办事项。
   • inferred（自动发现）：将未处理的需求标记为 P3 发现项，设置 autofix_class: advisory、owner: human。这些项仅保留在报告中——不创建待办事项，也不进行自主跟进。推断出的计划匹配仅供参考，并非约定。 如果未找到计划，则完全省略此部分——不要提及未找到计划。
4. 已应用的修复。 仅在本次调用中运行了修复阶段时包含。
5. 剩余待处理工作。 存在尚未解决的可操作发现项已移交或应移交时包含。
6. 预先存在的问题。 单独列出，不计入结论。
7. 经验总结与过往解决方案。 呈现经验研究员的结果：如果存在相关过往解决方案，将其标记为“已知模式”，并附上指向 docs/solutions/ 文件的链接。
8. Agent 原生能力缺口。 呈现 Agent 原生能力审查员的结果。未发现缺口时省略此部分。
9. 架构漂移检查。 如果运行了架构漂移检测器，则总结是否发现漂移。如果存在漂移，列出无关的架构对象和所需的清理命令。如果没有漂移，则简要说明。
10. 部署说明。 如果运行了部署验证 Agent，则呈现关键的 Go/No-Go 项目：部署前的阻断性检查、最重要的验证查询、回滚注意事项和监控重点。清单应便于执行，不要将其归入覆盖情况。
11. 覆盖情况。 被抑制的数量、剩余风险、测试缺口、失败／超时的审查者，以及非交互模式下遗留的任何意图不确定性。
12. 结论。 可合并／修复后可合并／尚未就绪。如适用，注明修复顺序。如果 explicit 计划中存在未处理的需求，结论必须体现这一点——除非遗漏是有意的，否则即使代码本身没有问题，但缺少计划中的需求，也属于“尚未就绪”。如果 inferred 计划中存在未处理的需求，应在结论理由中说明，但不能仅因此阻止合并。

不得包含时间估算。

格式验证： 提交报告前，确认发现项部分使用管道符分隔的表格行（| # | File | Issue | ... |），而非自由格式文本。如果发现自己将发现项写成以水平分隔线隔开的散文块或项目符号，请停止并改为表格。

无头输出格式

在 mode:headless 下，将交互式的竖线分隔表格报告替换为结构化文本封套。该封套遵循 document-review 无头输出的相同结构模式（完成标头、元数据块、按 autofix_class 分组的发现项、末尾部分），同时使用 ce:review 自己的章节标题和每条发现的字段。

Code review complete (headless mode).

Scope: <scope-line>
Intent: <intent-summary>
Reviewers: <reviewer-list with conditional justifications>
Verdict: <Ready to merge | Ready with fixes | Not ready>
Artifact: .context/compound-engineering/ce-review/<run-id>/

Applied N safe_auto fixes.

Gated-auto findings (concrete fix, changes behavior/contracts):

[P1][gated_auto -> downstream-resolver][needs-verification] File: <file:line> -- <title> (<reviewer>, confidence <N>)
  Why: <why_it_matters>
  Suggested fix: <suggested_fix or "none">
  Evidence: <evidence[0]>
  Evidence: <evidence[1]>

Manual findings (actionable, needs handoff):

[P1][manual -> downstream-resolver] File: <file:line> -- <title> (<reviewer>, confidence <N>)
  Why: <why_it_matters>
  Evidence: <evidence[0]>

Advisory findings (report-only):

[P2][advisory -> human] File: <file:line> -- <title> (<reviewer>, confidence <N>)
  Why: <why_it_matters>

Pre-existing issues:
[P2][gated_auto -> downstream-resolver] File: <file:line> -- <title> (<reviewer>, confidence <N>)
  Why: <why_it_matters>

Residual risks:
- <risk>

Learnings & Past Solutions:
- <learning>

Agent-Native Gaps:
- <gap description>

Schema Drift Check:
- <drift status>

Deployment Notes:
- <deployment note>

Testing gaps:
- <gap>

Coverage:
- Suppressed: <N> findings below 0.60 confidence (P0 at 0.50+ retained)
- Untracked files excluded: <file1>, <file2>
- Failed reviewers: <reviewer>

Review complete

详细信息补充（仅无头模式）： 无头封套包含 Why:、Evidence: 和 Suggested fix: 行。合并后（阶段 5），仅针对通过去重和置信度门控的发现，从 .context/compound-engineering/ce-review/{run_id}/ 读取各 Agent 的产物文件。

• 字段层级： Why: 和 Evidence: 属于详细信息层级——从各 Agent 的产物文件中加载。Suggested fix: 属于合并层级——直接使用精简返回结果，无需查找产物。
• 产物匹配： 对于每条通过筛选的发现，在各贡献审查者的产物文件中查找其详细信息层级字段。匹配条件为 file + line_bucket(line, +/-3)（与阶段 5 去重时使用的容差相同），且仅在各贡献审查者自己的产物中匹配。如果行范围内有多个产物条目，则将合并后发现项的标题和每个候选条目的标题都应用 normalize(title)，作为决胜条件。
• 审查者顺序： 按合并后发现项的审查者列表中的顺序，依次尝试各贡献审查者；使用第一个匹配项。
• 无匹配时的回退： 如果没有任何产物文件包含匹配项（所有写入均失败，或该发现是在合并期间合成的），则省略该发现的 Why: 和 Evidence: 行，并在 Coverage 中注明这一缺口。由于 Suggested fix: 属于合并层级，仍可使用精简返回结果填充该行。

格式规则：

• [needs-verification] 标记仅出现在 requires_verification: true 的发现项中。
• Artifact: 行向调用方提供完整运行产物的路径，以便机器读取完整的发现项架构。文本封套是主要交接内容；产物用于调试和访问完整信息。
• owner: release 的发现项出现在 Advisory 部分（这些是运维／发布项目，而非代码修复）。
• pre_existing: true 的发现项无论 autofix_class 为何，都出现在 Pre-existing 部分。
• Verdict 出现在元数据标头中（有意区别于交互格式：后者将其放在底部），让程序化调用方优先获取判定结果。
• 省略所有没有条目的章节。
• 如果所有审查者都失败或超时，则输出 Code review degraded (headless mode). Reason: 0 of N reviewers returned results.，后接 "Review complete"。
• 以 "Review complete" 作为结束信号，供调用方检测任务是否完成。

质量门槛

交付审查结果前，请核实以下内容：

1. 每条发现都可采取行动。 重新阅读每条发现。如果其中写有“考虑”“或许可以”或“可以改进”，却没有给出具体修复方案，请改写为明确的操作建议。含糊的发现会浪费工程时间。
2. 避免因略读而产生误报。 对于每条发现，请确认你确实阅读了相关代码。检查所谓的“漏洞”是否已在同一函数的其他位置处理，“未使用的导入”是否用于类型注解，“缺少的 null 检查”是否已由调用方保证。
3. 严重性分级准确。 样式方面的小问题绝不能是 P0。SQL 注入绝不能是 P3。重新检查每项严重性分级。
4. 行号准确。 对照文件内容核实每个引用的行号。指出错误行号的发现比没有发现更糟。
5. 遵守受保护的产物规则。 丢弃任何建议删除或通过 gitignore 排除 docs/brainstorms/、docs/plans/ 或 docs/solutions/ 中文件的发现。
6. 发现项不得重复报告 linter 输出。 不要标记项目的 linter／格式化工具可以发现的问题（例如缺少分号、缩进错误）。应聚焦于语义问题。

语言感知条件分支

当差异明确需要时，此技能会使用特定技术栈的审查 Agent。这些 Agent 应当保持鲜明立场。它们不是通用的语言检查器，而是在始终启用的通用审查角色和跨领域审查角色之上，提供独特的审查视角。

不要仅根据文件扩展名机械地启动这些 Agent。只有当该技术栈中有实质性的行为、架构或 UI 状态变更时，才触发它们。

审查后

由模式驱动的审查后流程

呈现审查结果和结论（阶段 6）后，根据模式安排后续步骤。所有模式的审查和综合流程都相同；只有修改和交接行为会发生变化。

步骤 1：构建操作集合

• 审查无问题表示在抑制和区分已有问题后，发现数为零。若审查无问题，则跳过修复／交接阶段。
• 修复队列： 最终发现项中，路由到 safe_auto -> review-fixer 的项目。
• 剩余可操作队列： 尚未解决的 gated_auto 或 manual 发现项，且其最终责任方为 downstream-resolver。
• 仅报告队列： advisory 发现项，以及任何由 human 或 release 负责的输出。
• 绝不将仅限建议的输出转为修复工作或待办事项。 部署说明、剩余风险和由发布负责的事项都保留在报告中。

步骤 2：按模式选择策略

交互模式

• 自动应用 safe_auto -> review-fixer 发现项，无需询问。这些项目按定义是安全的。

• 仅当安全修复后仍有 gated_auto 或 manual 发现项时，才使用平台的阻塞式提问工具（Claude Code 中的 AskUserQuestion、Codex 中的 request_user_input、Gemini 中的 ask_user）询问策略问题。不要用开放式对话问题代替。根据剩余项目调整选项：

  存在 gated_auto 发现项时（无论是否同时存在 manual）：

  Safe fixes have been applied. What should I do with the remaining findings?
  1. Review and approve specific gated fixes (Recommended)
  2. Leave as residual work
  3. Report only -- no further action
  

  仅剩 manual 发现项时（没有 gated_auto）：

  Safe fixes have been applied. The remaining findings need manual resolution. What should I do?
  1. Leave as residual work (Recommended)
  2. Report only -- no further action
  

  如果没有可用的阻塞式提问工具，请以文本形式列出适用的编号选项，并等待用户选择后再继续。

• 如果安全修复后没有剩余的 gated_auto 或 manual 发现项，则完全跳过策略问题——报告已修复的内容并继续后续步骤。

• 只有在用户明确批准具体项目后，才将 gated_auto 发现项加入修复队列。不要仅凭严重程度扩大队列。

自动修复模式

• 不提问。
• 仅应用 safe_auto -> review-fixer 队列中的项目。
• 将 gated_auto、manual、human 和 release 项目保留为未解决状态。
• 仅为最终责任方为 downstream-resolver 的未解决可操作发现项准备剩余工作。

仅报告模式

• 不提问。
• 不构建修复队列。
• 不创建剩余待办事项或 .context 产物。
• 在阶段 6 后停止。所有内容都保留在报告中。

无头模式

• 不提问。
• 在单次处理中仅应用 safe_auto -> review-fixer 队列。不要进入有界复审循环（步骤 3）。启动一个修复子 Agent，应用修复，然后直接进入步骤 4。
• 将 gated_auto、manual、human 和 release 项目保留为未解决状态——这些项目会显示在结构化文本输出中。
• 输出无头输出封套（参见阶段 6），而非交互式报告。
• 编写一次运行产物（步骤 4），但不创建待办文件。
• 在结构化文本输出和“Review complete”信号后停止。不执行提交／推送／创建 PR。

第 3 步：由一个修复器分轮应用修复

• 为当前检出中的修复队列恰好启动一个修复子 Agent。该修复器应一次性应用所有获批的更改，并在一致的代码树上运行相关的定向测试。
• 不要在同一检出中启动多个修复器并行工作。并行修复器必须使用隔离的工作树／分支，并谨慎合并回主分支。
• 修复完成后，仅重新审查已更改的范围。
• 使用 max_rounds: 2 限制循环轮数。如果第二轮后仍有问题，则停止，并将其作为剩余工作移交，或报告为未解决。
• 如果任何已应用的发现项标记了 requires_verification: true，则在运行定向验证之前，该轮仍未完成。
• 不要在同一检出上与浏览器测试并发启动会修改代码的审查轮次。若未来的编排器需要同时执行这两项工作，则必须在并行阶段使用 mode:report-only，或在独立的检出／工作树中进行会修改代码的审查。

第 4 步：生成产物并移交下游

• 在交互、自动修复和无头模式下，于 .context/compound-engineering/ce-review/<run-id>/ 下写入每次运行对应的产物，其中包含：
  • 综合发现项（Stage 5 的合并输出）
  • 已应用的修复
  • 尚待处理的可执行工作
  • 仅供参考的输出 每个 Agent 的完整详情 JSON 文件（{reviewer_name}.json）已由 Stage 4 的分派流程写入此目录。
• 同时在发现项旁写入 metadata.json，以便下游技能（例如 ce:polish-beta）验证该产物是否与当前分支和 HEAD 匹配。最低限度的字段：

  {
    "run_id": "<run-id>",
    "branch": "<git branch --show-current at dispatch time>",
    "head_sha": "<git rev-parse HEAD at dispatch time>",
    "verdict": "<Ready to merge | Ready with fixes | Not ready>",
    "completed_at": "<ISO 8601 UTC timestamp>"
  }
  

  在分派时（任何自动修复应用之前）记录 branch 和 head_sha，并在最终结论确定后写入文件。此文件为附加内容——早于该字段的现有产物仍然有效；如果缺少此字段，下游技能会回退到使用文件修改时间。
• 在自动修复模式下，仅为最终所有者为 downstream-resolver 的未解决可执行发现项创建持久待办文件。加载 todo-create 技能，以获取规范的目录路径、命名约定、YAML frontmatter 结构和模板。每项待办都应将发现项的严重程度映射到待办优先级（P0／P1 -> p1，P2 -> p2，P3 -> p3），并设置 status: ready，因为这些发现项已在综合整理阶段完成分流。
• 不要为 advisory 发现项、owner: human、owner: release 或受保护产物的清理建议创建待办。
• 如果只剩下仅供参考的输出，则不要创建待办。
• 交互模式可以在修复后提供选项，将剩余的可执行工作外化，但完成审查并不要求这样做。

第 5 步：最终后续步骤

**仅限交互模式：**修复—审查周期完成后（结论为干净，或用户选择停止），根据进入模式提供后续步骤。如果 Stage 1 已确定审查基准分支／默认分支，则沿用该结果；不要只硬编码 main／master。

• PR 模式（通过 PR 编号／URL 进入）：
  • 推送修复——将提交推送到现有 PR 分支
  • 退出——暂时完成
• 分支模式（无 PR 的功能分支，且不是已确定的审查基准分支／默认分支）：
  • 创建 PR（推荐）——推送并创建拉取请求
  • 继续，不创建 PR——留在当前分支
  • 退出——暂时完成
• 在已确定的审查基准分支／默认分支上：
  • 继续——进行后续步骤
  • 退出——暂时完成

如果选择“创建 PR”：先使用 git push --set-upstream origin HEAD 发布分支，然后使用 gh pr create，根据分支更改拟定标题和摘要。 如果选择“推送修复”：使用 git push 推送分支，以更新现有 PR。

**自动修复、仅报告和无头模式：**生成报告、产物并移交剩余工作后即停止。不要提交、推送或创建 PR。

回退方案

如果平台不支持并行子 Agent，请按顺序运行审查 Agent。其他所有内容（阶段、输出格式、合并流程）保持不变。

---

包含的参考资料

角色目录

@./references/persona-catalog.md

子 Agent 模板

@./references/subagent-template.md

差异范围规则

@./references/diff-scope.md

发现项架构

@./references/findings-schema.json

审查输出模板

@./references/review-output-template.md