Monitoring orchestrator

Skill LuckyOneTwoThree/pm-skill/pm-07-monitoring/orchestrators/monitoring-orchestrator

102 AI Agent Skills for the full product lifecycle. Compatible with Trae / Claude Code. 9 modules from discovery to launch to growth. | 102 个覆盖产品全生命周期的 AI Agent Skills，兼容 Trae / Claude Code，9 大模块从探索发现到上线增长。

Install

npx -y skills add LuckyOneTwoThree/pm-skill --skill monitoring-orchestrator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

当需要建立产品监控体系或处理异常告警时使用。监控预警指挥官，调度 monitoring-pipeline、user-feedback-loop-report 子Skill执行。关键词：监控预警、异常检测、告警分级、监控系统、健康监控、监控仪表盘、告警升级、反馈闭环、线上告警、系统监控。

SKILL.md

7.8 KB, as published. Nobody here has run it

监控预警指挥官

核心原则

让问题在用户发现之前被解决

监控的最高境界不是快速响应，而是提前预防。当用户感知到问题时，损害已经发生。监控系统的价值在于将问题发现的时间点前移到用户感知之前。

编排理念

体系先行，告警跟进，升级兜底：先构建监控体系建立基线，再基于告警归因精准响应，最后用升级机制兜底
数据在体系→归因→升级间递进流转：监控体系定义告警规则，告警归因提供根因，升级机制基于根因精准通知

编排协议

编排协议遵循 orchestrator-protocol.md 统一标准。

Pipeline

pipeline: monitoring-orchestrator
version: 9.0

post_pipeline:
  - action: stage-summary
    output: output/phase-reports/pm-monitoring/monitoring-orchestrator.md

stages:
  - id: phase-1
    name: "监控预警Pipeline"
    depends_on: []
    skills: [monitoring-pipeline]
    gate:
      condition: "监控预警全流程完成（核心路径覆盖率≥95%，告警噪音率<15%）"
      fail_action: "补充缺失路径的监控配置、优化告警规则"

  - id: phase-2
    name: "用户反馈闭环"
    depends_on: [phase-1]
    skills: [user-feedback-loop-report]
    trigger: 用户反馈闭环需求
    gate:
      condition: "反馈闭环报告经人类审核确认"
      fail_action: "补充分析或修改改进建议"

阶段执行计划

调用 monitoring-pipeline

Skill: monitoring-pipeline
输入:
  product_architecture: 用户提供
  metrics_system: metrics-system → metric_system.json
  sla_requirements: 用户提供
  release_info: release-gradual → release_record.json（可选）
  user_roles: 用户提供
  oncall_schedule: 值班管理系统 → 排班表
输出: output/pm-monitoring/monitoring-pipeline/
验证: 核心路径覆盖率≥95%；每个核心路径至少有4个黄金指标；告警噪音率<15%；告警分类准确率≥85%；所有角色都有对应Dashboard；告警分级准确率≥90%；升级触发及时性100%
模式: 🤖

调用 user-feedback-loop-report

Skill: user-feedback-loop-report
输入:
  voice_analysis: user-research-voice-analysis（可选）
  anomaly_monitoring: monitoring-pipeline（可选）
  feedback_data: 用户提供
输出: output/pm-monitoring/user-feedback-loop-report/
验证: 闭环率可计算；P0未解决已列出；改进建议可执行
模式: 🤖→👤

阶段总结（post_pipeline）

所有业务阶段执行完成后，必须立即生成阶段总结文档：

动作: 生成阶段总结
输入:
  所有子Skill输出: output/pm-monitoring/
  人类决策记录: 本轮执行中的人类决策点及结果
输出: output/phase-reports/pm-monitoring/monitoring-orchestrator.md
验证: 阶段总结文档已生成，6项结构（执行概览/关键发现/决策记录/产出清单/风险与待办/下游衔接）均非空
下游衔接:
  primary:
    target: diagnosis-orchestrator
    reason: 监控预警建立完成，如发现异常进入诊断定位根因
    input_mapping:
      monitoring_output: "output/pm-monitoring/monitoring-pipeline/ → diagnosis-health输入"
  alternatives:
    - target: release-orchestrator
      reason: 监控发现需发布修复
      condition: 监控预警触发P0/P1级异常需紧急修复时
    - target: iteration-orchestrator
      reason: 监控数据表明需调整迭代优先级
      condition: 监控指标趋势持续恶化，需调整迭代方向时
  special_cases:
    - target: monitoring-pipeline
      reason: 仅需搭建监控，无需完整监控编排
      condition: 已有反馈闭环机制，仅需监控预警配置时
模式: 🤖

⏸ 阶段卡口：阶段总结文档已生成且6项结构均非空 → 未通过：补充缺失结构项后重新生成

阶段卡口

卡口	条件	未通过处理
监控预警全流程完成	monitoring相关输出文件已生成且非空	补充缺失路径的监控配置、优化告警规则、补充可视化配置或升级规则
反馈闭环报告已审核	反馈闭环报告经人类审核确认	补充分析或修改改进建议
阶段总结已生成	output/phase-reports/pm-monitoring/monitoring-orchestrator.md 已生成且6项结构均非空	补充缺失结构项后重新生成

人类决策点

决策点	触发条件	决策内容
告警阈值调整	告警噪音率过高或漏报率过高	确认告警阈值调整方案
仪表盘布局确认	仪表盘构建完成	确认核心指标展示和布局
升级策略确认	升级规则生成完成	确认升级路径和通知渠道配置
反馈闭环报告确认	反馈闭环报告生成完成	确认闭环率和改进建议

异常处理

异常类型	处理策略
监控体系核心路径覆盖率不足（<80%）	暂停后续阶段，要求用户补充产品架构信息以完善核心路径
告警噪音率过高（>30%）	暂停告警分析，回退至监控体系优化告警规则后再继续
On-Call排班缺失	使用默认升级规则，标注"排班待配置"，P0告警直接通知产品负责人
子Skill输出校验未通过	回退至当前阶段重新执行，最多重试1次；仍失败则标记异常并上报人类
上下游数据格式不兼容	按下游子Skill输入Schema做字段映射和默认值填充，记录映射关系
阶段总结生成失败	基于已完成的子Skill输出生成部分总结，缺失项标注"数据缺失"，不阻塞编排完成
发布需求	转交 release-orchestrator 处理

变更记录

v1.0: 初始版本
v2.0: 结构优化
v3.0: 新增 user-feedback-loop-report（用户反馈闭环报告）
v4.0: 改造为子Skill执行协议+阶段执行计划模式，增加命令式调度规则
v5.0: 执行步骤替换为编排理念，新增异常处理表
v6.0: 编排协议优化——将"读取子Skill定义并代理执行"改为"使用Skill工具显式调用子Skill"；新增Pipeline定义（YAML声明式执行图）；阶段执行计划改为调用指令格式；调度规则合并入编排协议
v6.1: 阶段总结强化——Pipeline新增post_pipeline定义；调用规则第6条改为强制执行；阶段执行计划新增阶段总结执行指令；阶段卡口新增阶段总结校验；异常处理新增阶段总结生成失败策略
v7.0: 合并 monitoring-system + monitoring-anomaly + monitoring-dashboard + monitoring-escalation → monitoring-pipeline；4阶段Pipeline简化为1阶段；更新所有引用和输出路径
v8.0: 新增 quality-acceptance、release-gradual、release-auto-checklist、release-notes——从pm-05迁移；Pipeline新增4个触发阶段；阶段执行计划新增4个子Skill调用；阶段卡口新增4项；人类决策点新增质量验收放行决策和灰度发布策略确认
v9.0: 拆分发布交付阶段至 release-orchestrator；移除 quality-acceptance、release-auto-checklist、release-gradual、release-notes；Pipeline精简为2阶段；异常处理新增"发布需求→转交release-orchestrator"