安装此技能
npx skills@latest add mattpocock/skills --skill=grilling 然后在你的编码 agent 里输入 /grilling 。
本页目录
它做什么
grilling 是访谈（interview）循环，在任何人行动之前对一个计划、一个决定或一个想法做压力测试。它把主题映射成一棵设计树（design tree）：每一个决定都分出挂在它下面的决定，它一个分支一个分支地访谈你，直到没有任何假设留在未说出口的状态。
它不问一次一个问题，也不一次问完所有问题。每个轮次（round）问的是整个前沿（frontier）：所有前提条件已经解决的决定，别的什么都不问。两个问题如果其中一个依赖另一个，就绝不会同处一轮；一个取决于尚未有答案的问题，属于更晚的一轮。你的回答让决定落定，前沿向外移动，下一轮问的就是因此被解锁的东西。十三个问题通常落在三轮左右，而不是十三轮。
什么时候用它
输入 /grilling，或者当一个任务匹配时由 agent自行去拿它。它是质询（grilling）家族里唯一一个模型调用（model-invoked）的技能（skill），所以你很少亲手输入它。通常是你确实输入过的某个技能替你运行它。
直接输入 /grilling，你得到的是光秃秃的访谈，别的什么都没有。当你想要的不止这些时：
| 你有的情况 | 该用 |
|---|---|
| 你不在一个工作目录里工作 | grill-me：同一场会话（session），换成一个 agent 永远不会自己触发的名字 |
| 你在一个工作目录里 | grill-with-docs：同一场会话，而且它会边跑边写 GLOSSARY.md 和 ADR |
| 一项大到一场会话装不下的工作 | wayfinder：它绘制一张地图，并在决策工单（decision ticket）内部运行质询 |
| 一个靠谈话定不下来的问题：某样东西应该看起来或感觉起来怎样 | prototype：构建那个用完即弃的版本，然后再回来 |
| 你自己的一个需要访谈的技能 | 从它里面调用 /grilling，而不是再写一套访谈 |
轮次、前沿，以及谁来做决定
这个技能建立在三个想法上。
设计树是主题的模型：决定，以及挂在决定下面的决定。前沿是前提条件都已解决的那组决定：也是 agent 目前唯一能问的问题。一个轮次就是一个前沿，完整地问，完整地回答。
在一轮之内，每个问题都有固定格式：在一个 ❓ 后面编号并加标题，然后是正文，然后是单独占一行 ➡️ 的、agent 推荐的答案。这个格式让你可以按编号回答一整轮（「1 是，2 第二个选项，3 否，原因是……」），而不必把问题引用回来。这个格式有一个已知问题。推荐答案有时会反对问题本身的措辞，所以同意推荐答案就意味着对那个问题回答「否」。当这种情况发生时，回答推荐答案，并说明你是这么做的。
设计的另一半是事实与决定的分工。事实是这个技能自己的活。当一个前沿问题需要环境（environment）才能确定的东西时，agent 会派一个子代理（subagent）去查，而不是问你。这一轮不会等那项研究；只有依赖它的那些问题在等。决定是你的，agent 必须等它们。一个运行 grilling 却自问自答自己的决定的 agent，已经把这个技能弄坏了。当前沿为空时，会话结束。然后 agent 等你确认双方理解一致，才根据你们商定的内容行动。
前沿有一个限制。agent 靠判断来选择它；它不从图上计算。所以它可能把两个问题放进同一轮，到后来才发现一个答案本该改变另一个。唯一的防护是告诉它。那会在下一轮重新打开受影响的分支。
哪些内容在这里，哪些在包装技能里
这一页讲的是机制。包装技能（wrapper skill）的页面回答人们最常问的问题。
| 问题 | 在哪里回答 |
|---|---|
| 树、前沿、轮次、问题格式、事实与决定的区分 | 这里 |
| 一场会话该跑多久、一个靠谈话答不上来的问题该怎么办、怎么避免一味点头 | grill-me |
哪些内容写进 GLOSSARY.md，什么会成为 ADR | grill-with-docs |
常见问题
我能回到一次只问一个问题吗？
能，而且很大一部分受众就是这么做的。把下面这句加进你全局的 CLAUDE.md：
When grilling, ask one question at a time.
不是每个人都更喜欢基于轮次的默认设置。读得慢的用户、用第二语言工作的用户、或者利用顺序格式帮助自己专注的用户都报告说，一次一个问题对他们更有效。这个退出选项是一项受支持的设置，不是变通办法。
/batch-grill-me 去哪了？
进了这个技能。基于轮次的提问曾短暂地作为一个单独技能发布，后来搬进了 grilling 本身，所以建立在原语（primitive）上的一切（grill-me、grill-with-docs、triage、wayfinder）一次性都得到了它。没有 batch-grill-me 可装，也没有单独的串行技能；上面那行 CLAUDE.md 就是回到一次一个的方式。
一次问完一整轮，肯定会丢掉我早先的答案本该引出的问题吧？ 这是对轮次最常见的反对意见，而前沿回答它。一轮只包含彼此不依赖的问题，所以一轮里的任何答案都无法让同一轮里的另一个问题失效。你的答案仍然会改变它们之后的东西，因为 agent 会从零开始算出每一轮。你确实会丢掉一些东西，但比「一次问完所有问题」所暗示的要少。见上面关于前沿限制的说明。
它问完了问题，然后就开始构建了。
确认关卡（confirmation gate）就是为这个存在的。当你说理解已经共享，而不是当前沿清空时，这个技能才算完成。更弱、更快的模型（model）仍然会跳过这道关卡。用户在推理投入较低或非前沿的模型上报告得最多，这些模型把「访谈直到理解一致」压缩成几个问题加一个大纲。如果你的模型这样干，可靠的修法是在你自己的 AGENTS.md 或 CLAUDE.md 里写一行，告诉 agent 未经许可不要实现。
它自问自答，而不是来问我。
那是运行中的一个 bug，也正是技能文本把事实与决定分开的原因。它最常发生在另一个技能运行 grilling 来解决一张工单（ticket）、而 agent 把那个任务当成许可继续推进的时候。同一条约束也是没有异步模式的原因。有人要过一种变体，去读一个 GitHub issue 并贴出一份汇总的决定备忘录，那是另一个技能，因为一场没人回答的质询会话产出的只是 agent 的意见，而不是你的。
我能给问题的数量设个上限吗？ 不能，而且设上限是刻意排除在范围之外的。有些计划需要三个问题，有些需要五十个；固定上限要么截断困难的情况，要么在容易的情况上显得武断。预期的控制手段是平白的语言。告诉它收尾，或者停下来，接受计划现在的样子。如果一场会话跑得非常久，原因通常是范围太大了；把工作拆开，逐块质询。
我只装了 grill-me，什么都没发生。
grill-me 是一个一行式技能，整个正文就是「运行一场 /grilling 会话」，所以它也需要安装这个技能。grill-with-docs 也是如此，它还需要 domain-modeling。安装整套可以避免这个问题；有选择地安装意味着也要安装那些原语。
grill-with-docs 运行了，但它从来没加载 grilling。
这是一个真实的 bug，仍未修复，用户在不同的运行环境（harness）和模型上都报告过。一个技能点名另一个技能，并不能可靠地让那个技能加载，而 grill-with-docs 点名了两个。标志是一场把所有问题一次问完、没有任何推荐答案的会话。那意味着模型在即兴编一套访谈，而不是在运行这一套。直接问 agent 它有没有加载 grilling 和 domain-modeling，通常能把它拉回来。
它生效的标志
- 一轮以编号列表到达，每个问题在单独一行
➡️上带着推荐答案，而你能按编号回答整轮。 - 一轮里没有任何问题需要同一轮里另一个问题先被回答。
- 后续轮次问的是第一轮不可能问出的东西。
- 它会去查事实（读文件、派一个子代理），而不是问你一件它本可以自己查明的事。
- 后台运行的研究不会卡住这一轮；只有依赖它的那些问题在等。
- 它在结尾停下，请你确认理解一致，而不是开始干活。
- 问题数量保持很高，而轮次数量保持很低。
它在体系中的位置
grilling 是一个原语，而不是一个你排期的步骤：访谈技巧的单一事实来源（single source of truth），集中放在一处，好让每一个需要访谈的技能都来拿它，而不是另发明一套。grill-me 和 grill-with-docs 是它两个用户调用（user-invoked）的入口，而 grill-with-docs 是主构建链开始的地方，在 to-spec 之前。wayfinder 运行它来解决决策工单，triage 运行它把一份模糊的报告质询成可工作的报告，improve-codebase-architecture 在你挑中一个要深化的候选项之后走这棵树。当你不确定哪个入口合适时，ask-matt 会为你路由。