---
name: grill-with-docs
description: 对你的计划进行挑战性审问，对照现有领域模型，精炼术语，并在决策形成时实时更新文档（CONTEXT.md、ADR）。当用户想要对照项目语言和已记录的决策对计划进行压力测试时使用。
---

<做什么>

不断地就计划的每个方面对我进行审问，直到达成共同理解。遍历设计树的每个分支，逐一解决决策间的依赖关系。对每个问题，提供你的推荐答案。

一次问一个问题，在每个问题得到反馈后再继续。

如果某个问题可以通过探索代码库来回答，则改为探索代码库。

</做什么>

<支持信息>

## 领域意识

在代码库探索过程中，同时查找现有文档：

### 文件结构

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

```
/
├── 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)？它们是不同的东西。"

### 讨论具体场景

当领域关系被讨论时，用具体场景进行压力测试。创造能够探测边缘情况的场景，迫使用户精确说明概念之间的边界。

### 与代码交叉引用

当用户说明某事物的工作方式时，检查代码是否一致。如果发现矛盾，指出："你的代码取消了整个订单，但你刚才说可以部分取消——哪个是正确的？"

### 实时更新 CONTEXT.md

当一个术语被确定时，立即更新 `CONTEXT.md`。不要批量处理——在发生时捕获它们。使用 [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md) 中的格式。

不要将 `CONTEXT.md` 与实现细节耦合。只包含对领域专家有意义的术语。

### 谨慎提供 ADR

只有在以下三个条件都满足时才提供创建 ADR：

1. **难以逆转**——以后改变主意的成本是有意义的
2. **没有上下文会令人惊讶**——未来的读者会疑惑"他们为什么这样做？"
3. **是真正权衡的结果**——存在真正的替代方案，你因特定原因选择了其中一个

如果三者中任何一个缺失，跳过 ADR。使用 [ADR-FORMAT.md](./ADR-FORMAT.md) 中的格式。

</支持信息>
