Brainstorming
Skill supper-skills/develpment-skills/skills_zh-CN/brainstorming
Turn your ideas into production-ready code. One sentence is all it takes to start building.
npx -y skills add supper-skills/develpment-skills --skill brainstormingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
在任何创造性工作前执行此步骤——包括创建功能、构建组件、添加功能或修改行为。在实施前探究用户意图、需求与设计方案。通过自然协作对话，将创意转化为完整的设计方案与规格说明。当用户提及"新功能"、"构建"、"创建组件"、"添加功能"、"实现"或开始任何开发工作时触发本技能。本技能会自动调用 project-context 技能获取用户画像和流程路径推荐。
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.4 KB, as published. Nobody here has run it
头脑风暴技能
本技能是任何创造性工作前的必经步骤，通过协作对话将创意转化为完整的设计规格说明。
核心原则
设计优先
在用户批准设计文档前，请勿：
- 调用任何实施技能
- 编写任何代码
- 搭建项目框架
- 采取任何实施行动
会话状态管理
使用统一的会话状态文件跟踪进度：
- 路径：
design/.session-state.md - 模板：
references/session-state-template.md
操作时机：
- 技能激活时 → 创建状态文件
- 获得用户确认后 → 更新状态文件
- 每轮对话开始时 → 读取状态文件恢复上下文
- 每个阶段完成后 → 更新状态文件
终止条件
本技能的唯一终止方式是调用 writing-plan 技能，并传递规格文档路径。
工作流程
阶段 1：探索背景
目标：了解当前项目状态，评估需求范围。
执行动作：
- 调用
project-context技能获取用户画像 - 读取项目上下文（如有）：
design/context/project-context.md - 检查项目文件结构
- 评估需求是否涉及多个独立子系统
- 主动更新用户画像（如果识别到新的偏好或技术背景）
范围检查：
- 若请求涉及多个独立子系统，协助用户分解为子项目
- 每个子项目独立进行头脑风暴
完成标准：已了解项目技术栈和现有结构，已确认需求范围，用户画像已更新（如有变化）
阶段 2：确认需求
目标：逐条理解目标、约束条件和成功标准。
执行规则：
- 每条消息只提一个问题
- 优先使用选择题形式
核心问题清单（按顺序询问）：
| 序号 | 问题类型 | 示例问题 |
|---|---|---|
| 1 | 目标定位 | "这个功能的主要用户是谁？" |
| 2 | 约束条件 | "有没有时间或技术栈的限制？" |
| 3 | 成功标准 | "如何判断这个功能是否成功交付？" |
| 4 | 边界情况 | "有没有需要特别处理的边界情况？" |
完成标准：目标定位明确、约束条件清晰、成功标准可验证
阶段 3：方案选择
目标：提供 2-3 种不同方案及其权衡分析。
执行动作：
- 提出 2-3 种不同方案
- 说明每种方案的优缺点
- 给出推荐方案及理由
完成标准：用户已选择一个方案
参考：
references/tech-selection-guide.md
阶段 4：设计文档
目标：将验证通过的设计写入规格文档。
执行动作：
- 创建规格文档：
design/specs/YYYY-MM-DD-<topic>-design.md - 包含所有已确认的内容
- 确保无 TODO、TBD 或占位符
文档结构：
| 章节 | 内容要求 |
|---|---|
| 概述 | 功能目标、背景上下文 |
| 目标定位 | 主要用户和使用场景 |
| 约束条件 | 技术、时间、资源限制 |
| 成功标准 | 可验证的交付标准 |
| 架构设计 | 系统结构和组件划分 |
| 数据流 | 数据如何流转 |
| 错误处理 | 异常情况处理策略 |
| 测试策略 | 如何验证功能正确性 |
完成标准：文档已写入指定路径，无占位符内容
参考：
references/spec-template.md
阶段 5：交接
目标：获得用户批准，调用 writing-plan 技能。
执行动作：
- 呈现规格文档路径给用户
- 请用户审阅并确认
- 若用户批准，调用 writing-plan 技能
标准话术：
"规格文档已编写并提交至
<path>。请审阅，确认后我将开始制定实施计划。"
调用格式：
调用 writing-plan 技能，规格文档路径：<path>
终止：此阶段完成后，本技能结束。
参考指南
| 参考文档 | 用途 |
|---|---|
references/session-state-template.md | 会话状态文件模板 |
references/spec-template.md | 规格文档模板 |
references/tech-selection-guide.md | 技术选型指导 |
references/risk-assessment-template.md | 风险评估模板 |
常见问题
用户坚持跳过设计直接实施？
回复：
"我理解您希望快速推进。设计文档可以很简短，但需要记录并获得您的批准，这能确保我们对目标达成共识，避免后续返工。"
项目范围过大怎么办？
处理方式：
- 标记为多子系统项目
- 协助用户分解为独立子项目
- 对第一个子项目开始头脑风暴
- 每个子项目独立进行规格→规划→实施循环
对话中断后如何恢复？
处理方式：
- 读取会话状态文件
design/.session-state.md - 根据"下一步"继续执行