跳到主要内容
知仓学习社ZHICANG

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, …

不碰外部(只输出文字)无严重或高危命中mohitagw15856/pm-claude-skills

它会碰到什么

扫了多少1 个文本文件,5 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

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 的技能。它们内容并不相同,别混用: