uptimelens/claude-plugins

Guardia de UptimeLens

Opera los flujos de trabajo de guardia y escalamiento de UptimeLens sobre los propios recursos del cliente, a través del servidor MCP de UptimeLens. Este skill convierte una pregunta de alerta ("¿quién está de guardia?", "reconoce esa página", "cubre mi turno") en la secuencia correcta de llamadas a herramientas MCP.

Cuándo usar este skill

Úsalo para el lado operativo de las alertas de incidentes:

• Encontrar quién está actualmente de guardia (o por qué nadie lo está).
• Reconocer o posponer un escalamiento activo que está paginando a alguien.
• Cubrir un turno sobrescribiendo una rotación de guardia durante un período de tiempo.
• Inspeccionar ejecuciones de escalamiento (páginas activas + historial) y políticas de escalamiento.

Para el análisis de causa raíz de un incidente (en lugar de gestionar la página), prefiere el prompt MCP de solo lectura triage_incident, o las herramientas de lectura get_incident, get_root_cause, list_status_changes y query_metrics. Este skill se mantiene en la capa de guardia/escalamiento y se vincula al contexto del incidente solo cuando ayuda a decidir quién debe actuar.

Prerrequisitos

1. El servidor MCP de UptimeLens está conectado a este cliente. Las herramientas de lectura funcionan en todos los planes.
2. Las acciones de escritura (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) requieren un token de API de lectura-escritura y un plan Pro o superior. Con un token de solo lectura, las herramientas de escritura ni siquiera se listan; en el plan Gratuito devuelven FeatureNotAvailable.
3. Algunas de estas tienen una segunda puerta, por característica, además de la puerta del plan, y no son todas iguales:
   • create_on_call_override, update_on_call_override y accept_cover_request necesitan la característica de sobrescritura de guardia. Aceptar cuenta porque produce una sobrescritura activa, justo lo que vende la característica. (Una solicitud pendiente creada en un plan de pago y aceptada después de una degradación crearía una sobrescritura que el plan ya no incluye; esa brecha se cerró deliberadamente).
   • create_cover_request necesita una característica diferente: solicitudes de cobertura de guardia, por lo que un plan puede incluir una y no la otra.
   • delete_on_call_override y decline_cover_request están deliberadamente sin puerta: deshacer algo debe seguir siendo posible después de una degradación; de lo contrario, un intercambio de turno que ya no puedes editar también es uno que no puedes cancelar. Cualquiera de estas puede devolver FeatureNotAvailable incluso con un token de lectura-escritura.

Si una herramienta de escritura falta o devuelve FeatureNotAvailable, informa al usuario qué prerrequisito no se cumple en lugar de reintentar.

Herramientas

Estas herramientas provienen del servidor MCP de UptimeLens. Refiérete a ellas con el nombre completo como UptimeLens:<tool> — reemplaza UptimeLens con el nombre que se le haya dado al conector en este cliente; de lo contrario, es posible que no se encuentre la herramienta.

Lectura (descubrimiento y contexto):

• UptimeLens:list_on_call_schedules — horarios; fuente del scheduleId que necesitan who_is_on_call y create_on_call_override.
• UptimeLens:who_is_on_call — quién está de guardia para un horario en este momento; devuelve gapReason cuando no hay nadie.
• UptimeLens:get_on_call_schedule — el próximo roster para un horario durante los próximos N días (predeterminado 7, máximo 90): cada turno (quién, cuándo, rotación vs sobrescritura), brechas de cobertura con su motivo y un resumen de cobertura. Úsalo para la cobertura futura; who_is_on_call es solo ahora.
• UptimeLens:list_on_call_overrides — las sobrescrituras activas y próximas para un horario; fuente del id que necesitan update_on_call_override y delete_on_call_override. Cada entrada lleva el usuario (quién toma el turno), el solicitante (requestedBy, establecido solo para una solicitud de cobertura pendiente — quién pidió la cobertura), ventana, motivo y estado. Solo una sobrescritura active es editable; una entrada pending es una solicitud de cobertura que aún espera la aceptación del usuario objetivo, y update_on_call_override la rechazará. Las sobrescrituras pasadas no se listan.
• UptimeLens:list_escalation_runs — ejecuciones de escalamiento (páginas activas + historial); fuente del runId que necesitan acknowledge_escalation, snooze_escalation y escalate_escalation. El progreso es basado en 1: currentStep (el paso al que ha llegado el escalamiento), nextStep (se dispara a continuación), totalSteps.
• UptimeLens:get_escalation_run — el estado completo de una ejecución: qué paso ha alcanzado el escalamiento y cuál se dispara a continuación (currentStep/nextStep de totalSteps), progreso de repetición, urgencia, método de reconocimiento/resolución (POR QUÉ terminó), plazos de posposición y tiempo de espera de reconocimiento, nextActionAt, monitor/incidente desencadenante.
• UptimeLens:get_escalation_run_timeline — el registro cronológico de eventos de una ejecución: notificaciones, resultados de entrega, tiempos de espera de reconocimiento, objetivos saltados, repeticiones, resolución — la fuente más rica de "qué sucedió / por qué escaló".
• UptimeLens:list_escalation_policies — las reglas de alerta de guardia.
• UptimeLens:get_escalation_policy — el detalle de una política: pasos ordenados numerados 1..N (los números currentStep/nextStep en list_escalation_runs se refieren a estos), retardo de cada paso, estrategia de objetivos y objetivos. Resuelve los objetivos del horario mediante who_is_on_call, los objetivos de usuario mediante list_team_members.
• UptimeLens:list_team_members — personas en el equipo; fuente del userId que necesita create_on_call_override.

Escritura (cambiar estado — ver "Confirmar antes de escribir"):

• UptimeLens:acknowledge_escalation — detener la paginación adicional para una ejecución activa. Entrada: runId.
• UptimeLens:resolve_escalation — cerrar la página permanentemente. Entrada: runId. A diferencia de reconocer, una ejecución resuelta nunca vuelve a paginar, así que úsala cuando el problema subyacente esté confirmado como solucionado, no como una forma de silenciar una alerta ruidosa.
• UptimeLens:bulk_acknowledge_escalation — reconocer muchas ejecuciones activas a la vez. Entrada: runIds (1–50). Éxito parcial: las ejecuciones ya resueltas/desconocidas se cuentan como saltadas, no como errores. Úsala después de list_escalation_runs(state=active) para limpiar un lote.
• UptimeLens:snooze_escalation — pausar la paginación para una ejecución durante un número de minutos. Entrada: runId, durationMinutes (1–240).
• UptimeLens:escalate_escalation — paginar el siguiente paso aún no paginado ahora en lugar de esperar su temporizador ("escalar ahora"). Entrada: runId. No se salta nada: el paso mostrado como nextStep se dispara; después del último paso, la siguiente repetición comienza inmediatamente, y sin repetición restante, la ejecución se cierra como agotada (nextStep es 0 — informa al usuario de que no queda nadie a quien paginar). La ejecución vuelve a estar activa y su urgencia se vuelve high. Rechazada para ejecuciones de prueba y ejecuciones finalizadas.
• UptimeLens:create_on_call_override — poner a un usuario de guardia para un horario durante una ventana. Entrada: scheduleId, userId, endAt; opcional startAt (predeterminado a ahora), reason. Requiere la característica de sobrescritura de guardia (ver prerrequisitos).
• UptimeLens:update_on_call_override — editar una sobrescritura existente en su lugar: cambiar su endAt o reason, y (solo antes de que comience) su userId o startAt. Entrada: id (del resultado de create_on_call_override, o descubierto mediante list_on_call_overrides cuando no acabas de crearlo) más los campos a cambiar; omite un campo para dejarlo sin cambios. Así es como acortas, extiendes o reasignas una cobertura; usa delete_on_call_override cuando el intercambio no deba ocurrir en absoluto. Requiere la característica de sobrescritura de guardia.
• UptimeLens:delete_on_call_override — eliminar una sobrescritura directamente: el intercambio se cancela y la rotación regular se aplica de nuevo. Entrada: id. Úsala en lugar de editar cuando la cobertura no deba ocurrir en absoluto.
• UptimeLens:create_cover_request — pedir a un compañero que tome una ventana en lugar de asignarla: crea una solicitud pending y envía un correo electrónico al objetivo, quien debe aceptar antes de que se convierta en una sobrescritura activa. Entrada: scheduleId, userId (a quién se le pide), startAt, endAt; opcional reason. Usa create_on_call_override cuando quieras asignar el turno inmediatamente sin preguntar.
• UptimeLens:accept_cover_request — aceptar una solicitud de cobertura pending → se convierte en una sobrescritura activa (el usuario objetivo toma el turno). Entrada: id (una entrada pending de list_on_call_overrides). Solo el usuario objetivo o un administrador pueden aceptar.
• UptimeLens:decline_cover_request — rechazar una solicitud de cobertura pending (no se crea ninguna sobrescritura). Entrada: id (una entrada pending de list_on_call_overrides). Solo el usuario objetivo o un administrador pueden rechazar.

Flujo de trabajo principal: manejar una alerta de guardia

La mayoría de las herramientas de escritura necesitan un ID que solo una herramienta de lectura puede proporcionar, así que siempre descubre primero. Copia esta lista de verificación y trabaja a través de ella:

Respuesta de guardia:
- [ ] 1. Encontrar las ejecuciones de escalamiento activas (list_escalation_runs, state=active, isTest=false)
- [ ] 2. Elegir la ejecución en cuestión (ordenar por startedAt; verificar urgencia y currentStep/totalSteps)
- [ ] 3. Agregar contexto si es útil (incidentId → get_incident; triggeringMonitorId → list_status_changes → get_root_cause)
- [ ] 4. Decidir: reconocer (asumir responsabilidad, la paginación se detiene) o posponer (pausar N minutos, la paginación se reanuda)
- [ ] 5. Confirmar la acción con el usuario, luego llamar a la herramienta de escritura con el id de la ejecución

Paso 1 — encontrar ejecuciones activas. Llama a list_escalation_runs con state="active". Usa isTest=false para páginas reales desencadenadas por incidentes; isTest=true son ejecuciones de prueba de "páginarse a uno mismo" y no deben tratarse como incidentes en vivo.

Paso 2 — elegir la ejecución. Cada ejecución tiene un id (este es el runId para las herramientas de escritura), urgency (high/low), currentStep de totalSteps (qué tan lejos ha subido el escalamiento — basado en 1; más alto significa que se ha paginado a más personas; nextStep es quién será paginado a continuación), y startedAt. Cuando hay varias activas, ordena por startedAt (las más antiguas primero) y muestra la urgencia high primero.

Paso 3 — contexto (opcional). Si la ejecución tiene un incidentId, llama a get_incident para obtener impacto y cronología. Si tiene un triggeringMonitorId, llama a list_status_changes con ese id de monitor para ver sus cambios recientes de arriba/abajo, luego get_root_cause con un statusChangeId de esa lista para diagnósticos de red por sonda. Úsalo solo para ayudar al usuario a decidir; no inicies una investigación completa aquí.

Paso 4 / 5 — actuar. Elige entre reconocer, posponer o escalar (abajo), confirma, luego escribe.

Reconocer, resolver, posponer o escalar

• Reconocer (acknowledge_escalation) significa "ahora me encargo de esto" — la paginación se detiene mientras trabajas. Esta es la respuesta correcta para "tomar", "lo tengo" o "silenciar" una página. Reconocer una ejecución que ya no está activa devuelve un error EscalationRunAlreadyResolved — es inofensivo (ya fue reconocida o resuelta); repórtalo como ya manejado y no reintentes.

• Resolver (resolve_escalation) significa "esto terminó" — la ejecución se cierra permanentemente y nunca vuelve a paginar. Úsalo cuando el usuario diga que el problema subyacente está solucionado, no simplemente que lo está atendiendo. Una ejecución también se resuelve por sí sola cuando su incidente se resuelve, por lo que resolver manualmente es para el caso en que la página sobrevive al problema. Como no se puede deshacer, prefiere reconocer en caso de duda.

• Posponer (snooze_escalation) significa "siléncialo durante durationMinutes, luego vuelve a paginar" — un aplazamiento, no una responsabilidad. No es idempotente: cada llamada restablece la ventana de posposición a ahora + N minutos, por lo que llamarlo de nuevo extiende el silencio. Usa la duración más pequeña que se ajuste (1–240), y nunca pospongas en lugar de reconocer cuando la alerta realmente necesite un responsable.

• Escalar ahora (escalate_escalation) significa "esto necesita más personas, ahora" — el nextStep de la ejecución se pagina inmediatamente en lugar de después de su espera, la urgencia se vuelve high (las horas de silencio ya no se aplican), y una ejecución reconocida vuelve a estar activa. Úsalo cuando el usuario diga que el respondedor actual no puede manejarlo o nadie está respondiendo; es lo opuesto a posponer, así que nunca llames a ambos en la misma ejecución en un solo turno. Informa al usuario qué paso será paginado (nextStep de get_escalation_run).

Reconocer la ejecución incorrecta silencia una página real y nadie es alertado, así que confirma que el runId coincide con la alerta que el usuario quiere.

Brechas de cobertura

who_is_on_call devuelve un gapReason cuando nadie está de guardia:

• schedule_disabled — el horario está desactivado; la política depende de otros objetivos.
• no_active_rotations / no_rotation_members — el horario no tiene a nadie asignado para paginar en este momento.
• outside_active_window — está fuera del horario activo de este horario.

Cuando hay una brecha y alguien necesita tomar la página, create_on_call_override pone a un usuario específico de guardia durante una ventana. Descubre scheduleId mediante list_on_call_schedules y userId mediante list_team_members (los miembros del equipo no exponen correo electrónico ni teléfono — coincide por nombre/rol).

who_is_on_call solo informa la brecha que ocurre ahora. Para encontrar brechas antes de que paginen a alguien, llama a get_on_call_schedule para el horario — su arreglo gaps enumera cada ventana descubierta durante los próximos N días con los mismos motivos, y coveragePercent resume qué tan bien está cubierto el período. Este es el complemento proactivo de who_is_on_call.

Confirmar antes de escribir

Lee y triage libremente. Para las herramientas de escritura, indica lo que estás a punto de hacer y obtén la aprobación del usuario primero — estas cambian a quién se pagina:

• Reconocer / posponer: nombra la ejecución (urgencia, qué la desencadenó) y, para posponer, los minutos.
• Resolver: di claramente que la página se está cerrando de forma permanente y no volverá a paginar. Pregunta si el problema subyacente está realmente solucionado — "haz que se detenga" es una solicitud de reconocer o posponer, no de resolver.
• Sobrescritura: nombra el horario, el usuario y la ventana exacta (startAt–endAt, UTC RFC3339). Si la ventana cruza la medianoche, la fecha de endAt es el día siguiente; endAt debe ser después de startAt.
• Eliminar sobrescritura / rechazar solicitud de cobertura: nombra de quién es el turno que vuelve a la rotación regular. Cancelar una cobertura cambia a quién se pagina tanto como crearla.

La mayoría de estas son reversibles — una sobrescritura se puede editar o acortar, un reconocimiento o posposición se puede re-escalar — por lo que el objetivo es una decisión humana clara, no un muro de permisos. Dos no lo son:

...