brainstorming

name	brainstorming
description	在进行任何创意性工作之前必须使用此技能 — 创建功能、构建组件、添加功能、实现需求或修改行为。在实现前探索用户意图、需求和设计。用户说"头脑风暴"或类似的表达时，应触发此技能。

把想法转化为设计

通过自然的协作对话，把想法转化成完整成型的设计与 spec。

先理解当前项目上下文，然后一次问一个问题逐步打磨想法。一旦弄清楚要构建什么，就把设计提出来并获得用户批准。

在你把设计提出来并获得用户批准之前，禁止调用任何实现类 skill、写任何代码、搭任何项目骨架或采取任何实现动作。该规则对**每一个**项目都适用，无论看起来多简单。

工作流

你必须使用 TodoWrite 为下列每一项创建一个 Todo ，并按顺序完成：

1. 探索项目上下文
2. 提出澄清式问题
3. 提出 2-3 个方案
4. 呈现设计
5. 写设计文档
6. Spec 审查
7. 用户审阅已写好的 spec
8. 评估并询问是否使用 SubAgent 并行开发

1. 探索项目上下文

必须通过 SubAgent 执行代码库调查，主 Agent 自身禁止直接 Glob/Grep/Read 大批文件做摸底。SubAgent 返回结构化结论后，由主 Agent 汇总。

• 先了解当前项目状态（文件、文档、近期 commit）：用 Agent 工具（优先 subagent_type=Explore，需要跨模块综合分析时用 general-purpose）让子代理去翻文件、读文档、看 git log，并要求其返回："相关文件路径 + 关键片段摘录 + 现有模式/约定总结"。主 Agent 不在主上下文直接做大范围 Glob/Grep/Read，只接收 SubAgent 的结构化结论用于后续提问与设计。
• 提出修改前先探索现有结构，遵循既有模式。同样的硬性规定：现有代码库的结构调研一律派发 SubAgent，主 Agent 不亲自做大范围检索；只在 SubAgent 返回结果后做点对点的针对性 Read（如确认单个函数签名）。

2. 提出澄清式问题

一次一个，理解目的 / 约束 / 成功标准。

• 在开始提细节问题之前，先评估范围：如果用户描述的是多个独立子系统（例如"构建一个含聊天、文件存储、计费和数据分析的平台"），立即指出来。不要把问题花在一个其实需要先拆解的项目细节上。
• 如果项目对单份 spec 来说过大，帮用户拆分成子项目：哪些是相互独立的部分？它们如何关联？应该按什么顺序构建？然后按常规设计流程对第一个子项目做 brainstorming。每个子项目都有自己独立的 spec → plan → 实现 循环。
• 对范围合适的项目，一次问一个问题来打磨想法。
• 尽量用选择题（multiple choice），但开放式问题也可以。
• 每条消息只问一个问题 —— 如果某个话题需要更多探索，拆成多个问题。
• 关注点：目的（purpose）、约束（constraints）、成功标准（success criteria）。

3. 提出 2-3 个方案

附权衡分析与你的推荐。

• 提出 2-3 种不同方案，附权衡分析。
• 用对话化方式呈现选项，给出你的推荐与理由。
• 用推荐方案作为开头，并解释为什么。

4. 呈现设计

按各部分复杂度分段呈现，每段都获得用户批准。

• 一旦你觉得理解了要构建什么，就把设计呈现出来。
• 各部分按复杂度伸缩：直截了当的几句话即可，有微妙之处的可以写 200-300 字。
• 每段之后问"到目前为止看起来对吗？"。
• 覆盖：架构、组件、数据流、错误处理、测试。
• 一旦有什么讲不通，要随时回头澄清。
• 把系统拆成更小的单元，每个单元有一个明确的目的，通过定义良好的接口通信，并能被独立理解和测试。
• 对每个单元，你应当能回答：它做什么？怎么用？依赖什么？
• 别人能否在不读其内部实现的情况下理解一个单元的功能？你能否在不破坏调用方的前提下改其内部？如果不能，边界划分有问题。
• 更小、边界更清的单元也更便于你工作 —— 你对能完整放进上下文的代码推理得更好，而当文件聚焦时你的编辑也更可靠。当一个文件变大，往往就是它做得太多的信号。
• 当既有代码存在影响本次工作的问题时（例如某个文件已经过大、边界不清、职责纠缠），把针对性的改进作为设计的一部分纳入 —— 像一个优秀开发者改进他正在动的代码那样。
• 不要提议无关的重构。保持聚焦于服务当前目标。

5. 写设计文档

• 把已验证的设计（spec）写到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md（用户对 spec 位置的偏好可覆盖此默认值）
• 长 spec 拆分规则（硬性）：写完后用行数判定（Windows PowerShell 用 (Get-Content file | Measure-Object -Line).Lines），若 spec 单文件 > 300 行：
  1. 在与原 spec 同级创建目录 docs/superpowers/specs/YYYY-MM-DD-<topic>-design/；
  2. 按"独立子主题 / 独立可审阅单元"切分内容，每份子文档命名 NN-<subtopic>.md，每份必须 < 300 行；切分边界优先沿用 spec 自身的一级 / 二级标题，不要机械按行切；
  3. 该目录下必须有 index.md，包含：① 项目背景与目标摘要（≤ 50 行）；② 子文档清单（一行说明 + 相对链接）；③ 建议阅读顺序；④ 跨文档引用约定（统一用相对路径 + 锚点，例如 ./02-data-model.md#schema）；
  4. 原 YYYY-MM-DD-<topic>-design.md 默认删除，由该目录的 index.md 取代为入口；若特殊原因需保留，则改为指向 ./<同名目录>/index.md 的一行 redirect；

6. Spec 审查

写完 spec 后，主 Agent 禁止自查自审，必须派发 SubAgent 以"独立审阅者"身份检查写好的 spec 文件。

派发时给 SubAgent 的 prompt 必须显式要求覆盖下列 6 项检查，并要求其返回**"是否通过 / 问题清单（含文件位置与建议修订）"**：

1. Placeholder scan（占位符扫描）： 是否存在 "TBD"、"TODO"、未完成的段落或含糊的需求？
2. Internal consistency（内部一致性）： 各段落之间是否相互矛盾？架构与功能描述是否吻合？
3. Scope check（范围检查）： 这是否足够聚焦于单份实现计划，还是需要再拆分？
4. Ambiguity check（歧义检查）： 是否存在可以被两种方式解读的需求？
5. Split integrity（拆分完整性，仅当 spec 已拆为目录形态时）： ① 各子文档行数是否均 < 300 行；② index.md 是否齐备（摘要 / 子文档清单 / 阅读顺序 / 引用约定）；③ 子文档间相对链接与锚点是否有效；④ 是否存在重复内容或被切碎到无法独立理解的段落。
6. ASCII visualization check（ASCII 可视化检查）： ① 结构性内容（布局 / 流程 / 状态 / 层级）是否用 ASCII / Unicode 制表符图呈现；② 是否存在外链图片或对"视觉伴侣 / visual companion"的遗留引用（若有则标记删除）；③ ASCII 图是否被代码块包裹、对齐是否会被 Markdown 渲染破坏。

主 Agent 收到 SubAgent 的问题清单后，逐条 inline 修订 spec 文件；修订后若改动较大，可再派发一次 SubAgent 复查，否则不再循环，直接进入用户审阅环节。

7. 用户审阅已写好的 spec

在 spec 审阅循环通过之后，请用户在继续之前审阅写好的 spec：

"Spec 已写入并提交到 <path> 请审阅，告诉我是否需要修改后再进入后续开发。"

等待用户回复。如果用户提出修改，先改完再重跑 spec 审阅循环。只有在用户批准后才继续。

8. 评估并询问是否使用 SubAgent 并行开发

用户批准 spec 后，先基于 spec 内容判断是否值得、是否适合 SubAgent 并行开发——不要不经评估直接向用户抛「是/否」。

适合并行开发的信号（须同时满足多数）：

• spec 可拆成 ≥ 2 个相对独立的实现任务（各自有明确交付物与验收标准）；
• 并行任务之间 改动文件域不相交、无强先后依赖（或依赖可分层为多个 wave，同 wave 内仍不相交）；
• 各任务体量足够大，并行带来的收益大于协调成本（不是 1–2 个文件的 trivial 改动）。

不适合时（例如单文件小改、任务强耦合、需频繁共享中间状态、边界切不清）：说明理由，建议串行实现或用户自行选择其它方式；不得强行编排并行方案。

若判断适合，在询问用户之前须先 编排并行开发方案 并呈现，至少包含：

• 任务清单（每项：目标、涉及文件/目录、验收要点）；
• wave 划分（同 wave 内任务可并行；wave 之间串行及依赖关系）；
• 不相交依据（为何这些任务不会写同一文件）；
• 风险与取舍（若有任务边界存疑，说明为何仍归入不同 wave 或为何降级为串行）。

呈现后询问用户是否采用该方案：

"基于 spec，我建议按下列 wave 并行开发：[方案摘要]。是否按此方案执行 SubAgent 并行开发？（是 / 否 / 需调整）"

• 如用户确认进入开发（"是"/"用"/"go" 等，含采用 SubAgent 并行或经调整后确认的方案）：先用 TodoWrite 将 brainstorming 阶段 Todo（步骤 1–8）全部标为 completed，再基于已批准的开发任务（含 wave 划分，若适用）创建新的开发 Todo 列表并按序执行。
  • 开发 Todo 须覆盖全部实现任务（并行或串行均可，依用户选择）；最后一项必须是「代码评审」，且 必须派发 SubAgent 以独立审阅者身份执行——即使用户选择不由 SubAgent 参与实现，代码评审仍不得由主 Agent 自查自审。
• 如用户要求调整，修订方案后再次呈现并询问；确认前不得开工。
• 如用户拒绝开发或希望另行处理，先将 brainstorming Todo 收尾（未完成项说明原因后标记完成或取消），停在此处，由用户决定后续动作。
• 在用户明确回复进入开发之前，不得调用任何实现类 skill 或开始写实现代码。

关键原则（Key Principles）

• 一次一个问题 —— 不要用一堆问题压垮用户。
• 优先选择题 —— 比开放式问题更易回答。
• 狠抠 YAGNI —— 从所有设计中删掉不必要的功能。
• 探索替代方案 —— 落地前永远先提 2-3 个方案。
• 增量校验 —— 呈现设计，得到批准后再往下走。
• 保持灵活 —— 一旦有什么不对劲，随时回头澄清。

ASCII 可视化（ASCII Visualization）

当 brainstorming / spec 需要表达布局、流程、状态机、组件层级、数据流等结构性信息时，一律用 ASCII / Unicode 制表符直接在对话或 Markdown 中呈现，不要外链图片、不要调浏览器。

何时画：

• 页面 / 组件布局 → ASCII wireframe（用 ┌─┐│└┘ 或 +--+| |+--+）。
• 跳转 / 调用流程 → ASCII flow（用 ─▶ ▼ ◀─ 或 --> | <--）。
• 状态机 → 节点 + 箭头标注事件。
• 层级 / 目录 → ├─ └─ 缩进树。
• 数据流 → 左→右带管道符号的 pipeline。

怎么画：

• 优先 Unicode 制表符（─│┌┐└┘├┤┬┴┼▶◀▲▼），ASCII 退化方案 -|+><^v 仅在不支持 Unicode 的输出场景使用。
• 每张图前后用一行空行隔开，外裹 ``` 代码块（无语言标记或标 text），避免 Markdown 渲染破坏对齐。
• 单张图建议 ≤ 30 行、≤ 100 列；超出就拆多张并标号（图 1 / 图 2）并在 spec 正文交叉引用。
• 保留 ECharts 等真实图表的实现讨论：spec 里可以描述"图表选型 + 配置思路 + 字段映射"，但不在 spec 中插入图片 / 截图；图表交互说明用 ASCII wireframe + 文字标注完成。

示例（页面布局）：

┌──────────────────────────────────────────┐
│  顶部筛选区  [日期] [门店] [角色]  [导出] │
├──────────────┬───────────────────────────┤
│              │  ┌───────────┐ ┌────────┐ │
│  左侧导航树  │  │ KPI 卡 ×4 │ │ 趋势图 │ │
│              │  └───────────┘ └────────┘ │
│              │  明细表（虚拟滚动）       │
└──────────────┴───────────────────────────┘

绝对禁止：

• 在 spec 中嵌入二进制图片（PNG/JPG/SVG 外链）作为唯一可视化手段。
• 用纯文字段落替代本应画图就能说清的结构 —— 看到布局 / 流程 / 状态 / 层级问题，先画图再写字。