Unified Notifications Ops
FreeStreamline alerts across platforms into a single interface.
Free · Opens the source repo
What Unified Notifications Ops does
Unified Notifications Ops is designed to tackle the fragmentation of notification systems across various platforms such as GitHub, Linear, and desktop alerts. By consolidating these disparate event sources into a single operator interface, this skill ensures that notifications are not only centralized but also prioritized and actionable. The focus is on delivering clearer severity levels, responsible parties, routing paths, and next actions, which helps in reducing noise and improving response times to critical events.
This skill is particularly beneficial for teams facing issues with alert routing, duplication, and inbox overload. It streamlines the notification process by capturing events from multiple sources, classifying them by urgency, and routing them appropriately while merging duplicates to minimize signal noise. Users can expect a significant reduction in irrelevant notifications, allowing them to focus on what truly matters, thus enhancing productivity and operational efficiency.
Ideal for developers and operators who manage multiple tools, Unified Notifications Ops integrates seamlessly with existing workflows. It encourages a proactive approach to notification management by establishing clear guidelines for what constitutes an alert, how to handle various levels of urgency, and how to effectively triage issues as they arise. With a structured event pipeline, users can ensure that critical alerts are addressed immediately while less urgent notifications are summarized or batched, reducing the cognitive load on teams.
By implementing this skill, users can expect a more coherent notification strategy that not only improves individual productivity but also enhances team collaboration. This is particularly useful in environments where multiple communication channels exist but lack a unified strategy for managing alerts and notifications, leading to missed opportunities and delayed responses.
When to use it
Use this skill when you need to unify notifications from various sources into a single, manageable interface.
When not to use it
This skill may not be suitable if your notification needs are simple or if you do not have multiple sources generating alerts.
What you can build with it
Integrating Multiple Alert Sources
A team using GitHub, Linear, and local hooks can unify their alerts into a single dashboard, improving response times.
Reducing Notification Noise
Developers overwhelmed by CI failure alerts can use this skill to filter out irrelevant notifications and focus on critical issues.
Establishing Clear Notification Protocols
Teams can define clear rules for what constitutes an alert and how to handle different levels of urgency, streamlining their workflow.
How to install Unified Notifications Ops
View source1. Install with the skills CLI
npx skills add affaan-m/ecc/unified-notifications-ops --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by affaan-m統合通知運用
真の問題が通知の欠如ではなく、通知システムの断片化にある場合にこのスキルを使用する。
目標は、分散したイベントを単一のオペレーターインターフェースに統合することであり、以下を含む：
- 明確な重大度レベル
- 明確な責任者
- 明確なルーティング
- 明確な次のアクション
使用する場面
- ユーザーがGitHub、Linear、ローカルフック、デスクトップアラート、チャット、メール間の統一通知チャネルを望んでいる
- CI失敗、レビューリクエスト、Issue更新、オペレーターイベントが各所に散在している
- 現在のセットアップがアクションではなくノイズを生成している
- ユーザーが重複する通知ブランチや積み残しのプロポーザルを単一のECCネイティブチャネルに統合したい
- ワークスペースにフック、MCP、または接続されたツールがあるが、一貫した通知戦略がない
優先インターフェース
既存のものから始める：
- GitHub Issues、PR、レビュー、コメント、CI
- Linear Issues/プロジェクトのステータス変更
- ローカルフックイベントとセッションライフサイクルシグナル
- デスクトップ通知プリミティブ
- 接続されたメール/チャットインターフェース（実際に存在する場合）
独立した通知製品をユーザーに勧めるより、ECCネイティブのオーケストレーションを優先する。
絶対的なルール
- トークン、シークレット、Webhookシークレット、内部識別子を決して公開しない
- 以下を区別する：
- イベントソース
- 重大度レベル
- ルーティングチャネル
- オペレーターアクション
- 中断コストが不明な場合はデフォルトでサマリーファーストアプローチを取る
- すべてのチャネルにすべてのイベントをブロードキャストしない
- 真の解決策がより良いIssueトリアージ、フック戦略、またはプロジェクトフローである場合は明示する
イベントパイプライン
チャネルを以下として扱う：
- キャプチャ イベント
- 分類 緊急度と責任者
- ルーティング 適切なチャネルへ
- マージ 重複と低シグナルノイズ
- 添付 次のオペレーターアクション
目標はより少なく、より良い通知である。
デフォルト重大度モデル
| レベル | 例 | デフォルト処理 |
|---|---|---|
| クリティカル | デフォルトブランチのCI破損、セキュリティ問題、リリースブロック、デプロイ失敗 | 即座に中断 |
| 高 | レビューリクエスト、PR失敗、責任者をブロックするハンドオフ | 当日アラート |
| 中 | Issueステータス変更、重要なコメント、バックログ変更 | サマリーまたはキュー |
| 低 | 繰り返しの成功、通常のノイズ、冗長なライフサイクルタグ | 抑制または折りたたみ |
ワークスペースに重大度モデルがない場合は、自動化を提案する前にまず構築する。
ワークフロー
1. 現在のインターフェースの棚卸し
以下を列挙する：
- イベントソース
- 現在のチャネル
- アラートを発するフック/スクリプト
- 同じイベントの重複パス
- 重要事項が表示されないサイレント失敗のケース
ECCがすでに持っているものを指摘する。
2. 何が中断を正当化するかを決定する
各イベントファミリーについて答える：
- 誰が知る必要があるか？
- どれくらい早く知る必要があるか？
- 中断すべきか、バッチ処理すべきか、ログに記録するだけにすべきか？
以下のデフォルトを使用する：
- リリース、CI、セキュリティ、責任者をブロックするイベントは中断
- 中程度のシグナル更新にはサマリーを使用
- テレメトリと低シグナルライフサイクルタグはログ記録のみ
3. チャネルを追加する前に重複をマージする
以下を確認する：
- 同じPRイベントがGitHub、Linear、ローカルログに表示されている
- 同じ失敗に対する重複したフック通知
- 直接転送するより要約すべきコメントやステータス変更
- より良いアクションパスを提供せずに互いを複製しているチャネル
以下を優先する：
- 1つの正規サマリー
- 1人の責任者
- 1つのプライマリチャネル
- 1つのフォールバックパス
4. ECCネイティブワークフローを設計する
各実際の通知ニーズについて定義する：
- ソース
- ゲーティング
- 形式：即時アラート、サマリー、キュー、またはダッシュボードのみ
- チャネル
- アクション
ECCがすでにプリミティブを持っている場合は優先して使用する：
- オペレータートリアージスキル
- 自動トリガー/実行フック
- 委譲されたトリアージのためのエージェント
- 本当にブリッジが欠けている場合のみMCP/コネクター
5. アクション指向の設計を返す
最終出力：
- 保持するもの
- 抑制するもの
- マージするもの
- ECCが次にカプセル化すべきもの
出力フォーマット
現在のサーフェス
- ソース
- チャネル
- 重複
- ギャップ
イベントモデル
- クリティカル
- 高
- 中
- 低
ルーティング計画
- ソース -> チャネル
- 理由
- オペレーター/担当者
統合
- 抑制
- マージ
- 正規サマリー
次のECCアクション
- スキル/フック/エージェント/MCP
- 次に構築する具体的なワークフロー
推奨ルール
- 複数の弱いチャネルより1つの強いチャネルを優先する
- 中程度と低シグナルの更新にはサマリーを優先する
- シグナルが自動トリガーされるべき場合はフックを優先する
- 作業がトリアージ、ルーティング、レビュー決定を伴う場合はオペレータースキルを優先する
- 根本原因がアラートではなくバックログ/PR調整である場合は
project-flow-opsを優先する - ユーザーが最初にソースの棚卸しを必要とする場合は
workspace-surface-auditを優先する - デスクトップ通知で十分な場合は不要な外部ブリッジを発明しない
良いユースケース
- 「GitHub、Linear、ローカルフックアラートがあるが、統一されたオペレーターフローがない」
- 「CIの失敗ノイズが多くて人々が無視している」
- 「Claude、OpenCode、Codexインターフェース全体で統一された通知戦略が欲しい」
- 「何を中断すべきで、何をサマリーに入れるべきかを判断してほしい」
- 「重複する通知PRのアイデアを1つの正規ECCチャネルに統合してほしい」
関連スキル
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops通知の痛みポイントがエンジニアリングではなく課金/顧客運用に関わる場合
Frequently asked questions about Unified Notifications Ops
Similar skills
Agent-Browser Core
Efficient browser automation for AI agents.
Setup My IQ
Effortlessly create and update your personal context portfolio.
CRM Maintenance
Automate HubSpot updates from your calendar and emails.
Zoom MCP
Streamline access to Zoom meeting assets and recordings.
Slack Automation
Automate tasks and extract data from Slack easily.
SMB Onboard
Guides small business owners through initial tool setup.