brainstorm-solutions

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brainstorm Solutions

头脑风暴解决方案

Explore the solution space broadly before committing to a single path.

在确定单一方案之前，先广泛探索解决方案空间。

Position in Workflow

工作流中的位置

Step 2 of development workflow:

```
/research
```
- Understand problem and constraints
```
/brainstorm-solutions
```
- Explore solution space (THIS)
```
/design-solution
```
- Converge on a single solution
Plan, code, review, ship

开发工作流的第2步：

```
/research
```
- 理解问题与约束条件
```
/brainstorm-solutions
```
- 探索解决方案空间（本步骤）
```
/design-solution
```
- 确定单一解决方案
规划、编码、评审、发布

Core Principle

核心原则

Breadth first. Generate multiple distinct options before evaluating or ranking them.

先广度后深度。在生成多个不同选项后再进行评估或排序。

Input

输入

Default: Use research findings from the current conversation.

If argument provided:

File path: Read the file for research context
GitHub issue: Fetch with
```
gh issue view $ARG --comments
```

默认： 使用当前对话中的研究结果。

若提供参数：

文件路径：读取文件以获取研究背景
GitHub issue：使用
```
gh issue view $ARG --comments
```
命令获取内容

Workflow

工作流

1. Gather Context

1. 收集背景

Summarize the problem, constraints, and goals from research.
Identify existing architecture patterns and similar implementations.

总结研究得出的问题、约束条件与目标。
识别现有架构模式及类似实现。

2. Ask Clarifying Questions

2. 提出澄清问题

Ask only what improves solution quality:

Business goals and priorities
User workflows and usage patterns
Performance or scalability requirements
Extensibility or future roadmap considerations
Hard constraints (timeline, compatibility, cost)

仅提出有助于提升解决方案质量的问题：

业务目标与优先级
用户工作流与使用模式
性能或可扩展性要求
可扩展性或未来路线图考量
硬性约束（时间线、兼容性、成本）

3. Generate Options

3. 生成选项

Generate at least 3-5 distinct approaches across dimensions:

Dimension	Examples
Architectural approach	Event-driven vs request-response, monolith vs service
Implementation strategy	Extend existing module vs new module, refactor vs add
Library/tool choice	Redis vs in-memory, REST vs GraphQL
Feature design	Wizard flow vs single form, eager vs lazy loading

Avoid anchoring on the first idea. Expand, then refine.

至少生成3-5个跨不同维度的独特方案：

维度	示例
架构方案	Event-driven vs request-response, monolith vs service
实现策略	扩展现有模块 vs 新增模块，重构 vs 新增功能
库/工具选择	Redis vs 内存存储，REST vs GraphQL
功能设计	向导式流程 vs 单一表单，即时加载 vs 懒加载

避免锚定第一个想法。先拓展，再细化。

4. First Principles Check

4. 第一性原理检查

For each option, challenge assumptions:

Do we need this?
Are requirements correct?
Are existing patterns optimal?
What is the simplest viable solution?
What would we regret in 6 months?

针对每个选项，挑战现有假设：

我们真的需要这个吗？
需求是否准确？
现有模式是否最优？
最简单的可行方案是什么？
6个月后我们会后悔什么？

Output Format

输出格式

undefined

undefined

Solution Brainstorm

Context Summary

[Brief restatement of problem and key constraints]

Clarifying Questions

[Questions about strategy, usage, or requirements - if any]

Options

Option 1: [Name]

[Description]

Option 2: [Name]

[Description]

Option 3: [Name]

[Description]

[Add Option 4/5 if useful]

[Description]

[Add Option 4/5 if useful]

Notes

[Any assumptions or risks that should be validated before choosing]

Next Step

Ready to converge on a single solution. Run

/design-solution

undefined

Ready to converge on a single solution. Run

/design-solution

undefined

Common Mistakes

常见错误

Mistake	Fix
Anchoring on first idea	Generate 3-5 options BEFORE evaluating any
Shallow codebase exploration	Read related files and patterns first
Assuming requirements	Ask clarifying questions early
Skipping first principles	Apply first principles to each option
Rushing to recommendation	Save evaluation for design-solution

错误	修正方法
锚定第一个想法	在评估任何选项之前，先生成3-5个选项
对代码库的探索不够深入	先阅读相关文件和模式
假设需求已明确	尽早提出澄清问题
跳过第一性原理检查	对每个选项应用第一性原理
急于给出推荐	将评估环节留到设计解决方案步骤

What NOT to Do

禁止事项

Do NOT present only one option
Do NOT recommend a solution yet
Do NOT skip clarifying questions when uncertainty exists
Do NOT ignore existing codebase patterns

不得仅呈现一个选项
不得过早推荐解决方案
当存在不确定性时，不得跳过澄清问题
不得忽视现有代码库模式