runbook-author

name	runbook-author
description	運用手順書（ランブック）・オンコール対応手順・SOP を作成するスキル。アラート対応・定常運用・緊急時手順を、前提・手順・確認・エスカレーション・ロールバックまで含めて構造化する。「ランブックを作って」「運用手順書を書いて」「オンコール手順を作成して」「対応手順をまとめて」「SOPを作って」「このアラートの対処手順を書いて」などで発動する。
metadata	{"version":"1.0.0","tier":"experimental","category":"document","tags":["runbook","sop","oncall","operations","documentation"]}

runbook-author

「真夜中に叩き起こされた当番が、迷わず動ける」手順書を書く。属人知を、前提・手順・確認・エスカレーションまで含む再現可能なランブックにする。

一般の技術文書は technical-writer。本スキルは運用・オンコールの手順に特化する。

良いランブックの条件

• コピペで実行可能 — コマンドはそのまま貼れる形（プレースホルダは明示）
• 各手順に確認ステップ — 実行後「成功をどう確認するか」を必ず添える
• 可逆性とロールバック — 危険な操作には影響と戻し方を併記する
• エスカレーション経路 — 手に負えない時に誰へ・いつ上げるかが明確
• 判断を減らす — 当番が迷う分岐は、条件を明示して機械的に辿れるようにする

ワークフロー

Step 1: 対象と種別を決める

ランブックの種類を見分ける:

種別	例
アラート対応	「エラー率上昇」「ディスク逼迫」など監視発報への対処
定常運用	デプロイ・バックアップ・証明書更新・バッチ再実行
緊急時	障害時のフェイルオーバー・ロールバック・データ復旧

Step 2: 情報を集める

1. トリガー（何が起きたらこの手順を使うか）
2. 前提（必要な権限・アクセス・ツール）
3. 実際の手順（コマンド・画面操作・判断基準）
4. 関連情報（ダッシュボード・ログの場所・連絡先）

不明点は推測で埋めず「要確認」とする。

Step 3: 構造化して書く

references/template.md のテンプレートで:

• 手順は番号付きの命令形（「〜する」）。1ステップ1動作
• 各ステップに 確認 を付ける（「成功なら X が表示される」）
• 分岐は もし X なら → 手順N と明示
• 危険操作には ⚠️ と影響・ロールバックを併記

Step 4: 連携・配置

• アラート対応ランブックは observability-designer のアラートに、緊急時手順は incident-responder の止血手段にリンクさせる
• 配置先（wiki-use / obsidian-use / リポジトリ docs）への保存を提案する

ガードレール

制限	内容
推測禁止	不確かな手順・コマンドを断定で書かない。未確認は「要確認」と明記
危険操作の警告	破壊的コマンド（削除・本番変更）には ⚠️・影響・ロールバックを必ず添える
秘匿情報	手順書に資格情報・トークンを直書きしない。シークレット参照の方法を示す
確認の併設	実行ステップには必ず成否確認を付け、「やりっぱなし」の手順を作らない