/release

name: release
description: Ship releases with rich, auto-written notes instead of hand-typed bullet points. Use when cutting a release — promote the changelog, synthesize notes from your CHANGELOG, ADRs and commits, tag the release, and optionally publish via the gh CLI. Degrades gracefully to a notes file when gh is absent, and adapts to any repo via config.
license: MIT

Release Workflow

Cut a release end to end.

1. Promote the changelog

node "${CLAUDE_PLUGIN_ROOT}/scripts/changelog-parse.mjs" release --version <X.Y.Z> --date <today>

2. Gather context for notes

Find the previous tag and the commits/ADRs since then:

PREV=$(git describe --tags --abbrev=0 2>/dev/null || echo "")
COMMITS=$( [ -n "$PREV" ] && git log "$PREV"..HEAD --pretty=format:'%s' || git log --pretty=format:'%s' )

Collect new ADRs by diffing the ADR directory since `$PREV` (use `git diff --name-only --diff-filter=A "$PREV"..HEAD -- <adr.dir>`). Build a JSON object `{ "adrs": [{number,title,file}], "commits": ["..."] }`.

3. Synthesize notes

Pipe the JSON into the helper:

echo "$JSON" | node "${CLAUDE_PLUGIN_ROOT}/scripts/release-notes.mjs" --version <X.Y.Z>

This writes `RELEASE_NOTES.md` and prints the notes. The notes combine the changelog section for this version, new ADRs, and a collapsed commit list.

4. Tag and publish

git tag <tagPrefix><X.Y.Z>     # tagPrefix from config, default "v"

If `gh` is installed and a remote exists, publish:

gh release create <tagPrefix><X.Y.Z> --notes-file RELEASE_NOTES.md

If `gh` is unavailable, stop here and tell the user the notes are in `RELEASE_NOTES.md` for manual upload.

Rules

• Never tag before the changelog is promoted (step 1 must precede step 4).
• `gh` is optional — degrade gracefully to the notes file.
• Use the real version and date; confirm the version bump with the user if ambiguous.