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