Your team, thoughtfully built.

How to Write Release Notes With AI

By Staffmor Staff

Practical guides from the team building Staffmor.

To write release notes with AI, give it the record of what shipped and ask for the change in the user's terms: what they can do now, what was fixed, and what is still limited. Release notes describe the version people can use today. Work that is finished but not released does not belong in them.

The example is a made-up booking product at version 3.

Start from the release, not the work

Shipped: confirmation emails now show the correct arrival time. The address link is readable on a phone.
Not shipped: a calendar integration, still a prototype.
Checked on: desktop and one phone-size preview.

Give it the version, when it went out, which part of the product changed, what was checked and the known limits. A finished commit or an approved screenshot shows the work was done. It does not show customers have it.

The request

The request: "Write release notes for version 3 from the change list and release record below. Say what users can now do or what was corrected, in plain language. Include what is still limited and where to get help. Leave out the calendar prototype, which has not shipped. Do not say it was tested on all devices; checks covered desktop and one phone-size preview."

What comes back

Booking update, version 3
New workshop confirmations now show the correct arrival time. The venue address link is easier to read on a narrow screen. Calendar integration is not part of this release.
If your confirmation was sent before this update, check your booking details or contact the organizer.

The mistakes to watch for

Announcing the prototype. Prototype work is often the most interesting item on the change list, so a draft will want to mention it. Users who read "calendar integration" will go looking for it.

Fixing the past by implication. "Confirmation emails now show the correct time" is true of new emails. The ones already sent still say the wrong time. The last line of the note is there because someone checked.

Claiming more testing than happened. "Works on all devices" is a promise. "Checked on desktop and phone-size screens" is a fact.

Publish it with the version

Read the note beside the live product, try its links, and publish it through your normal route. If a problem turns up later, add a dated correction under the note. Rewriting the original as though it was always right is how release notes stop being believed.

Run it in your Staffmor office

Open the office on the computer running it with its Start Staffmor launcher. If you already have a paired web office, open it here. Paste this request and the source material into the conversation. Use your approved Codex connection, or ask your open Claude Code session to "Check Staffmor for work." A saved request is not a completed result. Review the answer or file when it comes back and reply with corrections. Ask a second pass to compare each line of the note with the release record.

Staffmor writes from the record you give it. Deciding what shipped, and publishing the note, stays with you. New to Staffmor? Set up your office with Codex or Claude Code and an empty folder. Use your own supported AI account and approve the download, office activation and local folder/network access during setup. Claude Code pickup is manual; keep that local session open.