统一通知运营¶

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

目标是把分散的事件整合到单一操作员界面中，包括：

明确的严重级别
明确的责任人
明确的路由
明确的下一步操作

使用场景¶

用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天和邮件之间拥有统一通知渠道
CI 失败、评审请求、Issue 更新、操作员事件分散在各处
当前配置产生的是噪音而不是可执行动作
用户希望把重复的通知分支和遗留提案整合到单一 ECC 原生渠道
工作区已有钩子、MCP 或已连接工具，但缺乏一致的通知策略

优先接口¶

从已有内容开始：

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

优先使用 ECC 原生编排，而不是向用户推荐独立通知产品。

绝对规则¶

绝不公开 Token、Secret、Webhook Secret、内部标识符
区分以下内容：
事件来源
严重级别
路由渠道
操作员操作
当中断成本不明确时，默认采用摘要优先方法
不要向所有渠道广播所有事件
如果真正解决方案是更好的 Issue 分诊、钩子策略或项目流程，则明确说明

事件流水线¶

将渠道视为：

捕获事件
分类紧急程度和责任人
路由到合适渠道
合并重复和低信号噪音
附带下一步操作员操作

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

默认严重级别模型¶

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

如果工作区没有严重级别模型，先构建它，再建议自动化。

工作流¶

1. 盘点当前接口¶

列出以下内容：

事件来源
当前渠道
触发提醒的钩子/脚本
同一事件的重复路径
重要事项未显示的静默失败案例

指出 ECC 已经拥有的内容。

2. 确定什么值得中断¶

对每个事件族回答：

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

使用以下默认值：

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

3. 在添加渠道前合并重复¶

检查以下内容：

同一 PR 事件同时出现在 GitHub、Linear、本地日志中
同一失败的重复钩子通知
应该摘要而不是直接转发的评论或状态变更
没有提供更好的操作路径却互相复制的渠道

优先以下做法：

一个规范摘要
一个责任人
一个主渠道
一个回退路径

4. 设计 ECC 原生工作流¶

为每个实际通知需求定义：

来源
门控
形式：即时提醒、摘要、队列或仅仪表盘
渠道
操作

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

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

5. 返回面向操作的设计¶

最终输出：

保留的内容
抑制的内容
合并的内容
ECC 接下来应封装的内容

输出格式¶

現在のサーフェス
- ソース
- チャネル
- 重複
- ギャップ

イベントモデル
- クリティカル
- 高
- 中
- 低

ルーティング計画
- ソース -> チャネル
- 理由
- オペレーター/担当者

統合
- 抑制
- マージ
- 正規サマリー

次のECCアクション
- スキル/フック/エージェント/MCP
- 次に構築する具体的なワークフロー

良好用例¶

“有 GitHub、Linear、本地钩子提醒，但没有统一操作员流程”
“CI 失败噪音太多，人们已经忽略”
“希望在整个 Claude、OpenCode、Codex 接口中拥有统一通知策略”
“希望判断哪些应中断，哪些应放入摘要”
“希望把重复的通知 PR 想法整合到一个规范 ECC 渠道”