TsCarpe Doubt Review（对抗式决策复查）
定位：自信的答案不等于正确的答案。长会话中，假设会悄然变成"事实"。本 skill 是 in-flight 复查——决策落地前质疑它，不是事后的代码质量检查（如 trellis-check、/code-review）。
何时触发
非平凡决策定义（任一命中才触发）
- 新增/修改分支逻辑或状态机流转
- 跨模块/跨域边界，影响 ER 或公共组件
- 断言编译器无法验证的属性（事务边界、幂等、数据一致性、租户隔离）
- 不可逆或大爆炸半径（删数据、迁移、审核状态变更）
触发场景
- 大需求切片发现影响 ER/公共组件的偏差，回写上层设计文档前
- design.md 关键决策定稿前（技术设计评审前）
- 复杂 SQL 定稿前（join 3 表+ / 租户隔离条件 / 聚合口径）
- 代码提交前，对"全范围检查已通过"这一断言本身存疑时
- 用户明示触发
不触发（防滥用）
命名选择、单层内实现细节、spec 已直接覆盖的规则、机械性改动（重命名/格式化/移动文件）、用户明确要速度不要验证。
五步闭环
复制此 checklist 跟踪：
Doubt cycle:
- [ ] Step 1: CLAIM — 2-3 行命名决策 + 为何重要
- [ ] Step 2: EXTRACT — 提取 artifact + contract，剥离推理，不含 CLAIM
- [ ] Step 3: DOUBT — Agent 子代理 + 对抗 prompt
- [ ] Step 4: RECONCILE — 每条发现按四分类回 artifact 文本归类
- [ ] Step 5: STOP — 满足停止条件（平凡发现 / 3 轮 / 用户 override）
Step 1: CLAIM
CLAIM: "订单取消走快照回滚而非实时表反查，在并发操作场景下数据一致"
WHY: 不一致会导致取消后订单列表与操作记录不符
写不出 2-3 行的紧凑 CLAIM = 还没有决策，只有感觉——先想清楚再质疑。
Step 2: EXTRACT（最关键的一步）
给审查者只准备两样东西：
- ARTIFACT：被审制品——代码 diff、design 片段、SQL，不是整个文件
- CONTRACT：它必须满足什么——接口契约、数据约束、业务规则
剥离自己的推理过程，明确不传 CLAIM——传了结论，审查者会顺着附和。制品大到审查者一遍读不完（如 500 行 PR），先拆分再提取。
Step 3: DOUBT
用 Agent 工具生成子代理（隔离上下文 = 天然 fresh reviewer），prompt 用下方对抗模板。可用 Code Reviewer / general-purpose 类型，但对抗 prompt 必须原样传入以覆盖其默认输出形态。
Step 4: RECONCILE
审查输出是数据，不是判决——每条发现回到 artifact 文本归类后才算数。按下方四分类表处理。不要因为审查者"上下文更新鲜"就服从它。
Step 5: STOP
满足任一即停：下一轮只剩平凡/已考虑过的发现；3 轮上限（3 轮仍有实质问题 = 制品不行，升级用户，不要磨第 4 轮）；用户明确说"就这样"。
对抗 Prompt 模板
模板与 sdlc-gate skill（
../sdlc-gate/SKILL.md，同集合安装时与本 skill 同级）Step 2 的对抗模板同源；输出形态按消费方有意分化——本 skill 会话内 RECONCILE 消费，行级证据即可；sdlc-gate 输出汇总进 issues 文件，需结构化四字段（标题/原文/位置/严重度）。单独安装本 skill 时该引用仅作来源说明，不依赖其存在。
Adversarial review. Find what is wrong with this artifact.
Assume the author is overconfident. Look for:
- Unstated assumptions
- Edge cases not handled
- Hidden coupling or shared state
- Ways the contract could be violated
- Existing conventions this might break
- Failure modes under unexpected input
- Concurrency or race conditions under parallel access
- Irreversible or hard-to-rollback changes
Do NOT validate. Do NOT summarize. Find issues, or state
explicitly that you cannot find any after thorough examination.
输出仅限问题清单，每条附 artifact 中的行级证据（引用原文）。
ARTIFACT: <粘贴 artifact>
CONTRACT: <粘贴 contract>
RECONCILE 四分类（按此 precedence 逐类过滤，首个命中即归类）
| 分类 | 判定特征 | 处置 |
|---|---|---|
| 1. 契约误读 | 审查者因不知道的上下文误报（数据来源是内部可信的、上游已校验、变更是注释里写明的有意设计） | 先补全 CONTRACT 再进下一轮 |
| 2. 有效可行动 | 真问题，artifact 确实违反 contract | 修改 artifact，重走 DOUBT |
| 3. 有效权衡 | 真取舍但修复成本大于接受成本 | 在 decisions.md 或 design.md 备注后放行，让用户看见 |
| 4. 噪音 | 同义反复/风格偏好/对不存在场景的防御 | 记下，跳过 |
消费侧详表（甄别他人评审的误报形态）可引用项目内的 AI 评审误报甄别表（如使用 Trellis 的项目在 .trellis/spec/guides/index.md「核对 AI 评审结论时」）——每条 CRITICAL/WARNING 都要回到代码里验证；该文件读不到时跳过，详表是增强材料，不阻塞五步闭环。
红旗（过程性，自查）
- 跳过 EXTRACT 直接把结论传给了审查者
- 审查者输出形态变成"验证/总结"而非"找错"（对抗失效，重发 prompt）
- 3 轮后还在磨同一条发现
- 应触发场景未触发且无用户豁免（静默跳过）
- 2 轮以上审查有实质发现、却零条被归为可行动（在演戏质疑，停止并升级）