mcpField
O
oma-pm

oma-pm

github.com/gracefullightAgent 工作流49153 次安装1 天前更新
代码仓库

关于 oma-pm

oma-pm 是面向产品规划和协调多 Agent 执行的产品经理技能。它将需求拆分为带优先级、依赖关系和验收标准的任务，并生成供编排流程使用的计划产物。

主要功能

  1. 01澄清目标、约束与交付内容
  2. 02拆分任务并标注依赖关系
  3. 03定义优先级和验收标准
  4. 04起草 API 合约与数据模型
  5. 05检查风险、安全与测试覆盖
  6. 06生成 JSON 计划和任务看板

适用场景

  1. 01将复杂功能需求拆分为可执行任务
  2. 02规划冲刺并安排专业 Agent
  3. 03为接口变更定义 API 合约
  4. 04为编排执行准备计划文件

安装

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

$npx skills add https://github.com/gracefullight/stock-checker --skill oma-pm

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

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

resources/
error-playbook.md
examples.md
execution-protocol.md
iso-planning.md
plan-phase-protocol.md
task-template.json

详细介绍

PM Agent - 产品经理

调度

目标

将模糊或复杂的产品需求转化为可执行且考虑依赖关系的计划，明确任务、优先级、验收标准、API 契约以及风险／治理说明。

意图特征
  • 用户请求制定计划、需求、规范、范围、优先级、任务拆分、路线图或实施计划。
  • 用户需要将工作分解后交由专业 Agent 或编排器执行。
适用场景
  • 将复杂功能需求拆分为任务
  • 判断技术可行性并规划架构
  • 确定工作优先级并规划冲刺
  • 定义 API 契约和数据模型
不适用场景
  • 编写实际代码 → 委派给专业 Agent
  • 执行代码审查 → 使用 QA Agent
预期输入
  • 用户请求、产品目标、约束、目标用户和验收预期
  • 现有代码库上下文、架构约束和集成点
  • 可选的标准、风险、治理或编排要求
预期输出
  • JSON 计划以及兼容 task-board.md 的任务拆分
  • Agent 分配、标题、优先级、依赖关系、验收标准、安全／测试预期
  • 相关时提供 API 契约或数据模型草案
  • 将计划产物保存到 .agents/results/
outputs:
  - name: plan
    description: PM task breakdown JSON for orchestrator consumption
    artifact: ".agents/results/plan-*.json"
    required: true
依赖项
  • resources/execution-protocol.md、示例、任务模板和 ISO 规划指南
  • 共享的 API 契约参考资料和项目上下文加载规则
  • 用于实现的下游专业技能
控制流特性
  • 根据模糊程度、依赖结构、风险级别，以及是否需要标准／治理方面的说明进行分支处理
  • 生成规划产物，而非代码
  • 优化计划，使专业 Agent 能够并行执行任务

结构流程

入口
  1. 明确产品目标、约束和目标交付物。
  2. 识别技术领域和所需契约。
  3. 判断是否需要采用 ISO／风险／治理方面的框架。
阶段
  1. 准备：收集需求、约束和上下文。
  2. 推理：分解工作，识别依赖关系、风险以及 API／数据契约。
  3. 执行：生成 JSON 计划和兼容任务看板的输出。
  4. 验证：检查任务的原子性、验收标准、安全／测试覆盖情况以及依赖关系。
  5. 完成：保存计划产物并总结执行路径。
转换
  • 如果需求存在歧义，先澄清再进行分解。
  • 如果任务紧密耦合，完善契约或调整顺序。
  • 如果架构尚不明确，在制定实施计划前与架构团队协调。
  • 如果用户需要自动化执行，在计划获批后移交给编排器。
失败与恢复
  • 如果范围过广，将其拆分为多个阶段。
  • 如果验收标准含糊，将其改写为可测试的结果。
  • 如果依赖关系阻碍并行执行，明确指出执行顺序。
出口
  • 成功：计划可执行、可测试、已确定优先级，并兼容编排器执行。
  • 部分成功：明确列出尚未解决的假设或依赖关系。

逻辑操作

操作
操作SSL 原语依据
读取需求／上下文READ用户请求和项目上下文
选择规划结构SELECT任务模板和工作流需求
推断任务和依赖关系INFER领域分解
验证验收标准VALIDATE检查清单和任务架构
编写计划产物WRITEJSON 计划和任务看板 Markdown
通知计划摘要NOTIFY最终规划报告
工具和辅助资料
  • 任务模板、示例、ISO 规划指南、共享 API 契约
  • 用于保存结果产物的本地文件系统
标准工作流路径
1. Define API/data contracts.
2. Decompose tasks with agent, title, priority, dependencies, and acceptance criteria.
3. Save `.agents/results/plan-{sessionId}.json` using the injected session ID. Write the run-scoped report from the shared memory/result contract.
资源范围
范围资源目标
MEMORY需求、假设、依赖项
LOCAL_FS.agents/results/plan-{sessionId}.json、注入的声明路径以及任务/运行范围内的报告
CODEBASE可选的项目上下文以及 API/数据模型参考
前置条件
  • 产品目标和规划边界足够明确。
  • 能够识别所需的实现领域。
影响和副作用
  • 创建计划工件和任务看板。
  • 影响下游 Agent 的分配和执行顺序。
  • 不直接实现代码。
护栏
  1. 对于有变更的接口，在依赖该接口的实现任务之前，复用或定义 API/数据契约
  2. 每项可执行任务都包含：Agent、标题、{id, description} 验收标准、涵盖 required_checks（含确切的 argv/cwd）、可重放的 task 提示词、优先级层级（1 = 独立，数字越小越先运行）、依赖项和范围
  3. 尽量减少依赖项，以实现最大程度的并行执行
  4. 安全和测试是每项任务的一部分（而非单独阶段）
  5. 单个 Agent 应能够完成每项任务
  6. 输出 JSON 计划 + task-board.md，以兼容编排器
  7. 相关时，使用 ISO 21500 概念来组织计划，采用 ISO 31000 思路进行风险优先级排序，并参考 ISO 38500 提出职责/治理建议
常见陷阱
  • 过于细分：“实现用户认证 API”是一项任务，而不是五项
  • 任务含糊：“让它更好” -> “为所有表单添加加载状态”
  • 耦合紧密：任务应使用公共 API，而不是内部状态
  • 延后质量保障：测试是每项任务的一部分，而不是最后阶段

参考资料

  • 本地代码工具：../_shared/core/code-intelligence.md（代码搜索/导航）

  • 运行时身份和运行范围内的报告：../_shared/runtime/memory-protocol.md、../_shared/runtime/result-contract.md

  • 执行步骤（针对选定任务遵循）：resources/execution-protocol.md

  • 计划示例：resources/examples.md

  • ISO 规划指南：resources/iso-planning.md

  • 错误恢复：resources/error-playbook.md

  • 任务架构：resources/task-template.json

  • Ultrawork PLAN 阶段协议：resources/plan-phase-protocol.md（此技能在 ultrawork 工作流中运行时使用）

  • 任务看板规范（编排器使用的格式）：../oma-orchestration/resources/memory-schema.md

  • 人类可读的跟踪文档：在 /plan 工作流中运行时，还要根据 .agents/workflows/plan.md 生成 docs/plans/work/{NNN}-{name}.md

  • API 契约模板（SSOT）：../_shared/core/api-contracts/template.md；将生成的契约写入 .agents/results/api-contracts/（运行工件）或 docs/plans/contracts/（持久规范）

  • 上下文加载：../_shared/core/context-loading.md

  • 规划深度：../_shared/core/difficulty-guide.md（范围或依赖项尚未明确时）

  • 澄清：../_shared/core/clarification-protocol.md

  • 上下文预算：../_shared/core/context-budget.md

  • 经验总结：../_shared/core/lessons-learned.md（存在相关的过往失败或用户要求复盘时）

评论

支持 Markdown