grill-me

持续深入地采访用户，直到达成共识。将其绘制为一棵设计树：每个决策都会分支出依赖于它的决策。

分轮次推进这棵树。每轮都从研究开始：查明下一轮问题所依赖的所有事实——第一轮还包括探索代码库、CONTEXT.md 和 ADR——并行派遣子 Agent 去查找这些事实。所有子 Agent 都汇报后，研究才算完成。然后才能计算前沿：所有前置条件都已确定的决策——也就是现在无需猜测尚未听到的答案，就可以提出的问题。每轮一次性提出整个前沿：给每个问题编号，并提供你推荐的答案。然后等待用户回答，再进入下一轮。

每个问题都应按以下格式编排：

❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>

每轮用户的回答都会重塑这棵树——已确定的决策会推动前沿向外延伸，并解锁依赖于它们的问题。研究新分支所需的事实，重新计算前沿，并提出下一轮的问题。同一轮中，若某个问题的答案取决于另一个尚未回答的问题，它就属于_后续_轮次，而不属于本轮。

查找_事实_是你的职责，绝不是用户的：凡是环境（文件系统、工具等）能提供答案的，都要查明。研究必须在发出每轮问题之前完成——只要还有任何子 Agent 在执行，就先搁置所有问题，并用一行话告知用户你正在研究什么。每个问题都必须以事实为依据，不能基于猜测，也不能在报告到达后撤回。决策由用户做出——把每个问题交给用户，并等待回答。

当前沿为空时，本次会话才算完成：设计树的每个分支都已探讨，没有任何事情被默认为已确定。在用户确认双方已达成共识之前，不要据此采取行动。

领域认知

探索代码库时，也要留意现有文档：

文件结构

大多数代码库只有一个上下文：

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

如果根目录中存在 CONTEXT-MAP.md，说明代码库有多个上下文。该映射会指出每个上下文所在的位置：

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── 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 中的格式。

---

改编自 mattpocock/skills，MIT © 2026 Matt Pocock。若复制此文件，请保留此行。