ce-doc-review

文档评审

帮助作者完善文档，使其可靠地指导已商定工作的实施。找出会改变工作结果或严重妨碍执行的问题，并在已有授权范围内解决。评判文档的标准是它能否指导正确的工作，而不是包含多少细节。即使缺陷很小，只要可能造成严重后果，也应予以关注。合格的文档无需修改。

评审者角色负责提供依据；判断由你作出。结合整份文档、项目事实和已确定的决策，核查他们提出的说法。根据综合参考中说明的编辑权限和评审者要求，更正那些已证实会妨碍落实现有决策的错误。仅返回仍需获得许可且值得改进的事项、只有用户才能提供的重要决策或关键信息，以及有用的观察。

**完成条件：**每位入选评审者均已返回结果，或已在 Coverage 中标记为失败；保留的发现均已证实会对商定工作造成后果；分配给 Apply 的每项授权更正均已完成并检查。通过交互式审批或决策流程报告最终状态；非交互模式下则以结构化文本返回。

交互模式规则

**首先阅读 references/modes.md。**其中定义了模式的检测方式、非交互参数约定以及提问工具规则：匹配当前工具列表中宿主提供的阻塞式提问工具（切勿调用面向用户的提问工具来发现该工具）；如果该工具已列出但尚未加载，则在交互流程开始时预先加载；只有当运行环境确实没有此类工具时，才改用编号列表。

无论哪种情况，需要用户作出决定的问题都必须调用该工具，或明确说明将改用编号列表。只用普通文本叙述是错误做法。

工件根目录

仅在无路径的交互分支中解析 <root>，该分支会在 <root>/plans/ 下查找最新计划。其他所有运行都读取传入路径指定的文档。因此，绝对路径或非交互式评审（例如 /tmp/plan.md，可能位于任何仓库之外）都不依赖仓库根目录，也不依赖其不需要的 CE 配置。

在编写任何工件路径之前，先解析 CE 工件根目录 <root>。

• 读取 <repo-root>/.compound-engineering/config.yaml 中的 docs_root，且仅从该文件读取（<repo-root> = git rev-parse --show-toplevel）。不要从 config.local.yaml 读取。若未设置，则 <root> 与之前一样为 docs。
• 验证已设置的值：它必须是仓库内的相对目录，其解析符号链接后的实际路径仍位于仓库内，且既不能是仓库根目录，也不能位于 .git/ 之下。否则停止并报告 docs_root 及其值，绝不可回退到 docs。
• 使用 <root> 作为唯一工件位置：若不存在则创建；将每个路径拼接为 <root>/<subdir>，其中 <subdir> 是此技能自身的子目录；绝不可同时读取 docs。

阶段 1：获取并分析文档

现在阅读 references/document-intake.md。 其中介绍了各模式下如何获取文档、未找到文档时该怎么做和怎么说，以及分类信号。

其中两条规则适用于后续所有步骤。

分派前先验证。 每个解析出的路径都必须在磁盘上可读。如果有路径不可读，则不要分派任何角色：审阅者从文件系统读取文档，因此无法访问仅存在于尚未检出的分支上的路径（issue #925）。

根据内容分类，而非就绪状态标签或文件路径。 仅包含 Product Contract 的统一产物属于 unified-requirements；缺少实现部分是预期情况。任何实现规划都会使其属于 unified-plan，包括需要审阅的不完整或受阻规划。其他产物使用传统的 requirements / plan 分类。

HTML 统一产物也采用相同的处理流程。所有修复都必须保留文档的原生格式；切勿在 HTML 中插入 markdown。该参考文档涵盖带 ID 的条目。将分类结果传给每个角色时，填入 {document_type} 槽位。

阶段 2：通知并分派角色

仅当 references/document-intake.md 中的已完成审阅复用条件满足时才跳过分派；带着该证据继续阶段 3。

对于每个条件角色的激活信号和通知格式，请阅读 references/persona-selection.md。其中两个信号容易因看似合理的证据而过度激活：security-lens-reviewer 的敏感数据界限，以及 adversarial-document-reviewer 的挑战面门槛。然后阅读 references/dispatch.md，了解负载变量、分片、模型分级和审阅者失败处理方式。

团队始终包含 coherence-reviewer 和 feasibility-reviewer，以及每个已激活的条件角色。分派前，逐一说明选择每个角色的理由，并通知团队成员。

通过平台的子 Agent 原语，以受限并行方式分派通用子 Agent。按照 references/dispatch.md 的说明，为每个子 Agent 提供对应的 references/personas/<reviewer-name>.md。切勿按类型或名称分派独立 Agent。

容量拒绝属于背压，不是审阅者失败：等待后重试。如果容量无法恢复，且仍有选定的审阅者未获分派，则按照 references/cross-model-review.md 的说明收集并清理所有已启动的跨模型任务，然后以未完成状态停止，不进行综合、修复或成功交接。保留已收集的结果，并报告哪些审阅者已完成、失败或无法运行，以及原因。

跨模型判断审阅

如果激活了三个条件判断角色中的任意一个，就运行此审阅：adversarial-document-reviewer、product-lens-reviewer、security-lens-reviewer。遵循 references/cross-model-review.md，其中定义了整个审阅流程：确认宿主、为整份文档选定一个目标和一条路径、在任何内容离开计算机前进行披露，以及如何启动、收集并整合同行审阅结果。

该审阅是附加且非阻塞的：失败或超时不会中止任何流程，并须在 Coverage 中说明。首先检查检出内容中的 cross_model_review_mode 设置；该设置可以跳过此审阅，但须说明具体原因。仅当设置了 CROSS_MODEL_PEERS 时才筛选接收方——未设置表示不筛选，并非未经授权。切勿静默更改明确指定的模型或接收方。

阶段 3–5：综合、呈现和后续操作

等待所有已派出的 Agent 返回，包括任何跨模型 <reviewer-name>-<provider>.json 返回结果。然后阅读 references/synthesis-and-presentation.md。该文件定义了综合方式、如何根据置信度和修复类别对每项发现进行分流、修复应用方式、非交互式结果格式，以及如何移交给路由问题。在提升共识时，只有 independence_verified: true 的产物才算独立审阅者的结果。

仅限交互模式。 阅读 references/walkthrough.md，了解分组确认、路由问题和逐项发现的讲解。阅读 references/bulk-preview.md，了解最佳判断路由、“追加到待解决问题”以及自动解决背后的批量操作预览。只有在审阅证据完整后（无论是新收集的还是有效复用的）才能加载这些文件；非交互式运行绝不会加载它们，而是停在结构化审阅结果处。

---

只阅读或传递当前审阅所选的角色提示词，并将每个提示词分别交给对应的审阅者。调度载荷所填充的模板和架构：

@./references/subagent-template.md

@./references/findings-schema.json