release-notes

name	release-notes
description	Generates Git release descriptions for json-schema-rs by summarizing commits between tags. Use when the user asks for release notes, a release summary, what changed in a version, or to summarize a tag; or when preparing release text for a new version.

Release notes for json-schema-rs

When to use

Apply this skill when the user:

• Asks for release notes, a release summary, or "what's in this release"
• Wants to summarize a specific version or tag
• Is preparing release text for a new version of the library

Resolve the tag to summarize

• User specified a version or tag (e.g. v0.0.4, 0.0.4): Use it. Normalize to the actual tag name if needed (e.g. if tags are v0.0.4, use that form).
• User did not specify: List tags with version ordering, then ask which tag to summarize.

List tags (newest first):

git tag -l --sort=-version:refname

Or oldest first:

git tag -l --sort=version:refname

Present the list and ask the user which tag to summarize (e.g. via AskQuestion or a clear prompt).

Commit range

• Previous tag: In the version-ordered list, the tag immediately before the chosen tag is the "previous" tag.
• First or only tag: If the chosen tag is the first (or only) tag, there is no previous tag; commits are from repo start through the chosen tag.
• Range: Collect all commits after the previous tag through and including the requested tag. In Git terms: previous_tag..requested_tag (excludes previous_tag, includes requested_tag). For the first tag, use the chosen tag as the range (e.g. all commits reachable from that tag).

Gathering commits

Overview (one line per commit):

git log previous_tag..requested_tag --oneline

Full commit messages:

git log previous_tag..requested_tag

For the first tag (no previous tag):

git log requested_tag --oneline
git log requested_tag

Merge commits and conventional-commit style messages are both in scope; use them to understand what changed.

Optional deep dive

If a commit message is vague or critical (e.g. "fix codegen"), run git show <commit> to see the diff and summarize what actually changed. Use this when it would make the release description more accurate or useful.

Writing the release description

Audience: Developers considering or using the library; developers scanning "what's new" per release.

Style:

• Succinct and insightful; no fluff.
• Group by theme where it helps (e.g. Codegen, CLI, Docs, Fixes).
• Use bullet points or short paragraphs.

Content:

• What changed and why it matters to users: new behavior, fixes, breaking changes, dependency or version bumps.
• Synthesize; do not list every commit. Focus on user-facing impact and clarity.

The result should be suitable for GitHub/Git release notes and helpful to anyone evaluating or upgrading the library.

Output format

• Default: Present the release notes directly in the chat. Do not write them to a file unless the user explicitly asks for a file (e.g. "write to RELEASE_NOTES.md", "save to a file").
• Copy-pasteable: When presenting in chat, format the release notes as easy copy-pasteable markdown (e.g. in a fenced code block with markdown language hint) so the user can grab the raw markdown.