Skip to main content
Kodelyth ECC
Skill

unified-notifications-ops

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.

Invoke via:use unified-notifications-ops
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:

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

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

← All skills