| name | superpowers-brainstorming |
| description | Use before any creative work - creating features, building components, adding functionality, or modifying behavior - guides through exploration, questioning, design proposal, and spec documentation before any implementation |
Superpowers Brainstorming - 想法到设计
核心准则
在创造性工作之前，通过协作对话将想法转化为完整的设计和规格说明。
触发条件： 创建功能、构建组件、添加功能、修改行为。
硬性门槛
在调用任何实现技能、写任何代码、搭建任何项目、或采取任何实现动作之前，
必须先展示设计并获得主人批准。
无论感知到的复杂度如何，每个项目都要走这个流程。
"简单"项目正是未审视假设造成最多浪费的地方。设计可以很短（真正简单的项目几句话就够），但必须展示并获得批准。
"继续思考" / "did you consider X" 信号 — 重新进入探索模式
当主人说"继续思考"、"再想想"、"你考虑过 X 吗"、"你漏了 Y"——这不是轻量确认，而是显式信号：你之前的探索不完整，需要回到本技能流程的早期阶段重做。常见触发：
| 主人原话 | 缺失的探索环节 | 重新执行 |
|---|
| "继续思考" / "再想想" | 问题空间、约束、方案对比 | 从 Step 1（探索项目上下文）重做 |
| "你漏了 X" / "考虑一下 X" | 现有文件/脚本/资源审计 | 重新 Step 1，重点 ls scripts/ git log --since 查近期并行提交 |
| "你选错方案了" | 方案对比不充分 | 重新 Step 4（2-3 方案） |
| "实际更复杂" / "还有个 case" | 边界 case / 失败模式没列 | 重新 Step 5（设计中的错误处理） |
| "你误解了我的意图" | 目的 / 成功标准没问清 | 重新 Step 3（澄清问题） |
反模式： 主人说"继续思考"后只追加一段"还有几个我刚才没想到的维度"而不重新走流程。这种"补丁式深化"看起来在响应，但跳过了重新设计、重新获得批准两步，会产出和已有部分不一致的实现。
正确响应： 承认探索不完整 → 列出缺失的具体探索点 → 重新走 Step 1-5 → 给出新的设计方案让主人重新批准 → 然后才实施。
真实案例 (2026-06-10 Zhihu 反爬 session)： 第一轮只 patch 了 zhihu-and-cnsite-fetcher.md（Layer 7: iPhone UA + Profile）。主人说"继续思考"。重新审计发现：(1) 现有 fetch-with-profile.js 的选择器根本不含 .Post-RichText，知乎 mobile UA 下会 fallback 到 document.body.innerText 把整页 dump 出来；(2) 同一 worktree 里上一轮 session 还创建了 fetch-zhihu-stealth.py（Layer 8: headless + init_script 6 patches），SKILL.md 也已被外部修改引用它——这两条平行突破路径我第一轮完全没发现。补完后的设计（Variant A / Variant B 双路径对比表）远比第一轮完整。
流程检查表
按顺序完成每个任务：
- 探索项目上下文 — 检查文件、文档、最近提交
- 提出视觉化同伴（如果主题涉及视觉问题）— 这是独立消息，不与澄清问题合并
- 提出澄清问题 — 一次一个，理解目的/约束/成功标准
- 提出 2-3 种方案 — 带有权衡和推荐
- 展示设计 — 按复杂度缩放各部分，在每个部分后获批准
- 写设计文档 — 保存到
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并 commit
- 规格自审 — 快速内联检查占位符、矛盾、模糊、范围
- 主人审查书面规格 — 在继续之前请主人审查规格文件
- 过渡到实现 — 调用
superpowers-writing-plans 技能创建实现计划
终点状态是调用 writing-plans。不要调用任何其他实现技能。
流程详解
理解想法
- 先检查当前项目状态（文件、文档、最近提交）
- 在问详细问题前，评估范围：如果请求描述多个独立子系统（如"构建有聊天、文件存储、计费、分析的平台"），立即标记。不要在需要先分解的项目上花时间细化细节。
- 对于适当范围的项目，一次问一个问题来细化想法
- 尽量用多选问题，但开放问题也可以
- 一次只问一个问题——如果主题需要更多探索，拆成多个问题
- 重点理解：目的、约束、成功标准
探索方案
- 提出 2-3 个不同方案，带权衡
- 用对话方式展示选项，说明推荐和原因
- 用推荐选项开头并解释为什么
展示设计
- 一旦相信理解了要构建什么，就展示设计
- 每个部分按复杂度缩放：直接的几句话，复杂的 200-300 字
- 每个部分后问"这样看起来对吗"
- 覆盖：架构、组件、数据流、错误处理、测试
- 如果有不明白的地方准备好回去澄清
为隔离和清晰而设计
- 将系统分成更小的单元，每个有明确目的，通过清晰接口通信，可以独立理解和测试
- 对于每个单元，应该能回答：它做什么，你怎么用它，它依赖什么？
- 有人能在不读内部代码的情况下理解它做什么吗？能改变内部代码而不破坏消费者吗？如果不能，边界需要改进
- 更小、边界好的单元你也更容易处理——你更容易推理能放在脑子里的代码，编辑时也更可靠。当一个文件变大，通常是它做太多事的信号
现有代码库中工作
- 在提出变更前先探索当前结构。遵循已有模式。
- 对于影响工作的现有代码问题（如长得太大的文件、边界不清、职责混乱），把针对性改进作为设计的一部分——好开发者在工作的代码中会做这些改进。
- 不要提无关的重构。聚焦于服务当前目标的内容。
设计之后
文档：
- 将经验证的设计（规格）写到
docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md
- Commit 设计文档到 git
规格自审：
写完规格文档后，用新眼光看：
- 占位符扫描： 有"TBD"、"TODO"、不完整部分或模糊需求吗？修复它们。
- 内部一致性： 各部分有矛盾吗？架构和功能描述匹配吗？
- 范围检查： 这个范围对于单一实现计划够聚焦吗？需要分解吗？
- 模糊检查： 任何需求能有两种解释吗？如果有，选一个并明确。
内联修复问题。不需要重新审查——修复并继续。
主人审查门槛：
规格审查循环通过后，在继续之前请主人审查书面规格：
"规格已写完并 commit 到 <path>。请审查，如果有要修改的告诉我，在我们开始写实现计划之前。"
等主人回复。如果请求变更，做修改并重新运行规格审查循环。只有在主人批准后才能继续。
实现：
- 调用
superpowers-writing-plans 技能创建详细实现计划
- 不要调用其他技能。writing-plans 是下一步。
关键原则
- 一次一个问题 — 不要用多个问题压垮
- 多选优先 — 比开放问题更容易回答
- YAGNI 彻底 — 从所有设计中移除不必要功能
- 探索替代方案 — 在确定之前总是提出 2-3 个方案
- 增量验证 — 展示设计，获得批准后再继续
- 灵活 — 有不明白的回去澄清
视觉化同伴（Canvas）
当预期接下来的问题涉及视觉内容时（模型、布局图、图表），提供 canvas 展示：
- 使用
canvas 工具展示模型、图表、选项对比等视觉内容
- 每个问题决定是否用浏览器： 用户看这个比读文字更好吗？
- 用 canvas： 内容本身是视觉的——模型、线框图、布局对比、架构图、并排视觉设计
- 用文字： 内容是文字的——需求问题、概念选择、权衡列表、A/B/C/D 文本选项、范围决策
关于 UI 主题的问题不自动是视觉问题。"在这个语境中个性意味着什么？"是概念问题——用文字。"哪种向导布局更好？"是视觉问题——用 canvas。
执行检查表
每次开始创意工作前，确认：
