/grill-me

name: grill-me
description: 仅当用户显式调用 `$grill-me`，或明确要求"追问我""挑战这个方案""拷打这个设计"时使用。通过高强度逐问逐答检验方案，并同步沉淀术语表和 ADR。不要因普通设计讨论自动触发。

追问会话

对方案的每一个方面不留死角地追问，沿设计决策树逐条走，直到达成共识。追问过程中一旦有决策结晶，就立即沉淀成术语表和决策记录。

开始前先看有没有既有材料：根目录的 `CONTEXT.md` 或 `CONTEXT-MAP.md`，以及 `docs/adr/` 下已有的 ADR。有就读，据此知道哪些概念和决策已经定过。

| 参考 | 何时读 | |------|--------| | [references/context-md.md](references/context-md.md) | 第一个术语敲定、要真正写入 `CONTEXT.md` 时；或需要判断单上下文还是多上下文结构时 | | [references/adr.md](references/adr.md) | 一个决策通过了下面三条门槛、要落笔写 ADR 时 |

核心规则

一次只问一个问题，等回复后再问下一个。一次抛出多个问题会让人无所适从。每个问题都给出你的推荐答案。

能从代码库查到的事实就直接查，不要问。但决策权在用户手里 —— 每个决策都提出来，等回答。

**在用户明确确认达成共识之前，不要开始执行方案。**

追问时的动作

**对照术语表质疑。** 用户的用词与 `CONTEXT.md` 里的定义冲突时立即指出："你的术语表把'取消'定义为 X，但你现在似乎指的是 Y —— 到底是哪个？"

**磨尖模糊表达。** 遇到含糊或多义的词，提出精确的规范术语："你说的'账户' —— 是 Customer 还是 User？这是两个不同概念。"

**用具体场景压力测试。** 讨论领域关系时构造边界场景，逼出概念之间的精确边界。

**与代码交叉验证。** 用户陈述某物如何运作时，去看代码是否一致，发现矛盾立即暴露："你的代码取消的是整个 Order，但你刚说可以部分取消 —— 哪个是对的？"

**即时写入，不要攒批。** 术语一敲定就更新 `CONTEXT.md`。懒创建：文件不存在就在第一个术语确定时建。

ADR 的门槛

三条全部成立才写 ADR：

1. **难以逆转** — 将来改变主意的代价可观 2. **缺乏上下文则令人费解** — 未来读者会困惑"为什么这样做？" 3. **确实是权衡的结果** — 存在真正的替代方案，且基于具体理由选了其一