workflow-clarify

工作流澄清

将请求转化为由用户确认的行为约定。先阅读代码，然后只询问代码无法回答的问题。不创建工单，不编写代码。

从此 SKILL.md 所在目录的 ../workflow/ 读取共享策略；如果该目录缺失，请停止并说明。绝不使用其他技能根目录中的 workflow 副本。其 SKILL.md 中的“始终”清单也适用于此处（每轮结束时都要附上状态行）。

开始之前，请检查：规则处于 READY 状态，或有记录在案的 LIMITED_EXCEPTION 在其限制范围内涵盖此阶段（workflow/RULES.md）；任务已找到并设置检查点（workflow/TASK-FOLDER.md），或者路由器只留下了任务身份待确认：此时将“这是单独的任务还是修订？”作为第一轮的第一个问题，并说明单独的任务最好在新聊天中进行；其他问题的措辞应确保无论答案如何都适用；按 TASK-FOLDER.md 中“identity pending”行的说明保存本轮内容，且绝不要将此问题与审批问题一同提出；请求属于实际工作，而非仅作解释或轻量编辑。如果已有约定涵盖此修订，则转到 workflow-specify。应用 UI，即用户在屏幕上看到的任何内容（顺序、文字、显示哪些行或项目、布局，而不仅是样式）：先阅读 ../ui-design/SKILL.md 和 ../rule-maker/rules/design.md，然后再追踪。你提供的选项绝不包含新增 CSS，即使只是一次性的例外也不行。

1. 追踪用户历程

用户历程是指一个参与者获得一个结果的过程：触发 → 步骤 → 他们看到的内容。对于请求涉及的每个参与者，在代码中追踪并在 FINDINGS 中记录（J-ID、E-ID）：

1. 所有者与调用方：拥有此行为的代码、所有其他能够触达它的调用方或入口点，以及它读取的数据和设置。任何尚无用户历程可解释的调用方都是一个问题。
2. 失败情况：参与者在输入错误、缺少权限、离线或依赖项失败、超时、取消、重试时会看到什么。
3. 兼容性：已保存的数据、旧调用方、公共接口、版本；变更是扩展现有内容还是替换现有内容。
4. 状态与时机：关闭后或在不同设备间是否会记住状态；立即生效还是在下次操作时生效。
5. 限制：允许使用的依赖项或成本、目标环境、隐私、明确排除的内容。
6. 界面（仅限 UI）：每个新元素、它所对应的现有元素（file:line、标签、类），以及 python -X utf8 -I ../ui-design/scripts/class_rules.py <project-root> <classes> 的输出。若规则显示 [needs context]，或 --compare <from-parent> <into-parent> 显示布局差异，则视为不匹配：提出 design.md 规则 4 中的问题。

如何阅读代码并记录证据：workflow/GROUNDING.md。

当每个用户历程的所有者与调用方都已追踪，或缺失的访问权限已记录时，即为完成。提问前先追踪问题所依赖的内容。一次性提出方向或访问权限方面的阻碍，同时继续追踪其余内容。

2. 追问

现在就阅读 ../grilling/SKILL.md，务必在编写任何问题之前阅读，并针对第 1 步的发现按其要求执行；不经过此步骤就提问，等于跳过决策检查。

当其中的停止规则得到满足（“在停止前彻底检验”）时，即为完成。

3. 编写约定

使用 workflow/scripts/record.py replace-section，按照 workflow/WRITING.md 的规则，在 PLAN 中编写 ## Agreement：

• 需求（R-ID），每条都注明其来源；
• 每个参与者会经历什么，包括失败情况；
• 哪些内容保持不变，以及哪些内容不在范围内；
• 验收条件（A-ID），表述为可观察到的结果；
• 用户可以拒绝的假设，以及待定的选择和由谁决定。

描述行为和验收条件；工单、实现文件清单和测试命令留待 workflow-specify 阶段处理。

4. 第一关

用通俗易懂的话在聊天中总结这份约定：各方会发生什么、哪些内容保持不变、哪些内容不在范围内、他们可以否决哪些假设，以及 PLAN 路径。然后询问：

“这是否描述了应当构建的内容？请同意，或告诉我需要修改什么。同意后，我就可以编写详细计划；在你批准该计划之前，不会更改代码。”

停止。 回答追问、保持沉默或笼统地说“继续”都不代表同意。绝不要邀请用户批准他们尚未看到的计划，也不要沿用其他任务或早期修订中的捷径。

如果当前没有待处理事项，且改动较小（workflow/VISUAL-REVIEW.md 中的“Both gates in one message”），先不要询问任何内容：现在调用 workflow-specify。它会编写工单和 HTML 报告，并在一条消息中询问两项关卡。如果需要澄清，Clarify 绝不会自行请求批准计划。即使在之后的会话中，用户明确同意两项内容，也会记录两条记录；接着继续执行 workflow-execute。

将回复记录在检查点的 Agreement 行中（并更新下一步操作），同时记录到 DECISIONS：已同意（修订版本、日期）、部分同意（重新开启的事项返回步骤 2）、已拒绝，或明确豁免及其适用范围。关卡规则：workflow/VISUAL-REVIEW.md。

下一步

• 已同意或已豁免：workflow-specify。
• 调研：记录发现和待决定事项后停止。仅计划：继续执行 workflow-specify，然后停止；要编写代码，还需要实现请求。
• 受阻：记录阻塞问题或缺少的访问权限，以及仍可继续推进的事项。

之后的改动只需返回此处处理受影响的事项；其余内容维持原有约定。