uptimelens/claude-plugins

UptimeLens On-Call

透過 UptimeLens MCP 伺服器，在客戶自己的資源上操作 UptimeLens 的 on-call 與升級工作流程。這個技能能將一個警報相關的問題（如「誰在值班？」、「確認那個分頁」、「幫我代班」）轉換為正確的 MCP 工具呼叫序列。

何時使用此技能

用於事件警報的操作層面：

• 查詢目前誰在值班（或為什麼沒人值班）。
• 確認或靜音一個正在呼叫人員的主動升級。
• 透過覆寫 on-call 輪值來涵蓋某段時間的班表。
• 檢視升級執行（主動分頁與歷史紀錄）與升級政策。

對於事件的根本原因分析（相對於管理分頁），請優先使用唯讀的 triage_incident MCP 提示，或唯讀工具 get_incident、get_root_cause、list_status_changes 與 query_metrics。此技能專注於 on-call/升級層面，僅在需要協助決定誰應採取行動時才連結至事件上下文。

先決條件

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 Token 以及 Pro 或更高方案。使用唯讀 Token 時，寫入工具根本不會列出；在免費方案上，它們會回傳 FeatureNotAvailable。
3. 其中一些操作在方案限制之外，還有第二層按功能授權，且它們並非全部相同：
   • create_on_call_override、update_on_call_override 與 accept_cover_request 需要 on-call override 功能。接受請求也算，因為它會產生一個主動覆寫——正是該功能所販售的內容。（否則，一個在付費方案建立的待定請求，在降級後被接受，會產生一個方案不再包含的覆寫；這個漏洞已被刻意封閉。）
   • create_cover_request 需要一個不同的功能——on-call cover requests——因此一個方案可以包含其中一個而不包含另一個。
   • delete_on_call_override 和 decline_cover_request 是刻意不設閘門的：在降級後，必須仍能撤銷操作，否則你無法再編輯的班表交換，也將無法取消。 即使使用讀寫 Token，這些操作仍可能回傳 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 — 目前一個排程的 on-call 人員；當無人值班時回傳 gapReason。
• UptimeLens:get_on_call_schedule — 一個排程未來 N 天（預設 7 天，最多 90 天）的即將到來輪值表：每個班次（誰、何時、輪值 vs 覆寫）、覆蓋缺口及其原因，以及覆蓋摘要。用於未來的覆蓋；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 — 一個執行的完整狀態：升級已到達哪一步以及將觸發哪一步（currentStep/nextStep of totalSteps）、重複進度、緊急程度、確認/解決方式（它為何結束）、靜音與確認逾時截止日期、nextActionAt、觸發監控器/事件。
• UptimeLens:get_escalation_run_timeline — 一個執行的按時間順序事件記錄：通知、傳送結果、確認逾時、跳過的目標、重複、解決——最豐富的「發生了什麼 / 為何升級」來源。
• UptimeLens:list_escalation_policies — on-call 警報規則。
• UptimeLens:get_escalation_policy — 一個政策的詳細資訊：編號 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 — 停止一個主動執行的進一步呼叫。輸入：runId。
• UptimeLens:resolve_escalation — 永久關閉分頁。輸入：runId。不同於確認，已解決的執行絕不會再次分頁，因此請在確認底層問題已修復時使用——而不是作為讓惱人警報停止的方法。
• UptimeLens:bulk_acknowledge_escalation — 一次確認多個主動執行。輸入：runIds（1–50）。部分成功：已解決/未知的執行會被計為跳過，而非錯誤。在 list_escalation_runs(state=active) 之後使用，以一次清除一批。
• UptimeLens:snooze_escalation — 暫停一個執行數分鐘的呼叫。輸入：runId、durationMinutes（1–240）。
• UptimeLens:escalate_escalation — 現在立即呼叫下一個尚未分頁的步驟，而不是等待其計時器（「立即升級」）。輸入：runId。不會跳過任何步驟：nextStep 所顯示的步驟會觸發；在最後一個步驟之後，下一個重複會立即開始，若無剩餘重複，則執行會以已耗盡狀態關閉（nextStep 為 0——告知使用者已無人可呼叫）。執行會回到主動狀態，且其緊急程度會變為 high。測試執行與已完成執行會拒絕此操作。
• UptimeLens:create_on_call_override — 讓一個使用者在某個時間區間內為一個排程值班。輸入：scheduleId、userId、endAt；可選 startAt（預設為現在）、reason。需要 on-call override 功能（請參閱先決條件）。
• UptimeLens:update_on_call_override — 原地編輯現有覆寫：變更其 endAt 或 reason，以及（僅在其開始前）其 userId 或 startAt。輸入：id（來自 create_on_call_override 的結果，或透過 list_on_call_overrides 發現，如果你不是剛剛建立它的話）加上要變更的欄位；省略某個欄位則保持不變。這就是你縮短、延長或重新指派代理人的方式；當交換完全不應發生時，請使用 delete_on_call_override。需要 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 條目）。只有目標使用者或管理員可以拒絕。

核心工作流程：處理 on-call 警報

大多數寫入工具需要一個只有讀取工具才能提供的 ID，因此請始終先進行發現。複製此清單並逐步操作：

On-call 回應：
- [ ] 1. 找出主動的升級執行 (list_escalation_runs, state=active, isTest=false)
- [ ] 2. 選取相關的執行（按 startedAt 排序；檢查 urgency 與 currentStep/totalSteps）
- [ ] 3. 如有用，添加上下文 (incidentId → get_incident; triggeringMonitorId → list_status_changes → get_root_cause)
- [ ] 4. 決定：確認（接手，呼叫停止）或靜音（暫停 N 分鐘，呼叫恢復）
- [ ] 5. 與使用者確認動作，然後使用執行的 id 呼叫寫入工具

**步驟 1 — 找出主動執行。**呼叫 list_escalation_runs，參數為 state="active"。使用 isTest=false 處理真實的、由事件觸發的分頁；isTest=true 是「分頁給自己」的測試執行，不應被視為即時事件。

**步驟 2 — 選取執行。**每個執行都有一個 id（這是寫入工具的 runId）、urgency（high/low）、currentStep of totalSteps（升級已進行到多遠——基於 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（靜音時段不再適用），且已確認的執行會再次變為活躍。當使用者表示目前的應對者無法處理或無人回應時使用；它與靜音相反，因此絕對不要在同一輪中對同一個執行同時呼叫兩者。告知使用者哪一步將會被呼叫（來自 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 之後。
• 刪除覆寫/拒絕代理人請求：指出誰的班次將恢復為常規輪值。取消代理人與建立代理人一樣會改變誰會收到分頁。

這些操作大多是可逆的——覆寫可以被編輯或縮短，確認或靜音可以重新升級——因此目標是一個清晰的人類決策，而不是一個權限壁壘。有兩個是不可逆的：

…

[為翻譯而截斷]