check-prd

对 B端 PRD 或系统设计文档进行严格、可执行的质量审查。

本 skill 保留 14 维 B 端 PRD 审查框架，并可按业务领域加载对应的领域 Provider（references/providers/<domain>/）执行专项审查。它不限定产品形态，既可用于商业化 SaaS，也可用于企业自研系统、私有化交付和二开项目。

支持用户显式调用（传入被审文档路径，需要领域专项时同时给出领域名）和模型自动触发（当用户明确要求审查 PRD、需求文档、产品方案或企业系统设计时）。

执行者与上下文隔离：本 skill 属审计类。若当前 Agent 是被审 PRD 的作者，必须委派独立子代理执行本 skill——作者上下文携带对自身产出的辩护，自审必然偷懒。首次审计与 M2 完整重审使用 fresh auditor；M1 定向复审可复用未参与修复的上一轮独立审计者。派发时按本 skill 所在 cookbook 的 Agent 执行协议（<cookbook>/process/agent-execution-protocol.md）第 3 节给出完整合同；本 skill 单独安装、取不到该协议时，派发 prompt 至少写明被审 PRD 与 Oracle 的路径、输出位置、完成标准、「只报告、不宣告通过」、对抗式立场（任务是找出问题，不采信作者的自述）与中断落盘（边审边把已完成部分写进报告文件），并在报告中注明未按协议全文派发；主 Agent 只回收并原样转呈审计报告，不得改写结论。审计结论是呈给用户裁定的证据，任何执行者都不得宣告"审计通过、可推进"。

审计权限：本 skill 对被审产物始终为 report-only，不得修改 PRD、Domain Model、spec、源码或测试，也不修改问题登记表、不删除或标记任何其它文件——只写本次报告。Focused recheck 先按当前文件完成判定，再逐项核销派发方给出的全部未关闭条目；没有旧条目时验证派发列出的 local change target、受影响维度和邻接回归。新发现使用独立编号进入“新增发现”章节。主 Agent 原样报告，是否修复或发起下一轮复审由用户决定。

本 skill 只回答“这份需求文档本身写得好不好”。 需求文档与模型、代码、图示、测试规格之间是否一致不在本 skill 的标准里，发现线索时记为“建议一致性审计复核”。变更等级、修复批次、问题登记与原文清理由派发方处理。每次审计都先加载下列文件，它规定三种审计动作在本 skill 下的范围与报告必须包含的元信息：

审计动作与报告元信息

输入

• 调用方给出的文件路径
• 或用户粘贴的 PRD / 系统设计文档内容
• 或不完整的文档（基于现有内容审查，并明确指出缺失的上下文）
• 当前项目中已有的上下文材料（如 Domain Model、解决方案文档、相邻模块 PRD、权限说明、状态机、数据流、UI/UX 规范、接口文档等）
• 审计报告输出路径：被派发执行时由派发方给出。直接使用且没有给出时，报告在对话里交付，是否保存由用户决定；用户要保存而没有指定位置时，放在被审文档所在模块的过程记录目录（宿主契约 cookbook.config.json 的 host.moduleDocs 与 host.processRecordsDir），不与需求文档混放。模块 = 被审文档路径所在的 host.moduleDocs 目录；路径对不上任何模块目录、或契约未声明时，请用户指明
• 复审时：派发方给出的该文档全部未关闭条目（来自模块的问题登记表）

调用方随调用给出的参数，优先作为输入源。

审查前的准备

1. 完整阅读文档后再对各维度进行评判。
2. 确定并记录：
   • 商业属性：自研内部系统 or 商业化产品
   • 功能类型：业务型管理软件 / 工具型软件 / 交易型平台 / 基础服务型
   • 领域补充规则：调用方指定的领域及是否已加载其 Provider；未指定时记"未指定，未加载领域补充规则"（见下文领域补充规则，不从文档内容判定）
   • 文档范围：0-1 系统级规划 / Overview PRD / 功能模块级需求 / 子功能详细需求 / 迭代需求
   • 是否涉及 AI 功能
3. 如果在项目工作区内审查 PRD，先检索并阅读相关已有材料，尤其是 Domain Model、相邻模块 PRD、解决方案文档、权限与状态机文档；审查中必须标注 PRD 与已有材料是否一致。
4. 在开始逐维度审查前，标记不适用的维度。
5. 如果页面或流程已经迁移到其它模块，检查原 PRD 是否只保留 contract、幂等和回写边界；原页面字段/按钮规格不得继续形成第二 Oracle。正文引用的流程图、SVG、原型截图必须与当前口径一致，历史图示应解除现行引用并显式标记 historical。
6. 扫描业务规则编号、缺口编号、审计问题编号、规则块字母、节点/文档/段落缩写等不透明引用。当前位置已完整表达规则时，冗余编码应删除；跨文档引用确有追溯价值时，必须同时给出可理解的名称、具体出处和可跳转链接。

适用性规则

Overview PRD 补充规则

当文档范围为 Overview PRD 时，不按单个页面或单个子功能的完整详细需求标准审查。Overview PRD 的核心职责是为后续模块级或 Sub PRD 提供稳定上位约束，审查时必须关注：

• 产品/模块定位、目标用户、业务价值和非目标是否清晰。
• PRD 包或子文档拆分是否完整、无重叠、无遗漏，且每个子文档边界可执行。
• 全局信息架构、功能分层、导航入口和跨子模块关系是否清晰。
• Domain Model、核心实体、数据读写边界、跨模块数据流是否与已有材料一致。
• 全局状态机、权限基线、审计基线、安全基线、异常基线是否能约束后续子文档。
• 是否明确 Sub PRD 需要继续展开的页面、字段、规则、异常、验收和埋点要求。

Overview PRD 不应因缺少页面级查询条件、列表字段、按钮、弹窗细节而直接判为严重缺失；但如果没有定义下钻到 Sub PRD 的覆盖矩阵和约束清单，应按影响范围标为 P1/P2。

领域补充规则

领域由调用方显式给出，本 skill 不从被审文档的内容里猜。 调用时指定了领域，且 references/providers/<domain>/ 下有对应 Provider，就额外加载它，并按其中的领域风险项与维度映射执行审查。"指定"指调用方明说了按哪个领域审；请求里出现某个业务话题的词（比如提到被审模块属于哪类业务），不算指定。模型自动触发时调用方通常没有给领域，按未指定处理。

没有指定领域时，按通用 14 维框架审查，并在报告开头显式声明"未加载领域补充规则"。 这条声明是必须的：不声明就变成静默降级——报告照常出、看起来完整，只是领域检查全部缺席，而读者无从知道。

不得从文档内容反推领域并自行加载。 一份 PRD 里出现某个领域的词汇，不代表调用方要按那个领域审；照着猜会让 skill 在判错的领域上静默产出错误结论，而不是报错。这条与工具包架构规范「默认值必须显式 resolve」同源。

领域的具体检查点由 Provider 定义，本文件不复制——同一条规则出现在两处，迟早会漂移成两个口径。同理，本文件也不写死任何一个领域的 Provider 路径。

输出规范

不可违反的行为规则

• 严格按照下方列出的顺序逐维度审查。
• 逐维度执行：开始第一个维度之前，先通读被审文档、加载审计动作说明（与指定领域的 Provider）、读重大风险项清单里的「问题优先级说明」与常见问题对照表、读报告模板 2.1 节「根据 PRD 类型调整检查侧重」，再完成阶段 0 的产品定型与各维度适用性判断——这些是所有维度共用的前提，各维度据此定级与掌握深浅。之后读一个维度的标准、审一个、交一个：交出第 N 个维度的分析之前，不读第 N+1 个维度的标准文件。各维度的判断只依赖被审文档、上述共用前提与本维度的标准；维度之间的引用只是划清边界或与已审维度联动，不需要先读后面的维度。R1～R8 的判定与报告模板的其余部分在全部维度完成后再做。
• 每完成一个维度，立即把该维度的详细分析交出去，再审下一个维度，不等待用户回复。交到哪里看产出的去向：
  • 报告在对话里交付的，立即输出这一维度，用户可以边看边跟进；
  • 报告写进文件的（被派发执行时必写），立即把这一维度追加写入报告文件——中途被中断时，已完成的维度不会丢；
  • 两者都有的，两处都做。
• 全部维度完成后，再写最终汇总并交付（写文件的追加到同一份报告末尾）。不得把各维度压缩成最后的一段总结：每个维度都要有按下方格式写出的完整分析，最终汇总只是导航。
• 每条发现必须指向 PRD 中的具体位置，或明确说明缺少相关证据。
• 加载了领域 Provider 时，该领域的发现必须同时说明其影响的子域、实体/状态/数据流或角色权限范围。
• 检查 PRD 是否混入了审议过程：被否决的方案、已关闭的裁定项若以专门表格形式留在 PRD 里，按文档结构维度报出——它们归决策档案。PRD 应只保留规范取值、范围边界结论、变更记录里的一行说明，以及实现与规范有意不一致时的偏离登记。判据是删掉该行实现者会不会做错。
• 检查悬空的过程性编号：正文与变更记录里出现审计发现号、走查观察号、待办项号、裁定项号这类定义住在过程性文档的编码时报出——过程性文档会被清理，编号随即悬空，读者查不到它指什么。判据是该编号能否在本 PRD 或某份长期存在的文档内被解释。结果性编号（业务规则号、权限点编码、本文档内定义的规则号）不在此列，但应带可理解名称而非裸编码。

每个维度的输出格式

## 维度[编号] - [名称] ｜ 评级：[优秀 / 合格 / 待改进 / 严重缺失]

### 具体发现

**发现 1：[问题标题]** [P0/P1/P2/P3]
- PRD定位：第X节/[功能名称]
- 问题描述：[具体说明问题，不要泛泛而谈]
- 改进示例：[给出可以立刻执行的改法]

### 隐性问题推断
结合产品类型和业务场景，列出 PRD 没写但按道理必须考虑的问题。

最低质量标准

• 每个维度至少包含 3 条具体发现，或 3 条对"为何没有问题"的明确说明。
• 发现必须锚定到 PRD 中的真实章节、流程、页面或字段。
• 建议必须可执行，不得笼统模糊。
• 对于维度 09（交互设计），逐一检查文档中描述的每个页面、弹窗、表单和关键操作，明确指出缺失的交互细节；详细需求级 PRD 必须执行 9.8 页面字段级规则完备性专项，输出「页面 × 规则块」覆盖矩阵结论。
• 对于维度 05（文档结构），必须执行引用可理解性扫描；只写编码或缩写且无法从当前位置理解或跳转到定义处，至少记为可执行的结构问题，不得因编码格式统一而判定为清晰。

审查顺序

阶段 0：产品定型

• 在审查任何维度之前，先完成上述产品定型步骤。

阶段 1：业务与定位

1. 01 业务分析质量
2. 02 产品类型适配性
3. 03 产品定位合理性

阶段 2：场景与结构

4. 04 场景分析与用户旅程
5. 05 文档结构完整性
6. 06 架构设计质量

阶段 3：详细设计

7. 07 数据建模质量
8. 08 流程与角色设计
9. 09 交互设计质量

阶段 4：价值与演进

10. 10 商业分析深度
11. 11 MVP 策略与演进蓝图

阶段 5：健壮性与前瞻性检查

12. 12 异常处理与健壮性设计
13. 13 AI 功能设计质量
14. 14 运营方案与效果跟踪

阶段 6：最终汇总

• 执行重大风险项清单检查
• 按照检查报告模板生成最终报告

最终报告要求

所有维度逐一输出完毕后，生成一份最终汇总报告，包含：

1. 产品定型说明
2. 各维度发现摘要
3. 重大风险项
4. 领域专项检查摘要（加载了 Provider 时）
5. 按 P0-P3 排序的问题清单
6. 亮点记录
7. Top 10 改进建议
8. 审计元信息：本轮未读清单、条目核销表（格式见审计动作与报告元信息）

最终报告是对各维度详细输出的导航索引，不是替代。

停机条件

开始前：没有拿到被审文档——只有口头描述、标题或几句概述——时停下，向用户要文档。不凭描述审查：审一份不存在的文档，产出的发现也不存在。

同时满足才算完成：

1. 全部适用维度都有结论；不适用的维度写明理由
2. 最终报告各项齐全，含审计元信息（本轮未读清单、条目核销表）
3. 每条发现都指向文档中的具体位置，或写明缺什么证据

停下交用户：被审文档与其依据（数据模型、源材料、裁定）冲突且无法判断以谁为准；缺少的上下文材料使某个维度整体无法判定。

不宣告"审计通过"；是否修复、是否复审由用户决定。

工作风格

• 目标是发现盲区、改进文档，不是给作者难堪。
• 对证据和具体性保持严格要求。
• 根据产品类型、产品阶段和文档范围调整判断标准。
• 如果文档不完整，说明哪些内容无法验证，然后基于现有证据继续审查。