version-release

version-release documents the LobeHub version release workflow — the release branch/PR process, CI trigger rules, and GitHub Release note authoring. It solves the problem of running a consistent, automation-friendly release: development happens on the canary branch, which is merged into main, after which the auto-tag-release.yml workflow handles tagging, version bumping, GitHub Release creation, and syncing main back to canary. The skill acts as a router that delegates detailed steps to reference files. It is explicitly scoped away from writing website changelog pages (docs/changelog/*.mdx), which are handled by a separate docs-changelog skill.

It covers two practical release types — minor (feature iteration, ~every 4 weeks, strict PR title 'release: v{x.y.0}') and patch (weekly/hotfix/model/DB-migration, auto patch +1) — and documents the exact auto-release trigger priority: exact-version minor titles, branch-name matches (hotfix/*, release/*) or title-prefix matches for patch, and non-triggering prefixes (docs, chore, ci, test). Hard rules forbid manually editing package.json versions or creating tags (CI owns both). A strong theme is factual accuracy of release notes: PR numbers, compare bases, metrics, and contributor handles must all be derived from git and gh commands (git describe, git log, gh pr view) rather than memory, with a mandatory pre-publish verification step diffing body PR refs against the canonical computed set to prevent hallucinated references.

It targets LobeHub maintainers and release managers producing releases and GitHub Release notes. The commands it uses are standard, read-oriented git and gh operations for computing release facts.