用途
Plan readiness review 用于对 PRD、计划、规格说明、RFC、设计文档或实施计划进行对抗式评审，回答一个决定性问题：一位未参加任何会议的有能力的资深工程师，能否在不自行发明任何内容的情况下正确实现该计划？任何实施者必须自行决定的内容都被视为计划中的缺口，而不是留待后续处理的细节——实施者的猜测就是由恰好接手该工单的人做出的未经评审的产品决策。
该技能强调：批准一个薄弱计划是代价高昂的失败模式。被拒绝的计划只花费一天；一个含糊的计划进入生产环境则会导致重写。因此评审偏向 NOT READY，并精确说明什么会改变判定。
主要能力
阶段 0 — 输入契约
在深入阅读之前，先声明评审对象。若以下任何一项未知且无法推断，则一次性询问，然后基于可用信息继续，并将其余部分标记为范围限制：评审对象（路径、文档 URL、工单 ID）及其版本或日期；明确不在本次评审范围内的内容；目标类型（全新项目、对现有系统的变更或集成）；是否已有代码（若有，本技能仅覆盖计划，代码问题属于 production-readiness-review）；开放产品问题的决策人（具体到人，而非团队）。
阶段 1 — 需求清单
在评判任何需求之前，先将每条需求、验收标准和隐含义务提取为编号清单。使用稳定 ID（R-001、R-002……），跨多次运行保持稳定，以便第二次评审显示差异而非新列表。每行携带来源锚点（§3.2、p4、PROJ-123、行号）；无锚点意味着是推断而非陈述，标记为 [implied]，而隐含需求本身就是一项发现。将散文中隐藏的义务（“自然这是要审计的”“应该很快”）作为一等需求捕获。将非功能需求、迁移/回填步骤和发布步骤也作为需求纳入。该清单的数量是后续所有百分比的分母。
阶段 2 — 逐需求就绪测试
对每条需求按七项检查评分，全部通过才为 READY，否则为 GAP（或在答案位于未获访问权限的系统或文档中时为 UNVERIFIABLE，并记录所需内容）：
- 无歧义——只有一种合理解读。
- 可测试验收标准——陈述可观察结果与阈值，而非意图。“快”不合格；“当前数据集上 50 rps 时 p95 < 300 ms”合格。
- 数据与模式已定义——实体、字段、类型、可空性、默认值、保留策略、状态存放位置，包括现有行的迁移与回填。
- 契约已定义——API 形状、事件模式或 UI 状态，包括认证、分页、幂等性和版本控制（如相关）。
- 错误行为已定义——无效输入、依赖失败、超时、部分写入和并发访问时的行为。“优雅地处理错误”是缺口。
- 非功能边界——负载、延迟、数据量、并发、保留、成本限制（当需求对其中任何一项敏感时）。
- 决策归属——不将产品或架构选择留给实施者。若有意委托，计划必须说明并指明实施者可选择的边界。
阶段 3 — 横向扫描
逐需求评审会遗漏需求之间的内容，因此对整体计划执行以下扫描：一致性（需求相互矛盾或与架构部分矛盾，引用双方）；排序与依赖（在外部团队、供应商、合同或数据迁移落地前无法开始的工作，未排序的依赖是交付风险，即使每条需求单独清晰也应标为 High）；安全设计（跨越的信任边界、每个新表面的认证/授权、租户与数据隔离、密钥处理、PII 分类与保留、审计追踪、边界输入验证、第三方数据流）；失败与恢复（降级模式、重试内容、幂等内容、需要死信路径的内容、凌晨 3 点人工需做什么）；可观测性（计划预见的每种失败模式对应的揭示信号，无信号的失败模式在生产中不可检测）；现有行为（当前可用但可能被破坏的内容：共享表、共享端点、变更契约的消费者、缓存数据、权限）；发布、开关、回滚（开关默认值、暗发布、退出路径，以及任何不可逆步骤如模式删除、数据删除、外部写入；无退出计划的不可逆步骤为 Critical）；合规与监管钩子（当领域暗示时，如 UK GDPR、DORA、NIS2、SOC 2、NCSC/NIST 指南，指明具体义务而非框架）。
阶段 4 — 证伪通过
确认文档包含什么不是评审。执行三种刻意攻击并报告各自产生的结果：字面实现（以最懒惰的合规方式完全按计划实现，哪里会产生作者会拒绝的东西，该缺口即为欠规范）；双工程师分歧（选取三条最重大的需求，为每条描述两种可辩护但不兼容的实现，任何容易产生分歧的需求都未达到可实施就绪）；恶意输入与滥用（恶意已认证用户、敌对租户、重放请求、100 倍载荷，哪条需求没有答案）。
严重级别标准
- Critical：会发布安全或数据完整性缺陷——未定义的授权/隔离、敏感数据的未定义数据处理、无退出计划的不可逆步骤，或两种解读在数据是否丢失上不同的需求。
- High：按书面内容实质上无法实施——实施者必须发明契约、模式、行为或验收标准；矛盾需求；未排序的硬依赖；主路径上缺失失败行为。
- Medium：可实施但可能被做错或返工——模糊阈值、边缘情况覆盖薄弱、缺少可观测性、归属不清。
- Low：清晰度、结构、命名或文档债务，不影响构建内容。
输出规则
每条问题按：严重级别 → 需求/领域 → 证据（锚点）→ 缺口 → 所需修复。所需修复是对计划的具体编辑（“为 POST /v1/x 添加响应模式和错误码”），而非“澄清这一点”。绝不在没有计数的情况下输出百分比，例如：计划完成度：71%（32/45 条需求 READY；9 条 GAP，4 条 UNVERIFIABLE）。未检查的需求为 UNVERIFIABLE 并附原因，绝不计为就绪。未解决的假设单独登记：假设、为何无法从计划推导、建议的默认值、必须决策的负责人、延迟决策的成本。绝不通过猜测解决产品问题，也绝不悄悄更改需求以使计划一致——提出更改并标记为需要决策。判定规则：只要存在未解决的 Critical 或 High 问题即 NOT READY，不提供部分批准或“有保留地就绪”，并给出会翻转判定的确切编辑列表。
修复计划
若被要求修复计划而非仅评审，按严重级别顺序逐项处理，并重写计划文本本身——评审评论不是修复。每次编辑后，对受影响需求重新运行阶段 2 并更新计数。产品决策保留在未解决登记表中，直到指定负责人回答；不要通过写入一个看似合理的答案来清除它们。代码存在后交接给 production-readiness-review。
适用场景与限制
适用于需要判断 PRD、计划、规格、RFC、设计文档或实施计划是否可实施就绪的场景，尤其适合在进入开发前进行对抗式评审。限制：该技能仅覆盖计划，不覆盖代码；若已有代码，代码问题属于 production-readiness-review。评审需要访问相关系统或文档才能验证某些需求，否则标记为 UNVERIFIABLE。该技能不通过猜测解决产品问题，也不提供部分批准。