Git Release
Prepara bozze di note di rilascio Keep-a-Changelog, sceglie il bump semver, stampa il comando gh release
Promosso
Cosa fa
Trasforma i commit e le PR unite dall'ultimo tag git in una bozza di note di rilascio Keep-a-Changelog, propone un bump di versione semantica (major per footer BREAKING CHANGE o marcatori `!`, minor per feature, patch altrimenti) e stampa un comando `gh release create` pronto all'uso. Si attiva quando si chiede di preparare note di rilascio, preparare un rilascio GitHub taggato o decidere quale numero di versione debba avere un set di modifiche. Si ferma prima di taggare o pubblicare finché non si conferma il bump, e segnala messaggi di commit non convenzionali invece di inventare un riepilogo per essi.
Rapporto di test
Clonato il repository (l'API di GitHub era soggetta a limitazioni di frequenza) e trovato esattamente un SKILL.md in .opencode/skills/git-release/; frontmatter analizzato con nome + descrizione (158 caratteri) più licenza/compatibilità/metadati, nessuno script o file in bundle referenziato, nessun percorso hardcoded, e una ricerca grep per curl|sh, base64, eval e frasi di iniezione nella directory della skill è tornata vuota. Installato sotto una HOME temporanea, mai la vera ~/.claude/skills (verificato in seguito). Per il test di output ho costruito un repository git temporaneo in /tmp/gr-testrepo taggato v1.2.0 con sei commit inclusi `feat(cli)!: rename --out to --output` con un footer BREAKING CHANGE e un messaggio spazzatura "Update readme", quindi ho scritto baseline-notes.md senza la skill e release-notes.md seguendo rigorosamente il corpo. Differenza concreta: la baseline intitolava il file "# Release v1.3.0" e elencava la ridenominazione sotto "New", mancando completamente la rottura, mentre l'artefatto della skill produceva "## [2.0.0]" con una sezione Removed, la ragione dichiarata ("carries a `!` marker and a `BREAKING CHANGE:` footer"), un comando `gh release create v2.0.0 --notes-file release-notes.md`, e segnalava "Update readme" come non revisionabile invece di parafrasarlo in "Updated the readme" come faceva la baseline. Frasi di attivazione che ho giudicato: DOVREBBE caricare — "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" (sì, sì, sì); NON DOVREBBE — "Write a commit message for these staged changes" e "Set up a GitHub Actions workflow that publishes to npm on tag push" (no, no; entrambi sono lavori di commit/CI, non di preparazione di note di rilascio). 5/5. I documenti perdono un punto solo perché la skill è presentata come l'unica skill di esempio del repository primer senza un README per skill; ciò che README.md e docs/skills.md affermano su di essa corrisponde al file.
Testato il: 2026-07-21 · Claude Code 2.x (agent harness)
Installazione
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.
Comandi e prompt di esempio
/git-releasePrepara bozze di note di rilascio Keep-a-Changelog, sceglie il bump semver, stampa il comando gh release
Gli skill si attivano con richieste in linguaggio naturale, senza comandi da ricordare. Dopo l'installazione, prompt come questi lo attivano (in inglese):
Draft release notes for this tagged releasePropose the next semver bump for this releasePrepare a gh release create command