用 “grilling“ 技能以设计树为骨架拷问你的方案：把计划、决策与想法逐一过堂

用 "grilling" 技能以设计树为骨架拷问你的方案：把计划、决策与想法逐一过堂

【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills

导读：本文讲解本仓库（GitHub_Trending/skills13/skills，一套面向真实工程师的 Agent Skills 集合）中 productivity 分类下的核心原语级技能grilling。它以「设计树（design tree）+ 前沿（frontier）+ 轮次（round）」机制，把一段"拷问式访谈"组织成可回答、可推进、可收敛的结构化对话，专门用于在动手之前对计划、决策和想法做压力测试。读完本文，你将掌握该技能的调用方式、轮次格式、事实与决策的职责切分，以及它与grill-me、grill-with-docs、wayfinder、triage等技能的协作关系。

grilling 是什么：一次"过堂式"访谈

grilling是一个**由模型自主调用（model-invoked）**的访谈循环，用于在任何人真正动手之前，对一个计划（plan）、一项决策（decision）或一个想法（idea）进行压力测试。其核心文档 skills/productivity/grilling/SKILL.md 开宗明义：

Interview the user relentlessly until you reach a shared understanding. Map this as adesign tree: every decision branches into the decisions that hang off it.

即：持续访谈用户，直到双方达成共识；把讨论对象建模为一棵设计树——每个决策都会分支挂出依赖它的后续决策。

与逐条提问或一次性问完所有问题都不同，它既不"一问一答"，也不"一次全问"，而是按**轮次（rounds）推进：每一轮只问当前前沿（frontier）**上的全部问题——也就是"所有前置条件都已确定"的决策。两个问题若存在依赖关系，绝不放进同一轮；某个问题若依赖本轮尚未回答的答案，则属于更晚的轮次。你的回答使决策落定，前沿随之向外推移，下一轮再问新解锁的问题。官方文档 docs/productivity/grilling.md 给出的典型效果是：十三个问题通常落在约三轮里，而不是十三轮。

三个核心概念：设计树、前沿与轮次

grilling的整套机制由三个概念承载，全部继承自原文档：

轮次内的问题有固定格式。每个问题都以❓开头、编号并给出标题，随后是问题正文（可多段、可含多个选项），最后单独一行➡️给出 Agent 的推荐答案。完整模板如下（来自 skills/productivity/grilling/SKILL.md）：

❓ **Q1** - **<问题标题>**: <问题正文，可为多段，可含多个选项> ➡️ <你的推荐答案> --- ❓ **Q2** - **<问题标题>**: <问题正文，可为多段，可含多个选项> ➡️ <你的推荐答案>

这种"编号 + 标题 + 正文 + 单独成行的推荐答案"的固定形状，使整个轮次可以用按编号作答的方式响应（例如："1 同意，2 选第二个选项，3 不同意，原因如下"），而不是把问题原文逐字复述回去。这也是 docs/productivity/grilling.md 强调的"整轮可按编号作答"的关键设计。

前沿的重算：每一轮用户回答完毕，已落定的决策就会把前沿向外推，解锁原本依赖它们的下游问题；Agent 需要重新计算前沿再问下一轮。某问题的答案依赖本轮仍在开放中的另一个问题，就属于更晚的轮次，而非本轮。官方文档也如实指出了前沿机制的边界：前沿是 Agent 的判断而非计算出的图，可能发生"同一轮里两个问题，其中一个答案本应改变另一个"的粗糙边缘；唯一的防线是用户当场指出，下一轮重开受影响的分支。

事实归 Agent，决策归用户：职责切分

grilling的另一半设计是事实（facts）与决策（decisions）的严格分工，这是 skills/productivity/grilling/SKILL.md 中反复强调的纪律：

• 寻找事实是 Agent 的本职，绝不是用户的。当某个前沿问题需要环境中的事实（文件系统、工具等）时，应派遣**子代理（sub-agent）**去查，而不是问用户任何自己能查到的内容。
• 探索不得阻塞轮次：运行中的探索算"未落定的前置条件"，只有依赖它的下游问题等待子代理回报，前沿上的其余问题现在照问。
• 决策属于用户：每个决策都必须交由用户并等待其确认。一个运行grilling却自己替用户回答了决策的 Agent，不是"灵活诠释"这个技能，而是破坏了技能本身。
• 会话结束条件：当前沿为空时——设计树的每个分支都已访问、没有任何东西被静默假定——技能仍未结束；必须等用户确认双方已达成共识，才能据此行动。文档原话是："Do not act on it until the user confirms you have reached a shared understanding."

官方文档 docs/productivity/grilling.md 还解释了这个设计的由来：曾经出现过 Agent"自问自答"的运行 bug，这正是事实与决策被分离写入技能文本的原因。也正因如此，该技能没有异步模式——有人曾要求一个"读取 GitHub issue 后发布一份汇总决策备忘录"的变体，但文档明确回应：那是另一个技能，因为一场无人作答的 grilling 会话，产出的只是 Agent 的观点，而非你的决策。

何时使用与调用方式

触发方式：多数时候不是你输入它

在grilling家族中，它是唯一由模型自主调用的技能（frontmatter 中description声明 "Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases"，见 skills/productivity/grilling/SKILL.md），因此你很少会手动输入它——通常是你输入了另一个技能，由那个技能替你运行它。其 Agent 配置 skills/productivity/grilling/agents/openai.yaml 中的描述为 "Stress-test thinking a round of questions at a time"，可作为调用意图的快速判断依据。

直接输入/grilling得到的是纯访谈，仅此而已。需要"更多"时，按场景选择包装技能（表格来自 docs/productivity/grilling.md）：

各包装技能如何调用它

grilling被定义为原语（primitive）：访谈技术的唯一事实来源，集中存放，使每个需要访谈的技能都来调用它，而不是各自发明一套。从仓库源码可以看到它被引用的具体方式：

• grill-me 整个技能只有一行实质内容：Call the Skill tool with "grilling"。因此单独安装grill-me而不装grilling是什么都不会发生的——它需要一个带grilling的本体。
• grill-with-docs 则Call the Skill tool twice, for "grilling" and "domain-modeling"，即同时加载访谈技能与领域建模技能。
• wayfinder 将工作绘制成 issue tracker 上的决策票地图，其中Grilling 票（HITL，人在回路）是其默认情况："Always call the Skill tool twice, for 'grilling' and 'domain-modeling'"；并强调"一个自己回答自己问题的 grilling Agent 已破坏此约定"。
• triage 在处理模糊 issue 时也调用这两者："call the Skill tool twice, for 'grilling' and 'domain-modeling', and grill it into shape a round of questions at a time"，把一份含糊的报告盘问成可执行的形式，并同步更新CONTEXT.md/ADR。
• improve-codebase-architecture 在用户选定一个架构深化候选后，同样 "call the Skill tool with 'grilling' to walk the decision tree"。

另外需注意：grilling的 frontmatter 没有disable-model-invocation: true（与grill-me的 skills/productivity/grill-me/SKILL.md 中disable-model-invocation: true形成对比），这正是它"可由模型主动触发"的配置体现，也对应 skills/productivity/README.md 中将grilling归入"Model-invoked（模型或用户可达）"的分类。

常见问题与已知边界（来自官方 FAQ）

官方文档 docs/productivity/grilling.md 用一整节 FAQ 回答了实操中最常被问的问题，以下内容均忠实继承：

可以退回一问一答吗？可以，而且相当一部分用户就这么做。在全局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就是回到一问一答的途径。

一次问完整轮，不会丢失我前几个回答本该引发的问题吗？这是对轮次设计最常见的质疑，而前沿正是答案：一轮只包含互不依赖的问题，因此轮内任何答案都不会使同轮其他问题失效。答案仍会重塑下游一切——下一轮是重算的，不是预先写好的。失去的东西小于"一次性全问"给人的印象，也大于"什么也没失去"。

它问完了问题就开始动手构建了。确认门槛（confirmation gate）正是为此而设：前沿清空并不代表技能完成，你说"共识已达成"才算完成。较弱、较快的模型仍会破坏这一点，最常见于低投入或非前沿型模型——它们会把"访谈至共识"坍缩成两三个问题加一份大纲。可靠的修复是在你自己的AGENTS.md或CLAUDE.md里加一行：未经许可不得实施。

它替用户回答了自己的问题。这是运行中的 bug，不是预期行为，也正是技能文本把事实与决策分离的原因。它最常出现在另一个技能以"解决这张票"的框架运行grilling时——周围的任务读起来像是"继续推进"的许可证。这也解释了为何没有异步模式。

可以限制问题数量吗？不能，上限被刻意排除在范围之外。有些计划需要三个问题，有些需要五十个；固定上限要么截断困难情形，要么在简单情形显得武断。用自然语言指挥才是预期控制手段：让它收尾，或者就地停下接受现有计划。若会话拖得过长，原因通常是范围太大——把工作拆开，逐块拷问。

单独安装了grill-me却毫无反应。因为grill-me是一个单行技能，正文就是"运行一场/grilling会话"，所以它同样需要安装grilling本体；grill-with-docs同理，且额外依赖 domain-modeling。整套安装可避免此问题；选择性安装则必须连原语一起装。

grill-with-docs运行了，但从未加载grilling。这是一个真实且未修复的粗糙边缘，在多种 harness 和模型上都有报告：一个技能指名另一个技能，并不保证后者会被可靠加载，而grill-with-docs指名了两个（grilling与domain-modeling）。征兆是一次问完全部问题、且不附带任何推荐答案——那是模型即兴发挥的访谈，而非本技能。直接问 Agent 是否加载了grilling和domain-modeling通常能恢复。

成功判据：如何知道 grilling 在正常工作

官方文档给出了 7 条"working"判据，可作为自查清单（继承自 docs/productivity/grilling.md）：

• 一轮以编号列表抵达，每个问题都带独立➡️行的推荐答案，且整轮可按编号作答；
• 轮内没有任何问题需要先回答同轮另一个问题；
• 后续轮次问出了第一轮不可能问的问题；
• 它主动去查事实（读文件、派子代理），而不是问你本可以自己查的东西；
• 后台运行的研究不会卡住轮次，只有依赖它的问题才等待；
• 它会在最后停下，请你确认共识已达成，而不是直接开始干活；
• 问题总数保持高位，而轮次数保持低位。

从 docs/productivity/grill-me.md 还能得到一组互补的用户视角判据：你会在某处与它意见不合（一场没有来自你的反驳的会话，是你本不需要的会话）；问题在几轮内抵达而非细水长流；你最终到达了自己没预料到的地方（某个问题暴露了你一直隐式做出的决策）；结束时你能为每个选择向不在场的人辩护。

它在一个技能生态中的位置

grilling是原语，不是安排在流程里的某个步骤。整个技能生态的访谈能力都以它为单一事实来源：

• 两个用户触达前门：grill-me（无状态，写零文件，可在任何地方对任何事运行，主题不必是代码）与 grill-with-docs（有状态，读取代码库对齐，把所学写进CONTEXT.md与 ADR）；grill-with-docs又是主构建链的起点，衔接 to-spec。
• 被嵌入的大型流程：wayfinder 用它解决决策票，triage 用它把模糊报告盘问成可执行形态，improve-codebase-architecture 用它走深候选方案的设计树。
• 路由与配套：不确定该用哪个入口时，ask-matt 负责导流；访谈中涉及术语澄清、CONTEXT.md更新与 ADR 记录时，配套 domain-modeling 技能按需并行工作。

如果你正在编写自己的技能且需要一次访谈，正确的做法是直接调用/grilling，而不是另写一套访谈逻辑——这正是"原语"设计的本意。

小结

grilling用一棵设计树、一条前沿和一轮轮按格式编号的提问，把"拷问一个想法"从随意的头脑风暴变成了可复现、可收敛、职责清晰的工程流程：事实由 Agent 与子代理负责查证，决策必须交还用户，前沿清空后还需用户确认共识才能行动。无论是直接输入/grilling，还是经由grill-me、grill-with-docs、wayfinder、triage等包装技能被间接触发，它都以同一套轮次机制工作，是整个技能集中"访谈能力"的单一事实来源。对于想为自己的技能引入访谈环节的开发者，掌握它的轮次格式、前沿纪律与事实/决策切分，是让"拷问"真正产生价值的关键。

【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills