runbook - SKILL.md Agent Skill

name: runbook description: 開発タスク（本番デプロイ・DB移行・インシデント対応など）の名前を渡すと、航空SOP方式の読み上げ式チェックリストをMarkdownで生成する。実行フェーズの品質を保証したいときに使う。デプロイ・移行・インシデント対応などの前にチェックリストが欲しいときに自動呼び出しされるべきスキル。

/runbook

使い方

/runbook <タスク名> — 指定タスクのチェックリストを生成
/runbook — 引数なしの場合はタスク名を自由入力で確認する

手順

ステップ1: タスクの特定

PROHIBITED: AskUserQuestion ツール（選択肢UI）は使わない。すべての質問はプレーンテキストで出力する。

IF 引数でタスク名が指定されていない:
  OUTPUT（プレーンテキスト）:
    「何をしたいですか？どんな作業でも自由に教えてください。」
  WAIT_FOR: ユーザーの回答
  {task} = ユーザーの回答（複数作業・複合的な内容でもそのまま受け取る）

ELSE（引数でタスク名が指定されている場合）:
  {task} = 引数として指定された値
ENDIF

ステップ1.5: ソースコードの調査

カレントディレクトリのソースを調査して {context} を組み立てる。

調査手順:
  1. ls / find で構成を把握する
  2. {task} に関係しそうなファイルを読む
     - package.json / go.mod / requirements.txt / Gemfile → 言語・FW・依存
     - docker-compose.yml / Dockerfile / infra/ → インフラ・DB種別
     - .env.example / config/ / database.yml → 接続先・環境設定
     - migration/ / schema/ → 現在のDB構造
     - README / docs/ → 既知の注意事項
  3. 調査結果を {context} にまとめる:
       - 技術スタック（言語・FW・インフラ）
       - 現在のDB種別・接続方式
       - 移行対象のデータ規模（テーブル数・推定行数など、分かれば）
       - その他 {task} に関係する情報

ソースが存在しない・{task} に無関係なら {context} = "" のままでよい。

調査後、コードから読み取れた内容を1〜3行で要約してユーザーに提示する。
その上で、コードから判断できなかった点のみをピンポイントで質問する。
  例: 「package.json を確認しました。Next.js + Prisma 構成ですね。
       移行先の PostgreSQL はどの環境ですか？（本番 / ステージング）」
  例: 「docker-compose.yml に MySQL の記述がありました。
       本番環境のデータ量はどのくらいですか？」
質問がなければそのままステップ2へ進む。

ステップ2: チェックリストの生成

CLASSIFY リスクレベル（{task} と {context}、ソース調査結果から判定）:
  HIGH   → 本番DB操作・本番デプロイ・大規模インフラ変更（判断に迷う場合はHIGHとして扱う）
  MEDIUM → ステージング操作・依存パッケージ更新・設定変更・機能フラグ操作
  LOW    → 開発環境作業・ドキュメント更新・ローカルテスト

リスクレベルに応じた追加ルール:
  HIGH   → ロールバック手順を必須とし、不可逆操作の直前に
           「[ ] 確認: 以下の操作は不可逆です。続行する」を挿入する
  MEDIUM → ロールバック手順を含める
  LOW    → ロールバック手順は任意

生成フォーマット:
  # {task} チェックリスト — YYYY-MM-DD
  （YYYY-MM-DD はステップ3でBash実行後に実際の日付で置換すること）

  リスクレベル: <HIGH / MEDIUM / LOW のいずれか>

  ## 事前確認
  実行前に必ず確認する。条件が揃っていない場合は実行を中止する。
  - [ ] ...

  ## 実行手順
  順番通りに実行する。各ステップ完了後にチェックを入れてから次へ進む。
  - [ ] ...

  ## 完了確認
  すべてパスしてから完了とする。1つでも失敗した場合はロールバックを検討する。
  - [ ] ...

  ## ロールバック手順
  （HIGH / MEDIUM の場合のみ必須。問題発生時はここから逆順で復旧する）
  - [ ] ...

IMPORTANT: 各チェックポイントは「何をするか」ではなく「何を確認したか」を問う形式にすること。
  NG: 「DBバックアップを取る」
  OK: 「DBバックアップを取得し、ファイルサイズが0でないことを確認した」
  生成指針: DO-CONFIRM方式（「〜した」という過去形で確認）・不可逆操作前は承認ゲートを挿入・ロールバック境界を明示すること

ステップ3: 出力とファイル保存

チェックリストを会話上に出力する。

「ファイルに保存しますか？（保存先パスを教えてください / 「しない」でスキップ）」と聞く。
WAIT_FOR: ユーザーの回答
PROHIBITED: 「しない」「スキップ」「no」「n」「要らない」等の拒否回答の場合にファイルを保存すること

IF 「しない」「スキップ」「no」「n」「要らない」: STOP

ELSE:
  1. Bash で `date +%Y%m%d` を実行して日付を取得する
  2. チェックリスト内の YYYY-MM-DD を取得した日付（YYYY-MM-DD形式）で置換する
  3. ファイル名: runbook-{YYYYMMDD}.md
     同名ファイルが既に存在する場合は `date +%Y%m%d%H%M%S` で秒まで含めた名前にする
     例: runbook-20260603.md、重複時 → runbook-20260603143022.md
  4. 指定パスが存在しない場合は Bash で mkdir -p <path> を実行してから保存する
  5. Write ツールで保存する
     失敗した場合: 「保存に失敗しました。パスの権限を確認してください: <path>」と報告してSTOP
  6. 「`{保存フルパス}` に保存しました」と一言伝える
ENDIF

ステップ4: コード変更が必要な場合のissue提案

チェックリストの実行手順にソースコードの変更（依存パッケージ変更・設定ファイル修正・
スキーマ変更・コード書き換えなど）が含まれる場合:

  OUTPUT（プレーンテキスト）:
    「このタスクにはコード変更が含まれています。
    GitHubにissueを作成しますか？作成すると /issue-triage でPRまで進められます。」
  WAIT_FOR: ユーザーの回答

  IF 「はい」「作る」「yes」「y」等の肯定回答:
    gh issue create コマンドで以下の内容のissueを作成する:
      title: {task}
      body:
        ## 概要
        {task} を実施する。

        ## 背景
        {ソース調査・ユーザー回答から得たコンテキストを簡潔に記載}

        ## やること
        チェックリストの実行手順のうち、コード変更が必要な項目を箇条書きで列挙する

        ## 参考
        runbook: {保存した場合はチェックリストのファイルパスを記載。保存しなかった場合は省略}
    作成したissueのURLを伝える。
    「/issue-triage <issue番号> で対応できます」と案内する。

  ELSE: STOP
ENDIF