Skill Learning

grilling

1. Bilingual SKILL.md

左右滑动可直接切换英文版与中文版;两种语言按段落自动对齐。英文中的蓝色虚线词语可点击查看解释。共标记 10 处。

入口 skill:grilling左右滑动切换语言 · 段落位置自动对齐
Interview the user relentlessly until you . Map this as a **design tree**: every decision branches into the .
Work the tree in **rounds**. The **frontier** is every decision : the questions you can ask _now_ you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Format a round like so:
``` ❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices> ➡️ <your recommended answer> --- ❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices> ➡️ <your recommended answer> ```
Each round the user answers : settled decisions and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is , so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
The session is done when the frontier is empty: every branch of the design tree visited, . Do not act on it until the user confirms you have reached a shared understanding.
持续追问用户,直到双方达成共同理解。把它映射成一棵**决策树(design tree)**:每项决策都会分叉为依附于它的后续决策。
分**轮次(rounds)**推进这棵树。**前沿(frontier)**是所有前置条件已经确定的决策:也就是你现在可以提出、而无需猜测尚未听到的答案的问题。在一轮中询问整个前沿:给每个问题编号,并提供你建议的答案。然后等待用户回答,再进入下一轮。
一轮应采用如下格式:
``` ❓ **Q1** - **<问题标题>**:<问题正文,可以有多个段落,也可以包含多个选项> ➡️ <你建议的答案> --- ❓ **Q2** - **<问题标题>**:<问题正文,可以有多个段落,也可以包含多个选项> ➡️ <你建议的答案> ```
用户每回答一轮,都会重塑这棵树:已经确定的决策把前沿向外推进,并解锁依赖它们的问题。重新计算前沿,然后询问下一轮。如果某个问题的答案依赖于本轮另一个仍未解决的问题,它就属于_后续_轮次,而不是本轮。
查找_事实_是你的工作,绝不是用户的工作。当某个前沿问题需要来自环境(文件系统、工具等)的事实时,派出一个子代理去查找;凡是你自己能够查到的,就不要问用户。不要因此阻塞:正在进行的探索是一项尚未解决的前置条件,所以只有它下游的问题需要等待子代理报告;当前前沿里的其余问题照常询问。_决策_属于用户:把每项决策交给用户,并等待回答。
当前沿为空时,会话才算完成:决策树的每个分支都已经遍历,不留下任何未经说明的假设。在用户确认双方已经达成共同理解之前,不要据此采取行动。

Entry SHA-256: 10ff989e7498b23b5acb49d5048f11dcd906757d2f79c5cdf8a00001381296f2

2. Why This Skill Is Clever

一句话核心机制

把规划讨论建模为一棵有依赖关系的决策树,每轮只批量询问所有前置条件已解决的“前沿”问题,答案回来后再重算下一轮。

触发与边界

直接来源: frontmatter 把触发条件定义为用户想对计划、决策或想法做压力测试,或使用任何 grill 触发短语。正文同时规定,事实由 agent 查,决策必须交给用户;直到用户确认达成共同理解之前,不得开始执行。

支持性上下文: 仓库的插件清单把 grilling 列为 promoted skill;productivity README 将它放在 model-invoked 分组。配套文档还说明,用户可以直接调用它,但更常见的是由 grill-me、grill-with-docs、triage 或 wayfinder 等上层 skill 复用。以上是架构背景,不属于本页所展示的原始 SKILL.md。

解释: 它不是“替用户做决定”的自动规划器,而是一种在行动前显式消除未知和隐含假设的访谈原语。

信息架构与执行顺序

  1. 把主题展开为 design tree,标出决策之间的依赖。
  2. 计算当前 frontier:只纳入前置决策已经确定的问题。
  3. 在一个 round 里问完整个 frontier,每题编号并附 agent 的推荐答案。
  4. 等待用户回答;答案会改变树、解锁新的下游问题。
  5. 遇到环境事实时并行查证,只让依赖该事实的分支等待。
  6. frontier 为空后仍不执行,先让用户确认双方已达成共同理解。

最巧妙的设计点

1. 用依赖关系代替固定问题清单

“every decision branches into the decisions that hang off it”

直接来源: 问题被组织成树,而不是线性脚本。解释: 后续问题由上游答案决定,因此不需要假装一开始就知道完整访谈路径,也避免问出已经失去意义的问题。

2. frontier 同时保证效率与因果顺序

“Ask the whole frontier in one round”

直接来源: 同一轮批量询问所有当前可回答的问题。解释: 这比一次只问一题更快,又不像“一次问完全部”那样跨越尚未解决的依赖;本质上是对决策图做分层遍历。

3. 推荐答案降低用户作答成本,但不夺走决策权

“give your recommended answer”

直接来源: 每题必须附建议,然后等待用户回答。解释: agent 不能只把分析负担抛给用户,但建议仍是可反驳的提案,不是代替用户作决定。

4. 事实与决策分工清楚

“Finding facts is your job, never the user's.”

直接来源: 可由环境查到的事实不得反问用户,而用户价值判断必须等用户作答。解释: 这条边界同时防止懒惰提问和越权决策,是人机协作中非常可迁移的责任划分。

5. 局部等待,而不是全局阻塞

“only the questions downstream of it wait”

直接来源: 一个后台事实探索只是未解决的前置条件;仅阻塞依赖它的分支,其余 frontier 立即继续。解释: 这把异步研究纳入同一依赖模型,提升吞吐量,同时不牺牲正确顺序。

6. 完成条件包含显式确认门

“Do not act on it until the user confirms”

直接来源: frontier 为空还不等于获准行动。解释: 将“没有更多问题”和“共同理解已被用户确认”拆成两个状态,防止 agent 把访谈结束误当作实施授权。

防失败机制与 trade-off

源中明确的不变量: 同轮问题不能相互依赖;每题编号并给推荐答案;事实由 agent 查、决策由用户做;frontier 为空后仍需确认才能行动。

支持性上下文: 配套文档坦承 frontier 是 agent 的判断,并非真正执行图算法;模型可能把两个实际互相影响的问题放进同一轮。它还指出,批量提问对慢读、第二语言或依赖顺序聚焦的用户并不总是最佳体验。

解释与可移植性风险: dispatch a sub-agent 假定运行环境支持并行子代理;没有该能力时,应降级为本地工具查询并显式保持分支阻塞状态。frontier 也依赖模型持续维护隐式状态,长会话里最好把树落盘或以结构化数据维护。round 批量化提升吞吐,却会增加单次认知负担。

可迁移原则

今日实践题

假设你要决定是否把一个内部工具开放给客户:请写出第一轮 frontier 的三个互不依赖问题,并说明哪一个事实应由 agent 查询、哪两个决策必须由用户回答。

Evidence note

核心机制、执行顺序与硬性边界来自所选 SKILL.md;调用分组、复用关系和已知局限使用了插件清单、productivity README 与配套文档;关于图遍历、吞吐量和可移植性的判断属于设计解释。

Source & provenance
Repository path
skills/productivity/grilling/SKILL.md
Generated
2026-08-28 08:23 Asia/Shanghai
Upstream commit
6654f6b60cd9d5be8b54c6fafe44346dabeb3b76
Source
View on GitHub