用途：在任何创意或构建类工作（功能、组件、架构、行为变更等）开始前，把原始想法转化为清晰、经验证的设计与规格。技能激活期间不允许实现、写代码或修改行为，旨在防止过早实现、隐藏假设、方案错位和脆弱系统。
角色与模式：充当设计引导者与资深评审者，而非构建者；不做创意实现、不加推测性功能、不做无声假设、不跳过步骤，刻意放慢节奏以确保方向正确。
流程：
- 先了解当前上下文（强制首步）：回顾项目状态（文件、文档、计划、既往决策），区分已有与拟新增内容，记录隐含但未确认的约束，此时不设计。
- 理解想法：每条消息只问一个问题，优先多选，必要时才开放式提问，必要时拆分问题；聚焦目的、目标用户、约束、成功标准和明确的非目标。
- 非功能需求（强制）：明确或提出假设，涵盖性能、规模（用户/数据/流量）、安全与隐私、可靠性/可用性、维护与归属；用户不确定时给出合理默认值并标注为假设。
- 理解锁定（硬性关口）：提出设计前必须暂停，给出5–7条理解摘要（做什么、为何存在、给谁用、关键约束、明确非目标、假设），列出全部假设与待解决问题，然后询问“这是否准确反映您的意图？请确认或纠正后再进入设计”，未获明确确认不得继续。
- 探索设计方案：提出2–3个可行方案，先给出推荐项，说明复杂度、可扩展性、风险、维护等权衡，严格遵循 YAGNI，避免过早优化。
- 增量呈现设计：每段200–300词，每段后询问“目前看起来对吗？”，按需覆盖架构、组件、数据流、错误处理、边界情况、测试策略。
- 决策日志（强制）：全程维护，记录每项决策的内容、考虑过的替代方案与选择理由，并保留用于文档。
设计之后：设计验证完成后，将最终设计写入持久、可共享的格式（如 Markdown），包含理解摘要、假设、决策日志与最终设计，并按项目标准工作流存放。实现交接为可选：仅在文档完成后询问“准备开始实现了吗？”，确认后创建明确的实现计划、隔离工作、增量推进。
退出条件（硬性停止）：理解锁定已确认、至少一个设计方案被明确接受、主要假设已记录、关键风险已确认、决策日志完整；任一未满足则继续细化，不得进入实现。
核心原则：一次只问一个问题、假设必须显式、探索替代方案、增量验证、清晰优先于取巧、愿意回头澄清、严格 YAGNI。若设计影响大、风险高或需要更高信心，必须在实现前把最终设计与决策日志交接给 multi-agent-brainstorming 技能。
限制：资料未提供具体命令、安装方式、平台支持、收费或价格信息。