grill-me

追问会话

启动步骤

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

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，不要攒着批量处理。格式参见下方「CONTEXT.md 格式」章节。

CONTEXT.md 必须完全不含实现细节。不要把它当规格文档、草稿本或实现决策仓库。它只是术语表。

审慎提供 ADR

仅当以下三条全部成立时才创建 ADR：

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

---

参考：CONTEXT.md 格式

结构

# {上下文名称}

{一两句话描述这个上下文是什么、为什么存在。}

## 语言

**订单（Order）**:
{一两句话定义该术语}
_避免使用_: Purchase, transaction

**发票（Invoice）**:
向客户发送的交付后付款请求。
_避免使用_: Bill, payment request

**客户（Customer）**:
下订单的个人或组织。
_避免使用_: Client, buyer, account

注：示例语言应跟随项目主语言。中文项目用中文术语，英文项目用英文术语。

规则

• 有主张。 当多个词指代同一概念时，选最好的那个，其余列入 _避免使用_。
• 定义简洁。 最多两句话。定义它是什么，而非它做什么。
• 只收录项目上下文专属术语。 通用编程概念不属于这里。
• 出现自然聚类时分组。 若所有术语属于同一领域，平铺即可。