mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-05-14 18:44:44 +08:00
198 lines
5.1 KiB
Markdown
198 lines
5.1 KiB
Markdown
---
|
|
name: unified-notifications-ops
|
|
description: 将通知作为统一的 ECC 原生工作流进行操作，涵盖 GitHub、Linear、桌面提醒、钩子以及连接的通信界面。当真正的问题是告警路由、去重、升级或收件箱崩溃时使用。
|
|
origin: ECC
|
|
---
|
|
|
|
# 统一通知运维
|
|
|
|
当真正的问题不是缺少通知，而是通知系统碎片化时，使用此技能。
|
|
|
|
任务是将分散的事件整合到一个操作员界面上，包含：
|
|
|
|
* 明确的严重等级
|
|
* 明确的责任人
|
|
* 明确的路由
|
|
* 明确的后续行动
|
|
|
|
## 何时使用
|
|
|
|
* 用户希望在 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 下一步应封装什么
|
|
|
|
## 输出格式
|
|
|
|
```text
|
|
当前表面
|
|
- 来源
|
|
- 渠道
|
|
- 重复项
|
|
- 缺口
|
|
|
|
事件模型
|
|
- 严重
|
|
- 高
|
|
- 中
|
|
- 低
|
|
|
|
路由计划
|
|
- 来源 -> 渠道
|
|
- 原因
|
|
- 操作员/负责人
|
|
|
|
整合
|
|
- 抑制
|
|
- 合并
|
|
- 规范摘要
|
|
|
|
下一步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` 当通知痛点涉及计费/客户运营而非工程时
|