thedixitjain Brainstorming
用途
- 把"直接跳到实现方案"改成"先发散探索、再收敛锁定"。
- 适合技术选型、架构方向、产品策略、用户体验方案等需要创造性思考的场景。
- 避免团队因锚定效应只看到第一个想到的方案。
默认做法
1. 框定问题
- 用一句话描述要解决的核心问题。
- 明确约束条件（时间、技术栈、团队能力、合规要求）。
- 明确成功标准：什么样的方案是"好方案"。
2. 发散阶段
产出至少 3 个差异化方案，每个方案包含：
- 一句话概述：方案的核心思路
- 关键假设：该方案依赖哪些前提
- 优势：这个方案比其他方案好在哪
- 风险：可能出什么问题
- 成本估算：时间/人力/基础设施的粗略评估
强制对比维度（来自 gstack multi-perspective 方法论）：
- 用户视角：哪个方案用户体验最好？
- 工程视角：哪个方案最容易维护和扩展？
- 商业视角：哪个方案 ROI 最高？
- 风险视角：哪个方案最不容易出问题？
3. 分块展示（来自 gstack chunked design）
- 复杂方案不要一口气全部展示，而是分层递进：
- 第一块：核心架构和关键决策（最高层）
- 第二块：模块拆分和接口设计（结构层）
- 第三块：技术细节和实现路径（执行层）
- 每块展示后暂停，等用户确认方向再展开下一层
- 用户可以在任意一层要求调整或切换方案
4. 收敛阶段
- 基于讨论结论，形成推荐方案的结构化输出：
- 推荐方案及原因
- 被排除的方案及排除原因
- 关键假设和待验证项
- 下一步行动建议
5. 产出
- 若用于
/team-plan前置：产出写入docs/artifacts/{slug}/brainstorm.md - 若用于独立探索：产出写入对话上下文，由用户决定是否持久化
- 若产出涉及架构级决策：建议同步写入 ADR
触发信号
- 用户说"我们讨论一下方案"、"有哪些选择"、"brainstorm"、"头脑风暴"。
/team-intake或discuss-phase识别出存在多条可行技术路线。architect在方案设计阶段需要对比多个选项。- 技术选型、框架选择、产品策略等需要创造性探索的场景。
配套约束
- 不替代正式决策：brainstorming 产出是输入，最终决策由
tech-lead或architect在/team-plan或 ADR 中锁定。 - 时间控制：单次 brainstorming 控制在 3-5 个方案以内，避免无限发散。
- 独立性：brainstorming 可以独立调用，不依赖
/team-*链路。 - 对话友好：分块展示模式应在每块结束后给用户反馈点，不要一次性输出整个方案。
Source: hashgraph-online/awesome-codex-plugins → plugins/Colin4k1024/tsp/skills/brainstorming/SKILL.md