用途：该技能用于在归档前验证某项变更的实现是否完整、正确且与变更工件协调一致。若用户指定了变更名则直接使用，否则可从对话上下文推断、在仅有一个活跃变更时自动选择，信息模糊时必须提示用户从可用变更中选择。
主要能力：
- 完整性检查：读取 tasks 工件中的复选框，统计已完成数与总数，未完成任务列为 CRITICAL；从 delta specs 中提取以“### Requirement:”标记的需求，搜索代码库关键词判断实现是否存在，疑似未实现的列为 CRITICAL。
- 正确性检查：将每条需求映射到代码实现证据（记录文件路径与行号范围），出现偏离时给出 WARNING；对每个“#### Scenario:”场景检查代码条件处理与测试覆盖，未覆盖时给出 WARNING。
- 一致性检查：若存在 design 工件，提取其中的关键决策并核对实现是否遵循，冲突时给出 WARNING；无 design.md 时跳过该项并注明；审查新代码在文件命名、目录结构、编码风格上是否符合项目模式，明显偏差给出 SUGGESTION。
使用方式：先通过 openspec status --change "<name>" --json 解析 schemaName、路径上下文及存在的工件，再用 openspec instructions apply --change "<name>" --json 获取 contextFiles 并读取全部工件，随后按上述三个维度验证，最后输出 Markdown 格式的验证报告，包含摘要计分表（完整性 X/Y 任务、N 项需求；正确性 M/N 需求覆盖；一致性 遵循/问题）、按优先级分组的问题列表、形如 file.ts:123 的代码引用以及具体可执行的建议。若用户指定了已注册的 store，需先运行 openspec store list --json 获取 id，并在读取或写入规格与变更的相关命令上追加 --store <id>，该参数在工作流余下部分保持粘性；未指定 store 时命令作用于最近的本地 openspec/ 根目录。
适用场景：在 OpenSpec 驱动的规格先行开发流程中，于归档变更之前进行实现核对，帮助发现未完成任务、缺失需求实现、未覆盖场景、设计与实现脱节及代码风格偏差。
限制：正确性判断依赖关键词搜索与合理推断，不要求完全确定；不确定时优先降级为 SUGGESTION 而非 WARNING 或 CRITICAL。工件不全时逐步降级：仅有 tasks.md 时只验证任务完成情况，tasks 与 specs 并存时验证完整性与正确性，完整工件才验证三个维度，并需注明跳过哪些检查及原因。最终评估规则为：存在 CRITICAL 问题则须在归档前修复；仅有警告则无严重问题、可在记录改进的前提下归档；全部通过则可直接归档。建议须具体可执行，避免“考虑审查”之类含糊表述。