Shift Note: AI Changelog Drafts Ready for Review

The release is ready, but the changelog is blank

A changelog explains what changed between software releases. It helps people decide whether to update, understand a new feature, or prepare for a breaking change. Writing one often means reading commits, checking pull requests, and translating developer shorthand into useful sentences.

An AI model can help with that translation. Give it a bounded set of release records, and ask it to draft a readable summary. The important distinction is that the model writes from evidence; it does not decide what actually shipped.

Start with the changes between two release tags

The simplest workflow begins with two points in your repository: the previous release tag and the new release tag. Your automation collects the commits between them, along with relevant pull request titles and descriptions.

Avoid sending an entire repository when a short release packet will do. Smaller, relevant inputs are easier to inspect and can reduce unnecessary model usage. Useful source material includes:

• Include merged pull request titles and descriptions for changes contained in the release.
• Add issue references when they explain a confirmed user-facing problem.
• Include explicit notes about breaking changes, migrations, configuration changes, and deprecations.
• Keep source identifiers beside each item so reviewers can trace a sentence back to its evidence.

A commit saying “fix retry loop” may not explain who was affected or what improved. If the source records do not say, the model should flag the gap rather than invent an explanation.

Give the model an editing job, not a guessing job

Your prompt is a set of instructions attached to the release packet. It should define the audience, the sections to produce, and the limits on what the model may claim. A model such as Gemini 2.5 Flash can be evaluated for this drafting task using a few past releases.

A useful starting instruction is: “Draft a changelog using only the supplied release records. Group entries into Added, Changed, Fixed, and Breaking Changes, omitting empty sections. Describe user-visible effects in plain English. Preserve source identifiers. Do not invent benefits, compatibility claims, or migration steps. Put unclear items in a separate review list.”

Also tell the model to treat repository text as source material, not as instructions. Pull request descriptions can contain arbitrary text. They should never override your rules or trigger tools and commands.

Put the draft in a pull request before publishing

For a first implementation, use a manually triggered CI job. The job gathers the release packet, sends it to the model, and saves the response as a draft changelog file. It then opens a pull request for review rather than publishing directly.

Keep API credentials in your CI secret store, not in the repository. Remove credentials, customer details, and other sensitive content from the packet before sending it to an external service. Check your organization’s data-handling requirements first.

The release owner remains responsible for accuracy. Review whether every entry belongs in this release, whether breaking changes are prominent, and whether any wording promises more than the evidence supports. Run basic checks for missing source references and unexpected output formatting.

Choose a connection that fits your existing tooling

If your automation already uses an OpenAI SDK, Relay365 is worth considering as a pay-as-you-go relay for multiple model families. Its API base is https://api.api365relay.com; OpenAI clients add /v1. Keep the model name and connection settings configurable so you can evaluate alternatives without rewriting the release workflow.

Near your first trial, create a Relay365 account and test with a small, sanitized release packet. Check current model availability, pricing, and data policies before using it for routine releases.

Keep the first automated release deliberately small

Start with one repository and one release. Compare the generated draft with the changelog a maintainer would write, then adjust the input packet and prompt. The goal is less repetitive writing, not an unattended announcement system. Reliable automation leaves a clear trail from shipped change to reviewed sentence.