plan-doubt 是一个面向智能体的评审技能，核心主张是：自信的计划不等于正确的计划。在不可逆计划被展示、请求批准或执行之前，由一个对计划生成过程没有记忆的全新上下文评审者尝试找出其中的问题。每个计划评审一次，最多 3 轮。
用途与触发条件 该技能仅在计划命中说明中的 A、B、C 三类条件时运行，不做其他触发。A 适用于任何机器，包括个人笔记本电脑；B 和 C 适用于生产环境。数据涵盖每个文件或每一行，包括被 gitignore 的文件（.env、uploads、SQLite）、日志、数据库行。凡无法重建的数据，即 git 历史或种子脚本无法恢复的数据，都在此列。备份可豁免 A（仅 A）：计划须在破坏性步骤前完成备份，备份存放于计划删除命令无法触及的位置，并列出恢复命令；没有恢复命令的副本不算备份；请求与交付报告都须写明备份完整路径和恢复命令。B 和 C 无论有无备份都要运行。如果一个计划把可回滚的代码部署与 schema 变更或数据迁移混在一起，则归为 C。生产环境指任何一旦丢失或被锁定用户就会感知其影响的系统；可重新灌种的本地临时环境不算生产环境。
主要能力 流程分为五步：CLAIM，用两行说明计划运行后仍须成立的内容（数据完好、可恢复、访问权限仅按预期变更）及其重要性；EXTRACT，从两部分构建评审者输入——ARTIFACT（含确切命令的计划，以及计划所依据的事实，每项附发现它的命令）和 CONTRACT（计划必须满足的约束），不含 CLAIM 和自身结论；DOUBT，派发一个全新上下文、只读的子代理，环境中有名为 deep-reviewer 的评审代理时优先使用，否则使用最强模型层级的通用子代理，不向用户询问外部或跨模型评审者；RECONCILE，把发现当作数据，由编排者逐条对照计划文本，按首个匹配类别归档（合同误读：修正 CONTRACT 后重跑；有效且可行动：修改计划后重跑；有效权衡：保留计划并向用户记录权衡；噪声：评审者缺少上下文，记录之）；STOP，最多 3 轮，若某轮只返回琐碎或已处理的发现可提前结束，第 3 轮后仍未解决的实质性问题按原样交给用户，不进行第 4 轮。
评审者提示词要求以对抗性视角找出计划中的问题，假定作者过度自信，重点检查：未备份或无法恢复的状态；范围超出预期的命令（未设置变量、通配符、按时间戳选择）；步骤顺序错误；无法真正回滚的回滚；声明目标之外被副作用改变的权限或数据。不验证、不总结，按严重程度列出问题及命中的步骤，或说明未发现问题及所检查的内容；只读，不做任何更改。
使用方式与结果去向 运行在任何展示计划的请求之前完成；该请求须携带发现、每条发现的归档方式以及计划中的改动。评审本身不增加任何停止点。只读调查后形成的计划，在展示该计划的消息之前接受评审。同一次运行服务于所有要求对同一计划进行二次意见的规则。子代理不能再派发子代理；若计划在子代理内形成，须交回主线程。完全没有可用子代理时，不得自行评审，也不得运行计划，而应在请求中标注“unreviewed: no fresh-context reviewer available”，交由用户决定。即使收到运行计划的明确指令，仍要评审；只有明确要求跳过评审才跳过（“run it”和“I checked it”不算该指令），请求中注明“review skipped at user request”。
实践示例 对一个生产环境 ACL 变更做了三轮评审，依次发现：447 条现有 ACL 条目没有备份；时间戳过滤也会匹配账户已拥有的文件；当 DIR 未设置时，"$DIR"/. 会展开为 /，可能把根文件系统复制进用户主目录。