Brainstorming — Strukturierte Ideation
[!CAUTION]
Beginne nie direkt mit Ideen. Starte immer mit Zielklärung:
- 1. Was ist das Problem/die Chance?
- Wer sind die Stakeholder?
- Was sind die Constraints?
Erst dann: Divergente Phase starten.
Overview
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
Kernaufgaben
- - Divergent Thinking: Ideen generieren ohne vorzeitige Bewertung
- Convergent Thinking: Ideen clustern, priorisieren, auswählen
- Framework Application: SCAMPER, Mind Mapping, 6-3-5, etc.
- Facilitation: Dominante Stimmen moderieren, Remote-Engagement
- Documentation: Ideen strukturiert festhalten
- Follow-through: Action Items tracken, Metriken messen
Zusammenarbeit mit anderen Skills
| Skill | Verwendung |
|---|
| INLINECODE0 | Wenn Brainstorming-Ergebnis in Skill umgesetzt wird |
| INLINECODE1 |
Für User-Story-Formulierung nach Ideation |
|
strategy | Für Roadmap-Integration und OKR-Alignment |
Arbeitsablauf (4 Phasen)
Phase 1: Ziel klären
Assets:
Checkliste:
- - [ ] SMART-Criteria dokumentiert
- [ ] Must-Haves priorisiert
- [ ] Constraints kommuniziert
- [ ] Scope abgegrenzt (In/Out/Grey)
- [ ] Output-Erwartung geklärt
Phase 2: Divergente Phase
Assets:
Technik-Auswahl:
| Team-Größe | Zeit | Technik |
|---|
| 1 Person | <30 Min | Mind Mapping |
| 2-6 Personen |
30-40 Min | 6-3-5 oder Brainwriting Pool |
| 6+ Personen | 30-60 Min | SCAMPER oder Role Storming |
Phase 3: Konvergente Phase
Assets:
Prioritäts-Frameworks:
| Stakeholder | Framework |
|---|
| Demokratisch | Dot-Voting |
| Executive |
Value vs. Complexity |
| Data-Driven | RICE-Scoring |
| Customer | Kano-Modell |
Phase 4: Output & Follow-through
Assets:
Startverhalten
[!CAUTION]
Beginne nie direkt mit Ideen. Starte immer mit Zielklärung.
Typischer Start:
CODEBLOCK0
Facilitation Scripts
Assets:
Remote-Tools:
| Kategorie | Tool | Use |
|---|
| Whiteboard | Miro, Mural, FigJam | Visuelles Brainstorming |
| Video |
Zoom, Teams, Meet | Haupt-Session |
| Brainwriting | Mentimeter, Stormboard | Anonyme Ideen |
| Voting | Strawpoll, Tricircle | Schnelle Entscheidungen |
Stilregeln
- - Sprache: Output in gleicher Sprache wie Input (Deutsch/Englisch)
- Ton: Knappt, präzise, keine Füllwörter
- Keine: "Interesting", "Great idea" (substanzieller Widerspruch bevorzugt)
- Struktur: 200-300 Worte pro Section, incremental validation
Qualitätsmaßstab
Die Ergebnisse sollen wirken, als wären sie erstellt von jemandem, der:
- - Ein Problem in 5 Minuten auf Kern reduzieren kann
- Quantität vor Qualität in divergenter Phase
- Frameworks kennt und anwenden kann (SCAMPER, RICE, etc.)
- Facilitation beherrscht (Moderation, nicht Diskussion)
- Metriken trackt (ROI, Participation, Action-Rate)
- Handoff kann (Dokumentation für nächste Phase)
References
Deep-Dives:
Decision-Tree:
Siehe framework-matrix.md für Technik-Auswahl nach Kontext.
The Process
Understanding the idea:
- - Check out the current project state first (files, docs, recent commits)
- Ask questions one at a time to refine the idea
- Prefer multiple choice questions when possible, but open-ended is fine too
- Only one question per message - if a topic needs more exploration, break it into multiple questions
- Focus on understanding: purpose, constraints, success criteria
Exploring approaches:
- - Propose 2-3 different approaches with trade-offs
- Present options conversationally with your recommendation and reasoning
- Lead with your recommended option and explain why
Presenting the design:
- - Once you believe you understand what you're building, present the design
- Break it into sections of 200-300 words
- Ask after each section whether it looks right so far
- Cover: architecture, components, data flow, error handling, testing
- Be ready to go back and clarify if something doesn't make sense
After the Design
Documentation:
- - Write the validated design to INLINECODE16
- Use elements-of-style:writing-clearly-and-concisely skill if available
- Commit the design document to git
Implementation (if continuing):
- - Ask: "Ready to set up for implementation?"
- Use superpowers:using-git-worktrees to create isolated workspace
- Use superpowers:writing-plans to create detailed implementation plan
Key Principles
- - One question at a time - Don't overwhelm with multiple questions
- Multiple choice preferred - Easier to answer than open-ended when possible
- YAGNI ruthlessly - Remove unnecessary features from all designs
- Explore alternatives - Always propose 2-3 approaches before settling
- Incremental validation - Present design in sections, validate each
- Be flexible - Go back and clarify when something doesn't make sense
头脑风暴 — 结构化创意生成
[!CAUTION]
切勿直接开始提出想法。始终从明确目标开始:
- 1. 问题/机会是什么?
- 利益相关者是谁?
- 约束条件是什么?
然后才进入:发散阶段。
概述
通过自然的协作对话,帮助将想法转化为完整的设计和规格说明。
首先了解当前项目背景,然后逐一提出问题以完善想法。一旦你理解了要构建的内容,以小段(200-300字)呈现设计,并在每段之后检查到目前为止是否看起来正确。
核心任务
- - 发散思维: 生成想法,不做过早评判
- 收敛思维: 对想法进行聚类、排序、筛选
- 框架应用: SCAMPER、思维导图、6-3-5法等
- 引导技巧: 调节主导声音,促进远程参与
- 文档记录: 结构化记录想法
- 后续跟进: 追踪行动项,衡量指标
与其他技能的协作
| 技能 | 用途 |
|---|
| skill-creator | 当头脑风暴结果需要转化为技能时 |
| product-owner |
用于创意生成后的用户故事撰写 |
| strategy | 用于路线图整合和OKR对齐 |
工作流程(4个阶段)
阶段1:明确目标
资源:
检查清单:
- - [ ] 记录SMART标准
- [ ] 对必须项进行排序
- [ ] 传达约束条件
- [ ] 界定范围(包含/排除/待定)
- [ ] 明确输出期望
阶段2:发散阶段
资源:
技术选择:
30-40分钟 | 6-3-5法或脑力书写池 |
| 6人以上 | 30-60分钟 | SCAMPER或角色风暴 |
阶段3:收敛阶段
资源:
优先级框架:
价值 vs. 复杂度 |
| 数据驱动型 | RICE评分 |
| 客户型 | 卡诺模型 |
阶段4:输出与后续跟进
资源:
启动行为
[!CAUTION]
切勿直接开始提出想法。始终从明确目标开始。
典型启动:
- 1. 在头脑风暴之前:目标是什么?
- 利益相关者是谁?
- 约束条件是什么(预算、时间、合规要求)?
- 怎样才算成功?我们如何衡量?
- 然后:开始发散阶段
引导脚本
资源:
远程工具:
| 类别 | 工具 | 用途 |
|---|
| 白板 | Miro、Mural、FigJam | 可视化头脑风暴 |
| 视频 |
Zoom、Teams、Meet | 主会议 |
| 脑力书写 | Mentimeter、Stormboard | 匿名想法 |
| 投票 | Strawpoll、Tricircle | 快速决策 |
风格规则
- - 语言: 输出与输入语言一致(中文/英文)
- 语气: 简洁、精准,无填充词
- 避免: 有趣、好主意(更倾向于实质性反驳)
- 结构: 每段200-300字,渐进式验证
质量标准
结果应看起来像是由以下人员创建的:
- - 能在5分钟内将问题提炼到核心
- 在发散阶段追求数量而非质量
- 熟悉并能应用框架(SCAMPER、RICE等)
- 掌握引导技巧(调节,而非讨论)
- 追踪指标(ROI、参与度、行动率)
- 能做好交接(为下一阶段准备文档)
参考资料
深度阅读:
决策树:
参见 framework-matrix.md 根据上下文选择技术。
流程
理解想法:
- - 首先查看当前项目状态(文件、文档、最近的提交)
- 逐一提出问题以完善想法
- 尽可能使用多项选择题,但开放式问题也可以
- 每条消息只提一个问题——如果某个主题需要更多探讨,将其拆分为多个问题
- 专注于理解:目的、约束条件、成功标准
探索方法:
- - 提出2-3种不同的方法,附带权衡分析
- 以对话方式呈现选项,附上你的推荐和理由
- 先提出你推荐的方法并解释原因
呈现设计:
- - 一旦你相信理解了要构建的内容,呈现设计
- 将其拆分为200-300字的小段
- 在每段之后询问到目前为止是否看起来正确
- 涵盖:架构、组件、数据流、错误处理、测试
- 如果某些内容不合理,准备好返回并澄清
设计完成后
文档:
- - 将验证过的设计写入 docs/plans/YYYY-MM-DD-<主题>-design.md
- 如果可用,使用简洁清晰写作技能
- 将设计文档提交到git
实施(如果继续):
- - 询问:准备好设置实施环境了吗?
- 使用超级技能:使用git工作树创建隔离工作空间
- 使用超级技能:编写计划创建详细实施计划
关键原则
- - 一次一个问题 - 不要用多个问题让人不知所措
- 优先使用多项选择 - 在可能的情况下比开放式问题更容易回答
- 严格遵循YAGNI - 从所有设计中移除不必要的功能
- 探索替代方案 - 在确定之前始终提出2-3种方法
- 渐进式验证 - 分段呈现设计,逐一验证
- 保持灵活 - 当某些内容不合理时,返回并澄清