用途：在任何创造性工作（创建功能、构建组件、添加功能或修改行为）前，先把想法头脑风暴成成型的设计与规范，避免未经审视的假设造成浪费。项目不论简单与否都要经过此流程，设计可以很短但必须展示并获批。
主要能力：探索项目上下文（文件、文档、近期提交）；提出澄清问题（一次一个，聚焦目的、约束、成功标准）；提出 2-3 种方案及权衡与建议；按复杂度分节展示设计并逐节获批；覆盖架构、组件、数据流、错误处理、测试；写入设计文档并提交 git；规范自审（占位符、内部一致性、范围、歧义检查）；用户审阅门禁。
使用方式：按检查清单顺序执行，并为每项创建任务。当预计问题涉及视觉内容（模型稿、布局、图表）时，需以独立消息先提供基于浏览器的 Visual Companion 并征得同意，之后逐问题判断用浏览器还是终端。设计文档默认保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md，用户偏好可覆盖该路径。若可用，使用 elements-of-style:writing-clearly-and-concisely skill，并将文档提交到 git。规范审阅通过后，请用户审阅；获批后才过渡到实现。
适用场景：新功能、组件、配置变更、单功能工具乃至待办清单等各类开发前设计；在现有代码库中需先探索当前结构、遵循既有模式，并可纳入与当前目标相关的针对性改进，但不做无关重构。若请求包含多个独立子系统，应先帮助拆分为子项目，各自走规范、计划、实现周期。
限制：一次只问一个问题，避免多问题堆叠；严格 YAGNI，移除不必要功能；终止状态是调用 writing-plans skill，不应调用 frontend-design、mcp-builder 等实现类技能。Visual Companion 功能较新，可能消耗较多 token，需打开本地 URL；用户拒绝时改用纯文本继续。
资料未提供：具体安装命令、收费与定价、平台范围、效果数据等信息暂未提供。