name: grill-me description: 通过先研究，然后仅询问判断性调用来澄清模糊或冲突的请求。当提示说 “$grill-me”/“grill me”、“ask hard questions”、“pressure-test assumptions”、“clarify scope/requirements”、“define success criteria”，或在实施前请求系统设计/优化决策时使用；在实施前停止。

Grill Me

双钻石模型适配

Grill Me 位于第一个钻石（发现 + 定义）：拓宽上下文，然后在构建之前收敛到一个可行的定义。

发现：先研究；不要询问可发现的事实。
定义：生成一行问题陈述 + 成功标准；仅询问判断性调用。
交接：当选项/权衡仍然存在时，调用 $creative-problem-solver；当准备实施时，交给 $tk / $code / $work。

快速启动

先研究；不要询问可发现的事实。
维护一个运行快照（事实、决策、开放问题）。
仅询问判断性调用：每批优选2-3个独立问题，仅当排序依赖强制序列时使用1个（如果可用，使用 request_user_input；否则注明不可用并使用人工输入块）。
整合答案并重复，直到没有开放问题为止。
生成一个详细的澄清摘要，然后停止（不实施）。

高压澄清模式

当用户要求压力测试时，运行一个更严格的提问循环。

每轮询问2个困难的判断性问题，当独立时；仅当阻塞依赖强制序列时使用1个。
强制具体性（指标、日期、范围边界、负责人）；如果答案模糊，用相同的 id 重新询问。
优先此顺序：目标 -> 约束 -> 非目标 -> 权衡 -> 接受信号。
保持语气直接简洁；避免实施建议。
仅当快照有具体问题陈述、可衡量的成功标准且没有阻塞开放问题时，退出此模式。

提问（工具感知）

维护一个有序的开放问题队列。
分批提问：优选2；当问题独立（无排序依赖）时使用最多3个，仅当需要序列时使用1个。
在高压澄清模式中，每批优选2个困难的判断性问题；仅当需要序列时使用1个。
如果名为 request_user_input 的工具可用，使用它（不要渲染后备人工输入块）。
否则，添加一行说明工具不可用，然后渲染后备人工输入块（如下）。
收到答案后，更新快照并刷新开放问题队列：
- 移除已回答的问题
- 追加新发现的开放问题（包括由答案触发的后续问题）
- 继续循环直到队列为空

循环伪代码

open_questions := 初始判断性调用（有序）
answered_ids := 集合()

while open_questions 非空：
  batch := 取下一个(open_questions, 最大=3, 优选=2)

  if 工具存在("request_user_input"):
    tool_args := { questions: 批转工具问题(batch) }
    raw := 调用 request_user_input(tool_args)
    resp := 解析_json(raw)
    answers_by_id := resp.answers
  else:
    说明 "request_user_input 不可用；使用后备"
    为 batch 渲染后备编号块
    answers_by_id := 从用户回复中提取答案

  for q in batch:
    a := answers_by_id[q.id].answers（可能缺失/空）
    if a 缺失/空 且 q 仍然必需：
      保留 q 在 open_questions 中（重新询问；重新措辞；相同 id）
    else:
      从 open_questions 中移除 q
      answered_ids.添加(q.id)
      用 a 中的事实/决策更新快照

  followups := 使用以下规则从 answers_by_id 和快照推导后续问题
  入队 followups：
    - 如果一个后续问题阻塞其他问题，前置它
    - 否则追加它
    - 根据 id 对 open_questions 和 answered_ids 去重

后续问题推导规则

仅当需要判断性调用以继续时创建后续问题。按顺序应用这些规则：

如果答案扩展范围（“also”、“while you’re at it”、“and then”），添加：“这在这个请求的范围之内吗？” 选项包括/排除。
如果答案引入依赖（“depends on”、“only if”、“unless”），添加：“我们应该假设哪个条件？”（如果可以命名，提供选项；否则自由形式）。
如果答案揭示竞争优先级（速度 vs 安全、UX vs 一致性等），添加：“我们应该优先考虑哪个？” 提供2-3个明确选择。
如果答案不具体（“faster”、“soon”、“better”），添加：“我们应该承诺的确切指标/日期/范围是什么？”。
如果答案包含 user_note 且有多个不同要求，拆分成多个后续问题（但每个问题单句）。
如果后续问题询问可发现的事实，不要询问；相反，将其视为研究行动，并在检查仓库后更新快照事实。

后续问题卫生：

为每个后续问题分配一个稳定的 snake_case id，源自意图（非位置），如果稍后重新询问，保持相同 id。
选择 header <= 12 字符（紧凑名词/动词），保持 question 单句。
当答案空间小时优选选项；对于真正自由形式的提示省略选项。

`request_user_input`（优选）

当可用时，通过工具调用询问最多3个问题。

调用形状

提供 questions: [...] 包含1-3项。
每项必须包括：
- id: 稳定的 snake_case 标识符（用于映射答案）
- header: 短UI标签（12字符或更少）
- question: 单句提示
- options（可选）：2-3个互斥选择
  - 将推荐选项放在第一位，并在其标签后添加"(推荐)"
  - 仅当明确想要自由形式选项时包括"其他"选项
  - 如果问题是自由形式，完全省略 options
如果需要重新询问相同的概念性问题（重新措辞），保持相同 id。

示例：

{
  "questions": [
    {
      "id": "deploy_target",
      "header": "部署",
      "question": "这应该首先部署到哪里？",
      "options": [
        { "label": "暂存环境 (推荐)", "description": "在生产前安全验证。" },
        { "label": "生产环境", "description": "直接交付给最终用户。" }
      ]
    }
  ]
}

响应形状

工具返回一个JSON负载，其中 answers 映射以问题 id 为键：

{
  "answers": {
    "deploy_target": { "answers": ["暂存环境 (推荐)", "user_note: 请同时更新文档"] }
  }
}

在某些运行时，这以JSON序列化字符串形式到达工具输出内容中；在读取 answers 前解析为JSON。

答案处理

将每个 answers[<id>].answers 视为用户提供的字符串。
在TUI流中：
- 选项问题通常返回选中的选项标签，加上可选的 user_note: ...
- 自由形式问题仅返回备注（如果用户未提交任何内容，可能为空）
如果问题使用选项且在推荐选项标签后添加了 (推荐)，选中的标签可能包括该后缀；解释意图时去除它。
如果一个条目以 user_note: 开头，将其视为自由形式上下文，并从中挖掘事实/决策/后续问题。
如果一个答案对于你仍然需要的问题缺失/空，将其保留在队列中并重新询问（可能重新措辞或添加选项）。

快照模板

快照
- 阶段: 发现 | 定义
- 问题陈述:
- 成功标准:
- 事实:
- 决策:
- 开放问题:

人工输入块（后备）

如果 request_user_input 不可用，添加一行说明其不可用，然后使用此确切标题和编号列表：

GRILL ME: 需要人工输入
1. ...
2. ...
3. ...

护栏

永远不要询问代码能揭示的内容；先检查仓库。
保持问题最小化和顺序化。
生成澄清输出后，硬停止。

可交付格式

快照。
请求答案（如果可用，使用 request_user_input；否则使用人工输入块）。
一行见解/下一步。