affaan-m/unified-notifications-ops
docs/ja-JP/skills/unified-notifications-ops/SKILL.md
GitHub、Linear、デスクトップアラート、フック、接続された通信インターフェースを網羅する、統合されたECCネイティブワークフローとして通知を運用する。真の問題がアラートルーティング、重複排除、エスカレーション、またはインボックス崩壊である場合に使用する。
$ install --global
skillsauthnpx skillsauth add affaan-m/everything-claude-code unified-notifications-opsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 18, 2026, 4:35 AM106.8s1 file scanned
SKILL.md
- name:
- unified-notifications-ops
- description:
- GitHub、Linear、デスクトップアラート、フック、接続された通信インターフェースを網羅する、統合されたECCネイティブワークフローとして通知を運用する。真の問題がアラートルーティング、重複排除、エスカレーション、またはインボックス崩壊である場合に使用する。
- origin:
- ECC
統合通知運用
真の問題が通知の欠如ではなく、通知システムの断片化にある場合にこのスキルを使用する。
目標は、分散したイベントを単一のオペレーターインターフェースに統合することであり、以下を含む：
- 明確な重大度レベル
- 明確な責任者
- 明確なルーティング
- 明確な次のアクション
使用する場面
- ユーザーが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通知の痛みポイントがエンジニアリングではなく課金/顧客運用に関わる場合
Related Skills
affaan-m/ito-compute
tools
VerifiedTrustedCommunity
Query live GPU inventory, submit an authenticated Itô fixed-rate RFQ, inspect RFQ or procurement status, revoke device credentials, and run explicitly gated node qualification through the separately installed canonical CLI. Use when a user asks to find H100/H200 capacity, request a fixed compute rate, check Itô compute status, validate GPU nodes, revoke Itô access, or rent or purchase GPU compute and needs the supported boundary explained.
247,258SKILL.mdUpdated Jul 24, 2026
affaan-m/social-publisher
testing
VerifiedTrustedCommunity
Agent-driven scheduling and publishing of social media posts across 13 platforms via SocialClaw. Use when the user wants to publish to X, LinkedIn, Instagram, Facebook Pages, TikTok, Discord, Telegram, YouTube, Reddit, WordPress, or Pinterest — or when managing campaigns, uploading media, or monitoring post delivery status.
247,258SKILL.mdUpdated May 26, 2026
affaan-m/cost-aware-llm-pipeline
development
VerifiedTrustedCommunity
LLM APIの使用量のコスト最適化パターン — タスクの複雑さによるモデルルーティング、予算追跡、リトライロジック、プロンプトキャッシング。
247,258SKILL.mdUpdated May 18, 2026
affaan-m/jira-integration
tools
VerifiedTrustedCommunity
Use this skill when retrieving Jira tickets, analyzing requirements, updating ticket status, adding comments, or transitioning issues. Provides Jira API patterns via MCP or direct REST calls.
247,258SKILL.mdUpdated Apr 10, 2026