用途
在开始任何创造性工作（创建功能、构建组件、添加功能、修改行为）之前，通过协作对话把想法转化为完整的设计和规格说明，避免在未经验证的假设上直接写实现。
主要能力
- 探索项目上下文：查看文件、文档和最近提交记录。
- 范围评估：当请求包含多个独立子系统时，先提示用户将项目拆分为子项目，每个子项目各自走「规格 → 计划 → 实现」流程。
- 逐个提问澄清：每次只问一个问题，尽量用选择题，聚焦目的、约束与成功标准；仅在问题彼此独立时可将最多4个选择题合并调用 AskUserQuestion。
- 提出2-3种方案：说明各自取舍并给出推荐及理由。
- 分节呈现设计：架构、组件、数据流、错误处理、测试，按复杂度控制篇幅（几句话到200-300字），每节后请用户确认。
- 边讨论边保存草稿：一旦有实际决定就创建带「Status: DRAFT」头的规格文件，随时追加已确定的决策，避免会话中断丢失。
- 设计原则：把系统拆成职责单一、接口清晰、可独立理解与测试的小单元。
- 在现有代码库中：先探索并遵循现有模式，把与当前工作相关的针对性改进纳入设计，不做无关重构。
使用方式（清单顺序）
- 探索项目上下文。
- 如涉及视觉问题，单独发消息提供可视化伴侣（Visual Companion），等待回应。
- 逐个提问澄清。
- 创建草稿规格并持续追加决策。
- 提出2-3种方案。
- 分节呈现设计并逐节获得确认。
- 将草稿转为正式规格文档（去掉 Draft 头）。
- 规格自审：检查占位符、内部一致性、范围、歧义，并就地修正。
- 请用户审阅规格文件。
- 调用 writing-plans 技能生成实现计划。
规格文档
- 新项目默认保存到 docs/rubypowers/specs/；若已有 docs/superpowers/specs/ 则沿用该处，全程不拆分到两个位置。
- 正式文件命名为 YYYY-MM-DD-<topic>-design.md，并提交到 git。
- 规格必须包含 ## Decisions 部分：逐条记录用户的明确决策及一句话理由。
- 用户偏好若指定了规格位置，优先于默认值。
适用场景
任何需要先设计再实现的创意性开发工作，包括看似简单的待办清单、单函数工具或配置改动——简单项目恰恰最容易因未检验的假设浪费工作。
限制与不适用场景
- 调试或修复回归问题：应使用 rubypowers:systematic-debugging；若修复改变了预期行为，再回到本技能。
- 执行已批准的计划：使用 executing-plans 或 subagent-driven-development。
- 纯研究或提问、后面没有实现工作：没有可设计的内容。
- 终态只能调用 writing-plans，不应调用 frontend-design、mcp-builder 等其他实现类技能。
- 不得以「用户已明确需求」「用户让跳过设计」「聊天中已同意」为由绕过规格文件、提交与用户审阅等环节；可将流程压缩到最短，但不可跳过。
可视化伴侣
可选的浏览器端伴侣，用于展示线框图、图表和视觉方案。它是工具而非模式，接受后也只对确实「看到更好理解」的问题使用浏览器，文本类问题仍在终端进行。该功能较新且可能消耗较多 token，需打开本地 URL。