원클릭으로
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 product design values / principles / checklists. Load this skill whenever the work touches user-interface features or implementation — designing or building any user-facing flow — to get better UX results.
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.
Vitest testing guide. Use when writing or updating tests, fixing failing tests, improving coverage, debugging test issues, or setting up mocks.
Agentic end-to-end testing for LobeHub: backend verification via the CLI, frontend verification via agent-browser (Electron), full-stack verification in the browser, and bot-channel verification via osascript. Local-first today, designed to extend to cloud automation. Triggers on 'cli test', 'test with cli', 'verify with cli', 'backend test with cli', 'local test', 'test in electron', 'test desktop', 'test bot', 'bot test', 'test in discord', 'test in telegram', 'test in slack', 'test in wechat', 'test in weixin', 'test in lark', 'test in feishu', 'test in qq', 'manual test', 'osascript', 'test report', or any local end-to-end verification task.
Audit .agents/skills SKILL.md files. Use for recurring checks of duplicate, overlapping, stale, inconsistent, or broken skills and merge/delete candidates.
Backfill and maintain model-bank metadata (knowledgeCutoff, family, generation). Use when adding models, fixing cutoff/family data, running a metadata sweep across aiModels providers, or researching official knowledge cutoffs.