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:

Capture

the event

Classify

urgency and owner

Route

to the correct channel

Collapse

duplicates and low-signal churn

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 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"