uptimelens/claude-plugins

UptimeLens On-Call

UptimeLens MCPサーバーを通じて、顧客自身のリソース上でUptimeLensのオンコールおよびエスカレーションワークフローを操作します。このスキルは、アラートに関する質問（「誰がオンコール？」「そのページを確認」「シフトをカバーして」）を、正しいMCPツール呼び出しのシーケンスに変換します。

このスキルを使用するタイミング

インシデントアラートの運用面で使用します：

• 現在オンコール担当者を特定する（または誰もいない理由を確認する）。
• 誰かをページングしているアクティブなエスカレーションを確認またはスヌーズする。
• 時間枠内でオンコールローテーションを上書きしてシフトをカバーする。
• エスカレーションの実行（アクティブなページと履歴）とエスカレーションポリシーを調査する。

インシデントの根本原因分析（ページ管理とは対照的）には、読み取り専用のtriage_incident MCPプロンプト、または読み取りツールget_incident、get_root_cause、list_status_changes、query_metricsを優先してください。このスキルはオンコール/エスカレーションレイヤーに留まり、誰が行動すべきかの判断に役立つ場合にのみインシデントコンテキストにリンクします。

前提条件

1. UptimeLens MCPサーバーがこのクライアントに接続されていること。読み取りツールはすべてのプランで動作します。
2. 書き込みアクション（acknowledge_escalation、bulk_acknowledge_escalation、resolve_escalation、snooze_escalation、escalate_escalation、create_on_call_override、update_on_call_override、delete_on_call_override、create_cover_request、accept_cover_request、decline_cover_request）には読み書き可能なAPIトークンとProプラン以上が必要です。読み取り専用トークンの場合、書き込みツールはリストに表示されません。FreeプランではFeatureNotAvailableを返します。
3. これらの一部には、プランゲートに加えて2番目の機能ごとのゲートがあり、すべてが同じものではありません：
   • create_on_call_override、update_on_call_override、および**accept_cover_requestにはオンコール上書き**機能が必要です。受け入れはアクティブな上書きを生成するため、カウントされます。これが機能の販売対象です。（有料プランで作成され、ダウングレード後に受け入れられた保留リクエストは、プランに含まれなくなった上書きを作成することになります。そのギャップは意図的に埋められています。）
   • create_cover_requestには異なる機能、つまりオンコールカバーリクエスト機能が必要です。これにより、プランは一方を含み、他方を含まないことができます。
   • delete_on_call_overrideとdecline_cover_requestは意図的にゲートなしです。ダウングレード後も元に戻す操作が可能である必要があります。そうでなければ、編集できなくなったシフト交換はキャンセルもできなくなります。 これらのいずれも、読み書き可能なトークンであってもFeatureNotAvailableを返す可能性があります。

書き込みツールが見つからないか、FeatureNotAvailableを返す場合は、再試行する代わりに、どの前提条件が満たされていないかをユーザーに伝えてください。

ツール

これらのツールはUptimeLens MCPサーバーから提供されます。完全修飾名でUptimeLens:<tool>として参照してください。UptimeLensは、このクライアントでコネクタに付けられた名前に置き換えてください。そうしないとツールが見つからない可能性があります。

読み取り（発見とコンテキスト）：

• UptimeLens:list_on_call_schedules — スケジュール。who_is_on_callとcreate_on_call_overrideが必要とするscheduleIdのソースです。
• UptimeLens:who_is_on_call — あるスケジュールの現在のオンコール担当者。誰もいない場合はgapReasonを返します。
• UptimeLens:get_on_call_schedule — あるスケジュールの今後N日間（デフォルト7、最大90）の予定表。各シフト（誰が、いつ、ローテーションか上書きか）、カバレッジギャップとその理由、カバレッジサマリーを含みます。将来のカバレッジに使用します。who_is_on_callは現在のみです。
• UptimeLens:list_on_call_overrides — あるスケジュールのアクティブおよび今後の上書き。update_on_call_overrideとdelete_on_call_overrideが必要とするidのソースです。各エントリには、ユーザー（シフトを担当する人）、リクエスター（requestedBy、保留中のカバーリクエストの場合のみ設定 — 誰がカバーを依頼したか）、時間枠、理由、状態が含まれます。active上書きのみ編集可能です。pendingエントリは、まだ対象ユーザーの受け入れを待っているカバーリクエストであり、update_on_call_overrideは拒否します。過去の上書きはリストされません。
• UptimeLens:list_escalation_runs — エスカレーションの実行（アクティブなページと履歴）。acknowledge_escalation、snooze_escalation、escalate_escalationが必要とするrunIdのソースです。進行度は1ベース：currentStep（エスカレーションが到達したステップ）、nextStep（次に発動するステップ）、totalSteps。
• UptimeLens:get_escalation_run — 1つの実行の完全な状態：エスカレーションが到達したステップと次に発動するステップ（currentStep/nextStep（totalSteps中））、繰り返しの進行度、緊急度、確認/解決方法（終了した理由）、スヌーズと確認タイムアウトの期限、nextActionAt、トリガーとなったモニター/インシデント。
• UptimeLens:get_escalation_run_timeline — 1つの実行の時系列イベントログ：通知、配信結果、確認タイムアウト、スキップされたターゲット、繰り返し、解決 — 「何が起こったか/なぜエスカレーションしたか」の最も豊富な情報源。
• UptimeLens:list_escalation_policies — オンコールアラートルール。
• UptimeLens:get_escalation_policy — 1つのポリシーの詳細：1..Nの番号が付けられた順序付きステップ（list_escalation_runs内のcurrentStep/nextStepの番号はこれを参照）、各ステップの遅延、ターゲット戦略、ターゲット。who_is_on_callでスケジュールターゲットを解決し、list_team_membersでユーザーターゲットを解決します。
• UptimeLens:list_team_members — チームメンバー。create_on_call_overrideが必要とするuserIdのソースです。

書き込み（状態変更 — 「書き込み前に確認」を参照）：

• UptimeLens:acknowledge_escalation — 1つのアクティブな実行に対するそれ以上のページングを停止します。入力：runId。
• UptimeLens:resolve_escalation — ページを完全に閉じます。入力：runId。確認とは異なり、解決された実行は再ページングされないため、根本的な問題が確実に修正された場合に使用します。騒がしいアラートを止める方法としては使用しないでください。
• UptimeLens:bulk_acknowledge_escalation — 多くのアクティブな実行を一度に確認します。入力：runIds（1～50）。部分的な成功：すでに解決/不明な実行はスキップとしてカウントされ、エラーではありません。list_escalation_runs(state=active)の後に使用して、バッチをクリアします。
• UptimeLens:snooze_escalation — 1つの実行のページングを一定時間停止します。入力：runId、durationMinutes（1～240）。
• UptimeLens:escalate_escalation — タイマーが切れるのを待たずに、まだページングされていない次のステップを今すぐページングします（「今すぐエスカレーション」）。入力：runId。何もスキップされません：nextStepとして表示されているステップが発動します。最後のステップの後、次の繰り返しがすぐに開始されます。繰り返しが残っていない場合、実行は使い果たされて閉じられます（nextStepは0 — ページングできる人がもういないことをユーザーに伝えてください）。実行はアクティブに戻り、緊急度はhighになります。テスト実行と完了した実行では拒否されます。
• UptimeLens:create_on_call_override — スケジュールの時間枠内でユーザーをオンコールに設定します。入力：scheduleId、userId、endAt。オプション：startAt（デフォルトは現在）、reason。オンコール上書き機能が必要です（前提条件を参照）。
• UptimeLens:update_on_call_override — 既存の上書きをその場で編集します。endAtまたはreasonを変更し、（開始前のみ）userIdまたはstartAtを変更します。入力：id（create_on_call_overrideの結果から、または作成したばかりでない場合はlist_on_call_overridesで発見）と変更するフィールド。フィールドを省略すると変更されません。これにより、カバーを短縮、延長、または再割り当てします。交換をまったく行わない場合はdelete_on_call_overrideを使用します。オンコール上書き機能が必要です。
• UptimeLens:delete_on_call_override — 上書きを完全に削除します。交換はキャンセルされ、通常のローテーションが再び適用されます。入力：id。カバーをまったく行わない場合は、編集ではなくこれを使用します。
• UptimeLens:create_cover_request — シフトを割り当てるのではなく、チームメートに時間枠を依頼します。pendingリクエストを作成し、対象ユーザーにメールを送信します。対象ユーザーが受け入れると、アクティブな上書きになります。入力：scheduleId、userId（依頼されている人）、startAt、endAt。オプション：reason。依頼なしで即座にシフトを割り当てる場合は、create_on_call_overrideを使用します。
• UptimeLens:accept_cover_request — pendingのカバーリクエストを受け入れます → アクティブな上書きになります（対象ユーザーがシフトを担当します）。入力：id（list_on_call_overridesからのpendingエントリ）。対象ユーザーまたは管理者のみが受け入れ可能です。
• UptimeLens:decline_cover_request — pendingのカバーリクエストを辞退します（上書きは作成されません）。入力：id（list_on_call_overridesからのpendingエントリ）。対象ユーザーまたは管理者のみが辞退可能です。

コアワークフロー：オンコールアラートの処理

ほとんどの書き込みツールは、読み取りツールでのみ取得できるIDを必要とするため、常に最初に発見してください。以下のチェックリストをコピーして、それに従って作業してください：

オンコール応答：
- [ ] 1. アクティブなエスカレーション実行を見つける（list_escalation_runs、state=active、isTest=false）
- [ ] 2. 対象の実行を選択する（startedAtでランク付け。緊急度とcurrentStep/totalStepsを確認）
- [ ] 3. 必要に応じてコンテキストを追加する（incidentId → get_incident；triggeringMonitorId → list_status_changes → get_root_cause）
- [ ] 4. 決定する：確認（引き受ける、ページング停止）またはスヌーズ（N分間一時停止、ページング再開）
- [ ] 5. アクションをユーザーに確認し、実行のidを使用して書き込みツールを呼び出す

ステップ1 — アクティブな実行を見つける。 state="active"を指定してlist_escalation_runsを呼び出します。実際のインシデントトリガーのページにはisTest=falseを使用します。isTest=trueは「自分をページングする」テスト実行であり、本番インシデントとして扱うべきではありません。

ステップ2 — 実行を選択する。 各実行にはid（これが書き込みツールのrunIdです）、urgency（high/low）、totalSteps中のcurrentStep（エスカレーションがどこまで上がったか — 1ベース。数値が大きいほど、より多くの人がページングされたことを示します。nextStepは次にページングされる人です）、およびstartedAtがあります。複数がアクティブな場合、startedAtでランク付けし（最も古いものから）、high緊急度を最初に表示します。

ステップ3 — コンテキスト（オプション）。 実行にincidentIdがある場合、get_incidentを呼び出して影響とタイムラインを取得します。triggeringMonitorIdがある場合、そのモニターIDでlist_status_changesを呼び出して最近のアップ/ダウン変更を確認し、そのリストからstatusChangeIdを指定してget_root_causeを呼び出し、プローブごとのネットワーク診断を取得します。これはユーザーの判断を助けるためだけに使用し、ここで本格的な調査を開始しないでください。

ステップ4 / 5 — 行動する。 確認、スヌーズ、またはエスカレーション（以下参照）を選択し、確認してから書き込みます。

確認、解決、スヌーズ、またはエスカレーション

• 確認（acknowledge_escalation）は「私がこれを引き受けました」を意味します — 作業中はページングが停止します。これは「引き受ける」「対応します」「サイレンス」ページに対して正しい答えです。もうアクティブではない実行を確認すると、EscalationRunAlreadyResolvedエラーが返されます — 無害です（すでに確認または解決されています）。すでに処理済みとして報告し、再試行しないでください。

• 解決（resolve_escalation）は「これで終わり」を意味します — 実行は完全に閉じられ、再ページングされません。ユーザーが根本的な問題は修正されたと言った場合に使用します。単に自分が対応しているという場合ではありません。インシデントが解決されると実行も自動的に解決されるため、手動での解決は、ページが問題よりも長く続いている場合に使用します。元に戻せないため、迷った場合は確認を優先してください。

• スヌーズ（snooze_escalation）は「durationMinutesの間静かにして、その後再びページングする」を意味します — 延期であり、所有ではありません。べき等ではありません：呼び出すたびにスヌーズウィンドウが現在+N分にリセットされるため、再度呼び出すとサイレンスが延長されます。適合する最小の時間（1～240）を使用し、アラートに実際の所有者が必要な場合に、確認の代わりにスヌーズしないでください。

• 今すぐエスカレーション（escalate_escalation）は「もっと人材が必要だ、今すぐ」を意味します — 実行のnextStepが待機時間を待たずに即座にページングされ、緊急度はhighになり（静穏時間は適用されなくなり）、確認済みの実行は再びアクティブになります。現在の応答者が対応できない、または誰も応答していないとユーザーが言った場合に使用します。これはスヌーズの逆なので、同じ実行に対して1ターンで両方を呼び出さないでください。どのステップがページングされるかをユーザーに伝えてください（get_escalation_runのnextStep）。

間違った実行を確認すると、実際のページが沈黙し、誰にも警告されないため、runIdがユーザーが意図するアラートと一致することを確認してください。

カバレッジギャップ

who_is_on_callは、誰もオンコールでない場合にgapReasonを返します：

• schedule_disabled — スケジュールがオフになっています。ポリシーは他のターゲットに依存しています。
• no_active_rotations / no_rotation_members — スケジュールに現在ページングする人が割り当てられていません。
• outside_active_window — このスケジュールのアクティブ時間外です。

ギャップがあり、誰かがページを受け取る必要がある場合、create_on_call_overrideは特定のユーザーを時間枠内でオンコールに設定します。list_on_call_schedulesでscheduleIdを、list_team_membersでuserIdを発見します（チームメンバーはメールや電話番号を公開しません — 名前/役割でマッチングします）。

who_is_on_callは現在発生しているギャップのみを報告します。誰かをページングする前にギャップを見つけるには、スケジュールに対してget_on_call_scheduleを呼び出します。そのgaps配列には、今後N日間のカバーされていないすべての時間枠が同じ理由とともにリストされ、coveragePercentは期間がどの程度カバーされているかを要約します。これはwho_is_on_callのプロアクティブなコンパニオンです。

書き込み前に確認

読み取りとトリアージは自由に行ってください。書き込みツールについては、これから行うことを説明し、最初にユーザーの承認を得てください。これらは誰がページングされるかを変更します：

• 確認/スヌーズ：実行の名前（緊急度、トリガーされたもの）、スヌーズの場合は分数を指定します。
• 解決：ページが完全に閉じられ、再ページングされないことを明確に伝えます。根本的な問題が実際に修正されたかどうかを尋ねてください — 「止めて」は確認またはスヌーズのリクエストであり、解決ではありません。
• 上書き：スケジュール、ユーザー、正確な時間枠（startAt–endAt、UTC RFC3339）を指定します。時間枠が真夜中をまたぐ場合、endAtの日付は翌日になります。endAtはstartAtより後である必要があります。
• 上書きの削除 / カバーリクエストの辞退：誰のシフトが通常のローテーションに戻るかを指定します。カバーのキャンセルは、作成と同様に誰がページングされるかを変更します。

これらのほとんどは元に戻せます — 上書きは編集または短縮できます。確認またはスヌーズは再エスカレーションできます。そのため、目的は明確な人間の判断であり、許可の壁ではありません。元に戻せないものは2つあります：

...

[翻訳のために切り詰められました]