用途：当请求信息不足、存在多种合理解读，或用户希望先澄清再实现时，使用该技能在动手前提出最少量的必要问题，避免返工。
触发规则：仅在用户明确调用该技能，或明确要求在实现前澄清时使用；当关键需求模糊到有实现错误风险时使用；若请求已具体、可测试且可直接执行，则不要使用。
工作流： 1）判断请求是否欠明确。若目标（变与不变）、完成标准（验收标准、示例、边界情况）、范围（涉及/不涉及的文件、组件、用户）、约束（兼容性、性能、风格、依赖、时间）、环境（语言/运行时版本、操作系统、构建/测试运行器）、安全与可逆性（数据迁移、发布/回滚、风险）中有任何一项不清，即视为欠明确；存在多种合理解读时同样视为欠明确。 2）先问必答问题，保持精简。首轮问 1-5 个问题，优先选择能排除整条工作分支的问题。让问题易于回答：可快速扫读（简短编号问题，避免长段落）、尽量给出多选选项；若有 request_user_input，优先用于 1-3 个简短结构化问题与紧凑选项，需要更丰富自由输入或超过 3 个问题时回退到普通对话；适当给出合理默认值并清楚标注（推荐项加粗，或在代码块上方加粗注明 Recommended 并在块内标注默认值）；提供快速通道回复（如回复默认值即接受全部推荐项）；必要时提供低门槛的“不确定”选项（如“不确定-使用默认”）；可将“必须知道”与“最好知道”分开；选项结构应支持紧凑决定（如 1b 2a 3c），随后用平实语言复述确认所选项。 3）行动前暂停。在必答问题得到答复前：不要运行命令、编辑文件或产出依赖未知项的详细计划；仅在不会锁定方向时，才可执行明确标注的低风险探查步骤（如查看仓库结构、读取相关配置文件）。若用户明确要求无答案继续：以简短编号列表陈述假设，请求确认，确认或更正后再继续。 4）确认理解后开始。拿到答案后，用 1-3 句话复述需求（含关键约束与成功标准），再开始工作。
问题模板示例：“开始前我需要：(1)…(2)…(3)…。若你不关心 (2)，我将假设…。”；“应该是哪一个？A)… B)… C)…（选一个）”；“你认为怎样算‘完成’？例如：…”；“有什么必须遵守的约束（版本、性能、风格、依赖）？若没有，我将以现有项目默认为准。”
反模式：不要问通过一次低风险查阅（配置、既有模式、文档）就能回答的问题；若有紧凑多选或是否题能更快消除歧义，就不要用开放式问题。