mcpField

openspec-verify-change

github.com/wh1024k测试与质量124 次安装
代码仓库

关于 openspec-verify-change

openspec-verify-change 是用于核对实现是否符合 OpenSpec 变更制品的技能。它检查任务、需求、场景、设计决策和代码模式，并生成按优先级整理的验证报告。

主要功能

  1. 01检查任务与需求覆盖情况
  2. 02审查实现和场景覆盖
  3. 03核对设计决策遵循情况
  4. 04检查代码模式一致性
  5. 05生成优先级验证报告

适用场景

  1. 01归档前核验变更
  2. 02查找未完成的实现任务
  3. 03对照代码与变更需求

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/wh1024k/openspec --skill openspec-verify-change

安装后在 Claude Code 中输入/openspec-verify-change确认已加载。

详细介绍

验证实现是否与变更产物（规范、任务、设计）一致。

存储库选择： 如果用户指定了存储库（存储库是本机上注册的独立 OpenSpec 仓库），或工作所在的位置属于某个存储库，请运行 openspec store list --json 以查找已注册的存储库 ID，然后在读取或写入规范和变更的命令（new change、status、instructions、list、show、validate、archive、doctor、context）中传入 --store <id>。其他命令不接受此标志。命令打印的提示已包含该标志；后续命令中也要保留它。如果没有指定存储库，命令会作用于最近的本地 openspec/ 根目录。

输入：可以选择指定一个变更名称。如果未指定，请检查是否可以从对话上下文中推断。如果含糊不清或存在歧义，你必须询问用户有哪些可用变更。

步骤

  1. 如果未提供变更名称，请提示用户选择

    运行 openspec list --json 以获取可用变更。使用 AskUserQuestion 工具让用户选择。

    显示包含实现任务的变更（即存在 tasks 产物）。 如果有可用的 schema，请一并显示。 将任务未完成的变更标记为“（进行中）”。

    重要：不要猜测或自动选择变更。始终让用户选择。

  2. 检查状态以了解 schema

    openspec status --change "<name>" --json

    解析 JSON 以了解：

    • schemaName：所用的工作流（例如，“spec-driven”）
    • planningHome、changeRoot、artifactPaths 和 actionContext：路径和作用范围上下文
    • 此变更中存在哪些产物

  3. 获取规划上下文并加载产物

    openspec instructions apply --change "<name>" --json

    这会返回变更目录和 contextFiles（产物 ID -> 具体文件路径数组）。读取 contextFiles 中所有可用的产物。

  4. 初始化验证报告结构

    创建包含三个维度的报告结构：

    • 完整性：跟踪任务和规范覆盖情况
    • 正确性：跟踪需求实现和场景覆盖情况
    • 一致性：跟踪设计遵循情况和模式一致性

    每个维度都可以包含 CRITICAL、WARNING 或 SUGGESTION 级别的问题。

  5. 验证完整性

    任务完成情况：

    • 如果 contextFiles.tasks 存在，读取其中的每个文件路径
    • 解析复选框：- [ ]（未完成）与 - [x]（已完成）
    • 统计已完成任务数和任务总数
    • 如果存在未完成任务：
      • 为每项未完成任务添加 CRITICAL 级别问题
      • 建议：“完成任务：”或“如果已实现，则标记为已完成”

    规范覆盖情况：

    • 如果 contextFiles.specs 中存在差异规范：
      • 提取所有需求（以“### Requirement:”标记）
      • 对于每项需求：
        • 在代码库中搜索与该需求相关的关键词
        • 评估实现是否可能已存在
      • 如果需求似乎尚未实现：
        • 添加 CRITICAL 级别问题：“未找到需求：”
        • 建议：“实现需求 X：”

  6. 验证正确性

    需求实现映射：

    • 对于差异规范中的每项需求：
      • 搜索实现证据
      • 如果找到，记录文件路径和行范围
      • 评估实现是否符合需求意图
      • 如果发现偏差：
        • 添加 WARNING：“实现可能与规范不一致：
          ”
        • 建议：“对照需求 X 检查 :”

    场景覆盖情况：

    • 对于差异规范中的每个场景（以“#### Scenario:”标记）：
      • 检查代码是否处理了相关条件
      • 检查是否存在覆盖该场景的测试
      • 如果场景似乎未覆盖：
        • 添加 WARNING：“未覆盖场景：”
        • 建议：“为以下场景添加测试或实现：”

  7. 验证一致性 设计遵循情况：

    • 如果存在 contextFiles.design：
      • 提取关键决策（查找类似「Decision:」「Approach:」「Architecture:」的部分）
      • 验证实现是否遵循这些决策
      • 如果发现矛盾：
        • 添加 WARNING：「未遵循设计决策：」
        • 建议：「更新实现，或修改 design.md 使其与实际情况一致」
    • 如果没有 design.md：跳过设计遵循情况检查，并注明「没有 design.md 可供核对」

    代码模式一致性：

    • 检查新增代码是否与项目模式一致
    • 检查文件命名、目录结构和编码风格
    • 如果发现明显偏差：
      • 添加 SUGGESTION：「代码模式偏差：
        」
      • 建议：「考虑遵循项目模式：」

  8. 生成验证报告

    摘要评分卡：

    ## Verification Report: <change-name>

### Summary
| Dimension    | Status           |
|--------------|------------------|
| Completeness | X/Y tasks, N reqs|
| Correctness  | M/N reqs covered |
| Coherence    | Followed/Issues  |

    按优先级分类的问题：

    1. CRITICAL（归档前必须修复）：

      • 未完成的任务
      • 缺少需求实现
      • 每项都要提供具体、可执行的建议

    2. WARNING（应当修复）：

      • 规范/设计偏差
      • 场景覆盖不足
      • 每项都要提供具体建议

    3. SUGGESTION（建议修复）：

      • 模式不一致
      • 次要改进
      • 每项都要提供具体建议

    最终评估：

    • 如果存在 CRITICAL 问题：「发现 X 个严重问题。请在归档前修复。」
    • 如果只有警告：「没有严重问题。还有 Y 个警告需要考虑。可以归档（请注意所列改进项）。」
    • 如果全部通过：「所有检查均已通过。可以归档。」

验证启发式

  • 完整性：重点检查客观的清单项（复选框、需求列表）
  • 正确性：使用关键词搜索、文件路径分析和合理推断——不要求完全确定
  • 一致性：查找明显的不一致之处，不要过分挑剔风格
  • 误报：不确定时，优先标记为 SUGGESTION，而不是 WARNING；优先标记为 WARNING，而不是 CRITICAL
  • 可操作性：每个问题都必须附有具体建议，并尽可能注明文件/行号

优雅降级

  • 如果仅存在 tasks.md：只验证任务完成情况，跳过规范/设计检查
  • 如果存在 tasks 和 specs：验证完整性和正确性，跳过设计检查
  • 如果存在全部制品：验证全部三个维度
  • 始终注明跳过了哪些检查及原因

输出格式

使用清晰的 Markdown，包括：

  • 使用表格展示摘要评分卡
  • 按类别分组列出问题（CRITICAL/WARNING/SUGGESTION）
  • 代码引用格式：file.ts:123
  • 提供具体、可执行的建议
  • 不要使用「考虑检查一下」之类含糊的建议

测试更新22

评论

支持 Markdown