grill-with-docs

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 中现有语言冲突时，立即指出。"你的术语表将'cancellation'定义为 X，但你似乎指的是 Y — 到底是哪个？"

锐化模糊语言

当用户使用模糊或多义的术语时，提出一个精确的规范术语。"你说的'account' — 你指的是 Customer 还是 User？这是不同的东西。"

讨论具体场景

当讨论领域关系时，用具体场景来压力测试。发明探测边缘情况的场景，迫使用户精确定义概念之间的边界。

与代码交叉验证

当用户陈述某些东西如何工作时，检查代码是否一致。如果发现矛盾，提出来："你的代码取消整个 Order，但你刚说部分取消是可能的 — 哪个是对的？"

内联更新 CONTEXT.md

当一个术语被解决时，当场更新 CONTEXT.md。不要批量处理 — 在发生时就捕获。使用 CONTEXT-FORMAT.md 中的格式。

CONTEXT.md 应该完全没有实现细节。不要把 CONTEXT.md 当作规格、草稿本或实现决策的存储库。它是术语表，仅此而已。

谨慎提供 ADR

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

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

如果三个条件中任何一个不满足，跳过 ADR。使用 ADR-FORMAT.md 中的格式。