用途
该技能是一套协作式设计方法论，用于在投入研究或规划之前，先把模糊的想法梳理清楚。它强调不要从含糊概念直接跳到实现，而是通过结构化探索来细化概念、暴露约束、评估方案。
使用时机
适用：需求模糊或不完整；存在多种可行方案；问题领域陌生；需要明确讨论取舍；需要做创意设计决策。
不适用：需求清晰具体；方案显而易见；已知原因的错误修复；例行维护。
三个阶段
第一阶段：理解想法。目标是澄清用户想达成什么。通过 AskUserQuestion 逐次提问：要解决什么问题（底层需求而非提出的方案）、为什么重要、面向谁（终端用户、开发者或运维）、他们需要什么、成功标准是什么、有哪些约束（技术限制、时间、兼容性）、已经考虑过哪些想法或要避免的方案。尽量使用多选题，开放式问题适合探索。
第二阶段：探索方案。在理解想法后，给出 2 到 3 个方案，每个方案附名称、2 至 3 句说明、优点、缺点、最佳适用情况，并给出基于已述约束的推荐。随后通过 AskUserQuestion 获取偏好，选项包括推荐方案、其他方案、继续探索、都不合适（需补充需求）。
第三阶段：设计文档。选定方案后，按每段 200 至 300 字分段呈现设计，每段确认后再继续，并根据反馈调整。最终保存到 docs/plans/YYYY-MM-DD-<topic>-design.md。文档结构包括：问题陈述、选定方案及理由、设计细节、接受的取舍、未解决问题、下一步（研究、规划、实现）。
提问技巧
漏斗式提问：先宽后窄，如先问要构建什么，再问哪些用户会使用，最后问最重要的交互。显性化假设：把隐含假设说出来请对方确认。取舍提问：当多个选择都成立时，说明各自简单与灵活的权衡。举例澄清：需求模糊时请用户给出具体场景示例。
YAGNI 原则
严格应用 YAGNI（你不需要它）：拒绝“以后可能用”的功能，质疑每个“锦上添花”，聚焦最小可行方案。复杂度可以后加，但移除很难。
与 RPI 工作流的衔接
头脑风暴是可选的前置阶段：头脑风暴 → 研究 → 规划 → 实现。当需求不清晰时才需要。产出的设计文档会输入到研究或规划阶段。设计完成并确认后，可转到 /rpikit:researching-codebase 研究代码库、/rpikit:writing-plans 编写实现计划，或继续头脑风暴；若还需调查，则建议先进入研究阶段。
反模式
直接跳到方案（应先问问题与用户）；分析瘫痪（应限时探索并做决定）；镀金（应 YAGNI 最小可行）；忽视约束（应尽早暴露约束并在其中设计）；独白式设计（应分段呈现并设检查点）。
继续前的检查清单
问题陈述清晰、成功标准已定义、约束已识别、已考虑多个方案、已讨论取舍、严格应用 YAGNI、设计已记录（如进入规划）、下一阶段已确定。