用途：协调 Elastic Stack 文档发布（docs release）流程。以 elastic/dev 中的 [Docs release] X.Y.Z issue 为唯一依据，而非工程 [Release] issue；负责从状态检查、PR 路由到 Slack 通知的整条链路。
主要能力：读取 ~/.elastic-docs/stack-release-state.json 会话状态并实时刷新；按 issue 复选框判断当前阶段（pre-release、等待发布基础设施、等待 RN、announced 等）；分类版本（patch/minor/major）；路由 PR——8.x/7.x 只动 elastic/docs，9.x 走 elastic/docs-builder 的 config/assembler.yml、config/versions.yml；处理同一 GA 下 9.x 版本的取代关系；检查 Release Notes 表格中各 PR 的合并状态；解决 stakeholder 归属；仅 9.x 监控 docs-internal-workflows 的 bump PR 与 prod version-bump 部署。
使用方式：$ARGUMENTS 为空格分隔的 semver 列表或 elastic/dev issue 编号（如 9.4.0 9.3.4 8.19.15 或 #1234）；为空时加载会话状态。常用命令包括 gh issue view <N> -R elastic/dev --json body,state、gh pr list -R elastic/docs-builder --search "<version>"、gh pr view <url> --json state,mergedAt,title、gh run list -R elastic/docs-internal-workflows --limit 20。文档 issue 缺失时用对应模板创建：gh issue create -R elastic/dev --template <template-file> --title "[Docs release] <version>"。Slack 消息需先读 slack-templates.md，发送前确认。
适用场景：Elastic 文档发布协调者处理多版本批次、状态巡检、RN PR 阻塞跟踪与发布通知。
限制：禁止混合同一 PR 中的 8.x 与 9.x；8.x/7.x 不使用 docs-internal-workflows；RN 合并不设复选框，必须逐个 gh pr view 验证；PR URL 在合并前始终视为阻塞，不按产品名豁免；9.x 发布前需生产 version-bump 成功且暂存未失败，并需用户目视检查网站后才能发送“已发布”消息；ID、日期、PR URL、@提及不得编造，缺失时以 (issue TBD) 或 [@handle] 标记并询问；RC 名称每次发布不同，须从协调线程或工程 issue 读取，不得硬编码。官方文档未提供收费、价格等信息。