{"id":"07c20d2a-b6e4-4885-acd5-6d9663311ab8","shortId":"LAvCYY","kind":"skill","title":"brainstorming","tagline":"在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。","description":"# 头脑风暴：将想法转化为设计\n\n通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。\n\n首先了解当前项目的上下文，然后逐一提问来完善想法。一旦你理解了要构建的内容，就展示设计方案并获得用户批准。\n\n<HARD-GATE>\n在你展示设计方案并获得用户批准之前，不要调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于所有项目，无论看起来多简单。\n</HARD-GATE>\n\n## 反模式：\"这个太简单了，不需要设计\"\n\n每个项目都要经过这个流程。一个待办事项列表、一个单函数工具、一个配置变更——全都需要。\"简单\"的项目恰恰是未经检验的假设造成最多浪费的地方。设计可以很简短（对于真正简单的项目几句话就够了），但你必须展示出来并获得批准。\n\n## 检查清单\n\n你必须为以下每个条目创建任务，并按顺序完成：\n\n1. **探索项目上下文** — 检查文件、文档、最近的 commit\n2. **提供视觉伴侣**（如果主题涉及视觉问题）— 这是一条独立的消息，不要与澄清问题合并。参见下方的\"视觉伴侣\"部分。\n3. **提出澄清问题** — 每次一个，了解目的/约束/成功标准\n4. **提出 2-3 种方案** — 附带权衡分析和你的推荐\n5. **展示设计** — 按复杂度分节展示，每节展示后获得用户批准\n6. **编写设计文档** — 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并 commit\n7. **规格自检** — 快速内联检查占位符、矛盾、模糊性、范围（详见下方）\n8. **用户审查书面规格** — 在继续之前请用户审查规格文件\n9. **过渡到实现** — 调用 writing-plans 技能创建实现计划\n\n## 流程图\n\n```dot\ndigraph brainstorming {\n    \"探索项目上下文\" [shape=box];\n    \"有视觉相关问题?\" [shape=diamond];\n    \"提供视觉伴侣\\n（独立消息，不含其他内容）\" [shape=box];\n    \"提出澄清问题\" [shape=box];\n    \"提出 2-3 种方案\" [shape=box];\n    \"分节展示设计\" [shape=box];\n    \"用户批准设计?\" [shape=diamond];\n    \"编写设计文档\" [shape=box];\n    \"规格自检\\n（内联修复）\" [shape=box];\n    \"用户审查规格?\" [shape=diamond];\n    \"调用 writing-plans 技能\" [shape=doublecircle];\n\n    \"探索项目上下文\" -> \"有视觉相关问题?\";\n    \"有视觉相关问题?\" -> \"提供视觉伴侣\\n（独立消息，不含其他内容）\" [label=\"是\"];\n    \"有视觉相关问题?\" -> \"提出澄清问题\" [label=\"否\"];\n    \"提供视觉伴侣\\n（独立消息，不含其他内容）\" -> \"提出澄清问题\";\n    \"提出澄清问题\" -> \"提出 2-3 种方案\";\n    \"提出 2-3 种方案\" -> \"分节展示设计\";\n    \"分节展示设计\" -> \"用户批准设计?\";\n    \"用户批准设计?\" -> \"分节展示设计\" [label=\"否，修改\"];\n    \"用户批准设计?\" -> \"编写设计文档\" [label=\"是\"];\n    \"编写设计文档\" -> \"规格自检\\n（内联修复）\";\n    \"规格自检\\n（内联修复）\" -> \"用户审查规格?\";\n    \"用户审查规格?\" -> \"编写设计文档\" [label=\"要求修改\"];\n    \"用户审查规格?\" -> \"调用 writing-plans 技能\" [label=\"批准\"];\n}\n```\n\n**终止状态是调用 writing-plans。** 不要调用 frontend-design、mcp-builder 或任何其他实现技能。头脑风暴之后你唯一要调用的技能是 writing-plans。\n\n## 流程详述\n\n**理解想法：**\n\n- 首先查看当前项目状态（文件、文档、最近的 commit）\n- 在提出详细问题之前，先评估范围：如果需求描述了多个独立子系统（例如\"构建一个包含聊天、文件存储、计费和分析的平台\"），立即指出这一点。不要花时间用问题去细化一个需要先拆分的项目。\n- 如果项目规模过大，单个规格说明无法覆盖，帮助用户分解为子项目：有哪些独立的部分，它们之间有什么关系，应该按什么顺序构建？然后通过正常的设计流程进行第一个子项目的头脑风暴。每个子项目都有自己的规格 → 计划 → 实现周期。\n- 对于范围适当的项目，每次提一个问题来完善想法\n- 尽量使用选择题，开放式问题也可以\n- 每条消息只提一个问题——如果一个主题需要更多探索，拆分成多个问题\n- 重点理解：目的、约束、成功标准\n\n**探索方案：**\n\n- 提出 2-3 种不同的方案及其权衡\n- 以对话的方式展示选项，附上你的推荐和理由\n- 先展示你推荐的方案并解释原因\n\n**展示设计：**\n\n- 一旦你认为理解了要构建的内容，就展示设计\n- 每个部分的篇幅与其复杂度匹配：简单的几句话，复杂的最多 200-300 字\n- 每个部分展示后询问是否正确\n- 涵盖：架构、组件、数据流、错误处理、测试\n- 随时准备回头澄清不明确的地方\n\n**面向隔离和清晰的设计：**\n\n- 将系统拆分为更小的单元，每个单元有一个明确的职责，通过定义良好的接口通信，可以独立理解和测试\n- 对于每个单元，你应该能回答：它做什么，如何使用，它依赖什么？\n- 别人能否不看内部实现就理解一个单元的功能？你能否在不影响调用者的情况下修改内部实现？如果不能，边界需要调整。\n- 更小、边界清晰的单元也更便于你工作——你对能一次放入上下文的代码推理得更好，文件越专注你的编辑越可靠。当文件变大时，这通常意味着它承担了过多职责。\n\n**在现有代码库中工作：**\n\n- 在提出更改之前先探索现有结构。遵循现有模式。\n- 如果现有代码存在影响当前工作的问题（例如文件过大、边界不清、职责纠缠），在设计中包含有针对性的改进——就像一个优秀的开发者在工作中改进经手的代码一样。\n- 不要提议无关的重构。专注于服务当前目标的事情。\n\n## 设计之后\n\n**文档：**\n\n- 将验证通过的设计（规格说明）写入 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`\n  - （用户对规格位置的偏好优先于此默认值）\n- 如果可用，使用 elements-of-style:writing-clearly-and-concisely 技能\n- 将设计文档 commit 到 git\n\n**规格自检：**\n编写规格文档后，以全新的视角审视它：\n\n1. **占位符扫描：** 有没有\"待定\"、\"TODO\"、未完成的章节或模糊的需求？修复它们。\n2. **内部一致性：** 各章节之间有矛盾吗？架构和功能描述匹配吗？\n3. **范围检查：** 这是否聚焦到可以用一个实现计划覆盖，还是需要进一步拆分？\n4. **模糊性检查：** 有没有需求可以被两种方式理解？如果有，选择一种并明确写出来。\n\n发现问题就直接内联修复。无需重新审查——修好继续推进。\n\n**用户审查关卡：**\n规格自检完成后，请用户在继续之前审查书面规格：\n\n> \"规格已编写并 commit 到 `<path>`。请审查一下，如果在我们开始编写实现计划之前你想做任何修改，请告诉我。\"\n\n等待用户回复。如果他们要求修改，做出修改并重新运行规格自检。只有在用户批准后才继续。\n\n**实现：**\n\n- 调用 writing-plans 技能创建详细的实现计划\n- 不要调用任何其他技能。writing-plans 是下一步。\n\n## 核心原则\n\n- **每次一个问题** — 不要同时抛出多个问题\n- **优先选择题** — 在可能的情况下比开放式问题更容易回答\n- **严格遵循 YAGNI** — 从所有设计中移除不必要的功能\n- **探索替代方案** — 在做决定之前始终提出 2-3 种方案\n- **增量验证** — 展示设计，获得批准后再继续\n- **保持灵活** — 有不明确的地方就回头澄清\n\n## 视觉伴侣\n\n一个基于浏览器的伴侣工具，用于在头脑风暴过程中展示原型、图表和视觉选项。它是一个工具——不是一种模式。接受伴侣意味着它可用于适合视觉呈现的问题；并不意味着每个问题都要通过浏览器。\n\n**提供伴侣：** 当你预计后续问题会涉及视觉内容（原型、布局、图表）时，提供一次以获得同意：\n> \"我们接下来讨论的一些内容，如果能在浏览器中展示给你看可能会更直观。我可以在讨论过程中为你制作原型、图表、对比图和其他视觉材料。这个功能还比较新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）\"\n\n**此提议必须是一条独立的消息。** 不要将它与澄清问题、上下文摘要或任何其他内容合并。消息中应该只包含上述提议，没有其他内容。等待用户回复后再继续。如果他们拒绝，继续纯文本的头脑风暴。\n\n**逐问题决策：** 即使用户接受了，也要对每个问题单独决定是使用浏览器还是终端。判断标准：**用户看到它是否比读到它更容易理解？**\n\n- **使用浏览器** 展示本身就是视觉的内容——原型、线框图、布局对比、架构图、并排视觉设计\n- **使用终端** 展示文本内容——需求问题、概念选择、权衡列表、A/B/C/D 文字选项、范围决策\n\n关于 UI 主题的问题不一定是视觉问题。\"在这个上下文中个性化是什么意思？\"是一个概念问题——使用终端。\"哪种向导布局更好？\"是一个视觉问题——使用浏览器。\n\n如果他们同意使用伴侣，在继续之前阅读详细指南：\n`skills/brainstorming/visual-companion.md`","tags":["brainstorming","superpowers","jnmetacode","agent-skills","agentic-coding","ai-coding","chinese","claude-code","code-review","cursor","gemini-cli","kiro"],"capabilities":["skill","source-jnmetacode","skill-brainstorming","topic-agent-skills","topic-agentic-coding","topic-ai-coding","topic-chinese","topic-claude-code","topic-code-review","topic-cursor","topic-gemini-cli","topic-kiro","topic-mcp","topic-npm-package","topic-prompt-engineering"],"categories":["superpowers-zh"],"synonyms":[],"warnings":[],"endpointUrl":"https://skills.sh/jnMetaCode/superpowers-zh/brainstorming","protocol":"skill","transport":"skills-sh","auth":{"type":"none","details":{"cli":"npx skills add jnMetaCode/superpowers-zh","source_repo":"https://github.com/jnMetaCode/superpowers-zh","install_from":"skills.sh"}},"qualityScore":"0.700","qualityRationale":"deterministic score 0.70 from registry signals: · indexed on github topic:agent-skills · 1857 github stars · SKILL.md body (4,202 chars)","verified":false,"liveness":"unknown","lastLivenessCheck":null,"agentReviews":{"count":0,"score_avg":null,"cost_usd_avg":null,"success_rate":null,"latency_p50_ms":null,"narrative_summary":null,"summary_updated_at":null},"enrichmentModel":"deterministic:skill-github:v1","enrichmentVersion":1,"enrichedAt":"2026-05-03T00:52:45.319Z","embedding":null,"createdAt":"2026-04-18T21:55:51.209Z","updatedAt":"2026-05-03T00:52:45.319Z","lastSeenAt":"2026-05-03T00:52:45.319Z","tsv":"'-3':61,113,162,166,256,394 '-300':268 '1':38,336 '2':44,60,112,161,165,255,343,393 '200':267 '3':52,347 '4':58,351 '5':64 '6':68 '7':75 '8':82 '9':85 'a/b/c/d':452 'box':98,107,110,116,119,125,130 'brainstorm':1,95 'builder':210 'clear':325 'commit':43,74,222,330,363 'concis':327 'design':207 'design.md':72,315 'diamond':101,122,133 'digraph':94 'docs/superpowers/specs/yyyy-mm-dd-':71,314 'dot':93 'doublecircl':140 'element':320 'elements-of-styl':319 'frontend':206 'frontend-design':205 'git':332 'label':148,152,173,178,190,198 'mcp':209 'mcp-builder':208 'n':103,127,145,155,182,185 'plan':90,137,196,203,215,376,381 'shape':97,100,106,109,115,118,121,124,129,132,139 'skill' 'skill-brainstorming' 'skills/brainstorming/visual-companion.md':466 'source-jnmetacode' 'style':322 'todo':340 'token':423 'topic-agent-skills' 'topic-agentic-coding' 'topic-ai-coding' 'topic-chinese' 'topic-claude-code' 'topic-code-review' 'topic-cursor' 'topic-gemini-cli' 'topic-kiro' 'topic-mcp' 'topic-npm-package' 'topic-prompt-engineering' 'ui':456 'url':426 'write':89,136,195,202,214,324,375,380 'writing-clearly-and-concis':323 'writing-plan':88,135,194,201,213,374,379 'yagni':389 '一个单函数工具':27 '一个基于浏览器的伴侣工具':402 '一个待办事项列表':26 '一个配置变更':28 '一旦你理解了要构建的内容':14 '一旦你认为理解了要构建的内容':262 '上下文摘要或任何其他内容合并':429 '不含其他内容':105,147,157 '不是一种模式':406 '不要与澄清问题合并':48 '不要同时抛出多个问题':385 '不要将它与澄清问题':428 '不要提议无关的重构':307 '不要花时间用问题去细化一个需要先拆分的项目':231 '不要调用':204 '不要调用任何其他技能':378 '不要调用任何实现技能':17 '不需要设计':24 '专注于服务当前目标的事情':308 '严格遵循':388 '主题的问题不一定是视觉问题':457 '也要对每个问题单独决定是使用浏览器还是终端':437 '了解目的':55 '从所有设计中移除不必要的功能':390 '以全新的视角审视它':335 '以对话的方式展示选项':258 '优先选择题':386 '但你必须展示出来并获得批准':34 '你对能一次放入上下文的代码推理得更好':294 '你应该能回答':284 '你必须为以下每个条目创建任务':36 '你能否在不影响调用者的情况下修改内部实现':289 '使用':318 '使用浏览器':440,463 '使用终端':447,460 '例如':226 '例如文件过大':302 '保存到':70 '保持灵活':399 '修复它们':342 '修好继续推进':358 '修改':175 '做出修改并重新运行规格自检':370 '先展示你推荐的方案并解释原因':260 '先评估范围':224 '全都需要':29 '关于':455 '内联修复':128,183,186 '内部一致性':344 '写入':313 '分节展示设计':117,168,169,172 '创建功能':3 '判断标准':438 '别人能否不看内部实现就理解一个单元的功能':288 '到':331,364 '单个规格说明无法覆盖':233 '占位符扫描':337 '即使用户接受了':436 '原型':411,442 '参见下方的':49 '反模式':22 '发现问题就直接内联修复':356 '只有在用户批准后才继续':371 '可以独立理解和测试':282 '可能会消耗较多':422 '各章节之间有矛盾吗':345 '否':153,174 '哪种向导布局更好':461 '图表':413,419 '图表和视觉选项':404 '在任何创造性工作之前必须使用此技能':2 '在你展示设计方案并获得用户批准之前':16 '在做决定之前始终提出':392 '在可能的情况下比开放式问题更容易回答':387 '在实现之前先探索用户意图':6 '在提出更改之前先探索现有结构':299 '在提出详细问题之前':223 '在现有代码库中工作':298 '在继续之前请用户审查规格文件':84 '在继续之前阅读详细指南':465 '在设计中包含有针对性的改进':305 '在这个上下文中个性化是什么意思':458 '增量验证':396 '复杂的最多':266 '头脑风暴':8 '头脑风暴之后你唯一要调用的技能是':212 '如何使用':286 '如果一个主题需要更多探索':247 '如果不能':290 '如果主题涉及视觉问题':46 '如果他们同意使用伴侣':464 '如果他们拒绝':433 '如果他们要求修改':369 '如果可用':317 '如果在我们开始编写实现计划之前你想做任何修改':366 '如果有':354 '如果现有代码存在影响当前工作的问题':301 '如果能在浏览器中展示给你看可能会更直观':417 '如果需求描述了多个独立子系统':225 '如果项目规模过大':232 '字':269 '它们之间有什么关系':236 '它依赖什么':287 '它做什么':285 '它是一个工具':405 '实现':372 '实现周期':241 '对于每个单元':283 '对于真正简单的项目几句话就够了':33 '对于范围适当的项目':242 '对比图和其他视觉材料':420 '将想法转化为设计':9 '将系统拆分为更小的单元':279 '将设计文档':329 '将验证通过的设计':311 '就像一个优秀的开发者在工作中改进经手的代码一样':306 '就展示设计':263 '就展示设计方案并获得用户批准':15 '尽量使用选择题':244 '展示文本内容':448 '展示本身就是视觉的内容':441 '展示设计':65,261,397 '布局':412 '布局对比':444 '帮助将想法转化为完整的设计和规格说明':11 '帮助用户分解为子项目':234 '并':73 '并不意味着每个问题都要通过浏览器':408 '并按顺序完成':37 '并排视觉设计':446 '应该按什么顺序构建':237 '开放式问题也可以':245 '当你预计后续问题会涉及视觉内容':410 '当文件变大时':296 '待定':339 '快速内联检查占位符':77 '成功标准':57,252 '我们接下来讨论的一些内容':416 '我可以在讨论过程中为你制作原型':418 '或任何其他实现技能':211 '批准':199 '技能':138,197,328 '技能创建实现计划':91 '技能创建详细的实现计划':377 '拆分成多个问题':248 '按复杂度分节展示':66 '探索方案':253 '探索替代方案':391 '探索项目上下文':39,96,141 '接受伴侣意味着它可用于适合视觉呈现的问题':407 '提供一次以获得同意':415 '提供伴侣':409 '提供视觉伴侣':45,102,144,154 '提出':59,111,160,164,254 '提出澄清问题':53,108,151,158,159 '搭建任何项目或采取任何实现行动':19 '数据流':274 '文件':219 '文件存储':228 '文件越专注你的编辑越可靠':295 '文字选项':453 '文档':41,220,310 '无论看起来多简单':21 '无需重新审查':357 '时':414 '是':149,179 '是一个概念问题':459 '是一个视觉问题':462 '是下一步':382 '更小':292 '最近的':42,221 '有不明确的地方就回头澄清':400 '有哪些独立的部分':235 '有没有':338 '有没有需求可以被两种方式理解':353 '有视觉相关问题':99,142,143,150 '未完成的章节或模糊的需求':341 '权衡列表':451 '构建一个包含聊天':227 '构建组件':4 '架构':272 '架构和功能描述匹配吗':346 '架构图':445 '核心原则':383 '检查文件':40 '检查清单':35 '概念选择':450 '模糊性':79 '模糊性检查':352 '此提议必须是一条独立的消息':427 '每个单元有一个明确的职责':280 '每个子项目都有自己的规格':239 '每个部分展示后询问是否正确':270 '每个部分的篇幅与其复杂度匹配':264 '每个项目都要经过这个流程':25 '每条消息只提一个问题':246 '每次一个':54 '每次一个问题':384 '每次提一个问题来完善想法':243 '每节展示后获得用户批准':67 '没有其他内容':431 '流程图':92 '流程详述':216 '测试':276 '消息中应该只包含上述提议':430 '涵盖':271 '添加功能或修改行为':5 '然后逐一提问来完善想法':13 '然后通过正常的设计流程进行第一个子项目的头脑风暴':238 '独立消息':104,146,156 '理解想法':217 '用于在头脑风暴过程中展示原型':403 '用户审查书面规格':83 '用户审查关卡':359 '用户审查规格':131,187,188,192 '用户对规格位置的偏好优先于此默认值':316 '用户批准设计':120,170,171,176 '用户看到它是否比读到它更容易理解':439 '的项目恰恰是未经检验的假设造成最多浪费的地方':31 '目的':250 '矛盾':78 '种不同的方案及其权衡':257 '种方案':62,114,163,167,395 '立即指出这一点':230 '等待用户回复':368 '等待用户回复后再继续':432 '简单':30 '简单的几句话':265 '约束':56,251 '线框图':443 '组件':273 '终止状态是调用':200 '继续纯文本的头脑风暴':434 '编写任何代码':18 '编写规格文档后':334 '编写设计文档':69,123,177,180,189 '职责纠缠':304 '范围':80 '范围决策':454 '范围检查':348 '获得批准后再继续':398 '要求修改':191 '要试试吗':424 '规格已编写并':362 '规格自检':76,126,181,184,333 '规格自检完成后':360 '规格说明':312 '视觉伴侣':50,401 '计划':240 '计费和分析的平台':229 '设计之后':309 '设计可以很简短':32 '详见下方':81 '请告诉我':367 '请审查一下':365 '请用户在继续之前审查书面规格':361 '调用':87,134,193,373 '边界不清':303 '边界清晰的单元也更便于你工作':293 '边界需要调整':291 '过渡到实现':86 '还是需要进一步拆分':350 '这个功能还比较新':421 '这个太简单了':23 '这是一条独立的消息':47 '这是否聚焦到可以用一个实现计划覆盖':349 '这适用于所有项目':20 '这通常意味着它承担了过多职责':297 '选择一种并明确写出来':355 '逐问题决策':435 '通过定义良好的接口通信':281 '通过自然的协作对话':10 '遵循现有模式':300 '部分':51 '重点理解':249 '错误处理':275 '附上你的推荐和理由':259 '附带权衡分析和你的推荐':63 '随时准备回头澄清不明确的地方':277 '需求和设计':7 '需求问题':449 '需要打开一个本地':425 '面向隔离和清晰的设计':278 '首先了解当前项目的上下文':12 '首先查看当前项目状态':218","prices":[{"id":"cba85536-5522-4763-8732-90262ecdcae1","listingId":"07c20d2a-b6e4-4885-acd5-6d9663311ab8","amountUsd":"0","unit":"free","nativeCurrency":null,"nativeAmount":null,"chain":null,"payTo":null,"paymentMethod":"skill-free","isPrimary":true,"details":{"org":"jnMetaCode","category":"superpowers-zh","install_from":"skills.sh"},"createdAt":"2026-04-18T21:55:51.209Z"}],"sources":[{"listingId":"07c20d2a-b6e4-4885-acd5-6d9663311ab8","source":"github","sourceId":"jnMetaCode/superpowers-zh/brainstorming","sourceUrl":"https://github.com/jnMetaCode/superpowers-zh/tree/main/skills/brainstorming","isPrimary":false,"firstSeenAt":"2026-04-18T21:55:51.209Z","lastSeenAt":"2026-05-03T00:52:45.319Z"}],"details":{"listingId":"07c20d2a-b6e4-4885-acd5-6d9663311ab8","quickStartSnippet":null,"exampleRequest":null,"exampleResponse":null,"schema":null,"openapiUrl":null,"agentsTxtUrl":null,"citations":[],"useCases":[],"bestFor":[],"notFor":[],"kindDetails":{"org":"jnMetaCode","slug":"brainstorming","github":{"repo":"jnMetaCode/superpowers-zh","stars":1857,"topics":["agent-skills","agentic-coding","ai-coding","chinese","claude-code","code-review","cursor","gemini-cli","kiro","mcp","npm-package","prompt-engineering","skills","superpowers","tdd","trae"],"license":"mit","html_url":"https://github.com/jnMetaCode/superpowers-zh","pushed_at":"2026-04-28T15:32:18Z","description":"🦸 AI 编程超能力 · 中文增强版 — superpowers（116k+ ⭐）完整汉化 + 6 个中国原创 skills，让 Claude Code / Copilot CLI / Hermes Agent / Cursor / Windsurf / Kiro / Gemini CLI 等 16 款 AI 编程工具真正会干活","skill_md_sha":"e01d423d3597154fdeda1e56a132e52ff3fc0f48","skill_md_path":"skills/brainstorming/SKILL.md","default_branch":"main","skill_tree_url":"https://github.com/jnMetaCode/superpowers-zh/tree/main/skills/brainstorming"},"layout":"multi","source":"github","category":"superpowers-zh","frontmatter":{"name":"brainstorming","description":"在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。"},"skills_sh_url":"https://skills.sh/jnMetaCode/superpowers-zh/brainstorming"},"updatedAt":"2026-05-03T00:52:45.319Z"}}