drill

针对正在讨论的计划或设计运行 core-interview 技能。访谈还会根据项目的领域模型检验计划。

快速路径：如果 docs/specs/ 中已有定稿规范涵盖此请求，直接进入 implement。否则，先在内部明确请求。思考顶尖专家会如何处理：使用哪些资料、采用哪些方法，以及用什么外部检查来证明结果。外部检查是来自工作之外的证据：测试运行器、在线系统或独立来源。弄清楚用户真正想要什么，以及请求是说得太多还是太少。删去无助于实现目标的约束。只添加能改善结果的内容，不要扩大工作范围。将属于用户的选择留给用户。不要向用户展示改写后的请求，只展示下面那句计划。然后判断请求的规模。没有真正决策树的请求显而易见。例如，一项显而易见的改动、一个小型 diff，或一句话就能说明的标准。说明请求显而易见，并将那句话作为计划直接进入 implement。这句话应将外部检查作为验收标准。显而易见的改动不要编写规范。快速路径仍需检验这句话：先陈述这句话，再进行检验。如果无法陈述这句话，或者这句话表明仍有待做出的决策，那么请求就不显而易见。此时运行访谈。

1. 在提出第一个问题前，先阅读项目背景：代码、文档和近期提交。
2. 在提出第一个问题前，查找根目录下的 CONTEXT.md。还要查找 CONTEXT-MAP.md 及其列出的每个 CONTEXT.md。查找 docs/adr/ 下的 ADR，也要查找仅适用于单一上下文的 ADR。
3. 对于没有 CONTEXT.md 的非简单代码库，主动提出从代码和文档中收集候选术语。在访谈中逐个向用户确认。只有用户确认后，才能将术语加入术语表。
4. 如果请求包含多个相互独立的部分，说明这一点。先深入讨论第一部分，其余部分留待后续。
5. 在选择方向前，先展示 2 或 3 种不同方案及其取舍，而不是同一方案的不同变体。按照 穷尽设计空间 的说明，将推荐方案放在首位。当新需求加入现有设计时，其中一个方案应为从第一性原理重新设计。根据设计警示信号检查每种架构形态。有些决策取决于文字无法确定的外观、感受或流程。对此，运行 prototype 技能构建一次性原型，让用户作出反馈。用户选定方向后，将原型丢弃。
6. 当决策树中的每个分支都解决后，本次会话即告结束。然后简要总结定稿的设计。在开始任何实现前，取得用户的明确同意。
7. 如果定稿设计涉及实现工作，在目标项目中将规范写入 docs/specs/<slug>.md。使用 spec-format.md：目标、非目标、可验证的验收标准、验证命令，以及分阶段迁移时的各个阶段。将快速路径中的外部检查纳入验证命令。
8. 有时本次会话无法解决决策树中的问题。决策可能需要在此上下文之外进行研究后才能确定，或者决策树对单次会话来说过于庞大。这时，不要为尚未定稿的设计编写定稿规范。应将规范写为草稿：draft-spec.md。

规则：

• 从设计中移除所有既定约束未要求的内容。根据体验优先检查保留的内容。当产品范围、用户体验或界面方面的取舍将易于实现置于用户体验之上时，请阅读该文档。
• 仅在文件有内容时才创建文件。确定第一个术语后，创建 CONTEXT.md；完成第一个 ADR 后，创建 docs/adr/。
• 在访谈中，**要求用户遵循术语表。**如果用户赋予某个词的含义与 CONTEXT.md 中的不同，请立即指出。例如：“术语表中，退款指的是 X。你似乎指的是 Y。到底是哪一个？”
• 在访谈中，**替换含糊的词。**遇到含糊的词或有多种含义的词时，给出一个确切术语。例如：“你说的‘用户’是指账户持有人还是操作员？两者不同。”
• 在访谈中，**用具体案例验证。**当两个概念交界时，挑选一个处于两者边界的具体案例，并询问会发生什么。
• 在访谈中，**对照代码核实说法。**用户描述某项功能如何运作时，请查看代码，并指出每一处差异。例如：“代码会退还整笔付款。你描述的是部分退款。哪种说法正确？”
• 在访谈中，**术语确定后立即记录。**术语一旦确定，就更新 CONTEXT.md，不要等到最后。它只是术语表：不得包含计划、备注或实现选择。使用 terms.md 中的格式。
• 在访谈中，**尽量少创建 ADR。**只有符合 decision-record.md 中三项标准的决策，才提出创建 ADR：该决策难以撤销、从代码中难以理解，而且是经过权衡真实备选方案后作出的。
• **后续会话基于草稿开展。**如果会话打开的规范仍包含 ## Open decisions 部分，请遵循 draft-spec.md。