用途：为带版本号的包、库、CLI 或市场插件搭建或统一 GitHub Actions 发布流水线，采用 push-to-main、语义化发布驱动的自增版本模式，仅发布环节因目标不同而变化。
主要能力：流水线含 verify 与 release 两个作业。verify 在 PR 和 push 上运行 lint、typecheck、test、build；release 仅在 push 到 main 且提交信息不含 [skip ci] 时运行，由 semantic-release 分析提交、打标签、创建 GitHub Release 与说明，发布到目标（npm、CocoaPods/SwiftPM、GoReleaser、GitHub Actions 市场标签、Homebrew tap），并通过 @semantic-release/git 把版本递增提交回 main 并带 [skip ci]。Rust 用 release-plz 替代 semantic-release，流水线形态相同。两个作业都以 fetch-depth: 0 检出；verify 用可取消的并发组，release 用独立不可取消组，避免两次发布竞争。
使用方式：确认 main 为发布分支、提交遵循 Conventional Commits、目标注册表存在发布令牌；选择发布目标；按参考文档编写 .github/workflows/ci.yml 的 verify 与 release 作业，加入发布配置（.releaserc.json、release.config.js 或 package.json 的 release 块）；在仓库设置中配置发布密钥（如 NPM_TOKEN、COCOAPODS_TRUNK_TOKEN、TAP_GITHUB_TOKEN）并按作业限定权限；为两个作业添加 [skip ci] 短路判断；设置机器人身份（GIT_AUTHOR_NAME/GIT_COMMITTER_NAME 及邮箱），使递增提交归属发布机器人；端到端验证 PR（仅 verify）→ 合并 feat:/fix: → 观察 verify→release → 确认标签、GitHub Release、发布产物和 main 上的 chore(release): … [skip ci] 提交。示例工作流使用 actions/checkout@v5 与 cycjimmy/semantic-release-action@v4。
限制与护栏：每个仓库只保留一条发布流水线，已有的基于标签的兜底工作流需说明原因，不要静默引入第二条；verify 是唯一发布门禁，不要把护栏移入 release 作业、不要用 workflow_dispatch 绕过、不要弱化 needs: [verify]；递增提交必须由机器人撰写、含 [skip ci]、被两个作业的 if 守卫识别，否则会无限触发流水线。资料未提供具体价格、平台支持范围之外的信息。