Release

Skill sp-daewoon/chronicle/skills/release

📜 Never write changelogs or release notes by hand again — automate your entire docs lifecycle (ADR · changelog · release · devlog · index) with 6 zero-dependency Claude Code skills.

Install

npx -y skills add sp-daewoon/chronicle --skill release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

1.9 KB, as published. Nobody here has run it

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.