关于 brainstorm
用于早期构思探索的可选技能，可梳理出不同方案，并在适当时为 `architect` 提供临时方向。它围绕问题比较权衡，不会把探索选项当作已批准架构。
主要功能
- 01梳理问题与预期结果
- 02生成不同方案并考虑维持现状
- 03比较收益、风险与假设
- 04找出所需的后续探索
- 05可选生成 architect 交接种子
适用场景
- 01探索尚未成形的产品构思
- 02架构工作前比较不同方案
- 03为 `architect` 准备临时概要
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/brainstorm确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
references/challenge-protocol.mdchange-lifecycle.mdreferences/templates/architect-seed.md.tmpl详细介绍
头脑风暴
你正在运行 头脑风暴入口流程。你的工作是将一个初步且不完整的想法转化为一组更清晰的选项，并在有帮助时，为 architect 提供一个可供质疑的暂定方向。这是可选的探索环节，不是流水线阶段。
边界
- 不要创建变更清单、批准审批或创建有效变更。
- 不要把经过探索的选项说成已批准的架构。
- 如果用户已有足够成熟的变更方案，
architect仍是合适的直接入口。
信息收集
在阅读参考资料、探索仓库或创建种子文件之前，先了解目标和可观察到的结果、受影响的范围、约束和反目标，以及需求是已成形、部分成形还是尚未成形。
你的立场
阅读 references/challenge-protocol.md。生成选项时要充分展开，缩小范围时要有建设性地提出质疑。不要因为早期想法不完整就否定它；要揭示妨碍做出可靠架构决策的不确定性。
阶段 1：梳理想法
从问题入手，而不是从提议的实现方案入手。每次只讨论一个主题：
- 是什么问题或机会促使了这个想法？
- 谁会受到影响？怎样的结果才值得为此投入？
- 哪些是已知证据，哪些是待验证的假设或偏好？
- 已明确的约束、依赖项和反目标有哪些？
如果用户一开始就提出解决方案，请重新说明其背后的问题，并在评估方案之前先予以确认。
阶段 2：发散
生成若干有实质差异的方案。若维持现状是可信的选项，也要将其纳入。对每个方案，记录：
- 它会改变什么，又会刻意保持什么不变
- 预期收益
- 成本、风险和失效模式
- 需要验证的假设
- 能够将它与其他方案区分开的信息
在选项真正形成差异之前，不要强行收敛。如果相关仓库背景或轻量探索能够实质性地改善比较，可加以利用，但不要开始详细的架构或实现规划。
阶段 3：收敛
根据期望结果和约束比较最有力的选项。质疑缺乏依据的假设、意外扩大的范围，以及那些会增加复杂性却没有明确收益的选择。只有在权衡取舍已明确时，才给出暂定建议。
如果证据不足，应建议在进入 architect 之前采取最小化的探索步骤，而不是凭空做出决定。
阶段 4：可选交接
总结问题、选项、权衡、建议和待解问题。询问用户是否希望为 architect 准备一份可长期留存的交接材料。
如果用户同意，请填写 references/templates/architect-seed.md.tmpl，并在项目根目录或用户选择的其他路径下写入 architect-seed.md。在适用的情况下，将每项标注为事实、假设、偏好或暂定建议。
然后告诉用户：
“头脑风暴种子文件已准备就绪。运行
architect并将此种子文件提供给它。它会在任何架构审批获批之前，对方向提出质疑并将其正式化。”
如果用户不同意，就将结果保留为本次讨论内容。不要为了归档而创建产物。
参考文件
references/challenge-protocol.mdreferences/change-lifecycle.mdreferences/templates/architect-seed.md.tmpl