Back to Details

brainstorming

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorming

头脑风暴

This skill provides detailed process knowledge for effective brainstorming sessions that clarify WHAT to build before diving into HOW to build it.
该Skill为有效的头脑风暴会议提供详细的流程指导，帮助在深入研究如何构建之前明确要构建什么。

When to Use This Skill

何时使用该Skill

Brainstorming is valuable when:
  • Requirements are unclear or ambiguous
  • Multiple approaches could solve the problem
  • Trade-offs need to be explored with the user
  • The user hasn't fully articulated what they want
  • The feature scope needs refinement
Brainstorming can be skipped when:
  • Requirements are explicit and detailed
  • The user knows exactly what they want
  • The task is a straightforward bug fix or well-defined change
在以下场景中，头脑风暴非常有价值：
  • 需求模糊或不明确时
  • 存在多种可行的问题解决方案时
  • 需要与用户探讨取舍权衡时
  • 用户尚未清晰表达其需求时
  • 需要细化功能范围时
在以下场景中可跳过头脑风暴：
  • 需求明确且详细时
  • 用户清楚知道自己想要什么时
  • 任务是简单的bug修复或定义明确的变更时

Core Process

核心流程

Phase 0: Assess Requirement Clarity

阶段0：评估需求清晰度

Before diving into questions, assess whether brainstorming is needed.
Signals that requirements are clear:
  • User provided specific acceptance criteria
  • User referenced existing patterns to follow
  • User described exact behavior expected
  • Scope is constrained and well-defined
Signals that brainstorming is needed:
  • User used vague terms ("make it better", "add something like")
  • Multiple reasonable interpretations exist
  • Trade-offs haven't been discussed
  • User seems unsure about the approach
If requirements are clear, suggest: "Your requirements seem clear. Consider proceeding directly to planning or implementation."
在提出问题之前，先评估是否需要进行头脑风暴。
需求明确的信号：
  • 用户提供了具体的验收标准
  • 用户参考了现有可遵循的模式
  • 用户描述了期望的精确行为
  • 范围受限且定义清晰
需要头脑风暴的信号：
  • 用户使用了模糊的表述（如“让它更好”、“添加类似的功能”）
  • 存在多种合理的解读
  • 尚未讨论取舍权衡
  • 用户似乎对实现方法不确定
如果需求明确，建议：“你的需求看起来很清晰，可以直接进入规划或实现阶段。”

Phase 1: Understand the Idea

阶段1：理解需求意图

Ask questions one at a time to understand the user's intent. Avoid overwhelming with multiple questions.
Question Techniques:
  1. Prefer multiple choice when natural options exist
    • Good: "Should the notification be: (a) email only, (b) in-app only, or (c) both?"
    • Avoid: "How should users be notified?"
  2. Start broad, then narrow
    • First: What is the core purpose?
    • Then: Who are the users?
    • Finally: What constraints exist?
  3. Validate assumptions explicitly
    • "I'm assuming users will be logged in. Is that correct?"
  4. Ask about success criteria early
    • "How will you know this feature is working well?"
Key Topics to Explore:
TopicExample Questions
PurposeWhat problem does this solve? What's the motivation?
UsersWho uses this? What's their context?
ConstraintsAny technical limitations? Timeline? Dependencies?
SuccessHow will you measure success? What's the happy path?
Edge CasesWhat shouldn't happen? Any error states to consider?
Existing PatternsAre there similar features in the codebase to follow?
Exit Condition: Continue until the idea is clear OR user says "proceed" or "let's move on"
一次只提一个问题，以理解用户的意图。避免同时提出多个问题让用户不知所措。
提问技巧：
  1. 当存在自然选项时，优先使用选择题
    • 示例：“通知方式应该是：(a)仅邮件，(b)仅应用内，还是(c)两者兼具？”
    • 避免：“用户应该如何收到通知？”
  2. 从宽泛到具体
    • 首先：核心目的是什么？
    • 然后：目标用户是谁？
    • 最后：存在哪些约束条件？
  3. 明确验证假设
    • “我假设用户需要登录才能使用，对吗？”
  4. 尽早询问成功标准
    • “你如何判断这个功能运行良好？”
需要探索的关键主题：
主题示例问题
目的这能解决什么问题？动机是什么？
用户谁会使用这个功能？他们的使用场景是什么？
约束条件有哪些技术限制？时间线？依赖项？
成功标准如何衡量成功？理想路径是什么？
边缘情况哪些情况不应该发生？需要考虑哪些错误状态？
现有模式代码库中是否有可遵循的类似功能？
退出条件： 持续提问直到需求意图清晰，或用户表示“继续”或“我们推进下一步”

Phase 2: Explore Approaches

阶段2：探索实现方案

After understanding the idea, propose 2-3 concrete approaches.
Structure for Each Approach:
markdown
undefined
在理解需求意图后，提出2-3种具体的实现方案。
每个方案的结构：
markdown
undefined

Approach A: [Name]

方案A：[名称]

[2-3 sentence description]
Pros:
  • [Benefit 1]
  • [Benefit 2]
Cons:
  • [Drawback 1]
  • [Drawback 2]
Best when: [Circumstances where this approach shines]

**Guidelines:**
- Lead with a recommendation and explain why
- Be honest about trade-offs
- Consider YAGNI—simpler is usually better
- Reference codebase patterns when relevant
[2-3句话描述]
优点：
  • [优势1]
  • [优势2]
缺点：
  • [劣势1]
  • [劣势2]
适用场景： [该方案最适用的情况]

**指导原则：**
- 优先给出推荐方案并解释原因
- 坦诚说明取舍权衡
- 考虑YAGNI原则——通常越简单越好
- 相关时参考代码库中的现有模式

Phase 3: Capture the Design

阶段3：记录设计决策

Summarize key decisions in a structured format.
Design Doc Structure:
markdown
---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---
以结构化格式总结关键决策。
设计文档结构：
markdown
---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---

<Topic Title>

<主题标题>

What We're Building

我们要构建什么

[Concise description—1-2 paragraphs max]
[简洁描述——最多1-2段]

Why This Approach

选择该方案的原因

[Brief explanation of approaches considered and why this one was chosen]
[简要说明考虑过的方案以及选择此方案的理由]

Key Decisions

关键决策

  • [决策1]：[理由]
  • [决策2]：[理由]

Open Questions

未解决问题

  • [Any unresolved questions for the planning phase]
  • [规划阶段需要解决的未决问题]

Next Steps

下一步

→ 
/workflows:plan
for implementation details

**Output Location:** `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`
→ 
/workflows:plan
获取实现细节

**输出位置：** `docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md`

Phase 4: Handoff

阶段4：交接

Present clear options for what to do next:
  1. Proceed to planning → Run 
    /workflows:plan
  2. Refine further → Continue exploring the design
  3. Done for now → User will return later
为下一步行动提供明确的选项：
  1. 进入规划阶段 → 运行 
    /workflows:plan
  2. 进一步细化 → 继续探索设计
  3. 暂时结束 → 用户稍后再返回

YAGNI Principles

YAGNI原则

During brainstorming, actively resist complexity:
  • Don't design for hypothetical future requirements
  • Choose the simplest approach that solves the stated problem
  • Prefer boring, proven patterns over clever solutions
  • Ask "Do we really need this?" when complexity emerges
  • Defer decisions that don't need to be made now
在头脑风暴过程中，主动抵制复杂性：
  • 不要为假设的未来需求做设计
  • 选择能解决当前问题的最简单方案
  • 优先选择成熟、经过验证的模式，而非巧妙但复杂的解决方案
  • 当出现复杂性时，问自己“我们真的需要这个吗？”
  • 推迟不需要立即做出的决策

Incremental Validation

增量验证

Keep sections short—200-300 words maximum. After each section of output, pause to validate understanding:
  • "Does this match what you had in mind?"
  • "Any adjustments before we continue?"
  • "Is this the direction you want to go?"
This prevents wasted effort on misaligned designs.
保持内容简短——每部分最多200-300字。在输出每一部分后，暂停以验证用户的理解：
  • “这和你想的一致吗？”
  • “在继续之前需要调整什么吗？”
  • “这是你想要的方向吗？”
这能避免在偏离用户预期的设计上浪费精力。

Anti-Patterns to Avoid

需要避免的反模式

Anti-PatternBetter Approach
Asking 5 questions at onceAsk one at a time
Jumping to implementation detailsStay focused on WHAT, not HOW
Proposing overly complex solutionsStart simple, add complexity only if needed
Ignoring existing codebase patternsResearch what exists first
Making assumptions without validatingState assumptions explicitly and confirm
Creating lengthy design documentsKeep it concise—details go in the plan
反模式更好的做法
同时提出5个问题一次只提一个问题
直接跳到实现细节专注于“要构建什么”，而非“如何构建”
提出过于复杂的解决方案从简单开始，仅在需要时增加复杂性
忽略代码库中的现有模式先研究已有的内容
未验证就做出假设明确说明假设并确认
创建冗长的设计文档保持简洁——细节放在规划文档中

Integration with Planning

与规划流程的集成

Brainstorming answers WHAT to build:
  • Requirements and acceptance criteria
  • Chosen approach and rationale
  • Key decisions and trade-offs
Planning answers HOW to build it:
  • Implementation steps and file changes
  • Technical details and code patterns
  • Testing strategy and verification
When brainstorm output exists, 
/workflows:plan
should detect it and use it as input, skipping its own idea refinement phase.
头脑风暴回答要构建什么：
  • 需求和验收标准
  • 选定的方案及理由
  • 关键决策和取舍权衡
规划流程回答如何构建：
  • 实现步骤和文件变更
  • 技术细节和代码模式
  • 测试策略和验证方法
当存在头脑风暴输出时，
/workflows:plan
应自动识别并将其作为输入，跳过自身的需求细化阶段。