brainstorming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brainstorming 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
```
/brainstorm
```
command invoked
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
```
,
```
decisions-log.md
```
) for known patterns, stack, and conventions
Read relevant existing code, docs, and recent commits
Review existing designs in
```
docs/plans/
```
for related prior work
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

方案对比模板

undefined

undefined

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]

Approach B: [Name]

...

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:
- ```
memory/decisions-log.md
```
  — any architectural decisions made
- ```
memory/learned-patterns.md
```
  — any new conventions discussed
Invoke the
```
planning
```
skill to create a detailed implementation plan

目标： 留存设计内容，并交接给planning skill。

将经过验证的设计写入
```
docs/plans/YYYY-MM-DD-<topic>-design.md
```
提交设计文档
更新自学习内存：
- ```
memory/decisions-log.md
```
  —— 所有做出的架构决策
- ```
memory/learned-patterns.md
```
  —— 所有讨论过的新规范
调用
```
planning
```
skill生成详细的落地实现计划

Design Document Template

设计文档模板

markdown

undefined

markdown

undefined

[Topic] Design Document

Date: YYYY-MM-DD Status: Approved Approach: [Which approach was chosen]

Problem Statement

[What problem this solves and for whom]

Design

Architecture

[High-level structure]

Components

[Key pieces and their relationships]

Data Flow

[How data moves through the system]

Error Handling

[What can go wrong and how it is handled]

Decisions Made

Non-Goals

[What was explicitly excluded and why]

[What was explicitly excluded and why]

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
`self-learning`	Upstream — provides project context from memory	Phase 1: context loading
`planning`	Downstream — receives approved design	Phase 5: transition to planning
`task-decomposition`	Complementary — breaks design into work breakdown	When design reveals complex scope
`spec-writing`	Complementary — can formalize design into specs	When formal specifications are needed
`verification-before-completion`	Downstream — verifies design completeness	Before claiming design is done

Skill	关系	触发时机
`self-learning`	上游——从内存提供项目上下文	阶段1：上下文加载
`planning`	下游——接收经过审批的设计	阶段5：交接给规划流程
`task-decomposition`	互补——将设计拆分为工作分解结构	当设计显示范围较为复杂时
`spec-writing`	互补——可以将设计正式化为规范	当需要正式规格说明时
`verification-before-completion`	下游——验证设计完整性	在声明设计完成之前

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 skill

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 skill

Example: 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 —— 严格遵循这个流程。所有想法都必须经过全部五个阶段。简单项目的设计可以很简短，但在任何实现开始前必须完成文档编写和审批。