用途：当请求存在多种合理解释，或目标、范围、约束、环境、安全等关键细节不清时，先澄清需求再实施，防止基于错误假设做无用功。请求已明确，或通过一次低风险的信息查看即可补齐细节时，不应使用本技能。
主要能力：判定请求是否描述不足，判断维度包括目标（哪些变、哪些不变）、完成标准（验收条件、示例、边界情况）、范围（涉及与不涉及的模块、组件、用户）、约束（兼容性、性能、风格、依赖、时间）、环境（语言与运行时版本、操作系统、构建与测试运行器）、安全与可逆性（数据迁移、上线与回滚、风险）。
使用方式：第一轮只问 1 至 5 个必答问题，优先选择能消除整条工作分支的问题。问题要短、编号清晰、便于扫读，尽量提供多选项、合理默认值并明确标注推荐项，提供快速回复路径（如回复 defaults 即接受全部推荐）和低摩擦的“不确定—用默认”选项，必要时区分“必须知道”与“最好知道”。可采用 1b 2a 3c 这种紧凑作答格式，再用自然语言复述确认。得到必答回复前，不要运行命令、编辑文件或给出依赖未知项的具体计划；仅可做明确标注且不锁定方向的低风险查看，如浏览仓库结构、读取相关配置。若用户要求不回答直接推进，应先用编号列出假设并请求确认。拿到答复后用 1 至 3 句话复述需求与成功标准，再开始工作。
适用场景：功能开发类请求（如“给应用加认证”）、缺陷修复类请求（如“修复慢的 API 接口”）、重构类请求（如“重构用户服务”）等存在多种解释的任务。也可在 systems-decompose、code-review、api-design、database-schema 等技能之前使用。
限制与注意事项：不要问一次低风险查看就能回答的问题（如配置、既有模式、文档）；不要用开放式提问替代更快的多选或是否题；不要堆砌大量问题，应区分必答与可选；若假设可能导致大量返工，不要在未澄清时直接推进。本技能基于 Trail of Bits Skills 的 ask-questions-if-underspecified，许可为 CC-BY-SA-4.0。