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

相关技能

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