n9e-notify-rule-copilot

name: n9e-notify-rule-copilot description: 夜莺(n9e)通知规则(notify_rule)的创建、编辑、复制、排障一站式助手。当用户要求"创建通知规则 / 添加通知策略 / 配置告警通知方式 / 编辑调整通知规则 / 分级通知 / 按业务组或标签路由 / 工作时间与非工作时间不同动作 / 恢复时不打电话 / 修复规则匹配不上"时使用——尤其擅长把自然语言路由需求拆成正确的 NotifyConfig 数组。本技能专注通知规则的路由层：不动通知媒介本身（→ n9e-notify-channel-copilot），不动消息模板（→ n9e-generate-message-template），不查"为什么没发出"（→ n9e-alert-rule-troubleshoot 流程 B）。 tags: - internal

夜莺(n9e) 通知规则 Copilot

通知规则定义告警事件的通知方式、通知对象、通知时段和过滤条件，可被多条告警规则关联引用。本技能覆盖通知规则的创建、编辑、复制、路由拆解、排障全流程。

配套资料（按需用 read_file 加载，base 填本技能名）

适用范围（先确定用户在改哪一层）

夜莺的通知链路是三层抽象，每层一个 skill，不要串台：

判断口径：

• 原话出现"URL / Webhook 地址 / 请求头 / 代理 / 签名 / AppID / AppSecret / 怎么接入 X"——媒介层，转 n9e-notify-channel-copilot。
• 原话出现"模板 / 正文 / 字段 / 卡片颜色 / @ 谁 / {{ ... }} 变量"——模板层，转 n9e-generate-message-template。
• 原话出现"发给谁 / 什么级别走什么通道 / 工作时间 / 按业务组路由 / 按标签过滤 / 适用属性 / 编辑现有规则"——规则层，本 skill。
• 原话出现"事件已经产生但没收到通知，帮我看为什么"——事后诊断，转 n9e-alert-rule-troubleshoot 流程 B。本 skill 只负责"调出正确的规则配置"，不负责回放日志。

前提

你是 n9e 站内 AI 助手，运行在 n9e 进程内、已以当前用户身份认证。直接调用内置工具操作，不要登录、不要调 HTTP API、不要用 http_fetch 打自家接口（HTTP 流程见 http-api.md，那是给外部 A2A agent 的）。

心智模型 NotifyRule + NotifyConfig

一条 NotifyRule 像一个文件夹，里面装 N 个 NotifyConfig，每个 NotifyConfig 是一条独立的"路由"——有自己的级别/时间/标签/属性过滤、走自己的媒介、用自己的模板、发给自己的接收人。多条 NotifyConfig 之间是并列 OR：一个事件命中哪条就走哪条，可以同时命中多条都发。

这就是为什么"P1 工作时间发钉钉+电话、非工作时间只电话"要拆成 3 条 NotifyConfig（见 recipes.md 模板 B）。

两个最容易误解的字段：

• user_group_ids 是授权团队，不是接收人——决定谁能看到/编辑/引用这条规则；接收人由每条 NotifyConfig 的 params.user_ids / params.user_group_ids 决定。空 user_group_ids + 非 admin 用户 → 只有 admin 看得到。
• 模板只做"内容渲染"，不做"路由决策"——用户想"在模板里 if-else 判断级别"时，引导他拆 NotifyConfig。

config 核心结构

{
  "name": "通知规则名称",
  "description": "建议写明路由意图，如：P1 全天 + P2/P3 工作时间通知运维",
  "enable": true,
  "user_group_ids": [1, 2],
  "notify_configs": [
    {
      "channel_id": 1,
      "template_id": 1,
      "params": { "user_ids": [1, 2], "user_group_ids": [1] },
      "severities": [1, 2, 3],
      "time_ranges": [],
      "label_keys": [],
      "attributes": []
    }
  ]
}

要点（字段全表与 params 各渠道形状见 reference.md）：

• user_group_ids 不能为空；notify_configs 至少 1 条，单条规则建议 ≤5 条（超过该拆成多条规则）。
• channel_id 必须 >0，用 list_notify_channels 拿真实 ID，别猜。
• params 的形状随媒介变：接收人类填 user_ids/user_group_ids，群机器人类填 access_token 等自定义 key，flashduty 填协作空间 ids——以 list_notify_channels 返回的 contact_key/custom_params 为准，缺的信息问用户并附文档链接（速查表见 reference.md）。
• template_id 可不填：工具会自动补该渠道默认模板（weight 最小的）；只有用户点名特定模板才用 list_message_templates（按渠道 ident 过滤）取真实 id。flashduty/pagerduty 渠道本就不需要模板。
• severities 不能为空，[1,2,3] = 全级别；想"P1 走一路、P2/P3 走另一路"必须拆 NotifyConfig。
• time_ranges 留空 [] = 全部时段生效，别再塞全天 00:00-00:00 条目；多个窗口之间是 OR；跨午夜要拆两段；week 用 0=周日。
• label_keys / attributes 多条之间都是 AND；in/not in 的 value 用空格分隔。

工作流一：创建

1. 确定接收通知的团队（用户组）：用 list_teams 拿 user_group_ids。用户点名了团队、或前端已弹团队表单时直接用其 ID，不必再问。
2. 确定通知媒介和模板：list_notify_channels 列出已启用媒介，按用户描述（钉钉/邮件/电话/短信…）匹配 channel_id；匹配不到就把候选列给用户选。template_id 按上文规则通常不填。
3. 确定渠道参数（params）——不同媒介要用户填的信息不同：按 list_notify_channels 返回的 contact_key / custom_params / request_type 判断该媒介的 params 形状（对照表见 reference.md「params 渠道参数」）：接收人类（邮件/短信/电话）问"发给谁"；群机器人类（钉钉/企微/飞书）必须要到 access_token/key；flashduty 要协作空间 ID；callback 要 URL。自定义参数用户没给时先 list_notify_rule_custom_params 查已有规则填过的值——用户说"和规则 X 同一个群"就按规则名匹配直接复用；查不到或用户明说是新群，停下来问用户，不要留空或编造，问的同时附上 reference.md 速查表里该媒介的官方文档链接，告诉用户去哪里拿这个值。要 token 时顺带请用户给个备注（bot_name/note：哪个群、什么用途）；备注用户没给不追问，按规则名/路由意图自动生成一个填上，不留空。
4. 拼 config 调用 create_notify_rule：复合路由需求先对照 recipes.md 拆 NotifyConfig；config 传单个 JSON 对象（不是数组），一次建一条。若没带 user_group_ids，工具会自动弹团队选择表单，用户选完会续上本次创建。
5. 回报结果：工具返回 {id, name, user_group_ids, notify_configs_count, url}，简要汇报规则名、关联团队、通知配置条数即可。规则名用站内链接展示：[<name>](<url>)（url 即返回的 /notification-rules/edit/<id>），用户可点击直达配置页核对。创建完成后可在告警规则中通过 notify_rule_ids 关联。

工作流二：编辑 / 复制 / 排障

1. 用 list_notify_rules / get_notify_rule_detail 拿到规则 ID 和现有配置的完整 JSON。
2. 调用 update_notify_rule（提案制：调用即向用户展示改动清单并暂停，用户确认后系统自动落库，确认环节不经过你）：id 必填，config 只写要改的字段（增量 patch：未写的字段保持原值）。两类改法注意区分：
   • 顶层标量（启停/改名/改描述）：config 只传那一个字段即可，如 {"enable":false}
   • notify_configs / user_group_ids 是整体替换不是追加：哪怕只动 notify_configs[1].attributes[0].func 一个值，也必须基于 detail 的现状改出完整数组再传，否则未提及的通知配置会被丢掉
3. 非管理员只能改自己所属团队的规则；改 user_group_ids 时新列表仍须包含自己所属的团队。新增通知配置缺 template_id 时工具会自动补该渠道默认模板（同创建）。新增 NotifyConfig 或换媒介时，params 按工作流一第 3 步重新确定——不同媒介的 params 形状不同（旧渠道的 access_token 换到企微就该叫 key），缺的信息问用户并附 reference.md 速查表里的文档链接，别沿用旧 params 或留空。
4. 复制规则 = get 详情 → 改名/改差异字段 → create_notify_rule 新建一条。
5. 用户写出会踩坑的配置（业务组按名绑定 / in 用逗号 / 跨午夜不拆段 / week 写反…）时，对照 troubleshooting.md 主动纠正。
6. 改完建议用户先 dry-run 验证再放量：拿一条真实历史事件 ID 走 POST /api/n9e/notify-rule/test（见 troubleshooting.md）。

输出风格

1. 第一句话锁定层（规则层才接，否则转对应 skill，不替别人的 skill 做事）。
2. 复合路由需求直接映射到 recipes.md 最贴近的模板，给完整 JSON 草稿，不让用户自己填字段名。
3. 创建走工具直接落库；修改是提案制——调用 update_notify_rule 后系统会向用户展示改动清单并等确认，调用前不要自己再复述一遍改动（避免双重确认），也不要传 proposal_id/confirmed。例外：改 notify_configs 整组替换时，系统文案只能展示整组 JSON（超长截断），调用前可用一句话点明实际动的字段路径（如"只把 notify_configs[1].severities 改成 [1,2]"）；HTTP API 仅在用户明确要 curl 时按 http-api.md 给命令模板，不执行。
4. 修改成功后同样按工作流一第 5 步的链接形式展示规则名（update_notify_rule 返回值里也有 url）。