用途
该技能旨在任何创意工作开始前，先弄清楚用户真正想要什么以及背后的原因。它适用于创建功能、构建组件、添加功能、修改行为或规划新项目等场景。技能强调，你虽然擅长构建，但对用户意图的理解往往比感觉上更薄弱，因此需要先通过对话挖掘需求。
主要能力
- 判断任务复杂度：先自问对用户想要什么及为什么知道多少；若请求本身已足够清晰（如“把图标改成矢车菊蓝”），则直接执行并说明；若缺少非平凡信息，则启动对话。
- 结构化对话：首条消息包含两部分——一行告知用户可跳过提问直接开始；一个开放式问题，引导用户描述真实场景或具体画面。后续每条消息只以一个单句问题结尾，使用平实语言，匹配用户词汇，避免流程术语。
- 覆盖关键领域：包括项目类型与特殊之处、为何现在做、成功标准、目标/非目标/反目标、先前作品、当前状态、在意的细节。问题锚定具体经历，如“带我走一遍上次……”“如果只能做好其中一个，选哪个？”“如果我做错了什么会让你皱眉？”
- 回放与确认：当理解某部分足够描述时，用约200-300字回放该部分（用途、服务对象、某部分行为等），然后继续询问下一部分。回放与提问交替进行，最后覆盖剩余内容。猜测标记为猜测，用户原话标记为用户所述。每段回放后询问哪里不对或缺失。
- 提供侦察选项：在有一定基础且查看有帮助时，主动提出查看代码库、项目文件、数据或网络，说明会找什么，由用户决定是否进行。
- 私下广泛思考：提出方案前先构思多个想法并淘汰弱项，包括与用户所述原因冲突的想法；仅在有助于决策时展示比较。
- 可视化伴侣：当视觉呈现比阅读更有效时（如屏幕、页面、打印件、布局、流程、选项对比、结构图），适时提供浏览器标签页展示模型、图表和原型。该提议单独成消息，不与其他内容混合。用户拒绝则不再主动提供。
- 快速原型：当有助于了解需求或验证可行性时，提议做一次性快速构建；若用户只想快速原型，则让路。快速原型不写测试或只写极少测试，不保证健壮，跳过计划、实现和审查流程，但需将所学带回对话。
- 评估工作规模：理解需求后，用平实语言说明规模（快速清晰任务→直接做；小改动→在聊天中描述并通过常规流程构建；有书面设计的项目→撰写设计文档并制定完整计划），用户可覆盖。任务中途扩大则停止并升级规模。若实为多个独立项目，说明并商定顺序，逐个头脑风暴。
- 撰写书面设计：针对项目，撰写一份平实文档，使该领域有能力的构建者无需再问用户即可规划。内容包括意图与原因、目标/非目标/反目标、约束、用户已决定的部分、留给构建者的部分。软件项目中存放于
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md并提交；其他情况询问用户偏好。 - 构建者检查：派遣新的子代理使用本目录下
builder-check-prompt.md进行检查。告知用户将有审查者先阅读文档，可能带回少量问题。将构建者问题分为三类：对话或项目已回答的（写入文档）、次要的（自行决定并标注为你的决定）、必须用户回答的（一次性按重要性排序带回）。更新文档后交付，并附上你所做决定的简短列表。检查只产生一轮问题。无子代理工具时，自行以构建者视角阅读文档。 - 例外情况：若用户选择跳过提问，技能结束，检查环节一并跳过；用户同意的快速原型可构建，但保持“一次性”标签，保留其产出属于新请求，需重新经过本技能。项目文档批准后，软件项目下一步调用
superpowers:writing-plans，不调用其他技能。
使用方式
在开始任何创意工作前调用本技能。按照上述流程：判断复杂度→首条消息→对话→回放→规模评估→（项目）书面设计与构建者检查。可视化伴侣需在适当时机单独提议，用户接受后阅读本目录下 visual-companion.md 再启动服务器。
适用场景
- 创建新功能、构建组件、添加功能、修改行为。
- 规划新项目或较大改动。
- 用户需求尚不清晰、需要帮助梳理思路时。
- 需要书面设计文档以确保构建者能独立实施的软件项目。
限制
- 不适用于已足够清晰、可直接执行的快速任务。
- 用户可随时选择跳过提问，此时技能结束。
- 快速原型不写测试或只写极少测试，不保证健壮，且保留其产出需重新走流程。
- 书面设计文档的存放位置在非软件项目中需询问用户；用户偏好优先。
- 构建者检查仅产生一轮问题，且无子代理工具时需自行模拟构建者阅读。
- 可视化伴侣需用户接受后才可使用，拒绝后不再主动提供。