用途：在任何创作性工作（做功能、搭组件、加功能、改行为或规划新事物）之前使用，先弄清用户真正想要什么、为什么想要，避免基于想当然的假设直接开工。
主要能力：先判断请求是否已足够明确——若信息完整就直接执行并说明；若缺少关键信息则开启对话。首条消息包含两部分：一行提示用户可跳过提问直接开始，以及一个开放式问题，引导对方描述真实场景或具体画面。后续每条消息只以一个问句结尾，用平实语言、贴近对方词汇，先让对方用自己的话描述，卡住时才给简短选项。需要时提议查看代码库、文件数据或网络资料，由用户决定是否查看。
可视化辅助：当“看”比“读”更有效时（界面、布局、流程、可对比选项、图示时间线等），单独发一条消息提议打开浏览器标签展示原型、图示或可点击的临时原型；被拒绝则继续用文字，不再重复提议。
复述与规模：理解一部分后就用约200-300字复述该部分，再继续问下一部分，复述与提问交替进行；猜测内容标注为猜测，用户所述标注为用户所述，每段结尾询问哪里不对或缺失。理解清楚后确定任务规模：快速明确任务直接做；小改动在对话中走常规流程；需要书面设计的项目则写设计文档，软件项目放在 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交。
设计文档与检查：文档需覆盖意图与原因、目标、非目标、反目标、约束、用户已决定的做法以及留给构建者的部分。写完后用 builder-check-prompt.md 派发新子代理做构建者检查，把问题分为已答、次要（自行决定并标注）、需用户回答三类，只把第三类一次性提出。文档获批后，软件项目下一步调用 superpowers:writing-plans。
限制：若用户选择跳过提问，本技能即结束；临时原型（spike）不写测试、不做完整计划与评审，保留其成果需作为新请求重新走流程。未提供具体平台、收费或价格信息。