Back to Details

simple

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fun Brainstorming

趣味头脑风暴

Uh oh...
A structured yet lightweight brainstorming skill designed to move from idea to actionable direction quickly. It preserves the rigor of collaborative design — exploring intent, evaluating trade-offs, and validating decisions — while eliminating process overhead that doesn't scale to small and medium tasks.
The goal is simple: understand what the user wants, think through the options together, pick a direction, and get moving. No multi-phase rituals, no mandatory design documents, no endless rounds of clarification. Just enough structure to make good decisions, and nothing more.
Uh oh...
这是一套结构化但轻量化的头脑风暴skill，旨在快速从想法推进到可执行方向。它保留了协作设计的严谨性——探索意图、评估权衡、验证决策——同时消除了不适用于中小型任务的流程开销。
目标非常简单：理解用户需求，共同梳理可选方案，选定方向后开始推进。无需多阶段的固定流程，无需强制输出设计文档，也无需无休止的沟通确认。仅提供足以支撑做出正确决策的流程结构，没有多余环节。

Ground Rules

基本规则

Do NOT write any code, scaffold any files, or take any implementation action until the user has explicitly approved a direction. This applies even when the task seems obvious. The whole point of brainstorming is to pause and think before building. Respect that boundary.
在用户明确批准方向之前，请勿编写任何代码、搭建任何文件框架或采取任何落地动作。即便任务看起来非常明确也需要遵守这一规则。头脑风暴的核心意义在于动手构建前先停下来思考，请遵守这一界限。

Process Flow

流程

dot
digraph fun_brainstorm {
    rankdir=TB
    node [shape=box style=rounded]

    Discover -> Propose
    Propose -> Converge
    Converge -> Approved [label="yes"]
    Converge -> Propose [label="no (max 2x)"]
    Approved [shape=diamond]
    Approved -> Capture
    Capture -> Implement
}
  • Discover — Assess project context — codebase, conventions, existing patterns. Ask up to 3 focused questions (prefer multiple-choice) to clarify intent, constraints, and success criteria. Batch related questions together. If the request is already clear, skip straight to proposing.
  • Propose — Present 2 approaches with trade-offs. Lead with your recommendation and say why. Keep each option to a short paragraph. Scale detail to the task — a few sentences for simple work, more reasoning for complex decisions.
  • Converge — Get explicit user approval. If rejected, revise and repropose — max 2 rounds. If still not aligned, ask the user to state what they want directly. A good-enough direction chosen quickly beats a perfect one chosen slowly.
  • Capture — Record the chosen direction (what, why, key decisions) as an inline comment in the first file you create, or share it in chat. No separate design doc unless the user asks for one.
dot
digraph fun_brainstorm {
    rankdir=TB
    node [shape=box style=rounded]

    Discover -> Propose
    Propose -> Converge
    Converge -> Approved [label="yes"]
    Converge -> Propose [label="no (max 2x)"]
    Approved [shape=diamond]
    Approved -> Capture
    Capture -> Implement
}
  • Discover（需求调研） —— 评估项目上下文：代码库、规范、现有模式。最多提出3个针对性问题（优先选择题形式）来明确需求意图、约束条件和成功标准。将相关问题合并提出。如果需求已经非常清晰，可以直接进入方案提议环节。
  • Propose（方案提议） —— 给出2种带有权衡分析的实现方案，优先说明你的推荐方案及理由。每个方案用简短的段落描述即可。根据任务量级调整细节丰富度：简单任务几句话说明即可，复杂决策可提供更多论证。
  • Converge（方案收敛） —— 获得用户的明确批准。如果方案被驳回，修改后重新提议，最多2轮。如果仍然无法达成一致，请用户直接说明其需求。快速选定一个足够好的方向，远好于缓慢选出一个完美的方向。
  • Capture（记录留存） —— 将选定的方向（内容、原因、关键决策）作为内联注释记录在你创建的第一个文件中，或者在聊天中共享。除非用户要求，否则不需要单独的设计文档。

Principles

原则

  • Speed over ceremony — The value of brainstorming is in the thinking, not in the artifacts it produces. Skip formality wherever it doesn't add real value. A quick conversation that leads to a good decision is better than a polished document that delays one.
  • YAGNI — Design only for what's needed right now. Don't introduce abstractions, extension points, or flexibility for requirements that don't exist yet. If they come up later, you can handle them then. Speculative design creates more problems than it solves.
  • Bias toward action — When two options are close in quality, just pick one and go. Spending extra time trying to find the theoretically optimal choice almost never pays off. Movement creates clarity. You'll learn more from building than from deliberating.
  • Batched discovery — Ask your clarifying questions together, not one at a time across multiple messages. Drawn-out discovery wastes the user's time and breaks their flow. Get what you need in one round and move forward.
  • Proportional depth — Match the weight of the process to the weight of the task. A small bug fix or config change might go through steps 1 and 2 in a single message. A new subsystem deserves a more thorough exploration in step 2. Let the complexity of the work guide the complexity of the conversation.
  • 速度优先于形式 —— 头脑风暴的价值在于思考过程，而非产出的文档。只要不产生实际价值，就跳过所有形式化环节。一次能促成正确决策的简短沟通，远好于一份会延误决策的精美文档。
  • YAGNI —— 仅针对当前实际需求做设计。不要为不存在的需求引入抽象、扩展点或灵活性。如果后续出现这类需求，到时再处理即可。推测性设计带来的问题远多于它解决的问题。
  • 行动导向 —— 当两个方案质量相近时，直接选择一个开始推进。花费额外时间寻找理论上的最优选择几乎永远不会有相应回报。行动会带来清晰的认知，你从构建过程中学到的东西远多于反复论证。
  • 批量调研 —— 将需要澄清的问题合并提出，不要分多条消息单次发送一个问题。冗长的调研会浪费用户时间，打断他们的工作节奏。一次性获取你需要的所有信息后就推进下一步。
  • 深度适配 —— 流程的复杂度要和任务的重要程度匹配。小的bug修复或配置变更可能在一条消息里就完成前两个步骤，新的子系统则值得在方案提议阶段做更全面的探索。根据工作的复杂度调整沟通的复杂度。