with one click
release
Tag a version, generate changelog, and create a GitHub release.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Tag a version, generate changelog, and create a GitHub release.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | release |
| description | Tag a version, generate changelog, and create a GitHub release. |
Tag a version, generate changelog, and create a GitHub release.
/release [version] [--dry-run] [--draft]
version: Semver version (1.2.3) or bump type (patch, minor, major)--dry-run: Preview release without creating anything--draft: Create as draft release (don't publish)When this skill is invoked:
Autonomy:
Safety:
Verify clean worktree:
git status --porcelain
If dirty, stop and ask user to commit or stash.
Verify branch:
git branch --show-current
Warn if not main or master.
Run quality checks:
make quality # or equivalent from prd/00_technology.md
All checks must pass before release.
Get current version:
git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0"
If version not specified, analyze commits since last tag:
git log $(git describe --tags --abbrev=0 2>/dev/null || echo "")..HEAD --oneline
Auto-bump rules (conventional commits):
feat!: or BREAKING CHANGE: → majorfeat: → minorfix:, perf:, refactor: → patchCheck for CHANGELOG.md in project root.
Classify changes using the Breaking Change Policy in CHANGELOG.md.
major, warn the user.Update CHANGELOG.md (if present):
[Unreleased] into a new [X.Y.Z] - YYYY-MM-DD section.Generate GitHub release notes from commits since last tag:
## What's Changed
### Breaking Changes
- description (#PR)
### Features
- description (#PR)
### Bug Fixes
- description (#PR)
### Performance
- description (#PR)
### Other Changes
- description (#PR)
**Full Changelog**: v1.0.0...v1.1.0
Update version in package config if applicable:
# package.json, pyproject.toml, Cargo.toml, etc.
Commit version bump (if file changed):
git add {package_config}
git commit -m "chore: bump version to {version}"
Create annotated tag:
git tag -a v{version} -m "Release v{version}"
Push tag:
git push origin main --tags
Create GitHub release:
gh release create v{version} --title "v{version}" --notes "{changelog}"
# or with --draft flag
gh release create v{version} --title "v{version}" --notes "{changelog}" --draft
When --dry-run is specified:
| Stack | File | Field |
|---|---|---|
| Node.js | package.json | version |
| Python | pyproject.toml | [project] version |
| Go | No file (tags only) | — |
| iOS | Info.plist | CFBundleShortVersionString |
| Android | build.gradle.kts | versionName / versionCode |
$ /release minor
Pre-release checks...
Branch: main
Worktree: clean
Tests: passing (142/142)
Lint: clean
Current version: v1.2.0
Analyzing commits since v1.2.0...
3 features, 2 fixes, 1 refactor
Bumping: v1.2.0 → v1.3.0
Changelog:
## What's Changed
### Features
- Add OAuth2 login support (#45)
- Add user avatar uploads (#48)
- Add dark mode toggle (#52)
### Bug Fixes
- Fix memory leak in image processing (#46)
- Fix pagination on user list (#50)
Creating release...
Updated package.json version
Created tag v1.3.0
Pushed to origin/main
Created GitHub release: https://github.com/org/repo/releases/tag/v1.3.0
Release v1.3.0 published!
Write a structured handoff at session end. Preserves context so the next agent can resume without human briefing. Invoke before ending any feature session longer than 30 minutes.
Multi-perspective code review against project standards with P1/P2/P3 severity classification. Works in Claude Code (Agent + optional GitHub MCP) and Cursor (Task subagents + gh/git). Use when the user invokes /review, asks for a PR or diff review, or wants a standards-aligned review with severity tags.
Multi-perspective code review (P1/P2/P3) for Cursor: inline checklists plus three parallel Task subagents (perf-auditor, security-reviewer, simplicity-reviewer with combined data-integrity prompt). Use when the user invokes /review, asks for a PR review, or wants repo-standard findings with severity.
Create well-formatted git commits following conventional commit standards.
Red→green→refactor discipline for new behavior — forces a failing test before implementation and a passing test before any claim of done.
Create or manage a git worktree for isolated parallel development — lets multiple agents work in the repo simultaneously without branch collisions.