oma-brainstorm

Brainstorm - 设计优先的构思

调度

目标

在规划或实施之前，探索用户意图、约束和备选方案，然后保留经批准的设计，供后续规划使用。

意图特征

• 用户表示自己有一个想法，想进行头脑风暴、比较方案、探索概念，或在规划前先进行设计。
• 请求足够模糊，若直接实施或规划任务还为时过早。

适用场景

• 规划前探索新的功能构想
• 在确定方案之前了解用户意图和约束
• 比较多个设计方案及其权衡
• 用户说“我有个想法”或“我们来设计点什么”时
• 对复杂或模糊的请求调用 /plan 之前

不适用场景

• 需求已经清楚明确 -> 直接使用 oma-pm
• 实际编写代码 -> 委派给专用 Agent
• 进行代码审查 -> 使用 oma-qa
• 调试现有问题 -> 使用 oma-debug

预期输入

• 初步构想、模糊目标、产品概念、设计问题或一组约束
• 当构想必须契合代码库或产品方向时，提供现有项目背景
• 用户偏好和审批关卡

预期输出

• 明确的意图和约束
• 以简要文字说明呈现的可行方案（场景、机制、剩余风险）；在有助于决策时进行比较并给出建议
• 经逐节批准的设计文档
• 盲审问题清单（第 1 级问题已解决，第 2/3 级问题已解决或明确延期）
• 交接给规划流程前保存的设计产物

依赖项

• 共享上下文加载、推理模板、澄清协议、质量原则和技能路由
• 可选的 resources/triz-lite.md，用于以矛盾为导向生成方案
• 按 Agent 分配审阅者（例如 qa-reviewer、architecture-reviewer），用于高风险盲审升级路径
• 设计获批后用于任务分解的下游 PM 工作流

控制流特性

• 根据模糊程度、用户回答、方案比较和审批关卡进行分支
• 技术或 UX 矛盾阻碍形成不同方案时，可选用 TRIZ-lite 分支
• 每次只提一个问题
• 保存前进行一轮盲审；对于高风险设计，可能会派发具有独立上下文的审阅者子 Agent（这是此技能中唯一会派生子 Agent 的路径）
• 在实施或任务规划之前停止

结构流程

入口

1. 确认请求是探索性的，而非已准备好实施。
2. 加载足够的项目背景以了解约束。
3. 从意图和约束入手，而非直接提出解决方案。

阶段

1. PREPARE：探索背景并界定设计问题。
2. ACQUIRE：每次提出一个澄清问题。
3. REASON：在有助于决策时比较可行方案及其权衡；若只剩一个方案，则说明决定性约束。
4. VERIFY：复用现有设计决策依据，仅解决重要的未决选择，然后在保存前进行一轮盲审（审阅者独立评议，彼此不可见对方的反馈）。
5. FINALIZE：保存设计，并在适当时转入规划阶段。

状态转换

• 如果需求变得清晰且已具备实施条件，则转入 PM 规划。
• 如果用户否定某个方案，则先修改方案，再进入详细设计。
• 如果过早出现实施压力，则推迟到设计获批之后处理。
• 如果不同方案最终只是在同一维度上调整参数，则加载 resources/triz-lite.md 重新生成方案，然后再次以简要文字说明呈现。

失败与恢复

• 如果用户无法回答某个问题，则提出假设并请求确认。
• 如果范围扩大，则将设计拆分为更小的部分。
• 如果多个备选方案收敛为一个选项，则找出导致这种情况的实际约束；只有当该约束属于技术或 UX 矛盾时，才使用 TRIZ-lite。

退出

• 成功：已批准的设计已存在，可进入规划阶段。
• 部分成功：未解决的问题和假设均已明确。

逻辑操作

操作

操作	SSL 原语	证据
阅读上下文和想法	READ	用户提示词和项目上下文
提出有针对性的问题	REQUEST	澄清阶段
比较方案	COMPARE	权衡矩阵
推断建议	INFER	推荐选项
记录选项选择	CALL_TOOL	实际方案、比较证据、设计／选项修订；以及在活动 OMA 工作流中匹配的 instanceId 和验证器 --instance
确定设计决策权	VALIDATE	对尚未解决的重要设计选择，依据现有指示、授权决定或明确答复
进行盲审	VALIDATE	独立视角的评审意见、分级问题列表、第 1 级问题的解决情况
编写设计文档	WRITE	docs/plans/designs/ 和记忆
转入规划阶段	NOTIFY	交接摘要

工具和手段

• 上下文加载、推理模板、澄清协议
• 可选的 TRIZ-lite 资源，用于引出矛盾
• 项目记忆和 docs/plans/designs/，用于保存设计

标准工作流路径

1. Ask one clarifying question at a time.
2. (Optional) If technical/UX contradiction or same-axis approaches only → resources/triz-lite.md.
3. Present viable alternatives as prose briefs and compare them when useful; do not invent extra options to meet a count; reuse an existing selection or delegated choice and resolve only an open material choice. In an active OMA workflow, record the actual approach, rationale, evidence, and design/option revision with `brainstorm.option-selection`; verify the matching --instance (workflow Step 3 owns the commands).
4. Design section by section within existing authorization, then blind review: independent lenses suited to the uncertainty and stakes critique the design; resolve Tier 1 issues (fresh-context reviewer subagents for high-stakes designs).
5. Save the approved design to `docs/plans/designs/` before handing off to planning.

资源范围

范围	资源目标
MEMORY	用户意图、假设、决策
CODEBASE	相关时使用的现有项目上下文
LOCAL_FS	已批准的设计文档；设计文档中可选的 TRIZ-lite 附录

前置条件

• 用户仍在探索阶段，或请求存在歧义。
• Agent 可以在实施前提出澄清问题。

影响和副作用

• 产出设计决策并保存设计文档。
• 影响后续规划，但不实施代码。

防护规则

1. 设计获批前不得实施或规划 - 头脑风暴会产出设计文档，而不是代码或任务计划
2. 一次只问一个问题 - 首先通过可用的异步提问工具提出澄清和审批问题，并遵循 ../_shared/core/clarification-protocol.md；如果无法使用，则改用获准的提问工具或纯文本。等待答复期间继续独立工作，绝不得根据沉默或预选选项推断已获批准。
3. 比较可行方案 - 当有助于决策时，提供两到三个方案；如果可选方案更少，则说明限制。根据实际目标、投入、可逆性和风险提出建议。不得仅因结构变更规模较大就优先选择该方案。
4. 用文字说明可行方案 - 说明适用场景、运作机制、剩余风险和投入。比较矩阵有助于决策时可使用，然后给出建议；如果只有一个受限选项，只需说明选择理由，不要虚构替代方案
5. 逐节设计 - 分阶段呈现设计；复用现有决策和已授权的决策权，仅根据共享执行策略询问尚未解决的重要选择
6. 保存前进行盲审 - 除非设计极其简单（1-2 个文件、低风险），否则必须盲审；不同视角须独立评审；对于架构上影响重大、难以逆转或涉及安全／合规的设计，使用具有全新上下文的评审子 Agent
7. YAGNI - 避免过度设计；只设计实现既定目标所需的内容
8. TRIZ-lite 为可选项 - 仅用于技术／用户体验矛盾或同一维度上的收敛；从精选集合中最多选用 3-5 条原则；不得使用虚假评分、完整 TRIZ／ARIZ 或经典矩阵；引出的思路用于第 3 步简述，不能替代用户审批
9. 先保存设计，再转入下一阶段 - 先保存已批准的设计文档，再交接给 /plan

执行阶段

按步骤遵循头脑风暴工作流：

1. 阶段 1 - 上下文：探索现有代码库，了解项目概况
2. 阶段 2 - 提问：一次提出一个澄清问题，以了解意图和限制条件
3. 阶段 3 - 方案：对于确实存在的矛盾，可选择用 TRIZ-lite 启发思路；用文字比较可行方案，并根据已说明的限制条件、工作量、可逆性和风险给出建议
4. 阶段 4 - 设计：逐节呈现详细设计，保留现有授权，只解决尚未确定的重要选择
5. 阶段 5 - 盲审：根据设计的不确定性和利害关系，采用适当的独立审查视角，将问题归纳为 Tier 1/2/3，并在保存前解决 Tier 1 问题；对于高风险设计，升级至全新上下文的审查子 Agent。仅对规模极小的设计（1-2 个文件、低风险）跳过此阶段
6. 阶段 6 - 文档：将获批设计保存到 docs/plans/designs/ 和项目记忆中
7. 阶段 7 - 过渡：移交给 /plan 进行任务拆解

常见陷阱

• 急于提供解决方案：尚未充分了解“是什么”和“为什么”，就开始询问“怎么做”
• 一次提问过多：一口气抛出一堆问题，让用户应接不暇
• 偏向单一方案：不解释限制条件，就跳过可行的替代方案
• 只用矩阵列方案：只给出权衡表，不用场景或机制方面的文字说明，导致用户无法选择
• 同一维度的“替代方案”：将同一参数的三种取值（间隔/TTL/防抖）当成不同方案
• 事事都用 TRIZ：没有真实矛盾也加载 triz-lite，徒增繁文缛节，却没有带来更好的方案
• 过度设计：针对假设中的未来需求进行设计，而非围绕已提出的需求
• 擅自赋予设计决策权：将 Agent 的建议视为用户已批准其负责的未决选择，或再次询问已获授权的选择
• 跳过盲审：未经过独立评审就保存非简单设计，或让设计者上下文泄露到升级审查的提示中

参考资料

• TRIZ-lite（可选的步骤 3 启发）：resources/triz-lite.md
• 上下文加载：../_shared/core/context-loading.md
• 澄清协议：../_shared/core/clarification-protocol.md
• 质量原则：../_shared/core/quality-principles.md
• 技能到 Agent 的映射：../_shared/core/skill-routing.md