SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场openspec-verify-change

openspec-verify-change

测试与质量

查看项目

更新于 10-16 20:01

技能介绍

用途

openspec-verify-change 用于验证某项实现是否与 OpenSpec 变更产物（specs、tasks、design）相匹配。当用户希望在归档变更之前确认实现完整、正确且连贯时使用。

主要能力

技能围绕三个维度构建验证报告：

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

每个维度可包含 CRITICAL、WARNING、SUGGESTION 三个级别的 issue。

使用方式

Store 选择：如果用户指定了 store（store 是本机注册的独立 OpenSpec 仓库），或工作位于某个 store 中，先运行 openspec store list --json 发现已注册的 store id，然后在读写 specs 和 changes 的命令上传入 --store <id>（包括 new change、status、instructions、list、show、validate、archive、doctor、context、schemas、view）。选定后，--store <id> 在该工作流剩余部分保持粘性。其他命令不接受该标志。

项目检查：在第一个写入步骤（new change、archive、sync specs 或创建产物文件）之前，确认项目已有根：运行 openspec list --json（选定 store 时带上 --store <id>）并读取 root。root 对象表示项目已设置；"root": null 表示未设置。若状态错误信息以 Declared in 或 Invalid store declaration in 开头并指向本项目的 openspec/config.yaml（或 config.yml），表示项目通过其声明的 store 使用 OpenSpec，但本机无法解析该 store，此时不要当作未初始化，应在写入前停止并展示错误信息。

无 root 时的处理：取决于进入工作流的方式。自动选择（用户未提及 OpenSpec）时，停止使用 OpenSpec 并正常回答，不提示设置。显式请求（用户提及 OpenSpec 或运行其斜杠命令）时，写入前停止并询问用户如何继续（openspec init、--store <id> 或不用 OpenSpec）。两种情况均不得因副作用创建 root。

输入：可选指定变更名称。省略时从对话上下文推断；模糊时必须提示可用变更。显示有实现任务的变更，标注进行中的变更，并提示 "Using change: " 及覆盖方式。

验证流程

  1. 选择变更
  2. 运行 openspec status --change "<name>" --json 理解 schema（schemaName、planningHome、changeRoot、artifactPaths、actionContext 等）
  3. 运行 openspec instructions apply --change "<name>" --json 获取规划上下文并加载产物（读取 contextFiles 中所有可用产物）
  4. 初始化验证报告结构
  5. 验证完整性：解析 tasks 文件中的复选框（- [x]/- [X] 为完成，其余为未完成），统计完成与总数；提取规格中的需求（### Requirement:），搜索代码库关键词评估实现是否存在
  6. 验证正确性：为每个需求映射实现证据，记录文件路径与行范围；检查每个场景（#### Scenario:）的条件处理与测试覆盖
  7. 验证一致性：提取设计关键决策并核对实现，检查代码模式一致性（文件命名、目录结构、编码风格）
  8. 生成验证报告：包含汇总计分表、按优先级分组的问题列表、最终评估

报告与评估

报告包含 Summary 计分表，按 CRITICAL/WARNING/SUGGESTION 分组列出问题，每项带具体建议，代码引用格式为 file.ts:123。最终评估根据 issue 级别给出：有 CRITICAL 时提示归档前修复；仅有 warning 时提示可归档（附改进项）；全部通过时提示可归档。

验证启发式

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

优雅降级

  • 仅有 tasks.md：只验证任务完成度，跳过 spec/design 检查
  • 有 tasks + specs：验证完整性与正确性，跳过 design
  • 完整产物：验证全部三个维度

始终注明跳过了哪些检查及原因。

限制

资料未提供该技能的收费、价格、平台、效果或具体实现细节。