/grilling 技能

它的作用

grilling 是压力测试计划、决策或想法的审问循环，在任何人行动之前进行。它把主题映射为 设计树 ——每个决策都分支进挂在它下面的决策——并逐个分支审问你，直到没有任何东西被默默假设。

它不是一次问一个问题，也不是一次问完所有。每个 round 问整个 frontier：每个前置条件已敲定的决策，仅此而已。如果一个问题依赖另一个问题，它们绝不会在同一轮出现——依赖一个悬而未决答案的问题属于更晚的一轮。你的回答敲定决策，前沿向外推进，下一轮再问被解锁了什么。十三个问题通常大约三轮就能问完，而不是十三轮。

何时使用

输入 /grilling，或这个 agent 任务合适时自行调用它。它是唯一 skill 在这个 追问审视 由模型自动调用的家族，这就是为什么你很少输入它：通常一个你 did 类型正在替你运行它。

输入 /grilling 直接给你纯粹的审问，仅此而已。当你想要更多时：

轮次、前沿，以及谁决定

三个想法撑起整个技能。

这个 设计树 是主题的模型：挂着子决策的决策。 frontier 是前置条件全部敲定的决策集合——目前唯一能诚实提出的问题。 round 是一个前沿，完整地提问，完整地回答。

一轮之内，每个问题都以固定形态到来：编号并带标题，放在一个 ❓，然后正文，然后智能体推荐答案单独放在一个 ➡️ 行。这正是让一轮问题可以按编号回答的原因——「1 同意，2 第二个选项，3 不同意，原因是……」——而不是把问题复述回去。这种格式有一个已知粗糙之处：推荐有时会为 against 按原文措辞的问题，所以同意推荐意味着对问题回答「不」。发生这种情况时，回答推荐本身并说明。

设计的另一半是事实与决策的拆分。事实是技能自己的职责：当前沿问题需要 环境 能够解决，它就派发一个 sub-agent 去查明，而不是问你。它不会为此阻塞——只有运行中探索下游的问题等待。决策是你的，它必须等待它们。一个运行 grilling 自问自答就是破坏了技能，而不是宽泛地解释它。会话在前沿清空时结束，而且在你确认已达成共识之前，它不会对你同意的事采取行动。

诚实的局限：前沿是智能体的判断，不是计算出的图。它可能把两个问题放进同一轮，事后才发现一个答案本应改变另一个。除了告诉它之外没有防护——这会在下一轮重新打开受影响的分支。

什么住在这里，什么住在包装器里

本页讲机制。人们最常要的东西在上一级文档中。

常见问题

我可以回到一次只问一个问题吗？ 是的，而且很大一部分用户确实如此。把这个加进你的全局 CLAUDE.md:

When grilling, ask one question at a time.

轮次式默认确实有争议。阅读慢的实践者、用第二语言工作的人、把顺序格式当作专注支架的人，都报告一次一个的节奏对他们更好，而且退出选项是被支持而不是被容忍的。

原来的 /batch-grill-me 去哪了？ 进入这个技能。轮次式提问曾短暂地作为独立技能发布，然后移入 grilling 本身，所以建立在原语上的一切—— grill-me, grill-with-docs, triage, wayfinder ——立刻就懂了。没有 batch-grill-me 要安装，也没有单独的连续式技能； CLAUDE.md 上面那一行是回到一次一个的方式。

一次问整轮问题，必然会失去我先前回答会引出的新问题。不是吗？ 这是对轮次设计最常见的反对，而前沿就是答案：一轮只包含互不依赖的问题，所以一轮中的答案不会否定同一轮中的另一个问题。答案仍然重塑下游的一切——下一轮被重新计算，而不是预先写好。你失去的比「一次问完所有问题」所暗示的小，又比零大：见上文前沿的局限。

它问题问完了，开始构建。 确认门正是为此而设：技能不是在前沿清空时结束，而是在你说理解已达成一致时结束。更弱更快的 models 仍然会破坏它——这最常被报告在低投入或非前沿模型上，它们把「审问直到达成共识」压成几个问题加一个提纲。如果你的模型这样做，可靠的修复是在你自己的 AGENTS.md or CLAUDE.md 告诉智能体未经许可不得实现。

它自问自答，而不是问我。 那是运行中的 bug，不是预期行为，这也是为什么技能文本把事实和决策分开。它最常出现在另一个技能运行 grilling 在「解决这个任务」的框架内，周围的任务读起来就像继续前进的许可。同样的约束也是没有异步模式的原因：有人要求过一种读取 GitHub issue 并发布一份整合决策备忘录的变体，而那是另一个技能，因为一场无人应答的审问会话产出的是智能体的意见，而不是你的。

我能限制问题的数量吗？ 不，而且上限被刻意排除在范围之外。有些计划需要三个问题，有些需要五十个；固定上限要么截断困难情况，要么在简单情况上显得武断。用平实的语言掌舵是设计好的控制方式——告诉它收尾，或者停下并按现状接受计划。如果会话运行过长，原因通常是范围太大；把工作拆开，逐个审问。

我安装了 grill-me 单独使用，什么也不会发生。 grill-me 是一个整篇正文只有「运行一个 /grilling 会话」，所以它也需要安装这个技能。 grill-with-docs，它另外需要 domain-modeling。安装整套技能可以避免这个问题；选择性安装则意味着要把这些基础技能也一起装上。

grill-with-docs 运行了，但它从未加载 grilling. 一个真实且未修复的粗糙之处，跨 harnesses 和模型：一个技能点名另一个技能，并不能可靠地让那个技能被加载，而 grill-with-docs 点名两个。征兆是一次问完所有问题且不附推荐——那是模型在即兴发挥一场审问，而不是运行这个。直接问智能体是否加载了 grilling and domain-modeling 通常能恢复它。

做到以下就算成功

• 一轮以编号列表形式到来，每个问题及其推荐答案分别放在 ➡️ 行，你就可以用编号回答整轮。
• 一轮之内，没有问题需要同一轮中另一个问题先被回答。
• 后面的轮次会问第一轮不可能问的事。
• 它去查事实——读文件、派发子智能体——而不是问你它本可查到的东西。
• 后台运行的研究不会让整轮停滞；只有依赖它的问题等待。
• 它在最后停下来，请你确认理解已达成一致，而不是开始工作。
• 问题数量保持高位，轮次数量保持低位。

在流程中的位置

grilling 是一个 primitive，不是你需要安排的一步：它是审问技术的唯一权威来源，放在一处，让每个需要审问的技能都直接调用它，而不是自创一套。 grill-me and grill-with-docs 是它的两个由用户调用的前门，而 grill-with-docs 是主构建链开始的地方，先于 to-spec. wayfinder 运行它来解析决策任务， triage 把模糊的报告审问成可用的，而 improve-codebase-architecture 在选定要深化的候选后遍历树。当你不确定哪个入口合适时， ask-matt 为你指路。