/grill-me

name: grill-me
description: 针对方案或设计的高强度追问式面试（adversarial design review / grill session），暴露假设漏洞与缺失约束，过程中同步维护领域模型（术语表和 ADR）。手动调用 /grill-me。
argument-hint: "你要追问的方案/设计是什么？"
disable-model-invocation: true

追问会话

启动步骤

触发后，先执行以下检查： 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

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

规则

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

单上下文 vs 多上下文

**单上下文（多数仓库）：** 根目录一个 `CONTEXT.md`。

**多上下文：** 根目录 `CONTEXT-MAP.md` 列出所有上下文及其关系：

# 上下文地图

## 上下文

- [Ordering](./src/ordering/CONTEXT.md) — 接收和追踪客户订单
- [Billing](./src/billing/CONTEXT.md) — 生成发票和处理付款
- [Fulfillment](./src/fulfillment/CONTEXT.md) — 管理仓库拣货和发运

## 关系

- **Ordering → Fulfillment**: Ordering 发出 `OrderPlaced` 事件；Fulfillment 消费它以启动拣货
- **Fulfillment → Billing**: Fulfillment 发出 `ShipmentDispatched` 事件；Billing 消费它以生成发票
- **Ordering ↔ Billing**: 共享 `CustomerId` 和 `Money` 类型

推断当前结构：

• 若 `CONTEXT-MAP.md` 存在，读取它来定位上下文
• 若只有根目录 `CONTEXT.md`，则为单上下文
• 若都不存在，在第一个术语确定时懒创建根目录 `CONTEXT.md`

多上下文时，推断当前话题关联哪个上下文。不确定时，问。

---

参考：ADR 格式

ADR 存放在 `docs/adr/`，使用顺序编号：`0001-slug.md`、`0002-slug.md`……

懒创建 `docs/adr/` 目录——只在第一个 ADR 需要时创建。

模板

# {决策的简短标题}

{1-3 句话：背景是什么，我们决定了什么，为什么。}

一个 ADR 可以只有一段话。价值在于记录**做了**什么决策以及**为什么**——而非填满各个章节。

可选章节

仅在确有价值时才加。大多数 ADR 不需要。

• **Status**（`proposed | accepted | deprecated | superseded by ADR-NNNN`）— 决策被重新审视时有用
• **备选方案** — 仅当被否决的替代方案值得记住时
• **后果** — 仅当存在不显而易见的下游影响时

编号

扫描 `docs/adr/` 找到当前最大编号，加一。

什么适合做 ADR

• **架构形态。** "我们使用 monorepo。" "写模型使用事件溯源。"
• **上下文间的集成模式。** "Ordering 和 Billing 通过领域事件通信。"
• **有锁定效应的技术选型。** 数据库、消息总线、认证提供商、部署目标。
• **边界与范围决策。** "Customer 数据由 Customer 上下文拥有；其他上下文只通过 ID 引用。"
• **对显而易见路径的刻意偏离。** 让未来读者不会误以为是 bug 而"修复"它。
• **代码中不可见的约束。** "因合规要求不能使用 AWS。"
• **被否决方案的理由不明显时。** 防止六个月后有人重新提出同样建议。