用途：在任何创意工作（新增功能、构建组件、添加能力、修改行为）之前使用，把想法转化为成型的设计与规格。核心是先分类请求所需流程，再按路径推进，且每一步实现前都必须获得用户批准。
三条路径：spike（可行性问题，输出是答案而非保留的代码，用两三句话说明问题与尝试方案，获批后以最低成本验证，结果作为建议汇报，产出物标注为一次性）；bounded（对仓库中已存在流程的小范围改动，如新标志、小接口、单文件修复，需问关键澄清问题，在聊天中给出简短设计后停止，得到明确同意再按常规开发流程实现，不写规格与计划文档）；architectural（新项目、新子系统、重构组件关系或改动他人依赖的接口，走完整流程：探索上下文、逐个提问、提出 2-3 个方案与权衡、分段呈现设计逐段获批、编写设计文档、自查、用户审阅规格、再调用 writing-plans 技能）。
选择规则：两路径之间存疑时取较重者；路径只能升级不能降级，任务中途发现隐藏复杂度需停下说明并升级。每种路径在实现前都必须先呈现意图并获批，简单任务只是设计更短，而非免除批准。
主要能力：探索项目上下文（文件、文档、近期提交）；评估范围，若涉及多个独立子系统则先帮助拆分为子项目，再逐一走设计流程；一次只问一个问题，关注目的、约束与成功标准；提出 2-3 种方案并给出推荐与理由；按复杂度分段呈现设计，覆盖架构、组件、数据流、错误处理与测试；强调隔离与清晰，将系统拆成单一职责、接口明确、可独立理解和测试的单元。
architectural 路径产出：把验证过的设计写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交 git；随后做规格自查（占位符、前后矛盾、范围、歧义），修正后请用户审阅，获批再调用 writing-plans 生成实现计划——该路径之后只调用 writing-plans。
视觉伴侣：按需提供，不提前开启；当某问题用图示比文字更清楚时，以单独一条消息提出，用户接受后以 --open 启动浏览器标签页，且每个问题单独判断用浏览器还是终端。
限制：不支持中途降级；不要提议无关重构；spike 产出物不得直接保留；未获批准不得开始实现。其他细节（如具体收费、适用平台）资料未提供。