菜单
Prepare a tagged release with consistent release notes, a SemVer version bump, and a copy-pasteable gh release command. Use when cutting a release, drafting a changelog, tagging a version, or the task mentions "release", "changelog", "version bump", "tag", or "publish a new version".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | git-release |
| description | Prepare a tagged release with consistent release notes, a SemVer version bump, and a copy-pasteable gh release command. Use when cutting a release, drafting a changelog, tagging a version, or the task mentions "release", "changelog", "version bump", "tag", or "publish a new version". |
| license | MIT |
| compatibility | opencode |
| metadata | {"audience":"maintainers","workflow":"github"} |
Turn a set of merged changes into a clean, tagged release: collect what
changed, pick the right version, and produce the exact commands to cut it.
Pairs well with the gh-cli and conventional-commits skills.
git tag and gh release create commands.Use this when you are preparing a tagged release, drafting a changelog, or the user asks to "cut a release", "bump the version", or "publish a new version".
git fetch --tags --force
git describe --tags --abbrev=0 # most recent tag, e.g. v1.3.0
git log <last-tag>..HEAD --oneline # commits since that tag
If there is no prior tag, use the repository's first commit as the baseline
(git log --oneline) and start at v0.1.0 (or v1.0.0 for a first stable
release).
Inspect the Conventional Commit types since the last tag and pick the highest applicable bump:
| Found in the range | Bump |
|---|---|
any BREAKING CHANGE / ! marker | major |
any feat: | minor |
only fix: / perf: / refactor: / docs: / ... | patch |
MAJOR.MINOR.PATCH — incrementing major resets minor and patch to 0;
incrementing minor resets patch to 0. Pre-1.0 projects may treat feat as
patch and BREAKING CHANGE as minor — match the project's existing cadence.
Group changes by type, newest first, and link PRs/issues:
## v1.4.0 — 2026-01-15
### Features
- add OAuth2 device-code login (#123)
### Fixes
- guard against null user before serializing (#130)
### Docs
- clarify skill auto-discovery paths (#128)
Prefer letting GitHub generate a first draft, then edit it:
gh release create v1.4.0 --generate-notes --draft
--generate-notes builds notes from merged PRs and the configured
.github/release.yml categories; --draft lets you review before publishing.
# Annotated tag on the release commit
git tag -a v1.4.0 -m "v1.4.0"
# Push the tag to the remote
git push origin v1.4.0
# Create the GitHub release (the tag is created if it does not exist yet)
gh release create v1.4.0 --title "v1.4.0" --notes-file RELEASE_NOTES.md
# or attach build artifacts:
gh release create v1.4.0 ./dist/*.tar.gz --title "v1.4.0" --generate-notes
For alpha/beta/rc releases, use --prerelease and SemVer pre-release labels:
gh release create v2.0.0-beta.1 --prerelease --title "v2.0.0-beta.1" --generate-notes
Before publishing, verify the release will look right:
gh release create v1.4.0 --generate-notes --draft # draft first, review in browser
gh release view v1.4.0 --json tagName,name,body # inspect before publishing
Note: some sandboxed environments cannot run git push. In that case push the
tag/commits via the available PR / report-progress workflow rather than
git push --tags directly.
gh release view v1.4.0
gh release list --limit 5
gh release create / gh release delete as mutating; confirm the
target repo (-R OWNER/REPO) and tag before running.package.json) in agreement.Manage agent skills with gh skill. Use this skill to discover, preview, install, update, and publish Agent Skills so an agent can self-manage the skills available in its environment.
Patterns for invoking the GitHub CLI (gh) from agents. Use when the task mentions GitHub, gh, pull requests/PRs, issues, releases, gists, Actions/workflow runs, forks, repo cloning, reviews, or you need exact gh commands. Covers structured output, pagination, repo targeting, search vs list, issue types/sub-issues/discussions, projects, rulesets, and gh api fallback.
Token-frugal, multi-dimension code review for a diff/branch/PR. Use when reviewing changes, checking a PR, running a review→fix loop, or the task mentions "code review", "review my changes", "review this PR", "找 bug", "审查代码". Scales review depth to diff size, reports findings by dimension and severity, and calibrates against the project's threat model to avoid severity inflation. Reports findings; never rewrites code unless explicitly asked.
Run a lightweight, spec-driven change workflow — capture WHY/WHAT in a proposal, define WHAT the system does in specs, decide HOW in a design, break work into a tasks checklist, implement, then archive. Use when the task is a non-trivial feature or behavior change that benefits from durable, git-tracked planning artifacts, or when the request mentions "spec", "proposal", "propose a change", "spec-driven", "openspec", "design doc", "requirements", or "tasks checklist". Not for one-line fixes or pure Q&A.
Structured workflow for complex/heavy tasks that benefit from a review-gated, phased approach. Use when the task involves 3+ files, a major refactor, or architectural changes — or when the task mentions "deep work", "complex refactor", "multi-phase", "staged rollout". Creates durable artifacts (plan, verify, report) so the orchestrator can track progress across sessions.
Review recent work to identify recurring friction and propose minimal, durable improvements to the opencode config (agents, skills, commands, rules). Use when the user says "reflect", "what can we improve", "review our setup", "optimize the config", or after a series of related sessions reveals a pattern worth codifying.