unified-notifications-ops

统一通知运维

当真正的问题不是缺少一条通知时使用此技能。真正的问题是碎片化的通知系统。

工作是将分散的事件转变为一个操作面：

• 清晰的严重性
• 清晰的所有权
• 清晰的路由
• 清晰的后续行动

何时使用

• 用户想要跨 GitHub、Linear、本地钩子、桌面警报、聊天或电子邮件的统一通知通道
• CI 失败、审查请求、问题更新和操作者事件到达不相连的地方
• 当前设置产生噪音而非行动
• 用户想要将重叠的通知分支或待办提案合并为一个 ECC 原生通道
• 工作区已有钩子、MCP 或连接工具，但没有一致的通知策略

首选面

从已有的开始：

• GitHub 问题、PR、审查、评论和 CI
• Linear 问题/项目移动
• 本地钩子事件和会话生命周期信号
• 桌面通知原语
• 连接的电子邮件/聊天面（当它们实际存在时）

优先使用 ECC 原生编排，而非告诉用户采用单独的通知产品。

不可协商的规则

• 绝不暴露令牌、密钥、Webhook 密钥或内部标识符
• 分离：
  • 事件源
  • 严重性
  • 路由通道
  • 操作者行动
• 当中断成本不明确时默认使用摘要优先
• 不要将每个事件分发到每个通道
• 如果真正的修复是更好的问题分类、钩子策略或项目流程，明确说出来

事件流水线

将通道视为：

1. 捕获事件
2. 分类紧急程度和负责人
3. 路由到正确的通道
4. 合并重复和低信号噪音
5. 附加下一步操作者行动

目标是更少、更好的通知。

默认严重性模型

类别	示例	默认处理
严重	默认分支 CI 损坏、安全问题、阻塞的发布、部署失败	立即中断
高	审查请求、PR 失败、所有者阻塞的交接	同日提醒
中	问题状态变更、重要评论、待办列表变动	摘要或队列
低	重复成功、例行变动、冗余的生命周期标记	抑制或折叠

如果工作区没有严重性模型，在提出自动化之前先建立一个。

工作流

1. 清点当前面

列出：

• 事件源
• 当前通道
• 发出警报的现有钩子/脚本
• 同一事件的重复路径
• 重要事项未被暴露的静默失败案例

指出 ECC 已经拥有的。

2. 决定什么值得中断

对每个事件族，回答：

• 谁需要知道？
• 他们需要多快知道？
• 这应该中断、批量还是仅记录？

使用这些默认值：

• 对发布、CI、安全和所有者阻塞事件进行中断
• 对中信号更新使用摘要
• 对遥测和低信号生命周期标记仅记录

3. 在添加通道之前合并重复

查找：

• 同一个 PR 事件出现在 GitHub、Linear 和本地日志中
• 同一失败的重复钩子通知
• 应该被摘要而非原始转发的评论或状态变动
• 互相重复而不提供更好行动路径的通道

优先：

• 一个规范摘要
• 一个负责人
• 一个主要通道
• 一个备用路径

4. 设计 ECC 原生工作流

对每个真正的通知需求，定义：

• 来源
• 门控
• 形态：即时警报、摘要、队列或仅仪表板
• 通道
• 行动

如果 ECC 已有原语，优先：

• 用于操作者分诊的技能
• 用于自动发出/执行的钩子
• 用于委派分类的智能体
• MCP/连接器仅在缺少真正桥接时使用

5. 返回行动偏向的设计

以以下内容结束：

• 要保留什么
• 要抑制什么
• 要合并什么
• ECC 接下来应该封装什么

输出格式

当前面
- 来源
- 通道
- 重复
- 差距

事件模型
- 严重
- 高
- 中
- 低

路由计划
- 来源 -> 通道
- 原因
- 操作负责人

整合
- 抑制
- 合并
- 规范摘要

下一步 ECC 行动
- 技能 / 钩子 / 智能体 / MCP
- 接下来要构建的确切工作流

推荐规则

• 优先一个强通道而非多个弱通道
• 对中和低信号更新优先使用摘要
• 当信号应自动发出时优先使用钩子
• 当工作是分诊、路由和审查优先决策时优先使用操作者技能
• 当根本原因是待办/PR 协调而非警报时优先使用 project-flow-ops
• 当用户首先需要来源清单时优先使用 workspace-surface-audit
• 如果桌面通知足够，不要发明不必要的外部桥接

典型用例

• "我们有 GitHub、Linear 和本地钩子警报，但没有统一的操作者流程"
• "我们的 CI 失败很嘈杂，人们忽略它们"
• "我想要一个跨 Claude、OpenCode 和 Codex 面的通知策略"
• "弄清楚什么应该中断 vs 放入摘要"
• "将重叠的通知 PR 想法合并为一个规范的 ECC 通道"

相关技能

• workspace-surface-audit
• project-flow-ops
• github-ops
• knowledge-ops
• customer-billing-ops 当通知痛点是计费/客户运营而非工程时