with one click
version-release
Version release workflow — release process and GitHub Release notes (not docs/changelog pages).
Version release workflow — release process and GitHub Release notes (not docs/changelog pages).
| name | version-release |
| description | Version release workflow — release process and GitHub Release notes (not docs/changelog pages). |
| disable-model-invocation | true |
| argument-hint | [minor|patch] [version?] |
This skill is a router. The detailed steps live in references/.
This skill is only for:
auto-tag-release.yml)This skill is not for writing docs/changelog/*.mdx.
If the user asks for website changelog pages, load ../docs-changelog/SKILL.md.
For every /version-release execution, you MUST load and apply:
../microcopy/SKILL.mdThe primary development branch is canary. All day-to-day development happens on canary. When releasing, canary is merged into main. After merge, auto-tag-release.yml automatically handles tagging, version bumping, creating a GitHub Release, and syncing back to the canary branch.
Only two release types are used in practice (major releases are extremely rare and can be ignored):
| Type | Use Case | Frequency | Source Branch | PR Title Format | Version | Reference |
|---|---|---|---|---|---|---|
| Minor | Feature iteration release | ~Every 4 weeks | canary | 🚀 release: v{x.y.0} | Manually set | references/minor-release.md |
| Patch | Weekly release / hotfix / model / DB migration | ~Weekly or as needed | canary or main | Custom (e.g. 🚀 release: 20260222) | Auto patch +1 | references/patch-release-scenarios.md |
For writing the release-note body (any release type), see references/release-notes-style.md.
auto-tag-release.yml)After a PR is merged into main, CI determines whether to release based on the following priority:
PR title matches 🚀 release: v{x.y.z} -> uses the version number from the title.
Triggered by the following priority:
hotfix/* or release/* -> triggers directly (skips title detection)style / 💄 stylefeat / ✨ featfix / 🐛 fixrefactor / ♻️ refactorhotfix / 🐛 hotfix / 🩹 hotfixbuild / 👷 buildPRs that don't match any conditions above (e.g. docs, chore, ci, test) will not trigger a release when merged into main.
package.json — commits 🔖 chore(release): release version v{x.y.z} [skip ci]v{x.y.z}sync-main-to-canary — syncs main back to canaryWhen the user requests a release:
Before creating the release branch, verify the source branch:
release/weekly-*): must branch from canarymain; run git merge-base --is-ancestor main <branch> && echo OKPick the right reference and follow it end-to-end:
references/minor-release.mdreferences/patch-release-scenarios.mdreferences/release-notes-style.mdpackage.json version — CI handles it.🚀 release: v{x.y.z}).git per references/release-notes-style.md § Computing Inputs — never from memory or descriptions.LobeHub React component conventions. Use when editing TSX UI, choosing base-ui vs @lobehub/ui vs antd, styling with antd-style, routing, desktop variants, layouts, or component state.
Agent runtime lifecycle hooks. Use for before/after tool or step hooks, tool mocks, human intervention, sub-agent calls, context compression, evals, tracing, callAgent, or lifecycle events.
Build or extend LobeHub Agent Signal pipelines. Use for signal sources, signal/action types, policies, middleware, workflow handoff, dedupe, scope behavior, or observability.
Agent tracing CLI for execution snapshots. Use for agent-tracing, traces, snapshots, LLM call inspection, context engine data, agent step analysis, or execution debugging.
Build LobeHub builtin tool packages. Use when adding agent-callable tools, manifests, executors, runtimes, inspectors, renders, placeholders, streaming, interventions, portals, or tool registries.
Build multi-platform chat bots with the chat SDK. Use for Slack, Teams, Google Chat, Discord, GitHub, Linear bots, webhooks, mentions, slash commands, cards, modals, or streaming responses.