release-status
概述
release-status 是一个用于诊断 release-please 发布流水线的技能，全程只读。它通过 gh 和 git 收集四项相互独立的信号，打印结构化报告，并针对每项信号给出修复建议。它不写入任何内容：不提交 commit、不打标签、不编辑 PR、不创建 release。
与 /send-it 的关系
它是 send-it 的兄弟技能，但并不由 send-it 调用。send-it 是合并前的交付流程，止步于 In Review（打开 PR、流转 Linear issue）。release-status 则接手合并之后的工作：检查 main 的状态、release PR 与标签，解释发布机制当前在做什么。两者互不调用。该技能可能在文字中提及 send-it（例如 /send-it 如何根据分支 commit 组合出 Conventional-Commit 风格的 PR 标题），但绝不会运行它。版本预览本身读取的是自上一个 tag 以来的 commit（排除 merge commit）——这正是 release-please 在多 commit 历史（R-824）下使用的逐 commit 信号，而非已合并 PR 的标题。
检查内容
信号一：版本预览。回答“origin/<mainBranch> 上自上一个 tag 以来各 commit 的 Conventional-Commit 主题会产生什么 bump 和版本？”规则：feat:→minor，fix:/perf:/revert:→patch，!/BREAKING CHANGE:→major；docs/chore/ci/refactor/test/build/style→none。取所有 commit 中最强的结果（排除 merge commit）。同一窗口内后又被 revert 的 feat: 仍意味着 minor——不做取消或抵消，与 release-please 保持一致。none 表示自上一个 tag 以来没有触发发布的提交落地，不会切出发布。
信号二：Release PR。回答“release-please--branches--main PR 是否打开，其必需检查（GO/NO GO）是否为绿色？”若打开且为绿色，编排器可以 squash-merge 它。若检查处于 pending/red，合并被阻塞——需要跟进该检查。若没有打开的 PR，说明 release-please 尚未打开（通常是因为没有触发发布的提交被合并，或流水线停滞——见下）。
信号三：陈旧的 autorelease: pending。回答“最后一个已合并的 release PR 是否仍带着 autorelease: pending 标签？”这是反复出现的停滞：当已合并的 release PR 仍保留该标签时，release-please 会中止下一次发布，流水线会静默停止触发。修复方式：从该 PR 上移除标签，然后重新运行编排器（或等待其 cron 触发）。
信号四：tag 与版本一致性。回答“是否已存在 v<package.json version> 标签？”这是 release.yml 的 version-vs-tag 门。标签存在 → 干净的空操作（该版本已发布）。标签缺失 → 该版本的发布处于待处理状态（门会在下一次 main push 时走发布路径）。
配置
配置文件 config.json 位于本文件旁边，使用受跟踪的 config.example.json 模板生成（运行时 config.json 按每个使用者生成，本身不受跟踪）。在运行开始时读取 config.json 并在整个过程中使用其值。请编辑你自己复制的 config.json 以匹配目标仓库。
键说明与默认值：
mainBranch：release-please 从中发布的干分支。默认 main。
releaseBranch：release-please 打开 release PR 的目标分支。默认 release-please--branches--main。
requiredCheck：编排器在合并 release PR 前轮询的必需状态检查的精确名称（含 emoji）。默认 GO/NO GO。
stalePendingLabel：release-please 在发布进行中给 release PR 打的标签；若它滞留在已合并的 PR 上即为陈旧。默认 autorelease: pending。
使用方法
运行随附的脚本。其路径相对于本技能自身目录（即包含本 SKILL.md 和 config.json 的目录）——应从那里解析，而不是从目标仓库根目录解析，否则会因为 ENOENT 而运行失败。
人类可读报告（默认）：
node scripts/release-status.mjs
机器可读 JSON（用于管道传给下一步）：
node scripts/release-status.mjs --json
显式指定仓库（当不在目标检出目录内运行时）：
node scripts/release-status.mjs --repo rheged-studio/agent-skills
自检——运行随附的离线断言（无网络、无 gh），是安装后确认脚本是否健康的快捷方式：
node scripts/release-status.mjs --self-test
--help（别名 -h）打印完整用法。
流程
第 1 步——确认前置条件。gh auth status 必须通过，且必须位于目标仓库内（或传入 --repo）。脚本通过 git 读取根 package.json 版本、本地标签，以及 origin/<mainBranch> 上自上一个 tag 以来的 commit，并通过 gh 查询打开的 release PR 和最后一个已合并 release PR 的标签。在信任版本预览前，确保 origin/<mainBranch> 是最新的（git fetch origin <mainBranch>）——脚本读取的是本地远程跟踪引用，而非实时 GitHub 查询。
第 2 步——运行脚本并读取四类信号。
node scripts/release-status.mjs
按顺序阅读每个区块：版本预览、release PR、陈旧的 autorelease: pending、tag 与版本一致性。脚本只获取并打印——运行它不会改变任何东西。
第 3 步——解读并建议（不要动手）。将信号映射为诊断。常见形态包括：“本该发布却没发”时，先检查陈旧 pending 区块——最后一个已合并 release PR 上滞留的 autorelease: pending 通常是元凶（release-please 会中止）。若该项正常，再检查版本预览是否为 none（没有触发发布的提交被合并），或 release PR 是否已打开但检查为红（卡在门上）。“下一个会切什么版本？”读取版本预览区块的 bump 与结果版本，none 表示不发布。“发布是否待处理？”读取一致性区块：缺失 v<version> 标签意味着下一次 main push 会走发布路径；存在标签则为干净空操作。
第 4 步——报告并给出修复建议。总结诊断并呈现脚本打印的修复建议，但不要执行——该技能仅作建议。针对陈旧 pending 停滞，修复方式是从已合并的 release PR 上移除标签并重新运行编排器；将其表述为推荐的下一步操作，交由人类（或具备写入能力的技能）执行。
重要规则
只读/建议性质。绝不移除标签、编辑 PR、推送标签或触发发布。收集、诊断、推荐——由人类或具备写入能力的工具执行动作。
不是 send-it 的一步。该技能永不被 send-it 调用，也永不调用它。它检查合并后的 main；send-it 止步于 In Review。
用证据，不猜测。报告脚本实际返回的内容。若 gh 失败（认证、限流、权限），报告该失败——绝不把“获取失败”当作“没有 release PR”或“没有停滞”。
镜像而非导入。为保持包的自包含（ADR-0001 self-containment），bump 规则在此重新实现；它们镜像 send-it 的 derive-bump.mjs 和 CLAUDE.md，但绝不触及兄弟技能。
错误处理
gh auth status 失败 → 停止并提示用户运行 gh auth login。
脚本以非零退出（限流、权限、GraphQL/REST 错误）→ 报告它；不要捏造信号。可回退到手动执行 gh pr list --state merged --head <releaseBranch> --json labels 来检查陈旧 pending 标签。
尚无标签（从未发布过的仓库）→ 版本预览会计入所有已合并 PR，一致性区块会报告首个 v<version> 标签待处理。这对引导式首次发布而言是预期行为。
参数
$ARGUMENTS