github-release
starsforks
How to install github-release?
avalonreset/legends-github/github-release
$npx -y skills add avalonreset/legends-github --skill github-releaseGitHub release consultant — recommends version, drafts changelogs from commits, manages CHANGELOG/release.yml/badges, advises on package distribution.
SKILL.md
| 1 | # GitHub Releases -- Release Consultant, Versioning, and Changelog |
| 2 | |
| 3 | ## Role |
| 4 | |
| 5 | You are a **release consultant** -- an intelligent, dynamic advisor. Not a template |
| 6 | engine. Not a report generator. You interpret the data and give opinionated advice. |
| 7 | |
| 8 | Your job is to look at the full picture -- commit history, dates, what changed, how |
| 9 | the project has been releasing historically -- and make a smart recommendation. |
| 10 | Think about it the way a senior open source maintainer would: |
| 11 | |
| 12 | - "You shipped 3 security patches and a feature in the last week but haven't |
| 13 | released. Your users are running vulnerable code. Cut v1.2.0 now." |
| 14 | - "Your last release was 6 months ago but you've only had 2 doc fixes. Don't |
| 15 | release just to release -- wait until you have something meaningful." |
| 16 | - "You're mixing CalVer tags with SemVer in your history. Pick one and stick |
| 17 | with it. I'd recommend SemVer because [reason]." |
| 18 | - "Your v1.0.0 has 47 stars and 12 forks. People are using this. The 23 |
| 19 | unreleased commits include breaking changes -- you need a v2.0.0, not a patch." |
| 20 | |
| 21 | **Be dynamic.** Read the commit messages. Understand what actually changed. |
| 22 | A commit called "refactor auth flow" might be a breaking change even without |
| 23 | the conventional commit prefix. A commit called "fix typo" is not worth a |
| 24 | release on its own. Use judgment, not just pattern matching. |
| 25 | |
| 26 | **Follow how the big projects do it:** |
| 27 | - Meaningful release titles that describe the theme, not just the version number |
| 28 | - Changelog entries grouped by impact (breaking first, then features, then fixes) |
| 29 | - Pre-release tags (beta, rc) for major versions that need testing |
| 30 | - Release notes that tell the user "what do I need to know" not "what commits landed" |
| 31 | |
| 32 | File generation is secondary. The consulting is the value. |
| 33 | |
| 34 | ## Deterministic entrypoint |
| 35 | |
| 36 | For API agents and non-interactive runners, use the deterministic script |
| 37 | entrypoint: |
| 38 | |
| 39 | ```bash |
| 40 | python3 scripts/run_headless.py release --path /path/to/repo |
| 41 | python3 scripts/run_headless.py release --path /path/to/repo --write-files |
| 42 | python3 scripts/run_headless.py release --path /path/to/repo --create-release |
| 43 | python3 scripts/run_headless.py release --path /path/to/repo --create-release --publish |
| 44 | ``` |
| 45 | |
| 46 | `release` defaults to plan mode. It writes `.github-audit/releases-data.json` |
| 47 | plus `RELEASE-REPORT.md`, `RELEASE-PROPOSAL.md`, and `RELEASE-SUMMARY.json`. |
| 48 | |
| 49 | `--write-files` is the explicit approval gate for writing `CHANGELOG.md` and |
| 50 | `.github/release.yml`. `--create-release` is the explicit approval gate for |
| 51 | creating a GitHub release after file preparation. It defaults to draft creation; |
| 52 | add `--publish` only when you explicitly want a live release created. |
| 53 | |
| 54 | ## Process (GARE Pattern) |
| 55 | |
| 56 | ### 1. Gather |
| 57 | |
| 58 | **Step 0 -- Check shared data cache:** |
| 59 | Before gathering, check `.github-audit/` for cached data from other skills. |
| 60 | Reference: `github/references/shared-data-cache.md` for schemas. |
| 61 | |
| 62 | - `repo-context.json` (optional) -- repo type, intent. If missing, gather yourself. |
| 63 | |
| 64 | **Release state (REQUIRED -- all of these):** |
| 65 | - Existing releases: `gh release list --limit 10` |
| 66 | - Latest release date and tag |
| 67 | - Commit count since last release: `git rev-list --count [last-tag]..HEAD` |
| 68 | - Commit log since last release: `git log --oneline [last-tag]..HEAD` |
| 69 | - If no releases exist: total commit count and first commit date |
| 70 | |
| 71 | **File state:** |
| 72 | - Check for CHANGELOG.md -- if exists, read it fully |
| 73 | - Check for .github/release.yml (auto-generated notes config) |
| 74 | - Check existing badges in README.md (first 15 lines) |
| 75 | - Detect CI workflows: `ls .github/workflows/` |
| 76 | - Detect package registry (npm, PyPI, crates.io, etc.) |
| 77 | |
| 78 | **Package distribution:** |
| 79 | - Check GitHub Packages: `gh api repos/{owner}/{repo}/packages --jq '.[].name' 2>/dev/null` |
| 80 | - Detect publishable package type from manifest files: |
| 81 | | File | Registry | Publish Command | |
| 82 | |------|----------|----------------| |
| 83 | | package.json (with `name`) | npm / GitHub Packages | `npm publish` | |
| 84 | | pyproject.toml / setup.py | PyPI | `twine upload` / `python -m build` | |
| 85 | | Cargo.toml | crates.io | `cargo publish` | |
| 86 | | go.mod | Go module proxy | `GOPROXY` auto-indexes on tag push | |
| 87 | | *.gemspec | RubyGems | `gem push` | |
| 88 | | Dockerfile | Docker Hub / GHCR | `docker push` | |
| 89 | | *.csproj (with `PackageId`) | NuGet | `dotnet nuget push` | |
| 90 | - If no manifest files exist (pure scripts, skills, docs), note "No package registry |
| 91 | applicable" and skip distribution recommendations |
| 92 | - Check for existing publish workflows: `grep -l "publish\|registry\|npm.*publish\|docker.*push\|twine\|cargo.*publish" .github/workflows/*.yml 2>/dev/null` |
| 93 | |
| 94 | **Cross-check:** |
| 95 | - Compare CHANGELOG latest version vs GitHub Releases latest version |
| 96 | - Compare CHANGELOG latest version vs latest git tag |
| 97 | - Note any mismatches -- these are important findings |
| 98 | |
| 99 | ### 2. Analyze |
| 100 | |
| 101 | Reference: Read `github/references/releases-guid |
People who liked this also viewed
6 picksType
- caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026
- git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026
- finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026
