oncall-handoff
Write a structured end-of-shift on-call handoff so the incoming engineer inherits state, not surprises. Use when asked to write an on-call handoff, …
它会碰到什么
这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。
技能内容
On-Call Handoff Skill
Produces a compact end-of-shift handoff the incoming on-call can read in under two minutes and act on for the next seven days. The single job: transfer state and attention, not a novel.
Working from a brief
Deliver the full handoff even from a thin brief — infer and label assumptions (never invent incident IDs, timestamps, service names, or dashboard URLs). If the outgoing engineer hasn't listed something, ask once, then move on with "unknown — confirm on takeover" placeholders.
Required Inputs
Ask for (if not already provided), else label as unknown:
- Rotation & window — which rotation, dates and timezone of the shift ending, and dates of the shift starting.
- Open incidents — for each: ticket ID, severity, one-line status, next step, owner.
- Silenced/flapping alerts — alert name, why silenced, when the silence expires.
- In-flight investigations — hypotheses not yet closed out, where the notes live.
- Recent risky changes — deploys, feature flag flips, config rollouts in the last ~72h that might still bite.
- Upcoming risky events — planned deploys, freezes, marketing pushes, load tests.
- Runbook or dashboard drift — anything you touched that the runbook doesn't reflect yet.
Output Format
# On-Call Handoff — <rotation>
**Outgoing:** <name> · **Incoming:** <name> · **Window handed over:** <YYYY-MM-DD HH:MM TZ → YYYY-MM-DD HH:MM TZ>
## TL;DR (read this if nothing else)
- <3–5 bullets: the state of the world, what's smoking, what's calm>
## 🔴 Open incidents
| ID | Sev | Service | Status (one line) | Next step | Owner |
|---|---|---|---|---|---|
| <INC-…> | <S1/S2/S3> | <svc> | <what's happening now> | <what to do next> | <person> |
## 🟡 Watchlist (silenced / flapping / near-threshold)
- **<alert name>** — silenced until <ts>. Reason: <one line>. If it fires after that, do <X>.
## 🔎 In-flight investigations (no incident yet)
- **<Hypothesis in one sentence>** — evidence so far in <link>. Next probe: <one line>.
## 🚀 Recent risky changes (last 72h)
- <deploy / flag / config> — <what shipped, blast radius, rollback command or link>.
## 📅 Upcoming this shift
- <planned deploy / freeze / launch / load test> — <when, who to page if it goes sideways>.
## 🧭 Runbook / dashboard drift
- <thing the runbook still says vs. what's actually true>. Owner to fix: <person>.
## Asks of the incoming on-call
1. <one thing to check within the first hour>
2. <one thing to confirm before end-of-week>
## Contacts
- Escalation: <person / group>. Vendor tickets in play: <list>. Slack channels to lurk: <#…>.
---
_Not an incident report — for full context on any open item, follow the linked ticket._
Quality Checks
- [ ] Every "open incident" row has a next step and an owner — a handoff without those is just a status page.
- [ ] Every silenced/flapping alert has an expiry or a condition for when it should stop being silenced — otherwise it will be silenced forever.
- [ ] Every "recent risky change" has a rollback path (command, PR revert link, or the person who knows how).
- [ ] Timestamps carry a timezone. "Tomorrow morning" is not a timestamp.
- [ ] TL;DR is readable standalone — the incoming on-call should be able to act on it before they finish coffee.
- [ ] No links or IDs are invented. Unknown values are marked "unknown — confirm on takeover", not fabricated.
Anti-Patterns
- [ ] Do not write a chronological journal of the outgoing shift. The incoming engineer doesn't need your Tuesday afternoon; they need the state at 09:00 today.
- [ ] Do not bury the buried lede. A P1 belongs in TL;DR, not on line 47.
- [ ] Do not hand off "everything is fine" without saying what "fine" means — name the top three services you actively looked at and their SLO status.
- [ ] Do not include war stories, praise, or vent. This is a working document, not a retro.
- [ ] Do not close out an investigation with "resolved itself" — either name the fix, or move it to the watchlist with a trigger for re-opening.
- [ ] Do not silently drop items from the previous handoff. If a previous open item is now closed, list it under a one-line "Closed since last handoff:" so the incoming engineer knows you saw it.
Example Trigger Phrases
- "Write an on-call handoff for this week"
- "Draft my SRE handover note"
- "Handoff pager to <name>"
- "End of shift summary"
- "Weekly on-call handover"
想直接用这个技能?
本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。
同名技能的其他版本
有 3 个不同仓库或目录里都有叫 oncall-handoff 的技能。它们内容并不相同,别混用:
- mohitagw15856/pm-claude-skills — Write a structured end-of-shift on-call handoff so the incoming engineer inherits state, n
- mohitagw15856/pm-claude-skills — Write a structured end-of-shift on-call handoff so the incoming engineer inherits state, n