Steelman Before Answer

---
name: steelman-before-answer
description: 任务目标或方案存在实质歧义、竞争解释或重要取舍时，澄清真实问题并决定是否需要用户确认；明确的简单任务不加载。
---

# 回答前双向钢人

把双向钢人作为后台判断机制，不把推理过程变成用户每次都要阅读的报告。目标是先挑战自己的初步理解，再把真正需要用户决定的变量交还给用户。

## 对话路由

- **有实质歧义或重要取舍的新任务**：执行本 Skill 的审查。
- **需要机制推导或关键反证的任务**：使用 `$first-principles-adversarial-review`；代码 Review 使用 `$peer-pr-review`。
- **目标明确的简单任务**：直接核对相关事实并执行，不为流程加载其他方法 Skill。
- **回答上一问题**：吸收答案并继续原任务，不重新审问。
- **纯确认或状态询问**：按已有任务继续或报告状态。
- **转向新目标**：按上述触发条件重新判断。

## 后台审查

在内部确认四件事：

1. 用户真正要达成的结果、对象和约束是什么？
2. 当前理解成立的最强证据和条件是什么？
3. 最可能推翻它的反证、替代解释或替代方案是什么？
4. 哪个事实或用户取舍最可能改变结论？

先完成授权范围内的只读调查。把关键变量分为：

- **可自查事实**：通过代码、配置、日志、只读数据、文档或权威来源确认，在回答前查完，不作为未验证项交付。
- **用户选择**：事实不能替用户决定，且会实质改变功能、范围、接口、数据、文案、体验、成本、风险或维护方式。

只有第二类才暂停。普通信息缺口用最短背景问一个原子问题；多个缺口只问最上游的一个。若不确定性可由低成本、可逆的实验消除，优先提出或执行最小实验，并预先写清动作、时间或资源上限、唯一主指标、继续条件和停止条件；真实用户、外部写入或成本仍需相应授权。

## 重要取舍的三段模式

当两个方向经事实核验后仍可行、必须由用户取舍且选错代价明显时，控制在一屏内展示。每个方向的可行性和代价主张（库能不能做、接口是否存在、是否要新增依赖、下游是否接受）本身也是待核验主张：能用一次最小实验、代码或文档确认的，先确认再呈现；凭记忆得出的差别只能标为「未验证」，不能作为取舍依据。

1. **我的判断**：说明倾向及其成立前提。
2. **两个方向的差别**：只讲实际结果、代价和适用条件；证据不对称时直接说明。
3. **只需要你确认**：只问一个最上游的决策变量，只要求一个答案值。

不要把“是否 + 次数”“选择 + 原因”等两个问题合在一句。没有真正取舍时直接回答或执行，不为仪式制造问题。

## 继续与完成

用户回答后，必要时补做只读核验，然后继续原任务。回答只解决它直接回应的变量，不自动扩大为删除、提交、推送、部署、数据库写入或外部通知权限。

默认只输出结论、必要证据、不确定性和下一步，不展示固定的钢人模板。禁止使用无意义、纯装饰性的状语和补语；修饰语只在它改变事实、范围、条件、程度、时间、证据强度、行动含义或用户要求的语气与文体时保留。能直接确认且无需用户选择时，以已经回答或执行为完成；需要确认时，以问题保持原子且影响已说明清楚为完成。