are-decisions-from-this-session-saved

本次会话的决定都保存了吗？

在会话结束时问一个问题：如果我们现在停下，关于这个系统的规划中，有什么会丢失吗？ 会话中对正在构建的东西达成的任何结论，在有人把它写到某个载体上之前，都只存在于对话记录里，而下一次会话不会读取对话记录。此技能会找出这些结论，逐一检查它们是否记录在应当记录的载体上，并弥补差距——要么记录下来，要么由人明确表示不予保留。最后，它会直接回答这个问题：设计中没有任何内容需要重新决定；你可以结束会话——或者，如果还没做到这一点，就明确指出还差什么。

主题是系统，而不是会话。 这里是如何完成工作的——调用了哪个技能、人类如何要求你推进、任务进行中你在哪些方面被纠正——这些都不属于规划，也不在范围内。请参阅不在范围内的内容；提起这些内容，会让真正重要的两个决定淹没在十个无关决定之中。

会话是信息来源，而不是跟踪器。 其他所有规划技能都从问题单着手，再逐步展开。此技能则从本次会话中做出的决定着手，并检查它们是否都已记录。只存在于这段对话中的决定，距离从未发生过只差一个上下文窗口。

未经人类同意，不会写入任何内容，也不会丢弃任何内容。 每一项都会记录到人类指定的位置，或者因为人类明确表示而不予保留。因此，无需事先询问，就可以在会话结束时安全地调用此技能——它只提出建议；每一项都由人类决定。

如何判定

判断标准：没有看过这段对话的人，会因此以不同的方式规划或构建系统吗？ 如果会，就属于范围内。下面所有内容都由这个问题推导而来。

• 对地图或问题单中尚未解决的问题给出的答案
• 对系统结构、行为或约定的选择——包括 “我们试过 X，不会采用 X”
• 工作过程中发现的约束或边界——“这项内容要等 Y 完成后才能纳入”
• 范围决定——确定本次工作是否纳入某项内容

同样不在范围内的内容： 重述规格中已有的内容、差异内容会显而易见的内容，以及经过权衡但仍未解决的问题。未解决的问题不是此技能要处理的内容，但不要丢弃它——请在报告中列出，让人类决定是否为它创建问题单，或继续将其作为未决事项。

不在范围内的内容

会话的工作方式。 这些内容看似是决定，也常常被明确地提出，但不符合上述判断标准——不了解这段对话的人在规划这个系统时，不会受到它们的影响：

• 使用了哪个技能或工具、使用顺序，以及给它的指示
• 人类要求你如何推进——一次只问一个问题、不使用子 Agent、写入前先询问
• 对你的工作风格、措辞或流程的纠正
• 为完成任务采取的步骤，以及与此仓库检出版本的操作机制有关的任何内容

确实应当延续到会话之外的工作方式，已经有对应的存放位置——AGENTS.md、规则、地图中的 Notes、工具环境自身的记忆——而将内容写入这些位置是人类另行发起的操作。如果人类在检查过程中提出这类内容，请按其指定的位置记录，然后继续。绝不要主动提起，也绝不要用它们来凑数。

流程

1. 清点本次会话中已确定的系统事项

从头重读本次会话，而不是依赖你的记忆。边读边按照如何判定中的标准逐项检查候选内容——如果交给人类的清单中还包含工作风格方面的内容，就已经失败了，因为现在还要由人类来筛选。每个保留下来的候选事项用你自己的话写成一行，并注明它来自哪段交流，按时间从早到晚排列。

包括你认为已经记录下来的决定。第 2 步会对照相应载体核实；在会话进行期间，“打算写下来”的决定和“已经写下来”的决定看起来完全一样。

完成标准： 你已经列出编号清单，其中每一项都会改变他人规划或构建系统的方式。

2. 检查每项内容是否已经记录在应有的位置

去查看。不要凭记忆判断自己是否写过：

• 决策工单——那里有解决方案评论吗？工单已关闭吗？
• 映射文档——Decisions so far、Not yet specified、Out of scope、Notes
• 本应记录该决策的规范文件
• 对于构建过程中作出的决定，检查实现工单或 PR

将每个候选项标记为 已记录（附上能证明这一点的链接）、已过时（该位置的内容与本次会话中后续对话所推翻的内容一致）或 未记录。

完成条件： 每个候选项都带有上述三种标记之一。

3. 与用户逐项处理缺漏

对于每个未记录或已过时的候选项，提出一个 AskUserQuestion：说明你对该决定的理解，以及你建议将它放在哪里。建议一个归档位置，不要提供选项列表——决策应放在哪里通常足以确定位置。提出问题是为了让用户纠正你的理解、指定其他位置，或放弃该决定。

每个问题都必须包含 “算了” 这一选项。每个问题只问一个决定；把多个问题合并成一段文字，很容易导致其中某个问题没有得到回答。

完成条件： 用户已为当前候选项指定归档位置，或选择了放弃。

4. 按用户指定的位置记录

遵循归属技能的约定进行记录，绝不要自行创造格式——/wayfinder 负责映射文档和决策工单格式，/decisions-to-specs 负责规范。若不确定，就阅读归属技能；本技能刻意不保存这些格式的副本。

/decisions-to-specs 仅供人类使用，因此无法在此处解决需要写入规范的决策。目前，这类决策的记录位置是跟踪器——解决方案评论和映射文档条目——这正是流程预期用来稍后将决策纳入规范的内容。在报告中注明待处理的规范工作，并暂且保留。

完成条件： 该位置显示了这一决策，且你已拿到链接。

5. 循环处理，直到列表清空

处理下一个候选项，然后返回第 3 步。只有当每一项都已记录，或经批准后被放弃，才能结束检查——不是列表变长时，也不是会话上下文快用完时。

如果上下文不足，无法处理完列表，就直截了当地说明，并按决策列出仍未解决的事项。明确报告检查尚未完成，之后还能继续处理；悄无声息地停下，比从未开始还糟。

完成条件： 没有候选项仍未标记。

6. 报告

每个决定用一行说明——决定内容、记录位置和链接——并将已放弃的决定集中放在最后。结尾说明流程还有哪些待办：等待 /decisions-to-specs 处理的决定、等待 /specs-to-tickets 处理的规范，以及用户可能希望转成工单的问题。

完成条件： 报告中包含清单里的每一项。

7. 回答问题

这项技能就是为了回答这个问题。请用用户的原话直接回答：

如果我现在结束本次会话，还需要重新决定系统设计中的任何事项吗？

只有在每一项都已在某个位置得到验证——你有链接，也实际查看过——或已获用户批准后放弃时，答案才是不需要。此时请明确直说，不要含糊其辞：

不需要。系统设计中的任何事项都不必重新决定。你可以结束本次会话。

如果答案还不是“不需要”，就按名称说明哪些事项需要重新决定，然后返回第 3 步——任何尚未回答的缺漏，无论多小，都会让答案变成需要。

完成条件： 用户得到明确的“需要”或“不需要”答复；如果答案是“需要”，还要列出具体哪些事项需要再次决定。

答案必须经得起核查

人们很容易想用一句漂亮的话收尾，而这里是唯一一处：一味迎合会造成真正的伤害。错误地说“你已经理清了”比不做检查更糟，因为这样一来，人就会停止寻找。

• **“已记录”意味着你查看了对应位置，**确认那里写明了这项决定——而不是只发了一条评论，就假定它已经生效。
• **被遗忘的条目不算作否决。**它们是有意舍弃的；这是决定仍然有效，而不是决定丢失。
• **工作风格永远不能让它变成是。**它从未属于范围，因此不可能丢失——参见不在范围内的内容。
• 确实是“不”，就别含糊。“不，不过你或许可以……”听起来像是“也许”，会让他们去寻找一个并不存在的问题。后续建议应放在第 6 步的报告中，置于答案之前。
• **是“是”也别弱化。**只要有一项决定未记录，答案就是“是”；说清楚是哪一项。

决定记录在哪里

决定……	位置
回答本次会话声称要处理的工单问题	该工单上的解决评论，工单已关闭，且对应内容已列在地图中
已有定论，但不属于任何工单	创建工单并填写答案后关闭——地图索引的是已关闭工单，因此没有工单的决定无处索引
决定哪些工作纳入或排除在本次工作之外	地图的范围部分，并关闭因此失去意义的工单
明确要构建什么，并长期保留	现在记录在跟踪器中；/decisions-to-specs 之后会将其写入规范
在构建过程中作出，涉及实现方式	实现工单或其 PR——如果改变了契约，也要更新规范
最后发现是个问题，而非答案	不属于此技能的记录范围：如果问题明确，就创建工单；如果不明确，就让它保持模糊

可以遗忘，但不能悄无声息地丢弃

人类表示不再保留某项决定——太小、已被取代或走入死胡同——可以舍弃。唯一的规则是，他们明确表示了这一点。被遗忘的决定不会留下任何痕迹：它只会出现在本次会话的报告中，不会出现在其他地方，因为把有意舍弃的内容记下来，只会增加杂乱。

此技能绝不会替他们决定某项范围内的内容不值得保留。擅自认定一项真实决定无关紧要，正是此技能要防止的失误——这与把从未涉及系统的内容强行扯进来，恰恰相反，也绝不是这么做的借口。

它在流程中的位置

它与工作流程并行运行，在本次会话对系统作出决定后执行——例如处理 /wayfinder 工单、在 /implement 执行过程中作出选择，或通过深入质询改变方向。它是 skill-callable，因此收尾或交接流程可以将其串接进来。

/wayfinder 会边做边记录；此技能用于检查它是否做到了，并作为在工单自身解决流程之外作出的每项决定的安全网。