用途：验证某次变更的实现是否完整、正确且与变更工件（specs、tasks、design）保持一致，通常在归档前使用。
主要能力：按三个维度核查——完整性（任务勾选状态、规格覆盖）、正确性（需求是否有实现证据、场景是否有测试覆盖）、一致性（是否符合 design 中的决策、代码模式是否统一）。输出 Markdown 验证报告，含汇总计分表，并按 CRITICAL、WARNING、SUGGESTION 分组列出问题及可操作建议，代码引用格式为 file.ts:123。问题判定采用启发式，不确定时倾向较低严重级别。支持优雅降级：仅有 tasks.md 时只查任务完成度；有 tasks+specs 时查完整性与正确性；工件齐全时查三个维度，并说明跳过了哪些检查。
使用方式：可指定 change 名称；未指定时从会话上下文推断、或唯一活动变更时自动选择，含糊则用 openspec list --json 列出并让用户选择。若使用已注册的 store，需先执行 openspec store list --json 获取 id，再在读取或写入 specs、changes 的命令上加 --store <id>，且该标志对后续步骤保持有效。随后运行 openspec status --change "<name>" --json 了解 schemaName 与各工件路径，再用 openspec instructions apply --change "<name>" --json 获取 contextFiles 并读取全部工件，据此生成报告。
适用场景：OpenSpec 驱动的规范化开发流程，在归档前自查实现与规格、任务的对应关系。
限制：需在装有 OpenSpec 并存在变更目录的环境中使用；验证依赖关键词搜索与合理推断，不要求绝对确定，可能产生误报；无 design.md 时跳过设计一致性检查。具体命令、分类与评分细节以官方资料为准，其他事实暂未提供。