release-please 技能用于在仓库中设置自动化发布流程。在开始之前，需要确认以下信息（若上下文中不明确应向用户询问）：使用什么语言/框架（决定 release-type）、是单包还是 monorepo、包当前的版本号。
主要能力
该技能能够指导创建 GitHub Actions 工作流（.github/workflows/release-please.yml），使用 googleapis/release-please-action@v4 在推送到 main 分支时自动运行。工作流需要 contents: write 与 pull-requests: write 权限。它会根据 conventional commits 创建 Release PR，合并后生成 GitHub Release。
使用方式
基本设置步骤包括：创建 GitHub Actions 工作流；对于 monorepo 或自定义配置，改为创建 manifest 文件（release-please-config.json 与 .release-please-manifest.json），并在工作流中省略 release-type 输入。
对于已有历史的仓库，需要在 .release-please-manifest.json 中设置与最新发布标签一致的当前版本；若提交历史很长，可在配置中添加 bootstrap-sha 来限制 changelog 范围。
与 GoReleaser 的统一工作流
当项目同时使用 release-please 与 GoReleaser 时，推荐使用单个工作流文件：先运行 release-please，仅当 release_created 为 true 时再运行 GoReleaser。这样可以避免常见的 PAT 变通方案，无需为了触发第二个工作流而使用自定义的 RELEASE_PLEASE_TOKEN。
常见配置模式
Node.js 包使用 release-type: node，更新 package.json 与 CHANGELOG.md；Python 包使用 release-type: python，更新 pyproject.toml/setup.py 与 CHANGELOG.md；Go 模块使用 release-type: go，仅更新 CHANGELOG.md（版本来自标签）；monorepo 使用包含多个包的 manifest 配置，可考虑 node-workspace 或 cargo-workspace 插件。
设置后检查清单
需要提示用户：提交并推送新文件；开始使用 conventional commits（feat:、fix:、feat!:）；对 PR 使用 squash-merge（以获得更整洁的 changelog）；在出现可发布提交后，release-please 会创建 Release PR；合并 Release PR 即可创建 GitHub Release。
限制与补充
该技能引用了若干参考文件，包括 release-types.md（支持的语言）、github-actions.md（Action 输入、输出、示例）、manifest-config.md（完整配置选项、插件、monorepo）、release-please-goreleaser-unified-workflow.md（release-please 与 GoReleaser 的标准组合设置）。若 CI 需要在 release PR 上运行，用户需要为该 PR 触发行为配置 PAT，但这不应作为 release-please 与 GoReleaser 集成的默认修复方式，应优先采用上述统一单工作流模式。具体支持的完整语言列表、各输入输出细节与插件配置，见对应参考文件（资料中未展开全部内容）。