Run any Skill in Manus with one click

changelog-and-release-notes

Stars3

Forks1

UpdatedJuly 4, 2026 at 14:45

Reads the diff and writes a CHANGELOG entry in the repo's own voice, and bumps the VERSION when asked. Use when asked to "update the changelog", "write release notes", "add a changelog entry", "bump the version", or when a change is ready to ship and the CHANGELOG has not been updated. Use before or as part of shipping a user-visible change.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

luminik-io

luminik-io/alfred

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	changelog-and-release-notes
description	Reads the diff and writes a CHANGELOG entry in the repo's own voice, and bumps the VERSION when asked. Use when asked to "update the changelog", "write release notes", "add a changelog entry", "bump the version", or when a change is ready to ship and the CHANGELOG has not been updated. Use before or as part of shipping a user-visible change.
license	MIT

Changelog and release notes

When to use

A change is ready to ship and the CHANGELOG has no entry for it.
You are asked to write release notes for a version.
A PR adds, changes, fixes, or removes user-visible behavior.

The entry is for the reader who upgrades and wants to know what changed and whether it affects them. Write for that person, not for the committer. Skip internal-only churn (a refactor with no observable effect) unless the repo's CHANGELOG convention records it.

Procedure

Read the diff, not the commit messages. Commit subjects drift from what actually shipped. Look at what the code now does differently: new behavior, changed defaults, fixed bugs, removed options.
Match the repo's CHANGELOG voice and format. Read the existing CHANGELOG.md first. Follow its structure (Keep a Changelog sections Added / Changed / Fixed / Removed, or whatever the repo uses), its tense, and its level of detail. Do not impose a new format.
Write one entry per user-visible change, grouped under the right section. Each line says what changed and, where it matters, the effect on the reader ("Changed the default page size to 50; callers relying on 20 must pass ?limit=20"). Reference the PR or issue number if the repo does.
Call out breaking changes explicitly. If a default changed or an API was removed, mark it so an upgrader cannot miss it.
Bump VERSION only if asked. When requested, update the VERSION file (or the manifest version field) following semver: major for a breaking change, minor for a backward-compatible addition, patch for a fix. State the bump and why. Do not tag or publish; that is a human gate.
Keep the house style: no em-dashes, no marketing adjectives, no invented numbers. Plain and accurate.

Output

The CHANGELOG entry (or entries), in the repo's existing format and voice, under the correct sections, with breaking changes flagged.
If a bump was requested: the new version and the semver reason for it.
A one-line summary of what shipped, suitable for a release-notes headline.

More from this repository

same repository

add-observability

luminik-io/alfred

Adds structured logging at decision points, one metric per new outcome, and a trace span per new I/O boundary, all behind config-driven levels. Use when asked to "add logging", "make this observable", "add metrics", "instrument this", "add a trace span", or when shipping a feature or path that would be a black box in production. Use when a change adds a new outcome, branch, or external call that operators will need to see.

2026-07-043

migrate-dependency

luminik-io/alfred

Migrates a dependency to a target version by pinning it, reading the changelog for breaking changes, updating call sites, running the tests, and writing a migration note. Use when asked to "upgrade this dependency", "bump the version of X", "migrate to X v2", "update the library", or when a dependency is out of date, deprecated, or has a security advisory. Use before merging any dependency version bump.

2026-07-043

review-security

luminik-io/alfred

Reviews a change through a STRIDE-lite security lens (injection, authorization, secret handling, SSRF and egress) and reports concrete findings with severity and a fix. Use when asked to "security review", "check this for vulnerabilities", "review the auth path", "is this safe to merge", or when a change touches untrusted input, authentication, secrets, or outbound network calls. Use before merging any change on a trust boundary.

2026-07-043

spec-to-issues

luminik-io/alfred

Turns an approved spec or roadmap item into scoped, single-repo agent:implement issues with testable acceptance criteria and an explicit out-of-scope block. Use when asked to "break down this spec", "turn this into issues", "scope this roadmap item", "create implementation issues", or "plan the work for this feature". Use when a spec is approved and needs to become the tickets a fleet can pick up.

2026-07-043

write-tests

luminik-io/alfred

Derives tests from acceptance criteria, writes a failing regression test before fixing a bug, runs the suite, and reports coverage of the specific behavior. Use when asked to "write tests", "add test coverage", "test this change", "write a regression test", or when implementing a feature or fixing a bug that ships without tests. Use before committing any behavior change.

2026-07-043

code-review-and-quality

luminik-io/alfred

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

2026-07-033

name	changelog-and-release-notes
description	Reads the diff and writes a CHANGELOG entry in the repo's own voice, and bumps the VERSION when asked. Use when asked to "update the changelog", "write release notes", "add a changelog entry", "bump the version", or when a change is ready to ship and the CHANGELOG has not been updated. Use before or as part of shipping a user-visible change.
license	MIT

Changelog and release notes

When to use

A change is ready to ship and the CHANGELOG has no entry for it.
You are asked to write release notes for a version.
A PR adds, changes, fixes, or removes user-visible behavior.

Procedure

Read the diff, not the commit messages. Commit subjects drift from what actually shipped. Look at what the code now does differently: new behavior, changed defaults, fixed bugs, removed options.
Match the repo's CHANGELOG voice and format. Read the existing CHANGELOG.md first. Follow its structure (Keep a Changelog sections Added / Changed / Fixed / Removed, or whatever the repo uses), its tense, and its level of detail. Do not impose a new format.
Write one entry per user-visible change, grouped under the right section. Each line says what changed and, where it matters, the effect on the reader ("Changed the default page size to 50; callers relying on 20 must pass ?limit=20"). Reference the PR or issue number if the repo does.
Call out breaking changes explicitly. If a default changed or an API was removed, mark it so an upgrader cannot miss it.
Bump VERSION only if asked. When requested, update the VERSION file (or the manifest version field) following semver: major for a breaking change, minor for a backward-compatible addition, patch for a fix. State the bump and why. Do not tag or publish; that is a human gate.
Keep the house style: no em-dashes, no marketing adjectives, no invented numbers. Plain and accurate.

Output

The CHANGELOG entry (or entries), in the repo's existing format and voice, under the correct sections, with breaking changes flagged.
If a bump was requested: the new version and the semver reason for it.
A one-line summary of what shipped, suitable for a release-notes headline.