/oncall-handoff

name: "On-Call Handoff"
description: >
  Assembling an on-call shift handoff from whatever incident-management tool
  (Rootly, PagerDuty, BetterStack) is connected, plus corroborating
  observability signal where available: the four handoff categories in
  priority order (currently paging, escalated without an owner, last-shift
  history, known-flaky watch list), why an empty open-incidents list is not
  an empty handoff, and the bar for calling an alert known-flaky rather than
  simply resolved.
when_to_use: >-
  When constructing or reviewing an on-call shift handoff — surfacing what's
  currently paging or unresolved, what happened during the last shift, and
  what the incoming responder needs to know before they take the pager. Use
  when: on-call handoff, shift handoff, what's open right now, oncall
  summary, taking over on-call, end of shift, who's on call, handing off the
  pager.

On-Call Handoff

Overview

A shift handoff is a state-transfer problem, not a status update. The outgoing responder holds context that only exists in their head — which alert fired three times and turned out to be noise, which open incident is waiting on a vendor callback, which service has been flaky all week even though nothing paged. A good handoff makes that context explicit and durable so the incoming responder starts the shift at full context instead of rebuilding it from scratch, or worse, missing it entirely.

This skill produces that handoff from whatever incident-management tool is actually connected, plus whatever corroborating alert/monitor state is available, rather than from the outgoing responder's memory alone.

Anti-triggers

• **Reading or editing a schedule, rotation, or escalation policy** — who is

on call and when is the vendor's own surface; use `rootly-oncall`, `pagerduty-oncall`, or `betterstack-oncall`. This skill assembles the state transfer between two shifts, not the roster behind it.

• **An MSP service-desk shift handover** — ticket-board state belongs to

`board-hygiene` in ops-pack; this skill covers the engineering pager.

Discovering available tools first

This pack is cross-vendor. Never assume which incident-management tool is connected, or what its tools are literally named, before checking:

1. Call `conduit__search_tools` with a query like `"on-call handoff"`, `"list incidents"`, or `"current on-call"` to discover which incident-management connector(s) are actually live for this org, and the exact tool names exposed (they follow `<vendor-slug>__<tool_name>`, e.g. `rootly__get_oncall_handoff_summary`, `rootly__list_incidents`, `pagerduty__list_incidents`, `betterstack__list_incidents`). 2. If an observability tool (Sentry, Datadog, Grafana) is also connected, a second discovery pass can surface corroborating signal — e.g., an error rate spike that hasn't yet paged but is worth flagging to the incoming responder as "watch this." 3. Only after discovery, call the concrete tools that came back. If discovery returns no incident-management connector at all, say so plainly — there is no pager state to hand off without one.

Never fall back to guessing a tool name speculatively — an unrecognized tool call is a worse failure mode than asking the user which incident-management tool they use.

Key Concepts

What belongs in a handoff

A complete handoff covers four categories, in priority order:

1. **Currently paging / unresolved** — anything open right now: active incidents, unacknowledged alerts, anything mid-investigation. This is the incoming responder's immediate to-do list, not background reading. 2. **Last-shift history and status** — incidents that fired and resolved during the outgoing shift, with a one-line outcome each. This isn't for action, it's for context — "we've had three DB connection-pool alerts today" changes how the incoming responder reads the fourth one. 3. **Known-flaky alerts to watch** — alerts that fired and were dismissed as noise, or that fire repeatedly without a real underlying issue. These don't belong in "currently paging," but silently dropping them from the handoff means the incoming responder re-diagnoses a known non-issue from scratch, or worse, dismisses a real one because "that alert's always noisy." 4. **Escalated but not yet actioned** — anything that crossed an escalation tier (secondary/manager paged) but doesn't yet have an owner or a next step. This is the highest-risk category to drop silently, because it means someone is already waiting on a response that hasn't happened.

Distinguishing "resolved" from "quiet"

An incident tool showing zero open incidents is not the same as "nothing to hand off." A service that alerted five times and self-recovered each time is quieter on paper than a single ongoing incident, but it's a stronger signal that something needs attention before it becomes a real outage. Don't let an empty open-incidents list stand in for the whole handoff — always check last-shift history even when nothing is currently open.

Known-flaky vs. genuinely resolved

Before labeling an alert "known-flaky," confirm it actually has a pattern — multiple firings with no corroborating incident, ideally across more than one shift. A single alert that fired once and cleared is not yet "known-flaky," it's just resolved; mislabeling it downgrades attention on something that might recur meaningfully. When in doubt, report it under last-shift history rather than the known-flaky category.

Common Workflows

Build a shift handoff

1. Discover the connected incident-management tool via `conduit__search_tools` (see above). 2. Pull current open/unresolved incidents and their status, severity, and assigned responder (if any). 3. Pull incident history for the outgoing shift window (default: since the last handoff, or the last 12–24 hours if no prior handoff timestamp is available — state which window was used). 4.