Change log release notes

Skill tanveerriaz/Skillz/skills/change-log-release-notes

Use to maintain a daily change journal during development and to generate release notes from it. Append every change to a dated log as you work, then derive user-readable release notes only from those logs. Use when the user asks to "log this change", "prepare release notes", or "summarize changes for release".From its SKILL.md

Install

npx -y skills add tanveerriaz/Skillz --skill change-log-release-notes

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

1 stars1 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.

SKILL.md

3.4 KB, as published. Nobody here has run it

Purpose

Create a reliable audit trail of changes and turn it into trustworthy release notes. Two problems this solves: changes get forgotten between sessions, and release notes get fabricated from memory. The fix is a single dated log appended to as work happens, and release notes derived strictly from those logs — never invented.

When to Use

Use throughout development to append a log entry after each change, and at release time to generate notes. Trigger phrases: "log this", "update the change log", "prepare release notes", "what's going into this release", "summarize changes".

Inputs

The change just made: the request, what was searched/found, the plan, files changed, and test results.
For release notes: the set of daily log files for the period or version being released.

Outputs

A dated change log file, appended to across the day (e.g. logs/03-Jun-26.md).
A release notes file derived from the logs (e.g. release-notes/v0.9.3.md), grouped into Features / Improvements / Bug Fixes / Security / Known Issues.

Procedure

Logging (during development):

Append to today's dated log file; use one file per day, append-only.
For each change record: timestamp, the user instruction, discovery (searches run and what was found), the plan, files changed with one-line summaries, test results, and any risks/TODOs.
Keep entries factual and concise.

Release notes (at release time):

Read only the relevant daily log files — do not pull from memory or invent items.
Group changes logically into: New Features, Improvements, Bug Fixes, Security / Auth, Known Issues / Follow-ups.
Rewrite each item in simple, user-readable language (no internal jargon, no file paths).
Write to a versioned or dated release-notes file.

Quality Checklist

Every change has a log entry with files touched and test result
Log is append-only and uses one file per day
Release notes derive solely from the logs
No invented features or fixes in the notes
Notes grouped by category and written in plain language
Security/auth changes called out explicitly

Edge Cases

No log entries for a period: state that there are no recorded changes rather than guessing.
A change spans multiple days: reference all relevant daily logs when composing notes.
Internal-only refactor: include in the log, but in release notes summarize as an improvement without exposing internals.
Sensitive details in a log entry: keep logs free of secrets; reference what changed, not credential values.

Safety Rules

Never fabricate release-note items not backed by a log entry.
Never put secrets, tokens, or private URLs in logs or notes.
Never overwrite prior log entries — append only.

Examples

See templates/daily-log.md and templates/release-notes.md.

Good: Release notes generated by reading five daily logs, grouping nine logged changes into Features (3), Improvements (4), Bug Fixes (2), each rewritten for end users.

Bad: Writing "Added dark mode and SSO" in release notes when neither appears in any log.