Github make release

Skill mtzanidakis/skills/skills/github/github-make-release

Personal collection of Claude Code skills for daily-use workflows

Install

npx -y skills add mtzanidakis/skills --skill github-make-release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when the user wants to cut a new GitHub release on the current repo. Triggers include "create a release", "cut a release", "make a release", "tag <version>", "publish vX.Y.Z", "ship a release". Tags the default branch and publishes a GitHub Release whose notes are auto-generated from commit history since the previous tag. Always shows draft notes for confirmation before publishing. Never overwrites an existing tag.

SKILL.md

3.2 KB, 709 tokens by cl100k_base, as published. Nobody here has run it

Make a GitHub Release

Given a user-supplied version, create both a git tag pushed to the remote and a GitHub Release with auto-generated notes.

Assume gh is authenticated and the working directory is a clone of the target repo.

Workflow

Get the version from the user if not supplied. Match the format of existing tags:
```
git tag --sort=-v:refname | head
```
If the repo uses vX.Y.Z, follow that; if it uses bare X.Y.Z, follow that. Don't mix.
Verify the tag doesn't already exist:
```
git rev-parse "<version>" 2>/dev/null && echo "EXISTS"
```
If it exists, stop and ask the user. Never overwrite a tag.
Find the previous release tag for the diff base:
```
gh release list --limit 1 --json tagName -q '.[0].tagName'
```
Fall back to the latest git tag if no GitHub Releases exist:
```
git describe --tags --abbrev=0
```
If neither exists, this is the first release — use the root commit (git rev-list --max-parents=0 HEAD) as the base.
Generate release notes from the commit log:
```
git log <previous-tag>..HEAD --pretty=format:"%s (%h)" --no-merges
```
Then format:
- Group by conventional-commit prefix when present: Features (feat:), Fixes (fix:), Dependencies (chore(deps):, deps:, Dependabot bumps), Other (everything else). If the repo doesn't use conventional commits, produce a flat bulleted list.
- One line per commit; keep the short SHA in parens at the end.
- Collapse Dependabot dependency bumps into a single line (e.g. - Dependency updates (12 bumps)) when there are more than ~3, otherwise list them.
- Drop pure-noise commits (e.g. "wip", "fix typo in comment") if they'd dominate the list — use judgment.
Show draft notes to the user and wait for confirmation before publishing. They may want to edit wording, reorder, or add a header summary.

Create the release:

gh release create "<version>" \
  --title "<version>" \
  --notes "<release-notes>" \
  --target "$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)"

gh release create creates and pushes the tag automatically — no separate git tag / git push --tags.

Confirm by printing the release URL gh returns.

Flags to ask about if unstated

--draft — if the user wants to review on github.com before publishing.
--prerelease — for -rc, -beta, -alpha versions or anything not production-ready.
--latest=false — if this is a backport release on an older branch and shouldn't be marked latest.

Hard rules

Never overwrite an existing tag — stop and ask the user instead.
Always show draft notes for confirmation before publishing.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.