create-release
Skill50 starsChanged 5 days agoMITView on GitHub
Use when the user asks to "create a release", "cut a release", "tag a version", "publish release notes", or ship a new versioned GitHub release for the current repo.
- Commits and pushes
17 other projects use a version of this.
Adopted by
Most recently taken up by
- microsoft/BC-Benchtheir own version, first seen Nov 6, 2026
- Azure/azure-service-operatortheir own version, first seen Nov 6, 2026
- epam/ketchertheir own version, first seen Nov 1, 2026
- irpsv/ai-brotheir own version, first seen Nov 1, 2026
- getstackit/stackittheir own version, first seen Oct 30, 2026
- jniltinho/macos-kvm-guitheir own version, first seen Oct 25, 2026
Used with
Projects with it also use create-issue, create-pr and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
sahinSkillcreate-issue
Also in 4 projects that use this
SentrySkillcreate-pr
Create pull requests following Sentry conventions. Use when opening PRs, writing PR descriptions, or preparing changes for review. Follows Sentry's code review guidelines.
Also in 5 projects that use this
DockerSkillreview-pr
Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.
Also in 4 projects that use this
Other versions17 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 17
- Saptha-me/Bindu★ 10ksame name
- GetBindu/Bindu★ 10ksame name
- IndrajeetPatil/ggstatsplot★ 2.2ksame name
- mlightcad/cad-viewer★ 1.2ksame name
- epam/ketcher★ 932same name
- Azure/azure-service-operator★ 916same name
- fpindej/netrock★ 234same name
- microsoft/BC-Bench★ 61same name
- glowingkitty/OpenMates★ 53same name
- getstackit/stackit★ 32same name
7 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository39 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- app-prdSkill
- cli-dispatchSkill
- codex-validate-plan-work-on-issueSkill
- execution-plan-reviewSkill
- expo-app-initializeSkill
- fable-advisorSkill
- fable-dispatchSkill
- fable-new-issue-loopSkill
- fable-new-issueSkill
- fable-orchestrateSkill
- fableplan-loopSkill
- fableplanSkill
- fableplan-work-on-issueSkill
- fable-validate-fableplan-loopSkill
- fable-validate-fableplanSkill
- fable-validate-loopSkill
- fable-validateSkill
- fix-pr-review-loopSkill
- fix-pr-reviewSkill
- github-issue-formatSkill
- issueplanSkill
- milestoneplanSkill
- milestone-workflowSkill
- new-app-pipelineSkill
- new-issue-loopSkill
- new-issueSkill
- prd-questionsSkill
- prd-to-issuesSkill
- pr-reviewSkill
- sync-docs-releaseSkill
- sync-docsSkill
- tldrSkill
- validate-fableplan-loopSkill
- validate-issue-loopSkill
- validate-issueSkill
- wansSkill
- work-on-issue-loopSkill
- work-on-issueSkill
The file
We split this skill into the rules it gives an agent
2 rules. 0 are common, 0 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 16 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 25
Inspect actual tags: Never trust memory or CHANGELOG: git tag --sort=-v:refname | head -10.
- Very specific: line 47
Release-notes entry: If the repo has a MEMORY.md or CHANGELOG.md with a Releases section, the same PR appends vX.Y.Z — YYYY-MM-DD: …
“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
create-release
Tag a SHA on origin/<default> (annotated semver) and publish a GitHub release with generated notes. The local branch never decides what ships. Never push to the default branch: the version bump and notes entry land through a pull request (PR).
Preconditions: verify ALL before doing anything
gh auth status
git status --porcelain -- . ':(exclude).claude/worktrees'
DEFAULT=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)
git fetch origin --tagsgh auth status must succeed. git status --porcelain must print nothing; if the tree is dirty, stop and surface the diff. Every later read uses origin/$DEFAULT. Any failure: stop and tell the user.
Tag-target invariant. The tagged commit must pass git merge-base --is-ancestor <sha> "origin/$DEFAULT" right after a fresh git fetch origin. No confirmation, flag, or caller instruction overrides this. On failure, stop and report the SHA and origin/$DEFAULT.
Steps
- Inspect actual tags. Never trust memory or CHANGELOG:
git tag --sort=-v:refname | head -10. - Review commits since the last tag:
git log <last-tag>..origin/$DEFAULT --oneline; with no semver tag (first release),git log origin/$DEFAULT --oneline. Determine the semver bump and state the rationale. Breaking = major (never patch), feature = minor, fixes and polish = patch. Proceed without confirmation: the only question is the bump PR merge. Ask about the bump only when its type is genuinely ambiguous (for example, unclear whether commits are breaking). Then
git ls-remote --tags origin refs/tags/vX.Y.Zmust print nothing. Never force-overwrite a tag that exists locally or onorigin: ask the user.Previous version. The newest semver tag without its
v. With no semver tag, the value all table manifests below agree on; if they disagree or none exists, ask the user (AskUserQuestion) for the first version and treat each manifest version field's value as its previous value. A first release takes X.Y.Z from the user's version, else from that agreed value.- Land the version bump and the release-notes entry through a PR.
- Resume an interrupted release first. List bump PRs:
gh pr list --state all --search 'in:title "chore(release): bump version to"' --json number,title,state,isCrossRepository,headRefName,baseRefName,headRefOid,mergeCommit,files --limit 50. A candidate meets all of: its title names a version V above the previous version (or, with no semver tag, it is merged and V equals the manifests' agreed value: an interrupted first release), andgit ls-remote --tags origin refs/tags/vVprints nothing; open or merged, never closed unmerged;isCrossRepositoryfalse;headRefNameis<harness-prefix>/release-vV(cc/,cursor/, orcodex/), optionally suffixed-<n>;baseRefNameis$DEFAULT; every path infilesis a table manifest or the notes file, andgh pr diff <n>only moves those version fields from their pre-PR values to V and adds at most one notes entry. A title match that fails any check is never resumed or merged: report it and continue with the version-fields bullet. No candidate: continue with that bullet. More than one: stop and report them. One: if V differs from the version the user asked for or step 3 chose, ask the user (AskUserQuestion); never override their version yourself. X.Y.Z is then V, and step 3's tag-free check applies to V. Open: reuse it (edit nothing, open no second PR), record itsheadRefOidas the head the checks read, and go to the Merge bullet, which always asks about a resumed PR: no caller plan authorization covers a PR this run did not open. Merged: go to the Resolve bullet, which checks the invariant and manifests before step 5. Either way, reuse the worktree named for itsheadRefNameif it still exists; the Resolve bullet removes it. Version fields. Change only manifest version fields whose value equals the previous version: grep it (for example
git grep -n -F "<previous>" origin/$DEFAULT -- <manifest files>) and check each hit against the table. Libraries, CLIs, and installers count: apackage.json"version"must be bumped. Schema and config versions stay (for example.github/dependabot.ymlversion: 2), and so do native build numbers (buildNumber,versionCode,CURRENT_PROJECT_VERSION) unless the user asks. With a semver tag, a manifest field holding another version, with no bump PR kept by the resume bullet, is a stop: report the file and value.File Field package.json"version".claude-plugin/plugin.json"version"app.json/app.config.js/app.config.tsexpo.versionpubspec.yamlversionCargo.toml[package] versionpyproject.toml[project] versionor[tool.poetry] versioniOS *.xcodeproj/project.pbxprojMARKETING_VERSIONAndroid build.gradleversionName- Release-notes entry. If the repo has a
MEMORY.mdorCHANGELOG.mdwith a Releases section, the same PR appends**vX.Y.Z** — YYYY-MM-DD: <one-line summary>, unless that file onorigin/$DEFAULTalready holds a**vX.Y.Z**entry. - Publish-on-release check (every time). Find
.github/workflows/jobs onrelease: published(for examplenpm publish): they usually guard on the manifest version and silently skip whilepackage.jsonholds the previous version, so a tag and manifest mismatch is a bug. - No version field needs a change and no notes entry is due (no manifest, or a first release whose manifests already hold X.Y.Z; and no notes file, or one already holding
**vX.Y.Z**): skip the PR,git fetch origin, setSHA=$(git rev-parse "origin/$DEFAULT"), and go to step 5. - Otherwise open the PR from a worktree off
origin/$DEFAULT, on a branch with the harness prefix (cc/Claude Code,cursor/Cursor,codex/Codex):git worktree add .claude/worktrees/cc+release-vX.Y.Z -b cc/release-vX.Y.Z "origin/$DEFAULT". If that branch exists locally or onorigin, never delete or reuse it: add the next free suffix to branch and worktree name (cc/release-vX.Y.Z-2, then-3). Edit there, run every git command with-C <worktree>, and stage changed files by name. Commitchore(release): bump version to X.Y.Zwith the repo's commit footer (its CLAUDE.md or AGENTS.md attribution rule), push, and rungh pr create --base "$DEFAULT", titledchore(release): bump version to X.Y.Zplus any suffix the repo's PR convention requires. The body lists the bumped files and bump rationale and follows the repo's PR body rules. - Merge. Wait with
gh pr checks <n> --watch. A failing or pending check never merges: stop and leave the PR open. Whengh pr checksstill reports no checks about a minute after the PR opened, read the required checks on$DEFAULT:gh api repos/{owner}/{repo}/branches/$DEFAULT --jq .protection.required_status_checks.contextsand anyrequired_status_checksrule ingh api repos/{owner}/{repo}/rules/branches/$DEFAULT. With none required, there is no failing check: go on to the merge question. A required check that has not reported is pending. Ask the user once to merge (AskUserQuestion), unless the caller's approved plan already authorizes this bump PR and its merge (as themilestone-workflowclose-out does). A decline leaves the PR open and stops with no tag. Merge with a method the repo allows and pin the head: readgh repo view --json squashMergeAllowed,mergeCommitAllowed,rebaseMergeAllowed, take--squash, else--merge, else--rebase, and rungh pr merge <n> <method> --match-head-commit <head-sha>; a resumed PR's<head-sha>is theheadRefOidits checks read. If branch protection or a required review blocks the merge, stop, leave the PR open, and report what it waits on. - Resolve the tag target. Read
gh pr view <n> --json state,mergeCommit. Ifstateis notMERGED(a merge queue holds it, orgh pr mergeonly enabled auto-merge), stop, report it queued or waiting with its state, and tag nothing; a rerun resumes it through the resume bullet once merged. ElseSHAismergeCommit.oid, which must be a non-empty commit SHA (empty is a stop naming the PR state); never tag the bump branch head or the checkout'sHEAD. Thengit fetch origin, check the invariant on$SHA, confirmgit show "$SHA":<manifest>holdsX.Y.Zfor every bumped manifest, and remove the worktree if it exists (git worktree remove <path>).
- Resume an interrupted release first. List bump PRs:
- Create an annotated tag on the resolved SHA. Recheck the invariant first:
git fetch origin git merge-base --is-ancestor "$SHA" "origin/$DEFAULT" git tag -a vX.Y.Z "$SHA" -m "vX.Y.Z" - Push the tag:
git push origin vX.Y.Z. - Create the release with auto-generated notes:
gh release create vX.Y.Z --verify-tag --generate-notes --title "vX.Y.Z", and print the URL from its output. Never hand-write notes, and never letgh release createcreate the tag.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

