spec-kit-clarify

通过有针对性的连续提问，消除功能规格中的歧义。

输入：可选指定变更名称。如果省略，请根据上下文推断或询问。 用户补充的其他内容均作为确定问题优先级的上下文。

在 spec-kit-plan 之前运行此步骤。 如果用户明确跳过此步骤（例如进行探索性试验），则继续，但要提醒用户：这会增加后续返工的风险。

步骤

1. 选择变更

   如果 specs/changes/ 下只有一个目录，则自动选择；否则询问用户。

2. 加载 specs/changes/<name>/spec.md

   如果文件不存在，请提示用户先使用 spec-kit-specify 技能；绝不要在此处创建规格。 同时阅读 FRAMEWORK.md（如存在，也要阅读 FRAMEWORK.local.md），了解答案必须遵守的约束。

3. 扫描歧义

   按优先级顺序，将每个类别标记为 Clear、Partial 或 Missing：

   • 功能范围——目标、范围外声明、边界或行为不明确之处、角色
   • 领域与数据——实体、身份与唯一性、状态与转换、数据量
   • UX 流程——缺失的用户旅程；变更界面的失败、等待、空白、重新打开或并发状态，或接收输入的界面中尚未确定的恶意输入处理方式
   • 非功能性——未指定的性能、规模、可靠性、可观测性、安全、隐私或合规要求
   • 集成——外部依赖及其故障处理方式
   • 术语——含糊或不一致的领域用语
   • 可测试性——含糊的形容词（如“健壮”“直观”），或无法通过测试验证的验收标准
   • 占位项——TODO 和尚未决定的事项

   每个 Partial 或 Missing 类别都可作为候选问题，除非答案不会改变实现方式或验证方式，或问题涉及实现方法、技术栈比较或任务拆分；这些内容应在规划阶段处理。 规格中提出的每个 ## Open Questions 条目都必须询问；若未询问，则须在总结中说明原因。 按影响程度乘以不确定性对候选问题排序，优先级最高的排在前面：一个高影响领域（例如安全策略）应排在两个低影响领域之前。

4. 询问前核实每个问题的前提

   问题会将其前提作为既定事实呈现给用户，而用户回答的是所问的问题，而非本该提出的问题。 如果问题基于系统当前行为（例如某个已存在的设置、已读取的字段或已执行的规则），提问前请先阅读相关代码，而不是依赖记忆。

5. 一次只问一个问题

   切勿提前透露排队等待的问题。 只有当答案会实质影响架构、数据建模、任务拆分、测试、UX、运维或合规时才提问。

   每个问题：

   • 以 **Question:** 开头，接一个完整的疑问句，并以 ? 结尾，且问题本身应当完整易懂。 不得使用主题标签、标题或需求 ID 作为问题。 需求 ID 可放在 ? 之后的括号中：**Question:** <interrogative>? (FR-03)。
   • 后接一个通俗易懂的句子，说明该问题为何关系到验收或交付。 使用日常用语；不了解 Spec Kit 的读者也应能仅凭问题作答。
   • 提供 2–5 个互斥选项，或要求简短回答（不超过五个词）。

   推荐一个选项（或建议一个答案），并用一至两句话说明理由：考虑项目类型的最佳实践、降低风险，以及规格中列明的目标和约束。

   如果答案可用选项表达，且已安装 ask-question 技能，则通过该技能提问，并将推荐选项放在首位；否则用表格列出选项，并接受用户回复选项字母、“yes”（表示接受推荐项）或自行给出的简短答案。 如果答案含糊，应就同一个问题快速追问，然后再继续。 在无人值守运行中（FRAMEWORK.md § Unattended runs），不会有人作答：选择推荐选项，在 ## Assumptions 下记录该选项及其理由，并通过本次运行的升级处理路径提交任何确实需要由人作出的决定。

6. 记录每个答案后，再提出下一个问题

   每次接受答案后，更新并保存 spec.md：

   • 在 ## Clarifications 下（如果缺少该部分，则在开篇部分之后创建），为今天创建一个 ### Session YYYY-MM-DD 小节，并追加 - Q: <question> → A: <answer>。
   • 将答案应用到所属部分：一项需求及其场景、用户故事、关键实体、成功标准（将模糊的形容词转化为可衡量的目标）、边缘情况或术语（在全文统一术语，如有需要，仅注明一次 (formerly "X")）。 新需求使用下一个未占用的 FR-nn；现有标识符保留原编号。
   • 用答案替换其已使之过时的陈述，不要在旁边新增内容；不得留下任何矛盾。
   • 移除答案所解决的 [NEEDS CLARIFICATION] 标记。
   • 保持修改精简且可测试，并维持无关部分及原有标题层级不变。

7. 在实质性歧义解决后停止

   问题数量没有固定限制。 当所有实质性歧义都已解决，或用户要求停止（“done”、“proceed”）时，停止。 在规格说明中明确标出任何仍未解决的问题。

8. 重新验证规格说明质量检查清单

   如果 specs/changes/<name>/checklists/requirements.md 存在，则根据更新后的规格说明重新评估其中每个复选项。 仅切换状态已发生变化的标记，不要更改文件中的其他内容。 说明哪些项目现已通过、哪些项目退步，以及哪些项目仍未通过。

输出

问题结束后：

• 已提出并回答的问题数量，以及涉及的 spec.md 部分。
• 清单状态（若已重新验证）：重新验证前后的通过数量（例如，“12/16 → 15/16 通过”），以及发生变化或仍未通过的项目。
• 覆盖情况表：列出每个类别及其状态——已解决、推迟（属于规划阶段，或用户要求停止）、明确，或待处理（仍不完整但影响较低）。
• 下一步：“使用 spec-kit-plan 技能创建技术实施计划。” 如果存在待处理或推迟的事项，说明应继续规划还是再次澄清。

防护规则

• 如果没有发现实质性歧义，说明：“未发现值得正式澄清的关键歧义。”并附上覆盖情况表，建议使用 spec-kit-plan 技能。
• 每次回答后都必须保存，绝不能批量更新。
• 澄清期间绝不在规格说明中引入实现细节。
• 除非缺少技术栈信息会妨碍功能层面的明确性，否则绝不询问技术栈。