| name | unified-notifications-ops |
| description | GitHub、Linear、デスクトップアラート、hook、接続済みコミュニケーションサーフェス全体で、通知を 1 つの ECC ネイティブワークフローとして運用します。本当の問題がアラートルーティング、重複排除、エスカレーション、または受信箱の崩壊である場合に使用します。 |
| origin | ECC |
Unified Notifications Ops
本当の問題が通知漏れではない場合にこのスキルを使用します。本当の問題は分断された通知システムです。
仕事は散在したイベントを 1 つのオペレーターサーフェスに変えることです:
- 明確な重大度
- 明確な所有権
- 明確なルーティング
- 明確なフォローアップアクション
使用タイミング
- ユーザーが GitHub、Linear、ローカル hook、デスクトップアラート、チャット、メールにまたがる統一された通知レーンを望む場合
- CI 障害、レビュー依頼、issue 更新、オペレーターイベントが切り離された場所に届いている場合
- 現在のセットアップがアクションではなくノイズを生成している場合
- ユーザーが重複する通知ブランチやバックログ提案を 1 つの ECC ネイティブレーンに統合したい場合
- ワークスペースに既に hook、MCP、接続済みツールがあるが、一貫した通知ポリシーがない場合
優先サーフェス
既に存在するものから始めます:
- GitHub issue、PR、レビュー、コメント、CI
- Linear issue/プロジェクトの動き
- ローカル hook イベントとセッションライフサイクルシグナル
- デスクトップ通知プリミティブ
- 実際に存在する場合の接続済み email/chat サーフェス
別の通知プロダクトをユーザーに採用させるよりも、ECC ネイティブなオーケストレーションを優先します。
ノンネゴシャブルなルール
- トークン、シークレット、webhook シークレット、内部識別子を絶対に公開しない
- 次を分離する:
- イベントソース
- 重大度
- ルーティングチャネル
- オペレーターアクション
- 割り込みコストが不明な場合はダイジェストファーストをデフォルトにする
- すべてのイベントをすべてのチャネルにファンアウトしない
- 本当の修正がより良い issue トリアージ、hook ポリシー、またはプロジェクトフローである場合、それを明示的に伝える
イベントパイプライン
レーンを以下として扱います:
- イベントを Capture
- 緊急度とオーナーを Classify
- 正しいチャネルへ Route
- 重複と低シグナルの churn を Collapse
- 次のオペレーターアクションを Attach
目標はより少なく、より良い通知です。
デフォルトの重大度モデル
| クラス | 例 | デフォルト処理 |
|---|
| Critical | default ブランチの CI 破損、セキュリティ問題、ブロック中のリリース、デプロイ失敗 | 今すぐ割り込む |
| High | レビュー依頼、失敗している PR、オーナーブロックのハンドオフ | 当日中のアラート |
| Medium | issue 状態の変更、注目すべきコメント、バックログの動き | ダイジェストまたはキュー |
| Low | 繰り返しの成功、ルーティンな churn、冗長なライフサイクルマーカー | 抑制または折りたたみ |
ワークスペースに重大度モデルがない場合、自動化を提案する前にそれを構築します。
ワークフロー
1. 現在のサーフェスをインベントリする
リストアップ:
- イベントソース
- 現在のチャネル
- アラートを発する既存の hook/スクリプト
- 同じイベントの重複パス
- 重要なことが表面化されていないサイレント障害ケース
ECC が既に所有しているものを明示する。
2. 何が割り込みに値するか判断する
各イベントファミリーに対して答える:
- 誰が知る必要があるか？
- どれくらい早く知る必要があるか？
- 割り込むべきか、バッチするか、ログだけか？
以下のデフォルトを使用:
- リリース、CI、セキュリティ、オーナーブロックイベントには割り込み
- 中程度のシグナル更新にはダイジェスト
- テレメトリや低シグナルのライフサイクルマーカーにはログのみ
3. チャネルを追加する前に重複を折りたたむ
以下を探す:
- GitHub、Linear、ローカルログに同じ PR イベントが出現
- 同じ障害に対する繰り返しの hook 通知
- raw で転送するのではなく要約すべきコメントやステータスの churn
- より良いアクションパスを追加せず互いに重複するチャネル
優先:
- 1 つの正規サマリー
- 1 人のオーナー
- 1 つのプライマリチャネル
- 1 つのフォールバックパス
4. ECC ネイティブなワークフローを設計する
各実際の通知ニーズに対して定義:
- source
- gate
- shape: 即時アラート、ダイジェスト、キュー、ダッシュボードのみ
- channel
- action
ECC に既にプリミティブがある場合は優先:
- オペレータートリアージ用のスキル
- 自動発行/強制用の hook
- 委譲分類用のエージェント
- 実際のブリッジが欠けている場合のみ MCP/connector
5. アクション指向の設計を返す
最後に示す:
- 何を残すか
- 何を抑制するか
- 何をマージするか
- 次に ECC が何をラップすべきか
出力フォーマット
CURRENT SURFACE
- ソース
- チャネル
- 重複
- ギャップ
EVENT MODEL
- critical
- high
- medium
- low
ROUTING PLAN
- ソース -> チャネル
- 理由
- オペレーターオーナー
CONSOLIDATION
- 抑制
- マージ
- 正規サマリー
NEXT ECC MOVE
- skill / hook / agent / MCP
- 次に構築する正確なワークフロー
推奨ルール
- 多くの弱いレーンよりも 1 つの強いレーンを優先
- 中程度および低シグナル更新にはダイジェストを優先
- シグナルが自動的に発行されるべき場合は hook を優先
- 作業がトリアージ、ルーティング、レビューファーストな意思決定の場合はオペレータースキルを優先
- 根本原因がアラートではなくバックログ/PR 調整の場合は
project-flow-ops を優先
- ユーザーがまずソースインベントリを必要とする場合は
workspace-surface-audit を優先
- デスクトップ通知で十分な場合、不要な外部ブリッジを発明しない
良いユースケース
- "GitHub、Linear、ローカル hook アラートがあるが、単一のオペレーターフローがない"
- "CI 障害がノイジーで、みんな無視する"
- "Claude、OpenCode、Codex サーフェス全体で 1 つの通知ポリシーが欲しい"
- "何を割り込み、何をダイジェストに入れるべきかを判断する"
- "重複する通知 PR アイデアを 1 つの正規 ECC レーンに折りたたむ"
関連スキル
workspace-surface-auditproject-flow-opsgithub-opsknowledge-ops- 通知のペインがエンジニアリングではなく課金/顧客オペレーションである場合は
customer-billing-ops
