readback

在开始执行前，用自己的话重述指令，并结合上下文核对。

目标

在错误目标上开始工作之前，发现对指令的误读。根据当前消息、会话历史、项目记忆、磁盘上的文件和既定惯例，核对请求者的本意。如果上下文足以确定解读，就不提问，直接继续；如果仍有两种可能的解读，就针对两者之间的选择向请求者提出一个具体问题。

工作流

1. 识别信号：指令较长或包含多个部分、范围或指代不明确、措辞刻意留有余地，或者事情风险较高，误猜会造成实际返工，包括难以撤销的工作。
2. 用自己的话重述指令。照抄用户的话不算理解。
3. 根据可用上下文（消息、会话历史、项目记忆、磁盘上的文件，以及目标中提到的惯例）核对重述内容，查找矛盾、缺失的先行指代，或上下文无法排除的两种合理解读。
4. 如果上下文足以确定解读，就不作说明，直接继续。不要询问请求者确认上下文已经给出的答案。
5. 如果仍存在分歧，就提出一个与重述后的理解相联系、明确说明选项的具体澄清问题，绝不要问“这样看起来对吗？”之类的模糊问题。由请求者作出决定：收到答复后，再继续会改变工作形态的工作。
6. 开始大量工作前，记录一条以 understood as: 开头的持久记录，写明已确认的解读，方便之后的读者据此核对工作。将它保存在工作已有的计划或任务文件中；如果没有，就写入交付工作成果的提交消息或拉取请求正文中。

规则

• 改述表明已建立对请求的理解；逐字重复则几乎不能说明理解。
• 对上下文足以解决或本身没有歧义的请求提出问题，属于缺陷；应不作说明，直接继续。
• 一次只提出一个分歧，优先处理风险最高的，绝不要列出一连串歧义供人确认。
• 绝不能默默决定会改变工作形态的分歧。
• 对计划、多文件更改、不可逆操作，或需要新审阅者进行审计的工作，保留持久解读记录；不要在每轮对话中都记录。如果符合这些情况，即使默默确认后继续，也要写下这条记录。
• 与同类技能的边界：readback 用于核实意图；factchk 用于核实关于现实世界的说法是否属实。只需说明这是边界，不要调用它。此技能不调用任何技能。

验证

继续之前，确认：

• 重述是改述。
• 提出的每个分歧都确实无法通过可用上下文解决。
• 开始大量工作前，要么已默默确认解读，要么已解决分歧。