docs-stack-release

ドキュメントリリースのイシュー（elastic/dev の [Docs release] X.Y.Z）が信頼できる情報源です。エンジニアリングの [Release] イシューではありません。ドキュメントのイシューがない場合は作成する（§1.1）か、日付をユーザーに確認してください。イシュー URL がない場合は (issue TBD) とします。

プレイブック： v9 -- v8。 テンプレート： マイナー -- 9.x パッチ -- 8.x パッチ。

ライン	リポジトリ	設定ファイル	デプロイの監視
9.x+	elastic/docs-builder	config/assembler.yml, config/versions.yml	docs-internal-workflows の更新 PR と本番環境のバージョン更新（§0.3）
8.x / 7.x	elastic/docs	shared/versions/stack/*.asciidoc, conf.yaml	なし -- docs-internal-workflows は使用しないでください

不変条件

• ID、日付、PR URL、@メンションは、gh、ドキュメントのイシュー、Slack、またはユーザーから取得してください。決して捏造しないでください。不明な場合は (issue TBD) または [@handle] として、確認してください。
• 8.x と 9.x を1つの PR に混在させないでください。8.x/7.x は elastic/docs のみです。docs-internal-workflows は使用しないでください。
• チェックリストは手順のインデックスです。進行中の作業だけをライブ取得してください。RN のマージはチェック項目ではありません。ブロック中の RN URL は必ず gh pr view で確認してください。
• RN テーブル内の PR URL は、マージされるまでブロック要因です。No changes / N/A の場合のみスキップしてください。Fleet、Agent、その他の製品を名前で例外扱いしないでください。
• このスキルで完了したチェック項目にはチェックを付けてください。他の人（docs-eng を含む）の作業にはチェックを付けないでください。依頼されるまで待たないでください。
• Slack：下書きの作成または送信の前に slack-templates.md を読んでください。送信前に確認し、FF の告知へのフォローアップはスレッドに返信してください。
• 公開中またはリリース済みの Slack 投稿は、ゲート（§0.3）を通過し、ユーザーがサイトを目視確認してからにしてください。ゲート前に下書きを作成しないでください。
• 引数が空、または「リリースの状況は？」の場合：セッション状態 → 有効なドキュメントのイシュー。進行中のリリースがある場合、バージョンを尋ねないでください。クローズ済みイシューの整理後に何も残らなければ、そこで停止してください。再検索しないでください。
• 整理の対象は、CLOSED のドキュメントイシューのみです。404 の場合はその ID を破棄し、再検索してください。TTL はありません。
• RC はリリースごとに異なります。#mission-control の調整スレッドまたはエンジニアリングのイシューから確認してください。名前をハードコードしないでください。
• すでにチェック済みのイシュー項目に関する Slack への通知や PR を提案しないでください。また、ユーザーがすでに送信したと述べている場合も提案しないでください。

---

入力

$ARGUMENTS は、セマンティックバージョンと elastic/dev のイシュー番号をスペース区切りで並べたリストです（例：9.4.0 9.3.4 8.19.15 または #1234 #1235）。空の場合は、セッション状態を読み込みます（§0.1）。有効なリリース（予定日が今日、過去2日以内、または明日で、ドキュメントのイシューが CLOSED ではないもの）があれば、それを使用してください。そうでなければ確認してください。

「リリースの状況は？」／「リリースはどうなっていますか？」（バージョンの指定なし）：引数が空の場合と同じように状況を確認します。セッション状態を読み込み、§0 を実行してください。状態に有効なリリースがある場合、バージョンを尋ねないでください。整理後にバージョンが残っていない場合は、追跡中のイシューがクローズ済みであることを伝えて終了してください。

ユーザーの依頼に関連するセクション（状況、PR、リマインダー）を選んでください。パイプライン全体を実行せず、一部を省略する場合もあります。

---

0. 状況を確認する（呼び出しのたびに実行）

$ARGUMENTS またはセッション状態からバージョンやイシュー番号が分かっている場合、アクションを提案する前に状態を確認してください。

0.1 セッション状態（高速パス）

パス： ~/.elastic-docs/stack-release-state.json。ローカルコーディネーターのキャッシュです。コミットしないでください。

呼び出しのたびに：

1. ファイルを読み込みます。ファイルが存在しない、読み取れない、JSON が無効、該当するバージョンがない、またはユーザーが「start fresh」と指示した場合は、スクラッチから開始します。
2. キャッシュされたID のみで、探索を省略できます：docsIssue、engIssue、coordinatorPrs.{repo:{number,sha,url}}、rnPrs[].{product,url}、slack.{docsChannelId,docsFfThreadTs,missionControlChannelId,coordinationThreadTs,beginPublishingTs,handles}、deploys（9.x のみ：configSha、stagingBumpPr、prodBumpPr、stagingRunId、prodRunId）。さらに line、type、anticipatedDate。
3. ドキュメントの issue で未完了の項目のみ、ライブで更新します（§0.2）。確認済みの行については、gh pr view / gh run view を再実行しないでください。RN PR のマージ状態は必ずライブで更新してください（テーブルには URL が保存され、マージ状態は保存されないためです）。マージ／デプロイに関する判断にはキャッシュされた JSON を決して信用しないでください。ただし、PR または実行の URL がすでに記載された確認済みの issue 行は信用できます。
4. キャッシュされた ID が 404 になる、または見つからないというメッセージが返った場合は、そのフィールドを削除し、その部分だけを再探索します。Buildkite／ボットの親メッセージ（begin publishing、release build declared）に対する slack_read_thread が空でも、404 ではありません。
5. §0 の最後に、CLOSED のドキュメント issue を削除してから、ファイルを書き込むか削除します。

deploys は 9.x のみです。8.x / 7.x では省略してください。

クローズ済み issue のクリーンアップ： state が CLOSED の場合のみ完了です。今回のステータスを報告してから、そのバージョンを releases と active から削除します。OPEN のまま announced であっても十分ではありません。404 は完了を意味しません。docsIssue を削除して再探索します（ステップ 4）。

• 未完了のバージョンが残っている： 残りのエントリーと現在の updatedAt を書き込みます。削除したバージョンを伝えてください。
• 残りがない： ファイルを削除します。{ "active": [], "releases": {} } は書き込まないでください。ローカル状態をクリアしたことを伝えてください。

0.2 ドキュメント issue からステージを判断する（追加の取得より先に実施）

セッション状態の確認後、最初の GitHub 呼び出しは gh issue view です。チェックボックスをすぐに解析し、該当するステージに進んでください。§1～§5を順に確認しないでください。確認済みの行を再検証しないでください。

gh issue view <N> -R elastic/dev --json body,state

issue の状態	ステージ	ライブで取得するもののみ
ドキュメント issue が CLOSED	完了／クリーンアップ	なし。クローズ済みであることを報告してから、クローズ済み issue のクリーンアップ（§0.1）を実施します。
前日通知またはコーディネーター PR のチェックボックスが未チェック	リリース前	コーディネーター PR の検索（キャッシュされた番号がない場合）＋ RN テーブルの URL。#mission-control と §0.3 はスキップします。
コーディネーター PR がチェック済み、マージ RN 通知が未チェック	執筆者への連絡待ち	RN PR の状態＋（リリース当日のみ）キャッシュされた #mission-control のスレッド。
Config-merge／prod-bump（9.x）／elastic/docs PR（8.x）が未チェック	公開インフラ待ち	該当する PR／デプロイ（9.x は §0.3）＋ RN PR の状態＋キャッシュされた #mission-control のスレッド。
prod-bump の行が実行 URL 付きでチェック済み（9.x）、または elastic/docs のマージがチェック済み（8.x）	RN 対応待ち／告知待ち	RN PR のマージ状態のみ。 コーディネーターの gh pr view、bump PR、gh run view はスキップします。
ウェブサイト確認と #mission-control のライブチェックボックスがチェック済み	告知済み	完了を報告します。ユーザーから求められない限り、追加で取得しません。

RN のマージはチェックボックスではありません。 ブロック対象となる RN URL ごとに、必ず gh pr view を実行してください。

確認済みの行に記載された URL が 404 になる場合は、その行のみを再探索します。

関係者の特定（下記§）：行にプレースホルダー、「担当者を指定してください」という脚注、または名前のある人物が 2 人以上含まれている場合にのみ実施します。各行に担当者が 1 人だけ明記されている場合は、#docs の FF スレッド検索をスキップします。

GitHub の状態

セッション状態にドキュメントの Issue 番号がある場合は、gh issue view で直接確認します。それ以外の場合は [Docs release] <version> を検索します。Issue またはセッション状態にコーディネーター PR の URL がすでにある場合、バージョンで gh pr list を実行しないでください。

§0.2 でまだ必要な場合に限り、コーディネーター PR を検索します。そのリリース系列のリポジトリ内のみで検索してください（9.x → docs-builder、8.x → docs）。9.x のみのバッチで elastic/docs に対して gh pr list を実行しないでください。

gh pr list -R elastic/docs-builder --search "<version>" --json number,title,state,url
gh pr list -R elastic/docs --search "<version>" --json number,title,state,url

• Issue のチェックボックス： 項目が未チェックでも、このスキルですでに完了している場合（送信した Slack メッセージ、作成した PR）は、§4 を使って今すぐチェックします。確認を求めないでください。このスキルで実施していない作業の項目はチェックしないでください。
• RN PR のステータス： Release Notes テーブル内のすべての PR URL に対して、1 つのシェルループを実行します。

gh pr view <url> --json state,mergedAt,title

スキップとブロッキング： No changes / N/A の場合に限りスキップします。PR URL はマージされるまでブロッキングです。Fleet、Agent、その他の製品を名前で例外扱いしないでください。名前が記載されたステークホルダーが担当者です。名前が記載された行に ? を追加しないでください。

報告内容：N/A の行を除いて X/Y 件がマージ済み、Z 件が未完了。ブロッキング対象の RN PR がすべてマージされたら、「すべての RN PR がマージされました」と報告します。

続いて、系列ごとに確認します。§0.2 で公開インフラがまだ未完了となっている場合に限ります。

• 9.x： docs-builder のコーディネーター PR がマージ済みで、かつ prod-bump の Issue の行がまだ未チェックの場合は、§0.3 に進みます。その行が実行 URL 付きですでにチェックされている場合は、§0.3 をスキップします。
• 8.x / 7.x： §0.3 をスキップします。設定は elastic/docs にあります。docs-internal-workflows の bump やデプロイはありません。

ステークホルダーの担当を確定する

行でまだ確認が必要な場合に限り実行します（§0.2）。該当するケース：バッククォートで囲まれたプレースホルダー（例：`Beats point person`）または「担当者を指定してください」という脚注がある場合、名前の記載が 2 人以上ありスレッドで 1 人の担当が確認できた場合、名前の記載されたステークホルダーが不在で、別の人が対応すると確認できた場合。

1. FF のアナウンススレッド（#docs でバージョンを指定して slack_search_public を実行し、その後 slack_read_thread を実行します）。
2. 返信を確認します：「[product] を対応できます」「[product] をやります」「X.Y.Z の [product] リリースノートを作成中です」、または明示的な代理対応の申し出。
3. Slack の表示名から GitHub ハンドルを、Issue の付録にある参照テーブルで逆引きします。見つからない場合は slack_search_users を実行し、ユーザーに GitHub ハンドルを尋ねます。
4. Issue の本文を更新します（§4）：プレースホルダーを置き換える、担当者を確認済みの人に絞る、または代理担当者に差し替えます。
5. 次のように報告します：「[Product] のステークホルダーを更新しました：[old] → @new-handle（スレッドで確認済み）。」

確認が取れない場合は変更せず、その旨を報告します。推測しないでください。「手伝えます」のように製品が特定されていない場合は、確認を求めます。

#mission-control（リリース当日のみ）

セッション状態にスレッドのタイムスタンプがある場合は、まずそれらを slack_read_thread で読み込みます。

#mission-control 全体に対して slack_read_channel を実行しないでください。バージョンと今日の日付以降を示す after: の両方を指定せずに "begin publishing" を slack_search_public で検索しないでください。

beginPublishingTs / releaseBuildDeclaredTs のスレッドが空でも、Buildkite ボットの投稿では想定どおりです。親投稿をシグナルとして扱い、再検索しないでください。

必要なキャッシュ済み ts がない場合に限り（単にスレッドが空の場合は除く）、次のようなクエリで検索します：9.5.2 in:#mission-control after:YYYY-MM-DD。上限は 5 件です。

追跡対象のバージョンに一致するシグナル（ステータス報告では各スレッドにリンクを付けます）：

1. 調整スレッド：「Coordination for ... release, scheduled on」――日程、誰が RC か（決して推測しないでください）、返信での日程変更。
2. 「release build declared」：「We are officially declaring X.Y.Z as the release build」。
3. 「begin publishing」：「All pre-finalize steps for X.Y.Z are complete. Please begin the publishing process.」――ドキュメント作業の開始シグナルです。ステップ 1 の RC にあたる人物からの進行／保留の指示を確認します。

0.3 docs-internal-workflows を監視する（9.x のみ）

8.x／7.x ではこのセクションをスキップしてください。 このリポジトリを検索したり、バンプ PR やバージョンバンプの実行を確認したり、8.x の公開メッセージで本番環境のバージョンバンプを必須としたりしないでください。

ドキュメントの issue で「本番環境のバージョンバンプのデプロイを監視する」という行（または同等の項目）がすでにチェックされ、成功した本番環境の実行 URL が記載されている場合は、§0.3 をスキップしてください。バンプ PR を再度列挙したり、実行を再確認したりしないでください。

9.x では、docs-builder コーディネーター PR がマージされ、かつその issue の該当行が未チェックの場合：

コーディネーターが docs-builder の設定 PR をマージし、本番環境のバージョンバンプを監視します。ドキュメントエンジニアリングの対応を待たないでください。コーディネーター PR をマージすると（設定 SHA = マージコミットの短縮 SHA）、次の PR が自動的に作成されます。

• [bump] [staging] docs-builder configuration: <sha>
• [bump] [prod] docs-builder configuration: <sha>

これらをマージすると、Staging / Docs / Deploy / version-bump / ... と Prod / Docs / Deploy / version-bump / ... が開始されます。

確認するのは次の 2 点だけです。

1. バンプ PR がマージ済み -- staging と prod の [bump] ... <sha> が MERGED であること。
2. その SHA の 本番環境の version-bump デプロイが成功していること。staging の version-bump が失敗すると進行がブロックされます。すぐに報告し、本番環境が完了したものとして扱わないでください。

ユーザーから依頼がない限り、無関係なワークフロー（edge、AI enrich、zizmor、dependabot、assembler ingest、link-index）は無視してください。staging が失敗していない限り、本番環境の成功後に staging の成功を待たないでください。

gh pr list -R elastic/docs-internal-workflows --state all \
  --search "[bump] docs-builder configuration: <sha>" \
  --json number,title,state,mergedAt,url
gh run list -R elastic/docs-internal-workflows --limit 20 \
  --json name,conclusion,status,displayTitle,url,databaseId,createdAt

実行は、名前に version-bump が含まれていることと、バンプ PR のマージ後に実行されたことを基準に照合してください。バンプ PR 番号と実行 ID をキャッシュしてください。

本番環境の version-bump が completed/success で、staging が失敗していない場合は、「 の本番環境へのデプロイが成功しました。」とします。

ゲート -- 次の条件がすべて満たされるまで、「ドキュメントが公開されました」／「ドキュメントをリリースしました」というメッセージの下書きを作成しないでください。

行	ゲート
9.x	ブロック要因となるすべての RN PR がマージ済み かつ 本番環境の version-bump が成功済み（staging が失敗していない）
8.x / 7.x	ブロック要因となるすべての RN PR がマージ済み かつ elastic/docs コーディネーター PR がマージ済み

ゲートを満たすまでは、これらのメッセージを下書きせず、「送信の準備はできていますか？」と尋ねず、ウェブサイト確認や #mission-control のチェックボックスにもチェックを入れないでください。

ゲートを満たしたら、ユーザーにウェブサイトを目視で確認してもらい、その後 §6.5 に進んでください。送信前に目視確認が必須です。8.x の「ドキュメントをリリースしました」には、引き続きスクレイプの行も含まれます。

次のアクションを提案する

§0.2 の段階、現在のブロック要因、次に実行する 1 つのアクションを要約してください。チェックボックスがすでにチェック済み、またはユーザーがすでに送信済みの Slack への連絡や PR を提案しないでください。

---

1. 入力情報を集める

• Semver の一覧。
• ドキュメントリリースの issue -- [Docs release] X.Y.Z。エンジニアリングリリースの issue ではありません。gh issue list -R elastic/dev --search "[Docs release] <version>" --json number,title,url
• エンジニアリングリリースの issue -- RC の親 issue（[Release] X.Y.Z、X.Y.Z release など）。正式なスケジュール（FF、GA）が記載され、ドキュメントの issue へのリンクが含まれることも多く、RC を特定できます。ドキュメントの issue がまだないバージョンの日付、GA を共有するバージョン、RC 名の確認に使用します。
• ドキュメントの issue がまだない場合は、§1.1。

1.1 ドキュメントリリースの Issue を作成する（存在しない場合）

1. テンプレート：9.x のマイナーリリース → docs-release.md；9.x のパッチリリース → docs-patch-release.md；8.x → docs-patch-release-8.x.md。
2. 日付は エンジニアリングリリースの Issue（機能凍結、予定される GA）を参照します。情報がない場合は、この 2 項目だけをユーザーに確認します。リリースノートのマージ期限 = 予定される GA の前日（[DAY_BEFORE_RELEASE_DATE]）。マージ期限やコード凍結については尋ねないでください。
3. gh issue create -R elastic/dev --template <template-file> --title "[Docs release] <version>"
4. 概要（バージョン、日付）と、エンジニアリングの Issue に記載されている場合は リリースコーディネーターを記入します。テンプレートの残りの部分はそのままにします。以前のリリースから関係者をコピーしないでください。
5. 報告：「X.Y.Z 用に #NNNN を作成しました。エンジニアリングの Issue #MMMM の日付を記入しました。ご確認ください。」
6. エンジニアリングの Issue から新しいドキュメント Issue が参照されていない場合：gh issue comment <eng-issue> -R elastic/dev --body "Docs tracking: https://github.com/elastic/dev/issues/<new-docs-issue>"

ユーザーから提供されたスケジュールをエンジニアリングの Issue より優先します。

---

2. 各バージョンを分類する

パッチ番号が > 0 の場合はパッチ、V.R.0 の場合はマイナー、V.0.0 の場合はメジャーです（開発 Issue と v8/v9 の手順に従ってください）。その後、§3 に従って振り分けます。

---

3. PR の振り分け（判断）

8.x / 7.x（パッチまたはマイナー）

elastic-stack-v8.md に従います。コーディネーターの PR の対象は elastic/docs のみです（テンプレートに従い、shared/versions*、conf.yaml を変更）。

9.x -- 単独のパッチ（バッチに 9.x が 1 つだけ、または同じ GA の上位マイナーがない場合）

• パッチ： elastic/docs-builder の PR を 1 件作成します。config/versions.yml を更新し、versioning_systems.stack.current をリリースする マイナー系列に合わせます（例：9.3.4 → マイナー 9.3）。versions.yml のチェックリスト行にリンクします。
• タイミングの条件： 同じマイナー系列で GA 前にさらにパッチリリースが予定されている場合、この PR は作成しないでください。現在公開されているバージョンが 1 つを超えるパッチ分だけ遅れている場合（例：現在が 9.3.2 で、リリース対象が 9.3.4）、先に中間のパッチリリースが行われる可能性があります。待つか、ユーザーに確認してください。

9.x -- マイナー（9.x.0）

ドラフト PR を 2 件、別々に作成します（チェックリストの行も 2 つです）。

タイミング	ブランチ／変更	開発 Issue に記載するリンク
FF 後	config/assembler.yml のみ：shared_configuration.stack.next を次の マイナーに変更（例：9.4）	FF 後の行 -- PR またはマージコミット（形式）
GA 前（タイミングについては以下を参照）	assembler.yml：stack.current をそのマイナーに、stack.next を main に変更。versions.yml：versioning_systems.stack.current をそのマイナーに変更。	入れ子になった versions.yml の箇条書き -- 行末に PR URL

versions.yml PR（マイナー）のタイミング： 早い段階では作成しないでください。FF から GA までの間に多くのパッチが入ります。GA 前にパッチがこれ以上予定されていないタイミング（通常は 1～2 日前）で作成します。#mission-control を確認するか、別のパッチが予定されているか尋ねてください。

コーディネーターは、それぞれの docs-builder PR を適切なタイミングでマージします。バージョン更新 PR とデプロイは自動です。FF 後の assembler 手順と GA 前の versions.yml 手順を、1 件の PR で代用しないでください。

同じ暦日の GA：複数の 9.x（例：9.3.4 + 9.4.0）

マイナーになるのは 1 つだけで、残りはパッチです。同じ日に 2 つのマイナーがリリースされることはありません。

1. Assembler PR： マイナーには、FF 後の assembler.yml PR（stack.next の更新）が別途必要です。
2. versions.yml PR： 1 件のみ作成し、バッチ内で最も高いバージョンを対象にします。
3. 正規 Issue = 最も高い 9.x マイナー（versions.yml PR を管理します）。
4. 低い系列の Issue = semver でより低いパッチ：引き続き RN 用として使用します。versions.yml の更新を重複して行わず、§4 に従って正規 Issue に 置き換えます。

---

4. elastic/dev の課題本文を編集する

• 主な作業履歴はコメントではなく説明欄に記載します。
• テンプレートのプレースホルダー、脚注、関係者テーブルは削除しないでください。チェックマーク、リンク、取り消し線、短い相互参照のみ追加してください。
• gh またはユーザーから提供された実際の # / PR URL を使用してください。番号を推測しないでください。
• 作業に沿ってチェックを入れてください。 チェックリスト項目に該当するスキルフローの操作を行ったら、すぐにチェックを入れてください。同じ操作に対するネストされたチェックボックスもまとめてチェックしてください。依頼されるまで待たないでください。項目を未完了として報告しないでください。
• 完了していない項目にはチェックを入れないでください。 他チーム（docs-eng を含む）の手順、このスキル以外でユーザーが完了した作業、リリース当日の将来の項目は未チェックのままにしてください。
• このスキルでコーディネーター PR を開くたびに： 親項目とネストされた項目にチェックを入れ、PR URL を貼り付けてください（マイナーリリースでは、FF 後とバージョン更新の行にそれぞれ異なる URL を記載します）。

テンプレートを決めつけず、チェックリストの文言と照合してください。

スキルの操作	チェックリストの行
未処理の RN／前日の #docs への ping を送信	未開設および／または未承認の ... PR について #docs にリマインドを投稿する
コーディネーター PR を開設	... の PR を開く（ネストされた versions.yml / assembler.yml / conf.yaml の行を含む）
Merge-RN の #docs への ping を送信	... リリースノート PR をマージできるよう #docs に投稿する
コーディネーター PR をマージ	docs-builder 設定 PR をマージする（または 8.x 相当の項目）
Prod のバージョン更新デプロイが成功（9.x のみ）	Prod のバージョン更新デプロイを確認する -- §0.3 の Prod デプロイ成功後にのみチェックする（ステージングで失敗していないこと）。8.x ではこの行を使わないでください。
ユーザーがウェブサイトの確認を完了したことを確認	更新されたドキュメントがウェブサイトに表示されることを確認する -- ゲート（§0.3）通過後、ユーザーがサイトに問題がないと伝えた場合にのみ実施
#mission-control に「docs are live」と返信	ドキュメントが公開されたことを #mission-control に投稿する -- ゲート通過後、かつウェブサイト確認後にのみ実施。Slack への送信前に必ず確認する

gh issue view <N> -R elastic/dev --json body -q .body > /tmp/dev-issue.md
gh issue edit <N> -R elastic/dev --body-file /tmp/dev-issue.md

同一 GA による置き換え（下位ラインの課題）

• 関係者ブロック：superseded by #<canonical>（実際の番号）。
• canonical が担当するチェックリストブロック：~取り消し線~ で囲み、例のようにタグを付けます [not needed: superseded by 9.4.0 -- #<canonical>]。
• 任意のフッター：取り消し線で消された手順は https://github.com/elastic/dev/issues/<canonical> により置き換えられました
• RN のみのコーディネーター手順は、下位ラインの課題で未完了のままにしてかまいません（「このバージョンのリリースノートを確認／公開する」）。canonical のデプロイ作業と重複する行のみ取り消し線を付けます。

誤った課題のパスに対して PR を開いた場合：Superseded by owner/repo#N を記載して閉じます。

---

5. コーディネーター PR を開く（elastic/docs / elastic/docs-builder）

ブランチ：stack-<version>（例：stack-9.5-post-ff、stack-9.5、stack-8.19.16）。docs/ プレフィックスや、名前に pre-ga / "day before" を含めないでください。既存のチェックアウトが利用できる場合はそれを使用し、利用できない場合は一時ディレクトリにクローンします。

gh pr create -R elastic/<repo> --draft --base main --head <branch> \
  --title "<concise title -- no Draft prefix>" \
  --body "## Refs\n\n- https://github.com/elastic/dev/issues/<N>"

適切な期間にのみReadyにします。再びドラフトにする場合：gh pr ready <num> -R elastic/<repo> --undo。

PR が作成されたら、直ちに該当する docs の課題行にチェックを入れ、PR URL を貼り付けます（§4）。

---

6. リマインダーとメッセージ（#docs、Slack）

日付、課題リンク、製品、未処理の PR の状況は、docs の課題（またはユーザーが提供したスケジュール）から転記してください。バージョン、PR の状態、@メンションを決して捏造しないでください。

§0 の時点で本文がコンテキストにない場合は、gh issue view <N> -R elastic/dev --json title,url,body を実行します。バージョンはタイトル／Overview から、予定されている GA / FF / マージ期限は Overview から、関係者と RN PR 列は Release Notes テーブルから読み取ります。§0 に従い、スキップ対象かブロッキング対象かを判断してください。URL がある場合は、マージされるまでブロッキング対象です。

グループ化： 8.x と 9.x ではテーブルの内容が異なることがよくあります。その場合は「Ping for ...」のセクションを分けてください。同じ関係者が複数のバージョンに該当する場合は、製品行の重複をまとめてください。

未解決の関係者と Slack の送信／プレビューについては、slack-templates.md を参照してください。

テンプレート、メンション、送信

テンプレート、ハンドルの検索、OOO の確認については、slack-templates.md をご覧ください。ユーザーがリマインダーの種類を指定しない場合は、次の選択肢を提示してください：機能凍結、未対応の RN、ドキュメント公開、その他。

ドキュメント公開： 1 つのバージョンの場合は単数形のテンプレート（version / are released）を使用します。2 つ以上の場合は複数形（versions / are all released）を使用します。単一バージョンに「versions」や「all」を使わないでください。9.x のみの一括処理では、8.x のスクレイプ行を省略します。

送信（テンプレートファイルを参照しない場合も必ず実施）：

1. 改行を保持できるよう、フェンス付きコードブロック（slack-templates.md）でプレビューを表示します。その後、「送信しますか？」と尋ねます。
2. 確認を待ちます。「送って」や「よさそうです」は確認とみなします。「スレッドを更新して」や「チェックボックスにチェックを入れて」は確認とみなしません。
3. ペイロード内のメンション：人物は <@U…>、ユーザーグループは <!subteam^S…> を使用します。ID を推測しないでください。
4. フォローアップ：FF 告知のスレッド（docsFfThreadTs）に返信し、reply_broadcast: true も設定します。
5. 送信後：該当する docs-issue の項目を確認します（§4）。

6.5 #mission-control スレッドへの返信（リリース日）

ゲート（§0.3）を満たすまで開始しないでください：9.x はブロッキング RN のマージと prod のバージョン更新、8.x はブロッキング RN のマージと elastic/docs コーディネーター PR のマージが必要です。満たしていない場合は未完了の項目を伝えて終了します。ライブ／公開済みメッセージの下書きは作成しないでください。

ゲートを満たしたら、次の手順に従います。

1. ユーザーにウェブサイトを確認してもらいます（9.x：現在のドキュメント／今回のバージョンのリリースノート、8.x：v8 プレイブックのページ）。
2. 確認後、「ドキュメントがウェブサイトに表示される」ボックスをチェックします（§4）。#mission-control への返信（X.Y.Z docs are live.）と、#docs の「docs released」通知を下書きします（8.x バージョンが一括処理に含まれる場合に限り、8.x のスクレイプ行を記載します）。両方を表示し、確認を得てから送信します（slack-templates.md）。
3. 確認を得たら、begin-publishing スレッド（§0 の thread_ts）に返信し、#docs の通知を送信して、#mission-control のボックスをチェックします。

---

7. バックグラウンドポーラー（セッション内）

ユーザーが「PR を監視して」「デプロイを監視して」「すべてマージされたら知らせて」と言った場合：

7.1 リリースノート PR

1. issue テーブルからブロッキング RN PR の URL を取得します（N/A / No changes のみの場合はスキップ）。
2. バックグラウンドシェル（block_until_ms: 0）で 5 分ごとに実行します：gh pr view <url> --json state -q .state。
3. すべてが MERGED になったら、ALL_RN_PRS_MERGED を出力します（notify_on_output）。
4. 「すべての RN PR がマージされました。」と報告し、セッションファイルに記録します。

7.2 docs-internal-workflows のデプロイ（9.x のみ）

8.x / 7.x ではスキップします。

9.x の docs-builder コーディネーター PR がマージされた後（またはユーザーが 9.x のデプロイ監視を依頼した場合）：

1. Config SHA、staging/prod の更新 PR、バージョン更新の run ID を取得します（§0.3）。セッション状態を優先します。
2. 30 秒ごとに gh run view <id> をポーリングします。DEPLOY_STAGING_FAILED（ブロック要因。直ちに警告）、DEPLOY_PROD_FAILED、DEPLOY_PROD_DONE（prod が completed/success で、staging が失敗していない場合）を出力します。
3. DEPLOY_PROD_DONE の場合：「Prod のデプロイが成功しました。」と伝えます。ブロッキング RN PR がまだオープンしている場合は一覧表示し、ライブ／公開済みの Slack メッセージは提案しません。すべてマージ済みの場合は、ユーザーに確認してもらってから §6.5 に進みます。
4. run ID と結論をセッション状態に書き込みます。

ポーラーは現在のセッションでのみ実行されます。次のセッションでは、すべてを再発見するのではなく、§0.1 と §0 を参照してください。

ここに記載されていない内容（API ドキュメント、Buildkite）については、docs issue のチェックリストとプレイブックに従ってください。