--- 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 --- Source attribution: affaan-m Original project: https://github.com/affaan-m/everything-claude-code/blob/25278e7d7b6cf6e6a4e7a6c8e10f14ff22f0eb5b/skills/unified-notifications-ops/SKILL.md License: MIT License information: https://opensource.org/license/mit Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice MIT License Copyright (c) 2026 Affaan Mustafa Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. # Mega AI Hub resource metadata Creator / publisher: affaan-m Original project: https://github.com/affaan-m/everything-claude-code/blob/25278e7d7b6cf6e6a4e7a6c8e10f14ff22f0eb5b/skills/unified-notifications-ops/SKILL.md Attribution basis: Source repository record Fields of work: Development & Engineering, Operations, Project & Program Management, Sales, Customer Support Roles: Customer Success Manager, DevOps / SRE, Operations Manager, Project Manager, Technical Support Specialties: Specialty not specified Tools: Discord, Email (SMTP/IMAP), GitHub, Linear, Slack Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 0ade130619dfc73781d6a4beaf79b65b6d3ac70f0751dce0844a8f9fd39167aa