unified-notifications-ops

Topics in the source

• 統合通知運用
• 使用する場面
• 優先インターフェース
• 絶対的なルール
• イベントパイプライン
• デフォルト重大度モデル
• ワークフロー
• 1. 現在のインターフェースの棚卸し

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

This is an excerpt. Refer to the complete source and its current requirements.