技能介绍

要解决的问题

在需求从口头讨论走向实现的过程中，常见的失败并不是“代码写错了”，而是缺少可追溯的准入记录、对象映射不一致，以及原型页面被误当成业务闭环的证据。此时如果直接修改 spec.md、补齐缺失字段或推倒重写原型，很容易把猜测混入规范。另一个问题是评审产物散落在工作区，截图、回放日志、诊断脚本与最终结论混在一起，导致后续审计无法区分证据来源。

核心能力

speckit-review 将评审拆成 Spot、Delta、Formal、Recheck 四种模式：Spot 只给快速风险意见，Delta 只复审受影响对象，Formal 才生成可交给 Version 使用的正式凭证，Recheck 只验证上次阻断项。它会读取 command.md、证据与可追溯性文档、业务闭环契约、Spec 与 IA 评审参考，并按需读取 dimensions、adapters、templates、UX checklist 或原型的 interaction-state 与验收参考。

评审过程中，技能会检查规范性概念的来源引用与 user-confirmed 准入、CAP/FR/FLOW/STATE/TRANS/ENTITY/PAGE/VIEW/ACT/NAV 映射一致性、上下文操作是否缺少 IA 证据、范围外概念是否混入规范性 IA 或路由，以及输入产物是否过期。闭环判断以 transition 证据为准，页面、按钮或 toast 不能单独证明业务闭环；正式流程评审还必须逐节点回放并记录闭环矩阵与阻断项。

它还区分 SPEC_GAP、PROTOTYPE_GAP、PRESENTATION_ONLY 和 UNAUTHORIZED_BACKFLOW，不会因为原型已有实现就认定 Spec 缺失或自动补写。Formal 模式会运行 speckit-workspace/scripts/validate_spec_scope.py --spec /spec.md --strict，字段契约存在时还会运行 speckit-specify/scripts/validate_field_contract.py --feature-dir，逐字段审计来源、语义、数据、必填、约束、唯一性、访问、依赖、持久化、反馈和验收覆盖。

使用边界

评审对 spec 和原型只读，不得修改 spec.md、原型页面或业务对象，也不会自动切换版本或发布。截图、回放日志、诊断脚本和中间报告必须写入 .specify/work/review/，正式结论只写 review.md 及契约要求的证据目录。缺少 P0/P1 来源、存在无法解释的 IA 矛盾、输入过期或 transition 阻断时不能给出 Pass；未知内容只能标记为 open_question，不能伪装成已确认缺陷。