readchk 是一个在执行非平凡工作之前，先检查模型是否真正读懂用户指令的技能。它的目标是在误读的指令变成针对错误目标的大量连贯工作之前，把误读拦截下来。
用途
readchk 用于验证关于请求者意图的推断是否与可用上下文一致。可用上下文包括：当前消息、会话历史、项目记忆、磁盘上的文件以及既有约定。
需要说明的是，readchk 不是事实核查（factchk）。它要回答的问题是“用户想表达什么”，而不是“某个关于世界的陈述是否真实”。
主要能力
识别需要核对的信号：较长或多部分的指令、含糊的范围或指代、刻意灵活的措辞，或者一旦猜错就会造成真实工作损失的高风险场景。
在内部用自己的话复述指令，而不是把用户的措辞原样抄回给自己并当作已经理解。
将复述内容与可用上下文交叉核对，寻找矛盾、缺失的先行词，或上下文无法在两种合理解读之间做出选择的歧义。
如果上下文已经解决了理解问题，就静默继续，不要求请求者确认上下文已经回答的内容。
如果确实存在无法消除的分歧，则提出一个具体的澄清问题，并锚定在复述后的理解上。要指明具体选项，而不是笼统地问“这样对吗？”。
对于重要工作，在开始前记录一行持久的“理解为：……”日志，以便后续读者能够审计工作是否与确认后的理解一致。
使用方式
按以下流程操作：先识别信号；再在内部用自己的话复述指令；然后与可用上下文交叉核对；若上下文可解决则静默继续；若存在真实分歧则提出一个具体澄清问题；对重要工作记录一行“理解为：……”日志。
适用场景
适用于请求较长、内容捆绑、风险较高、难以撤销或措辞含糊的情况。也适用于范围或指代不明确、措辞刻意灵活、或错误猜测会带来实际工作成本的场景。
限制与规则
复述，不要照搬。改写能证明你建立了对请求的模型；逐字重复证明不了什么。
上下文能解决时就保持静默。默认的好结果是不可见的。对已解决或无歧义的请求提出问题是一种缺陷。
一次只处理一个分歧。如果存在多个歧义，先呈现风险最高的那个，而不是一次性抛出一份清单。
绝不静默解决会改变工作形态的分歧。
只对重大承诺记录日志，而不是每一轮对话。持久理解日志用于计划、多文件改动、不可逆操作，或可能需要新审阅者审计的工作。
验证
在继续工作之前：复述必须是改写；每一个呈现出来的分歧都确实是可用上下文无法解决的；任何重要工作都必须在静默通过或分歧解决之后才能开始。
其他信息
该技能的官方文本、收费方式、价格、支持平台及具体使用步骤暂未提供。