| name | release-tag |
| description | Create a GitHub release with tag after a PR merge — follows the repo's tag and gh release create workflow |
| license | MIT |
| metadata | {"audience":"maintainers","workflow":"github"} |
What I do
Create a Git tag and GitHub release after a release PR has been merged to main.
When to use me
Use this skill only after a release PR has been merged to main and all CI checks have passed. Never use this before the PR is merged.
Pre-conditions
Before proceeding, verify ALL of these:
- The release PR is merged to
main
- CI passed on the merge commit
go test ./... -race passes locally on main
CHANGELOG.md has entries under the version being released
- No other release is in-flight
Workflow
-
Checkout and pull main:
git checkout main
git pull origin main
-
Determine version — read from CHANGELOG.md:
- Find the first
## [x.y.z] heading that isn't [Unreleased]
- The tag will be
v<x.y.z>
-
Verify the tag doesn't exist:
git tag -l "v<x.y.z>"
-
Build release notes from the CHANGELOG section for this version. Include:
- Summary of what changed
- Link to the upstream OpenClaw version if this is a sync release
- Link to the PR that was merged
-
Create the tag and release:
git tag v<x.y.z>
git push origin v<x.y.z>
gh release create v<x.y.z> --title "v<x.y.z>" --notes "<release notes>"
-
Verify the release:
gh release view v<x.y.z>
-
Close related issues — if there's an upstream-release issue, close it with a link to the release.
Version format
This project uses semantic versioning:
- Patch (
x.y.Z) — bug fixes, test improvements, doc updates
- Minor (
x.Y.0) — new features (new RPC methods, new packages), backward compatible
- Major (
X.0.0) — breaking changes to exported API (should be rare)
Rules
- Never create a tag from an unmerged branch
- Never create a release without passing tests
- Never skip the CHANGELOG — if there's no entry, something was missed
- One release per merged PR — do not batch
- The docs-deploy workflow triggers automatically on
v* tags