技能介绍

一个老问题：长会话里的「假设固化」

在一个持续数小时的会话里，上下文会越积越厚。真正危险的地方不在于信息多，而在于早期的某个假设会在没人察觉的情况下悄悄变成「事实」。模型给出的答案听起来越自信，越容易被直接采纳——但自信不等于正确。当一处分支逻辑、一个跨服务调用、一条数据迁移路径已经写进代码好几层之后，再发现前提错了，回改成本可能已经是生产事故级别。

这个技能要解决的就是这一点：在非平凡输出成立之前，先让怀疑站上评审席。

它怎么做：把证伪做成一道工序

技能的核心动作是 materialize 一个「全新上下文」的审查者——它没有参与前面的上下文积累，因此天然带着证伪而非批准的偏见。它不是来帮你把改动跑通的，是来找漏洞的。

几个关键点：

不是 /review：/review 是对已完成产物的终审裁决；本技能是一种进行中的姿态（in-flight posture），在纠错成本还低的时候，就对决策发起交叉质询。
触发门槛是「非平凡」，满足任一条件即触发：

- 引入或修改分支逻辑
- 跨越模块或服务边界
- 断言类型系统或编译器无法验证的性质（线程安全、幂等性、顺序、不变量）
- 正确性依赖未来读者看不到的上下文
- 爆炸半径不可逆（生产部署、数据迁移、公开 API 变更）

典型场景：在不确定下做架构决策、提交非平凡代码、宣称一个非显然的事实（「这很安全」「这能扩展」「这符合规格」）、在自己不完全理解的代码里工作。

边界：怀疑不是每键必查

技能自己也划了红线——机械操作（重命名、格式化、搬文件）、执行明确无歧义的指令、阅读或总结已有代码、一行且正确性显然的改动、纯工具操作（跑测试、列文件）、用户明确要求速度优先时，都不该用。如果怀疑每一次击键，那你什么都发不出来。它只作用于上面定义的非平凡决策。

另外有一个加载约束：本技能设计给主会话编排器（main-session orchestrator），其中的 DOUBT 步骤需要由它来拉起全新的审查者。不要把它加进 persona 的 frontmatter——那会让一个 persona 拉起另一个 persona，是编排上的反模式。