用途：deploy-release 用于为容器化应用创建 GitHub Release，支持 release-please 自动化与手动发布两种方式。适用场景包括从 main 分支切新版本并打标签、设置或审计 release-please 自动化与清单、发布手动 GitHub Release（含草稿与预发布），以及驱动容器化发布流水线中的版本标签环节。若需要为已部署服务生成交接文档，应改用 deploy-handoff；若需构建或加固容器镜像，应改用 container-development。
主要能力：技能会先读取上下文，包括 git remote、当前分支、最近标签、最近提交、release-please-config.json、.release-please-manifest.json 与 CHANGELOG.md 是否存在，再决定发布策略。若存在 release-please 配置，则走 release-please 流程：检查上次发布标签以来的约定式提交，查询带 autorelease: pending 标签的开放发布 PR，报告其状态与 URL，并说明合并该 PR 即可触发发布。若没有配置，则走手动流程：校验 VERSION 参数符合语义化版本格式，检查工作区是否干净（git status --porcelain），确认分支为 main 或 master，然后执行 gh release create v<VERSION> --title "v<VERSION>" --generate-notes，并按参数附加 --draft 或 --prerelease。
使用方式：参数从 $ARGUMENTS 解析，$1 为语义化版本字符串（如 1.2.0、v2.0.0-rc.1），可选 --draft 创建草稿、--prerelease 标记预发布。若用户要求设置 release-please，技能会创建 release-please-config.json（release-type 为 simple，含 packages、extra-files、changelog-sections）与 .release-please-manifest.json（初始版本 0.0.0），并建议添加 release-please GitHub Action 工作流，在 push 到 main 时运行 googleapis/release-please-action@v4，需 contents: write 与 pull-requests: write 权限。最后输出发布版本与 URL、发布 PR 状态及后续步骤。
限制：资料未提供该技能的收费、价格、平台支持范围或效果保证；手动发布依赖已安装并认证的 gh CLI，且要求工作区干净、分支为 main 或 master。release-please 流程不会直接创建发布，而是依赖约定式提交自动生成发布 PR，需人工合并后触发。