用途：在动手前先弄清用户真正需要什么。资料称受控研究中模型在信息缺失时约 70% 会直接假设而提问，clarify 作为计划流水线的澄清环节，用来抵消这种默认执行偏差。
主要能力：把不清楚之处分类为意图类（真实目标不可恢复，如“让它更好”）、前提类（请求中的假设有误，如修复并不存在的竞态）、参数类（缺少或冲突的细节，如“建个登录页”未说明认证方式）、表达类（指代、词义、范围歧义）。并按歧义方向选择动作：语义歧义去消歧，范围过宽去收敛到最要紧的部分，范围过窄则泛化到更广的目标。对编码任务，特别关注缺失目标、缺失前提（排序、错误处理、边界情况）和术语含糊，并显式检查需求间的矛盾。
使用方式：先想“有哪些合理解释”，再找能排除最多解释的问题。生成 2–4 个竞争性解释，找出区分它们的轴，就这条轴提问；选择信息增益最大的问题，目标 3–5 轮内收敛。尽量用具体的行为差异示例代替抽象提问，如“若你指 X，输入 Z 会这样；若指 Y 则那样”。针对不同故障类型可分别采用请求参数、消歧、提出替代方案、确认风险、报告障碍等策略。问题应聚焦单一缺口、可回答、有区分度、非诱导、与任务相关。按用户付出的成本区分：意图、目标、约束类问题可直接问；实现细节（如上游服务超时返回什么）应自行查代码，不要问用户。
适用场景：需求含糊、信息不足、前提可能有误，或处于高风险不可逆操作前的确认。
限制：若关键信息齐全且没有竞争性假设，直接推进；提问与不提问效果相同时偏向行动；用户说“随便怎么做都行”时切换到确认模式，声明假设而非沉默。每轮问题上限 1–3 个，避免审问式连环提问。资料提及 ${CLAUDE_PLUGIN_ROOT}/references/adaptive-questioning.md 为共享参考，涉及模式切换协议。具体价格、收费与平台支持情况暂未提供。