grill-me

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

追问会话

启动步骤

触发后，先执行以下检查：

1. 检查项目根目录是否已有 CONTEXT.md 或 CONTEXT-MAP.md，有则读取
2. 检查 docs/adr/ 是否已有 ADR 记录，有则了解已有决策
3. 然后开始追问

核心规则

针对方案的每一个方面进行不留死角的追问，直到我们达成共识。沿着设计决策树逐一走下去，逐条解决决策之间的依赖关系。每个问题给出你的推荐答案。

一次只问一个问题，等我回复后再继续下一个。一次抛出多个问题会让人无所适从。

如果某个事实可以通过探索代码库获得，就直接查找，不要问我。但决策权在我——每个决策都提给我，等我回答。

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

---

领域建模（内置流程）

追问过程中，一旦有决策结晶，就立即建立和完善项目的领域模型——挑战术语、构造边界场景、在第一时间写下术语表和决策记录。

文件结构

大多数仓库只有单一上下文：

/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

如果根目录存在 CONTEXT-MAP.md，则表示仓库有多个上下文，地图指向各自位置：

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← 系统级决策
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← 上下文专属决策
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

懒创建——只在有内容可写时才创建文件。如果 CONTEXT.md 不存在，在第一个术语确定时创建它。如果 docs/adr/ 不存在，在第一个 ADR 需要时创建它。

追问过程中的行为

对照术语表质疑

当用户使用的术语与 CONTEXT.md 中已有定义冲突时，立即指出："你的术语表把'取消'定义为 X，但你现在似乎是指 Y——到底是哪个？"

磨尖模糊表达

当用户使用含糊或多义的词汇时，提出精确的规范术语："你说的'账户'——是指 Customer 还是 User？这是两个不同概念。"

讨论具体场景

讨论领域关系时，用具体场景压力测试。构造探索边界条件的场景，迫使用户精确界定概念之间的边界。

与代码交叉验证

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

即时更新 CONTEXT.md

术语一旦敲定，立即更新 ，不要攒着批量处理。格式参见下方「CONTEXT.md 格式」章节。