name	unified-notifications-ops
description	将通知作为统一的 ECC 原生工作流进行操作，涵盖 GitHub、Linear、桌面提醒、钩子以及连接的通信界面。当真正的问题是告警路由、去重、升级或收件箱崩溃时使用。
origin	ECC

统一通知运维

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

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

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

何时使用

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

首选界面

从已有资源出发：

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

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

不可妥协的规则

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

事件管道

将通道视为：

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

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

默认严重等级模型

等级	示例	默认处理方式
严重	默认分支 CI 损坏、安全问题、发布受阻、部署失败	立即中断
高	请求审查、PR 失败、阻塞责任人的交接	当日提醒
中	问题状态变更、重要评论、积压变动	摘要或队列
低	重复成功、常规噪音、冗余生命周期标记	抑制或折叠

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

工作流程

1. 盘点当前界面

列出：

事件来源
当前通道
现有的发出提醒的钩子/脚本
同一事件的重复路径
重要事项未被呈现的静默失败案例

指出 ECC 已拥有的部分。

2. 决定哪些值得中断

针对每个事件族，回答：

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

使用以下默认值：

发布、CI、安全和阻塞责任人的事件需要中断
中等信号更新使用摘要
遥测和低信号生命周期标记仅记录

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

检查：

同一 PR 事件出现在 GitHub、Linear 和本地日志中
同一失败的重复钩子通知
应总结而非直接转发的评论或状态变更
相互重复且未提供更好行动路径的通道

优先选择：

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

4. 设计 ECC 原生工作流

针对每个真实通知需求，定义：

来源
门控
形态：即时提醒、摘要、队列或仅仪表盘
通道
行动

如果 ECC 已有原语，优先使用：

操作员分类技能
自动触发/执行的钩子
委托分类的代理
仅在真正缺少桥接时才使用 MCP/连接器

5. 返回以行动为导向的设计

最终输出：

保留什么
抑制什么
合并什么
ECC 下一步应封装什么

输出格式

当前表面
- 来源
- 渠道
- 重复项
- 缺口

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

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

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

下一步ECC行动
- 技能/钩子/代理/MCP
- 下一步要构建的具体工作流

良好用例

"我们有 GitHub、Linear 和本地钩子提醒，但没有统一的操作员流程"
"我们的 CI 失败噪音很大，人们都忽略了"
"我想要一个跨 Claude、OpenCode 和 Codex 界面的统一通知策略"
"判断哪些应该中断，哪些应该进入摘要"
"将重叠的通知 PR 想法合并为一个规范的 ECC 通道"

统一通知运维

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

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

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

何时使用

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

首选界面

从已有资源出发：

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

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

不可妥协的规则

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

事件管道

将通道视为：

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

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

默认严重等级模型

等级	示例	默认处理方式
严重	默认分支 CI 损坏、安全问题、发布受阻、部署失败	立即中断
高	请求审查、PR 失败、阻塞责任人的交接	当日提醒
中	问题状态变更、重要评论、积压变动	摘要或队列
低	重复成功、常规噪音、冗余生命周期标记	抑制或折叠

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

工作流程

1. 盘点当前界面

列出：

事件来源
当前通道
现有的发出提醒的钩子/脚本
同一事件的重复路径
重要事项未被呈现的静默失败案例

指出 ECC 已拥有的部分。

2. 决定哪些值得中断

针对每个事件族，回答：

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

使用以下默认值：

发布、CI、安全和阻塞责任人的事件需要中断
中等信号更新使用摘要
遥测和低信号生命周期标记仅记录

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

检查：

同一 PR 事件出现在 GitHub、Linear 和本地日志中
同一失败的重复钩子通知
应总结而非直接转发的评论或状态变更
相互重复且未提供更好行动路径的通道

优先选择：

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

4. 设计 ECC 原生工作流

针对每个真实通知需求，定义：

来源
门控
形态：即时提醒、摘要、队列或仅仪表盘
通道
行动

如果 ECC 已有原语，优先使用：

操作员分类技能
自动触发/执行的钩子
委托分类的代理
仅在真正缺少桥接时才使用 MCP/连接器

5. 返回以行动为导向的设计

最终输出：

保留什么
抑制什么
合并什么
ECC 下一步应封装什么

输出格式

当前表面
- 来源
- 渠道
- 重复项
- 缺口

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

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

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

下一步ECC行动
- 技能/钩子/代理/MCP
- 下一步要构建的具体工作流

良好用例

"我们有 GitHub、Linear 和本地钩子提醒，但没有统一的操作员流程"
"我们的 CI 失败噪音很大，人们都忽略了"
"我想要一个跨 Claude、OpenCode 和 Codex 界面的统一通知策略"
"判断哪些应该中断，哪些应该进入摘要"
"将重叠的通知 PR 想法合并为一个规范的 ECC 通道"

unified-notifications-ops

统一通知运维

何时使用

首选界面

不可妥协的规则

事件管道

默认严重等级模型

工作流程

1. 盘点当前界面

2. 决定哪些值得中断

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

4. 设计 ECC 原生工作流

5. 返回以行动为导向的设计

输出格式

推荐规则

良好用例

相关技能

统一通知运维

何时使用

首选界面

不可妥协的规则

事件管道

默认严重等级模型

工作流程

1. 盘点当前界面

2. 决定哪些值得中断

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

4. 设计 ECC 原生工作流

5. 返回以行动为导向的设计

输出格式

推荐规则

良好用例

相关技能