mcpField
O
oma-brainstorm

oma-brainstorm

github.com/first-flukeAgent 工作流1.4k61 次安装今天更新
代码仓库

关于 oma-brainstorm

oma-brainstorm 是面向 Agent 的设计优先技能，用于处理早期或含糊的构想。它先澄清意图、比较方案，再保存获批设计供后续规划。

主要功能

  1. 01澄清意图与约束
  2. 02比较方案及权衡
  3. 03逐节展开设计
  4. 04进行独立盲审
  5. 05保存获批的设计文档

适用场景

  1. 01规划前探索功能构想
  2. 02比较产品想法的不同方案
  3. 03实施前厘清模糊需求

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/first-fluke/oh-my-agent --skill oma-brainstorm

安装后在 Claude Code 中输入/oma-brainstorm确认已加载。

附带文件resources/triz-lite.md

详细介绍

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 级问题的解决方案
编写设计文档WRITEdocs/decisions/ 和关联的协调摘要
转入规划阶段NOTIFY交接摘要
工具和手段
  • 上下文加载、推理模板、澄清流程
  • 可选的 TRIZ-lite 资源，用于引出矛盾
  • 项目记忆，用于存放协调摘要；docs/decisions/ 用于保留方案提案
规范工作流路径
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 approach to `docs/decisions/{NNN}-{name}.md` and update `docs/decisions/index.md` before handing off to planning. Keep this directory versioned. Read `docs/plans/designs/` and `docs/design-docs/` only as legacy fallback until migration; `design` names UI work.
资源范围
范围资源目标
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 为可选项 - 仅用于技术／UX 矛盾或同轴坍缩；从精选集合中最多选择 3-5 条原则；不得伪造评分、使用完整 TRIZ/ARIZ 或经典矩阵；这些原则仅用于为步骤 3 编写简报，不替代用户审批
  9. 保存选定方案，然后转交 - 在交接至 /plan 前，先将方案持久化到 docs/decisions/。针对单次运行的评审意见和 result-*.md 报告应放在 .agents/results/；将文档移入 docs/ 时，在源报告中保留目标位置
执行阶段

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

  1. 阶段 1 - 上下文：探索现有代码库，了解项目全貌
  2. 阶段 2 - 提问：一次提出一个澄清问题，以了解意图和约束
  3. 阶段 3 - 方案：遇到实际矛盾时，可选用 TRIZ-lite 作为启发；用文字比较可行方案，并根据已说明的约束、工作量、可逆性和风险提出建议
  4. 阶段 4 - 设计：逐节呈现详细设计，保留现有授权，仅解决尚未确定的重要选项
  5. 阶段 5 - 盲审：根据设计的不确定性和利害程度，采用独立的审查视角；将问题归纳为 Tier 1/2/3，并在保存前解决 Tier 1 问题；对于高风险设计，升级至全新上下文的审查子 Agent。仅对极其简单的设计（1-2 个文件、低风险）跳过此步骤
  6. 阶段 6 - 文档：将已批准的方案保存到 docs/decisions/{NNN}-{name}.md，更新其索引，并在项目记忆中记录一份关联的协调摘要
  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

评论

支持 Markdown