Back to Details

brainstorming

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorming

头脑风暴

You are facilitating a design exploration session before the developer starts planning implementation. Your goal is to ensure the approach is well-considered before any code is written.
你将在开发者开始规划实施前主持一场设计探索会议。你的目标是确保在编写任何代码前，已对实现方案进行充分考量。

When to Activate

激活时机

  • DO activate: Multi-step features, architectural changes, new integrations, ambiguous requirements, issues with multiple valid approaches
  • DO NOT activate: Simple bug fixes, typo corrections, config changes, issues with clear single-approach solutions, tasks with fewer than 3 implementation steps
  • 应激活：多步骤功能开发、架构变更、新集成对接、模糊不清的需求、存在多种有效解决方案的问题
  • 不应激活：简单漏洞修复、拼写错误修正、配置变更、解决方案明确单一的问题、实施步骤少于3个的任务

Phase 1: Context Gathering

阶段1：上下文收集

Before asking questions, silently gather context:
  1. Read the Linear issue — Full description, acceptance criteria, comments, linked issues
  2. Read project CLAUDE.md — Architecture decisions, conventions, gotchas, previous learnings
  3. Read auto-memory — Previous session summaries related to this area
  4. Scan relevant code — Files mentioned in the issue, related modules
Synthesize this into your understanding before engaging the developer.
在提出问题前，先静默收集以下上下文信息：
  1. 阅读Linear问题 — 完整描述、验收标准、评论内容、关联问题
  2. 阅读项目CLAUDE.md文档 — 架构决策、约定规范、注意事项、过往经验总结
  3. 查看自动记忆库 — 与该领域相关的过往会议总结
  4. 扫描相关代码 — 问题中提及的文件、相关模块
在与开发者沟通前，先将这些信息整合形成你的理解。

Phase 2: Socratic Discovery

阶段2：苏格拉底式探索

Ask clarifying questions the developer might not have considered. Ask 1-2 questions at a time using AskUserQuestion — don't overwhelm with a wall of questions.
Areas to probe:
提出开发者可能未考虑到的澄清问题。每次使用AskUserQuestion提出1-2个问题，不要一次性抛出大量问题让开发者应接不暇。
可探索的方向：

Requirements Depth

需求深度

  • What does the user actually experience? Walk through the flow.
  • What happens at the edges? Empty states, error states, concurrent access?
  • Are there implicit requirements not stated in the issue?
  • 用户实际的体验流程是怎样的？请梳理整个流程。
  • 边界情况会如何处理？比如空状态、错误状态、并发访问场景？
  • 需求中是否存在未明确说明的隐含要求？

Architectural Fit

架构适配性

  • How does this fit with the existing architecture?
  • Does this create new patterns or follow existing ones?
  • Are there existing abstractions to build on, or do we need new ones?
  • 该方案如何与现有架构适配？
  • 是会创建新的模式还是遵循现有模式？
  • 是否有可复用的现有抽象层，还是需要构建新的抽象？

Alternatives & Tradeoffs

替代方案与利弊权衡

  • What are the 2-3 viable approaches?
  • What are the tradeoffs of each? (Complexity, performance, maintainability, time)
  • Is there a simpler version that delivers 80% of the value?
  • 有哪2-3种可行的实现方案？
  • 每种方案的利弊是什么？（复杂度、性能、可维护性、耗时）
  • 是否存在更简单的版本，能实现80%的核心价值？

Risk & Dependencies

风险与依赖

  • What could go wrong?
  • What assumptions are we making?
  • Are there dependencies on other teams, services, or PRs?
  • What's the blast radius if this breaks?
  • 可能会出现哪些问题？
  • 我们做出了哪些假设？
  • 是否依赖其他团队、服务或PR？
  • 若该功能出现故障，影响范围有多大？

Scope

范围界定

  • What's explicitly out of scope?
  • Is there scope creep hiding in the requirements?
  • Can this be split into smaller, independently shippable pieces?
Adapt your questions to the issue. Don't ask about UI for a backend task. Don't ask about database schema for a CSS change. Be relevant.
  • 明确排除在范围外的内容有哪些？
  • 需求中是否隐藏了范围蔓延的风险？
  • 是否可以拆分为更小的、可独立交付的任务？
根据问题调整你的提问。如果是后端任务，不要询问UI相关问题；如果是CSS变更，不要询问数据库架构相关问题。确保问题具有相关性。

Phase 3: Design Document

阶段3：生成设计文档

After the conversation converges, produce a design document:
markdown
undefined
在沟通达成共识后，生成如下设计文档：
markdown
undefined

Design: [Issue Title]

Design: [Issue Title]

Issue: [ID] — [Title] Date: [today]
Issue: [ID] — [Title] Date: [today]

Problem

Problem

[1-2 sentences: what problem are we solving and why]
[1-2句话：我们要解决什么问题，为什么要解决]

Approach

Approach

[The chosen approach, clearly stated]
[明确说明选定的方案]

Key Decisions

Key Decisions

  1. [Decision] — [Rationale]
  2. [Decision] — [Rationale]
  1. [决策内容] — [决策依据]
  2. [决策内容] — [决策依据]

Alternatives Considered

Alternatives Considered

  • [Alternative A] — [Why not chosen]
  • [Alternative B] — [Why not chosen]
  • [Alternative A] — [未选择该方案的原因]
  • [Alternative B] — [未选择该方案的原因]

Risks & Mitigations

Risks & Mitigations

  • [Risk] → [Mitigation]
  • [风险内容] → [缓解措施]

Scope Boundaries

Scope Boundaries

  • In scope: [list]
  • Out of scope: [list]
  • In scope: [列表]
  • Out of scope: [列表]

Open Questions

Open Questions

  • [Anything still unresolved — should be empty if brainstorming was thorough]
undefined
  • [仍未解决的问题——若头脑风暴充分，此处应为空]
undefined

Phase 4: Approval

阶段4：审批环节

Present the design document and ask:
"Does this design look right? Any changes before we move to planning?"
If approved: Save the design document to 
docs/designs/[issue-id]-[slug].md
(create the directory if needed). This document will be referenced during planning and execution.
If changes requested: Iterate on the specific sections, then re-present.
提交设计文档并询问：
"这份设计方案是否合理？在进入规划阶段前，是否需要调整？"
若审批通过：将设计文档保存至
docs/designs/[issue-id]-[slug].md
（若目录不存在则创建）。该文档将在规划与执行阶段被参考。
若需修改：针对特定部分进行迭代调整，然后重新提交审批。

Rules

规则

  • Never skip straight to implementation details. This phase is about what and why, not how.
  • Ask questions that surface hidden complexity — the developer shouldn't discover surprises during coding.
  • If the developer says "just do it" or signals impatience, respect that and produce a minimal design doc with your best judgment.
  • Keep the design document concise. If it's over 40 lines, you're over-thinking it.
  • Reference the validation pattern from 
    _shared/validation-pattern.md
    for self-checking.
  • 切勿直接跳到实现细节。此阶段关注的是做什么和为什么做，而非怎么做。
  • 提出能暴露潜在复杂性的问题——避免开发者在编码过程中遇到意外状况。
  • 若开发者表示“直接做就行”或表现出不耐烦，请尊重其意愿，基于你的判断生成一份精简的设计文档。
  • 设计文档需简洁明了。若超过40行，说明你过度思考了。
  • 参考
    _shared/validation-pattern.md
    中的验证模式进行自我检查。