evanflow-brainstorming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

EvanFlow: Brainstorming

EvanFlow：头脑风暴

Vocabulary

术语说明

See

evanflow

meta-skill. Key terms used here: deep modules, deletion test, mockup quick-mode, grill.

请查看

evanflow

元技能。此处使用的关键术语：deep modules、deletion test、mockup quick-mode、grill。

When to Use

使用场景

"Help me think through X"
"I want to build Y"
New feature scoping
Design questions where intent is unclear
Before any creative work that will produce code

SKIP this skill when: the user is asking a factual question, requesting a quick mockup, or doing exploratory reading. EvanFlow has no skill tax — answer directly.

"帮我梳理X的思路"
"我想开发Y"
新功能范围界定
意图不明确的设计问题
任何会产生代码的创意工作开展前

跳过本技能的场景：用户提出事实性问题、请求快速制作原型，或进行探索性阅读时。EvanFlow无技能使用门槛——直接作答即可。

Mockup Quick-Mode

原型快速模式

If the user says "show me mockups", "give me visual options", "let's see designs", or anything similar and is NOT asking to implement — skip everything below. Produce mockups directly in whatever form the project uses:

HTML files (often easiest — write self-contained pages and tell the user where to open them, e.g.,
```
open mockup-1.html
```
or via a local HTTP server)
Figma frames (if the project uses Figma)
ASCII layouts (for terminal UIs)
Whatever the project's CLAUDE.md documents as the design-iteration medium

No spec doc. No plan. No git operations. Just iterate visually until the user picks a direction.

如果用户提到“给我展示原型”、“提供视觉选项”、“看看设计方案”等类似需求，且不要求实现——请跳过以下所有步骤。直接以项目采用的形式生成原型：

HTML文件（通常最简单——编写独立页面并告知用户打开方式，例如
```
open mockup-1.html
```
或通过本地HTTP服务器）
Figma框架（若项目使用Figma）
ASCII布局（适用于终端UI）
项目CLAUDE.md文档中指定的任何设计迭代媒介

无需规范文档，无需规划，无需git操作。只需进行视觉迭代，直到用户选定方向。

The Flow

流程步骤

Quick context check. Skim relevant files, recent commits, and any referenced docs. Do NOT exhaustively explore — just enough to ground the conversation.
Scope check. If the request describes multiple independent subsystems, flag it and propose decomposition before going further. Don't refine details on something that needs to be split.
Ask clarifying questions one at a time. Multiple-choice when possible (use AskUserQuestion). Focus on purpose, constraints, success criteria.
Propose 2–3 approaches with trade-offs and your recommendation as option (a). Lead with "here's what I'd do and why."
Embedded Grill (see below) — stress-test the chosen approach before committing.
Present the design in sections sized to their complexity. Get explicit approval after each section.
Decide: spec doc, straight to plan, or just go.

快速上下文检查。浏览相关文件、近期提交记录及任何参考文档。无需全面深入探索——只需足够信息让对话贴合项目实际。
范围检查。若请求涉及多个独立子系统，需先指出并建议拆分后再推进。不要在需要拆分的内容上细化细节。
逐个提出澄清问题。尽可能采用选择题形式（使用AskUserQuestion）。聚焦于目的、约束条件、成功标准。
提出2–3种方案，说明各方案的权衡，并将你的推荐方案列为选项(a)。以“以下是我的建议及理由”作为开头。
嵌入式审查（Embedded Grill）（见下文）——在确定方案前对选定方案进行压力测试。
分模块展示设计，模块大小根据复杂度而定。每个模块展示后需获得用户明确认可。
决策：编写规范文档、直接制定计划，或立即启动开发。

Embedded Grill

嵌入式审查（Embedded Grill）

Once an approach is chosen, ask 3–5 sharp questions targeting:

Hidden constraints: "What breaks if a user does X?"
Reversibility: "If we ship this and it's wrong, what's the rollback?"
Boundaries: "What's explicitly NOT in scope?"
Existing patterns: "Is there code in the project that already does something similar? Should this conform or diverge?"
Domain language: "Are we using the right terms from
```
CONTEXT.md
```
?"

For each question, propose a recommended answer. The user accepts, refines, or rejects. Don't grill on every single design — only when the choice has irreversibility, security, or domain-modeling implications.

选定方案后，提出3–5个尖锐问题，聚焦于：

隐藏约束：“如果用户执行X操作，会有什么功能受影响？”
可回滚性：“如果我们发布后发现方案有误，回滚流程是什么？”
边界范围：“哪些内容明确不属于本次范围？”
现有模式：“项目中是否已有类似功能的代码？本次方案应遵循还是偏离该模式？”
领域术语：“我们使用的术语是否符合
```
CONTEXT.md
```
中的定义？”

每个问题需给出推荐答案。用户可接受、细化或拒绝该答案。无需对每个设计都进行审查——仅当方案存在不可逆性、安全或领域建模相关影响时才需进行。

Hard Rules

硬性规则

Never auto-commit. Confirm in the current turn before any git op.
No forced spec path. If a spec doc is appropriate, ask the user where to put it. Default suggestion:
```
docs/specs/YYYY-MM-DD-<topic>.md
```
. Don't write to any vendor-specific path unless user requests.
No forced visual companion offer. Skip the browser-companion offer entirely; mockup quick-mode handles visual work directly.
No skill tax. If the user is just chatting or asking a factual question, exit this skill — don't force the flow.

禁止自动提交。执行任何git操作前需在当前对话中确认。
不强制规范文档路径。若需要编写规范文档，需询问用户存储位置。默认建议路径：
```
docs/specs/YYYY-MM-DD-<topic>.md
```
。除非用户要求，否则不要写入特定供应商路径。
不强制提供视觉配套工具。完全跳过浏览器配套工具的提议；原型快速模式可直接处理视觉工作。
无技能使用门槛。若用户仅在闲聊或提出事实性问题，请退出本技能——不要强制遵循流程。

Hand-offs

交接流程

Spec written →
```
evanflow-writing-plans
```
(if non-trivial)
Substantial new feature (sprint-sized, multi-stakeholder) →
```
evanflow-prd
```
instead of writing-plans
Plan exists →
```
evanflow-executing-plans
```
(which itself offers
```
evanflow-coder-overseer
```
if the plan has 3+ parallelizable units)
Just go → start with
```
evanflow-tdd
```
for the first behavior
Domain term emerged →
```
evanflow-glossary
```
to update
```
CONTEXT.md
```
Interface shape is the hard part of the design →
```
evanflow-design-interface
```
before writing-plans

规范文档编写完成 → 移交至
```
evanflow-writing-plans
```
（若内容非 trivial）
大型新功能（冲刺级、涉及多方利益相关者）→ 移交至
```
evanflow-prd
```
而非writing-plans
已有计划 → 移交至
```
evanflow-executing-plans
```
（若计划包含3个以上可并行单元，该技能会自动提供
```
evanflow-coder-overseer
```
选项）
立即启动开发 → 先使用
```
evanflow-tdd
```
实现首个功能
出现新领域术语 → 移交至
```
evanflow-glossary
```
更新
```
CONTEXT.md
```
接口设计是本次设计的核心难点 → 移交至
```
evanflow-design-interface
```
后再进行writing-plans