unified-notifications-ops
整合 GitHub、Linear 和 hook 通知，做路由、去重與升級
中文翻譯
--- name: unified-notifications-ops description: 把通知當成一條 ECC 原生的工作流來運作，涵蓋 GitHub、Linear、桌面通知、hook 和已連接的通訊管道。當真正的問題是警報路由、去重、升級或收件匣太亂時使用。 metadata: origin: ECC --- # Unified Notifications Ops 當真正的問題不是少了一個提醒時，就用這個 skill。真正的問題是通知系統太零碎。 工作是把散落各處的事件，變成一個操作者介面，具備： - 清楚的嚴重程度 - 清楚的負責人 - 清楚的路由 - 清楚的後續動作 ## 何時使用 - 使用者想要一條跨 GitHub、Linear、本機 hook、桌面通知、聊天或 email 的統一通知通道 - CI 失敗、review 請求、issue 更新和操作者事件，都到達彼此不相連的地方 - 目前的設定製造的是雜訊，不是行動 - 使用者想把重疊的通知 branch 或待辦提案，整合成一條 ECC 原生的通道 - workspace 已經有 hook、MCP 或已連接的工具，但沒有一致的通知政策 ## 優先使用的介面 從已經存在的東西開始： - GitHub 的 issue、PR、review、留言和 CI - Linear 的 issue/專案動態 - 本機的 hook 事件和 session 生命週期訊號 - 桌面通知的基本元件 - 真的存在時，已連接的 email/聊天介面 優先用 ECC 原生的編排，不要叫使用者採用另一個獨立的通知產品。 ## 不可妥協的規則 - 絕對不要暴露 token、祕密、webhook 祕密或內部識別碼 - 要把這幾項分開： - 事件來源 - 嚴重程度 - 路由管道 - 操作者動作 - 打斷的成本不明確時，預設用摘要優先 - 不要把每個事件都 fan out 到每個管道 - 如果真正的解法是更好的 issue 分流、hook 政策或專案流程，就明確說出來 ## 事件管線 把這條通道當成： 1. **Capture** 事件 2. **Classify** 緊急程度和負責人 3. **Route** 到正確的管道 4. **Collapse** 重複和低訊號的反覆 5. **Attach** 下一個操作者動作 目標是更少、更好的通知。 ## 預設的嚴重程度模型 | 等級 | 範例 | 預設處理 | | --- | --- | --- | | Critical | 預設 branch 的 CI 壞了、安全問題、被擋住的 release、失敗的 deploy | 立刻打斷 | | High | 被要求 review、PR 失敗、卡住負責人的交接 | 當天警報 | | Medium | issue 狀態變更、值得注意的留言、待辦動態 | 摘要或佇列 | | Low | 重複的成功、例行的反覆、多餘的生命週期標記 | 抑制或折疊 | 如果 workspace 沒有嚴重程度模型，在提出自動化之前先建一個。 ## 工作流 ### 1. 盤點目前的介面 列出： - 事件來源 - 目前的管道 - 會發出警報的既有 hook/script - 同一個事件的重複路徑 - 重要的事沒有被顯示出來的靜默失敗情況 指出 ECC 已經擁有什麼。 ### 2. 決定什麼值得打斷 對每一類事件，回答： - 誰需要知道？ - 他們需要多快知道？ - 這應該打斷、批次處理，還是只記錄？ 使用這些預設： - release、CI、安全和卡住負責人的事件要打斷 - 中等訊號的更新用摘要 - 遙測和低訊號的生命週期標記只記錄 ### 3. 先收掉重複，再加管道 找出： - 同一個 PR 事件同時出現在 GitHub、Linear 和本機 log - 同一個失敗重複的 hook 通知 - 應該被摘要、而不是原封不動轉發的留言或狀態反覆 - 彼此重複、卻沒有提供更好行動路徑的管道 優先採用： - 一份標準摘要 - 一個負責人 - 一個主要管道 - 一條備援路徑 ### 4. 設計 ECC 原生的工作流 對每個真實的通知需求，定義： - **source** - **gate** - **shape**：即時警報、摘要、佇列，或只放在 dashboard - **channel** - **action** 如果 ECC 已經有這個基本元件，優先用： - skill 做操作者分流 - hook 做自動發出/強制執行 - agent 做委派的分類 - 只有在真的缺少橋接時，才用 MCP/connector ### 5. 回傳偏向行動的設計 結尾要寫： - 要保留什麼 - 要抑制什麼 - 要合併什麼 - ECC 接下來應該包裝什麼 ## 輸出格式 ```text CURRENT SURFACE - sources - channels - duplicates - gaps EVENT MODEL - critical - high - medium - low ROUTING PLAN - source -> channel - why - operator owner CONSOLIDATION - suppress - merge - canonical summaries NEXT ECC MOVE - skill / hook / agent / MCP - exact workflow to build next ``` ## 建議規則 - 寧可一條強的通道，也不要很多條弱的 - 中等和低訊號的更新優先用摘要 - 訊號應該自動發出時，優先用 hook - 工作是分流、路由和先 review 再決定時，優先用操作者 skill - 根本原因是待辦 / PR 協調、而不是警報時，優先用 `project-flow-ops` - 使用者首先需要來源盤點時，優先用 `workspace-surface-audit` - 如果桌面通知就夠了，就不要發明不必要的外部橋接 ## 適合的使用情境 - 「我們有 GitHub、Linear 和本機 hook 的警報，但沒有單一的操作者流程」 - 「我們的 CI 失敗很吵，大家都不理它」 - 「我想要一套橫跨 Claude、OpenCode 和 Codex 介面的通知政策」 - 「搞清楚什麼該打斷、什麼該放進摘要」 - 「把重疊的通知 PR 點子整合成一條標準的 ECC 通道」 ## 相關 Skills - `workspace-surface-audit` - `project-flow-ops` - `github-ops` - `knowledge-ops` - `customer-billing-ops`：當通知的痛點是帳務/客戶營運，而不是工程時使用
英文原文
--- name: unified-notifications-ops description: Operate notifications as one ECC-native workflow across GitHub, Linear, desktop alerts, hooks, and connected communication surfaces. Use when the real problem is alert routing, deduplication, escalation, or inbox collapse. metadata: origin: ECC --- # Unified Notifications Ops Use this skill when the real problem is not a missing ping. The real problem is a fragmented notification system. The job is to turn scattered events into one operator surface with: - clear severity - clear ownership - clear routing - clear follow-up action ## When to Use - the user wants a unified notification lane across GitHub, Linear, local hooks, desktop alerts, chat, or email - CI failures, review requests, issue updates, and operator events are arriving in disconnected places - the current setup creates noise instead of action - the user wants to consolidate overlapping notification branches or backlog proposals into one ECC-native lane - the workspace already has hooks, MCPs, or connected tools, but no coherent notification policy ## Preferred Surface Start from what already exists: - GitHub issues, PRs, reviews, comments, and CI - Linear issue/project movement - local hook events and session lifecycle signals - desktop notification primitives - connected email/chat surfaces when they actually exist Prefer ECC-native orchestration over telling the user to adopt a separate notification product. ## Non-Negotiable Rules - never expose tokens, secrets, webhook secrets, or internal identifiers - separate: - event source - severity - routing channel - operator action - default to digest-first when interruption cost is unclear - do not fan out every event to every channel - if the real fix is better issue triage, hook policy, or project flow, say so explicitly ## Event Pipeline Treat the lane as: 1. **Capture** the event 2. **Classify** urgency and owner 3. **Route** to the correct channel 4. **Collapse** duplicates and low-signal churn 5. **Attach** the next operator action The goal is fewer, better notifications. ## Default Severity Model | Class | Examples | Default handling | | --- | --- | --- | | Critical | broken default-branch CI, security issue, blocked release, failed deploy | interrupt now | | High | review requested, failing PR, owner-blocking handoff | same-day alert | | Medium | issue state changes, notable comments, backlog movement | digest or queue | | Low | repeat successes, routine churn, redundant lifecycle markers | suppress or fold | If the workspace has no severity model, build one before proposing automation. ## Workflow ### 1. Inventory the current surface List: - event sources - current channels - existing hooks/scripts that emit alerts - duplicate paths for the same event - silent failure cases where important things are not being surfaced Call out what ECC already owns. ### 2. Decide what deserves interruption For each event family, answer: - who needs to know? - how fast do they need to know? - should this interrupt, batch, or just log? Use these defaults: - interrupt for release, CI, security, and owner-blocking events - digest for medium-signal updates - log-only for telemetry and low-signal lifecycle markers ### 3. Collapse duplicates before adding channels Look for: - the same PR event appearing in GitHub, Linear, and local logs - repeated hook notifications for the same failure - comments or status churn that should be summarized instead of forwarded raw - channels that duplicate each other without adding a better action path Prefer: - one canonical summary - one owner - one primary channel - one fallback path ### 4. Design the ECC-native workflow For each real notification need, define: - **source** - **gate** - **shape**: immediate alert, digest, queue, or dashboard-only - **channel** - **action** If ECC already has the primitive, prefer: - a skill for operator triage - a hook for automatic emission/enforcement - an agent for delegated classification - an MCP/connector only when a real bridge is missing ### 5. Return an action-biased design End with: - what to keep - what to suppress - what to merge - what ECC should wrap next ## Output Format ```text CURRENT SURFACE - sources - channels - duplicates - gaps EVENT MODEL - critical - high - medium - low ROUTING PLAN - source -> channel - why - operator owner CONSOLIDATION - suppress - merge - canonical summaries NEXT ECC MOVE - skill / hook / agent / MCP - exact workflow to build next ``` ## Recommendation Rules - prefer one strong lane over many weak ones - prefer digests for medium and low-signal updates - prefer hooks when the signal should emit automatically - prefer operator skills when the work is triage, routing, and review-first decision-making - prefer `project-flow-ops` when the root cause is backlog / PR coordination rather than alerts - prefer `workspace-surface-audit` when the user first needs a source inventory - if desktop notifications are enough, do not invent an unnecessary external bridge ## Good Use Cases - "We have GitHub, Linear, and local hook alerts, but no single operator flow" - "Our CI failures are noisy and people ignore them" - "I want one notification policy across Claude, OpenCode, and Codex surfaces" - "Figure out what should interrupt versus land in a digest" - "Collapse overlapping notification PR ideas into one canonical ECC lane" ## Related Skills - `workspace-surface-audit` - `project-flow-ops` - `github-ops` - `knowledge-ops` - `customer-billing-ops` when the notification pain is billing/customer operations rather than engineering