on-call-handoff-patterns

on-call-handoff-patterns スキルの概要

on-call-handoff-patterns スキルは、特にインシデント対応や調査、リスクの高い変更作業がまだ継続中の状況で、信頼できるオンコールのシフト引き継ぎを作るのに役立ちます。役割は単なるシフトの要約ではなく、次の担当者が重要事項を再発見し直さなくても安全に動けるよう、運用コンテキストを引き渡すことにあります。

このスキルが向いている人

このスキルは、シフト交代をより明確にしたい SRE、Reliability、プラットフォーム、インフラ、インシデント対応チームに最適です。特に、今の引き継ぎが人によってばらつく、情報量は多いのに要点がぼやける、あるいは顧客影響・現在の仮説・次に確認すべきこと・エスカレーション状況といった意思決定に直結する情報が抜けがちな場合に有効です。

このスキルが本当に解決する課題

多くのチームに必要なのは、見栄えの良い引き継ぎメモではありません。必要なのは、「何が壊れているのか」「何が変わったのか」「何をすでに試したのか」「夜間に何がリスクになるのか」「次のエンジニアはまず何をすべきか」を、毎回同じ水準で答えられる再現性のある方法です。on-call-handoff-patterns スキルは、その文脈をシフトの境目をまたいで確実に残したいときに価値を発揮します。

on-call-handoff-patterns が他と違う点

汎用的な「引き継ぎを書いて」というプロンプトと違い、このスキルは、進行中のインシデント、継続中の調査、直近の変更、既知の問題、今後のイベントといった運用引き継ぎの構成要素を前提に設計されています。表現のうまさよりも、重要な情報の抜け漏れが危険になりやすい Reliability 業務により適しています。

向いている利用シーン

次のような場面では on-call-handoff-patterns を使う価値があります。

• 未解決の作業を残したまま通常のオンコールシフトを終えるとき
• ライブインシデントの最中に引き継ぐとき
• バックアップ担当やエスカレーション先のエンジニアに状況共有するとき
• 新しくローテーションに入る人を立ち上げるとき
• 現在の引き継ぎフォーマットがプレッシャー下でも本当に使えるか見直したいとき

インストール前に知っておきたい重要な制約

このスキルはドキュメント中心の構成に見えます。リポジトリ上で確認できるのは SKILL.md のみで、補助スクリプト、テンプレート、参照ファイルは見当たりません。つまり価値の中心は自動化ではなく、引き継ぎパターンそのものにあります。チケット自動生成、Slack 連携、ページングシステム統合まで求める場合は、そのワークフローは別途自分たちで追加する必要があります。

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 スキルは、曖昧に「引き継ぎを書いて」と頼むより、運用上の生の事実を渡したときに最も力を発揮します。入力として有用なのは次のような情報です。

• 現在アクティブなインシデントとその重大度
• 顧客またはシステムへの影響
• シフト中に何が変わったか
• 調査状況と有力な仮説
• すでに試した対応
• 保留中の判断や承認
• 次に予定している確認項目
• エスカレーション状況と連絡済みの相手
• 次のシフト中に予定されているメンテナンス、リリース、または既知の高リスクイベント

これらがない場合でも整ったメモは生成できますが、内容は単なるインシデント要約以下になりやすく、実際には継続性がないのに、あるように見せてしまうリスクがあります。

ざっくりした依頼を強いプロンプトに変える

弱いプロンプト:

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. インシデント文書、アラート、デプロイログ、チャットからメモを集める。
2. 下書き前に、引き継ぎに必要な項目で足りないものをモデルに洗い出させる。
3. on-call-handoff-patterns を使って最初の引き継ぎ文を作る。
4. 文体ではなく、抜け漏れがないかを中心にレビューする。
5. チケット、wiki、Slack など、出力先に合わせて圧縮または展開させる。

この順序が大切なのは、引き継ぎの主な失敗要因が文章の下手さではなく、必要な文脈の欠落だからです。

ライブインシデントの引き継ぎで使う

このスキルは、インシデント対応中に担当が交代し、調査の現状を失わずに新しいエンジニアへ渡したい場面で特に有効です。その場合は、次の情報を明示的に含めるよう依頼してください。

• 現在の指揮系統
• タイムライン上の現在位置
• 検証済み・棄却済みの仮説
• ロールバックまたは緩和策の状況
• 判断の締切
• 再評価なしに変更してはいけない事項

こうすることで、単なるステータス共有よりも、次の担当者がすぐ動ける引き継ぎになります。

シフト終了時の引き継ぎ要約で使う

通常のシフト交代では、次のように分けて整理するよう依頼すると効果的です。

• 今すぐ対応が必要な問題
• 監視継続中の問題
• 後回しにしてよい問題
• 繰り返し発生するノイズや既知の false positive

これにより、次の担当者は未解決の話題をすべて同じ緊急度で扱わずに済み、優先順位を付けやすくなります。

実用的な on-call-handoff-patterns 利用テンプレート

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 に依存しないほうがよいです。このスキルは、構造化された引き継ぎパターンとしては強力ですが、エンドツーエンドのインシデント対応基盤そのものではありません。

シフトサマリーを頼むのと何が違いますか？

シフトサマリーは振り返り寄りで、広くまとめるものでも成立します。一方、引き継ぎは次の行動につながる前向きで運用的な文書である必要があります。次の担当者が即座に状況を把握し、やるべきことを理解する必要があるなら、on-call-handoff-patterns skill のほうが実用的です。

インシデント対応以外でも使えますか？

はい。ただし最も適しているのは、やはり運用継続性が重要な場面です。たとえばサポート当番、インフラ変更、リリース監視、Reliability オペレーションには向いています。一般的な会議メモやプロジェクト更新用途では、相対的に魅力は下がります。

on-call-handoff-patterns スキルを改善する方法

記憶の断片ではなく、根拠になる事実を与える

on-call-handoff-patterns の結果を最も手早く改善する方法は、インシデント文書、アラート、変更履歴から引いた構造化された事実を渡すことです。We had some errors after deploy では弱すぎます。Error rate rose from 1% to 12% after deploy api-2025.03.01, rollback not started, impact isolated to 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、インシデント文書、チケットのどこに入れるのかを明示してください。on-call-handoff-patterns は、対象フォーマット、希望する長さ、受け手が一次対応者・バックアップ・マネージャーのどれかを指定すると、より適切な出力になりやすいです。

文体ではなく、抜け漏れを中心に反復する

最初のドラフトのあとに、単に「もっと短く」「もっとわかりやすく」と頼むだけでは不十分です。代わりに次を確認してください。

• 重要な文脈で欠けているものは何か
• 明示されていない前提は何か
• 暗黙のままで担当が割り当てられていないアクションは何か
• 初見で入る担当者が混乱しそうな点はどこか

こうした観点で反復したほうが、言い回しを磨くよりも引き継ぎ品質の改善につながります。

チーム用の定型プロンプトを on-call-handoff-patterns の上に載せる

チームで頻繁に使うなら、on-call-handoff-patterns を自分たちの必須項目を含む標準プロンプトで包むのがおすすめです。たとえば service owner、dashboards、rollback threshold、escalation chain、business hours constraints などです。スキルは強い土台を提供しますが、環境固有の必須項目を加えることで、運用上の完成度が上がります。

次の担当者の最初の 15 分でレビューする

有効な品質チェックはシンプルです。引き継ぎを読んだ受け手が、最初の 15 分で何を確認すべきか判断できるでしょうか。もしできないなら、現在の状態、リスク、直近のアクションが明確になるまで入力情報を改善してください。