Unified Notifications Ops

统一通知运维

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

任务是将分散的事件整合到一个操作员界面上，包含：

• 明确的严重等级
• 明确的责任人
• 明确的路由
• 明确的后续行动

何时使用

• 用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天或邮件之间建立统一的通知通道
• CI 失败、审查请求、问题更新和操作员事件分散在不同的地方
• 当前设置制造了噪音而非行动
• 用户希望将重叠的通知分支或积压提案整合到一个 ECC 原生通道中
• 工作区已有钩子、MCP 或连接工具，但缺乏连贯的通知策略

首选界面

从已有资源出发：

• GitHub 问题、PR、审查、评论和 CI
• Linear 问题/项目状态变更
• 本地钩子事件和会话生命周期信号
• 桌面通知原语
• 已连接的邮件/聊天界面（如果实际存在）

优先使用 ECC 原生编排，而非建议用户采用独立的通知产品。

不可妥协的规则

• 绝不暴露令牌、密钥、Webhook 密钥或内部标识符
• 区分：
  • 事件来源
  • 严重等级
  • 路由通道
  • 操作员行动
• 当中断成本不明确时，默认采用摘要优先策略
• 不要将每个事件广播到所有通道
• 如果真正的解决方案是更好的问题分类、钩子策略或项目流程，请明确说明

事件管道

将通道视为：

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

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

默认严重等级模型

如果工作区没有严重等级模型，请先构建一个，再提出自动化方案。

工作流程

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 界面的统一通知策略"
• "判断哪些应该中断，哪些应该进入摘要"
• "将重叠的通知 PR 想法合并为一个规范的 ECC 通道"

相关技能

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