ideate

头脑风暴技能

概述

协作探索新功能设计、架构决策和复杂问题的解决方案。在精简流程中，没有单独的设计阶段——{{COMMAND_PREFIX}}ideate 会编写同一份统一的 docs/specs/ 文档中的 ## Design & Rationale 部分，然后自动接续到 {{COMMAND_PREFIX}}plan，由后者向同一份文档添加 ## Decomposition 部分。唯一的审批节点是 plan-review（对统一文档进行的对抗性审查，由已分派的审查者在全新上下文中执行）。

文档结构由统一规范模板规定——请据此编写，不要重复说明：参见 @skills/plan/references/spec-template.md。

触发条件

在以下情况下启用此技能：

• 用户说“我们来头脑风暴”“我们来构思”或“我们来探索”
• 用户运行 {{COMMAND_PREFIX}}ideate 命令
• 用户希望在拆解任务前讨论设计依据
• 一个问题有多个可行方案，需要进行评估（deep 档）

完整的演示示例请参见 references/worked-example.md。

规划深度（默认单轮完成；deep 档才启用发散循环）

设计部分分为三个深度级别，每个功能在进入 PLAN 时解析并冻结为 designDepth，相当于每项任务的 riskTier。解析器根据简述中的信号（不确定性、影响范围、任务数量）建议一个深度；作者确认或覆盖。较高档位严格包含较低档位的全部内容。

designDepth	此技能的行为	适用情况
thin	单轮完成：问题陈述 + DR-N 列表。不列备选方案，不进行探索。	影响范围小的简单功能，拆解内容就是重点。
standard	单轮完成：完整设计依据（问题、所选方案、包含验收标准的 DR-N、技术设计、备选方案）。（默认）	大多数功能。
deep	执行下方的发散循环：探索 2–3 个真正不同的方案，坦诚说明取舍并与用户来回讨论，另加可选的 discover 桥接流程。	不确定性高或影响范围大的功能，适合开放式设计流程。

**探索 2–3 个方案属于 deep 档，而非默认流程。**在 thin/standard 档中，应在一轮内收敛；不要为不需要备选方案的问题硬凑方案。

流程

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

**目标：**在提出澄清问题之前，先梳理与提案相关的架构不变量，让设计从第一轮起就以承重约束为锚点。

加载 .exarchos/invariants.md 中的核心不变量目录（标记为 cost-of-load: always-load 的条目），并列出 Constraints 部分，指出相关不变量——例如，CLI / Agent 优先的界面提案应以 INV-5a（输入体验）和 INV-5c（Aspire 动词）为锚点。完整的选择规则包括：always-load 基线与按需加载的 reference-only，不展示的 archivable，提案形态到锚点不变量的映射表，输出格式，以及目录注册门控（仅当目录在 invariants.catalogs 下注册时才展示）。这些内容是 /ideate、/refactor 和 /debug 所用设计阶段 Constraints 步骤的唯一共享事实来源。参见 @skills/ideate/references/constraint-anchoring.md。

在阶段 1 之前，按照该参考文档输出 Constraints 部分，以便澄清问题能够针对承重不变量探究提案，而不是在设计过程中再重新发现它们。

第 1 阶段：理解

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

规则：

• 一次只问一个问题
• 等待回复后再问下一个问题
• 重点关注：目标、约束、现有模式、用户偏好
• 转入下一阶段前最多提问 5 个

问题类型：

1. “我们要解决什么问题？”（核心需求）
2. “有哪些约束？”（时间、技术、兼容性）
3. “代码库中已有何种模式？”（保持一致）
4. “谁/什么会使用它？”（用户、API、其他系统）
5. “怎样才算成功？”（验收标准）

第 2 阶段：探索——仅限 deep 档

目标（当 designDepth: 'deep' 时）： 提出 2-3 种截然不同的方案，坦诚说明权衡，推荐其中一种，并通过人与人之间的往返交流逐步达成一致。

使用 references/design-template.md 中的方案格式。提出真正不同的方案，并说明推荐理由。可选的 discover 桥接： 在 deep 档，运行时会通过 next_actions 发布 discover 桥接入口（DR-7）——一个与事件关联、由 correlationId 串联到 {{COMMAND_PREFIX}}discover 研究工作流的升级选项。它绝不会自动运行；应向作者展示，并且仅在确认后升级。在“探索”部分引用 discover 报告的路径和 correlationId，使来源信息贯穿两份文档。

在 thin/standard 档，跳过此阶段，直接在第 3 阶段达成一致。

第 3 阶段：编写“设计与理由”部分

目标： 按照 @skills/plan/references/spec-template.md 中的结构，基于确定的深度，编写统一 docs/specs/ 文档中的 ## Design & Rationale 部分。每个部分最多 200-300 个词；复杂流程应使用图表。

需求格式（强制）：

• 使用编号的需求标识符：在 ### Requirements (DR-N) 标题下列出 DR-1、DR-2、……、DR-N
• 每条需求都必须包含一个 **Acceptance criteria:** 区块，其中列出具体、可测试的标准（thin 档可使用单个项目符号）
• 至少一条需求必须涉及错误处理、故障模式或边缘情况
• 这些 DR-N 标识符是来源锚点——## Decomposition 部分会在同一份文档内追溯任务与它们的关系（不使用第二份文件）

保存位置： docs/specs/YYYY-MM-DD-<feature>.md。将路径保存为 $SPEC_PATH。

迭代限制

设计迭代：最多 3 轮（deep 档的发散循环）。如果第 2 阶段经过 3 轮仍未能与用户达成一致，请暂停并总结权衡，交由用户最终决定。

用户可以覆盖此限制：{{COMMAND_PREFIX}}ideate --max-iterations 5

反模式

不要	应改为
立即跳到解决方案	先提出澄清问题
在 thin/standard 档凭空制造 2-3 个选项	将发散循环留给 deep 档
隐瞒首选方案的缺点	坦诚说明权衡
写大段文字	每个部分最多 200-300 个词
忽视现有模式	参照代码库惯例
单独编写 docs/designs/ 文档	在统一 docs/specs/ 文档中编写“设计与理由”部分
自动升级到 discover	展示桥接选项；仅在作者确认后升级

状态管理

此技能会管理工作流状态，以便在上下文之间持久化。

启动时（第 1 阶段之前）

使用 {{MCP_PREFIX}}exarchos_workflow 初始化工作流状态，设置 action: "init"、workflowType: "feature" 和 featureId。功能工作流的初始阶段为 plan（原先的 ideate/GATHER 阶段已并入 PLAN）——此处无需转换到其他阶段。

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

将统一规格文档路径保存为 artifacts.spec（而非 artifacts.design——新流程只生成一份 docs/specs/ 文档）：

action: "update", featureId: "<id>", updates: { "artifacts": { "spec": "<docs/specs/...>" } }

此处不要转换阶段——{{COMMAND_PREFIX}}plan 会在统一文档中完成 ## Decomposition 部分，并将阶段从 plan 转换为 plan-review。

阶段转换与守卫条件

此技能是功能工作流（workflowType: "feature"）的入口。精简后的生命周期如下：

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

{{COMMAND_PREFIX}}ideate 和 {{COMMAND_PREFIX}}plan 都会在初始 plan 阶段内编写唯一的 docs/specs/ 工件。完整的转换表请参阅 @skills/checkpoint/references/phase-transitions.md。

架构发现

使用 exarchos_workflow({ action: "describe", actions: ["update", "init"] }) 获取 参数架构，使用 exarchos_workflow({ action: "describe", playbook: "feature" }) 获取阶段转换、守卫条件和操作手册指南。

完成度与覆盖率

精简流程中没有单独的设计完整性门槛——check_design_completeness 是已弃用的别名。设计部分的验收标准覆盖率会在统一工件上通过 check_plan_coverage 进行验证；当 ## Decomposition 部分存在后，由 {{COMMAND_PREFIX}}plan 运行。在继续串联流程前，请确认每个 DR-N 都包含验收标准，并且至少有一个 DR-N 涵盖错误处理／边缘情况。

转换

编写完 Design & Rationale 部分后，自动继续到分解阶段（无需用户确认）：

串联前验证（必须）

调用 {{COMMAND_PREFIX}}plan 前：

1. 确认工作流状态中存在 artifacts.spec
2. 确认磁盘上存在规格文件：test -f "$SPEC_PATH"
3. 如果步骤 1 或 2 失败："未找到规格工件，无法自动串联到 {{COMMAND_PREFIX}}plan"

串联步骤

1. 更新状态：action: "update", featureId: "<id>", updates: { "artifacts": { "spec": "<docs/specs/...>" } }
2. 输出："Design & Rationale 部分已保存到统一规格文档。正在自动继续到分解阶段……"
3. 立即调用：

   {{CHAIN next="plan" args="$SPEC_PATH"}}
   

这不是人工检查点。唯一的人工检查点位于 plan-review（对统一工件执行的对抗性审查）和 synthesize（合并确认）阶段。

工作流继续： {{COMMAND_PREFIX}}ideate -> {{COMMAND_PREFIX}}plan -> plan-review -> [人工检查点] -> {{COMMAND_PREFIX}}delegate -> {{COMMAND_PREFIX}}review -> {{COMMAND_PREFIX}}synthesize -> [人工检查点]

Exarchos 集成

当 Exarchos MCP 工具可用时：

1. **工作流开始时：**由 exarchos_workflow 的 action: "init" 自动发出——不要手动追加 workflow.started