用途
pm-closure-validation 是一个 PM（产品负责人 / 发布经理）收尾验证技能，作为增量关闭前的最终质量闸门。它通过一套严格的三道门（3-gate）验证流程，确保增量在关闭前达到质量标准。
适用时机包括：
- 验证增量是否具备关闭条件
- 检查所有任务是否完成（按 P1、P2、P3 优先级）
- 核实测试覆盖率与测试通过情况
- 确保文档已更新（CLAUDE.md、README.md、CHANGELOG.md）
- 检测范围蔓延（实现过程中新增的额外任务）
- 在关闭增量前获得 PM 批准
- 理解增量完成的质量门标准
主要能力
该技能以产品负责人 / 发布经理角色运作，确保增量交付三方面价值：业务价值（所有关键任务完成）、质量（测试通过、无回归）、知识留存（文档已更新）。它会在批准关闭前验证全部三道门。
验证工作流
第 1 步：加载增量上下文
需要读取以下文件：
Read: .specweave/increments/{id}/spec.md
Read: .specweave/increments/{id}/plan.md
Read: .specweave/increments/{id}/tasks.md # Tests embedded in tasks.md
第 2 步：验证门 1 — 任务完成
检查清单：
- 所有 P1（关键）任务已完成
- 所有 P2（重要）任务已完成，或已附原因延期
- P3（锦上添花）任务已完成、延期或移入待办
- 没有处于“阻塞”状态的任务
- 每个任务的验收标准均已满足
第 3 步：验证门 2 — 测试通过
检查清单：
- 所有测试套件通过（无失败）
- 测试覆盖率达到目标（关键路径默认 80%+）
- E2E 测试通过（如存在 UI）
- 没有未记录说明的跳过测试
- 测试用例与 spec.md 中的验收标准一致
该步骤会要求用户运行测试并分享结果：
npm test # Run all tests
npm run test:coverage # Check coverage
第 4 步：验证门 3 — 文档已更新
检查清单：
- CLAUDE.md 已更新新功能
- README.md 已更新使用示例
- CHANGELOG.md 已更新（如公共 API 变更）
- API 文档已重新生成（如适用）
- 内联代码文档完整
- 没有对旧代码的过时引用
该步骤会扫描文件：
Read: CLAUDE.md
Read: README.md
Read: CHANGELOG.md
Grep: Search for references to new features
第 5 步：PM 决策
如果三道门全部通过，输出“READY TO CLOSE”，汇总交付的业务价值、已满足的验收标准，并给出后续步骤（更新增量状态、设置完成日期、生成完成报告、将延期的 P2 任务转入待办、更新活文档）。
如果任意一道门失败，输出“NOT READY TO CLOSE”，列出阻塞项、修复所需预估工时与行动计划，增量状态保持 in-progress。
范围蔓延检测
当 tasks.md 中的任务数显著多于原计划时触发。技能会对比原始计划（spec.md）与当前状态（tasks.md），列出实现期间新增的任务，并提供选项：
- A）接受范围增长，带全部任务关闭
- B）将新任务移入下一个增量，按原任务数关闭
- C）拆分为两个增量（推荐）
并给出最佳实践：若新任务带来明确价值可接受范围增长；若范围翻倍或三倍则拆分为两个增量；记录经验教训以改进未来估算。
验证模板
技能为三道门分别提供输出模板：
- 门 1：任务完成模板（按优先级统计完成比例、列出未完成的 P1 任务与延期的 P2 任务）
- 门 2：测试通过模板（单元/集成/E2E 通过数、覆盖率、失败详情与修复建议）
- 门 3：文档模板（各文档状态与更新或缺失详情）
使用方式
该技能在 /sw:done 之前使用，用于验证增量是否就绪。相关命令包括：
/sw:done {increment-id}— 触发 PM 收尾验证/sw:status {increment-id}— 查看增量状态/sw:validate {increment-id}— 运行验证检查/sw:check-tests {increment-id}— 验证测试覆盖率
相关技能包括：increment-planner（创建含验收标准的 spec.md）、test-aware-planner（生成内嵌测试的 tasks.md）、architect（设计技术方案 plan.md）。
适用场景
适用于采用 SpecWeave 增量工作流的项目，在增量关闭前由 PM 角色执行最终质量把关，尤其适合需要同时保证任务完成度、测试质量与文档同步的团队。
限制与最佳实践
- 三道门必须全部通过，无例外，质量不可妥协。
- 反馈需具体：包含文件路径、行号、具体测试失败与修复预估工时。
- 工时估算参考：小修复 < 1 小时，中等修复 1-3 小时，大修复 4-8 小时。
- 需尽早检测范围蔓延。
- 批准关闭时需记录业务价值。
- 开始工作前应检查项目特定的经验记录（原文在此处截断，具体内容暂未提供）。