unified-notifications-ops

unified-notifications-ops

熱門

將通知操作整合為單一 ECC 原生工作流程,涵蓋 GitHub、Linear、桌面警示、Hook 及已連接的通訊介面。當真正的問題是警示路由、去重、升級或收件匣崩潰時使用。

23萬星標
3.5萬分支
更新於 2026/7/21
SKILL.md
唯讀
名稱
unified-notifications-ops
描述

將通知操作整合為單一 ECC 原生工作流程,涵蓋 GitHub、Linear、桌面警示、Hook 及已連接的通訊介面。當真正的問題是警示路由、去重、升級或收件匣崩潰時使用。

統一通知操作

當真正的問題不是缺少通知,而是破碎的通知系統時,請使用此技能。

目標是將分散的事件轉換為單一操作介面,具備:

  • 明確的嚴重性
  • 明確的擁有者
  • 明確的路由
  • 明確的後續行動

使用時機

  • 使用者希望跨 GitHub、Linear、本地 Hook、桌面警示、聊天或電子郵件建立統一的通知通道
  • CI 失敗、審查請求、議題更新和操作事件分散在不同地方
  • 當前設定產生噪音而非行動
  • 使用者希望將重疊的通知分支或待辦事項提案整合為單一 ECC 原生通道
  • 工作區已有 Hook、MCP 或連接工具,但缺乏一致的通知策略

首選介面

從現有資源開始:

  • GitHub 議題、PR、審查、評論和 CI
  • Linear 議題/專案移動
  • 本地 Hook 事件和工作階段生命週期訊號
  • 桌面通知基本功能
  • 已連接的電子郵件/聊天介面(如果實際存在)

偏好使用 ECC 原生編排,而非建議使用者採用獨立的通知產品。

不可妥協的規則

  • 絕不暴露 Token、密碼、Webhook 密碼或內部識別碼
  • 區分:
    • 事件來源
    • 嚴重性
    • 路由通道
    • 操作者行動
  • 預設使用摘要優先,當中斷成本不明確時
  • 不要將每個事件發送到每個通道
  • 如果真正的解決方案是更好的議題分類、Hook 策略或專案流程,請明確說明

事件管線

將通道視為:

  1. 擷取事件
  2. 分類緊急性和擁有者
  3. 路由到正確通道
  4. 合併重複和低訊號干擾
  5. 附加下一個操作者行動

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

預設嚴重性模型

等級 範例 預設處理方式
嚴重 預設分支 CI 中斷、安全性問題、發佈受阻、部署失敗 立即中斷
高 審查請求、PR 失敗、阻擋擁有者的交接 當日警示
中 議題狀態變更、重要評論、待辦事項移動 摘要或佇列
低 重複成功、例行干擾、冗餘生命週期標記 抑制或摺疊

如果工作區沒有嚴重性模型,請在提出自動化之前先建立一個。

工作流程

1. 盤點當前介面

列出:

  • 事件來源
  • 當前通道
  • 現有發出警示的 Hook/腳本
  • 同一事件的重複路徑
  • 重要事項未被呈現的靜默失敗案例

指出 ECC 已擁有的部分。

2. 決定哪些值得中斷

針對每個事件家族,回答:

  • 誰需要知道?
  • 他們需要多快知道?
  • 應該中斷、批次處理,還是僅記錄?

使用這些預設值:

  • 發佈、CI、安全性和阻擋擁有者的事件應中斷
  • 中等訊號的更新使用摘要
  • 遙測和低訊號生命週期標記僅記錄

3. 在新增通道前先合併重複

尋找:

  • 同一 PR 事件同時出現在 GitHub、Linear 和本地日誌中
  • 同一失敗的重複 Hook 通知
  • 應總結而非直接轉發的評論或狀態變更
  • 彼此重複但未提供更好行動路徑的通道

偏好:

  • 一個標準摘要
  • 一個擁有者
  • 一個主要通道
  • 一個備援路徑

4. 設計 ECC 原生工作流程

針對每個真正的通知需求,定義:

  • 來源
  • 閘道
  • 形式:即時警示、摘要、佇列或僅儀表板
  • 通道
  • 行動

如果 ECC 已有基本功能,偏好:

  • 使用技能進行操作者分類
  • 使用 Hook 進行自動發送/執行
  • 使用代理進行委派分類
  • 僅在真正缺少橋接時使用 MCP/連接器

5. 回傳以行動為導向的設計

結尾包含:

  • 保留什麼
  • 抑制什麼
  • 合併什麼
  • ECC 下一步應包裝什麼

輸出格式

當前介面
- 來源
- 通道
- 重複
- 缺口

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

路由計畫
- 來源 -> 通道
- 原因
- 操作者擁有者

整合
- 抑制
- 合併
- 標準摘要

ECC 下一步行動
- 技能 / Hook / 代理 / MCP
- 下一步要建立的確切工作流程

建議規則

  • 偏好一個強大的通道,而非多個弱通道
  • 中低訊號更新偏好使用摘要
  • 當訊號應自動發送時偏好使用 Hook
  • 當工作是分類、路由和以審查為主的決策時,偏好使用操作者技能
  • 當根本原因是待辦事項/PR 協調而非警示時,偏好使用 project-flow-ops
  • 當使用者首先需要來源盤點時,偏好使用 workspace-surface-audit
  • 如果桌面通知已足夠,不要發明不必要的外部橋接

良好使用案例

  • 「我們有 GitHub、Linear 和本地 Hook 警示,但沒有單一操作者流程」
  • 「我們的 CI 失敗很吵雜,人們忽略它們」
  • 「我想要一個跨 Claude、OpenCode 和 Codex 介面的統一通知策略」
  • 「找出哪些應該中斷,哪些應該進入摘要」
  • 「將重疊的通知 PR 想法整合為單一標準 ECC 通道」

相關技能

  • workspace-surface-audit
  • project-flow-ops
  • github-ops
  • knowledge-ops
  • customer-billing-ops 當通知問題是帳單/客戶操作而非工程時