ln-63-release-publisher

发布版本

目标： 准备可复现的发布流程，并且仅在用户批准确切的标签和说明后发布。

执行约定： 按顺序排列的复选框即为完成定义。内部跟踪每一项的状态：PENDING、有具体证据支持的 PROVEN、有证据证明相关条件不存在的 CLEARED，或存在缺口的 UNPROVEN；阅读、委派或工具故障都不构成证据。每完成一个部分后都要重新核对各项。返回前，解决所有 PENDING 项，仅统计 PROVEN 和 CLEARED 项；根据本技能的判定和审批规则处理所有缺口。 遵循用户意图、范围和现有授权。继续已获授权的工作；仅针对尚未解决且会产生重大影响的选择或必需的外部审批进行询问。根据实质风险调整审查深度，不得悄悄跳过检查。遵循依赖关系和安全顺序；其他情况下，为每项义务选择合适的验证方法。

工具路由

需求	首选能力	备用方案
发布边界和提交证据	Git 历史记录、标签和差异	托管平台 API 提交比较
现有发布风格和状态	已通过身份验证的 GitHub CLI 或连接器	只读证据的公开 GitHub API
发布标识和版本范围	仓库策略、既往标签，以及存在时的规范版本文件	仅在发布标识仍有歧义时停止
发布验证	仓库原生检查和干净检出	手动结构检查，但置信度较低
创建标签和 GitHub Release	Git 加已通过身份验证的 GitHub 发布能力	BLOCKED；不得通过文件模拟发布状态
安装验证	在隔离环境中使用文档说明的分发源进行验证	仅进行干净源代码验证，不算安装证明

通过 Shell 发布时，使用临时说明文件，避免 Markdown、引号和代码块被重新解释。将凭据保存在主机凭据存储中，绝不回显凭据。

如果仓库策略和以往可比发布已能解答问题，就不要为寻求通用发布建议而浏览网页。仅在需要确认当前 API 或 CLI 行为时，使用托管平台的官方文档。

检查清单

确定范围并收集证据

• 确认用户明确要求发布，并确定仓库、发布目标和目标受众。
• 在选择版本、标签格式、文件或发布顺序前，阅读仓库的发布规则。
• 验证已通过身份验证的 GitHub 发布能力、仓库访问权限和创建发布的权限。
• 要求工作区干净，或明确排除无关变更后再准备发布。
• 获取标签和目标分支；确认本地 HEAD 与远程发布分支同步。
• 确定本次发布线的上一个发布边界；首次发布时，使用约定的初始历史边界并明确标注。
• 检查从上一个发布边界到拟发布提交之间的提交及完整提交正文。
• 阅读受影响的清单文件、权威文档、安装说明、已配置的目录，以及存在时面向用户的迁移说明。
• 将提交和源代码差异作为证据；仅将现有发布说明作为辅助背景信息。

版本与范围

• 遵循仓库声明的版本管理政策；若未指定，则不要强行采用 CalVer、SemVer 或统一的目录版本。
• 如果发布目标或标签含糊不清，请暂停并询问，而不是自行设定惯例。
• 在本地和远程检查拟定的标签。对于恢复进行中的已批准发布，继续操作前请核实其确切目标和现有发布状态；否则，遇到冲突时应将其视为阻碍，绝不可覆盖。
• 仅在仓库说明指定的规范字段中准备版本变更；在提案获批前，保持这些变更为本地状态且便于审查。
• 仅更新纳入本次发布的软件包、插件或组件；不要为了视觉一致性而提升无关清单的版本。
• 除非本次发布明确推进其版本，否则应让新的分发单元保持已批准的初始版本。
• 确保标签、发布标题和说明描述的是同一个发布单元；只有纳入该单元的带版本清单才需要与版本号保持一致。
• 在仓库要求的迁移说明中记录会造成安装或行为中断的变更。

发布说明

• 阅读最近的可比发布说明，在不照搬过时结构的前提下沿用有用的惯例。
• 按用户获得的结果对变更分组，而不是按文件列表或内部实现时间顺序分组。
• 先说明本次发布的重要意义，再陈述用户将获得的具体行为。
• 只有在根据当前权威文档和适用的分发元数据核实后，才提供准确的安装或更新命令。
• 为每项已确认的破坏性变更提供迁移步骤，并明确区分旧行为和新行为。
• 明确说明已移除的行为；不要把移除说成简化。
• 通过核实的用户名向外部贡献者致谢；如果是个人独立完成的工作，则省略贡献者部分。
• 链接到发布提交中实际存在的权威文档和仓库路径。
• 不要作出无法复现的采用情况、性能、兼容性或数量方面的声明。
• 区分实测事实、解读和未来意图。

验证与批准

• 运行仓库的所有发布门禁，以及现有产品、软件包、插件、技能或市场平台相关的检查。
• 如果存在多个宿主目录，且仓库政策要求保持一致，请确认它们仍然对齐；除非迁移已获批准，否则保留所有稳定的分发标识符。
• 如果安装方式发生变化，请在批准前验证拟议树的精确隔离快照，并注明其基线和补丁；提交后，确认发布提交包含该已验证的树。
• 记录命令、版本、退出代码和跳过的检查，同时避免泄露机密。
• 提供确切的版本变更、标签、标题、完整说明、验证证据和计划执行的命令。
• 在提交版本变更、创建标签或发布之前，等待用户明确批准这份确切提案。
• 只要版本变更、目标、标签、标题和说明与已批准的内容完全一致，就可沿用该批准；发布内容如有变更，须在发布前重新提交审批。

发布

• 将准备好的元数据和文档与已批准的提案核对；应用任何尚未完成的已批准修改，并排除无关更改。
• 确认必需的发布门禁覆盖最终批准的树；仅重新运行因最终修改而失效的检查或尚未解决的失败项。
• 按照授权的分支工作流提交并推送发布提交。
• 创建标签前，确认发布提交上的必需 CI 检查均已通过。
• 创建指向已验证提交的附注标签或仓库标准标签，并在不使用强制推送的情况下推送。
• 从包含已批准说明的文件创建 GitHub Release，以保留 Markdown 格式并确保 shell 安全。
• 通过托管平台 API 验证已发布的标签、目标提交、标题、正文和发布 URL。
• 如果发布内容更改了安装入口，请从仓库文档所述的发布源或分发源测试安装或更新流程。
• 除非另行授权，否则不要发布 npm、PyPI、NuGet、容器或其他软件包。
• 不要将发布社区公告作为默认的附带操作。

故障处理

• 在公开打标签前，诊断故障并在范围内修正有限的准备缺陷；仅当提案未变更时才复用审批。若前置条件尚未解决，则停止并保留确切状态。
• 如果标签发布或 Release 创建返回的结果不确定，请先检查远程标签和 Release 的标识，再重试。报告部分完成的状态，并仅继续执行尚未完成的已批准操作；切勿创建重复内容或覆盖冲突内容。
• 未经明确批准，绝不删除或移动已发布的标签。
• 绝不覆盖现有 Release，也绝不通过强制操作掩盖有问题的发布提交。

结论

• RELEASED — 标签和 GitHub Release 均指向已验证的提交，且远程检查通过。
• READY — 提案和证据均已完备，但发布仍待批准。
• PARTIAL — 存在对外可见的发布状态，但验证或后续步骤失败。
• BLOCKED — 无法安全地继续发布。

自检

• 返回前先核对。 检查各项证据、需求覆盖情况、矛盾、范围、结论以及适用的清理工作。更正报告或已获授权的产物。复用有效证据；不要自动重新扫描仓库或重新运行已成功的命令。仅因相关更改、失败或未解决的证据而重复检查。披露仍存在的缺口。

输出约定

按以下顺序使用用户的语言报告；保留全部五个字段，并且每项事实只陈述一次。简短结果可以每个字段占一行；省略空表格，不要复制已链接的产物：

1. 结果： 技能专属结论及有证据支持的结果。
2. 范围： 已审查/更改的范围、排除项、基线和重要假设。
3. 证据： 下方列出的技能专属字段；区分事实、推断和未经验证的声明。链接产物；必要时使用表格。
4. 验证： 检查及结果、无法获取的证据，以及适用的清理工作/外部状态。
5. 完成情况： Checklist: X/Y complete；Incomplete: None，或列出每项 UNPROVEN 的原因、对结果的影响及确切的后续操作；以及剩余风险和待定决策。

技能专属证据： 发布范围、规范版本变更、标签/提交、标题、审批前的完整拟议说明或发布后的 URL、验证证据和发布状态。对于 PARTIAL，逐一列出所有对外可见的对象，以及删除、移动或替换这些对象所需的批准。