用途：在归档规格驱动变更前进行验证，确认变更完整、实现正确且与规格一致。
前提：项目根目录需存在 .spec-driven/ 目录，可用 ls .spec-driven/ 检查；若失败说明项目未初始化，需先运行 /spec-driven-init。
主要步骤：
- 选择变更：运行 node {{SKILL_DIR}}/scripts/spec-driven.js modify 列出活动变更并询问要验证哪个。
- 格式检查：运行 node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>，报告错误（阻塞）与警告（非阻塞）；若提示 tasks.md 缺少 ## Testing 段，升级为 CRITICAL。
- 任务完成检查：运行 node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>，若 remaining > 0，列出未完成任务，视为 CRITICAL。
- 开放问题检查：读取 .spec-driven/changes/<name>/questions.md，扫描 - [ ] Q: 条目，任何未回答问题均为 CRITICAL。
- 实现证据检查：对每个已完成任务，确认应改动的代码或文件确实存在，无可见证据记为 WARNING。
- 规格一致性检查：读取 .spec-driven/specs/、config.yaml、proposal.md 及 changes/<name>/specs/ 下所有文件，核对实现与提案是否一致；delta 文件是否准确描述实现（空 specs/ 却有真实行为变更为 CRITICAL）；delta 文件路径是否与主规格文件对应（不匹配会导致合并失败）；是否使用标准格式（### Requirement: <name>、RFC 2119 关键词、#### Scenario: 块），不符合为 CRITICAL；config.yaml 的 rules（含 fileMatch）违规为 WARNING；proposal.md 的 Unchanged Behavior 若被违反为 CRITICAL。
输出：分级报告，含 CRITICAL（阻塞归档）、WARNING（应处理）、SUGGESTION（可选改进），并建议下一步：有 CRITICAL 先处理；仅有 WARNING 询问用户是否处理或继续；无问题则建议 /spec-driven-review <name>。
限制：需诚实评估，不能仅因任务被勾选就通过；CRITICAL 指会导致变更错误或不完整的问题，WARNING 降低信心但不一定阻塞，SUGGESTION 为可选质量改进。