izittmarvin/agent-skills-zh/grilling

持续访谈用户，直到双方达成共同理解。把对象画成一棵设计树：每个决策都会分出后续决策。

不是所有歧义都值得入树：一个假设如果可逆、且即使选错也不会实质改变结果，直接声明它并继续推进，不要为它开分支。树越小，用户要做的决定越集中在真正重要的地方。

按轮次推进这棵树。前沿（frontier）是所有前置条件已经确定的决策：现在就能问、不必猜测尚未听到的答案。一轮之内问完整个前沿：给每个问题编号（Q1、Q2……），并给出你建议采用的答案。然后等待用户回答，再进入下一轮。

提问方式：结构化提问工具优先

每一轮提问都必须通过宿主的结构化提问工具发出，严禁把问题当普通文本输出。 这类工具会把问题渲染成可点选的交互界面，用户点选即可作答；纯文本问题在很多宿主里只会被当成普通回复刷过去，用户得手动打字回答，是本 Skill 失效的最常见原因。

开始前检查当前工具描述、适用模式和调用限制，使用本轮实际可用的结构化提问工具。工具不存在、当前模式不允许、调用失败或不能表达所需问题时，使用文末纯文本格式；不为确认已知限制故意调用一次失败工具。

使用工具提问时遵守：

• 即使一轮只有一题，也必须用工具。 不要用“问题少”当借口退回纯文本。
• 调用前先用一两句普通文本铺垫：这轮哪些决策已定、剩下哪些为什么需要用户拍板。很多宿主要求工具调用前必须有这条说明，它也让用户知道马上要回答问题。
• 按工具容量分批覆盖前沿。同步工具每批等待回答后再发下一批；异步工具只有在宿主允许时才并发发出独立问题。回答改变前提时重新计算剩余问题，避免继续发送已失效选项。
• 每问都给出建议答案：把推荐项放第一个选项，标签后缀“（推荐）”；开放问题没有选项可给时，在问题正文里写明你的建议。需要多选的决策，按宿主工具的标注方式注明（如 (multi)）。
• 问题编号仅用于跨轮引用，写在问题标题里即可；不要画蛇添足加表情符号或特殊排版，工具会自行渲染。

纯文本降级格式（工具不可用或不能承载当前问题时使用）：

**Q1 · <问题标题>**
 
<问题正文，可以有多段，也可以列出选项>
 
建议：<你建议采用的答案>

推进规则

用户每回答一轮，树就会改形：已确定的决策把前沿往外推，解开依赖它们的问题。重新计算前沿，再问下一轮。答案仍依赖本轮尚未关闭的另一个问题的，属于更后一轮，不能放进本轮。

查找事实是你的工作。平台允许且有可独立进行的调查时，可委派只读子代理；否则自己查证。只等待依赖该事实的问题，其余前沿仍可推进。决策属于用户：逐项交给他们，并等待回答；沉默或超时不算确认。

界面外观、布局或交互确实需要实物比较时，可使用已安装的 prototype；未安装时用当前能力提供等价的可视化。简单决策不额外搭建原型。

收敛与去向

前沿为空时，设计树的每个分支都已走过，没有静默假设。此时先输出收敛摘要（摘要是陈述，直接以文本输出，不走提问工具），固定四节：

• 方案：收敛后的做法，最短连贯表述
• 假设：已声明的可逆假设
• 排除项：明确不做的部分
• 验收判据：完成以什么可观察结果为准，这也是 /implement 需要的输入

随后用同样的提问方式（工具优先）确认去向，作为最后一轮。选项固定为：

• A. 只是聊聊 —— 到此为止，不写文件
• B. 落盘成执行清单 —— 转 /to-checklist 写入 .plans/ 下的本地文档（归 gitignore），过目后由 /implement 逐批执行
• C. 直接动手 —— 一步能完成的小改动才选，转 /implement

根据方案规模标注推荐项：涉及多步骤或多文件时推荐 B。

在用户确认摘要与去向前，不得据此采取行动。