spec-loop-clarify-task

在需要与用户进行重要澄清时，使用此技能： 讨论、分析、比较选项、检验方案的稳健性，并解决重要的 未决事项。不要在其他工作流中以非结构化的旁支讨论形式进行重要的 Spec Loop 澄清。工作项不是必需的。如果没有任务文件、ADR 或调用此技能的工作流，请仅通过聊天进行澄清。

在 ADR 工作期间，只要不同的答案可能会实质性地改变 ADR 决策或其依据，就使用此技能澄清标准、替代方案和决策边界。

重要的未决事项是指任何开放的问题、选择、标准、权衡、可信选项或边界，只要不同的答案可能会实质性地改变用户预期的结论、范围、行为、政策、概念模型、概念契约边界、约束、路径、验收逻辑、验证预期、Design、Test 规范，或 ADR Decision 及其依据。

除调用工作流要求的强制决策筛查外，如果当前讨论或工作项显然不存在重要的未决事项，就不要使用此技能。

此技能不只是提问。要解决现有证据能够确定的事项；存在治理工件时，将最终决策记录在其中；只有仍需用户输入时才询问用户。

对于 Spec Loop 任务创建、任务更新、设计更新和 ADR 工作期间的澄清，优先使用此技能，而不是通用的 grill-me 变体或自由形式讨论。

解决范围

此技能通过检查现有证据、就剩余选择与用户沟通并记录最终答案来解决决策。它不会创建 ADR、创建任务或选择长期工作路径。

如果证据和用户沟通都无法解决该决策，因为还需要 ADR 工作、实现工作或研究、探索、原型、目录或概念验证工作，请说明阻碍，并将控制权交还给调用工作流。调用工作流决定是转入 ADR 工作、创建或更新任务或子任务，还是暂停，直至有可接受的证据。

如果不存在调用工作流，请停止并说明阻碍，询问用户应由哪个工作流或工件负责。不要继续依赖该未解决结果的工作流步骤。

阶段与交接

如果存在调用工作流，澄清应留在该工作流所处的阶段：

• 规划阶段的澄清留在 PLAN；
• ADR 工作期间的澄清留在 ADR 工作阶段；
• 实现期间的澄清遵循 spec-loop-implementation-flow/SKILL.md。

如果不存在调用工作流，澄清应留在聊天中。除非用户明确说明应将结果记录在哪里，否则不要创建或编辑任务文件、ADR、术语表或其他持久化工件。

在 PLAN 或 ADR 工作期间，根据需要直接修订相应的治理工件。不得进行可执行的更改。

此技能结束时：

• 如果存在调用工作流，将控制权交还给该工作流；
• 否则，停止并保留已解决的聊天状态，明确说明任何尚未解决的问题。

针对不同工作流的返回路径：

• 任务规划返回 spec-loop-plan-task/SKILL.md；
• 工作拆分返回 spec-loop-plan-work-breakdown/SKILL.md；
• ADR 工作期间的澄清返回 spec-loop-write-adr/SKILL.md；
• 执行审批准备期间的澄清返回 spec-loop-prepare-execution-approval/SKILL.md；
• 实现期间的澄清返回 spec-loop-implementation-flow/SKILL.md。

强制决策筛查

当另一个工作流要求在编写或修改内容前应用此技能时，使用下方的决策树和允许的筛查结果，对所有会影响该内容的重要决策点进行筛查。不要用直觉判断来替代这一流程，例如认为“无需提问”。

重要决策点是指助手需要作出、暗示或写入最终内容的任何选择，而不同的答案可能会成为此技能下的重要待定决策。

在编写依赖这些决策点的最终内容前，必须将每个重要决策点归类为且仅归类为一种允许的筛查结果。

强制决策筛查要求对每个重要决策点进行归类，而不是逐一提问。只有 pending User answer as a clarification question 这一结果需要提出澄清问题。

决策树

1. 检查是否需要澄清

如果没有重要的待定决策：

• 如果存在调用工作流，立即将控制权交还给它；
• 否则，立即结束仅限聊天的澄清；并且
• 不要针对这项技能启动澄清问题汇总或持久状态记录。

将此技能用于强制决策筛查时，只有在被筛查内容的每个重要决策点都已根据确定性证据或外部澄清归类为已解决后，才可在此步骤返回。

2. 直接回答简单情况

如果决策点属于明显的拼写错误修正、简单的单词消歧或简单的事实确认，且答案不会实质性改变范围、行为、政策、边界、验收逻辑、路线、设计或测试规范，则直接回答。

这些情况不要使用澄清流程。

如果后来发现该问题会影响设计，则继续进行常规澄清。

3. 根据已有证据确定答案

对于每个重要的待定决策，首先检查答案是否已由用户确认的选择、当前讨论上下文、现有任务材料、术语表内容、代码、文档或这些选择所导致的低风险机械结果确定。

不要向用户询问当前代码库、文档或适用规范已有明确答案的信息。应先使用这些来源，仅在信息缺失、含糊、冲突或不足以作出决策时再询问。

默认值、“合理默认值”、惯例、常见做法、框架习惯、实现便利性、助手偏好和助手直觉都不属于已有的确定性证据。不要用它们来默默解决重要决策点。

这些因素可以用于提出待决策选项或建议方案，之后由用户确认或作答来敲定决策。

将用户表述、术语表内容、任务材料和代码之间的冲突明确指出，作为证据呈现。

如果某个区别会改变两个概念是否相同、是否不同，或是否受不同规则约束，就将其视为重要区别。

如果边界已经确定，不要针对确切名称、措辞、标签、字段名、枚举名或其他易于更改的设计文本请求澄清。如果存在设计文档，应将其写入设计文档；否则直接处理。

如果起草或审查设计文档时发现新的重要待定决策，应先返回澄清，再继续。

4. 确认已敲定的决策

对于已敲定的决策，仅当需要在对话中明确记录该选择时，才使用聊天确认。结果的文档存储方式由“结果存储位置”部分处理。

适用于用户作出的选择、用户输入所带来的机械结果、后续澄清所依赖的选择，或确认后能减少歧义的选择。不要添加置信度或模型推理。使用：

已记录：<选择>。

记录决策后，立即继续。

不要将已敲定的决策放入决策汇总中。

5. 提出决策建议，或针对尚未确定的决策提问

对于用户或现有材料尚未确定的重要决策，选择以下一种处理方式：

• 提出一批决策建议：适用于 Agent 能提出明确选项，且只需用户检查或同意的情况。
• 澄清问题：适用于做出选择前仍需用户提供输入的情况。

一批决策建议最多包含 6 项。批次内的决策从 1 开始连续编号，且不得超过 6。对每项建议的决策，使用以下格式：

Decision 1: <简短答案>（%） Reason: <简短理由>

Decision 2: <简短答案>（%） Reason: <简短理由>

两行都应简短。每个 Decision <N>: 行都必须包含建议的答案。

提出一批决策建议后，请用户确认、提问或表示异议，然后等待。

每个澄清问题都必须列出备选项。使用以下格式：

Question: <简短问题> Recommended option: <字母>（%） Options:

• A. <备选项简述>
• B. <备选项简述>
• C. <备选项简述>

Reason: <简短理由>

对于澄清问题：

• Recommended option: 必须只包含建议选项的字母和置信度；
• 备选项摘要和说明只能放在 Options: 和 Reason: 中；
• 选项行使用 - <字母>. <摘要> 的格式；
• 最后一条选项行与 Reason: 之间留一个空行；
• 选项行不得包含置信度；
• 对于是／否选择，选项摘要使用 A. 是 和 B. 否 之类的形式。

发送任何包含 Options: 的回复前，请验证：

• Recommended option: 行的格式严格为 Recommended option: <字母>（<N>%）；
• 建议选项的字母存在于选项列表中；
• 选项行的格式严格为 - <字母>. <摘要>；
• 最后一条选项行与 Reason: 之间留有一个空行；且
• 选项行中不含置信度。

用户明确确认已提供的选项时，请记录该决定。

决策筛选结果

对于每个重要决策点，强制决策筛选只能得出以下结果：

• 根据决定性证据解决，并在需要时获得确认；
• 筛选结果表明该选择不符合重要未决策的定义，且无需根据此技能征求用户检查，因此无需澄清；
• 等待用户在一批决策建议中检查；
• 等待用户通过澄清问题作答；或
• 受阻，并根据 Resolution scope 返回。

无需澄清的结果适用于实质含义已确定时的措辞或标签选择，以及仅用于实现已确定的范围、行为、约束、路径和验收预期的设计／测试选择。

无需澄清的选择不属于决定性证据，也不属于用户确认的决策。将这些选择交回调用工作流，并且只在该工作流负责的范围内记录。

只有已解决和无需澄清的结果，才允许立即撰写依赖于该结果的最终内容。等待用户检查或等待用户作答的结果，必须先解决，之后才能撰写依赖于该结果的最终内容。受阻的结果应将控制权交回调用工作流。

澄清投入程度问题

澄清投入程度用于控制拟议决策批次与针对用户或现有材料尚未确定的决策所提出的澄清问题之间的平衡。它不控制问题是否列出备选项；每个澄清问题都会列出备选项。它不会改变哪些内容属于重要的未决策事项，也不会改变保留最终结果的必要性。

只有当澄清预计需要超过两个实质性步骤，或决策范围足够广、用户需要掌控细节时，才询问澄清投入程度。若预计在两个实质性步骤内即可完成澄清，则不要询问。

实质性澄清步骤包括：

• 一个决策批次；或
• 一个关于讨论内容或工作事项的实质性问题。

在询问澄清投入程度之前，简要说明需要澄清什么以及原因。范围说明和澄清投入程度问题不计入实质性步骤。

澄清投入程度问题可以在任何实质性步骤之前提出，也可以在一个或多个步骤之后提出。以下方式均有效：

• 澄清投入程度问题，1，2，3；
• 1，澄清投入程度问题，2，3；
• 1，2，澄清投入程度问题，3，4，5。

澄清投入程度问题是必需备选项格式的一种特殊情况。使用以下固定模板；只调整推荐选项、置信度数值和理由：

问题：您希望在本次澄清过程中参与到什么程度？ 推荐选项：<A/B/C/D>（%） 选项：

• A. 低投入：在安全可行时优先采用拟议决策批次；仅在需要用户输入时提问。
• B. 正常投入：提出明确选项；在不确定或偏好会影响决策时提问。
• C. 高投入：在不确定或决策属于最重要事项之一时提问；对于简单明了的选择则使用批次。
• D. 穷尽式：询问每一项重要的未决策事项；直接记录已确定的决策。

理由：<推荐该选项的简要理由> 您之后可以说“少问一些问题”“多问一些问题”或“询问每一项重要决策”来更改此设置。

推荐最适合当前情况的选项。没有更充分的理由推荐其他选项时，使用正常投入。

提出澄清投入程度问题后，等待用户回复。如果回复没有回答该问题，则使用推荐选项，说明您将采用该选项，然后继续。

设置后，澄清投入程度适用于当前澄清流程，除非用户更改设置。同一聊天会话中之后需要澄清时，如果有必要，可以再次询问；您可以推荐上次选择的偏好，也可以推荐其他选项。不要默认将之前的投入程度设置沿用为新澄清流程的当前设置。如果用户要求记住此偏好，可以使用可用的记忆或项目指令。

将低、正常、高和穷尽式视为连续范围上的命名锚点，而非仅有的设置。将“少问一些问题”和“多问一些问题”理解为沿此范围进行相对调整。将“询问每一项重要决策”理解为穷尽式。

诸如“多盘问我”“更深入地盘问我”“少盘问我”或“轻松点问我”这样的自然表述，可以理解为参与程度调整，但不要在面向用户的文本中主动推荐这些说法。

澄清期间的决策顺序

按重要性和不确定性从高到低选择尚未确定的事项。针对选定事项，先深入处理。

在每个实质性的澄清步骤中，只能提出以下其中一项：

• 一组决策；或
• 一个澄清问题。

不要在呈现其所依赖的待决决策之前提问。 不要在同一条回复中同时提出新问题和一组决策。

如果回复中包含澄清问题或一组决策，请将问题或决策组放在消息末尾。将必要的背景、证据、说明或状态放在它们之前。一组决策之后，只能附上简短的确认、提问或异议提示。

仅对需要用户检查或同意的 Agent 提议决策使用编号条目 Decision <N>:。不要将其用于用户已作出的选择或现有材料已确定的事项。

结果的存储位置

澄清可能有对应的管理文档，也可能只在聊天中进行。

请遵循以下存储规则：

• 由任务管理的澄清：将最终确定的决策存入任务文档。
• ADR 编写过程中的澄清：将最终确定的决策存入 ADR。
• 仅在聊天中进行的澄清：将决策保留在聊天中，直到用户说明要记录在何处。在仅聊天的澄清结束时，询问是否应保存结果以及保存位置。

对于仅在聊天中进行的澄清，不要创建、选择或推断持久存储位置。将结果写入任何位置之前，先询问用户要记录在哪里。

当存在管理文档时，只在其中记录最终确定的内容。不要记录未决问题、置信度或临时备注。

在任务文档中：

• 对于任务文件，将最终决策放入 Analysis；对于仅在聊天中进行的任务，将其放入 Scope；
• 关于章节顺序和各类信息的规则，请遵循 spec-loop-plan-task/common-task-guidance.md；并且
• 无论采用哪种形式，最终决策都遵循其中的 Analysis 条目规则。

在 ADR 中，不要强行将所有最终确定的内容都放入 Analysis。 请遵循 spec-loop-write-adr/adr-format.md：

• 将决策前的事实放入 Context；
• 将可信的竞争选项放入 Alternatives；
• 将选定结果放入 Decision；并且
• 在 Analysis 中仅保留与 ADR 相关的推理要点，以简洁条目支持所选决策。

对于 ADR，请将可信的替代方案保留在 Alternatives 中，不要在 Analysis 中重复。

此技能适用于多个工作环节。当某项决策最终确定且存在管理文档时，请更新上述正确章节，并更新管理文档中所有受影响的章节。

如果澄清解决或更改了共享领域术语，请在当前任务中注明所需的术语表后续工作（如果存在或正在准备）。

对于由任务控制的工作，不要让最终确定的状态仅留在聊天中，直到这样做变得不安全。应在聊天记录存储变得不安全之前，将其移入任务文件；并且在交还控制权前，始终同步最终确定的状态。本规则不会将独立的仅聊天讨论转变为由任务控制的工作。

退出

在将工作交还给调用工作流之前，请确认：

• 正交还的工作项部分没有遗留重要的未决决策；
• 术语表冲突和代码／文档矛盾已解决或已明确指出；
• 相关时，已注明所需的术语表后续工作；并且
• 管理文档与最终确定的状态一致。