kscz0000 需求不明确时先提问
何时使用
当请求存在多种合理解读，或关键细节（目标、范围、约束、环境或安全）不清晰时，使用此技能。
何时不使用
当请求已经清晰，或通过快速、低风险的探索性阅读就能回答缺失细节时，不要使用此技能。
目标
提出避免错误工作所需的最小澄清问题集；在必须回答的问题得到解答之前（或用户明确批准按声明的假设继续），不要开始实现。
工作流程
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）
反模式
- 不要问通过快速、低风险的探索性阅读就能回答的问题（例如，配置、现有模式、文档）。
- 如果紧凑的多选或是非题能更快消除歧义，不要问开放式问题。
局限性
- 仅当任务明确符合上述范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少必需的输入、权限、安全边界或成功标准，停下来请求澄清。