統合通知運用
真の問題が通知の欠如ではなく、通知システムの断片化にある場合にこのスキルを使用する。
目標は、分散したイベントを単一のオペレーターインターフェースに統合することであり、以下を含む：
- 明確な重大度レベル
- 明確な責任者
- 明確なルーティング
- 明確な次のアクション
使用する場面
- ユーザーがGitHub、Linear、ローカルフック、デスクトップアラート、チャット、メール間の統一通知チャネルを望んでいる
- CI失敗、レビューリクエスト、Issue更新、オペレーターイベントが各所に散在している
- 現在のセットアップがアクションではなくノイズを生成している
- ユーザーが重複する通知ブランチや積み残しのプロポーザルを単一のECCネイティブチャネルに統合したい
- ワークスペースにフック、MCP、または接続されたツールがあるが、一貫した通知戦略がない
優先インターフェース
既存のものから始める：
- GitHub Issues、PR、レビュー、コメント、CI
- Linear Issues/プロジェクトのステータス変更
- ローカルフックイベントとセッションライフサイクルシグナル
- デスクトップ通知プリミティブ
- 接続されたメール/チャットインターフェース（実際に存在する場合）
独立した通知製品をユーザーに勧めるより、ECCネイティブのオーケストレーションを優先する。
絶対的なルール
- トークン、シークレット、Webhookシークレット、内部識別子を決して公開しない
- 以下を区別する：
- イベントソース
- 重大度レベル
- ルーティングチャネル
- オペレーターアクション
- 中断コストが不明な場合はデフォルトでサマリーファーストアプローチを取る
- すべてのチャネルにすべてのイベントをブロードキャストしない
- 真の解決策がより良いIssueトリアージ、フック戦略、またはプロジェクトフローである場合は明示する
イベントパイプライン
チャネルを以下として扱う：
- キャプチャ イベント
- 分類 緊急度と責任者
- ルーティング 適切なチャネルへ
- マージ 重複と低シグナルノイズ
- 添付 次のオペレーターアクション
目標はより少なく、より良い通知である。
デフォルト重大度モデル
| レベル | 例 | デフォルト処理 |
|---|---|---|
| クリティカル | デフォルトブランチのCI破損、セキュリティ問題、リリースブロック、デプロイ失敗 | 即座に中断 |
| 高 | レビューリクエスト、PR失敗、責任者をブロックするハンドオフ | 当日アラート |
| 中 | I… |
