用途
readchk 用于在投入非平凡工作之前，验证模型对用户指令的理解是否正确。它要解决的问题是：误读的指令可能在错误的目标上产生看似连贯的工作。readchk 会在这种代价发生之前将其拦截。
它核验的是关于请求者意图的主张，依据是可用上下文：当前消息、会话历史、项目记忆、磁盘上的文件以及既有约定。
需要区分的是：readchk 不是 factchk。它关心的是“对方想表达什么”，而不是某个关于世界的陈述是否真实。
主要能力
- 识别需要核验理解的信号：冗长或多部分的指令、含糊的范围或指代、刻意灵活的措辞，或错误猜测会带来真实工作代价的高风险场景。
- 用自己的话在内部复述指令，而不是把用户的措辞原样抄回给自己并当作理解。
- 将复述内容与可用上下文交叉核对，寻找矛盾、缺失的先行词，或上下文无法在两种合理解读之间做出选择的状况。
- 若上下文能够解决该解读，则静默继续，不要求请求者确认上下文已经回答的内容。
- 若存在真实分歧，则提出一个具体的澄清问题，并锚定在复述后的理解上；要点明选项，而不是笼统地问“这样对吗？”。
- 对重要工作，在开始前记录一行持久的“理解为：……”日志，以便后续读者审计工作是否与已确认的解读一致。
使用方式
工作流程如下：
- 识别信号：长指令或多部分指令、含糊的范围或指代、刻意灵活的措辞，或高风险到错误猜测会耗费真实工作的程度。
- 用不同措辞在内部复述指令。不要复制用户措辞并当作理解。
- 将复述与可用上下文交叉核对。寻找矛盾、缺失的先行词，或上下文无法在两种合理解读之间做出选择的状况。
- 若上下文解决了该解读，静默继续。不要要求请求者确认上下文已经回答的内容。
- 若真实分歧仍然存在，提出一个具体的澄清问题，锚定在复述后的理解上。点明选项，不要问含糊的“这样看起来对吗？”。
- 对重要工作，在开始前记录一行持久的“理解为：……”日志，以便后续读者审计工作是否与已确认的解读一致。
适用场景
- 请求较长或包含多个部分。
- 范围或指代含糊。
- 措辞刻意灵活。
- 风险足够高，错误猜测会耗费真实工作。
- 工作难以撤销。
- 需要为后续审查者留下可审计的理解记录。
规则与限制
- 复述，不要照搬。改写能证明你建立了请求的模型；逐字重复证明不了什么。
- 上下文能解决时保持静默。默认的好结果是不可见的。对已解决或无歧义的请求提出问题是一种缺陷。
- 一次只处理一个分歧。若存在多个含糊之处，先呈现风险最高的那个，而不是倾倒一份清单。
- 绝不静默解决会改变工作形态的分歧。
- 只对重大承诺记录日志，而不是每一轮都记录。持久解读日志适用于计划、多文件改动、不可逆操作，或新审查者可能需要审计的工作。
验证
在继续工作之前：复述是改写；每个呈现的分歧确实无法由可用上下文解决；没有在静默通过或分歧解决之前开始重要工作。
暂未提供的信息
关于该技能的安装方式、具体命令、收费模式、支持平台等信息，资料中暂未提供。