spec-kit-checklist

审核变更产物中的需求质量。这是一个需求检查工具，不是测试运行器： 如果规格是用英语编写的代码，那么检查清单就是它的单元测试套件。

输入：可选地指定变更名称和检查清单的关注重点（例如“安全”或“结账流程的 UX”）。如果未指定变更，请根据上下文推断或询问。

所有权：此技能编写的检查清单归审核者所有。 勾选表示审核者判定该需求质量标准已满足；绝不表示实现工作已完成。 此技能会创建未勾选的条目，且绝不会替用户勾选；仅当审核者提出要求时，才可协助评估这些条目。 checklists/requirements.md 是由 spec-kit-specify 和 spec-kit-clarify 维护的规格质量检查清单，不属于此类检查清单。

步骤

1. 加载产物

   加载 specs/changes/<name>/ 下存在的文件：

   • spec.md、plan.md、tasks.md

   另加载 FRAMEWORK.md，以确保符合指导原则。 仅加载与检查清单关注重点相关的部分；对于较长的章节，应予以概述，而非照搬。

2. 最多提出 3 个澄清问题（请求中已回答的问题除外）

   根据请求和产物推导问题，不要使用固定问题目录；且只有答案会改变检查清单时才提问：

   • 范围——包含哪些领域或集成。
   • 风险——哪些风险需要列为强制检查项。
   • 深度——简单的自查、正式审核，还是发布门禁。
   • 受众——作者、审核者还是 QA。
   • 排除项——此次刻意不纳入的内容。

   如果已安装 ask-question 技能，请通过它提供选项。 如果无人能回答，则默认采用标准深度、审核者作为受众，并选择最相关的两个关注领域。

3. 生成需求质量检查清单

   在 specs/changes/<name>/checklists/ 中创建或更新按领域命名的文件（例如 api.md、ux.md、security.md）。 新文件从 CHK001 开始；现有文件则从最后一个 CHK ID 继续追加。绝不删除或替换现有条目。

   文件结构：标题、用途和日期、说明勾选由审核者负责的备注、按质量维度划分的 ## 章节，以及格式为 - [ ] CHK001 <question> [Dimension, Spec §FR-01] 的条目。

   每个检查清单条目必须：

   • 以问题形式询问产物中写明（或未写明）的内容：“是否为 [场景] 定义了 [需求方面]？”
   • 包含质量维度标签：[Completeness]、[Clarity]、[Consistency]、[Measurability]、[Coverage]、[Edge Case]、[Gap]、[Ambiguity]、[Conflict]、[Assumption]、[Dependency]
   • 通过标识符引用来源：[Spec §FR-03]、[Spec §US-2]、[Plan §Data Models]，或对缺失的需求标记为 [Gap]

   需要覆盖的质量维度：

   • 完整性——是否包含所有必要需求？
   • 清晰度——术语是否明确且可客观衡量？
   • 一致性——需求之间是否存在矛盾？
   • 可测量性——是否可以在不依赖解释的情况下验证每个需求场景？
   • 覆盖范围——是否涵盖主要流程、替代流程、异常流程和恢复流程？是否已明确每个变更界面在边缘情况下的状态？
   • 非功能性——是否包含性能、安全、无障碍和规模方面的需求？
   • 依赖项和假设——是否已记录并验证？

   对于状态会发生变化的情形，应询问是否说明回滚和部分失败的处理方式。 如果候选条目超过约 40 项，应保留风险最高的条目并合并相近项；将多个影响较低的边缘情况合并为一项。 ❌ 禁止——这类问题测试的是实现：“验证按钮是否可以点击”“测试 API 是否返回 200”“确认页面是否显示三张卡片”，以及任何涉及代码运行、渲染或导航的内容。 ✅ 必须——这类问题测试的是需求：“图片加载失败时是否定义了回退行为？[Edge Case, Gap]”“是否用具体阈值量化了‘快速’？[Clarity, Spec §SC-02]”“所有交互元素的悬停状态要求是否一致？[Consistency]”

4. 报告

   生成摘要：

   • 清单路径、条目数量，以及文件是新建还是追加内容
   • 选择的关注领域、深度和受众
   • 各维度的条目总数
   • 高优先级缺口
   • 阻止继续使用 spec-kit-plan 或 spec-kit-implement 技能的条目

防护措施

• 永不删除现有清单条目——只能追加。
• 永不勾选条目；勾选由审核者负责。
• 清单条目的可追溯性保持在 ≥80%。
• 将 FRAMEWORK.md 原则方面的缺口标记为 CRITICAL。
• 此技能审查的是需求，而非代码行为。