unified-notifications-ops
GitHub、Linear、デスクトップアラート、Webhook、接続された通信インターフェースを横断し、通知をECCネイティブの統合ワークフローとして一元管理します。アラートのルーティング・重複排除・エスカレーション、または通知の氾濫が本質的な問題となっている場合に活用してください。
description の原文を見る
将通知作为统一的 ECC 原生工作流进行操作，涵盖 GitHub、Linear、桌面提醒、钩子以及连接的通信界面。当真正的问题是告警路由、去重、升级或收件箱崩溃时使用。
SKILL.md 本文
統一通知運用
真の問題が通知の欠落ではなく、通知システムの断片化である場合に、このスキルを使用してください。
タスクは分散したイベントを単一のオペレーター画面に統合することです。以下を含みます：
- 明確な重大度レベル
- 明確な責任者
- 明確なルーティング
- 明確なネクストアクション
使用時期
- ユーザーが GitHub、Linear、ローカルフック、デスクトップアラート、チャット、またはメール間で統一された通知チャネルを確立したい
- CI 失敗、レビュー要求、問題更新、オペレーターイベントが異なる場所に散らばっている
- 現在の設定がノイズを生成しアクションを生成していない
- ユーザーが重複する通知の枝や積み残し提案を単一の ECC ネイティブチャネルに統合したい
- ワークスペースにフック、MCP、または接続ツールがあるが、統一された通知戦略が欠けている
優先インターフェース
既存リソースから開始してください：
- GitHub の issue、PR、レビュー、コメント、および CI
- Linear の issue/プロジェクトステータス変更
- ローカルフックイベントとセッションライフサイクル信号
- デスクトップ通知プリミティブ
- 接続されたメール/チャットインターフェース（実際に存在する場合）
独立した通知製品の採用を提案するのではなく、ECC ネイティブオーケストレーションを優先してください。
譲歩できないルール
- トークン、キー、Webhook シークレット、または内部識別子を決して露出させない
- 以下を区別してください：
- イベント送信元
- 重大度レベル
- ルーティングチャネル
- オペレーターアクション
- 中断コストが不明な場合、デフォルトではダイジェスト優先戦略を採用してください
- すべてのチャネルにすべてのイベントをブロードキャストしない
- 真の解決策がより良い問題分類、フック戦略、またはプロジェクトプロセスである場合、明確に述べてください
イベントパイプライン
チャネルを以下のものと考えてください：
- イベントをキャプチャする
- 緊急度と責任者に応じて分類する
- 適切なチャネルにルーティングする
- 重複と低信号ノイズをマージする
- 次のオペレーターアクションを追加する
目標はより少なく、より良い通知です。
デフォルト重大度レベルモデル
| レベル | 例 | デフォルト処理 |
|---|---|---|
| 重大 | デフォルトブランチ CI 破損、セキュリティ問題、リリースブロック、デプロイ失敗 | 即座に中断 |
| 高 | レビュー要求、PR 失敗、責任者をブロックしているハンドオフ | 本日中のリマインダー |
| 中 | 問題ステータス変更、重要なコメント、積み残し変更 | ダイジェストまたはキュー |
| 低 | 繰り返し成功、通常のノイズ、冗長ライフサイクルタグ | サプレスまたは折りたたみ |
ワークスペースに重大度レベルモデルがない場合は、自動化提案を行う前に最初に構築してください。
ワークフロー
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 失敗のノイズが大きく、人々は無視しています」
- 「Claude、OpenCode、Codex インターフェース間の統一された通知戦略が欲しい」
- 「何が中断すべきで、何がダイジェストに入るべきかを判断する」
- 「重複する通知 PR のアイデアを 1 つの規範的な ECC チャネルにマージする」
関連スキル
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops通知の痛点がエンジニアリングではなく請求/カスタマー運用に関わる場合
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- affaan-m
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/affaan-m/everything-claude-code / ライセンス: MIT
関連スキル
superfluid
Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード：Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool（member/distributor）、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper
civ-finish-quotes
実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。
nookplot
Base（Ethereum L2）上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。
web3-polymarket
Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。
ethskills
Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格（ERC-20、ERC-721、ERC-4626など）、Layer 2ネットワーク（Base、Arbitrum、Optimism、zkSync、Polygon）、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化（EIPライフサイクル、フォーク追跡、今後の変更予定）といったトピックを含みます。
xxyy-trade
このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。