reviewing-document-discovery

reviewing-document-discovery — SKILL.md

变体： standard · 使用时机： 评判已产出的文档计划（项目将产出哪些文档的清单）——判断其是否足够完善，可以据此开始产出文档，然后给出 VERDICT: approve|revise，并列出可执行的发现。

概述

此技能是针对已产出文档计划的验收关卡——负责独立审查 project-document-discovery 的产出。审查者加载计划（以及该计划所依据的构想／项目类型）后，需要回答一个问题：这组文档是否恰当——比例合理、内容完整且能够产出，是否完善到足以据此开始产出？ 它依据固定的十四项条件标准（九项原始条件 + 三项 v2.0.0 输出契约条件 + 两项新增的 v3.0.0 清单完整性条件）进行审查，然后给出单一、可供机器解析的判定，以及供产出方采取行动的发现。

该标准与发现技能的自检项逐项完全对应（其第 9 步，v6.0.0）：发现技能依据这十四项自检，确保产出良好计划；此技能则独立审查相同的十四项（不能自己给自己的作业打分）。此技能仅用于审查：绝不撰写、修复或重新规划，只报告发现，由产出方进行修改。

何时启用

• 产出的文档计划／清单需要在文档产出前作出接受／修改判定。
• 你是对 project-document-discovery（或任何等效工具）产出的计划进行独立把关的审查者。
• 根据先前 revise 的反馈修复后重新评判计划，或评判一项 amend（现有计划 + 明确说明的变更 → 差异）。

请勿在以下情况启用：

• 你要评判单份已产出文档的内部质量（例如 PRD、架构文档）——请使用该文档对应类型的审查器。
• 你要评判一组已完成文档彼此之间是否一致——请使用 reviewing-document-set（它是已产出文档集的关卡；此技能是前期计划关卡）。
• 你要撰写计划——这属于 project-document-discovery；此技能仅用于审查。

输入

• 已产出的文档计划，采用发现技能的输出格式——包含文档列表，每份文档都列出其 what、产出者角色、工具／提供方、技能和 depends_on。
• 计划所依据的构想 + 项目类型——用于判断比例是否合理（对于当前项目，哪些内容是关键支撑，哪些是凑数）。
• （仅适用于 Amend）先前的计划 + 明确说明的变更——用于判断差异是否仅限于该变更。

缺少构想／项目类型属于指导信息缺失（尽可能评判，并标明无法评判之处）——绝不臆造项目意图。

工作流

此方法包含十四项条件，然后给出判定。首先通读整个计划（以及构想／项目类型）。

第 1 步 — 明确背景

记下项目类型（轻量 CLI 工具、UI SaaS 和 ML 产品所需的文档集迥异），并确认这是一个绿地计划还是 amend（先前的计划 + 明确说明的变更）。假设计划由能力出色的发现流程产出——你负责独立检查，找出它可能轻率放过的缺漏。

第 2 步 — 评判十四项条件

1. 与项目原型相匹配。 文档集的规模应与项目相称——既不能过度选取（为命令行工具准备 PRD、线框图和设计系统），也不能选取不足（为了显得精简而删掉关键文档）。应依据原型判断，而非固定分类体系。
2. 包含关键文档。 定义功能的文档（PRD／功能规格；对于 UI 产品，还包括设计文档）均在文档集中。
3. 每份文档均满足生产要求。 每份文档都具有作者 + 审阅者 roles 配对（恰好两个 ID，按 [author, reviewer] 顺序排列，并与原型匹配——工程师／策略师使用 [document-author, document-reviewer]，设计师使用 [designer, design-reviewer]）+ 工具／提供方 + 编写和审阅 skills（例如 [authoring-prd, reviewing-prd]）。
4. 每份文档均有 depends_on。 每份文档都包含 depends_on（已裁剪至文档集范围）。
5. 依赖图无环。 组合后的（已裁剪）depends_on 图中不存在环；依赖边按需求 → 设计 → 交付 → 文档的方向流动。
6. 不存在孤立文档——终端交付物除外。 每份中间文档要么为其他文档提供输入，要么以其他文档为输入。叶节点交付物若本身是可交付的最终产品——例如 LICENSE／CHANGELOG／SECURITY.md，通常也包括 README——其 depends_on: []，且没有下游文档读取，不算孤立文档；不要将其标记出来。只有既不读取任何上游文档、也不被任何文档读取的中间文档才是孤立文档。
7. 不凑数。 不包含项目不会使用的文档。
8. 保留开放性。 对于无法识别的类型，计划应将其视为经过研究／构建，而不是猜测；不能仅仅因为目录中没有该类型，就默默省略所需的类型。
9. （仅适用于修订）变更范围仅限于差异。 修订时，只修改变更／新增的文档及其 DAG 边；不重新推导未变更的计划，且重新裁剪后的图仍须无环。（从零开始制定计划时不适用。）
10. 存在且完整的 capability_map 键。 输出 JSON 顶层包含 capability_map 键；10 个 v2 分类簇子键（archetype、domain、regulatory、scale、security、integrations、ui、data_ml、infrastructure、business）均须存在，同时还要包含由模型编写的 prior_art_triggers 块。仅检查是否存在且内容一致——触发条件的正确性由确定性验证器（scripts/validate.py）负责；此处不要重新推导触发条件公式。（v1.x 输出不适用；从 4.0.0 输出起适用。）
11. 存在且格式正确的 product_capabilities 记录。 输出 JSON 顶层包含 product_capabilities 数组；每条记录都包含必填字段（id、name、scope、owns、has_ui、has_api、has_persistence）；列表包含 4–10 条 L1 记录（没有 parent 字段或 parent: null 的记录）。如果数量不在 4–10 条范围内，应将其标记为问题（违反指导要求，而非硬性门槛）。（v1.x 输出不适用。）
12. manifest 嵌套在 "manifest" 键下；存在各能力对应的条目。 输出 JSON 包含 manifest 键（文档列表不能位于根级）；每个文档条目都包含 type 和 scope 字段；每项有效能力都存在对应条目（feature-spec-{id}）；分流标记（has_ui、has_api、has_persistence）与生成的各能力对应文档条目一致。（v1.x 输出不适用。）
13. 五个 manifest 元数据分区均已填充。 manifest.capabilities 包含 docs（始终包含）和 design（当 ui.has_ui: true 时包含）；不得包含构建级能力（auth、ci、vcs、storage 等）。manifest.roles、manifest.skills 和 manifest.tools 均根据文档集填充——不得为空数组 []。manifest.roles 包含所有现有原型所需的完整作者／审阅者配对（存在工程师／策略师文档时，包含 document-author + document-reviewer；存在设计师文档时，包含 designer + design-reviewer），且每个角色条目都是纯角色设定（不包含 skills／tools 字段）。manifest.skills 中的每个条目都具有 version: null、source: null、已填充的 purpose 和非空的 requirements 列表；每个技能和角色条目都带有 resolved_id 和 match_status，发现阶段这两个字段均为 null——不要将 version／source／resolved_id／match_status 为 null 标记为缺陷（审批门会解析这些字段）。（v2.x 及更早版本的输出不适用。）
14. 每个文档条目都包含标量 capability。 manifest.documents 中的每个文档条目都包含 capability 字段，且值为字符串标量（"docs" 或 "design"）。使用数组形式 "capabilities": [...] 的条目不符合此条件。（v2.x 及更早版本的输出不适用。）

步骤 3 — 作出判断并输出

权衡各项发现。对于比例适当、完整、可产出且无循环依赖的计划，批准；不要错误地修改适合精简型项目类型的精简计划。发现任何真实且明确的缺口（选择过多／不足、缺少产出文档或 depends_on、存在循环、存在中间孤立文档、凑数）时，要求修改。按下方的输出约定给出结果。

规则

硬性规则（绝不可违反）：

• 只给出一个最终判定。 结尾必须恰好一行，内容为 VERDICT: approve 或 VERDICT: revise，适用于整个计划。（调用方通常只读取最后一行 VERDICT:。）
• 不得错误地要求修改。 批准比例适当的计划；对于精简型项目类型，规模适当的精简文档集合应当批准，而非要求修改。只有存在真实缺口时才要求修改，且发现必须一次就能落实（说明问题是什么、涉及哪些文档以及如何修复）。
• 不得臆造要求。 评判结果是否达到（计划是否比例适当、充分且无循环依赖）。绝不可要求与项目类型无关的文档（无状态 CLI 不需要数据模型，库不需要线框图），绝不可要求引用某个具名标准，也绝不可仅因目录中列有某份文档就要求提供它。计划本来就是开放式的。
• 仅作审查。 绝不可撰写、修复或重新规划；只报告发现，由产出方修改。
• 终端交付物例外至关重要。 绝不可将叶节点交付物（LICENSE/README/CHANGELOG）标记为孤立文档（条件 6）。

易错点

• 错误地要求修改精简计划。 精简 CLI 工具的计划（README + 简短设计说明）是正确的，并非不完整——比例是否适当应根据项目类型判断，而非对照绝对清单。
• 将叶节点交付物标记为孤立文档。 没有 depends_on 且没有下游读取者的 LICENSE/README/CHANGELOG 是可交付的最终成果，而非孤立文档（条件 6）——这是最常见的错误修改原因。
• 要求涵盖完整分类体系。 不顾项目情况要求包含目录中的每个类别／叠加项，会重现发现技能试图避免的繁重强制分类体系；这属于过度选择，应该由你发现并指出，而不是由你导致。
• 偏离文档计划审查。 PRD 写得好不好，应由 PRD 自己的审查者评判；此处只评判计划是否选对了文档集合并正确连接依赖关系。
• 修订时重新验证整个计划。 修订时，应评判变更部分（条件 9）——不要重新争论未变且已经合理的计划内容。

反模式

• 判定不在最后一行，或给出多个判定。
• 要求项目类型不需要的文档（“每个项目都需要 PRD”）——臆造要求。
• 仅因计划规模小，就要求修改适合精简型项目类型的精简计划。
• 将叶节点交付物标记为孤立文档。
• 重写计划，而不是返回发现。

输出

发现报告：包含零条或多条可执行的发现（每条都指出受影响的文档及修复方法），随后给出恰好一个最终 VERDICT: approve|revise。如需修改，发现列表应是产出方据以修正计划的可执行事项。抽象消费者是负责转交修复任务的编排器，以及负责修订计划的发现流程。

相关内容

• project-document-discovery — 与之对应的编写技能，用于生成本技能把关的计划；其第 9 步自检（v6.0.0）是这十四项条件的唯一来源，两者一一对应（作者自我纠正 vs. 本技能的独立把关）。
• reviewing-document-set — 已生成文档集的一致性把关（文档写完后，检查成品是否一致）；本技能是前置计划把关（文档编写前，检查计划是否合理）。两者相辅相成，互不重叠。
• 按类型划分的文档审查技能（reviewing-prd、……）— 评判单份已生成文档的内部质量；本技能则评判决定文档集构成的计划。
• design-review — 把关通用设计文档、规格说明或 §15 实施计划；它从未把关过文档计划/清单（这是另一种产物），因此两者之间无需划定例外。
• 本技能所落实的实践 — ISO/IEC/IEEE 15289（生命周期信息项及裁剪）、适度控制规模／“恰到好处”，以及需求→设计→交付 DAG — 参见 references/sources.md。

渐进式披露

• references/plan-quality-bar.md — 十四项条件的逐项通过／差距信号及实例化发现（尤其应针对条件 1/6/9/10/11/12/13/14 加载）。
• references/sources.md — 质量标准的研究依据。

正文预算

• description ≤ 1,024 个字符（agentskills.io 上限；列表中 description 与 when_to_use 合计超过 1,536 个字符时会被截断）。
• 正文 ≤ 约 500 行／5,000 个 token — 大量内容放在 references/ 中。

更新日志

• 1.5.0（2026-07-10）— 增量更新，跟踪 project-document-discovery 6.0.0（技能意图 + 解析字段）。条件 13 现在要求每个 manifest.skills 条目都填有 purpose，且 requirements 列表非空；每个技能和角色条目都必须包含 resolved_id + match_status（发现时两者均为 null——明确规定这不算缺失，与现有的 version: null 例外处理一致）。与发现流程的自检项 13 完全一一对应。其他十三项条件保持不变。

• 1.4.0（2026-07-09）— 增量更新，跟踪 project-document-discovery 5.0.0（清单审查角色）。条件 3 现在检查作者/审阅者的 roles 配对（两个 ID 按 [author, reviewer] 顺序排列，与原型一致），以及每份文档对应的编写和审阅技能；条件 13 现在要求 manifest.roles 为其中存在的每种原型都包含完整配对，且每个角色条目都必须是纯 persona（不含 skills/tools）。与发现流程的自检项 3 + 13 完全一一对应。其他十二项条件保持不变。

• 1.3.0（2026-06-26）— 更新以适配 project-document-discovery 4.0.0（capability-map v2）。条件 10 重写为 10 个 v2 分类集群（移除 team；新增 business、integrations），并纳入现在由模型编写的 prior_art_triggers 区块；仅检查存在性和一致性——触发条件是否正确由确定性验证器负责（不重新推导公式）。与生成方的 v2 分类完全一一对应。其他十三项条件保持不变。

• 1.2.0（2026-06-21）— 增量更新，以适配 project-document-discovery v3.0.0。新增两项条件：13（全部五个清单元数据区块均已填充——capabilities/roles/skills/tools 不为空；无 build 级别 capability；skills 的 version/source 为 null）和 14（每个文档条目都使用标量 capability——不使用数组形式）。描述更新为“十四项条件门槛”。原有十二项条件保持不变。

• 1.1.0（2026-06-21）— 增量更新，以适配 project-document-discovery v2.0.0 输出契约。新增三项条件（10、11、12）：存在 capability_map 键，且包含全部 10 个集群；存在 product_capabilities 键，且包含 4–10 条 L1 记录并具备必需字段；manifest 嵌套在 "manifest" 键下，每个条目都包含 type/scope，且每个 capability 的展开条目与标记相符。原有九项条件保持不变。描述更新为“十二项条件门槛”。

• 1.0.0（2026-06-15）— 初始审核版本。对已生成的文档计划进行独立门控；九项条件与 project-document-discovery 的自检完全一一对应。