烧烤式拷问

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install wait-what
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 wait-what。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

Grilling 是一种 Openclaw Skills 工作流，用于通过分支设计树审查计划和决策。代理不会提出互不相关的问题，而是映射每项决策及其依赖关系，确定当前的问题前沿，并在一轮中以清晰编号提出所有可用问题。
该技能将事实与决策分开：代理使用工具或子代理调查环境事实，而用户作出实际决策。流程会持续进行，直到每个分支都被访问、所有隐藏假设都被揭示，并且用户在采取任何行动前确认双方已达成共同理解。

应用场景

在执行产品、工程或商业计划前进行压力测试。
评估包含多个相互依赖选择的困难决策。
揭示未声明的假设、风险、约束和权衡。
当用户明确要求接受拷问或使用相关触发短语时审查一个想法。
在实施或作出承诺前开展结构化探索。
使用 Openclaw Skills 将模糊讨论转化为明确的决策树。

工作原理

检测用户希望针对某个计划、决策或想法接受持续追问。
构建一棵设计树，其中每项决策都会分支出依赖它的决策。
确定前沿：所有前置条件已经确定的决策。
将环境事实与用户负责的决策分开；使用工具或子代理调查所需事实，而不是询问用户。
在一轮中询问整个可用前沿，为每个问题编号并提供建议答案。
等待用户回答后再进入下一轮。
每次收到回复后重新计算设计树和前沿，将新解除阻塞的决策移入后续轮次。
持续进行，直到前沿为空且每个分支都已检查。
要求用户确认双方已经达成共同理解，在获得确认前不要采取行动。

配置指南

Grilling 是一种由提示驱动的 Openclaw Skills 能力，源技能定义中未指定外部软件包或运行时依赖。请按照兼容 OpenClaw 的宿主环境约定安装或注册该技能，然后让代理可以使用其 SKILL.md 指令。
典型的基于文件的设置方式如下：
mkdir -p ~/.openclaw/skills/grilling
cp SKILL.md ~/.openclaw/skills/grilling/SKILL.md
如果宿主代理要求重新加载技能，请重启或刷新它。通过要求代理就某个计划、决策或想法对你进行拷问，或使用宿主配置的 grill 触发短语来调用该技能。提供的定义不需要 API keys、数据库或其他配置。

数据架构

该技能将推理组织为隐式设计树，而不是生成预定义的文件或数据库模式。
元素 用途
设计树 表示每项决策以及依赖该决策的下游选择。
决策节点 必须由用户解决的问题或选择。
前置条件 在提出另一个问题前必须先确定的既有决策。
前沿 当前可询问且其前置条件已经确定的决策集合。
轮次 包含当前完整前沿、编号问题和建议答案的一批问题。
事实 从环境、文件系统、工具或子代理获得的信息。
决策 由用户作出的选择，代理必须提出并等待回答。
完成状态 前沿为空，并且用户确认双方已达成共同理解。
每个问题都应包含标题、问题正文、可选选项和建议答案。答案会通过确定节点并解锁依赖决策来重塑树。源技能不定义生成的报告、持久化元数据或外部存储要求。

高级特性

基于前沿的提问可防止代理询问前置条件尚未解决的问题。
整个前沿的轮次会创建完整、并行的问题批次，而不是零散的盘问。
建议答案让每个问题都可执行，同时保留用户对决策的主导权。
工具和子代理委派会处理可发现的事实，避免让用户承担环境调研。
感知依赖关系的排序确保下游问题等待其所依赖的决策。
明确的完成检查可防止无声假设，并在共同理解得到确认前阻止行动。
结构化的轮次格式让 Openclaw Skills 对话更易于浏览、回答和审计。

name: grilling description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

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

Work the tree in rounds. The frontier is every decision whose prerequisites are already settled: the questions you can ask now without guessing at answers 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 - ****:

➡️

❓ Q2 - ****:

➡️

Each round the user answers reshapes the tree: settled decisions push the frontier outward 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 an unsettled prerequisite, 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, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

sum-and-translate-install-check
experiment-lifecycle-governance