Back to Details

brainstorm

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Collaborative Brainstorming

协作式头脑风暴

Structured ideation using the Double Diamond model, grounded in persistent memory. Mined from 100+ real brainstorming sessions across production projects.
Core insight: AI excels at divergent phases (volume, cross-domain connections). Humans excel at convergent phases (judgment, selection). This skill separates the two and uses Sibyl as institutional memory to prevent re-exploring solved problems.
基于持久化记忆，采用Double Diamond模型的结构化构思方法。该方法源自100多个生产项目中的真实头脑风暴会议。
核心洞察： AI擅长发散阶段（大量产出、跨领域关联）。人类擅长收敛阶段（判断、选择）。本Skill将两者分离，并利用Sibyl作为机构记忆，避免重复探索已解决的问题。

The Process

流程

dot
digraph brainstorm {
    rankdir=TB;
    node [shape=box];

    "1. GROUND" [style=filled, fillcolor="#e8e8ff"];
    "2. DIVERGE: Problem" [style=filled, fillcolor="#ffe8e8"];
    "3. CONVERGE: Define" [style=filled, fillcolor="#e8ffe8"];
    "4. DIVERGE: Solutions" [style=filled, fillcolor="#ffe8e8"];
    "5. CONVERGE: Decide" [style=filled, fillcolor="#e8ffe8"];
    "EXIT → Any skill" [style=filled, fillcolor="#fff8e0"];

    "1. GROUND" -> "2. DIVERGE: Problem";
    "2. DIVERGE: Problem" -> "3. CONVERGE: Define";
    "3. CONVERGE: Define" -> "4. DIVERGE: Solutions";
    "4. DIVERGE: Solutions" -> "5. CONVERGE: Decide";
    "5. CONVERGE: Decide" -> "EXIT → Any skill";
}
dot
digraph brainstorm {
    rankdir=TB;
    node [shape=box];

    "1. GROUND" [style=filled, fillcolor="#e8e8ff"];
    "2. DIVERGE: Problem" [style=filled, fillcolor="#ffe8e8"];
    "3. CONVERGE: Define" [style=filled, fillcolor="#e8ffe8"];
    "4. DIVERGE: Solutions" [style=filled, fillcolor="#ffe8e8"];
    "5. CONVERGE: Decide" [style=filled, fillcolor="#e8ffe8"];
    "EXIT → Any skill" [style=filled, fillcolor="#fff8e0"];

    "1. GROUND" -> "2. DIVERGE: Problem";
    "2. DIVERGE: Problem" -> "3. CONVERGE: Define";
    "3. CONVERGE: Define" -> "4. DIVERGE: Solutions";
    "4. DIVERGE: Solutions" -> "5. CONVERGE: Decide";
    "5. CONVERGE: Decide" -> "EXIT → Any skill";
}

Phase 1: GROUND (Memory-First)

阶段1：锚定（记忆优先）

Before generating a single idea, search what we already know.
在产生任何想法之前，先检索我们已有的知识。

Actions

行动

  1. Search Sibyl for related patterns, past decisions, known constraints:
    • sibyl search "<topic keywords>"
      — find prior art
    • sibyl search "<related architecture>"
      — find relevant patterns
    • Check for existing tasks/epics on this topic
  2. Surface constraints — what's already decided? What's non-negotiable?
    • Tech stack locked? Budget constraints? Timeline?
    • Existing patterns we must follow?
  3. Present prior art — show the user what Sibyl knows before ideating:
    "Sibyl has 3 relevant entries: [pattern X from project Y], [decision Z from last month], [gotcha W]. Want to factor these in?"
  1. 在Sibyl中检索相关模式、过往决策、已知约束：
    • sibyl search "<topic keywords>"
      — 查找已有方案
    • sibyl search "<related architecture>"
      — 查找相关模式
    • 检查该主题下是否存在现有任务/史诗
  2. 明确约束条件 — 哪些内容已确定？哪些是不可协商的？
    • 技术栈是否固定？是否有预算限制？时间线要求？
    • 是否必须遵循现有模式？
  3. 呈现已有方案 — 在构思前向用户展示Sibyl检索到的内容：
    "Sibyl找到3条相关记录：[项目Y中的模式X]、[上月的决策Z]、[注意事项W]。是否需要将这些纳入考虑？"

Gate

闸门

If Sibyl has a directly applicable pattern or decision, present it first. Don't re-brainstorm solved problems.
如果Sibyl中有直接适用的模式或决策，优先呈现。不要重复探索已解决的问题。

Phase 2: DIVERGE — Explore the Problem Space

阶段2：发散 — 探索问题空间

Goal: Generate breadth. Understand what we're actually solving.
目标： 拓展广度，明确我们实际要解决的问题。

Actions

行动

  1. Ask ONE question at a time to understand intent:
    • What's the friction/pain point?
    • Who benefits? How do they use it today?
    • What does success look like?
  2. Reframe the problem from multiple angles:
    • User perspective: "As a [user], I need..."
    • System perspective: "The system currently..."
    • Constraint perspective: "We're bounded by..."
  3. If the problem space is large, spawn parallel Explore agents:
    Agent 1: Research how similar projects solve this
Agent 2: Map the existing codebase surface area
Agent 3: Search for SOTA approaches (WebSearch)
  1. 每次只提一个问题以理解意图：
    • 存在哪些摩擦/痛点？
    • 谁会从中受益？他们当前的使用方式是怎样的？
    • 成功的标准是什么？
  2. 从多个角度重构问题：
    • 用户视角："作为[用户角色]，我需要..."
    • 系统视角："当前系统的情况是..."
    • 约束视角："我们受限于..."
  3. 如果问题空间较大，启动并行探索Agent：
    Agent 1: 研究类似项目的解决方案
Agent 2: 梳理现有代码库的涉及范围
Agent 3: 搜索SOTA方案（WebSearch）

Anti-patterns

反模式

  • Don't jump to solutions. This phase is about the PROBLEM.
  • Don't ask 5 questions at once. One at a time, build understanding.
  • Don't dismiss vague input — "make it faster" is valid; help sharpen it.
  • 不要直接跳到解决方案。本阶段聚焦于问题。
  • 不要一次性问5个问题。逐个提问，逐步建立理解。
  • 不要否定模糊的输入——“让它更快”是合理需求；帮助用户明确具体方向。

Phase 3: CONVERGE — Define the Core Problem

阶段3：收敛 — 定义核心问题

Goal: Narrow from exploration to a crisp problem statement.
目标： 从探索阶段过渡到清晰的问题陈述。

Actions

行动

  1. Synthesize what was explored into a 1-2 sentence problem statement
  2. Confirm with the user: "Is this what we're solving?"
  3. Identify scope boundaries — what's IN, what's OUT
  1. 整合探索结果，形成1-2句话的问题陈述
  2. 与用户确认："这是我们要解决的问题吗？"
  3. 明确范围边界 — 哪些属于范围内，哪些属于范围外

Output

输出

Problem: [crisp statement] In scope: [what we'll address] Out of scope: [what we won't] Key constraint: [the most important limiting factor]
问题： [清晰的陈述] 范围内： [我们将解决的内容] 范围外： [我们不会涉及的内容] 关键约束： [最重要的限制因素]

Phase 4: DIVERGE — Explore Solutions

阶段4：发散 — 探索解决方案

Goal: Generate multiple viable approaches. Quality through quantity.
目标： 生成多个可行方案。以量保质。

Actions

行动

  1. Present 2-3 approaches with explicit tradeoffs:
    ApproachProsConsComplexityRisk
    A: [name]......Low/Med/High...
    B: [name]......Low/Med/High...
    C: [name]......Low/Med/High...
  2. Include at least one unconventional option — break fixation on the obvious path
  3. Ground in existing patterns:
    • "This follows the pattern we used in [project X]"
    • "This diverges from our convention because [reason]"
  4. For each approach, name the verification method:
    • How would we know it works? (Test? Benchmark? Visual check?)
  1. 呈现2-3个方案并明确说明权衡：
    方案优势劣势复杂度风险
    A: [名称]......低/中/高...
    B: [名称]......低/中/高...
    C: [名称]......低/中/高...
  2. 至少包含一个非常规方案 — 避免局限于显而易见的路径
  3. 结合现有模式：
    • "此方案遵循了[项目X]中使用的模式"
    • "此方案偏离了我们的常规做法，原因是[具体理由]"
  4. 为每个方案指定验证方法：
    • 我们如何确认它有效？（测试？基准测试？视觉检查？）

Exploration vs Exploitation

探索与利用

Balance like MCTS — don't fixate on the first decent idea:
  • If all approaches look similar → push for a wild card option
  • If approaches are wildly different → good, that's healthy divergence
  • If the user gravitates early → present the contrarian case before converging
像MCTS一样平衡两者——不要局限于第一个不错的想法：
  • 如果所有方案看起来都相似 → 提出一个突破性方案
  • 如果方案差异极大 → 很好，这是健康的发散
  • 如果用户过早倾向于某个方案 → 在收敛前提出相反观点

Anti-patterns

反模式

  • Don't present 7 options. 2-3 is the sweet spot.
  • Don't present options without tradeoffs. Every option has a cost.
  • Don't present options that violate known constraints from Phase 1.
  • Don't default to the most complex solution. Start simple, add complexity only if justified.
  • 不要呈现7个方案。2-3个是最佳数量。
  • 不要呈现没有权衡的方案。每个方案都有成本。
  • 不要呈现违反阶段1中已知约束的方案。
  • 不要默认选择最复杂的方案。从简单开始，仅在有充分理由时增加复杂度。

Phase 5: CONVERGE — Decide and Record

阶段5：收敛 — 决策与记录

Goal: Lock in the approach. Record the decision. Exit to action.
目标： 确定方案，记录决策，转向行动。

Actions

行动

  1. Let the user choose. Present your recommendation but don't bulldoze.
  2. Record the decision in Sibyl:
    sibyl add "Brainstorm: [topic]" "Chose [approach] because [reason]. Rejected [other approaches] due to [tradeoffs]. Key constraint: [X]."
  3. Define next action — the brainstorm exits to whatever makes sense:
    Next StepWhen
    /hyperskills:plan
    		Complex feature needing decomposition
    /hyperskills:research
    		Need deeper investigation first
    /hyperskills:orchestrate
    		Ready to dispatch agents
    Direct implementationSimple enough to just build
    Write a specNeeds formal documentation
  1. 让用户选择。给出你的建议，但不要强制。
  2. 在Sibyl中记录决策：
    sibyl add "Brainstorm: [topic]" "Chose [approach] because [reason]. Rejected [other approaches] due to [tradeoffs]. Key constraint: [X]."
  3. 定义下一步行动 — 头脑风暴结束后转向合适的环节：
    下一步适用场景
    /hyperskills:plan
    		需要分解的复杂功能
    /hyperskills:research
    		需先进行深入调研
    /hyperskills:orchestrate
    		准备好调度Agent
    直接实现足够简单可直接构建
    编写规格文档需要正式文档记录

Output

输出

Decision: [what we're doing] Approach: [which option, brief description] Why: [1-2 sentences on the reasoning] Next: [the immediate next action]
决策： [我们要做的事情] 方案： [所选选项的简要描述] 理由： [1-2句话说明原因] 下一步： [立即要执行的行动]

Quick Mode

快速模式

For small decisions that don't need the full diamond:
  1. Search Sibyl (always)
  2. Present 2 options with tradeoffs (skip problem exploration)
  3. Decide and record
Use quick mode when: The problem is already well-understood and the user just needs help choosing between known options.
对于不需要完整Double Diamond流程的小型决策：
  1. 检索Sibyl（始终执行）
  2. 呈现2个带权衡的方案（跳过问题探索阶段）
  3. 决策与记录
适用场景： 问题已明确，用户仅需在已知选项中做出选择。

Multi-Agent Brainstorming

多Agent头脑风暴

For complex architectural decisions, deploy a Council pattern:
Agent 1 (Advocate): Makes the strongest case FOR approach A
Agent 2 (Advocate): Makes the strongest case FOR approach B
Agent 3 (Critic): Finds flaws in BOTH approaches
Synthesize their outputs, then present the unified analysis to the user.
When to use: Architecture decisions affecting 3+ systems, technology selection, major refactors. Don't use for simple feature design.
对于复杂的架构决策，采用委员会模式：
Agent 1（支持者）：为方案A提出最有力的论据
Agent 2（支持者）：为方案B提出最有力的论据
Agent 3（批评者）：找出两个方案的缺陷
整合他们的输出，然后向用户呈现统一的分析结果。
适用场景： 影响3个以上系统的架构决策、技术选型、重大重构。不要用于简单的功能设计。

What This Skill is NOT

本Skill不包含以下内容

  • Not a gate. You don't need permission to skip phases. If the user says "just build it," build it.
  • Not a waterfall. Phases can revisit. New information in Phase 4 can send you back to Phase 2.
  • Not a document generator. The output is a decision, not a design doc (unless the user wants one).
  • Not required for everything. Bug fixes, typo corrections, and clear-spec features don't need brainstorming.
  • 不是闸门。无需获得许可即可跳过阶段。如果用户说“直接构建”，就直接构建。
  • 不是瀑布模型。阶段可以回溯。阶段4中的新信息可能会让你回到阶段2。
  • 不是文档生成器。输出是决策，不是设计文档（除非用户要求）。
  • 并非所有场景都需要。 bug修复、拼写纠正、规格明确的功能不需要头脑风暴。

YAGNI Check

YAGNI检查

Before concluding, ask: "Is there anything in this plan we don't actually need yet?" Strip it. Build the minimum that validates the approach.
结束前，询问：“此计划中是否有我们目前实际上不需要的内容？” 去掉这些内容。构建验证方案所需的最小版本。