Writing
Blog post draft
Draft a blog post from a brief or notes: one argument, a concrete opening, a source for every claim, and a headline that says what the reader gets.
Add in the app
Writing · For your bots
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.
In Lobstack: Skills › Library › Add
Download LobstackWhen to use it
A version is about to go out. Also when a conversation has settled what shipped and somebody has to write it down.
What your bot will do
- 01
Work from what merged since the last release, not from the commits. A branch of nine commits is one entry.
- 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.
- 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.
- 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".
- 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.
- 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
---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.