Unified Notifications Ops

# 統合通知運用

真の問題が通知の欠如ではなく、通知システムの断片化にある場合にこのスキルを使用する。

目標は、分散したイベントを単一のオペレーターインターフェースに統合することであり、以下を含む：

* 明確な重大度レベル
* 明確な責任者
* 明確なルーティング
* 明確な次のアクション

## 使用する場面

* ユーザーがGitHub、Linear、ローカルフック、デスクトップアラート、チャット、メール間の統一通知チャネルを望んでいる
* CI失敗、レビューリクエスト、Issue更新、オペレーターイベントが各所に散在している
* 現在のセットアップがアクションではなくノイズを生成している
* ユーザーが重複する通知ブランチや積み残しのプロポーザルを単一のECCネイティブチャネルに統合したい
* ワークスペースにフック、MCP、または接続されたツールがあるが、一貫した通知戦略がない

## 優先インターフェース

既存のものから始める：

* GitHub Issues、PR、レビュー、コメント、CI
* Linear Issues/プロジェクトのステータス変更
* ローカルフックイベントとセッションライフサイクルシグナル
* デスクトップ通知プリミティブ
* 接続されたメール/チャットインターフェース（実際に存在する場合）

独立した通知製品をユーザーに勧めるより、ECCネイティブのオーケストレーションを優先する。

## 絶対的なルール

* トークン、シークレット、Webhookシークレット、内部識別子を決して公開しない
* 以下を区別する：
  * イベントソース
  * 重大度レベル
  * ルーティングチャネル
  * オペレーターアクション
* 中断コストが不明な場合はデフォルトでサマリーファーストアプローチを取る
* すべてのチャネルにすべてのイベントをブロードキャストしない
* 真の解決策がより良いIssueトリアージ、フック戦略、またはプロジェクトフローである場合は明示する

## イベントパイプライン

チャネルを以下として扱う：

1. **キャプチャ** イベント
2. **分類** 緊急度と責任者
3. **ルーティング** 適切なチャネルへ
4. **マージ** 重複と低シグナルノイズ
5. **添付** 次のオペレーターアクション

目標はより少なく、より良い通知である。

## デフォルト重大度モデル

| レベル | 例 | デフォルト処理 |
| --- | --- | --- |
| クリティカル | デフォルトブランチのCI破損、セキュリティ問題、リリースブロック、デプロイ失敗 | 即座に中断 |
| 高 | レビューリクエスト、PR失敗、責任者をブロックするハンドオフ | 当日アラート |
| 中 | Issueステータス変更、重要なコメント、バックログ変更 | サマリーまたはキュー |
| 低 | 繰り返しの成功、通常のノイズ、冗長なライフサイクルタグ | 抑制または折りたたみ |

ワークスペースに重大度モデルがない場合は、自動化を提案する前にまず構築する。

## ワークフロー

### 1. 現在のインターフェースの棚卸し

以下を列挙する：

* イベントソース
* 現在のチャネル
* アラートを発するフック/スクリプト
* 同じイベントの重複パス
* 重要事項が表示されないサイレント失敗のケース

ECCがすでに持っているものを指摘する。