grilling

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

持续访谈用户，直到双方达成共同理解。把对象画成一棵**设计树**：每个决策都会分出后续决策。

不是所有歧义都值得入树：一个假设如果可逆、且即使选错也不会实质改变结果，直接声明它并继续推进，不要为它开分支。树越小，用户要做的决定越集中在真正重要的地方。

按**轮次**推进这棵树。**前沿（frontier）**是所有前置条件已经确定的决策：现在就能问、不必猜测尚未听到的答案。一轮之内问完整个前沿：给每个问题编号（Q1、Q2……），并给出你建议采用的答案。然后等待用户回答，再进入下一轮。

## 提问方式：结构化提问工具优先

**每一轮提问都必须通过宿主的结构化提问工具发出，严禁把问题当普通文本输出。** 这类工具会把问题渲染成可点选的交互界面，用户点选即可作答；纯文本问题在很多宿主里只会被当成普通回复刷过去，用户得手动打字回答，是本 Skill 失效的最常见原因。

开始前检查当前工具描述、适用模式和调用限制，使用本轮实际可用的结构化提问工具。工具不存在、当前模式不允许、调用失败或不能表达所需问题时，使用文末纯文本格式；不为确认已知限制故意调用一次失败工具。

使用工具提问时遵守：

- **即使一轮只有一题，也必须用工具。** 不要用“问题少”当借口退回纯文本。
- **调用前先用一两句普通文本铺垫**：这轮哪些决策已定、剩下哪些为什么需要用户拍板。很多宿主要求工具调用前必须有这条说明，它也让用户知道马上要回答问题。
- **按工具容量分批覆盖前沿**。同步工具每批等待回答后再发下一批；异步工具只有在宿主允许时才并发发出独立问题。回答改变前提时重新计算剩余问题，避免继续发送已失效选项。
- **每问都给出建议答案**：把推荐项放第一个选项，标签后缀“（推荐）”；开放问题没有选项可给时，在问题正文里写明你的建议。需要多选的决策，按宿主工具的标注方式注明（如 `(multi)`）。
- 问题编号仅用于跨轮引用，写在问题标题里即可；不要画蛇添足加表情符号或特殊排版，工具会自行渲染。

纯文本降级格式（工具不可用或不能承载当前问题时使用）：

```
**Q1 · <问题标题>**

<问题正文，可以有多段，也可以列出选项>

建议：<你建议采用的答案>
```

## 推进规则

用户每回答一轮，树就会改形：已确定的决策把前沿往外推，解开依赖它们的问题。重新计算前沿，再问下一轮。答案仍依赖本轮尚未关闭的另一个问题的，属于*更后一轮*，不能放进本轮。

查找*事实*是你的工作。平台允许且有可独立进行的调查时，可委派只读子代理；否则自己查证。只等待依赖该事实的问题，其余前沿仍可推进。*决策*属于用户：逐项交给他们，并等待回答；沉默或超时不算确认。

界面外观、布局或交互确实需要实物比较时，可使用已安装的 `prototype`；未安装时用当前能力提供等价的可视化。简单决策不额外搭建原型。

## 收敛与去向

前沿为空时，设计树的每个分支都已走过，没有静默假设。此时先输出**收敛摘要**（摘要是陈述，直接以文本输出，不走提问工具），固定四节：

- **方案**：收敛后的做法，最短连贯表述
- **假设**：已声明的可逆假设
- **排除项**：明确不做的部分
- **验收判据**：完成以什么可观察结果为准，这也是 `/implement` 需要的输入

随后用同样的提问方式（工具优先）确认去向，作为最后一轮。选项固定为：

- A. 只是聊聊 —— 到此为止，不写文件
- B. 落盘成执行清单 —— 转 `/to-checklist` 写入 `.plans/` 下的本地文档（归 gitignore），过目后由 `/implement` 逐批执行
- C. 直接动手 —— 一步能完成的小改动才选，转 `/implement`

根据方案规模标注推荐项：涉及多步骤或多文件时推荐 B。

在用户确认摘要与去向前，不得据此采取行动。

From iZiTTMarvin/agent-skills-zh, MIT.

More from iZiTTMarvin/agent-skills-zh