Back to Details

docs-stack-release

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Docs release issue (
[Docs release] X.Y.Z
in 
elastic/dev
) is the source of truth -- not the eng 
[Release]
issue. Create missing docs issues (§1.1) or collect dates from the user. Missing issue URLs: 
(issue TBD)
.
Playbooks: v9 -- v8. Templates: minor -- 9.x patch -- 8.x patch.
LineRepoConfig filesDeploy watch
9.x+
elastic/docs-builder
config/assembler.yml
, 
config/versions.yml
docs-internal-workflows
bump PRs + prod version-bump (§0.3)
8.x / 7.x
elastic/docs
shared/versions/stack/*.asciidoc
, 
conf.yaml
None -- do not use 
docs-internal-workflows
Docs release issue（
elastic/dev
中的 
[Docs release] X.Y.Z
）是唯一事实来源，而不是工程团队的 
[Release]
issue。创建缺失的 docs issue（§1.1），或向用户收集日期。缺失的 issue URL：
(issue TBD)
。
操作手册： v9 -- v8。模板： minor -- 9.x patch -- 8.x patch。
版本线仓库配置文件部署监控
9.x+
elastic/docs-builder
config/assembler.yml
、
config/versions.yml
docs-internal-workflows
bump PR + prod version-bump（§0.3）
8.x / 7.x
elastic/docs
shared/versions/stack/*.asciidoc
、
conf.yaml
无——不要使用 
docs-internal-workflows

Invariants

不变量

  • IDs, dates, PR URLs, @mentions: from 
    gh
    , the docs issue, Slack, or the user. Never invent. Missing → 
    (issue TBD)
    or 
    [@handle]
    and ask.
  • Never mix 8.x and 9.x in one PR. 8.x/7.x: 
    elastic/docs
    only; no 
    docs-internal-workflows
    .
  • Checklist is the step index. Live-fetch only open work. RN merge is not a checkbox -- always 
    gh pr view
    blocking RN URLs.
  • A PR URL in the RN table is blocking until merged. Skip only 
    No changes
    / 
    N/A
    . Do not exempt Fleet, Agent, or any product by name.
  • Check boxes this skill just completed. Do not check anyone else's work (including docs-eng). Do not wait to be asked.
  • Slack: read slack-templates.md before drafting or sending. Confirm before send; thread follow-ups on the FF announcement.
  • Live/released Slack only after the gate (§0.3) and a user eyeball of the site. Do not draft before the gate.
  • Empty args / "how's my release": session state → active docs issue. Do not ask which version if one is in flight. After closed-issue cleanup leaves none, stop -- do not rediscover.
  • Cleanup = docs issue 
    CLOSED
    only. 404 = drop that ID and rediscover. No TTL.
  • RC varies each release -- read from the 
    #mission-control
    coordination thread or eng issue. Never hardcode a name.
  • Do not offer a Slack ping or PR whose issue box is already checked, or that the user already said they sent.
  • ID、日期、PR URL、@mention：必须来自 
    gh
    、docs issue、Slack 或用户。绝不编造。缺失时使用 
    (issue TBD)
    或 
    [@handle]
    并询问用户。
  • 绝不要在同一个 PR 中混合 8.x 和 9.x。8.x/7.x：只使用 
    elastic/docs
    ；不要使用 
    docs-internal-workflows
    。
  • Checklist 是步骤索引。仅实时获取仍处于 open 状态的工作。RN merge 不是 checkbox——始终通过 
    gh pr view
    检查阻塞的 RN URL。
  • RN 表中的 PR URL 在合并前始终是阻塞项。仅可跳过 
    No changes
    / 
    N/A
    。不得按名称豁免 Fleet、Agent 或任何其他产品。
  • 勾选此 skill 刚完成的 checkbox。不要勾选他人的工作（包括 docs-eng）。无需等待用户要求。
  • Slack：起草或发送前阅读 slack-templates.md。发送前确认；在 FF announcement 中以 thread 形式跟进。
  • 只有在 gate（§0.3）通过且用户目视检查网站后，才发送 live/released Slack 消息。gate 通过前不要起草。
  • 空参数 / “how's my release”：从 session state 获取 active docs issue。如果有一个版本正在进行，不要询问版本。closed-issue cleanup 后没有剩余版本时，停止——不要重新发现。
  • Cleanup 仅在 docs issue 为 
    CLOSED
    时完成。404 表示丢弃该 ID 并重新发现。没有 TTL。
  • RC 每次发布都可能不同——从 
    #mission-control
    coordination thread 或 eng issue 中读取。绝不硬编码名称。
  • 如果对应 checkbox 已经勾选，或用户已经表示发送过，则不要提供 Slack ping 或 PR。

Inputs

输入

$ARGUMENTS
is a space-separated list of semver versions and/or 
elastic/dev
issue numbers (e.g. 
9.4.0 9.3.4 8.19.15
or 
#1234 #1235
). If empty: load session state (§0.1). If it has an active release (anticipated date is today, in the last 2 days, or tomorrow, and the docs issue is not CLOSED), use that. Otherwise ask.
"How's my release" / "how's my release doing" (no versions given): empty-args status. Load session state and run §0. Do not ask which version if an active release is in state. If cleanup left no versions, say the tracked issues are closed and stop.
Match the user's request to the relevant section (status, PRs, reminders) -- they may skip the full pipeline.
$ARGUMENTS
是以空格分隔的 semver 版本和/或 
elastic/dev
issue 编号列表，例如 
9.4.0 9.3.4 8.19.15
或 
#1234 #1235
。如果为空：加载 session state（§0.1）。如果其中有一个 active release（anticipated date 是今天、最近 2 天内或明天，且 docs issue 未标记为 CLOSED），则使用它。否则询问用户。
“How's my release” / “how's my release doing”（未提供版本）：属于空参数状态查询。加载 session state 并执行 §0。如果 session state 中存在 active release，不要询问版本。如果 cleanup 后没有剩余版本，说明被跟踪的 issue 均已关闭并停止。
将用户请求匹配到相关部分（状态、PR、提醒）；用户可以跳过完整流程。

0. Check status (run on every invocation)

0. 检查状态（每次调用都执行）

When versions or issue numbers are known (from 
$ARGUMENTS
or session state), check state before proposing actions.
当已知版本或 issue 编号时（来自 
$ARGUMENTS
或 session state），先检查状态，再提出操作建议。

0.1 Session state (fast path)

0.1 Session state（快速路径）

Path: 
~/.elastic-docs/stack-release-state.json
. Local coordinator cache -- never commit it.
On every invocation:
  1. Read the file. Fall back to scratch if missing, unreadable, invalid JSON, no matching version, or the user says "start fresh".
  2. Cached IDs only skip discovery: 
    docsIssue
    , 
    engIssue
    , 
    coordinatorPrs.{repo:{number,sha,url}}
    , 
    rnPrs[].{product,url}
    , 
    slack.{docsChannelId,docsFfThreadTs,missionControlChannelId,coordinationThreadTs,beginPublishingTs,handles}
    , 
    deploys
    (9.x only: 
    configSha
    , 
    stagingBumpPr
    , 
    prodBumpPr
    , 
    stagingRunId
    , 
    prodRunId
    ). Also 
    line
    , 
    type
    , 
    anticipatedDate
    .
  3. Live-refresh only what the docs issue still has open (§0.2). Do not re-
    gh pr view
    / 
    gh run view
    checked lines. Always live-refresh RN PR merge state (the table stores URLs, not merge). Never trust cached JSON for merge/deploy conclusions; do trust a checked issue line that already cites a PR or run URL.
  4. Cached ID 404 / missing message: drop that field and rediscover just that piece. Empty 
    slack_read_thread
    on a Buildkite/bot parent (
    begin publishing
    , 
    release build declared
    ) is not a 404.
  5. End of §0: drop CLOSED docs issues, then write or delete the file.
deploys
is 9.x only. Omit it for 8.x / 7.x.
Closed-issue cleanup: Finished only if 
state
is 
CLOSED
. Report status this turn, then drop that version from 
releases
and 
active
. 
announced
while OPEN is not enough. A 404 is not finished -- drop 
docsIssue
and rediscover (step 4).
  • Some versions still open: write remaining entries + 
    updatedAt
    now. Mention which version was dropped.
  • None remain: delete the file. Do not write 
    { "active": [], "releases": {} }
    . Mention that local state was cleared.
路径： 
~/.elastic-docs/stack-release-state.json
。这是本地 coordinator 缓存——绝不提交到版本库。
每次调用时：
  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. 仅实时刷新 docs issue 中仍处于 open 状态的部分（§0.2）。不要对已勾选的行重新执行 
    gh pr view
    / 
    gh run view
    。始终实时刷新 RN PR 的合并状态（表中存储的是 URL，而不是合并结果）。对于合并或部署结论，绝不信任缓存 JSON；但可以信任已勾选且已引用 PR 或 run URL 的 issue 行。
  4. 缓存 ID 返回 404 / missing message 时：丢弃对应字段，只重新发现该部分。在 Buildkite/bot 父消息（
    begin publishing
    、
    release build declared
    ）上得到空的 
    slack_read_thread
    不是 404。
  5. §0 结束时：丢弃 CLOSED docs issue，然后写入或删除该文件。
deploys
仅适用于 9.x。对于 8.x / 7.x，省略该字段。
Closed-issue cleanup： 只有当 
state
为 
CLOSED
时才算完成。先在当前回合报告状态，再从 
releases
和 
active
中删除该版本。状态为 OPEN 时，仅标记 
announced
并不表示完成。404 不表示已完成——丢弃 
docsIssue
并重新发现（步骤 4）。
  • 仍有部分版本处于 open 状态： 写入剩余条目，并将 
    updatedAt
    更新为当前时间。说明已删除哪个版本。
  • 没有任何版本剩余： 删除该文件。不要写入 
    { "active": [], "releases": {} }
    。说明本地状态已清除。

0.2 Stage from the docs issue (do this before extra fetches)

0.2 根据 docs issue 确定阶段（在额外获取数据之前执行）

After session state, the first GitHub call is 
gh issue view
. Parse checkboxes immediately. Jump to that stage. Do not walk §1–§5. Do not re-verify checked lines.
bash
gh issue view <N> -R elastic/dev --json body,state
If the issue showsStageLive-fetch only
Docs issue CLOSEDdone / cleanupNone. Report closed, then closed-issue cleanup (§0.1).
Day-before ping or coordinator-PR box uncheckedpre-releaseCoordinator PR search (if no cached number) + RN table URLs. Skip 
#mission-control
and §0.3.
Coordinator PR checked, merge-RN ping uncheckedwaiting to tell writersRN PR states + (release day only) cached 
#mission-control
threads.
Config-merge / prod-bump (9.x) / 
elastic/docs
PR (8.x) unchecked		waiting on publish infraThat PR/deploy (§0.3 for 9.x) + RN PR states + cached 
#mission-control
threads.
Prod-bump line checked with a run URL (9.x), or 
elastic/docs
merge checked (8.x)		waiting on RNs / announceRN PR merge states only. Skip coordinator 
gh pr view
, bump PRs, 
gh run view
.
Website-confirm and 
#mission-control
live boxes checked		announcedReport done. No extra fetches unless the user asks.
RN merge is never a checkbox. Always 
gh pr view
each blocking RN URL.
If a checked line's cited URL 404s, rediscover that line only.
Stakeholder resolution (§ below): run only when a row still has a placeholder, a "specify who's responsible" footnote, or 2+ named people. Skip the 
#docs
FF-thread search when every row already has a single named stakeholder.
完成 session state 处理后，第一次 GitHub 调用必须是 
gh issue view
。立即解析 checkbox，直接跳到对应阶段。不要依次执行 §1–§5。不要重新验证已勾选的行。
bash
gh issue view <N> -R elastic/dev --json body,state
Issue 显示状态阶段仅实时获取
Docs issue CLOSED完成 / cleanup无。报告已关闭，然后执行 closed-issue cleanup（§0.1）。
发布前一天提醒或 coordinator-PR checkbox 未勾选发布前Coordinator PR 搜索（如果没有缓存编号）以及 RN 表中的 URL。跳过 
#mission-control
和 §0.3。
Coordinator PR 已勾选，但 merge-RN 提醒未勾选等待通知撰写者RN PR 状态，以及（仅发布当天）缓存的 
#mission-control
thread。
Config-merge / prod-bump（9.x）/ 
elastic/docs
PR（8.x）未勾选		等待发布基础设施对应 PR/部署（9.x 使用 §0.3）、RN PR 状态，以及缓存的 
#mission-control
thread。
Prod-bump 行已勾选并包含 run URL（9.x），或 
elastic/docs
merge 已勾选（8.x）		等待 RN / 宣布发布仅获取 RN PR 合并状态。 跳过 coordinator 
gh pr view
、bump PR 和 
gh run view
。
Website-confirm 和 
#mission-control
live checkbox 已勾选		已宣布报告完成。除非用户要求，否则不要执行额外获取。
RN merge 永远不是 checkbox。 始终使用 
gh pr view
检查每个阻塞的 RN URL。
如果已勾选行引用的 URL 返回 404，只重新发现该行。
Stakeholder resolution（见下文）：仅当某一行仍包含 placeholder、“specify who's responsible” 脚注或 2 个以上具名负责人时运行。如果每一行都只有一个具名 stakeholder，则跳过 
#docs
FF-thread 搜索。

GitHub state

GitHub 状态

If session state has the docs issue number, 
gh issue view
it directly. Otherwise search 
[Docs release] <version>
. Do not 
gh pr list
by version if the issue or session state already has the coordinator PR URL.
Search coordinator PRs only when §0.2 still needs them, and only in the repo for that line (9.x → 
docs-builder
, 8.x → 
docs
). Never 
gh pr list
elastic/docs
for a 9.x-only batch.
bash
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 checkboxes: If an item is unchecked but this skill already completed it (a Slack message you sent, a PR you opened), check it now using §4. Do not ask. Do not check items for work this skill did not do.
  • RN PR status: One shell loop over every PR URL in the Release Notes table:
bash
gh pr view <url> --json state,mergedAt,title
Skip vs blocking: Skip only 
No changes
/ 
N/A
. A PR URL is blocking until merged -- do not exempt Fleet, Agent, or any other product by name. Named stakeholder is the owner; do not add 
?
on a named row.
Report: X/Y merged (skipping N/A rows), Z outstanding. When all blocking RN PRs are merged: "All RN PRs merged."
Then, by line -- only if §0.2 says publish infra is still open:
  • 9.x: After the 
    docs-builder
    coordinator PR is merged and the prod-bump issue line is still unchecked, continue to §0.3. If that line is already checked with a run URL, skip §0.3.
  • 8.x / 7.x: Skip §0.3. Config lives in 
    elastic/docs
    . No 
    docs-internal-workflows
    bump or deploy.
如果 session state 中有 docs issue 编号，直接执行 
gh issue view
。否则搜索 
[Docs release] <version>
。不要在 issue 或 session state 已有 coordinator PR URL 时按版本执行 
gh pr list
。
仅当 §0.2 仍需要 coordinator PR 时搜索它们，并且只搜索对应版本线的仓库（9.x → 
docs-builder
，8.x → 
docs
）。对于仅包含 9.x 的批次，绝不要对 
elastic/docs
执行 
gh pr list
。
bash
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 checkbox： 如果某项未勾选，但此 skill 已经完成对应工作（发送过 Slack 消息、打开过 PR），立即使用 §4 将其勾选。不要询问用户。不要勾选此 skill 未完成的工作。
  • RN PR 状态： 使用一个 shell 循环遍历 Release Notes 表中的每个 PR URL：
bash
gh pr view <url> --json state,mergedAt,title
跳过与阻塞： 仅可跳过 
No changes
/ 
N/A
。PR URL 在合并前始终是阻塞项——不得按名称豁免 Fleet、Agent 或任何其他产品。具名 stakeholder 即负责人；不要在具名行中添加 
?
。
报告格式：X/Y 已合并（跳过 N/A 行），Z 项未完成。当所有阻塞 RN PR 均已合并时，报告“All RN PRs merged.”
然后按版本线处理——仅当 §0.2 表示发布基础设施仍处于 open 状态时：
  • 9.x： 
    docs-builder
    coordinator PR 合并后，如果 prod-bump issue 行仍未勾选，则继续执行 §0.3。如果该行已勾选并包含 run URL，则跳过 §0.3。
  • 8.x / 7.x： 跳过 §0.3。配置位于 
    elastic/docs
    。没有 
    docs-internal-workflows
    bump 或部署。

Resolve stakeholder assignments

解析 Stakeholder 分工

Run only when a row still needs it (§0.2). Cases: backtick placeholder (e.g. 
`Beats point person`
) or "specify who's responsible" footnote; 2+ named people and one confirmed in thread; named stakeholder out and someone else confirmed covering.
  1. FF announcement thread (
    slack_search_public
    for the version in 
    #docs
    , then 
    slack_read_thread
    ).
  2. Scan replies: "I can handle [product]", "I'll do [product]", "I'm drafting the X.Y.Z [product] release notes", or explicit coverage.
  3. Reverse-map Slack display name → GitHub handle via the issue appendix lookup table. If missing, 
    slack_search_users
    and ask the user for the GitHub handle.
  4. Update the issue body (§4): replace placeholder, narrow to the confirmed person, or swap in the covering person.
  5. Report: "Updated [Product] stakeholder: [old] → @new-handle (confirmed in thread)."
No confirmation: leave as-is and flag. Do not guess. Ambiguous ("I can help" with no product): ask.
仅在某一行仍需要解析时运行（§0.2）。适用情况：存在反引号 placeholder，例如 
Beats point person
，或“specify who's responsible”脚注；一行中有 2 个以上具名人员且其中一人已在 thread 中确认；具名 stakeholder 休假且已确认由其他人代为负责。
  1. 在 FF announcement thread 中查找对应版本（在 
    #docs
    中使用 
    slack_search_public
    ，然后使用 
    slack_read_thread
    ）。
  2. 扫描回复：“I can handle [product]”、“I'll do [product]”、“I'm drafting the X.Y.Z [product] release notes”，或明确的代为负责说明。
  3. 通过 issue 附录查找表，将 Slack display name 反向映射到 GitHub handle。如果找不到，使用 
    slack_search_users
    并向用户询问 GitHub handle。
  4. 更新 issue body（§4）：替换 placeholder、将范围缩小到已确认人员，或替换为代为负责的人员。
  5. 报告：“Updated [Product] stakeholder: [old] → @new-handle (confirmed in thread).”
没有确认信息时：保持原样并标记出来。不要猜测。如果信息含糊（例如只说“I can help”但未说明产品），则询问用户。

#mission-control (release day only)

#mission-control
（仅发布当天）

If session state has thread timestamps, 
slack_read_thread
those first.
Do not 
slack_read_channel
the whole of 
#mission-control
. Do not 
slack_search_public
for 
"begin publishing"
without a version and 
after:
today's date.
Empty thread on 
beginPublishingTs
/ 
releaseBuildDeclaredTs
is expected for Buildkite bot posts. Treat the parent as the signal; do not rediscover.
Only search when a needed cached ts is missing (not merely an empty thread): 
slack_search_public
query like 
9.5.2 in:#mission-control after:YYYY-MM-DD
, limit 5.
Signals matching tracked versions (link each thread in the status report):
  1. Coordination thread: "Coordination for ... release, scheduled on" -- timing, who's RC (never assume), schedule changes in replies.
  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." -- docs action trigger. Read for go/hold from whoever is RC (step 1).
如果 session state 中有 thread 时间戳，优先使用 
slack_read_thread
读取对应 thread。
不要对整个 
#mission-control
执行 
slack_read_channel
。不要在没有版本和 
after:
当天日期的情况下搜索“begin publishing”。
beginPublishingTs
/ 
releaseBuildDeclaredTs
对应的 thread 为空是 Buildkite bot 消息的正常情况。将父消息视为信号；不要重新发现。
仅当所需缓存 ts 缺失时才搜索（仅仅 thread 为空不代表需要搜索）：使用类似 
slack_search_public
的查询，例如 
9.5.2 in:#mission-control after:YYYY-MM-DD
，限制为 5 条结果。
匹配被跟踪版本的信号（在状态报告中附上每个 thread 的链接）：
  1. Coordination thread： “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.”——这是 docs 操作的触发信号。从实际担任 RC 的人处读取 go/hold 指示（步骤 1）。

0.3 Watch 
docs-internal-workflows
(9.x only)

0.3 监控 
docs-internal-workflows
（仅限 9.x）

Skip this section for 8.x / 7.x. Do not search that repo, do not poll bump PRs or version-bump runs, and do not require a prod version-bump for 8.x live messages.
Skip §0.3 when the docs issue already checks the "Watch for the prod version-bump deploy" line (or equivalent) and cites a successful prod run URL. Do not re-list bump PRs or re-view runs.
For 9.x, after the 
docs-builder
coordinator PR merges and that issue line is still unchecked:
The coordinator merges docs-builder config PRs and watches the prod version-bump. Do not wait on docs engineering. Merging the coordinator PR (config SHA = merge commit short SHA) automatically opens:
  • [bump] [staging] docs-builder configuration: <sha>
  • [bump] [prod] docs-builder configuration: <sha>
Those merges kick off 
Staging / Docs / Deploy / version-bump / ...
and 
Prod / Docs / Deploy / version-bump / ...
.
Care about two things only:
  1. Bump PRs merged -- staging and prod 
    [bump] ... <sha>
    are 
    MERGED
    .
  2. Prod version-bump deploy succeeded for that SHA. A failed staging version-bump blocks -- report immediately; do not treat prod as done.
Ignore unrelated workflows (edge, AI enrich, zizmor, dependabot, assembler ingest, link-index) unless the user asks. Do not wait on staging success once prod has succeeded, as long as staging did not fail.
bash
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
Match runs by 
version-bump
in the name plus timing after the bump PR merge. Cache bump PR numbers and run IDs.
When prod version-bump is 
completed/success
and staging did not fail: "Prod deploy succeeded for <sha>."
Gate -- do not draft "docs are live" / "docs released" until all required:
LineGate
9.xAll blocking RN PRs merged and prod version-bump succeeded (staging did not fail)
8.x / 7.xAll blocking RN PRs merged and the 
elastic/docs
coordinator PR is merged
Until the gate is met: do not draft those messages, do not ask "ready to send?", do not check website-confirm or 
#mission-control
boxes.
Once the gate is met: ask the user to eyeball the website, then §6.5. Visual check is required before sending. 8.x "docs released" still includes the scrape line.
8.x / 7.x 必须跳过本节。 不要搜索该仓库，不要轮询 bump PR 或 version-bump run，也不要要求 8.x 提供 prod version-bump 后才能发送 live 消息。
当 docs issue 已勾选“Watch for the prod version-bump deploy”一行（或等效项），并引用成功的 prod run URL 时，跳过 §0.3。不要重新列出 bump PR，也不要重新查看 run。
对于 9.x，在 
docs-builder
coordinator PR 合并后，如果该 issue 行仍未勾选：
Coordinator 会合并 docs-builder 配置 PR，并监控 prod version-bump。不要等待 docs engineering。合并 coordinator PR（config SHA = merge commit 的短 SHA）后会自动创建：
  • [bump] [staging] docs-builder configuration: <sha>
  • [bump] [prod] docs-builder configuration: <sha>
这些合并会触发 
Staging / Docs / Deploy / version-bump / ...
和 
Prod / Docs / Deploy / version-bump / ...
。
只需关注两件事：
  1. Bump PR 已合并——staging 和 prod 的 
    [bump] ... <sha>
    均为 
    MERGED
    。
  2. 该 SHA 的 prod version-bump 部署成功。staging version-bump 失败会构成阻塞——立即报告；不要把 prod 当作已完成。
忽略无关 workflow（edge、AI enrich、zizmor、dependabot、assembler ingest、link-index），除非用户另有要求。prod 成功后无需再等待 staging 成功，只要 staging 没有失败即可。
bash
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
以及 bump PR 合并后的时间匹配 run。缓存 bump PR 编号和 run ID。
当 prod version-bump 为 
completed/success
且 staging 未失败时，报告“Prod deploy succeeded for <sha>.”
Gate——在以下所有条件满足前，不要起草“docs are live” / “docs released”：
版本线Gate
9.x所有阻塞 RN PR 均已合并，并且 prod version-bump 成功（staging 未失败）
8.x / 7.x所有阻塞 RN PR 均已合并，并且 
elastic/docs
coordinator PR 已合并
Gate 未满足时：不要起草这些消息，不要询问“ready to send?”，不要勾选 website-confirm 或 
#mission-control
checkbox。
Gate 满足后：要求用户目视检查网站，然后执行 §6.5。发送前必须进行视觉检查。8.x 的“docs released”消息仍需包含 scrape 行。

Propose next action

提出下一步操作

Summarize the §0.2 stage, what is still blocking, and the single next action. Do not offer a Slack ping or PR whose box is already checked / the user already sent.
总结 §0.2 所确定的阶段、仍然存在的阻塞项，以及唯一的下一步操作。如果对应 checkbox 已勾选，或用户已经表示发送过，则不要提供 Slack ping 或 PR。

1. Gather inputs

1. 收集输入

  • Semver list.
  • Docs release issue(s) -- 
    [Docs release] X.Y.Z
    , not the eng release issue. 
    gh issue list -R elastic/dev --search "[Docs release] <version>" --json number,title,url
    .
  • Eng release issue -- RC's parent (
    [Release] X.Y.Z
    , 
    X.Y.Z release
    , etc.). Canonical schedule (FF, GA), often links to docs issues, identifies the RC. Use for dates when the docs issue does not exist yet, which versions share a GA, and RC name.
  • If docs issues don't exist yet, §1.1.
  • Semver 列表。
  • Docs release issue(s)——使用 
    [Docs release] X.Y.Z
    ，不要使用 eng release issue。
    gh issue list -R elastic/dev --search "[Docs release] <version>" --json number,title,url
    。
  • Eng release issue——RC 的父 issue（
    [Release] X.Y.Z
    、
    X.Y.Z release
    等）。其中包含权威日程（FF、GA），通常会链接 docs issue，并标识 RC。当 docs issue 尚不存在时，使用它获取日期；使用它判断哪些版本共享 GA，以及获取 RC 名称。
  • 如果 docs issue 尚不存在，执行 §1.1。

1.1 Create docs release issues (when they don't exist)

1.1 创建 Docs release issue（当 issue 不存在时）

  1. Template: 9.x minor → 
    docs-release.md
    ; 9.x patch → 
    docs-patch-release.md
    ; 8.x → 
    docs-patch-release-8.x.md
    .
  2. Dates from the eng release issue (feature freeze, anticipated GA). If none, ask the user for those two only. Merge release notes by = the calendar day before anticipated GA (
    [DAY_BEFORE_RELEASE_DATE]
    ). Do not ask for merge-by or code freeze.
  3. gh issue create -R elastic/dev --template <template-file> --title "[Docs release] <version>"
  4. Fill Overview (version, dates) and the release coordinator from the eng issue if listed. Leave the rest of the template as-is -- do not copy stakeholders from a previous release.
  5. Report: "Created #NNNN for X.Y.Z. Filled in dates from eng issue #MMMM. Please review."
  6. If the eng issue doesn't already reference the new docs issue: 
    gh issue comment <eng-issue> -R elastic/dev --body "Docs tracking: https://github.com/elastic/dev/issues/<new-docs-issue>"
User-provided schedule wins over the eng issue.
  1. 模板：9.x minor → 
    docs-release.md
    ；9.x patch → 
    docs-patch-release.md
    ；8.x → 
    docs-patch-release-8.x.md
    。
  2. 日期来自 eng release issue（feature freeze、anticipated GA）。如果不存在，只向用户询问这两个日期。Release notes 合并截止日期 = anticipated GA 的前一个日历日（
    [DAY_BEFORE_RELEASE_DATE]
    ）。不要询问 merge-by 或 code freeze。
  3. gh issue create -R elastic/dev --template <template-file> --title "[Docs release] <version>"
  4. 填写 Overview（版本、日期），以及 eng issue 中列出的 release coordinator。模板其余部分保持原样——不要从上一次发布复制 stakeholders。
  5. 报告：“Created #NNNN for X.Y.Z. Filled in dates from eng issue #MMMM. Please review.”
  6. 如果 eng issue 尚未引用新建的 docs issue：
    gh issue comment <eng-issue> -R elastic/dev --body "Docs tracking: https://github.com/elastic/dev/issues/<new-docs-issue>"
用户提供的日程优先于 eng issue。

2. Classify each version

2. 对每个版本进行分类

Patch if the patch number 
> 0
; minor if 
V.R.0
; major if 
V.0.0
(follow the dev issue + v8/v9 playbooks). Then route with §3.
如果 patch number 
> 0
，则为 patch；如果为 
V.R.0
，则为 minor；如果为 
V.0.0
，则为 major（遵循 dev issue 和 v8/v9 操作手册）。然后按 §3 分流。

3. Route PRs (decision)

3. PR 分流（决策）

8.x / 7.x (patch or minor)

8.x / 7.x（patch 或 minor）

Follow elastic-stack-v8.md. Coordinator PRs target 
elastic/docs
 only (
shared/versions*
, 
conf.yaml
per template).
遵循 elastic-stack-v8.md。Coordinator PR 只能针对 
elastic/docs
（按模板修改 
shared/versions*
、
conf.yaml
）。

9.x -- isolated patch (only one 9.x in the batch, or no higher minor same GA)

9.x——独立 patch（批次中只有一个 9.x，或同一 GA 下没有更高的 minor）

  • Patch: One 
    elastic/docs-builder
    PR: bump 
    config/versions.yml
    so 
    versioning_systems.stack.current
    matches the minor line you ship (e.g. 
    9.3.4
    -> minor 9.3). Link on the 
    versions.yml
     checklist line.
  • Timing gate: Don't open this PR if more patch releases are expected on the same minor line before GA. If the current published version is more than one patch behind (e.g. current 
    9.3.2
    , shipping 
    9.3.4
    ), an intermediate patch is likely first -- wait or confirm with the user.
  • Patch： 创建一个 
    elastic/docs-builder
    PR：更新 
    config/versions.yml
    ，使 
    versioning_systems.stack.current
    与所发布的 minor line 一致（例如 
    9.3.4
    → minor 9.3）。在 
    versions.yml
     checklist 行中填写链接。
  • 时间 gate： 如果预计在 GA 前同一 minor line 上还有更多 patch release，不要打开此 PR。如果当前已发布版本落后超过一个 patch（例如当前为 
    9.3.2
    ，本次发布 
    9.3.4
    ），很可能先发布一个中间 patch——等待或向用户确认。

9.x -- minor (
9.x.0
)

9.x——minor（
9.x.0
）

Two separate draft PRs (two checklist lines):
WhenBranch / changeLink on dev issue
After FF
config/assembler.yml
only: 
shared_configuration.stack.next
-> upcoming minor (e.g. 
9.4
)		Post-FF line -- PR or merge commit (shape)
Before GA (see timing below)
assembler.yml
: 
stack.current
-> that minor; 
stack.next
-> 
main
. 
versions.yml
: 
versioning_systems.stack.current
-> that minor.		Nested 
versions.yml
 bullet -- PR URL at end of line
Timing for the versions.yml PR (minors): Don't open early -- many patches land between FF and GA. Open when no more patches are expected before GA (typically 1-2 days before). Check 
#mission-control
or ask if another patch is queued.
The coordinator merges each docs-builder PR when it is time; bump PRs and deploys are automatic. Do not substitute one PR for both post-FF assembler and pre-GA versions.yml steps.
创建两个独立的 draft PR（对应两个 checklist 行）：
时间Branch / 变更Dev issue 中的链接位置
FF 之后仅修改 
config/assembler.yml
：
shared_configuration.stack.next
→ 即将发布的 minor（例如 
9.4
）		Post-FF 行——PR 或 merge commit（shape）
GA 之前（时间见下文）
assembler.yml
：
stack.current
→ 该 minor；
stack.next
→ 
main
。
versions.yml
：
versioning_systems.stack.current
→ 该 minor。		嵌套的 
versions.yml
 bullet——行末填写 PR URL
Minor 版本的 versions.yml PR 时间： 不要过早打开——FF 与 GA 之间通常会合并许多 patch。通常在 GA 前 1–2 天、预计不会再有 patch 时打开。检查 
#mission-control
或询问用户是否还有 patch 在队列中。
Coordinator 会在合适的时间合并每个 docs-builder PR；bump PR 和部署会自动进行。不要使用一个 PR 同时替代 post-FF assembler 和 pre-GA versions.yml 两个步骤。

Same calendar GA: multiple 9.x (e.g. 
9.3.4
+ 
9.4.0
)

同一日历日 GA：多个 9.x（例如 
9.3.4
+ 
9.4.0
）

Only one will be a minor -- the others are patches. There will not be two minors on the same day.
  1. Assembler PR: The minor still gets its own post-FF 
    assembler.yml
    PR (
    stack.next
    bump).
  2. versions.yml PR: Only one -- targets the highest version in the batch.
  3. Canonical issue = highest 9.x minor (owns the versions.yml PR).
  4. Lower-line issue = lower semver patch: still for RNs; do not duplicate the versions.yml bump -- supersede to canonical (§4).
其中只有一个版本会是 minor，其余都是 patch。同一天不会有两个 minor。
  1. Assembler PR： minor 仍需拥有自己的 post-FF 
    assembler.yml
    PR（更新 
    stack.next
    ）。
  2. Versions.yml PR： 只创建一个——目标为批次中的最高版本。
  3. Canonical issue = 最高的 9.x minor（负责 versions.yml PR）。
  4. Lower-line issue = 较低 semver 的 patch：仍负责 RN；不要重复执行 versions.yml bump——将其标记为由 canonical issue 取代（§4）。

4. Edit 
elastic/dev
issue bodies

4. 编辑 
elastic/dev
issue body

  • Main trail in the description, not comments.
  • Do not delete template placeholders, footnotes, or stakeholder tables -- only add checkmarks, links, strikethrough, short cross-refs.
  • Real 
    #
    / PR URLs from 
    gh
    or the user -- never guess numbers.
  • Check off as you go. After any skill-flow action that matches a checklist item, check it immediately. Nested boxes for the same action get checked together. Do not wait to be asked. Do not report the item as pending.
  • Do not check items you did not complete. Other teams' steps (including docs-eng), user-completed work outside this skill, and future release-day items stay unchecked.
  • After each coordinator PR this skill opens: check the parent and nested lines and paste the PR URL (minors: post-FF vs version-bump have different URLs on different lines).
Match by checklist wording, not by assuming one template:
Skill actionChecklist line
Outstanding-RNs / day-before 
#docs
ping sent		Post in #docs to remind ... PRs that have not been opened and/or approved
Coordinator PR openedOpen a PR ... plus the nested versions.yml / assembler.yml / conf.yaml line
Merge-RN 
#docs
ping sent		Post in #docs ... they can merge their release note PRs
Coordinator PR mergedMerge the docs-builder config PR (or the 8.x equivalent)
Prod version-bump deploy succeeded (9.x only)Watch for the prod version-bump deploy -- check only after §0.3 prod deploy success (staging did not fail). Do not use this line for 8.x.
User confirmed website eyeballConfirm that the updated docs appear on the website -- only after the gate (§0.3) and the user says the site looks right
#mission-control
"docs are live" reply		Post in #mission-control that the docs are live -- only after the gate and website eyeball; still confirm before sending Slack
bash
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
Same-GA supersession (lower-line issue)
  • Stakeholder blocks: 
    superseded by #<canonical>
    (real number).
  • Checklist blocks owned by canonical: wrap in 
    ~strikethrough~
    , tag e.g. 
    [not needed: superseded by 9.4.0 -- #<canonical>]
    .
  • Optional footer: 
    Crossed out instructions superseded by https://github.com/elastic/dev/issues/<canonical>
  • RN-only coordinator steps may stay open on the lower-line issue ("verify/publish this version's release notes"); strike only lines that duplicate canonical deploy work.
PR opened against the wrong issue's path: close with Superseded by 
owner/repo#N
.
  • 主要记录应写在 description 中，而不是 comment 中。
  • 不要删除 template placeholder、脚注或 stakeholder 表——只能添加勾选标记、链接、删除线和简短交叉引用。
  • 真实的 
    #
    / PR URL 必须来自 
    gh
    或用户——绝不猜测编号。
  • 边执行边勾选。 任何与 checklist 项匹配的 skill 操作完成后，立即勾选。同一操作的嵌套 checkbox 一并勾选。不要等待用户要求，也不要将该项报告为待处理。
  • 不要勾选你未完成的项目。 其他团队的步骤（包括 docs-eng）、此 skill 之外由用户完成的工作，以及未来的发布当天事项，都应保持未勾选。
  • 每次此 skill 打开 coordinator PR 后： 勾选父级和嵌套行，并粘贴 PR URL（minor 的 post-FF 与 version-bump 使用不同 URL，并填写在不同行中）。
根据 checklist 措辞进行匹配，不要假设所有模板都完全相同：
Skill 操作Checklist 行
Outstanding-RNs / 发布前一天 
#docs
提醒已发送		在 #docs 发布提醒……PR 尚未打开和/或批准
Coordinator PR 已打开打开一个 PR……以及嵌套的 versions.yml / assembler.yml / conf.yaml 行
Merge-RN 
#docs
提醒已发送		在 #docs 发布提醒……以便合并 release note PR
Coordinator PR 已合并合并 docs-builder 配置 PR（或 8.x 对应项）
Prod version-bump 部署成功（仅限 9.x）监控 prod version-bump 部署——仅在 §0.3 prod 部署成功且 staging 未失败后勾选。8.x 不要使用此行。
用户确认已目视检查网站确认更新后的文档已出现在网站上——仅在 gate（§0.3）满足且用户确认网站显示正常后勾选
已在 
#mission-control
回复“docs are live”		在 #mission-control 发布文档已上线的消息——仅在 gate 通过且完成网站目视检查后执行；发送 Slack 前仍需确认
bash
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 的 supersession（lower-line issue）
  • Stakeholder 区块：
    superseded by #<canonical>
    （使用真实编号）。
  • 由 canonical 负责的 Checklist 区块：使用 
    ~strikethrough~
    包裹，并添加标签，例如 
    [not needed: superseded by 9.4.0 -- #<canonical>]
    。
  • 可选 footer：
    Crossed out instructions superseded by https://github.com/elastic/dev/issues/<canonical>
  • 仅涉及 RN 的 coordinator 步骤可以在 lower-line issue 上保持 open（“verify/publish this version's release notes”）；只划掉与 canonical 部署工作重复的行。
如果 PR 错误地基于另一个 issue 的路径打开：使用 
Superseded by owner/repo#N
关闭它。

5. Open coordinator PRs (
elastic/docs
/ 
elastic/docs-builder
)

5. 打开 Coordinator PR（
elastic/docs
/ 
elastic/docs-builder
）

Branch: 
stack-<version>
(e.g. 
stack-9.5-post-ff
, 
stack-9.5
, 
stack-8.19.16
) -- no 
docs/
prefix, no 
pre-ga
/ "day before" in the name. Existing checkout if available; otherwise clone to a temp directory.
bash
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>"
Mark ready only in the right window. Re-draft: 
gh pr ready <num> -R elastic/<repo> --undo
.
Immediately after the PR exists: check the matching docs-issue lines and paste the PR URL (§4).
Branch：
stack-<version>
（例如 
stack-9.5-post-ff
、
stack-9.5
、
stack-8.19.16
）——不要使用 
docs/
prefix，也不要在名称中使用 
pre-ga
/ “day before”。如果已有可用 checkout，则直接使用；否则克隆到临时目录。
bash
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。重新转为 draft：
gh pr ready <num> -R elastic/<repo> --undo
。
PR 创建后立即执行：勾选匹配的 docs-issue 行并粘贴 PR URL（§4）。

6. Reminders & messages (
#docs
, Slack)

6. 提醒与消息（
#docs
、Slack）

Copy dates, issue links, products, and outstanding PR status from the docs issue (or user-provided schedule). Never invent versions, PR state, or @mentions.
If the body is not already in context from §0, 
gh issue view <N> -R elastic/dev --json title,url,body
. Parse: version from title/Overview; anticipated GA / FF / merge-by from Overview; stakeholders and RN PR column from the Release Notes table. Skip vs blocking as in §0. URL present = blocking until merged.
Grouping: 8.x and 9.x tables often differ -- separate "Ping for ..." sections when they do; merge duplicate product lines when the same stakeholders apply to multiple versions.
Unresolved stakeholders and Slack send/preview: slack-templates.md.
从 docs issue（或用户提供的日程）复制日期、issue 链接、产品和未完成的 PR 状态。绝不编造版本、PR 状态或 @mention。
如果 §0 中尚未加载 body，执行 
gh issue view <N> -R elastic/dev --json title,url,body
。解析：从 title/Overview 获取版本；从 Overview 获取 anticipated GA / FF / merge-by；从 Release Notes 表获取 stakeholders 和 RN PR 列。跳过与阻塞规则同 §0。只要存在 URL，在合并前就视为阻塞项。
分组： 8.x 和 9.x 的表格通常不同——不同时应分别创建“Ping for ...”区块；当同一批 stakeholders 适用于多个版本时，合并重复的产品行。
未解析的 stakeholders 以及 Slack 发送/预览操作：slack-templates.md。

Templates, mentions, send

模板、Mention 与发送

Read slack-templates.md for templates, handle lookup, and OOO checks. If the user doesn't specify the reminder type, present options: feature freeze, outstanding RNs, docs released, or other.
Docs-released: one version → singular template (
version
/ 
are released
); two or more → plural (
versions
/ 
are all released
). Never "versions" / "all" for a single version. Omit the 8.x scrape line on a 9.x-only batch.
Send (do this even if you skip the templates file):
  1. Preview in a fenced code block (slack-templates.md) so line breaks are preserved. Then "Send?"
  2. Wait for confirmation. "Send it" / "looks good" counts. "Update the thread" / "check the boxes" does not.
  3. Payload mentions: people 
    <@U…>
    ; user groups 
    <!subteam^S…>
    . Never guess an ID.
  4. Follow-ups: thread on the FF announcement (
    docsFfThreadTs
    ) and 
    reply_broadcast: true
    .
  5. After send: check the matching docs-issue item (§4).
阅读 slack-templates.md 以获取模板、handle 查找方式和 OOO 检查。如果用户未指定提醒类型，列出选项：feature freeze、outstanding RNs、docs released 或其他。
Docs-released： 一个版本 → 使用单数模板（
version
/ 
are released
）；两个或更多版本 → 使用复数模板（
versions
/ 
are all released
）。绝不能对单个版本使用“versions” / “all”。仅包含 9.x 的批次中不要加入 8.x scrape 行。
发送（即使跳过模板文件也要执行）：
  1. 在 fenced code block 中预览（使用 slack-templates.md），以保留换行。然后询问“Send?”
  2. 等待确认。“Send it” / “looks good” 视为确认。“Update the thread” / “check the boxes” 不算确认。
  3. Payload mention：人员使用 
    <@U…>
    ；用户组使用 
    <!subteam^S…>
    。绝不猜测 ID。
  4. 后续消息：在 FF announcement（
    docsFfThreadTs
    ）下使用 thread，并设置 
    reply_broadcast: true
    。
  5. 发送后：勾选匹配的 docs-issue 项（§4）。

6.5 Replying in #mission-control threads (release day)

6.5 在 
#mission-control
thread 中回复（发布当天）

Do not enter until the gate is met (§0.3): 9.x = blocking RNs merged + prod version-bump; 8.x = blocking RNs merged + 
elastic/docs
coordinator PR merged. If not met, say what is outstanding and stop -- do not draft live/released messages.
Once the gate is met:
  1. Ask the user to eyeball the website (9.x: current docs / this version's release notes; 8.x: v8 playbook pages).
  2. After they confirm: check the "docs appear on the website" box (§4). Draft the 
    #mission-control
    reply (
    X.Y.Z docs are live.
    ) and the 
    #docs
    "docs released" ping (8.x scrape line only when an 8.x version is in the batch). Show both; send only with confirmation (slack-templates.md).
  3. On confirm: reply in the begin-publishing thread (
    thread_ts
    from §0), send the 
    #docs
    ping, and check the 
    #mission-control
    box.
在 gate 满足前不要进入此流程（§0.3）：9.x = 阻塞 RN PR 已合并 + prod version-bump 成功；8.x = 阻塞 RN PR 已合并 + 
elastic/docs
coordinator PR 已合并。如果未满足，说明尚未完成的项目并停止——不要起草 live/released 消息。
Gate 满足后：
  1. 要求用户目视检查网站（9.x：当前文档 / 本版本 release notes；8.x：v8 操作手册页面）。
  2. 用户确认后：勾选“docs appear on the website” checkbox（§4）。起草 
    #mission-control
    回复（
    X.Y.Z docs are live.
    ）和 
    #docs
    “docs released”提醒（仅当批次中包含 8.x 版本时才加入 8.x scrape 行）。展示两条消息；仅在得到确认后发送（slack-templates.md）。
  3. 确认后：在 begin-publishing thread 中回复（使用 §0 中的 
    thread_ts
    ），发送 
    #docs
    提醒，并勾选 
    #mission-control
    checkbox。

7. Background poller (in-session)

7. 后台轮询器（会话内）

When the user says "watch the PRs", "watch the deploy", or "let me know when they're all merged":
当用户说“watch the PRs”、“watch the deploy”或“let me know when they're all merged”时：

7.1 Release-note PRs

7.1 Release-note PR

  1. Blocking RN PR URLs from the issue table (skip N/A / No changes only).
  2. Background shell (
    block_until_ms: 0
    ) every 5 minutes: 
    gh pr view <url> --json state -q .state
    .
  3. All 
    MERGED
    → emit 
    ALL_RN_PRS_MERGED
    (
    notify_on_output
    ).
  4. Report: "All RN PRs are merged." Persist to the session file.
  1. 从 issue 表中获取阻塞的 RN PR URL（仅跳过 N/A / No changes）。
  2. 后台 shell（
    block_until_ms: 0
    ）每 5 分钟执行一次：
    gh pr view <url> --json state -q .state
    。
  3. 全部为 
    MERGED
    → 输出 
    ALL_RN_PRS_MERGED
    （
    notify_on_output
    ）。
  4. 报告：“All release-note PRs are merged.” 将结果持久化到 session 文件。

7.2 docs-internal-workflows deploys (9.x only)

7.2 docs-internal-workflows 部署（仅限 9.x）

Skip for 8.x / 7.x.
After the 9.x 
docs-builder
coordinator PR is merged (or when the user asks to watch 9.x deploys):
  1. Config SHA + staging/prod bump PRs + version-bump run IDs (§0.3). Prefer session state.
  2. Poll 
    gh run view <id>
    every 30s. Emit 
    DEPLOY_STAGING_FAILED
    (blocks; alert immediately), 
    DEPLOY_PROD_FAILED
    , 
    DEPLOY_PROD_DONE
    (prod 
    completed/success
    and staging did not fail).
  3. On 
    DEPLOY_PROD_DONE
    : "Prod deploy succeeded." If blocking RN PRs are still open, list them -- do not offer live/released Slack. If they are all merged, ask the user to eyeball, then §6.5.
  4. Write run IDs and conclusions to session state.
Pollers only run in the current session. Next session: §0.1 + §0, not full rediscovery.
For anything not specified here (API docs, Buildkite): follow the docs issue checklist and playbooks.
8.x / 7.x 必须跳过。
在 9.x 
docs-builder
coordinator PR 合并后，或用户要求监控 9.x 部署时：
  1. 获取 config SHA、staging/prod bump PR 和 version-bump run ID（§0.3）。优先使用 session state。
  2. 每 30 秒轮询一次 
    gh run view <id>
    。输出 
    DEPLOY_STAGING_FAILED
    （阻塞项；立即告警）、
    DEPLOY_PROD_FAILED
    、
    DEPLOY_PROD_DONE
    （prod 为 
    completed/success
    且 staging 未失败）。
  3. 出现 
    DEPLOY_PROD_DONE
    时，报告“Prod deploy succeeded.” 如果阻塞 RN PR 仍处于 open 状态，列出这些 PR——不要提供 live/released Slack。如果全部已合并，要求用户目视检查网站，然后执行 §6.5。
  4. 将 run ID 和结论写入 session state。
轮询器只在当前会话中运行。下一次会话：执行 §0.1 + §0，而不是完整重新发现。
对于此处未规定的内容（API docs、Buildkite）：遵循 docs issue checklist 和操作手册。