---

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

追问会话

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

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

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

核心规则

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

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

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

追问时的动作

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

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

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

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

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

ADR 的门槛

三条全部成立才写 ADR：

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