
Github Release
Cut a versioned Git tag, push branch and tags, and publish a GitHub Release with notes from commits since the last tag.
Overview
github-release is an agent skill for the Ship phase that automates version tags, push order, commit-based release notes, and GitHub Release creation via the gh CLI.
Install
npx skills add https://github.com/jezweb/claude-skills --skill github-releaseWhat is this skill?
- Detect version from `package.json` via node, prefix tags with `v`, or ask the user when no manifest exists
- Monorepo scoped tags such as `mypackage-v1.0.0` vs single-repo `v1.0.0`
- Resolve local tag conflicts with `git tag -d` and cautious remote tag deletion after user confirmation
- Push branch first then `git push origin --tags`; troubleshoot upstream, `gh auth status`, and remotes
- Release notes from `git log` since last tag formatted as markdown under `## What's New`; supports `gh release create` in
Adoption & trust: 928 installs on skills.sh; 841 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are ready to ship but keep fumbling version strings, tag conflicts, push order, or blank GitHub Release notes.
Who is it for?
Indie maintainers of Node or monorepo projects who release through GitHub with `gh` already installed.
Skip if: Teams using only npm publish without GitHub Releases, or organizations with formal CI-only release gates that forbid local tag pushes.
When should I use this skill?
Cutting a GitHub release after implementation is ready—tags, push, and gh release create.
What do I get? / Deliverables
A correctly named tag is on the remote, release notes list changes since the prior tag, and a GitHub Release is published (including pre-release when needed).
- Annotated git tag (scoped for monorepos when applicable)
- Pushed branch and tags on origin
- GitHub Release with What's New markdown notes
Recommended Skills
Journey fit
Tagging and `gh release create` are classic ship milestones immediately before or as users receive a new version. Launch under Ship covers release mechanics—version detection, tag push order, and published release notes—not day-two monitoring.
How it compares
Tag-push-`gh release` mechanics—not full semantic-version policy debate or marketplace ASO launch checklists.
Common Questions / FAQ
Who is github-release for?
Solo developers and small teams who tag versions and publish GitHub Releases from the command line with agent assistance.
When should I use github-release?
In Ship at launch when merging a release branch, cutting beta tags, or regenerating release notes from commits since the last tag.
Is github-release safe to install?
It instructs git push and optional remote tag deletion—review Security Audits on this page and confirm destructive tag commands before running them on shared remotes.
SKILL.md
READMESKILL.md - Github Release
# Release Workflow Detailed reference for the tag-push-release mechanics. ## Version Detection Check `package.json` first: ```bash node -p "require('./package.json').version" 2>/dev/null ``` If no package.json, ask user for version. Always prefix with `v` (e.g., `v1.0.0`). ## Monorepo Tags In monorepos, use scoped tags: ```bash # Single repo git tag -a v1.0.0 -m "Release v1.0.0" # Monorepo git tag -a mypackage-v1.0.0 -m "Release mypackage v1.0.0" ``` ## Tag Conflicts If tag already exists locally: ```bash # Delete local tag git tag -d v1.0.0 # If also on remote (dangerous — confirm with user) git push origin :refs/tags/v1.0.0 ``` ## Push Sequence Always push branch first, then tags: ```bash BRANCH=$(git branch --show-current) git push origin ${BRANCH} git push origin --tags ``` If push fails: - Set upstream: `git push -u origin ${BRANCH}` - Check auth: `gh auth status` - Verify remote: `git remote -v` ## Release Notes Generate from commits since last tag: ```bash LAST_TAG=$(git describe --tags --abbrev=0 HEAD^ 2>/dev/null || echo "") if [ -z "$LAST_TAG" ]; then git log --oneline --no-merges HEAD else git log --oneline --no-merges ${LAST_TAG}..HEAD fi ``` Format as markdown bullet list under `## What's New`. ## gh release create ```bash # Standard release gh release create v1.0.0 --title "Release v1.0.0" --notes "## What's New - Feature A - Bug fix B" # Pre-release (beta/rc) gh release create v1.0.0-beta.1 --title "v1.0.0 Beta 1" --notes "..." --prerelease # Draft (not published) gh release create v1.0.0 --title "Release v1.0.0" --notes "..." --draft ``` ## Post-Release Depending on project type: - **npm package**: `npm publish` - **Announce**: Social media, relevant communities - **Update docs**: Ensure README references latest version # Safety Checklist Pre-release safety checks for public repositories. ## Blockers (must pass) | Check | How | Fail action | |-------|-----|-------------| | No secrets in files | `gitleaks detect --no-git --source=.` | Remove secrets, check git history | | No secrets in git history | `git log -S "sk_" -S "ghp_" -S "PRIVATE KEY"` | BFG Repo-Cleaner | | LICENSE exists | `ls LICENSE*` | Create MIT or proprietary | | Remote URL is correct | `git remote -v` | Fix with `git remote set-url` | ## Warnings (should fix) | Check | How | Recommendation | |-------|-----|----------------| | README has Install/Usage/License | `grep -i "## Install\|## Usage" README.md` | Add missing sections | | .gitignore has essentials | `grep "node_modules\|\.env" .gitignore` | Add missing patterns | | No personal artifacts | `ls SESSION.md planning/ screenshots/ 2>/dev/null` | Delete or .gitignore | | Build succeeds | `npm run build` | Fix before release | | No critical vulnerabilities | `npm audit --audit-level=high` | `npm audit fix` | | No large files (>1MB) | `find . -size +1M -not -path "*/node_modules/*" -not -path "*/.git/*"` | Git LFS or external storage | ## Common Secret Patterns | Pattern | Example | |---------|---------| | API keys | `sk_live_...`, `ghp_...`, `AKIA...` | | Tokens | `Bearer eyJ...`, `xoxb-...` | | Private keys | `-----BEGIN PRIVATE KEY-----` | | Passwords | `password = "..."`, `DB_PASSWORD=...` | | Cloudflare | `account_id` in committed wrangler files with real IDs | ## Package.json Fields For npm packages, verify these fields before publish: ```json { "name": "@scope/package", "version": "1.0.0", "description": "Clear description", "license": "MIT", "repository": { "type": "git", "url": "https://github.com/..." }, "keywords": ["relevant", "terms"] } ``` --- name: github-release description: "Prepare and publish GitHub releases. Sanitizes code for public release (secrets scan, personal artifacts, LICENSE/README validation), creates version tags, and publishes via gh CLI. Trigger with 'release', 'publish', 'open source', 'prepare for release', 'create release', or 'github release'." compatibility: claude-code-only --- # GitHub Release Sani