---
name: oncall-handoff-writer
description: Turn a sprawling on-call shift's activity into a clean handoff note for the next engineer — ongoing issues, watch-items, recent changes, unresolved tickets, and "if this alert fires, do X".
version: 1.0.0
author: VantagePoint Networks
author_url: https://www.vpnetworks.co.uk
audience: On-call Engineers, SREs, NOC staff, IT Operations teams, MSP engineers
audience: On-call Engineers, Service Desk Managers, SREs, MSPs
output_format: Formatted Markdown handoff note with ongoing issues, watch-items, recent changes, open tickets, and alert-response shortcuts.
license: MIT
last-reviewed: 2026-04
---

# On-Call Handoff Writer

A Claude Code skill to turn a messy on-call shift's activity into the handoff note the next engineer actually needs — so nothing falls through the gaps between shifts.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/oncall-handoff-writer`. Paste your raw notes, ticket IDs, and anything from your shift. Answer a few clarifying questions. Receive a structured handoff note.

## When to use this

- You're coming off shift and want to hand over cleanly without writing from scratch at 7am.
- Your team has grown past the point where "I'll DM you" handoffs work, and you need a standard format.
- You want a searchable handoff archive so patterns become visible.
- A weekend shift ending Monday morning with a lot of activity needs a clear handover pack for the whole team.
- An incident is ongoing at shift change and you need a sharp handover script.

## What you'll get

A single Markdown document containing:

- **Shift header** (who, when, scope)
- **Ongoing issues** (anything still in flight)
- **Watch items** (things that are fine now but could escalate)
- **Recent changes** (what's new in the environment that might cause alerts)
- **Open tickets** (with state + next action)
- **Alert-response shortcuts** ("if X alerts, do Y first")
- **Unresolved questions** for the next engineer to pick up
- **Key contacts on the bridge or standby**
- **"What I would do next if I were staying"** — one line

## Clarifying questions I will ask you

1. **Shift length and timezone?**
2. **What's still going on that isn't resolved?**
3. **Any incidents declared during shift?** (P1/P2/Major — even if now closed)
4. **Any changes went in during your shift or the 24 hours before?**
5. **Any tickets you escalated or are waiting on someone for?**
6. **Any alerts you silenced or tuned that the next engineer should know about?**
7. **Any customer or stakeholder comms sent that need follow-up?**
8. **Any one-line "if X happens, do Y" things you learned this shift?**
9. **Who was on the bridge / on call with you?**
10. **How busy was the shift?** (calm / steady / busy / fire-fighting — tone-setter for the next engineer)

## Output template

```markdown
# On-Call Handoff — <date, shift end time>

**Outgoing:** <name/role> · **Incoming:** <name/role>
**Shift length:** <start — end> · **Overall feel:** calm / steady / busy / fire-fighting

## 1. Ongoing (hand these over cleanly)
| # | Issue | Status | Owner now | Next action | By when |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |

## 2. Watch Items (not broken, but watching)
| # | What | Why | Thresholds | If X happens, do Y |
|---|---|---|---|---|
| 1 | | | | |
| 2 | | | | |

## 3. Recent Changes (last 24-48h)
| Time | Change | System | Owner | Expected effect / risk |
|---|---|---|---|---|
| | | | | |

## 4. Open Tickets I Touched
| Ticket | Title | State | Next action | Notes |
|---|---|---|---|---|
| | | | | |

## 5. Alerts & Tuning Done This Shift
| Alert | Action taken | Why | Reversal trigger |
|---|---|---|---|
| <rule> | Silenced until <time> | <reason> | <if this condition, unmute> |

## 6. Customer / Stakeholder Comms
| Recipient | Channel | Summary | Follow-up needed |
|---|---|---|---|
| | | | |

## 7. Unresolved Questions
- <question / unknown>
- <question / unknown>

## 8. Key Contacts Right Now
| Role | Name | Reachable via |
|---|---|---|
| Bridge / escalation | | |
| Vendor TAM on case | | |
| Customer contact | | |

## 9. What I Would Do First
If I were staying on, my first action would be: <one line>.

## 10. Shift Stats
- Alerts received: <N>
- Incidents declared: <N>
- Tickets touched: <N>
- Changes implemented: <N>
```

## Example invocation

**User:** "Night shift 22:00-06:00. Quiet until 03:15 when a BGP session dropped between our PoP and the upstream provider. Session recovered in 8 minutes but flapped again at 04:30. Upstream is looking at it, case open. Also silenced noisy disk-space alert on a legacy server — capacity remediation is in next week's change. Two tickets escalated to vendor. Raised DR test question with the weekend team via email."

**What the skill will do:**
1. Ask the 10 clarifying questions briefly, pressing on whether the BGP flap was customer-impacting and what the unmute trigger should be for the disk-space alert.
2. Produce a clean handoff note that:
   - Flags the BGP issue as an Ongoing item ("upstream case #XXX open; watch for flaps; if third flap, escalate to <carrier support line>")
   - Lists the silenced disk-space alert under Alerts & Tuning with an unmute trigger of "change complete or disk > 95%"
   - Captures the DR test email as an unresolved question
   - Tags the shift as "quiet → BGP excitement → steady" for tone
3. Produce a one-line "what I'd do first" — "Check the carrier case for overnight updates and the BGP session stability charts from 03:00 onwards."

## Notes for the requester

- **Write for the incoming engineer, not for HR.** Specific, direct, time-saving. No narrative prose.
- **State-changing events first, watch-items second, context last.** The first three bullets are the ones that must not be missed.
- **"If X happens, do Y" is the single most valuable pattern.** It turns tacit knowledge into transferable instructions.
- **Shift tone-setting matters.** "Busy" signals the incoming engineer to brace; "calm" signals they can work through a backlog.
- **Archive every handoff.** After a few months, you'll spot patterns — recurring alerts, vendor issues, monthly end-of-cycle spikes — that drive permanent fixes.
- **Good looks like:** the incoming engineer reads the handoff in 3 minutes, knows exactly what's still in flight, and has zero "wait, what was that thing from overnight?" moments.

---
*VantagePoint Networks · <https://www.vpnetworks.co.uk> · Authored by Hak · Free under the MIT licence*