DevOps & Reliability

Run the reliability scorecard for one service, or every connected service if omitted - error-budget burn rate where an SLO is defined, trend reporting otherwise

Generate the current on-call handoff brief - what's paging, what's escalated without an owner, last-shift history, and known-flaky alerts to watch

Draft a blameless postmortem for a given incident (by ID or name), or the most recent significant incident within a time window

Use this agent when an on-call engineer needs a structured shift handoff brief — what's currently paging or unresolved, what happened during the last shift, known-flaky alerts to watch, and anything escalated but not yet actioned — assembled from whatever incident-management tool is connected. Trigger for: on-call handoff, shift handoff, what's open right now, oncall summary, taking over on-call, handing off the pager. Examples: "Build my on-call handoff before I go off shift", "What's currently open that I need to know about taking over the pager", "Give me the shift summary for the last 12 hours"

Use this agent when an engineer, SRE, or incident manager needs a full blameless postmortem drafted from a resolved incident — identified by ID or by a rough time window — reconstructed from the incident tool's event log plus correlated observability and deploy data. Trigger for: incident postmortem, write a postmortem, incident retro, incident retrospective, what happened during the outage, post-incident review, blameless postmortem. Examples: "Write the postmortem for the outage we resolved this morning", "Draft a postmortem for INC-482", "What happened during last night's incident — give me the full retro", "I need a blameless postmortem for the database outage from yesterday afternoon"

Use this agent when a team lead, SRE, or engineering manager needs a ranked reliability status across connected services — error-budget burn rate where a formal SLO exists, degrading to raw error-rate/uptime trend reporting where it doesn't — worst service first. Trigger for: reliability scorecard, error budget status, uptime review, are we meeting our SLOs, service health ranking, burn rate report. Examples: "Give me a reliability scorecard across everything we've got connected", "Are we meeting our SLOs this month?", "Which service is burning its error budget fastest?", "Uptime review for the platform services"

Use this skill when computing or reporting error-budget status across whatever observability tools are connected through the gateway. Covers SLO/error-budget concepts applied practically — how to compute current burn rate from available observability data (Sentry error rate, Datadog/Grafana uptime or latency SLIs, BetterStack uptime checks), what counts as a budget-threatening trend versus noise, and how to degrade gracefully when no formal SLO is defined (fall back to raw error-rate/uptime trend reporting instead of a burn-rate calculation). Discover connected tools via conduit__search_tools before assuming a specific vendor; never hardcode a tool surface.

Use this skill when assembling a blameless postmortem from an incident across whatever incident-management and observability tools are connected through the gateway. Covers timeline reconstruction from the incident tool's event log plus correlated observability data (Sentry error spikes, Datadog/Grafana metric anomalies, GitHub deploy history around the incident window), a root-cause hypothesis structure, and the difference between contributing factors and root cause. Discover connected tools via conduit__search_tools before assuming a specific vendor; never hardcode a tool surface.

Use this skill when assembling a proper on-call handoff across whatever incident-management tool (Rootly, PagerDuty, BetterStack) is connected through the gateway. Covers what belongs in a handoff — currently paging or unresolved incidents, last-shift incident history and status, known-flaky alerts worth flagging, and anything escalated but not yet actioned — and, critically, how to use conduit__search_tools to discover which incident-management tool is actually connected before assuming a specific vendor's tool names. Do not hardcode a vendor's tool surface; discover it first.