用途：在归档变更前，验证代码实现是否与变更产物（specs、tasks、design）匹配，确认实现完整、正确且前后一致。
主要能力：
- 完整性检查：读取 tasks.md，解析复选框统计完成与未完成任务；从 delta specs 提取需求（### Requirement:），搜索代码库判断是否已实现。
- 正确性检查：将每条需求映射到实现证据（文件路径与行范围），检查场景（#### Scenario:）是否在代码与测试中被覆盖。
- 一致性检查：若存在 design.md，核对实现是否遵循其中的决策；检查新代码与项目命名、目录结构、编码风格是否一致。
- 输出分级报告：按 CRITICAL、WARNING、SUGGESTION 分组，附具体可执行的建议与 file.ts:123 形式的引用，并给出最终评估（是否可归档）。
使用方式：
- 可选指定变更名称；若省略则尝试从对话上下文推断，模糊时必须提示用户选择，不得猜测或自动选择。
- 运行 openspec list --json 获取可用变更，用 AskUserQuestion 让用户选择，展示含实现任务的变更并标记未完成项为“(In Progress)”。
- 运行 openspec status --change "<name>" --json 了解 schemaName 与存在的产物。
- 运行 openspec instructions apply --change "<name>" --json 获取变更目录与上下文文件，读取全部产物。
适用场景：变更归档前的质量把关，尤其是采用 spec-driven、tdd 等工作流的项目。
限制与降级：仅有 tasks.md 时只校验任务完成度；tasks 与 specs 同时存在时校验完整性与正确性，跳过设计检查；产物齐全时校验三个维度。无 design.md 时跳过设计一致性检查并注明。判断不确定时优先降级为 SUGGESTION 而非 WARNING 或 CRITICAL。具体收费、平台支持等信息暂未提供。