用途：该技能要求代理给出的答案符合当前被推荐、被采用的惯用做法，而不仅是“能跑通”。它针对的是代理最容易翻车的场景——代码可运行，却建立在过时 API 或非惯用写法之上。
主要能力：区分“正确/能跑通”“不过时”“最佳实践”三种主张；识别两类需自我怀疑的信号——内部信号（版本敏感事实、变化快的领域、惯用法类问题、写外部 API 代码前）与外部信号（被指出错误、被质疑、对方不耐烦、同一测试或命令反复失败）；外部信号权重最高。核心规则是避免“加倍下注陷阱”：被纠正或反复失败后，不再用同一套记忆和假设重答，先核实再行动。
使用方式：先分诊再反应，从成本最低的检查开始——理解/指令错误就重读需求与上下文；知识/技术错误才去权威来源核实；反复失败则停止重复猜测，先检查是否基于过时知识，否则升级到系统化调试。核实来源按层级：已安装源码/changelog/lockfile、官方文档（MCP 或 llms.txt）、网络搜索（最后手段）。证据层级为实战 > 测试 > 声明，并始终对齐版本。
适用场景：框架、SDK、工具链、CLI flag、配置 schema、环境变量等版本敏感话题，以及“最佳实践/惯用法”类提问。
限制：不建知识库、不缓存核实结果；稳定基础知识、本地可确认事实、对方已明确指定的内容不触发核实；核实结论若支撑交付物，应连同来源写入该次任务的工作文档，而非长期缓存。具体安装与调用方式资料未提供。