名称： ask-questions-if-underspecified
描述： 在实施前澄清需求。仅在明确调用时使用，不要自动使用。

需求不明确时主动提问

目标

提出最少量的澄清问题以避免错误工作；在必须回答的问题得到解决（或用户明确批准基于既定假设继续）之前，不要开始实施。

工作流程

1) 判断需求是否不明确

如果在探索如何执行工作时，发现以下部分或全部内容不清晰，则视为需求不明确：
- 明确目标（什么应该改变，什么保持不变）
- 明确“完成”标准（验收标准、示例、边界情况）
- 明确范围（哪些文件/组件/用户包含在内/排除在外）
- 明确约束（兼容性、性能、风格、依赖、时间）
- 明确环境（语言/运行时版本、操作系统、构建/测试运行器）
- 澄清安全性/可逆性（数据迁移、发布/回滚、风险）

如果存在多种合理的解释，则假定其为不明确。

2) 优先提出必须回答的问题（保持精简）

第一轮提出 1-5 个问题。优先选择能排除整个工作分支的问题。

使问题易于回答：
- 优化可读性（简短、编号的问题；避免段落）
- 尽可能提供多项选择
- 在适当时建议合理的默认值（明确标记为默认/推荐选择；在列表中加粗推荐项，或在代码块中呈现选项时，在块上方加粗“推荐”行，并在块内标记默认值）
- 包含快速路径回复（例如，回复 defaults 以接受所有推荐/默认选择）
- 在有用时包含低门槛的“不确定”选项（例如，“不确定 - 使用默认值”）
- 将“必须知道”与“最好知道”分开，以减少阻力
- 构建选项，使用户能够以紧凑的决策回复（例如，1b 2a 3c）；用通俗语言复述所选选项以确认

3) 行动前暂停

在获得必须的答案之前：
- 不要运行命令、编辑文件或制定依赖于未知因素的详细计划
- 仅当不会使你承诺某个方向时，可以执行一个明确标记的低风险探索步骤（例如，检查仓库结构，读取相关配置文件）

如果用户明确要求你在没有答案的情况下继续：
- 将你的假设陈述为一个简短的编号列表
- 请求确认；只有在他们确认或纠正后才继续

4) 确认理解，然后继续

一旦获得答案，用 1-3 句话复述需求（包括关键约束和成功标准），然后开始工作。

问题模板

• “在开始之前，我需要知道：(1) ..., (2) ..., (3) .... 如果你不关心 (2)，我将假设 ....”
• “应该是以下哪一种？A) ... B) ... C) ... （选择一个）”
• “你认为什么算‘完成’？例如：...”
• “有任何我必须遵循的约束吗（版本、性能、风格、依赖）？如果没有，我将以现有项目默认值为目标。”
• 使用带字母选项的编号问题和清晰的回复格式

推荐

1) 范围？
   a) 最小改动（默认）
   b) 在接触该区域时进行重构
   c) 不确定 - 使用默认值

2) 兼容性目标？
   a) 当前项目默认值（默认）
   b) 同时支持旧版本：<指定>
   c) 不确定 - 使用默认值

回复格式：defaults （或 1a 2a）

反模式

• 不要问那些可以通过快速、低风险的探索性阅读（例如，配置文件、现有模式、文档）来回答的问题。
• 如果紧凑的多项选择或是否问题能更快消除歧义，就不要问开放式问题。

致谢

改编自 Tibo 的帖子 (@thsottiaux)：https://x.com/thsottiaux/status/2006624792531923266