on-call-handoff-patterns

on-call-handoff-patterns 技能概览

on-call-handoff-patterns 技能用于帮助团队产出更可靠的 on-call 交接，尤其适合仍有事故、调查和高风险变更在持续推进时使用。它的目标不只是总结一班发生了什么，而是把运行上下文完整交给下一位响应者，让对方无需重新摸索关键信息，也能安全接手并继续推进。

这个技能适合谁

这个技能最适合 SRE、Reliability、平台、基础设施和事件响应团队，尤其适用于需要把值班交接做得更清晰、更稳定的场景。如果你们现在的交接内容前后不一致、信息太碎太啰嗦，或者经常漏掉影响决策的关键上下文，比如客户影响、当前假设、下一步检查项和升级状态，那么它会很有帮助。

它真正解决的是什么问题

大多数团队并不缺一份“写得更漂亮”的交接说明，真正需要的是一种可重复的方法，能稳定回答这些问题：哪里坏了、改过什么、已经试过什么、夜里还存在哪些风险、下一位工程师第一步该做什么。on-call-handoff-patterns 技能的价值，就在于让这些关键上下文在交班时不丢失。

on-call-handoff-patterns 有什么不同

和泛泛一句“帮我写个交接”相比，这个技能是围绕运维交接中的核心组件来组织的，例如活跃事故、持续中的调查、近期变更、已知问题和即将发生的事件。对于 Reliability 工作来说，这种结构化方式更合适，因为在这类场景里，漏信息往往比措辞不佳更危险。

最适合使用 on-call-handoff-patterns 的场景

在以下情况下，适合使用 on-call-handoff-patterns：

• 正常 on-call 班次结束，但还有未完成工作
• 在 live incident 处理中途交接
• 向 backup 或 escalation engineer 做情况交代
• 帮新人进入值班轮转
• 评估你们当前的交接格式在高压情况下是否真的可用

安装前需要先了解的限制

这个技能看起来是典型的 documentation-first 设计：从仓库可见内容来看，只有 SKILL.md，没有 helper scripts、templates 或 reference files。这意味着它的价值主要来自交接模式本身，而不是自动化能力。如果你希望它顺带生成工单、同步到 Slack，或接入 paging system，这些流程需要你自己补上。

如何使用 on-call-handoff-patterns 技能

on-call-handoff-patterns 的安装背景

由于仓库路径是 plugins/incident-response/skills/on-call-handoff-patterns，你需要通过主技能仓库，按自己常用的 Skills 工作流来安装。常见命令如下：

npx skills add https://github.com/wshobson/agents --skill on-call-handoff-patterns

如果你的环境使用的是其他安装器或本地 checkout 流程，关键点在于：这个技能本体位于 wshobson/agents 仓库的 incident response 插件集合下。

先读这个文件

从这里开始：

• plugins/incident-response/skills/on-call-handoff-patterns/SKILL.md

这个技能没有可见的配套支持文件，因此阅读 SKILL.md 不是可选项。这个文件本身就是实现内容。

on-call-handoff-patterns 需要什么输入

当你提供原始运维事实，而不是一句模糊的“写个交接”时，on-call-handoff-patterns 技能效果最好。比较有用的输入包括：

• 当前活跃事故及其严重级别
• 对客户或系统的影响
• 本班期间发生了哪些变更
• 调查进展和当前最主要的假设
• 已经尝试过的操作
• 还未决策或待批准的事项
• 下一步计划检查什么
• 当前升级状态，以及已经联系过哪些人
• 下一班期间会遇到的维护窗口、发布活动或已知高风险事件

如果没有这些输入，模型依然能生成一份格式完整的交接说明，但质量会比通用 incident summary 还要弱，而且可能会“脑补”并不存在的连续性。

把模糊需求改写成高质量提示词

弱提示词：

Write an on-call handoff for my shift.

更强的提示词：

Use the on-call-handoff-patterns skill to produce an on-call handoff for the incoming Reliability engineer. Include active incidents, ongoing investigations, recent changes, known issues, and upcoming events. Highlight customer impact, what has already been tried, what still looks risky, who has been paged, and the first 3 actions the next engineer should take. Ask follow-up questions if any critical handoff fields are missing.

更强的版本效果更好，因为它同时给了这个技能明确的结构和决策标准。

实际工作中最推荐的使用流程

一个实用的使用流程如下：

1. 从 incident docs、alerts、deploy logs 和聊天记录中收集笔记。
2. 先让模型识别哪些交接字段缺失，再开始起草。
3. 使用 on-call-handoff-patterns 生成第一版交接。
4. 审核时重点看有没有遗漏，而不是语气好不好。
5. 再根据投放渠道，让模型压缩或展开内容，比如用于 ticket、wiki 或 Slack。

这个顺序很重要，因为交接的主要失败点通常不是“写得不好”，而是“关键信息没写进去”。

在 live incident 交接中使用它

这个技能在事故处理中途交接时尤其有用：此时新的工程师需要在不丢失当前调查状态的前提下接手。在这种情况下，建议明确要求输出以下内容：

• 当前指挥结构
• 时间线检查点
• 已验证和已排除的假设
• rollback 或缓解措施的状态
• 决策截止时间
• 哪些内容在重新评估前不能随意改动

这样得到的交接会比普通的状态回顾更可执行。

用于班次结束时的总结交接

对于常规班次交接，可以要求技能明确区分：

• 现在就需要处理的问题
• 需要持续观察的问题
• 可以安全延后的问题
• 重复噪音或已知误报

这样能帮助下一位工程师快速排序优先级，而不是把所有未关闭事项都当成同等紧急。

实用提示词模板

你可以把下面这个模板用于 on-call-handoff-patterns usage：

Use on-call-handoff-patterns to draft a handoff for the next on-call engineer.
Context:

• Shift window: [time range]
• Active incidents: [list]
• Ongoing investigations: [list]
• Recent changes: [deploys/config/infra changes]
• Known issues/workarounds: [list]
• Upcoming events: [releases, maintenance, traffic spikes]
• Escalations: [who was contacted and status]
• Recommended first actions next shift: [list]
  If information is missing, identify the gaps first, then draft the handoff.

如何判断输出质量是否达标

一份由 on-call-handoff-patterns 生成的好交接，应该能让下一位工程师迅速回答这些问题：

• 当前最紧急的问题是什么
• 最近改过什么
• 已经试过哪些操作
• 现在不确定的点还在哪里
• 接手后第一步该做什么

如果输出无法快速回答这些问题，就应该补充更多运维细节后重新生成。

什么时候它比普通提示词更值得用

当你需要跨班次、跨工程师保持交接一致性时，应该优先用这个技能，而不是普通提示词。对于 Reliability 团队来说，这种内置的交接框架很有价值，因为它能降低人在疲劳或时间压力下漏掉关键类别信息的风险。

on-call-handoff-patterns 技能 FAQ

on-call-handoff-patterns 适合 Reliability 团队吗？

适合。on-call-handoff-patterns for Reliability 是很强的匹配，因为 Reliability 工作的核心在于把状态跨工程师保留下来，而不只是生成一段文字。这个技能的价值，在于让交接在运维层面尽可能完整。

这个技能对新手友好吗？

友好，但有一个前提：新手依然需要掌握源事实。这个技能可以很好地组织交接内容，但它不能代替你判断严重级别、影响范围，或者判断某项调查是否真的已经结束。

on-call-handoff-patterns 会安装自动化能力吗？

不会。从仓库可见内容来看，这个技能本身没有包含自动化。更准确地说，它是一个以方法和引导为主的技能，而不是带脚本集成的自动化包。

什么情况下不该使用 on-call-handoff-patterns？

如果你需要强依赖具体环境的 runbook 逻辑、pager 集成，或者严格的合规格式要求，而你又没有自行补充这些上下文，就不要单独依赖 on-call-handoff-patterns。它最强的定位是结构化交接模式，而不是端到端的 incident platform。

它和“写个班次总结”有什么区别？

班次总结可以偏回顾、偏宽泛；而交接必须是面向下一步行动、面向运维执行的。当前提是下一位工程师需要立刻建立态势感知，并且明确知道接下来该做什么时，on-call-handoff-patterns skill 会比普通总结更有用。

可以在事件响应之外使用吗？

可以，但最合适的仍然是强调运行连续性的场景，比如 support 轮班、基础设施变更、发布观察和值班可靠性运营。对于一般会议纪要或项目更新，这个技能的优势就没那么明显。

如何改进 on-call-handoff-patterns 技能的使用效果

提供证据，不要只给零碎记忆

提升 on-call-handoff-patterns 结果质量最快的方法，就是提供来自 incident docs、alerts 和变更历史的结构化事实。比如，“我们在 deploy 之后出了一些错误”就很弱；而“deploy api-2025.03.01 后错误率从 1% 升到 12%，尚未开始 rollback，影响范围仅限 EU tenants”就非常有用。

先让模型找出缺失的交接字段

在起草前，先这样提示：

Using on-call-handoff-patterns, list missing handoff information that would block a safe transition.

很多时候，这比要求它“写得更漂亮”更能提升最终输出质量。

把事实、假设和下一步拆开写

一个常见失败模式，是把已确认事实和推测混在一起。可以要求技能明确标注：

• confirmed observations
• working hypotheses
• actions already taken
• recommended next actions

这样会让交接更安全，也更容易让接手工程师信任内容。

明确优先级

如果有多个问题同时在处理中，要明确要求技能按紧急程度或影响大小排序。否则输出看起来可能很完整，但最关键的运维风险却被埋在正文中间。

补充目标投放渠道的约束

如果交接要发到 Slack、incident doc 或 ticket，就直接说明。指定目标格式、期望长度，以及接收对象是 primary responder、backup 还是 manager，on-call-handoff-patterns 才能生成更贴合场景的输出。

迭代时盯遗漏，不要只改文风

第一版出来后，不要只要求“更短一点”或“更清晰一点”。更有效的追问是：

• 缺了哪些关键上下文
• 哪些假设没有说清楚
• 哪些动作只是暗示了，但没有明确分配
• 哪些地方会让一个冷启动接手的人看不明白

这种迭代方式，比单纯润色措辞更能提升交接质量。

围绕技能建立团队可复用的标准提示词

如果团队会高频使用它，可以基于 on-call-handoff-patterns 封装一套标准提示词，加入你们自己的必填字段，比如 service owner、dashboards、rollback threshold、escalation chain 和 business hours constraints。这个技能给你的是一个强结构模式，而你们环境专属的字段，才决定它是否真正达到运维可用。

用“下一位工程师的前 15 分钟”来做质检

一个很好用的质量检验标准很简单：接手工程师读完交接后，能不能立刻知道前 15 分钟该检查什么？如果不能，就继续改进输入，直到交接能够清晰说明当前状态、风险点和马上要做的动作。