workflow-brainstorm

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brainstorming Ideas Into Designs

将头脑风暴的想法转化为设计方案

Goal

目标

Transform "vague ideas/requirements" into actionable designs and specifications, producing reusable file artifacts (rather than just staying in chat).

Key requirement: Ask only one question at a time. If a topic is complex, break it into multiple rounds of Q&A—don't throw out a checklist all at once.

将「模糊的想法/需求」转化为可执行的设计方案和规范，生成可复用的文件成果（而非仅停留在对话中）。

核心要求：每次只提出一个问题。如果主题复杂，将其拆分为多轮问答——不要一次性抛出所有问题清单。

Core Process (Must Follow)

核心流程（必须遵循）

0) Check Project Context First (Required When Repo Exists)

0) 首先检查项目上下文（仓库存在时必须执行）

Before asking questions, quickly check:

Key documentation:
```
README.md
```
,
```
docs/
```
,
```
design-system.md
```
(if exists)
Tech stack and constraints:
```
package.json
```
/
```
Cargo.toml
```
/
```
pyproject.toml
```
etc.
Structure overview: top-level directories, main modules
Recent changes:
```
git log -n 10 --oneline
```
(if it's a git repo)

Output a very brief context summary: what you observed + possible constraint points (don't start designing yet).

在提问前，快速检查以下内容：

关键文档：
```
README.md
```
、
```
docs/
```
、
```
design-system.md
```
（若存在）
技术栈与约束：
```
package.json
```
/
```
Cargo.toml
```
/
```
pyproject.toml
```
等
结构概览：顶级目录、主要模块
近期变更：
```
git log -n 10 --oneline
```
（如果是Git仓库）

输出一份非常简短的上下文总结：你观察到的内容 + 可能的约束点（此时不要开始设计）。

1) Understand the Idea (One Question at a Time)

1) 理解需求（每次只提一个问题）

Goal is to gather the minimum information set (purpose / constraints / success criteria).

Rules:

Each message asks 1 question only
Prefer multiple choice (reduce user's cognitive load), use open questions only when necessary
Ask direction-determining questions first (goals/success criteria/non-goals), then details

目标是收集最必要的信息集（目的/约束/成功标准）。

规则：

每条消息仅提出1个问题
优先使用选择题（降低用户认知负担），仅在必要时使用开放式问题
先询问决定方向的问题（目标/成功标准/非目标），再询问细节

2) Explore Solutions (2-3 Options + Trade-offs)

2) 探索解决方案（2-3个选项 + 取舍分析）

After you understand the requirements:

Provide 2-3 options (A/B/C)
Explain trade-offs for each (complexity/risk/iteration speed/long-term cost)
Give your recommended option first, then explain why

在理解需求后：

提供2-3个选项（A/B/C）
说明每个选项的取舍（复杂度/风险/迭代速度/长期成本）
优先给出你的推荐选项，然后解释原因

3) Output Design (200-300 Word Segments + Confirm Each)

3) 输出设计方案（200-300字段落 + 每段确认）

When you're confident you understand what needs to be done, start outputting the design spec.

Requirements:

Output in segments (~200-300 words each)
Ask for confirmation at the end of each segment: e.g., "Does this look good?"
Design should at least cover:
- Architecture and module boundaries
- Core data flow (input → processing → output)
- Error handling and edge cases
- Testing and validation strategy (minimum viable set)

If user disagrees with a segment: go back to questioning/option phase to clarify—don't push forward.

当你确定已理解需要完成的内容后，开始输出设计规范。

要求：

分段落输出（每段约200-300字）
每段结尾需请求确认：例如，「这个内容看起来没问题吧？」
设计至少应涵盖：
- 架构与模块边界
- 核心数据流（输入→处理→输出）
- 错误处理与边缘情况
- 测试与验证策略（最小可行集合）

如果用户对某段内容有异议：回到提问/方案阶段澄清——不要继续推进。

Artifacts and Persistence (Strongly Recommended)

成果物与持久化（强烈推荐）

Write Design Document

撰写设计文档

Prefer writing to run directory (artifact-first):

run_dir/evidence/YYYY-MM-DD-<topic>-design.md

If there's no

run_dir

but there is a

repo_root

Create

runs/brainstorm/active/<run_id>/

, and write design to

evidence/

Note: Writing files is a write operation; if this is the user's project repo, confirm "should I persist to the project?" before writing.

优先写入运行目录（成果优先）：

run_dir/evidence/YYYY-MM-DD-<topic>-design.md

如果没有

run_dir

但存在

repo_root

：

创建

runs/brainstorm/active/<run_id>/

，并将设计内容写入

evidence/

注意：写入文件是写操作；如果这是用户的项目仓库，在写入前需确认「是否要将内容持久化到项目中？」

Enter Implementation (Optional)

进入实现阶段（可选）

After design is confirmed, ask one question to let user choose next step:

Enter implementation directly (recommend

workflow-ship-faster

workflow-feature-shipper

)

Write implementation plan first (persist as checklist items in
```
run_dir/tasks.md
```
, then wait for confirmation)
Need research/code reading first (split to
```
run_dir/evidence/parallel/<task-name>/
```
and do in parallel)

设计方案确认后，提出一个问题让用户选择下一步：

直接进入实现阶段（推荐使用
```
workflow-ship-faster
```
或
```
workflow-feature-shipper
```
）
先撰写实现计划（作为清单项持久化到
```
run_dir/tasks.md
```
中，然后等待确认）
需要先进行研究/代码阅读（拆分到
```
run_dir/evidence/parallel/<task-name>/
```
并行处理）

Key Principles

核心原则

One question at a time: Never ask 5 questions in one message
Multiple choice preferred: Help user respond faster and more effectively
YAGNI: Actively remove "not needed yet" features from the design
Incremental validation: Output design in segments, confirm each one

每次一个问题：永远不要在一条消息中问5个问题
优先选择题：帮助用户更快、更高效地回应
YAGNI：主动从设计中移除「目前不需要」的功能
增量验证：分段落输出设计内容，每段都需确认