brainstorming

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brainstorming Skill

头脑风暴Skill

Overview

概述

Collaborative design exploration for new features, architecture decisions, and complex problem-solving.

针对新功能、架构决策及复杂问题解决的协作式设计探索。

Triggers

触发条件

Activate this skill when:

User says "let's brainstorm", "let's ideate", or "let's explore"
User runs
```
/ideate
```
command
User wants to discuss design options before implementation
A problem has multiple valid solutions needing evaluation

For a complete worked example, see

references/worked-example.md

在以下场景激活此Skill：

用户说 "let's brainstorm"、"let's ideate" 或 "let's explore"
用户执行
```
/ideate
```
命令
用户希望在实现前讨论设计方案
某个问题有多个可行解决方案需要评估

完整示例请查看

references/worked-example.md

。

Three-Phase Process

三阶段流程

Phase 1: Understanding

阶段1：理解

Goal: Deeply understand the problem before proposing solutions.

Rules:

Ask ONE question at a time
Wait for response before asking next question
Focus on: goals, constraints, existing patterns, user preferences
Maximum 5 questions before moving to exploration

Question Types:

"What problem are we solving?" (core need)
"What constraints exist?" (time, tech, compatibility)
"What patterns already exist in the codebase?" (consistency)
"Who/what will consume this?" (users, APIs, other systems)
"What does success look like?" (acceptance criteria)

目标： 在提出解决方案前深入理解问题。

规则：

一次仅提出一个问题
等待用户回复后再提出下一个问题
聚焦于：目标、约束条件、现有模式、用户偏好
最多提出5个问题后进入探索阶段

问题类型：

"我们要解决什么问题？"（核心需求）
"存在哪些约束条件？"（时间、技术、兼容性）
"代码库中已存在哪些模式？"（一致性）
"谁/什么会使用这个功能？"（用户、API、其他系统）
"成功的标准是什么？"（验收标准）

Phase 2: Exploration

阶段2：探索

Goal: Present 2-3 distinct approaches with trade-offs.

Use the approach format from

references/design-template.md

. Present genuinely different approaches with honest trade-offs. Recommend one option with rationale.

目标： 呈现2-3种不同的方案及权衡分析。

使用

references/design-template.md

中的方案格式。展示真正不同的方案并如实说明权衡点。推荐一个选项并给出理由。

Phase 3: Design Presentation

阶段3：设计呈现

Goal: Document the chosen approach in detail with numbered requirements.

Document the chosen approach using the structure in

references/design-template.md

. Sections of 200-300 words max. Use diagrams for complex flows.

Requirements format (MANDATORY):

Use numbered requirement identifiers:
```
DR-1
```
,
```
DR-2
```
, ...,
```
DR-N
```
Each requirement MUST have an
```
**Acceptance criteria:**
```
block with concrete, testable criteria
At least one requirement MUST address error handling, failure modes, or edge cases
These DR-N identifiers are provenance anchors — implementation plans trace tasks to them

Save Location:

docs/designs/YYYY-MM-DD-<feature>.md

目标： 详细记录选定的方案，包含编号的需求项。

使用

references/design-template.md

中的结构记录选定的方案。每个部分最多200-300字。复杂流程使用图表展示。

需求格式（必填）：

使用编号的需求标识：
```
DR-1
```
、
```
DR-2
```
……
```
DR-N
```
每个需求必须包含
```
**Acceptance criteria:**
```
块，内容为具体、可测试的标准
至少有一个需求必须涉及错误处理、故障模式或边缘情况
这些DR-N标识是溯源锚点——实现规划会将任务与它们关联

保存位置：

docs/designs/YYYY-MM-DD-<feature>.md

Iteration Limits

迭代限制

Design iterations: max 3. If Phase 2 (Exploration) cycles through 3 rounds of presenting approaches without the user converging on a choice, pause and summarize the trade-offs for the user to make a final decision.

The user can override:

/ideate --max-iterations 5

设计迭代：最多3次。如果阶段2（探索）经过3轮方案展示后用户仍未选定方案，请暂停并总结权衡点，供用户做出最终决策。

用户可覆盖此限制：

/ideate --max-iterations 5

Anti-Patterns

反模式

Don't	Do Instead
Jump to solution immediately	Ask clarifying questions first
Present only one option	Always show 2-3 alternatives
Hide drawbacks of preferred option	Be transparent about trade-offs
Write walls of text	Use 200-300 word sections max
Ignore existing patterns	Reference codebase conventions
Skip documentation	Save design to docs/designs/

禁止做法	正确做法
直接跳到解决方案	先提出澄清问题
只展示一个选项	始终展示2-3种替代方案
隐藏首选方案的缺点	透明说明权衡点
大段文字堆砌	每个部分最多200-300字
忽略现有模式	参考代码库约定
跳过文档记录	将设计保存到docs/designs/

State Management

状态管理

This skill manages workflow state for context persistence.

此Skill管理工作流状态以保持上下文持久化。

On Start (before Phase 1)

启动时（阶段1之前）

Initialize workflow state using

mcp__exarchos__exarchos_workflow

with

action: "init"

workflowType: "feature"

, and the featureId.

This creates a state file tracked by the MCP server.

使用

mcp__exarchos__exarchos_workflow

初始化工作流状态，参数为

action: "init"

、

workflowType: "feature"

及featureId。

这会创建一个由MCP服务器跟踪的状态文件。

On Design Save (after Phase 3)

设计保存时（阶段3之后）

action: "set", featureId: "<id>", updates: { "artifacts": { "design": "<path>" } }, phase: "plan"

action: "set", featureId: "<id>", updates: { "artifacts": { "design": "<path>" } }, phase: "plan"

Phase Transitions and Guards

阶段转换与防护

This skill is the entry point for the feature workflow (

workflowType: "feature"

). The full lifecycle is:

ideate → plan → plan-review → delegate ⇄ review → synthesize → completed

For the full transition table, consult

@skills/workflow-state/references/phase-transitions.md

此Skill是功能工作流（

workflowType: "feature"

）的入口点。完整生命周期为：

ideate → plan → plan-review → delegate ⇄ review → synthesize → completed

完整转换表请查阅

@skills/workflow-state/references/phase-transitions.md

。

Schema Discovery

架构发现

Use

exarchos_workflow({ action: "describe", actions: ["set", "init"] })

for parameter schemas and

exarchos_workflow({ action: "describe", playbook: "feature" })

for phase transitions, guards, and playbook guidance.

使用

exarchos_workflow({ action: "describe", actions: ["set", "init"] })

获取参数架构，使用

exarchos_workflow({ action: "describe", playbook: "feature" })

获取阶段转换、防护及工作指南。

Completion Verification

完成验证

Run the ideation artifact verification:

typescript

mcp__exarchos__exarchos_orchestrate({
  action: "check_design_completeness",
  featureId: "<featureId>",
  designPath: "docs/designs/YYYY-MM-DD-<feature>.md"
})

On
passed: true
: All completion criteria met — proceed to gate check. On
passed: false
: Missing artifacts — review output and complete before continuing. If the check is advisory (

advisory: true

), emit a warning but do not block auto-chain.

执行构思工件验证：

typescript

mcp__exarchos__exarchos_orchestrate({
  action: "check_design_completeness",
  featureId: "<featureId>",
  designPath: "docs/designs/YYYY-MM-DD-<feature>.md"
})

当
passed: true
时：所有完成条件满足——进入 gate check。当
passed: false
时：缺少工件——查看输出并补充完整后再继续。如果检查是建议性的（

advisory: true

），则发出警告但不阻止自动链式执行。

Adversarial Gate Check (ideate → plan)

对抗性Gate Check（ideate → plan）

After artifact verification passes, run the design completeness gate check. This is the D1 (spec fidelity) lightweight adversarial check at the ideate → plan boundary.

typescript

mcp__exarchos__exarchos_orchestrate({
  action: "check_design_completeness",
  featureId: "<id>",
  designPath: "<path>"
})

The handler returns a structured result:

{ passed, advisory, findings[], checkCount, passCount, failCount }

passed=true
: Design complete — all requirements have acceptance criteria and error coverage.
passed=false, advisory=true
: Findings detected. These are advisory — they do NOT block the auto-chain to
```
/plan
```
. Present
```
result.data.findings
```
to the user alongside the transition message.

Gate events (

gate.executed

) are emitted automatically by the handler — no manual event emission is needed.

工件验证通过后，执行设计完整性gate check。这是ideate → plan边界处的D1（规范保真度）轻量级对抗性检查。

typescript

mcp__exarchos__exarchos_orchestrate({
  action: "check_design_completeness",
  featureId: "<id>",
  designPath: "<path>"
})

处理器返回结构化结果：

{ passed, advisory, findings[], checkCount, passCount, failCount }

。

passed=true
：设计完整——所有需求都有验收标准和错误覆盖。
passed=false, advisory=true
：检测到问题。这些是建议性的——不会阻止自动链式执行到
```
/plan
```
。将
```
result.data.findings
```
展示给用户并附带转换消息。

Gate事件（

gate.executed

）由处理器自动触发——无需手动触发事件。

Transition

转换

After brainstorming completes, auto-continue to planning (no user confirmation):

头脑风暴完成后，自动进入规划阶段（无需用户确认）：

Pre-Chain Validation (MANDATORY)

链式前验证（必填）

Before invoking

/plan

Verify
```
artifacts.design
```
exists in workflow state
Verify the design file exists on disk:
```
test -f "$DESIGN_PATH"
```

Run

mcp__exarchos__exarchos_orchestrate({ action: "check_design_completeness", featureId: "<id>", designPath: "<path>" })

(advisory — record findings but don't block)

If steps 1 or 2 fail: "Design artifact not found, cannot auto-chain to /plan"

调用

/plan

前：

验证工作流状态中存在
```
artifacts.design
```
验证设计文件存在于磁盘：
```
test -f "$DESIGN_PATH"
```

执行

mcp__exarchos__exarchos_orchestrate({ action: "check_design_completeness", featureId: "<id>", designPath: "<path>" })

（建议性——记录问题但不阻止）

如果步骤1或2失败："未找到设计工件，无法自动链式执行到/plan"

Chain Steps

链式步骤

Update state:

action: "set", featureId: "<id>", updates: { "artifacts": { "design": "<path>" } }, phase: "plan"

If
```
result.data.passed === false
```
and
```
result.data.advisory === true
```
: Output
```
result.data.findings
```
summary, then: "Advisory findings noted. Auto-continuing to implementation planning..." If
```
result.data.passed === true
```
: Output: "Design complete. Auto-continuing to implementation planning..."

Invoke immediately:

typescript

[Invoke the exarchos:plan skill with args: <design-path>]

This is NOT a human checkpoint. The human checkpoint occurs at plan-review (plan approval) and synthesize (merge confirmation).

Workflow continues:

/ideate

/plan

-> plan-review -> [HUMAN CHECKPOINT] ->

/delegate

/review

/synthesize

-> [HUMAN CHECKPOINT]

更新状态：`action: "set", featureId: "<id>", updates: { "artifacts": { "design": "<path>" } }, phase: "plan"
如果
```
result.data.passed === false
```
且
```
result.data.advisory === true
```
：输出
```
result.data.findings
```
摘要，然后："已记录建议性问题。自动进入实现规划..." 如果
```
result.data.passed === true
```
：输出："设计完成。自动进入实现规划..."

立即调用：

typescript

[调用exarchos:plan skill，参数：<design-path>]

这不是人工检查点。人工检查点位于plan-review（规划审批）和synthesize（合并确认）阶段。

工作流继续：

/ideate

/plan

-> plan-review -> [人工检查点] ->

/delegate

/review

/synthesize

-> [人工检查点]

Exarchos Integration

Exarchos集成

When Exarchos MCP tools are available:

At workflow start: Auto-emitted by
```
exarchos_workflow
```
```
action: "init"
```
— do NOT manually append
```
workflow.started
```

当Exarchos MCP工具可用时：

工作流启动时： 由
```
exarchos_workflow
```
的
```
action: "init"
```
自动触发——请勿手动添加
```
workflow.started
```