統一通知操作 是做什麼的?
請在當真正的問題不是缺少通知,而是通知系統碎片化時使用此技能。
目標是將分散的事件整合為單一操作員控制面,具備:
- 清晰的嚴重性
- 清晰的擁有權
- 清晰的路由
- 清晰的後續行動
使用時機
- 使用者想要在 GitHub、Linear、本地鉤子、桌面警示、聊天或郵件之間建立統一的通知通道
- CI 失敗、審查請求、問題更新與運維事件分散在不同的地方
- 現有設定只產生噪音,而非行動
- 使用者想要將重疊的通知分支或積壓提案合併為一個 ECC 原生的通道
- 工作區已存在鉤子、MCP 或已連接的工具,但缺乏一致的通知政策
偏好的表面
從已存在的開始:
- GitHub 問題、PR、審查、評論與 CI
- Linear 問題/專案移動
- 本地鉤子事件與工作階段生命週期訊號
- 桌面通知基元
- 已連接的電子郵件/聊天表面(當實際存在時)
偏好使用 ECC 原生編排,而非告訴使用者採用單獨的通知產品。
不可協商的規則
- 絕不暴露令牌、密碼、Webhook 密碼或內部識別碼
- 區分:
- 事件來源
- 嚴重性
- 路由通道
- 操作員行動
- 當中斷成本不明時,預設使用摘要優先
- 不要將每個事件廣播到每個通道
- 如果真正的解決方案是更好的問題分類、鉤子政策或專案流程,請明確指出
事件管線
將通道視為:
- 擷取 事件
- 分類 緊急程度與擁有者
- 路由 到正確的通道
- 合併 重複項與低信號干擾
- 附加 下一個操作員行動
目標是更少、更好的通知。
預設嚴重性模型
| 等級 | 範例 | 預設處理方式 |
|---|---|---|
| 關鍵 | 預設分支 CI 中斷、安全問題、版本受阻、部署失敗 | 立即中斷 |
| 高 | 審查已請求、PR 失敗、阻礙擁有者的交接 | 當天警示 |
| 中 | 問題狀態變更、重要評論、積壓變動 | 摘要或佇列 |
| 低 | 重複成功、例行干擾、冗餘的生命週期標記 | 抑制或摺疊 |
如果工作區沒有嚴重性模型,請先建立一個再提出自動化方案。
工作流程
1. 盤點當前表面
列出:
- 事件來源
- 當前通道
- 目前已發送警示的鉤子/腳本
- 同一事件的重複路徑
- 重要事項未被呈現的靜默失敗案例
指出 ECC 已擁有的部分。
2. 決定哪些事件值得中斷
針對每個事件家族,回答:
- 誰需要知道?
- 他們需要多快知道?
- 這應該中斷、批次處理,還是僅記錄?
使用這些預設值:
- 版本、CI、安全與阻礙擁有者的事件應中斷
- 中等信號的更新應使用摘要
- 遙測與低信號生命週期標記僅記錄
3. 在新增通道前先去除重複
尋找:
- 同一個 PR 事件同時出現在 GitHub、Linear 與本地日誌中
- 同一失敗的重複鉤子通知
- 應被摘要而非原始轉發的評論或狀態干擾
- 相互重疊且未提供更好行動路徑的通道
偏好:
- 一個標準摘要
- 一個擁有者
- 一個主要通道
- 一個備援路徑
4. 設計 ECC 原生工作流程
針對每個真實的通知需求,定義:
- 來源
- 閘道
- 形式:立即警示、摘要、佇列或僅儀表板
- 通道
- 行動
如果 ECC 已有該基礎元件,則優先使用:
- 用於操作員分類的 skill
- 用於自動發射/強制的 hook
- 用於委派分類的 agent
- 僅在真正缺少橋接時使用 MCP/連接器
5. 回傳以行動為導向的設計
最後呈現:
- 保留什麼
- 抑制什麼
- 合併什麼
- ECC 下一步該封裝什麼
輸出格式
當前表面
- 來源
- 通道
- 重複項
- 缺口
事件模型
- 關鍵
- 高
- 中
- 低
路由計畫
- 來源 -> 通道
- 原因
- 操作員擁有者
合併
- 抑制
- 合併
- 標準摘要
ECC 下一步行動
- skill / hook / agent / MCP
- 下一步要建立的確切工作流程
建議規則
- 偏好一條強大的通道,而非多條弱通道
- 偏好對中等與低信號更新使用摘要
- 偏好當信號應自動發射時使用 hooks
- 偏好當工作是分類、路由與以審查為先的決策時使用 operator skills
- 當根本原因是積壓/PR 協調而非警示時,偏好使用
project-flow-ops - 當使用者首先需要來源盤點時,偏好使用
workspace-surface-audit - 如果桌面通知已足夠,不要發明不必要的外部橋接
良好使用案例
- "我們有 GitHub、Linear 與本地鉤子警示,但沒有單一的操作流程"
- "我們的 CI 失敗很吵雜,大家都不理會"
- "我想要在 Claude、OpenCode 與 Codex 表面之間建立一個通知政策"
- "找出哪些應中斷、哪些應進入摘要"
- "將重疊的通知 PR 想法合併為一個標準的 ECC 通道"
相關技能
workspace-surface-auditproject-flow-opsgithub-opsknowledge-ops- 當通知痛點是帳單/客戶操作而非工程時,使用
customer-billing-ops