grilling

持续、深入地询问用户关于主题的每个方面，直到双方达成共识。将其建模为设计树：每个决策都会分支出依赖于它的决策。

前沿

前沿是所有前置条件已确定的开放决策：也就是现在可以提出、且无需猜测尚未听到的答案的问题。每个答案都会重塑这棵树：它会确定一个节点，解锁下方的决策，也可能重新打开与之矛盾的先前分支。每次回答后都要重新计算前沿；前沿绝不是预先列好的清单。

提问

只要答案仍会改变设计，就一次只问一个问题，然后等待回答。选择最能解锁树中其他决策的前沿决策。如果连续两次回答都采纳了你的建议，或者剩下的事项影响较小或彼此独立（位置、命名、日期、ADR 格式），就将前沿中的其余问题作为一个编号批次发送；每个问题都附上推荐默认选项，并请用户回复“其余均批准”或指出例外。只将用户无需细读即可批准的内容放入批次。会推翻已记录的决策、创建 ADR 或提供两个以上选项的问题，无论用户采纳了多少条建议，都必须一次只问一个：用户快速接受建议，代表信任这些建议，而不是有余力处理更多问题。

每个问题都按以下格式编写：

❓ **Q<n>** - **<question title>** (<k> more on the frontier)

<question body, might be multiple paragraphs, including the choices>

➡️ <your recommended answer, and why>

将建议写成针对问题本身的回答，这样用户表示同意就等于回答“是”。

如果选项使用了之前工作中的名称（原型变体、其他工单的决策、代号），问题正文必须说明它具体是什么：如果有对应的实际材料，就展示该材料本身，例如图片路径或链接；否则用一个简单句子说明。绝不要假设用户在不同会话中还记得某个名称。

如果用户要求分轮提问，则改为一次提出整个前沿：按上述格式为每个问题编号，用 --- 分隔，并将所有依赖其他问题的问题留到下一轮。

事实、默认值与决策

查明_事实_是你的职责。问题需要环境中的事实（代码、文件、文档、工具）时，应查找，而不是询问；耗时的工作交给子 Agent。若事实涉及仓库中现有的内容，应在 fetch 后根据 origin/<default> 陈述，而不是依据工作树：本地检出只是缓存，未 fetch 的检出会悄无声息地把已合并的工作说成缺失。这也适用于每个选项的前提：提出选项前，先列出每个选项所依赖的事实（涉及系统的格式、路径、限制和权限），并查明这些事实。前提未经验证的选项必须在正文中说明这一点，你的建议也不能以此为依据。名称不是前提：表格、函数或角色的名称只说明作者的意图，因此在依赖它之前，应打开读取数据的代码，并为每个前提注明文件和行号。若默认值沿用了其他代码库或早期设计中的数值，应根据目标系统自身的尺度（它比较的值以及调整这些值的修正项）进行核对，并在选项中展示对比（“命中值为 6 或更高；这里的命中值为 3 到 6”）。当基于这些回答编写的词汇表、规范或 ADR 在每轮审查中都发现一个新的事实错误时，应停止审查，并进行一轮事实核查，阅读设计所经过的代码路径。正在进行的查找只会阻塞依赖它的问题：查找期间，继续处理其余未决事项。它也会阻止作出断言：结果返回前，只陈述已经查明的内容，并将对尚未探索的系统的任何推断标为猜测。

方向决策（做什么、面向谁、先做什么）由用户决定。逐项询问并等待答复，无论你的建议看起来多么显而易见。

_默认值_是有依据的实现选择：用户即使不细看也会接受的建议。每项用一行说明，然后继续，让用户提出异议。询问是否制作原型前，先检查是否已有可供此项工作使用的现成产物（仪表板、脚本或模拟稿）能够回答设计问题；如果有，该产物就是原型。

计划若要按利益相关者文档中的顺序安排工作，应先对这个顺序提出质疑：用一句话说明文档的核心主张，并按各部分对实现该主张的直接程度排序。“没有阻塞”只能用于打破平局。

完成

当前沿为空时，工作会话即告完成：每条分支都已检查，没有任何内容被默默假定。然后列出已敲定的决策和已说明的默认值，并请用户确认这份清单体现了双方的共同理解。只有在用户确认后，才能据此采取行动。