# Brainstorming > Use when the user asks to brainstorm, clarify requirements, compare approaches, design a feature, draft a spec, sketch a prototype, or think through architecture before implementation. 适用于需求不清、方案未定、需要先梳理思路再实现，以及功能设计、组件设计、页面结构、交互流程、数据流和模块边界讨论。先探索用户意图、约束和设计，再决定是否进入实现。 - Skill: `morningstar0709/brainstorming` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add morningstar0709/brainstorming` - Raw SKILL.md: https://api.skillmd.com/api/skills/morningstar0709/brainstorming/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: MorningStar0709 (https://skillmd.com/u/morningstar0709) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/morningstar0709/brainstorming --- # Brainstorming ## Overview 通过自然的协作对话，帮助将想法转化为清晰、可执行的设计结论。 首先了解当前项目的上下文，然后逐一提问来完善想法。一旦你理解了要构建的内容，就展示设计方案并获得用户批准，再决定是否写入规格、是否进入计划模式或输出实现步骤、是否直接实现。 ## Use This Skill - 需求表述仍然模糊，直接实现很可能返工。 - 存在 2-3 种可行方案，需要先比较权衡再做决定。 - 涉及功能设计、组件设计、页面结构、交互流程、数据流或模块边界。 - 用户明确要求先做方案、设计、规格、原型、思路梳理或头脑风暴。 - 需要在实现前先获得用户对方向的批准。 ## Do Not Use - 用户只是在问一个直接事实、用法说明或单点解释。 - 任务已经有明确实现指令，只需要按要求小范围修改。 - 这是简单的单点修复、文本修改、配置更正或路径调整，且需求没有歧义。 - 用户明确要求跳过设计阶段，直接实现一个边界清晰的小任务。 - 当前步骤只是执行既定计划，而不是探索方案。 ## Input Contract **必需输入：** - 用户想讨论的问题、目标或待设计对象 **可选但强烈推荐的输入：** - 当前代码库上下文或相关路径 - 已知约束、非功能需求、边界条件 - 成功标准、验收方式、目标用户 - 是否需要落盘为规格文件 **缺失输入处理：** - 如果目标本身仍模糊，先通过单问题澄清逐步缩小范围 - 如果用户其实已经给出清晰实现指令，停止设计流程，改为直接实现或转交更合适的 skill - 如果缺少代码库上下文但仍可先讨论方向，先做概念设计，并明确哪些内容仍待结合仓库确认 ## Anti-Pattern: "This is too simple, no design needed" 不要因为任务看起来熟悉就跳过澄清。对于小任务，设计可以很短；对于已经清晰的任务，则不应强行套用本 Skill。 ## Checklist 你必须为以下每个条目创建任务，并按顺序完成： 1. **探索项目上下文** — 检查文件、文档、最近的变更；若当前目录是 git 仓库且确有帮助，再查看最近的 commit 2. **提供视觉伴侣**（仅当主题本身是视觉问题且当前环境支持时）— 这是一条独立的消息，不要与澄清问题合并。参见下方的"Visual Companion"部分。 3. **提出澄清问题** — 每次一个，了解目的/约束/成功标准 4. **提出 2-3 种方案** — 附带权衡分析和你的推荐 5. **展示设计** — 按复杂度分节展示，每节展示后获得用户批准 6. **选择输出形式** — 根据用户需求决定是内联总结、写入规格文件、输出实现步骤，还是直接实现 7. **规格自检** — 若写入规格，快速内联检查占位符、矛盾、模糊性、范围（详见下方） 8. **用户审查设计结果** — 若写入规格或设计较复杂，在继续前请用户确认 9. **过渡到下一步** — 根据用户意图选择进入计划模式、调用当前环境可用的计划类能力、直接实现，或结束在设计结论 ## Flowchart ```dot digraph brainstorming { "探索项目上下文" [shape=box]; "有视觉相关问题?" [shape=diamond]; "当前环境支持视觉伴侣?" [shape=diamond]; "提供视觉伴侣\n（独立消息，不含其他内容）" [shape=box]; "提出澄清问题" [shape=box]; "提出 2-3 种方案" [shape=box]; "分节展示设计" [shape=box]; "用户批准设计?" [shape=diamond]; "需要写入规格文件?" [shape=diamond]; "编写设计文档" [shape=box]; "规格自检\n（内联修复）" [shape=box]; "用户审查设计结果?" [shape=diamond]; "直接进入实现" [shape=doublecircle]; "进入计划模式\n或调用可用计划能力" [shape=doublecircle]; "结束于设计结论" [shape=doublecircle]; "探索项目上下文" -> "有视觉相关问题?"; "有视觉相关问题?" -> "当前环境支持视觉伴侣?" [label="是"]; "有视觉相关问题?" -> "提出澄清问题" [label="否"]; "当前环境支持视觉伴侣?" -> "提供视觉伴侣\n（独立消息，不含其他内容）" [label="是"]; "当前环境支持视觉伴侣?" -> "提出澄清问题" [label="否"]; "提供视觉伴侣\n（独立消息，不含其他内容）" -> "提出澄清问题"; "提出澄清问题" -> "提出 2-3 种方案"; "提出 2-3 种方案" -> "分节展示设计"; "分节展示设计" -> "用户批准设计?"; "用户批准设计?" -> "分节展示设计" [label="否，修改"]; "用户批准设计?" -> "需要写入规格文件?" [label="是"]; "需要写入规格文件?" -> "编写设计文档" [label="是"]; "需要写入规格文件?" -> "用户审查设计结果?" [label="否"]; "编写设计文档" -> "规格自检\n（内联修复）"; "规格自检\n（内联修复）" -> "用户审查设计结果?"; "用户审查设计结果?" -> "编写设计文档" [label="要求修改"]; "用户审查设计结果?" -> "进入计划模式\n或调用可用计划能力" [label="需要计划"]; "用户审查设计结果?" -> "直接进入实现" [label="需求已清晰"]; "用户审查设计结果?" -> "结束于设计结论" [label="仅需设计"]; } ``` ## Detailed Workflow **理解想法：** - 首先查看当前项目状态（文件、文档、最近的变更；若当前目录是 git 仓库且确有帮助，再查看最近的 commit） - 在提出详细问题之前，先评估范围：如果需求描述了多个独立子系统（例如"构建一个包含聊天、文件存储、计费和分析的平台"），立即指出这一点。不要花时间用问题去细化一个需要先拆分的项目。 - 如果项目规模过大，单个规格说明无法覆盖，帮助用户分解为子项目：有哪些独立的部分，它们之间有什么关系，应该按什么顺序构建？然后通过正常的设计流程进行第一个子项目的头脑风暴。每个子项目都有自己的规格 → 计划 → 实现周期。 - 对于范围适当的项目，每次提一个问题来完善想法 - 尽量使用选择题，开放式问题也可以 - 每条消息只提一个问题——如果一个主题需要更多探索，拆分成多个问题 - 重点理解：目的、约束、成功标准 - 如果用户已经给出了足够明确的约束和验收标准，可以快速确认后结束在简短设计，而不是强行延长流程 **探索方案：** - 提出 2-3 种不同的方案及其权衡 - 以对话的方式展示选项，附上你的推荐和理由 - 先展示你推荐的方案并解释原因 **展示设计：** - 一旦你认为理解了要构建的内容，就展示设计 - 每个部分的篇幅与其复杂度匹配：简单的几句话，复杂的最多 200-300 字 - 每个部分展示后询问是否正确 - 涵盖：架构、组件、数据流、错误处理、测试 - 随时准备回头澄清不明确的地方 **面向隔离和清晰的设计：** - 将系统拆分为更小的单元，每个单元有一个明确的职责，通过定义良好的接口通信，可以独立理解和测试 - 对于每个单元，你应该能回答：它做什么，如何使用，它依赖什么？ - 别人能否不看内部实现就理解一个单元的功能？你能否在不影响调用者的情况下修改内部实现？如果不能，边界需要调整。 - 更小、边界清晰的单元也更便于你工作——你对能一次放入上下文的代码推理得更好，文件越专注你的编辑越可靠。当文件变大时，这通常意味着它承担了过多职责。 **在现有代码库中工作：** - 在提出更改之前先探索现有结构。遵循现有模式。 - 如果现有代码存在影响当前工作的问题（例如文件过大、边界不清、职责纠缠），在设计中包含有针对性的改进——就像一个优秀的开发者在工作中改进经手的代码一样。 - 不要提议无关的重构。专注于服务当前目标的事情。 ## After Design - 默认先给出**内联设计摘要**，包括目标、约束、推荐方案、关键结构和下一步建议。 - 只有在用户需要沉淀、多人协作、后续要多轮实现，或你判断复杂度足以受益时，才写入规格文件。 - 如果用户只需要方向确认，不必强制落盘。 **文档（可选）：** - 将验证通过的设计写入用户认可的位置。默认建议路径可以是 `docs/superpowers/specs/YYYY-MM-DD--design.md`，但用户偏好优先。 - 只有在用户明确希望落盘、当前目录可写且这样做确有价值时，才写文件。 - 只有在当前目录本来就是 git 仓库，且用户希望保留版本记录时，才进行 commit。 **规格自检（若已写入规格）：** 编写规格文档后，以全新的视角审视它： 1. **占位符扫描：** 有没有"待定"、"TODO"、未完成的章节或模糊的需求？修复它们。 2. **内部一致性：** 各章节之间有矛盾吗？架构和功能描述匹配吗？ 3. **范围检查：** 这是否聚焦到可以用一个实现计划覆盖，还是需要进一步拆分？ 4. **模糊性检查：** 有没有需求可以被两种方式理解？如果有，选择一种并明确写出来。 发现问题就直接内联修复。无需重新审查——修好继续推进。 **用户审查关卡：** - 如果你写入了规格文件，或设计本身较复杂，请用户在继续前审查结果。 - 如果只是简短设计摘要且用户已在对话中确认，可以不再强制增加一个独立审查关卡。 规格自检完成后，可使用类似表述： > "设计结果已整理到 ``。请审查一下；如果在我们开始计划或实现之前你想做任何修改，请告诉我。" 等待用户回复。如果他们要求修改，做出修改并重新运行规格自检。只有在用户批准后才继续。 **下一步：** - 如果任务较复杂、需要明确里程碑或风险控制，优先衔接到 `writing-plans`；如果当前环境没有该 skill，再在当前对话中给出详细实现计划。 - 如果任务已经足够清晰且范围很小，可以在得到用户确认后直接实现。所谓"直接实现"是指在当前会话中直接编码，然后走标准收尾流程（`verification-before-completion` → commit 或分支收尾），而非跳过验证。 - 如果用户当前只需要设计结论，则结束在设计摘要或规格文件即可。 ## Output Contract 默认输出一份**内联设计摘要**，至少包含：目标、约束、推荐方案、关键结构、风险/待确认点、建议的下一步。 默认使用以下摘要骨架： ```markdown 设计讨论已收敛。 **目标:** [一句话] **关键约束:** - [若无则写 `- 无`] **可选方案:** - 方案 A: [一句话 + 取舍] - 方案 B: [一句话 + 取舍] - 方案 C: [如无则省略] **推荐方案:** - [推荐理由] **关键结构:** - [模块 / 页面 / 数据流 / 边界] **风险 / 待确认点:** - [若无则写 `- 无`] **下一步:** - [进入 writing-plans / 直接实现 / 写规格文件 / 结束在设计结论] ``` 如果写入规格文件，回复中必须额外给出：写入路径、文档用途、是否已完成规格自检、是否需要用户继续审查。 如果直接实现，先用一句话确认设计已收敛，再切换到实现任务。 ## Core Principles - **每次一个问题** — 不要同时抛出多个问题 - **优先选择题** — 在可能的情况下比开放式问题更容易回答 - **严格遵循 YAGNI** — 从所有设计中移除不必要的功能 - **探索替代方案** — 在做决定之前始终提出 2-3 种方案 - **增量验证** — 展示设计，获得批准后再继续 - **保持灵活** — 有不明确的地方就回头澄清 - **以最小流程达成清晰** — 不为简单且清晰的任务制造额外流程 ## Visual Companion `brainstorming` 附带一个**可选**的浏览器原型工具。用于展示布局、线框图、架构图等视觉内容，让用户直接在浏览器中点击选择。 **提供伴侣：** 当你预计后续问题会涉及视觉内容时，发送一条独立消息邀请用户： > "我们接下来讨论的一些内容，如果能在浏览器中展示给你看可能会更直观。我可以在讨论过程中为你制作原型、图表、对比图和其他视觉材料。这个功能还比较新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）" **此提议必须是一条独立的消息。** 不要与澄清问题或其他内容合并。用户拒绝则继续纯文本。 **逐问题决策：** 即使用户接受了，也要按"用户看到它是否比读到它更容易理解？"决定每个问题是否用浏览器。 如果用户同意使用伴侣，切换到 `visual-brainstorming` Skill 来管理后续的浏览器交互，完成后交回给 `brainstorming` 继续文字讨论。 如果当前环境不支持本地服务、预览或后台进程，跳过视觉伴侣，继续纯文本头脑风暴。 ## Resources - 示例输入输出：`examples/input.md`、`examples/output.md` - 评估用例：`evals/evals.json` - 规格审查模板：`spec-document-reviewer-prompt.md` ## Failure Handling - 如果无法快速判断是否需要本 Skill，先用一句话确认需求是否已经足够清晰；不要默认强行进入长流程。 - 如果用户不想写规格文件，改为输出内联设计摘要。 - 如果当前目录不是 git 仓库，或用户不希望记录版本，不要强制 commit。 - 如果当前环境不支持视觉伴侣，继续纯文本模式，不要因为缺少浏览器分支而阻塞任务。 - 如果当前环境没有 `writing-plans` 或其他专门的计划类 Skill，直接在当前对话中输出实现计划，不要引用不存在的能力名称。 - 如果用户在过程中改目标，回到澄清问题阶段，重新确认约束和成功标准。 ## Integration - `writing-plans`: Downstream — brainstorming clarifies requirements and design, then hands off to writing-plans for task breakdown before implementation. - `executing-plans`: Downstream — when the scope is small and confirmed, brainstorming can proceed directly to sequential execution. - `subagent-driven-development`: Downstream — when the scope is small, confirmed, and tasks are independent, brainstorming can proceed directly to subagent-driven execution. - `visual-brainstorming`: Optional downstream — if the user accepts the browser companion offer, switch to visual-brainstorming for interactive prototyping, then return to brainstorming for text-based discussion.