Release notes from git commits and PRs

Automation replaces the manual ritual of 'sitting down on Friday and writing out everything done during the sprint' with a reproducible pipeline. An AI agent reads the repository history, separates what matters from technical noise, and produces a structured draft that an engineer or product manager proofreads in 5-10 minutes instead of writing it from scratch.

Step-by-step process

1. Data collection. The agent connects to the repository (GitHub, GitLab, or another Git hosting) and pulls commits and merged pull requests since the last release — by tag, date, or branch name.
2. Normalization. PR descriptions, titles, labels, issue links, and author names are collected into a unified structure. Technical commits (chore, refactor, test) are flagged but not removed.
3. Classification. The language model sorts changes into categories: new features, fixes, breaking changes, internal improvements. The classification logic is based on conventional commits, labels, or the semantics of PR titles.
4. Summarization for audiences. The agent generates three versions: technical (for developers, with PR links), short (for management — what changed for the business), and customer-facing (without internal terminology, focused on value).
5. Draft for review. The output arrives in Slack, Notion, or a pull request with a CHANGELOG.md template — the engineer edits and publishes it.
6. Publication. Optional step: an automatic post to the release channel, updating the in-app changelog widget, sending an email newsletter to customers.

What automation does NOT do

• Does not replace the tech lead. The decision on what counts as a breaking change or a major release stays with a human. The agent only suggests a classification.
• Does not write marketing copy from scratch. The customer-facing version is a structured draft, not a finished launch post with positioning and a CTA.
• Does not analyze code quality. Metrics such as test coverage, security findings, or architectural decisions do not end up in release notes.

The pipeline is built on Git hosting calls and a single LLM processing step. The custom-code solution is deployed as a cron job, CI step, or manual trigger — all depending on the team's release cadence.

Technical flow

The agent works in three stages: history extraction, LLM processing, draft delivery. Between stages, data is passed in structured JSON, which simplifies debugging and allows adding manual rules without rewriting the prompt.

Implementation steps

1. Defining the release range. The script receives two anchors — previous and current. Options: the latest tag (git describe --tags), date, branch name, or deploy ID from CI. For teams without tags, the approach is "everything merged into main in the last N days".
2. Request to the Git hosting. Commits and pull requests within the range are fetched via REST or GraphQL API (GitHub, GitLab, Bitbucket). For each PR, the following are collected: title, description, labels, author, linked issues, merge timestamp.
3. Pre-processing. Duplicate commits (the same PR squashed) are collapsed. Conventional commits are parsed — if the team uses the format feat:, fix:, chore:, the agent inherits the classification. Without conventional commits, the LLM figures it out from context.
4. LLM call. The LLM receives a structured list of PRs and a prompt with instructions: which categories, which audiences, tone, length. The response is JSON with arrays features, fixes, breaking, internal.
5. Rendering. A templating engine (Mustache, Jinja, or the same LLM in a second pass) converts the JSON into a markdown draft in the team's format — CHANGELOG.md, Notion page, Slack message, in-app modal.
6. Delivery. The draft is sent via webhook to the review channel — the standard option: a pull request with a CHANGELOG.md change so the engineer can see the diff and comment. The alternative is drafts in Notion or a Linear release.

Solution components

Nuances and specifics

• Handling long ranges. For releases with hundreds of PRs, data is split into batches — the LLM processes parts, then an aggregator combines the result. Otherwise, the context overflows and classification quality drops.
• Format stability. The prompt requires JSON with a strict schema, not free-form markdown. This gives a predictable result for automatic rendering and parsing.
• Style memory. If the team maintains a CHANGELOG.md, the agent receives previous entries as few-shot examples — new release notes are written in the same tone.
• Custom rules. The list of PR labels to ignore (for example, internal, dependabot), is set in the config. The LLM does not decide this on its own.

The base version of the automation is deployed in 2-5 business days by a single engineer — hence the complexity label «weekend». Further complexity depends on the team's requirements.

Data and access

• Git hosting with API access. GitHub, GitLab, Bitbucket or self-hosted — a token with read access to history and PRs in the required repositories is needed.
• Release policy. The team uses tags, semantic versioning, or at least a regular merge into main. Without a stable reference point, the range has to be set manually each time.
• Access to the delivery channel. Slack webhook, Notion API token, permission to create a PR in the repository — depends on the chosen publication format.
• Language model API key via Anthropic or a wrapper platform.

Team readiness

• One engineer who maintains the script and owns the access credentials — tech lead or DevOps.
• An agreed set of release notes categories: what counts as a feature, what counts as a fix, which PR labels to ignore. Without this, LLM classification will hit the mark, but not always meet expectations.
• A CHANGELOG.md template or equivalent format in Notion/Linear — even a draft one.

Timelines

• Weekend version (2-5 days): one repository, one audience (technical), publication in Slack or CHANGELOG.md via PR. Minimum prompts, standard format.
• Extension (up to 2 weeks): multiple repositories in a monorepo or multi-service architecture, three text variants (tech/mgmt/customer), integration with Notion and an in-app changelog widget.

For teams with a non-standard workflow (feature flags, release trains, multiple products in a single repository) it is worth budgeting additional time to define the range logic.