{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Grill Me

在动手实现前做对抗式计划访谈。

Skill 元数据

参考：完整 SKILL.md

Grill Me

在写任何代码之前，通过结构化的对抗式提问压测一个计划。把计划建模成一棵设计树——每个决策分叉出挂在它下面的决策——并分轮访谈用户，直到每个分支都被解决、没有任何东西被默默假设。

结合了原版的阶段纪律和 mattpocock/skills grilling 的 frontier-rounds 机制。

使用时机

• 用户说"grill me"、"访谈我的计划"、"压测这个想法"
• 复杂工作之前：认证流程、schema 变更、迁移、支付
• 计划有未决决策或显得含糊
• 在 subagent-driven-development 分解之前

不要用于已有代码（用 requesting-code-review）或简单一次性任务。

前提条件

无。本 skill 适用于任何计划或原始想法。

核心机制：Frontier Rounds

把计划映射成一棵设计树。frontier 是每个前提都已敲定的决策——你现在就能问、而不必猜还没听到的答案的问题。

按轮次工作：在一条消息里问出整个当前 frontier，编号，每个问题带上你推荐的答案。然后等待。一个答案依赖于本轮仍未决问题的问题，属于更后的轮次，不是这一轮。

每轮格式如下：

❓ Q1 — <问题标题>：<问题正文，如相关附选项>
➡️ 推荐：<你推荐的答案 + 一行理由>

❓ Q2 — <问题标题>：<问题正文>
➡️ 推荐：<...>

每个答案重塑这棵树：已敲定的决策把 frontier 向外推，并解锁依赖问题。重算 frontier，问下一轮。

事实是你的活；决定是用户的。 当一个 frontier 问题需要来自环境（代码库、文件系统、配置、文档）的事实时，自己用 search_files / read_file / terminal 找——或通过 delegate_task 派一个子 agent 做重探索。绝不向用户索要你能查到的东西。不要因探索而阻塞：只有它下游的问题等待；现在就问 frontier 的其余部分。

问题覆盖（把这些分支做进树里）

理解——真实目标和边界：

• 实际目标是什么？明确什么在范围内、什么不在？
• 约束是什么（时间、技术、团队、预算）？用户是谁？

技术决策——对每个架构选择：

• "为什么是这个方案而不是 X？" / "Y 挂了会怎样？"
• "最坏情况是什么？" / "你会怎么回滚？"
• 交叉参考现有代码库；如果项目对此已有模式，点出来。

边界情况：

• "用户做 Z 会怎样？" / "依赖 X 挂了会怎样？"
• "量级是预期 100 倍会怎样？" / "安全影响是什么？"

综合（当 frontier 为空时）

1. 用要点总结所有决策
2. 列出任何仍未决的，以及明确不在范围内的
3. 问："对齐了吗？我该开始实现，还是要调整什么？"

在用户确认共同理解之前，不要按计划行动。

常见陷阱

1. 按依赖顺序之外提问。 一个依赖于未答问题的问题，是戴着问号的猜测。留到后面的轮次。
2. 跳过代码库。 用 Hermes 工具在代码里找事实，而不是问用户。
3. 把"我不知道"当最终答案。 给选项、讲权衡、做推荐。
4. 在拷问期间写代码。 只对齐——明确放行后再写代码。
5. 太顺从。 你的活是找问题。如果一切看起来都好，就看得更仔细些。
6. 不适应用户的语言。 用用户说的任何语言访谈。

验证

•  一轮里每个问题的前提都已敲定
•  每个问题都附了推荐
•  用代码库找事实而非问用户
•  综合前 frontier 为空（没有分支被默默假设）
•  产出了所有决策和未决项的清晰总结
•  停下前确认了用户对齐