| 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の失敗ノイズが多くて人々が無視している」
- 「Codex、OpenCode、Codexインターフェース全体で統一された通知戦略が欲しい」
- 「何を中断すべきで、何をサマリーに入れるべきかを判断してほしい」
- 「重複する通知PRのアイデアを1つの正規eccチャネルに統合してほしい」
関連スキル
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops 通知の痛みポイントがエンジニアリングではなく課金/顧客運用に関わる場合
