用途：该技能用于在“收集初步设计上下文”之后、开始头脑风暴之前，弥合原始用户输入与结构化设计之间的差距，确保理解的是用户真正想表达的意思，而不是字面说法。核心原则是先解决矛盾，再消除歧义——冲突目标必须先协调，否则会在错误的目标上做精确澄清。开始时需声明：“I'm using the asking-clarifying-questions skill to make sure I understand your requirements correctly.”
澄清内容：先扫描需求中的逻辑矛盾（显式矛盾、不可能组合、未承认的取舍），用“我注意到你提到 X 和 Y，它们可能方向不同，哪个优先”的方式点明张力；然后消除技术术语歧义（如 OAuth2 具体流程、数据库类型、缓存层级）、明确范围边界（用户是谁、集成的哪些部分、报告范围）、核实假设与约束（为什么必须用某库、“快”具体指多少、遵循某模式指哪个方面），以及核对版本与 API 细节（如 Stripe API 版本与功能、React Router 版本）。澄清前应尽量从工作目录上下文自行解答，可派发 codebase-investigator、combined-researcher 等子代理，但不允许嵌套子代理。
使用方式：有 2-4 个带取舍的选项时使用 AskUserQuestion 呈现具体选项；理解“为什么”时使用开放式问题；核实事实时做快速查询，不做深度研究。最后必须确立“完成定义”：推断完成后会存在什么、用户或系统能做什么、具体交付物是什么，用 AskUserQuestion 向用户确认（选项为“对”“部分对但……”“不对，我来说明”）；若交付物仍模糊，则追问“完成后应存在什么”“如何知道成功”“最小可行交付物是什么”。
输出与停止：澄清后输出上下文包，包含已解决的取舍、澄清后的需求、已验证的假设、范围边界（IN/OUT），作为头脑风暴的输入，并出现在最终设计文档顶部。当矛盾已解决、术语已消除歧义、范围明确、约束被理解、假设已验证、无重大歧义时，即可停止并进入头脑风暴；若头脑风暴中出现新歧义，可返回澄清。不适用于探索设计方案、提出架构、验证已完成设计或收集初始需求。适用场景为设计流程中“上下文收集”与“头脑风暴”之间的环节。限制：资料未说明该技能的具体运行平台、安装命令、依赖、收费或价格信息，暂未提供。