Back to Details

ideate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorming Skill

Brainstorming Skill

Overview

概述

Collaborative design exploration for new features, architecture decisions, and complex problem-solving. In the collapsed flow, there is no separate design phase — 
/ideate
authors the 
## Design & Rationale
section of one unified 
docs/specs/
artifact, then auto-chains to 
/plan
, which adds the 
## Decomposition
section to the same document. The single approval point is 
plan-review
(a dispatched, fresh-context adversarial pass over the unified doc).
The artifact shape is owned by the unified spec template — author against it, do not restate it: see 
@skills/plan/references/spec-template.md
.
针对新功能、架构决策及复杂问题解决的协作式设计探索。在简化流程中，无独立设计阶段 —— 
/ideate
会在统一的
docs/specs/
工件中撰写
## Design & Rationale
部分，随后自动衔接至
/plan
命令，后者会在同一文档中添加
## Decomposition
部分。唯一的审批节点为
plan-review
（针对统一文档的全新上下文对抗式审核）。
工件格式由统一规范模板定义，请基于模板撰写，勿重复模板内容：详见
@skills/plan/references/spec-template.md
。

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 rationale before decomposition
  • A problem has multiple valid solutions needing evaluation (the 
    deep
    rung)
For a complete worked example, see 
references/worked-example.md
.
在以下场景激活此Skill：
  • 用户输入"let's brainstorm"、"let's ideate"或"let's explore"
  • 用户执行
    /ideate
    命令
  • 用户希望在任务分解前讨论设计原理
  • 问题存在多种需评估的有效解决方案（
    deep
    层级）
完整示例详见
references/worked-example.md
。

Planning depth (one-pass by default; 
deep
gates the divergent loop)

规划深度（默认单次完成；
deep
层级触发发散循环）

The design section is authored at one of three depths, resolved-then-frozen per feature as 
designDepth
on PLAN entry (the per-feature analog of per-task 
riskTier
). The resolver proposes a depth from brief signals (uncertainty, blast-radius, task count); the author confirms or overrides. A higher rung is a strict superset of the lower.
designDepth
This skill's behaviorWhen
thin
One-pass: Problem Statement + the DR-N list. No alternatives, no exploration.Trivial, low-blast features where the decomposition is the substance.
standard
One-pass: full rationale (Problem, Chosen Approach, DR-N with acceptance criteria, Technical Design, Alternatives). (default)Most features.
deep
The divergent loop below: 2-3 genuinely distinct approaches with honest trade-offs and human back-and-forth, plus the opt-in discover bridge.High-uncertainty / high-blast-radius features where the open-design path is warranted.
The 2-3 approach exploration is the 
deep
rung — not a default ceremony. At 
thin
/
standard
, converge in one pass; do not manufacture alternatives the problem does not warrant.
设计部分的撰写分为三个深度层级，每个功能进入PLAN阶段时会确定并冻结
designDepth
（对应任务级别的
riskTier
）。系统会根据简短信号（不确定性、影响范围、任务数量）建议一个深度，由作者确认或覆盖。高层级是低层级的严格超集。
designDepth
本Skill的行为适用场景
thin
单次完成：问题陈述 + DR-N列表。无备选方案，无探索过程。影响范围小的简单功能，任务分解即为核心内容。
standard
单次完成：完整原理阐述（问题、选定方案、带验收标准的DR-N、技术设计、备选方案）。（默认）大多数功能。
deep
以下发散循环：2-3种真正不同的方案，包含坦诚的权衡分析及人机交互，外加可选的探索桥接功能。高不确定性/高影响范围的功能，适合采用开放式设计路径。
2-3种方案的探索仅适用于
deep
层级 —— 并非默认流程。 在
thin
/
standard
层级，单次完成收敛；请勿为无需备选方案的问题强行制造选项。

Process

流程

Phase 0: Constraint anchoring (first turn, before Phase 1)

阶段0：约束锚定（第一轮，阶段1之前）

Goal: Surface the architectural invariants relevant to the proposal before the clarifying questions, so the design is anchored to load-bearing constraints from the first turn.
Load the core invariants catalog at 
.exarchos/invariants.md
(entries marked 
cost-of-load: always-load
) and surface a Constraints section naming the relevant invariants — e.g. a CLI / agent-first surface proposal anchors on 
INV-5a
(input ergonomics) and 
INV-5c
(Aspire verbs). The full selection rules — 
always-load
baseline vs 
reference-only
on-demand vs 
archivable
not-surfaced, the proposal-shape → anchor-invariant table, the emit format, and the catalog-registration gating (surfaced only when a catalog is registered under 
invariants.catalogs
) — are the single shared source of truth for the design-time Constraints step used by 
/ideate
, 
/refactor
, and 
/debug
. See 
@skills/ideate/references/constraint-anchoring.md
.
Emit the Constraints section (per that reference) before Phase 1 so the clarifying questions can probe the proposal against the load-bearing invariants instead of re-discovering them mid-design.
目标： 在提出澄清问题之前，先梳理与提案相关的架构不变量，确保设计从一开始就锚定核心约束。
加载
.exarchos/invariants.md
中的核心不变量目录（标记为
cost-of-load: always-load
的条目），并生成Constraints部分列出相关不变量 —— 例如，CLI/Agent优先的界面提案需锚定
INV-5a
（输入 ergonomics）和
INV-5c
（Aspire verbs）。完整的选择规则（
always-load
基线 vs 按需
reference-only
vs 不展示的
archivable
、提案格式→锚定不变量表、输出格式、目录注册规则（仅当
invariants.catalogs
下注册了目录时才展示））是
/ideate
、
/refactor
和
/debug
在设计阶段约束步骤的唯一共享事实来源。详见
@skills/ideate/references/constraint-anchoring.md
。
在阶段1之前输出Constraints部分（遵循上述参考文档），以便澄清问题可以基于核心不变量探查提案，而非在设计中途重新发现这些约束。

Phase 1: Understanding

阶段1：需求理解

Goal: Deeply understand the problem before proposing a design.
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 on
Question Types:
  1. "What problem are we solving?" (core need)
  2. "What constraints exist?" (time, tech, compatibility)
  3. "What patterns already exist in the codebase?" (consistency)
  4. "Who/what will consume this?" (users, APIs, other systems)
  5. "What does success look like?" (acceptance criteria)
目标： 在提出设计方案前深入理解问题。
规则：
  • 一次仅提出一个问题
  • 等待回复后再提出下一个问题
  • 聚焦于：目标、约束、现有模式、用户偏好
  • 最多提出5个问题后进入下一阶段
问题类型：
  1. "我们要解决什么问题？"（核心需求）
  2. "存在哪些约束？"（时间、技术、兼容性）
  3. "代码库中已有哪些模式？"（一致性）
  4. "谁/什么会使用这个功能？"（用户、API、其他系统）
  5. "成功的标准是什么？"（验收标准）

Phase 2: Exploration — 
deep
rung only

阶段2：方案探索 —— 仅
deep
层级

Goal (when 
designDepth: 'deep'
): Present 2-3 distinct approaches with honest trade-offs, recommend one, and converge through human back-and-forth.
Use the approach format from 
references/design-template.md
. Present genuinely different approaches; recommend one with rationale. Opt-in discover bridge: at the 
deep
rung the runtime publishes a discover-bridge affordance via 
next_actions
(DR-7) — an event-linked, 
correlationId
-stitched escalation to the 
/discover
research workflow. It never auto-runs; surface it to the author and only escalate on confirmation. Cite the discover report by path and 
correlationId
in the Exploration section so provenance spans both documents.
At 
thin
/
standard
, skip this phase — converge directly in Phase 3.
目标（当
designDepth: 'deep'
时）： 呈现2-3种不同方案及坦诚的权衡分析，推荐一种方案，并通过人机交互达成收敛。
使用
references/design-template.md
中的方案格式。呈现真正不同的方案；附上原理说明并推荐一种方案。可选探索桥接： 在
deep
层级，运行时会通过
next_actions
（DR-7）发布探索桥接功能 —— 一种关联
correlationId
的事件链接，可升级至
/discover
研究工作流。该功能绝不会自动运行；需展示给作者，仅在确认后才升级。在探索部分通过路径和
correlationId
引用探索报告，确保溯源覆盖两份文档。
在
thin
/
standard
层级，跳过此阶段 —— 直接进入阶段3收敛。

Phase 3: Author the Design & Rationale section

阶段3：撰写Design & Rationale部分

Goal: Write the 
## Design & Rationale
section of the unified 
docs/specs/
artifact, at the resolved depth, using the structure in 
@skills/plan/references/spec-template.md
. Sections of 200-300 words max; diagrams for complex flows.
Requirements format (MANDATORY):
  • Use numbered requirement identifiers: 
    DR-1
    , 
    DR-2
    , ..., 
    DR-N
    , under the 
    ### Requirements (DR-N)
    heading
  • Each requirement MUST have an 
    **Acceptance criteria:**
    block with concrete, testable criteria (
    thin
    may use a single bullet)
  • At least one requirement MUST address error handling, failure modes, or edge cases
  • These DR-N identifiers are provenance anchors — the 
    ## Decomposition
    section traces tasks to them within this same document (no second file)
Save location: 
docs/specs/YYYY-MM-DD-<feature>.md
. Capture the path as 
$SPEC_PATH
.
目标： 按照确定的深度，使用
@skills/plan/references/spec-template.md
中的结构，撰写统一
docs/specs/
工件的
## Design & Rationale
部分。每个小节最多200-300字；复杂流程需配图表。
要求格式（强制）：
  • 使用编号需求标识符：
    DR-1
    、
    DR-2
    ……
    DR-N
    ，置于
    ### Requirements (DR-N)
    标题下
  • 每个需求必须包含
    **Acceptance criteria:**
    块，内容为具体、可测试的标准（
    thin
    层级可使用单个项目符号）
  • 至少有一个需求需涉及错误处理、故障模式或边缘情况
  • 这些DR-N标识符是溯源锚点 —— 
    ## Decomposition
    部分会在同一文档中追踪对应任务（无需第二个文件）
保存位置： 
docs/specs/YYYY-MM-DD-<feature>.md
。将路径记录为
$SPEC_PATH
。

Iteration Limits

迭代限制

Design iterations: max 3 (the 
deep
divergent loop). If Phase 2 cycles through 3 rounds without the user converging, pause and summarize the trade-offs for a final decision.
The user can override: 
/ideate --max-iterations 5
设计迭代：最多3次（
deep
层级的发散循环）。如果阶段2经过3轮循环仍未达成用户收敛，暂停并总结权衡分析供最终决策。
用户可覆盖限制：
/ideate --max-iterations 5

Anti-Patterns

反模式

Don'tDo Instead
Jump to a solution immediatelyAsk clarifying questions first
Manufacture 2-3 options at thin/standardReserve the divergent loop for the 
deep
rung
Hide drawbacks of the preferred optionBe transparent about trade-offs
Write walls of textUse 200-300 word sections max
Ignore existing patternsReference codebase conventions
Write a separate 
docs/designs/
doc		Author the Design & Rationale § of the one 
docs/specs/
artifact
Auto-escalate to discoverSurface the bridge; escalate only on author confirmation
禁止行为正确做法
直接跳到解决方案先提出澄清问题
在thin/standard层级强行制造2-3个选项仅在
deep
层级使用发散循环
隐藏首选方案的缺点透明展示权衡分析
大段文字堆砌每个小节最多200-300字
忽略现有模式参考代码库约定
单独撰写
docs/designs/
文档		在统一的
docs/specs/
工件中撰写Design & Rationale部分
自动升级至discover展示桥接功能；仅在作者确认后升级

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. The feature workflow's initial phase is 
plan
 (the former ideate/GATHER phase was collapsed into PLAN) — there is no phase to transition into here.
使用
mcp__exarchos__exarchos_workflow
初始化工作流状态，参数为
action: "init"
、
workflowType: "feature"
及featureId。功能工作流的初始阶段为
plan
（原ideate/GATHER阶段已合并至PLAN）—— 无需在此阶段切换。

On Design-Section Save (after Phase 3)

设计部分保存后（阶段3之后）

Persist the unified-spec path as 
artifacts.spec
(NOT 
artifacts.design
— the new flow produces one 
docs/specs/
artifact):
text
action: "update", featureId: "<id>", updates: { "artifacts": { "spec": "<docs/specs/...>" } }
Do not transition the phase here — 
/plan
finalizes the unified doc with the 
## Decomposition
section and transitions 
plan → plan-review
.
将统一规范路径持久化为
artifacts.spec
（而非
artifacts.design
—— 新流程仅生成一个
docs/specs/
工件）：
text
action: "update", featureId: "<id>", updates: { "artifacts": { "spec": "<docs/specs/...>" } }
请勿在此阶段切换 —— 
/plan
会在统一文档中添加
## Decomposition
部分并完成
plan → plan-review
阶段切换。

Phase Transitions and Guards

阶段切换与守卫

This skill is the entry point for the feature workflow (
workflowType: "feature"
). The collapsed lifecycle is:
text
plan → plan-review → delegate ⇄ review → synthesize → completed
/ideate
and 
/plan
both author the one 
docs/specs/
artifact within the initial 
plan
phase. For the full transition table, consult 
@skills/checkpoint/references/phase-transitions.md
.
本Skill是功能工作流（
workflowType: "feature"
）的入口点。简化后的生命周期为：
text
plan → plan-review → delegate ⇄ review → synthesize → completed
/ideate
和
/plan
均在初始
plan
阶段内撰写统一的
docs/specs/
工件。完整的阶段切换表请参考
@skills/checkpoint/references/phase-transitions.md
。

Schema Discovery

模式发现

Use 
exarchos_workflow({ action: "describe", actions: ["update", "init"] })
for parameter schemas and 
exarchos_workflow({ action: "describe", playbook: "feature" })
for phase transitions, guards, and playbook guidance.
使用
exarchos_workflow({ action: "describe", actions: ["update", "init"] })
获取参数模式，使用
exarchos_workflow({ action: "describe", playbook: "feature" })
获取阶段切换、守卫及工作流指南。

Completion & Coverage

完成度与覆盖范围

There is no separate design-completeness gate in the collapsed flow — 
check_design_completeness
is a deprecated alias. The design section's acceptance-criteria coverage is validated as part of 
check_plan_coverage
over the unified artifact, run by 
/plan
once the 
## Decomposition
section exists. Before chaining, confirm each 
DR-N
carries acceptance criteria and at least one DR-N covers error handling / edge cases.
简化流程中无独立的设计完成度检查节点 —— 
check_design_completeness
已废弃。设计部分的验收标准覆盖范围会作为
check_plan_coverage
的一部分，在
## Decomposition
部分生成后由
/plan
验证。衔接前，需确认每个
DR-N
都包含验收标准，且至少一个DR-N覆盖错误处理/边缘情况。

Transition

流程衔接

After the Design & Rationale section is authored, auto-continue to decomposition (no user confirmation):
Design & Rationale部分撰写完成后，自动进入任务分解阶段（无需用户确认）：

Pre-Chain Validation (MANDATORY)

衔接前验证（强制）

Before invoking 
/plan
:
  1. Verify 
    artifacts.spec
    exists in workflow state
  2. Verify the spec file exists on disk: 
    test -f "$SPEC_PATH"
  3. If steps 1 or 2 fail: "Spec artifact not found, cannot auto-chain to /plan"
调用
/plan
前：
  1. 验证工作流状态中存在
    artifacts.spec
  2. 验证磁盘上存在规范文件：
    test -f "$SPEC_PATH"
  3. 若步骤1或2失败："未找到规范工件，无法自动衔接至/plan"

Chain Steps

衔接步骤

  1. Update state: 
    action: "update", featureId: "<id>", updates: { "artifacts": { "spec": "<docs/specs/...>" } }
  2. Output: "Design & Rationale section saved to the unified spec. Auto-continuing to decomposition..."
  3. Invoke immediately:
    typescript
    [Invoke the exarchos:plan skill with args: $SPEC_PATH]
This is NOT a human checkpoint. The single human checkpoint occurs at plan-review (the dispatched adversarial pass over the unified artifact) and at synthesize (merge confirmation).
Workflow continues: 
/ideate
-> 
/plan
-> plan-review -> [HUMAN CHECKPOINT] -> 
/delegate
-> 
/review
-> 
/synthesize
-> [HUMAN CHECKPOINT]
  1. 更新状态：
    action: "update", featureId: "<id>", updates: { "artifacts": { "spec": "<docs/specs/...>" } }
  2. 输出："Design & Rationale部分已保存至统一规范。自动进入任务分解阶段..."
  3. 立即调用：
    typescript
    [Invoke the exarchos:plan skill with args: $SPEC_PATH]
此步骤并非人工检查点。唯一的人工检查点为plan-review（针对统一文档的对抗式审核）及synthesize（合并确认）。
工作流继续： 
/ideate
-> 
/plan
-> plan-review -> [人工检查点] -> 
/delegate
-> 
/review
-> 
/synthesize
-> [人工检查点]

Exarchos Integration

Exarchos集成

When Exarchos MCP tools are available:
  1. At workflow start: Auto-emitted by 
    exarchos_workflow
    action: "init"
    — do NOT manually append 
    workflow.started
当Exarchos MCP工具可用时：
  1. 工作流启动时： 由
    exarchos_workflow
    的
    action: "init"
    自动触发 —— 请勿手动添加
    workflow.started
    ",