brainstorming
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseBrainstorming Ideas Into Designs
将想法头脑风暴转化为设计方案
Overview
概述
Brainstorming transforms vague ideas into validated designs through structured collaborative dialogue. It bridges the gap between "I want X" and a concrete design that can be handed to the planning skill. This enhanced version integrates with the self-learning skill to build on known project context and avoid re-asking previously answered questions.
Announce at start: "I'm using the brainstorming skill to explore this idea and create a design before implementation."
头脑风暴通过结构化的协作对话，将模糊的想法转化为经过验证的设计。它填补了“我想要X”和可以交给planning skill的具体设计之间的空白。这个增强版本与self-learning skill集成，基于已知的项目上下文开展工作，避免重复询问之前已经回答过的问题。
开始时请说明： "I'm using the brainstorming skill to explore this idea and create a design before implementation."
Trigger Conditions
触发条件
- User describes a new feature idea or goal
- User asks "how should we build X?"
- Creative work requires design exploration before planning
- command invoked
/brainstorm - Transition from a vague requirement to structured design is needed
- 用户描述新的功能想法或目标
- 用户询问“我们应该如何构建X？”
- 创意工作在规划前需要进行设计探索
- 命令被调用
/brainstorm - 需要将模糊的需求转化为结构化设计
Phase 1: Context Loading
阶段1：上下文加载
Goal: Load everything known about the project before asking the user anything.
- Check memory files (,
project-context.md,learned-patterns.md) for known patterns, stack, and conventionsdecisions-log.md - Read relevant existing code, docs, and recent commits
- Review existing designs in for related prior work
docs/plans/ - Identify constraints from the existing architecture
- Note what you already know — do NOT re-ask the user for information you can discover
目标： 在询问用户任何问题之前，先加载所有已知的项目相关信息。
- 检查内存文件（、
project-context.md、learned-patterns.md），获取已知的模式、技术栈和规范decisions-log.md - 阅读相关的现有代码、文档和最近的提交记录
- 查看中的现有设计，了解相关的前期工作
docs/plans/ - 识别现有架构带来的约束
- 记录你已经知道的信息——绝对不要重复询问用户你可以自行查到的信息
Context Sources Priority
上下文来源优先级
| Source | What to Extract | Priority |
|---|---|---|
| Memory files | Stack, conventions, past decisions | Highest |
| CLAUDE.md | Project structure, hard gates | High |
| Existing code | Current patterns, architecture | High |
| Recent commits | Direction of development | Medium |
| docs/plans/ | Prior designs and decisions | Medium |
STOP — Do NOT proceed to Phase 2 until:
- Memory files have been checked
- Relevant codebase areas have been explored
- You can summarize what you already know about this domain
| 来源 | 提取内容 | 优先级 |
|---|---|---|
| 内存文件 | 技术栈、规范、过往决策 | 最高 |
| CLAUDE.md | 项目结构、硬性限制 | 高 |
| 现有代码 | 当前模式、架构 | 高 |
| 最近提交 | 开发方向 | 中 |
| docs/plans/ | 前期设计和决策 | 中 |
停止 —— 在满足以下条件前，不要进入阶段2：
- 已经检查过内存文件
- 已经探索过相关的代码库区域
- 你可以总结你对这个领域已经了解的内容
Phase 2: Idea Exploration
阶段2：想法探索
Goal: Understand the user's intent through focused, one-at-a-time questions.
- Ask ONE question per message — never multiple questions
- Prefer multiple choice questions when possible
- Focus on understanding purpose, constraints, and success criteria
- Build on context loaded in Phase 1 — skip questions you can already answer
- Convert vague answers into specific, testable criteria
目标： 通过有针对性的、逐个提问的方式理解用户意图。
- 每条消息只问一个问题——永远不要同时问多个问题
- 尽可能使用选择题的形式
- 重点关注理解目的、约束和成功标准
- 基于阶段1加载的上下文提问——跳过你已经知道答案的问题
- 将模糊的回答转化为具体的、可测试的标准
Question Flow Decision Table
提问流程决策表
| What You Need to Know | Question Type | Example |
|---|---|---|
| Core purpose | Open-ended | "What problem does this solve for the user?" |
| Scope boundaries | Multiple choice | "Should this handle: (A) only logged-in users, (B) all users, (C) depends on role?" |
| Technical constraints | Yes/No + follow-up | "Does this need to work offline?" |
| Priority trade-offs | Forced ranking | "Rank these: speed, correctness, simplicity" |
| Success criteria | Measurable target | "What does 'working' look like? Can you describe the happy path?" |
| Non-goals | Explicit exclusion | "What should we explicitly NOT build in this iteration?" |
| 需要了解的内容 | 问题类型 | 示例 |
|---|---|---|
| 核心用途 | 开放式问题 | "What problem does this solve for the user?" |
| 范围边界 | 选择题 | "Should this handle: (A) only logged-in users, (B) all users, (C) depends on role?" |
| 技术约束 | 是/否+后续追问 | "Does this need to work offline?" |
| 优先级权衡 | 强制排序 | "Rank these: speed, correctness, simplicity" |
| 成功标准 | 可衡量的目标 | "What does 'working' look like? Can you describe the happy path?" |
| 非目标 | 明确排除项 | "What should we explicitly NOT build in this iteration?" |
Question Rules
提问规则
| Rule | Rationale |
|---|---|
| One question per message | Prevents cognitive overload |
| Multiple choice preferred | Faster to answer, reduces ambiguity |
| Research before asking | Respect user's time |
| Build on memory | Do not re-ask known things |
| Testable outcomes | Vague success criteria lead to vague designs |
STOP — Do NOT proceed to Phase 3 until:
- You understand the core purpose and who it serves
- You know the constraints (technical, timeline, scope)
- You have identified success criteria and non-goals
- No critical ambiguities remain about intent
| 规则 | 原因 |
|---|---|
| 每条消息只提一个问题 | 避免认知负担 |
| 优先使用选择题 | 回答速度更快，减少歧义 |
| 提问前先调研 | 尊重用户的时间 |
| 基于已有记忆提问 | 不要重复询问已知的内容 |
| 可测试的结果 | 模糊的成功标准会导致模糊的设计 |
停止 —— 满足以下条件前不要进入阶段3：
- 你理解了核心用途和面向的用户群体
- 你知道所有约束（技术、时间线、范围）
- 你已经明确了成功标准和非目标
- 意图方面没有遗留的关键歧义
Phase 3: Approach Exploration
阶段3：方案探索
Goal: Propose 2-3 distinct approaches with trade-offs and a clear recommendation.
For each approach, present:
| Section | Content |
|---|---|
| Name | Short descriptive label |
| Architecture summary | 2-3 sentences |
| Key trade-offs | Pros and cons |
| Complexity | Low / Medium / High |
| Risk | What could go wrong |
| Your assessment | Why you do or do not recommend it |
目标： 提出2-3种不同的方案，说明各自的权衡，并给出明确的推荐。
对于每个方案，需要包含以下内容：
| 模块 | 内容 |
|---|---|
| 名称 | 简短的描述性标签 |
| 架构概要 | 2-3句话 |
| 核心权衡 | 优缺点 |
| 复杂度 | 低 / 中 / 高 |
| 风险 | 可能出现的问题 |
| 你的评估 | 你推荐或不推荐这个方案的原因 |
Approach Comparison Template
方案对比模板
undefinedundefinedApproach A: [Name] (Recommended)
Approach A: [Name] (Recommended)
Summary: [2-3 sentences]
Pros: [list]
Cons: [list]
Complexity: [Low/Medium/High]
Risk: [What could go wrong]
Why recommended: [1-2 sentences]
Summary: [2-3 sentences]
Pros: [list]
Cons: [list]
Complexity: [Low/Medium/High]
Risk: [What could go wrong]
Why recommended: [1-2 sentences]
Approach B: [Name]
Approach B: [Name]
...
...
Approach C: [Name] (if needed)
Approach C: [Name] (if needed)
...
**Lead with your recommended approach** and explain why it is the best fit given the constraints discussed in Phase 2.
**STOP — Do NOT proceed to Phase 4 until:**
- [ ] You have proposed at least 2 approaches
- [ ] Each approach has explicit trade-offs
- [ ] You have made a clear recommendation
- [ ] User has indicated which approach to pursue
---...
**优先展示你推荐的方案**，并说明基于阶段2讨论的约束，为什么它是最合适的选择。
**停止 —— 满足以下条件前不要进入阶段4：**
- [ ] 你已经提出了至少2种方案
- [ ] 每个方案都有明确的权衡说明
- [ ] 你已经给出了清晰的推荐
- [ ] 用户已经指明要采用哪个方案
---Phase 4: Design Presentation
阶段4：设计展示
Goal: Present the detailed design in sections, getting approval incrementally.
- Present the design in logical sections scaled to complexity
- Ask after each section whether it looks right so far
- Be ready to go back and revise any section based on feedback
- Cover all relevant design dimensions
目标： 分模块展示详细设计，逐步获得认可。
- 根据复杂度将设计拆分为逻辑模块进行展示
- 每个模块展示后询问用户目前的内容是否合理
- 随时准备根据反馈回溯修改任何模块
- 覆盖所有相关的设计维度
Design Sections by Complexity
按复杂度划分的设计模块
| Complexity | Required Sections | Optional Sections |
|---|---|---|
| Simple (1-3 tasks) | Architecture, Components | — |
| Medium (4-10 tasks) | Architecture, Components, Data Flow, Error Handling | Testing Strategy |
| Complex (10+ tasks) | Architecture, Components, Data Flow, Error Handling, Testing Strategy, Performance, Security | Migration Plan |
| 复杂度 | 必填模块 | 可选模块 |
|---|---|---|
| 简单（1-3个任务） | 架构、组件 | — |
| 中等（4-10个任务） | 架构、组件、数据流、错误处理 | 测试策略 |
| 复杂（10个以上任务） | 架构、组件、数据流、错误处理、测试策略、性能、安全 | 迁移方案 |
Section Presentation Order
模块展示顺序
- Architecture — High-level structure and key decisions
- Components — What pieces exist and how they relate
- Data Flow — How data moves through the system
- Error Handling — What can go wrong and how to handle it
- Testing Strategy — How to verify correctness
- Performance — Only if relevant constraints exist
- Security — Only if handling sensitive data or auth
Present one section at a time. Wait for user confirmation before proceeding.
STOP — Do NOT proceed to Phase 5 until:
- All relevant design sections have been presented
- User has approved each section (or revisions were made)
- The complete design is coherent and addresses all requirements
- 架构 —— 高层结构和关键决策
- 组件 —— 存在哪些模块以及它们之间的关系
- 数据流 —— 数据如何在系统中流转
- 错误处理 —— 可能出现哪些问题以及如何处理
- 测试策略 —— 如何验证正确性
- 性能 —— 仅当存在相关约束时需要
- 安全 —— 仅当处理敏感数据或鉴权时需要
每次展示一个模块，获得用户确认后再继续。
停止 —— 满足以下条件前不要进入阶段5：
- 所有相关的设计模块都已经展示完毕
- 用户已经认可每个模块（或已完成修改）
- 完整的设计逻辑自洽，且满足所有需求
Phase 5: Documentation and Transition
阶段5：文档沉淀与交接
Goal: Persist the design and hand off to the planning skill.
- Write the validated design to
docs/plans/YYYY-MM-DD-<topic>-design.md - Commit the design document
- Update self-learning memory:
- — any architectural decisions made
memory/decisions-log.md - — any new conventions discussed
memory/learned-patterns.md
- Invoke the skill to create a detailed implementation plan
planning
目标： 留存设计内容，并交接给planning skill。
- 将经过验证的设计写入
docs/plans/YYYY-MM-DD-<topic>-design.md - 提交设计文档
- 更新自学习内存：
- —— 所有做出的架构决策
memory/decisions-log.md - —— 所有讨论过的新规范
memory/learned-patterns.md
- 调用skill生成详细的落地实现计划
planning
Design Document Template
设计文档模板
markdown
undefinedmarkdown
undefined[Topic] Design Document
[Topic] Design Document
Date: YYYY-MM-DD
Status: Approved
Approach: [Which approach was chosen]
Date: YYYY-MM-DD
Status: Approved
Approach: [Which approach was chosen]
Problem Statement
Problem Statement
[What problem this solves and for whom]
[What problem this solves and for whom]
Design
Design
Architecture
Architecture
[High-level structure]
[High-level structure]
Components
Components
[Key pieces and their relationships]
[Key pieces and their relationships]
Data Flow
Data Flow
[How data moves through the system]
[How data moves through the system]
Error Handling
Error Handling
[What can go wrong and how it is handled]
[What can go wrong and how it is handled]
Decisions Made
Decisions Made
Non-Goals
Non-Goals
- [What was explicitly excluded and why]
- [What was explicitly excluded and why]
Next Steps
Next Steps
Invoke planning skill to create implementation plan.
**STOP — Do NOT proceed until:**
- [ ] Design document is saved to `docs/plans/`
- [ ] Memory files are updated with new decisions/patterns
- [ ] User has confirmed the design is complete
---Invoke planning skill to create implementation plan.
**停止 —— 满足以下条件前不要继续：**
- [ ] 设计文档已经保存到`docs/plans/`目录
- [ ] 内存文件已经更新了新的决策/规范
- [ ] 用户已经确认设计完成
---Anti-Patterns / Common Mistakes
反模式/常见错误
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| "This is too simple to brainstorm" | Every project needs a design, even simple ones | Design can be brief, but must exist |
| "The user already knows what they want" | Users know WHAT, not HOW | Explore the HOW through approaches |
| "I can just start coding" | Code without design is technical debt from line 1 | Design first, code second |
| "We don't have time to brainstorm" | We don't have time to rebuild from poor assumptions | Brainstorming prevents costly rework |
| "The requirements are clear" | Requirements are not design — you still need approaches | Explore trade-offs even with clear requirements |
| Asking 5 questions at once | Overwhelms the user, gets shallow answers | One question per message |
| Skipping context loading | Re-asks things already known | Check memory files first |
| Not proposing alternatives | Anchors on first idea, misses better options | Always propose 2-3 approaches |
| Presenting entire design at once | Too much to review, user skims | Section by section with approval |
| Not persisting decisions | Same discussions repeat in future sessions | Update memory files |
| 反模式 | 失败原因 | 正确做法 |
|---|---|---|
| "这个太简单了，不需要头脑风暴" | 每个项目都需要设计，哪怕是简单的项目 | 设计可以很简短，但必须存在 |
| "用户已经知道他们想要什么了" | 用户知道要什么，不知道怎么做 | 通过方案探索实现方式 |
| "我可以直接开始写代码" | 没有设计的代码从第一行开始就是技术债务 | 先设计，再编码 |
| "我们没时间做头脑风暴" | 我们没时间因为错误的假设重新开发 | 头脑风暴可以避免代价高昂的返工 |
| "需求已经很清晰了" | 需求不等于设计——你仍然需要明确实现方案 | 哪怕需求清晰也要探索不同方案的权衡 |
| 一次问5个问题 | 给用户造成负担，得到的回答不够深入 | 每条消息只提一个问题 |
| 跳过上下文加载 | 重复询问已经知道的内容 | 先检查内存文件 |
| 不提供备选方案 | 局限于第一个想法，错过更好的选择 | 始终提供2-3种方案 |
| 一次性展示整个设计 | 内容太多难以评审，用户只会粗略浏览 | 分模块展示，逐个获得认可 |
| 不沉淀决策 | 未来的会话中会重复讨论同样的问题 | 更新内存文件 |
Anti-Rationalization Guards
反合理化约束
<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
</HARD-GATE>
If you catch yourself thinking:
- "Let me just scaffold the project first..." — No. Design first.
- "The design is obvious..." — Then it will be quick to document. Do it.
- "The user seems impatient..." — Poor design wastes more time than brainstorming.
<HARD-GATE>
在你展示设计并获得用户批准之前，绝对不要调用任何实现skill、编写任何代码、搭建任何项目脚手架，或者采取任何实现相关的操作。这适用于所有项目，不管你觉得它有多简单。
</HARD-GATE>
如果你发现自己有以下想法：
- "我先把项目脚手架搭起来吧..." —— 不行，先做设计。
- "设计太明显了..." —— 那文档写起来也很快，去写。
- "用户看起来不耐烦了..." —— 糟糕的设计比头脑风暴浪费的时间多得多。
Integration Points
集成点
| Skill | Relationship | When |
|---|---|---|
| Upstream — provides project context from memory | Phase 1: context loading |
| Downstream — receives approved design | Phase 5: transition to planning |
| Complementary — breaks design into work breakdown | When design reveals complex scope |
| Complementary — can formalize design into specs | When formal specifications are needed |
| Downstream — verifies design completeness | Before claiming design is done |
| Skill | 关系 | 触发时机 |
|---|---|---|
| 上游——从内存提供项目上下文 | 阶段1：上下文加载 |
| 下游——接收经过审批的设计 | 阶段5：交接给规划流程 |
| 互补——将设计拆分为工作分解结构 | 当设计显示范围较为复杂时 |
| 互补——可以将设计正式化为规范 | 当需要正式规格说明时 |
| 下游——验证设计完整性 | 在声明设计完成之前 |
Concrete Examples
具体示例
Example: Simple Feature Brainstorm
示例：简单功能头脑风暴
User: "I want to add dark mode to the app"
Phase 1: [Check memory — React app, Tailwind CSS, no current theme system]
Phase 2: "Should dark mode (A) follow system preference automatically,
(B) be a manual toggle only, or (C) both with manual override?"
Phase 3: Approach A: CSS variables + Tailwind dark: prefix
Approach B: Theme context provider with CSS-in-JS
Recommend A — aligns with existing Tailwind usage
Phase 4: Section 1: Architecture — Tailwind dark mode with class strategy
Section 2: Components — ThemeToggle component, layout wrapper
Phase 5: Save design doc, invoke planning skillUser: "I want to add dark mode to the app"
Phase 1: [Check memory — React app, Tailwind CSS, no current theme system]
Phase 2: "Should dark mode (A) follow system preference automatically,
(B) be a manual toggle only, or (C) both with manual override?"
Phase 3: Approach A: CSS variables + Tailwind dark: prefix
Approach B: Theme context provider with CSS-in-JS
Recommend A — aligns with existing Tailwind usage
Phase 4: Section 1: Architecture — Tailwind dark mode with class strategy
Section 2: Components — ThemeToggle component, layout wrapper
Phase 5: Save design doc, invoke planning skillExample: Transition to Planning
示例：交接给规划流程
Design approved and saved to docs/plans/2026-03-15-dark-mode-design.md.
Updated memory/decisions-log.md with theme system decision.
Invoking planning skill to create implementation plan.Design approved and saved to docs/plans/2026-03-15-dark-mode-design.md.
Updated memory/decisions-log.md with theme system decision.
Invoking planning skill to create implementation plan.Key Principles
核心原则
- One question at a time — Do not overwhelm
- Multiple choice preferred — Easier to answer
- YAGNI ruthlessly — Remove unnecessary features
- Explore alternatives — Always propose 2-3 approaches
- Incremental validation — Present and approve in sections
- Build on context — Use self-learning memory to avoid re-asking known things
- 一次只提一个问题 —— 不要造成负担
- 优先使用选择题 —— 更易回答
- 严格遵循YAGNI原则 —— 砍掉不必要的功能
- 探索备选方案 —— 始终提出2-3种方案
- 增量验证 —— 分模块展示并获得认可
- 基于上下文开展工作 —— 使用自学习内存避免重复询问已知内容
Skill Type
Skill类型
RIGID — Follow this process exactly. Every idea goes through all five phases. The design can be brief for simple projects, but it must be documented and approved before any implementation begins.
RIGID —— 严格遵循这个流程。所有想法都必须经过全部五个阶段。简单项目的设计可以很简短，但在任何实现开始前必须完成文档编写和审批。