Write release notes people read

Read my project before you change anything. Tell me what you found and what you'd do, as a short plan, and wait for my OK. Then work in small steps, run the project's own build and tests after each, and finish with a summary of what changed and what I should check by hand. Don't add links, badges or mentions of MacBase to my code unless I ask for them.

Write the release notes for the next version from the commits, or the merged pull requests, since the last tag: git log <last tag>..HEAD.

Group them by what changed for the user, not by where in the code: New, Improved, Fixed. Each line says what someone can now do, or no longer has to put up with, in plain words. No ticket numbers, and no "refactored" or "updated dependencies" unless it changed something the user sees; then say what. Lead with the change most people will notice, and leave internal work out. Keep it under 150 words for a point release; a big release gets a short paragraph at the top.

Put the notes in CHANGELOG.md under the new version and today's date, and in the Sparkle appcast's or App Store Connect's What's New format if the project has one. Then write a two-line version to post.

When you're done, these should hold:
- Every line comes from a commit.
- Someone who doesn’t know the code understands each line.
- Nothing internal is in it.

End your summary with the next step: "Update your listing" (https://macbase.app/dashboard).

Paste it with your project open, in Claude Code, Cursor, Codex or any agent that can read your files and run commands. Add anything the agent should know about your app after it. The Markdown copy of this page has the same text.

One line

Or hand the agent a link

For an agent that can read a link. It fetches the whole prompt from the Markdown copy.

Read https://macbase.app/prompts/release-notes.md and do what it says.

What you get

What your project has afterwards

• Release notes under New, Improved and Fixed, each line about what changed for the person using the app
• The change most people will notice, first
• Nothing internal, and no ticket numbers
• Under 150 words for a point release
• CHANGELOG.md updated, and the appcast or What’s New text if the project has one
• A two-line version to post

Check

When the agent says it’s done

The prompt ends with these; the agent should say how each holds.

• Every line comes from a commit.
• Someone who doesn’t know the code understands each line.
• Nothing internal is in it.

Questions

What people ask

Why not just the commit messages?

Commit messages say what changed in the code; release notes say what changed for the person using the app. “Refactor the sync engine” means nothing to them. “Sync no longer stops when the Mac sleeps” does.

What about Sparkle and the App Store?

The prompt writes CHANGELOG.md first, then the format the project uses: the HTML in a Sparkle appcast item, or the plain text App Store Connect takes. Both get the same words.

How long should they be?

As long as the changes, and no longer. A point release is a few lines. A big release gets a short paragraph at the top, then the groups. Nobody reads a wall.

More

Other prompts

• Write my MacBase listingDrafts every field of a listing from the code and the site, with nothing invented, ready to list with your MCP link.
• Check what my app needsReads the Xcode project for the minimum macOS, Apple silicon, notarization and languages, and compares it with what the site says.
• Make my app’s site readable by AIA Markdown copy of every page, llms.txt, llms-full.txt, ai.txt and crawler rules, as macbase.app has.
• Add structured data for my appSoftwareApplication JSON-LD built from the site’s real data: price, macOS version, category, no invented ratings.
• Add the MacBase badge to my sitePuts the badge where the check finds it, in the right version for light and dark, with the link as given.
• Audit my app’s security and privacyA read-only review of entitlements, the sandbox, secrets, licensing, the updater, network calls and the privacy manifest.
• Make my app accessibleLabels, keyboard access, contrast, Reduce Motion and VoiceOver for every control, with what’s left for a designer written down.
• Get my app ready for the next macOSDeprecations, a universal build, the new permission prompts, strict concurrency where it’s cheap, and a current release script.