用途：spec-clarify 用于在规格产物完成后进行校验，弥补“格式正确”与“完整且已确认”之间的差距。它适用于三种上下文：AUTHORED-SPEC（idea-to-spec 新编写的 §1-8）、EXISTING-SPEC（spec-to-pbi 待分解的既有规范）、TEST-SPEC（idea-to-pbi 深度模式，精炼想法加 §8 测试用例）。
主要能力：Phase 0 检测上下文并确定提问预算；Step 0 解析产物、规格发现全景、原始想法、领域分析四项输入；Step 1 对照已发现系统做完整性检查，包括交叉引用、隐含覆盖、§8 测试用例、不变量与 UI 交互面；Step 2 按类别审计每个假设，分类为 OBVIOUS、NON-OBVIOUS 或 CONFLICTS；Step 3 头脑风暴会实质改变产物的问题并做对抗性预演；Step 4 对非显而易见、冲突及高影响项执行阻塞式用户确认；Step 5 将确认决策写回产物与决策日志；Step 6 通过 $why-review --validate-findings 校验自身发现，输出 CLARIFIED 或 NEEDS-AUTHORING-FIX。
使用方式：该技能在主代理上内联运行，而非子代理，因为确认环节需要直接向用户提问。执行时按声明顺序逐步进行，不得跳过、重排或合并步骤，除非用户明确批准。每步开始与结束需更新任务跟踪，并附简要证据或跳过原因。提问预算由 Spec Validation: questions=MIN-MAX 配置控制，每次提问不超过 4 个选项，推荐项优先。
适用场景：在规格产物已存在、且 artifact-review 与 why-review 已完成之后运行，用于补充两者都不做的两件事：对照已发现系统的完整性，以及对每个非显而易见决策的阻塞式用户确认。
限制：它不重复 artifact-review 的隔离检查（M1-M5 与 M7、AC 可测试性），也不重复 why-review 的决策理由校验。若缺少或过期的项目文档、发现全景，本身会作为 NEEDS-AUTHORING-FIX 发现。若所需步骤或工具在当前环境无法运行，应停止并询问用户。具体收费、价格、平台支持等信息暂未提供。