We use a small number of cookies to keep you signed in and, with your permission, to understand how the product is used so we can improve it. See our privacy policy.

releasedog
PricingDocsChangelogBlogAbout
Log inGet started
All posts
April 7, 2026·6 min read·The Releasedog pack

AI-drafted release notes that don't sound like a robot

Generative AI can write a changelog in seconds. Here's how we prompt it so the output reads like a human wrote it — because a human still edits it.

aillmrelease-notesprompting

Most AI-generated release notes are easy to spot. They're technically correct, structurally fine, and completely forgettable — the writing equivalent of stock photography. If you're going to use a model to draft your changelog, the goal isn't to save writing time. It's to get a good first draft so a human can spend their time on the last 20%.

Feed it the right source, not all of it

Throwing every commit message at a model produces a wall of noise. We filter upstream: merged PRs tagged with a user-visible label, or Jira tickets closed in the release's version. Fewer inputs, more signal.

Prompt for voice, not just structure

"Write a changelog" gets you a changelog. "Write in the voice of a senior engineer explaining to a friend over coffee" gets you something a person might read for fun. Give the model a voice sample from a past release you liked — it matches tone better than any list of rules.

Ban the obvious tells

Add explicit "don't use" lists to your prompt:delve, leverage, seamlessly, unlock, in today's fast-paced world. The corporate-blog lexicon is the fastest way to signal "AI wrote this."

Ground it in facts, then let it write

The pattern that works: first extract the raw facts (what changed, by who, when, affecting what), then ask the model to narrate over those facts. Two-step prompting beats one-shot generation because it lets you check the facts separately from the prose.

Always edit. Always.

The model gets you to 80%. The last 20% — cutting the one weird sentence, adding the inside joke, linking to the right doc — is what makes the changelog yours. If nobody edits the draft, your users will notice, and they'll stop reading.

A prompt that holds up

Here's the skeleton we use inside Releasedog, adapted for your own use:

  • Role — "You are an engineer writing release notes for other engineers."
  • Voice — paste 1-2 paragraphs from a previous release you liked.
  • Structure — headline, new, better, fixed. 1-3 bullets per section.
  • Constraints — no marketing adjectives, no hype, plain English, active voice.
  • Input — the filtered PR list or ticket list, with titles and short bodies.

Done well, the draft you get back is something you'd be happy to publish with a five-minute polish. Done badly, it's something users scroll past. The prompt is the difference.

keep reading
  • April 14, 2026Shipping changelogs your users actually readMost release notes get ignored. Here's the small set of habits that turn a changelog into something users look forward to.
releasedog

Ship changelogs your users actually read. Built for indie devs and small teams.

made with 🦴 by a very small pack

Product
  • Features
  • Pricing
  • Changelog
  • Security
Resources
  • Docs
  • Blog
Company
  • About
  • Contact
Legal
  • Terms
  • Privacy
© 2026 releasedog — good boy, great shipper.v0.1 · no dogs were harmed in the making of this product