sdlc-doubt

# Doubt Review（对抗式决策复查） > **定位**：自信的答案不等于正确的答案。长会话中，假设会悄然变成"事实"。本 skill 是 **in-flight** 复查——决策落地前质疑它，不是事后的代码质量检查（如 trellis-check、/code-review）。 ## 何时触发 ### 非平凡决策定义（任一命中才触发） 1. 新增/修改分支逻辑或状态机流转 2. 跨模块/跨域边界，影响 ER 或公共组件 3. 断言编译器无法验证的属性（事务边界、幂等、数据一致性、租户隔离） 4. 不可逆或大爆炸半径（删数据、迁移、审核状态变更） ### 触发场景 - 大需求切片发现影响 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 轮）；用户明确说"...