Generating Release Notes With AI From Finished Tasks

The most reliable way to get release notes from AI is to give it the finished tasks, not the commits. Connect an assistant to your board, have it list what reached Completed since the last release, group it by kind (new features, improvements, fixes), and write one plain sentence per task for the reader you name. Then a person reads every line against its task before anything is published. The assistant saves you the blank page; it does not get to decide what shipped.

Three routes, and what each reads

If your code is on GitHub, you already have one option without any AI. GitHub’s automatically generated release notes↗ (opens in a new tab) add a list of merged pull requests, the contributors and a link to the full changelog when you press Generate release notes on a draft release. A .github/release.yml file groups pull requests into headings by label and excludes labels or authors you name.

So can GitHub Copilot generate release notes? Yes, through a separate route: GitHub’s copilot-release-notes action↗ (opens in a new tab) reads every pull request merged between two refs, including titles, bodies, labels and diffs, and writes structured notes, following a style guide you keep in .github/release-notes-instructions.md. It needs an active Copilot licence and a token, runs in GitHub Actions, and its README describes it as under active development.

Both of those start from pull requests. The third route, the rest of this article, starts from tasks. Use it when the people reading the notes care about what they can now do, when one task took several pull requests, or when some of what shipped was never code at all: a changed process, a new template, a fixed piece of documentation.

Why tasks make better raw material

The long-standing advice from Keep a Changelog↗ (opens in a new tab) is that changelogs are for humans, not machines, and that commit log diffs are a bad source because they are full of noise. A pull request title is written for a reviewer. A task title, if your board is kept well, is written for whoever asked for the work, which is much closer to the reader of a release note.

A task also carries the one field that decides which section a line belongs in. On fenbs every task is a feature, an enhancement or a bug, so the grouping is data, not the model’s guess. The same split is explained in features, enhancements and bugs.

Get the board ready first

• Titles a user would understand. “Fix null in exportRows” becomes “CSV export no longer drops the last row”. It is cheaper to fix the title on the task than to fix it in every draft.
• The right kind. A bug filed as a feature ends up under New. Correct the kind on the task and the notes follow.
• A test record. On fenbs, a finished task carries a test status and test notes saying how it was checked. Untested work is a question for the reviewer, not a line in the notes.
• How it ended. When a task is moved to Completed, the board also records how it ended: Completed, Won’t fix, Duplicate, Cannot reproduce or Obsolete. Only Completed counts as delivered; the rest are closed and not built.

The drafting prompt

Connect the assistant to the board over MCP (the steps for Claude, Claude Code and ChatGPT are on their own pages) with read access at least. Then give it the job in one message. The tool names below are fenbs’s; any board with an MCP server will have equivalents.

Draft release notes for version 2.4 of the Billing project.

1. Call fenbs_list_items with lane "done" and project "Billing".
   Keep tasks updated since 2026-09-01 (the 2.3 release).
2. Skip any task whose category is already "Released 2.3".
3. Group by kind: feature -> New, enhancement -> Improved, bug -> Fixed.
4. One sentence per task, written for customers: what they can now do,
   or what no longer goes wrong. No refs, no internal names, no file paths.
5. Do not invent detail. If the title and note do not say what changed
   for a user, put the task under "Needs a person" instead.
6. After the notes, list separately: tasks with testStatus "untested",
   and every ref you used, so I can check each line.

The last two instructions do most of the work. “Do not invent detail” turns vague tasks into a short list for you instead of confident sentences about features that do not quite exist. The list of refs turns the review into ticking lines, not searching.

What to leave out

• Work nobody outside the team will notice: refactors, dependency bumps, build changes. Useful in an internal changelog; noise in customer notes.
• Anything closed as Won’t fix, Duplicate, Cannot reproduce or Obsolete. They sit in Completed but were not delivered. Check the card if the assistant cannot tell.
• Security fixes described in detail before everyone has the fix. “Fixed a security issue in sign-in” is enough until it is safe to say more.
• Customer names, including the customer who reported the bug. Thank them privately.
• Internal refs and codenames, for an outside audience. Keep them for the internal version, where they are exactly what people need.
• Numbers the task does not contain. If the note says “faster”, the release note says faster, not “40% faster”.

The human review

1. Read each line next to its task. Does the sentence say what the task did, no more?
2. Clear the “Needs a person” and untested lists. Either you can say what shipped, or it waits for the next release.
3. Read the whole draft once as the customer. Would they know what to try first?
4. Decide the order. The assistant groups; you choose which change leads.

That is the same review you would give any assistant output that others will read; verifying AI-generated work covers the general method, including how to record that the check happened.

Mark what went out, so it is never listed twice

The easiest mistake in release notes is listing last month’s fix again. Once the notes are published, ask the assistant to set the category of every task it used to “Released 2.4” with fenbs_update_item, and to comment on each one with a link to the notes. Next time, the prompt skips anything with a Released category, and the task itself says which release it went out in. Anyone looking at the task later can see when a customer first got it, and History shows who marked it. A task has one category, so if yours already sort tasks by area, rely on the comment instead and have the prompt skip tasks that carry one.

If you release often, keep the prompt as a saved instruction rather than retyping it. In Claude, that is a skill; see Claude skills for project management for a release-notes skill and others like it.