tracer-interview-me

持续深入地询问用户，直到双方达成共识。将其映射为一棵设计树：每个决策都会分支出依赖于它的决策。

分轮次推进这棵树。前沿是所有前置条件已经确定的决策——也就是你现在可以提问、而无需猜测尚未听到的答案的问题。每轮一次性提出整个前沿：为每个问题编号，并给出你的推荐答案。然后等待用户作答，再进入下一轮。

每一轮用户的回答都会重塑这棵树——已确定的决策会将前沿向外推，并解锁依赖于它们的问题。重新计算前沿，并提出下一轮问题。如果某个问题的答案取决于本轮中仍未解决的另一个问题，那么它属于后续轮次，不属于本轮。

查明事实是你的职责，绝不是用户的职责。当某个前沿问题需要了解环境中的事实（文件系统、工具等）时，派遣一个全新的探索子 Agent 去查找——不要向用户询问任何你能自行查明的信息。该探索 Agent 负责查找；它返回的证据即可满足这一步事实查明。不要因此停下来等待：正在进行的探索属于尚未解决的前置条件，因此只有依赖它的问题需要等待子 Agent 报告——现在先提出前沿中的其他问题。决策由用户做出——逐一请用户决定，并等待答复。

有代码库时（有状态）

在代码库中运行时，访谈需双向参考文档：

• 第 1 轮前阅读：CONTEXT.md（或 CONTEXT-MAP.md 及相关上下文文件）以及涉及该领域的任何 docs/adr/ 条目。现有术语表和 ADR 都是已确定的决策——它们会在提出第一个问题前裁剪设计树，并据此计算前沿。如果文档不存在，就直接继续；不要一开始就建议创建文档。
• **确定时写入：**某轮解决了模糊或含义过载的术语时，将其记录到 CONTEXT.md 的术语表中；确定了难以逆转的决策时，将其记录为 docs/adr/ 下的 ADR。遵循 /tracer-domain-modeling 的规范和格式（其 CONTEXT-FORMAT.md 和 ADR-FORMAT.md）：术语表只保留术语表内容——不写实现细节；只有当决策难以逆转、若无上下文会令人意外，且确实源于权衡取舍时，才提供 ADR。确定时立即记录，而不是最后集中处理——文档记录能让下一次会话从更小的设计树开始。如果访谈内容与现有 ADR 矛盾，这本身就是一个前沿问题：明确提出（“与 ADR-NNNN 矛盾——要重新讨论吗？”），让用户决定。

没有代码库时（无状态）

没有代码库，或者计划／想法并不属于某个代码库：以同样的方式进行访谈，不读取任何内容，也不写入任何内容。设计树完全存在于对话中；只要保持在同一个上下文窗口内，输出的共同理解便可继续沿用。

完成

当前沿为空时，任务即告完成：设计树的每个分支都已逐一讨论，没有任何事项仍被默默假定。在用户确认你们已经达成共识前，不要据此采取行动。

**然后交接：**用户确认后，提供 /tracer-to-spec——已确定的设计树正是它要综合整理的内容。确保整个访谈和规格说明都保留在同一个连续的上下文窗口中。