openspec-verify-change

用途

openspec-verify-change 用于验证某项实现是否与对应的变更工件（specs、tasks、design）相匹配。当用户希望在归档（archive）之前确认实现是完整的、正确的且连贯的，可以使用该技能。

主要能力

该技能围绕三个维度组织验证：

• 完整性（Completeness）：跟踪任务与规格覆盖情况。
• 正确性（Correctness）：跟踪需求实现与场景覆盖情况。
• 一致性（Coherence）：跟踪设计遵循情况与模式一致性。

每个维度可产生 CRITICAL、WARNING 或 SUGGESTION 级别的问题。

使用方式

输入：可选地指定一个变更名称。如果省略，则检查是否可以从对话上下文中推断。如果模糊或不确定，必须提示用户从可用变更中选择。

步骤：

1. 如果未提供变更名称，则提示选择。运行 openspec list --json 获取可用变更，使用 AskUserQuestion 工具让用户选择。展示带有实现任务（存在 tasks 工件）的变更，如可用则包含每个变更使用的 schema，将任务未完成的变更标记为 "(In Progress)"。重要：不要猜测或自动选择变更，始终让用户选择。

2. 检查状态以了解 schema。运行 openspec status --change "<name>" --json，解析 JSON 以了解 schemaName（使用的工作流，例如 "spec-driven"）以及该变更存在哪些工件。

3. 获取变更目录并加载工件。运行 openspec instructions apply --change "<name>" --json，返回变更目录和上下文文件，从 contextFiles 读取所有可用工件。

4. 初始化验证报告结构，包含三个维度：完整性（跟踪任务与规格覆盖）、正确性（跟踪需求实现与场景覆盖）、一致性（跟踪设计遵循与模式一致性）。

5. 验证完整性：

   • 任务完成情况：如果 contextFiles 中存在 tasks.md，读取并解析复选框 - [ ]（未完成）与 - [x]（已完成），统计完成数与总数。若存在未完成任务，为每个未完成任务添加 CRITICAL 问题，建议 "Complete task: " 或 "Mark as done if already implemented"。
   • 规格覆盖：如果 openspec/changes/<name>/specs/ 中存在增量规格，提取所有需求（以 "### Requirement:" 标记）。对每个需求，在代码库中搜索相关关键词，评估实现是否可能存在。若需求似乎未实现，添加 CRITICAL 问题 "Requirement not found: "，建议 "Implement requirement X: "。

6. 验证正确性：

   • 需求实现映射：对增量规格中的每个需求，在代码库中搜索实现证据。若找到，记录文件路径与行范围，评估实现是否匹配需求意图。若检测到偏差，添加 WARNING "Implementation may diverge from spec: "，建议 "Review : against requirement X"。
   • 场景覆盖：对增量规格中的每个场景（以 "#### Scenario:" 标记），检查代码中是否处理了条件，检查是否存在覆盖该场景的测试。若场景似乎未覆盖，添加 WARNING "Scenario not covered: "，建议 "Add test or implementation for scenario: "。

7. 验证一致性：

   • 设计遵循：如果 contextFiles 中存在 design.md，提取关键决策（查找 "Decision:"、"Approach:"、"Architecture:" 等部分），验证实现是否遵循这些决策。若检测到矛盾，添加 WARNING "Design decision not followed: "，建议 "Update implementation or revise design.md to match reality"。如果没有 design.md，跳过设计遵循检查，注明 "No design.md to verify against"。
   • 代码模式一致性：审查新代码是否与项目模式一致，检查文件命名、目录结构、编码风格。若发现显著偏差，添加 SUGGESTION "Code pattern deviation: "，建议 "Consider following project pattern: "。

8. 生成验证报告：

   • 摘要记分卡，包含维度与状态表格（完整性 X/Y tasks, N reqs；正确性 M/N reqs covered；一致性 Followed/Issues）。
   • 按优先级分组的问题：CRITICAL（归档前必须修复，如未完成任务、缺失需求实现，每条附具体可操作建议）、WARNING（应当修复，如规格/设计偏差、缺失场景覆盖）、SUGGESTION（可选修复，如模式不一致、次要改进）。
   • 最终评估：若有 CRITICAL 问题，输出 "X critical issue(s) found. Fix before archiving."；若仅有警告，输出 "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."；若全部通过，输出 "All checks passed. Ready for archive."。

验证启发式

• 完整性：聚焦客观清单项（复选框、需求列表）。
• 正确性：使用关键词搜索、文件路径分析、合理推断，不要求完全确定。
• 一致性：寻找明显不一致，不纠结风格细节。
• 误报处理：不确定时，优先 SUGGESTION 而非 WARNING，优先 WARNING 而非 CRITICAL。
• 可操作性：每个问题都必须有具体建议，并在适用时附带文件/行引用。

优雅降级

• 如果只有 tasks.md：仅验证任务完成情况，跳过规格/设计检查。
• 如果存在 tasks + specs：验证完整性与正确性，跳过设计。
• 如果工件齐全：验证全部三个维度。
• 始终注明哪些检查被跳过以及原因。

输出格式

使用清晰的 markdown，包含：摘要记分卡表格、按 CRITICAL/WARNING/SUGGESTION 分组的问题列表、代码引用格式 file.ts:123、具体可操作的建议。避免 "consider reviewing" 之类的模糊建议。

适用场景

适用于使用 OpenSpec 工作流、希望在归档变更前对实现进行系统性验证的开发者。

限制

该技能依赖 OpenSpec 命令（openspec list、openspec status、openspec instructions apply）与变更目录结构。若缺少相应工件，会按优雅降级规则跳过部分检查。关于收费、价格、平台支持等信息，资料中暂未提供。