用途：在任何创造性工作开始前，通过自然协作对话把想法变成完整的设计与规格。要求在每个项目上都执行该流程，包括待办清单、单函数工具、配置修改等“简单”项目，因为未检验的假设最容易造成返工。
主要流程：先探索项目上下文（文件、文档、近期提交）；评估范围，若请求包含多个独立子系统，先提示并帮助拆解为子项目，再逐个走 spec→plan→实现循环；随后逐个提问澄清目的、约束与成功标准，每条消息只问一个问题，优先多选；接着提出 2-3 种带取舍的方案并给出推荐；再按复杂度分段呈现设计（涵盖架构、组件、数据流、错误处理、测试），每段后确认；获批后写设计文档。
产物与后续：设计文档保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交 git（用户偏好可覆盖路径）；随后做规格自检，排查占位符、矛盾、歧义与范围问题并就地修正；再请用户审阅规格，通过后调用 writing-plans 技能生成实现计划。终态只调用 writing-plans，不得调用 frontend-design、mcp-builder 等其它实现技能。
视觉伴生：仅在有真正需要图示的问题时按需提供，不作为默认模式；需单独一条消息提出，用户接受后以 --open 启动服务。每个问题单独判断用浏览器还是终端：布局、线框、架构图等视觉内容用浏览器，需求、概念选择、取舍列表用终端。
在既有代码库中：先探索现有结构与模式，遵循既有约定；仅对影响当前工作的代码问题做针对性改进，不做无关重构。
限制：视觉伴生属于新功能且可能消耗较多 token；是否可用的具体环境与安装方式暂未提供。规范位置、分支等细节以用户偏好为准，资料未提及其他收费或平台信息。