Git Release
Entwirft Keep-a-Changelog Release Notes, wählt den Semver-Bump, gibt den gh release Befehl aus
Getestet · Funktioniert
Was es kann
Wandelt die Commits und zusammengeführten PRs seit dem letzten git Tag in einen Keep-a-Changelog Release-Notes-Entwurf um, schlägt einen semantischen Versions-Bump vor (Major bei BREAKING CHANGE Footern oder `!` Markern, Minor bei Features, Patch sonst) und gibt einen ausführungsbereiten `gh release create` Befehl aus. Wird ausgelöst, wenn Sie Release Notes entwerfen, ein getaggtes GitHub Release vorbereiten oder entscheiden möchten, welche Versionsnummer eine Reihe von Änderungen erhalten soll. Es stoppt vor dem Taggen oder Veröffentlichen, bis Sie den Bump bestätigen, und kennzeichnet nicht-konventionelle Commit-Nachrichten, anstatt eine Zusammenfassung dafür zu erfinden.
Testbericht
Das Repo geklont (GitHub API war ratenbegrenzt) und genau eine SKILL.md unter .opencode/skills/git-release/ gefunden; Frontmatter geparst mit name + description (158 Zeichen) plus license/compatibility/metadata, keine Skripte oder gebündelten Dateien referenziert, keine festkodierten Pfade, und ein grep nach curl|sh, base64, eval und Injection-Formulierungen im Skill-Verzeichnis ergab nichts. Unter einem mktemp HOME installiert, niemals das echte ~/.claude/skills (danach verifiziert). Für den Output-Test habe ich ein temporäres Git-Repo unter /tmp/gr-testrepo erstellt, das v1.2.0 mit sechs Commits getaggt war, darunter `feat(cli)!: rename --out to --output` mit einem BREAKING CHANGE Footer und einer Junk-Nachricht „Update readme“, dann baseline-notes.md ohne den Skill und release-notes.md streng nach dem Body geschrieben. Konkreter Unterschied: Die Baseline überschrieb die Datei mit „# Release v1.3.0“ und listete die Umbenennung unter „New“ auf, wobei der Bruch vollständig fehlte, während das Skill-Artefakt „## [2.0.0]“ mit einem Removed-Abschnitt, dem angegebenen Grund („carries a `!` marker and a `BREAKING CHANGE:` footer“), einem `gh release create v2.0.0 --notes-file release-notes.md` Befehl und es „Update readme“ als nicht überprüfbar kennzeichnete, anstatt es wie die Baseline in „Updated the readme“ zu paraphrasieren. Trigger-Formulierungen, die ich beurteilt habe: SOLLTE laden — „Draft release notes for v2.0.0 from what's merged since the last tag“, „I'm cutting a release tomorrow, is this a major or a minor bump?“, „Prepare a GitHub release for this repo“ (ja, ja, ja); SOLLTE NICHT — „Write a commit message for these staged changes“ und „Set up a GitHub Actions workflow that publishes to npm on tag push“ (nein, nein; beides ist Commit-/CI-Arbeit, nicht Release-Note-Entwurf). 5/5. Die Dokumentation verliert nur einen Punkt, weil der Skill als einziges Beispiel-Skill des Primer-Repos ohne pro-Skill-README präsentiert wird; was README.md und docs/skills.md darüber behaupten, stimmt mit der Datei überein.
Getestet am: 2026-07-21 · Claude Code 2.x (agent harness)
Installation
git clone --depth 1 https://github.com/wesammustafa/opencode-primer.git /tmp/git-release-src mkdir -p ~/.claude/skills cp -R /tmp/git-release-src/.opencode/skills/git-release ~/.claude/skills/git-release # Single-file skill (SKILL.md only), no scripts or deps to install. # Frontmatter carries `compatibility: opencode`, but the folder is a standard # Claude Code skill and loads unchanged from ~/.claude/skills/git-release/. # Runtime expectation from the skill body: an authenticated `gh` CLI if you want # it to read merged PR data and actually run the emitted release command. # Without `gh` it still works off `git log <last-tag>..HEAD`. # Usage: "draft release notes since the last tag" in a repo with at least one tag.
Befehle & Beispiel-Prompts
/git-releaseEntwirft Keep-a-Changelog Release Notes, wählt den Semver-Bump, gibt den gh release Befehl aus
Skills reagieren auf normale Anfragen — keine Slash-Befehle nötig. Nach der Installation aktivieren Prompts wie diese den Skill (auf Englisch):
Draft release notes for this tagged releasePropose the next semver bump for this releasePrepare a gh release create command