Unified Notifications Ops（統合通知運用）
このスキルは、真の問題が通知の欠落ではなく、断片化された通知システムそのものである場合に使用します。
仕事は、散在するイベントを1つの運用サーフェスに変えることです。
- 明確な重要度
- 明確な所有者
- 明確なルーティング
- 明確なフォローアップアクション
使用すべき場面
- ユーザーがGitHub、Linear、ローカルフック、デスクトップ通知、チャット、メールにわたる統合通知レーンを求めている場合
- CI障害、レビューリクエスト、イシュー更新、運用イベントがバラバラの場所に届いている場合
- 現在の設定がアクションではなくノイズを生み出している場合
- ユーザーが重複する通知ブランチやバックログ提案を1つのECCネイティブレーンに統合したい場合
- ワークスペースにすでにフック、MCP、接続ツールがあるが、首尾一貫した通知ポリシーがない場合
優先すべきサーフェス
すでに存在するものから始めます。
- GitHubのイシュー、PR、レビュー、コメント、CI
- Linearのイシュー/プロジェクトの移動
- ローカルフックイベントとセッションライフサイクルシグナル
- デスクトップ通知プリミティブ
- 実際に存在するメール/チャットサーフェス
ユーザーに別の通知プロダクトを導入するよう促すよりも、ECCネイティブのオーケストレーションを優先します。
絶対ルール
- トークン、シークレット、Webhookシークレット、内部識別子を決して露出しない
- 以下を分離する：
- イベントソース
- 重要度
- ルーティングチャネル
- 運用アクション
- 割り込みコストが不明な場合は、デフォルトでダイジェストファーストにする
- すべてのイベントをすべてのチャネルにファンアウトしない
- 真の修正がイシュートリアージ、フックポリシー、プロジェクトフローである場合は、それを明示的に伝える
イベントパイプライン
このレーンを次のように扱います。
- キャプチャ：イベントを取得
- 分類：緊急度と所有者を分類
- ルーティング：正しいチャネルにルーティング
- 統合：重複と低シグナルの変化を統合
- 付加：次の運用アクションを付加
目標は、より少なく、より良い通知です。
デフォルト重要度モデル
| クラス | 例 | デフォルト処理 |
|---|---|---|
| Critical | デフォルトブランチCIの破損、セキュリティイシュー、リリースブロック、デプロイ失敗 | 即時割り込み |
| High | レビューリクエスト、失敗PR、所有者ブロッキングハンドオフ | 当日アラート |
| Medium | イシューステータス変更、重要なコメント、バックログの動き | ダイジェストまたはキュー |
| Low | 繰り返し成功、ルーティンの変化、冗長なライフサイクルマーカー | 抑制または折りたたみ |
ワークスペースに重要度モデルがない場合は、自動化を提案する前にモデルを構築します。
ワークフロー
1. 現在のサーフェスを棚卸し
以下をリスト化します。
- イベントソース
- 現在のチャネル
- アラートを発する既存のフック/スクリプト
- 同じイベントへの重複パス
- 重要なことが表面化されていないサイレント障害ケース
ECCがすでに所有しているものを明確にします。
2. 割り込みに値するものを決定
各イベントファミリーについて、以下に答えます。
- 誰が知る必要があるか？
- どれだけ早く知る必要があるか？
- これは割り込むべきか、バッチすべきか、ログに記録すべきか？
次のデフォルトを使用します。
- リリース、CI、セキュリティ、所有者ブロッキングイベントは割り込み
- 中程度のシグナル更新はダイジェスト
- テレメトリーと低シグナルライフサイクルマーカーはログのみ
3. チャネルを追加する前に重複を統合
以下を確認します。
- 同じPRイベントがGitHub、Linear、ローカルログに表示されていないか
- 同じ障害に対して繰り返しフック通知が送られていないか
- そのまま転送するのではなく、要約すべきコメントやステータスの変化
- より良いアクションパスを追加せずに互いに重複しているチャネル
以下を優先します。
- 1つの正規の要約
- 1人の所有者
- 1つのプライマリチャネル
- 1つのフォールバックパス
4. ECCネイティブワークフローを設計
各実際の通知ニーズに対して、以下を定義します。
- ソース
- ゲート
- 形状：即時アラート、ダイジェスト、キュー、ダッシュボードのみ
- チャネル
- アクション
ECCがすでにプリミティブを持っている場合は、以下を優先します。
- オペレータトリアージ用のスキル
- 自動出力/実行用のフック
- 委任された分類用のエージェント
- 実際のブリッジが不足している場合のみMCP/コネクタ
5. アクション重視の設計を出力
以下で締めくくります。
- 何を保持するか
- 何を抑制するか
- 何を統合するか
- ECCが次にラップすべきこと
出力形式
現在のサーフェス
- ソース
- チャネル
- 重複
- ギャップ
イベントモデル
- critical
- high
- medium
- low
ルーティング計画
- ソース -> チャネル
- 理由
- 運用所有者
統合
- 抑制
- 統合
- 正規の要約
次のECCの動き
- スキル / フック / エージェント / MCP
- 次に構築する正確なワークフロー
推奨ルール
- 複数の弱いレーンよりも1つの強いレーンを優先する
- 中程度および低シグナルの更新にはダイジェストを優先する
- シグナルが自動で発せられるべき場合はフックを優先する
- トリアージ、ルーティング、レビューファーストの意思決定が作業である場合はオペレータスキルを優先する
- 根本原因がアラートではなくバックログ/PR調整である場合は
project-flow-opsを優先する - ユーザーがまずソース棚卸しを必要とする場合は
workspace-surface-auditを優先する - デスクトップ通知で十分な場合は、不要な外部ブリッジを発明しない
適したユースケース
- 「GitHub、Linear、ローカルフックアラートがあるが、単一のオペレータフローがない」
- 「CI障害がうるさく、誰も無視している」
- 「Claude、OpenCode、Codexのサーフェスにまたがる1つの通知ポリシーを設定したい」
- 「何が割り込むべきか、何がダイジェストに入るべきかを判断する」
- 「重複する通知PRのアイデアを1つの正規のECCレーンに統合する」
関連スキル
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops（通知の問題がエンジニアリングではなく、請求/顧客運用の場合）