mcpField
W
write-release-notes

write-release-notes

github.com/koruworksDevelopment012 installsUpdated 1d ago
Repository

About write-release-notes

A skill for preparing release notes according to a project's own release rules. It gathers channel history and repository changes, then writes notes for people installing the release without publishing or committing them.

Key features

  1. 01Find project-specific release instructions
  2. 02Gather channel manifests and change history
  3. 03Follow version and file-format rules
  4. 04Write notes focused on user-visible changes
  5. 05Leave publishing and commits to the user

Use cases

  1. 01Preparing release notes for a project channel
  2. 02Summarizing changes since a published build
  3. 03Checking release version and descriptor requirements

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/koruworks/skills --skill write-release-notes

After installing, type/write-release-notesin Claude Code to confirm it loaded.

Details

From the project README

Release notes

The project owns the rules: how versions advance, where the published manifests live, what the descriptor looks like and how its copy reads. This skill only gathers the context and makes sure those rules are followed rather than guessed.

Find the instructions

Look for the project's release-writing instructions before anything else — releases/WRITING.md first, then whatever AGENTS.md, CONTRIBUTING.md or a releases/README.md points at. If there are none, stop and ask where releases are described; do not invent a version scheme or a file format.

If the user named no channel and the instructions define more than one, ask which. One question, with the channels as options.

Gather the context

Collect these yourself unless the request already supplied them:

  1. What is published on each channel, from wherever the instructions say the manifests live. Bypass caches the way they describe (a fresh query parameter is the usual one). A missing manifest means the channel was never published; a network failure is not the same thing — report it, do not treat it as an empty history.
  2. This tree: git rev-parse --short HEAD, today's date in UTC (date -u +%Y%m%d), and git status --porcelain. A dirty tree is worth a sentence to the user, since a build from it would not match HEAD.
  3. What changed since the published commit on that channel — git log <published>..HEAD, read for what a user would notice. Commit messages written for changelog readers (see commit-changes) are the source; the diff settles anything they leave unclear.

Write it

Follow the instructions for version selection, the file name and the format exactly. If the publisher supplied an exact descriptor path or version, use it unchanged, even if the date or the manifests have moved since.

Write for the person installing the release: what they can now do, what was fixed that they may have hit, what changed under them. Leave out internal refactors unless they change something observable.

Finish

Show the file and the version you chose, with the one line of reasoning behind the version. Do not commit unless asked, and never publish, tag or push — releasing is the user's step.

Comments

Markdown supported