統合通知オペレーション は何をしますか？
このスキルは、本当の問題が欠落したピン（通知）ではなく、断片化された通知システムである場合に使用します。
役割は、散在するイベントを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が次にラップすべきもの
出力形式
CURRENT SURFACE
- ソース
- チャネル
- 重複
- ギャップ
EVENT MODEL
- critical
- high
- medium
- low
ROUTING PLAN
- ソース -> チャネル
- 理由
- オペレーター所有者
CONSOLIDATION
- 抑制
- マージ
- 正規の要約
NEXT ECC MOVE
- スキル / フック / エージェント / 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（通知の問題がエンジニアリングではなく、請求/顧客運用に関する場合）