Unified Notifications Ops

Operate notifications as one ECC-native workflow across GitHub, Linear, desktop alerts, hooks, and connected communication surfaces.

You say
Buy it · $89 Read it before you buy $89 Written by affaan-m · unverified publisher
Context cost
1.4k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 5.6 kBtext throughout, nothing executable
Licence
MITpaid listing
Last change
no release on file
Servers it uses
Noneruns standalone

What it does

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.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

collaborationgithublinear

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md5.6 kB · 189 lines
--- 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 ---
8# Unified Notifications Ops
9
10Use this skill when the real problem is not a missing ping. The real problem is a fragmented notification system.
11
12The job is to turn scattered events into one operator surface with:
13- clear severity
14- clear ownership
15- clear routing
16- clear follow-up action
17
18## When to Use
19
20- the user wants a unified notification lane across GitHub, Linear, local hooks, desktop alerts, chat, or email
21- CI failures, review requests, issue updates, and operator events are arriving in disconnected places
22- the current setup creates noise instead of action
23- the user wants to consolidate overlapping notification branches or backlog proposals into one ECC-native lane
24- the workspace already has hooks, MCPs, or connected tools, but no coherent notification policy
25
26## Preferred Surface
27
28Start from what already exists:
29- GitHub issues, PRs, reviews, comments, and CI
30- Linear issue/project movement
31- local hook events and session lifecycle signals
32- desktop notification primitives
33- connected email/chat surfaces when they actually exist
34
35Prefer ECC-native orchestration over telling the user to adopt a separate notification product.
36
37## Non-Negotiable Rules
38
39- never expose tokens, secrets, webhook secrets, or internal identifiers
40- separate:
41 - event source
42 - severity
43 - routing channel
44 - operator action
45- default to digest-first when interruption cost is unclear
46- do not fan out every event to every channel
47- if the real fix is better issue triage, hook policy, or project flow, say so explicitly
48
49## Event Pipeline
50
51Treat the lane as:
52
531. **Capture** the event
542. **Classify** urgency and owner
553. **Route** to the correct channel
564. **Collapse** duplicates and low-signal churn
575. **Attach** the next operator action
58
59The goal is fewer, better notifications.
60
61## Default Severity Model
62
63| Class | Examples | Default handling |
64| --- | --- | --- |
65| Critical | broken default-branch CI, security issue, blocked release, failed deploy | interrupt now |
66| High | review requested, failing PR, owner-blocking handoff | same-day alert |
67| Medium | issue state changes, notable comments, backlog movement | digest or queue |
68| Low | repeat successes, routine churn, redundant lifecycle markers | suppress or fold |
69
70If the workspace has no severity model, build one before proposing automation.
71
72## Workflow
73
74### 1. Inventory the current surface
75
76List:
77- event sources
78- current channels
79- existing hooks/scripts that emit alerts
80- duplicate paths for the same event
81- silent failure cases where important things are not being surfaced
82
83Call out what ECC already owns.
84
85### 2. Decide what deserves interruption
86
87For each event family, answer:
88- who needs to know?
89- how fast do they need to know?
90- should this interrupt, batch, or just log?
91
92Use these defaults:
93- interrupt for release, CI, security, and owner-blocking events
94- digest for medium-signal updates
95- log-only for telemetry and low-signal lifecycle markers
96
97### 3. Collapse duplicates before adding channels
98
99Look for:
100- the same PR event appearing in GitHub, Linear, and local logs
101- repeated hook notifications for the same failure
102- comments or status churn that should be summarized instead of forwarded raw
103- channels that duplicate each other without adding a better action path
104
105Prefer:
106- one canonical summary
107- one owner
108- one primary channel
109- one fallback path
110
111### 4. Design the ECC-native workflow
112
113For each real notification need, define:
114- **source**
115- **gate**
116- **shape**: immediate alert, digest, queue, or dashboard-only
117- **channel**
118- **action**
119
120If ECC already has the primitive, prefer:
121- a skill for operator triage
122- a hook for automatic emission/enforcement
123- an agent for delegated classification
124- an MCP/connector only when a real bridge is missing
125
126### 5. Return an action-biased design
127
128End with:
129- what to keep
130- what to suppress
131- what to merge
132- what ECC should wrap next
133
134## Output Format
135
136```text
137CURRENT SURFACE
138- sources
139- channels
140- duplicates
141- gaps
142
143EVENT MODEL
144- critical
145- high
146- medium
147- low
148
149ROUTING PLAN
150- source -> channel
151- why
152- operator owner
153
154CONSOLIDATION
155- suppress
156- merge
157- canonical summaries
158
159NEXT ECC MOVE
160- skill / hook / agent / MCP
161- exact workflow to build next
162```
163
164## Recommendation Rules
165
166- prefer one strong lane over many weak ones
167- prefer digests for medium and low-signal updates
168- prefer hooks when the signal should emit automatically
169- prefer operator skills when the work is triage, routing, and review-first decision-making
170- prefer project-flow-ops when the root cause is backlog / PR coordination rather than alerts
171- prefer workspace-surface-audit when the user first needs a source inventory
172- if desktop notifications are enough, do not invent an unnecessary external bridge
173
174## Good Use Cases
175
176- "We have GitHub, Linear, and local hook alerts, but no single operator flow"
177- "Our CI failures are noisy and people ignore them"
178- "I want one notification policy across Claude, OpenCode, and Codex surfaces"
179- "Figure out what should interrupt versus land in a digest"
180- "Collapse overlapping notification PR ideas into one canonical ECC lane"
181
182## Related Skills
183
184- workspace-surface-audit
185- project-flow-ops
186- github-ops
187- knowledge-ops
188- customer-billing-ops when the notification pain is billing/customer operations rather than engineering
189
In the file
SKILL.md896 words
Files1
LicenceMIT
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈70
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
1,330
on trigger
The instruction body, read only when the skill fires.
0.70%
of a 200k window
Ten skills this size would take about 7% of the window before you open a file.
050k100k150k200k context window

1.4k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 5.6 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md5.6 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

$89 once
Unified Notifications Ops · MIT · affaan-m
one-time
Price$89 once
LicenceMIT — the author’s, unchanged by this purchase
Paid throughStripe, once, on the card you add at the checkout
Keeps workingfor good — the files are yours once they are on disk
Updatesevery update its author ships, delivered through this account

You can read the whole bundle before paying — the SKILL.md above is the product, not a preview of it. What the money buys is the delivery: the folder packaged and handed to your machine by key, every update its author ships, and our support if it does not do what this listing says. The terms of use are MIT, set by the author and unchanged by buying it here.

Payment runs through Stripe, on a page like this one rather than a redirect. Once there is an account it joins the same mcprush invoice as everything else you run, so there is never a second card to enter.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
Price$89
Referenceaffaan-m/unified-notifications-ops

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Publisher
Servers0