unified-notifications-ops

Original：🇺🇸 English

Translated

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.

7installs

Sourceaffaan-m/everything-claude-code

Added on2026-04-06

NPX Install

npx skill4agent add affaan-m/everything-claude-code unified-notifications-ops

SKILL.md Content

View Translation Comparison →

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

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