Writing

Release notes from merged work

Turn merged work, or a thread about it, into release notes written for the person installing the version rather than the person who built it.

Download LobstackRead the file

In Lobstack: Skills › Library › Add

For your agents

What your agent will do.

A version is about to go out. Also when a conversation has settled what shipped and somebody has to write it down.

  1. 01

    Work from what merged since the last release, not from the commits. A branch of nine commits is one entry.

  2. 02

    Cut everything the reader cannot observe: refactors, dependency bumps, pipeline changes, internal renames. An entry with no visible effect is padding, and padding is why people stop opening the file at all.

  3. 03

    Order by what it costs them. Breaking changes first, each with the migration written as an instruction; then what is new; then what was fixed.

  4. 04

    Write each entry from outside the code. "The menu bar icon is a glyph again instead of a black square" rather than "corrected iconAsTemplate handling".

  5. 05

    Link every entry to the change it came from, so a reader who needs the detail can go and get it and the note can stay one line.

  6. 06

    List what is still broken, when a known problem survived the release. Somebody is going to hit it, and finding it already written down is a very different experience from finding it.

If a change cannot be described without naming a source file, it is probably not a release note.

The file

The whole SKILL.md: 33 lines of Markdown.

Add it in the app from Skills › Library, or copy it and paste it into Skills › Add a skill.

release-notes/SKILL.md33 lines
---name: release-notesdescription: "Turn merged work, or a thread about it, into release notes written for the person installing the version rather than the person who built it."metadata:  title: "Release notes from merged work"  category: writing  tags: [releases, changelog]--- ## When to use this A version is about to go out. Also when a conversation has settled what shippedand somebody has to write it down. ## How 1. Work from what merged since the last release, not from the commits. A branch   of nine commits is one entry.2. Cut everything the reader cannot observe: refactors, dependency bumps,   pipeline changes, internal renames. An entry with no visible effect is   padding, and padding is why people stop opening the file at all.3. Order by what it costs them. Breaking changes first, each with the migration   written as an instruction; then what is new; then what was fixed.4. Write each entry from outside the code. "The menu bar icon is a glyph again   instead of a black square" rather than "corrected iconAsTemplate handling".5. Link every entry to the change it came from, so a reader who needs the detail   can go and get it and the note can stay one line.6. List what is still broken, when a known problem survived the release.   Somebody is going to hit it, and finding it already written down is a very   different experience from finding it. If a change cannot be described without naming a source file, it is probably nota release note.
Agents that start with it

Ready-made agents that follow this skill.

All agents.

More skills

More for your agents, from Writing first.

All skills, on their shelves.