release-please
Setting Up Release-Please
This skill guides you through setting up release-please in a repository.
Before You Start
Ask the user (if not clear from context):
- What language/framework? (determines
release-type) - Single package or monorepo?
- Current version of the package(s)?
Setup Steps
1. Create GitHub Actions Workflow
Create .github/workflows/release-please.yml:
on:
push:
branches: [main]
permissions:
contents: write
pull-requests: write
name: release-please
jobs:
release-please:
runs-on: ubuntu-latest
steps:
- uses: googleapis/release-please-action@v4
with:
release-type: <type> # See references/release-types.md
Unified release-please + GoReleaser workflow (recommended when both are used)
If the project uses both release-please and GoReleaser, prefer a single workflow file. Run release-please first, then run GoReleaser only when release_created is true.
This avoids the common PAT workaround. You do not need a custom RELEASE_PLEASE_TOKEN just to trigger a second workflow for GoReleaser.
For the canonical recipe, see references/release-please-goreleaser-unified-workflow.md.
name: release-please
on:
push:
branches: [main]
permissions:
contents: write
pull-requests: write
packages: write
jobs:
release-please:
runs-on: ubuntu-latest
outputs:
release_created: ${{ steps.release.outputs.release_created }}
tag_name: ${{ steps.release.outputs.tag_name }}
steps:
- id: release
uses: googleapis/release-please-action@v4
with:
release-type: <type>
goreleaser:
needs: release-please
if: ${{ needs.release-please.outputs.release_created == 'true' }}
runs-on: ubuntu-latest
permissions:
contents: write
packages: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
ref: ${{ needs.release-please.outputs.tag_name }}
- uses: actions/setup-go@v5
with:
go-version-file: go.mod
- uses: goreleaser/goreleaser-action@v6
with:
version: latest
args: release --clean
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
If the user needs CI to run on release PRs (common), they need a PAT for that PR-triggering behavior:
with:
token: ${{ secrets.RELEASE_PLEASE_TOKEN }}
Do not use this PAT requirement as the default fix for release-please + GoReleaser integration. Prefer the unified single-workflow pattern above.
2. Create Config Files (for advanced setups)
For monorepos or custom config, create manifest files instead of using release-type input.
release-please-config.json:
{
"packages": {
".": {
"release-type": "<type>"
}
}
}
.release-please-manifest.json:
{
".": "<current-version>"
}
Then update the workflow to omit release-type:
- uses: googleapis/release-please-action@v4
with:
token: ${{ secrets.RELEASE_PLEASE_TOKEN }}
3. Bootstrap Existing Repository
For repos with existing releases, set the current version in .release-please-manifest.json to match the latest release tag.
If there's extensive commit history, add bootstrap-sha to config to limit changelog scope:
{
"bootstrap-sha": "<commit-sha-before-first-desired-commit>",
"packages": { ... }
}
Common Setup Patterns
Node.js Package
release-type: node- Updates
package.jsonandCHANGELOG.md
Python Package
release-type: python- Updates
pyproject.toml/setup.pyandCHANGELOG.md
Go Module
release-type: go- Updates
CHANGELOG.mdonly (version from tags)
Monorepo
- Use manifest config with multiple packages
- Consider
node-workspaceorcargo-workspaceplugins - See
references/manifest-config.md
Post-Setup Checklist
Tell the user:
- Commit and push the new files
- Start using conventional commits:
feat:,fix:,feat!: - Use squash-merge for PRs (cleaner changelogs)
- Release-please will create a Release PR after releasable commits
- Merge the Release PR to create the GitHub release
Reference Files
Read these for detailed options:
references/release-types.md- All supported languagesreferences/github-actions.md- Action inputs, outputs, examplesreferences/manifest-config.md- Full config options, plugins, monoreposreferences/release-please-goreleaser-unified-workflow.md- Canonical combined setup for release-please + GoReleaser
More from aaronflorey/agent-skills
amber-lang
Write, debug, and explain Amber code, the `amber` language that compiles `.ab` files to Bash. Use this skill when the user asks to write an Amber script, convert Bash to Amber, compile Amber to Bash, debug Amber syntax or type errors, or asks about Amber 0.5.1-alpha syntax, functions, types, error handling, the standard library, or the `amber` CLI.
26go-cobra
Write, scaffold, and debug Go CLI applications with `github.com/spf13/cobra`. Use this skill whenever the user mentions Cobra, `cobra.Command`, a Go command-line app, subcommands, persistent or local flags, required flags, argument validation, shell completions, generated docs, or wants to build or refactor a cobra-based CLI.
24laravel-actions
Write, scaffold, explain, and refactor code using the `lorisleiva/laravel-actions` package. Use this skill whenever the user mentions Laravel Actions, `AsAction`, `php artisan make:action`, action classes, converting a controller, job, listener, or command into an action, dispatching an action as a job, using an action as a controller or listener, or adding validation, authorization, testing, or mocking around an action.
24num30-config
Write, debug, and explain Go configuration code using `github.com/num30/config`. Use this skill when the user mentions `num30/config`, wants config structs, file plus env plus CLI flag loading, validation, config watching, precedence rules, or asks how to integrate the num30/config package into a Go application.
22pelican-panel-plugins
Write, scaffold, explain, and debug plugins for the Pelican gaming panel. Use this skill whenever the user mentions Pelican plugins, extending Pelican, FilamentPHP resources or pages for Pelican, plugin service providers, custom permissions, plugin settings, routes, models, widgets, or asks how to add new functionality to the Pelican panel.
21go-viper
Write, debug, and explain Go configuration code with `github.com/spf13/viper`. Use this skill whenever the user mentions Viper, `viper`, config structs, reading config from files plus env vars plus flags, Cobra or `pflag` integration, unmarshaling into structs, env key replacers, config precedence, config watching, or a clean Viper bootstrap.
20