| 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
- 接下来要构建的确切工作流
推荐规则
- 优先一个强通道而非多个弱通道
- 对中和低信号更新优先使用摘要
- 当信号应自动发出时优先使用钩子
- 当工作是分诊、路由和审查优先决策时优先使用操作者技能
- 当根本原因是待办/PR 协调而非警报时优先使用
project-flow-ops
- 当用户首先需要来源清单时优先使用
workspace-surface-audit
- 如果桌面通知足够，不要发明不必要的外部桥接
典型用例
- "我们有 GitHub、Linear 和本地钩子警报，但没有统一的操作者流程"
- "我们的 CI 失败很嘈杂，人们忽略它们"
- "我想要一个跨 Claude、OpenCode 和 Codex 面的通知策略"
- "弄清楚什么应该中断 vs 放入摘要"
- "将重叠的通知 PR 想法合并为一个规范的 ECC 通道"
相关技能
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops 当通知痛点是计费/客户运营而非工程时
