On a schedule
Write GitHub release notes from commits
When a new tag appears, readable release notes are written from the commits since the last tag and published on the release.
- Runs
- On a schedule
- Apps
- GitHub
- AI
- Yes, uses the built-in AI allowance
- Access
- Contents: read+write
Send this to your assistant
Create a ClickRuntime automation: when a new tag appears on acme/app, write release notes from the commits since the previous tag, grouped into features, fixes and other changes, and publish them on the GitHub release.
First time? Adding ClickRuntime to your assistant takes about two minutes.
Why use it
Why teams use this automation
Cutting a release on GitHub usually ends with someone scrolling through forty commit messages like "fix typo" and "wip" to write the changelog by hand. It happens at the end of a long day, so the notes are skipped, copied from the commit log or so terse that users cannot tell what changed. Support then fields questions that a clear release page would have answered.
When a new tag appears, the run compares it with the previous tag and collects the commits and merged changes between them. ClickRuntime's built-in AI groups them into sections such as features, fixes and breaking changes, and the result is written into the GitHub release for that tag, either as a new release or an update to an existing one.
Maintainers of open source libraries and small product teams that ship often get the most from it, since the notes appear without anyone breaking their flow to write them.
What you get out of it
Every release has readable notes
Users and customers get a grouped list of what changed instead of an empty release page, which cuts the number of questions about whether a bug was fixed in the latest version.
Breaking changes are called out
Grouping commits makes a breaking change easy to spot under its own heading, so downstream users have a fair chance to read it before upgrading and filing an issue when their build fails.
Maintainers keep their evening
Compiling a changelog from raw commits can take an hour on a busy release, and handing that to the AI draft means the maintainer only skims and corrects it. Reviewing a draft is far quicker than writing one.
Release pages stay consistent
Each release follows the same structure, which makes the history easier to scan and gives anyone writing about your project, such as a blogger, an easy source of accurate information.
Compare range is exact
Because the notes come from the diff between two tags and not from memory, nothing merged since the last release is forgotten and nothing from earlier versions is repeated. Late merges still make it into the right release.
How it works
What happens, step by step
Every hour, the automation checks your GitHub repo for a new release tag.
When it finds one, it collects the commits made since the previous tag.
AI turns the commit messages into readable release notes, grouped into features and fixes.
The notes are published on the GitHub release for that tag.
Before it runs live
- Connect GitHub
What you get
Build your own
Need it to work differently?
Your own rules
Conditions, thresholds, filters and exceptions, written the way you'd explain them to a colleague.
Any number of apps
One automation can read from one app and update several others. Over 248 apps are ready, and anything with an API works too.
AI where it helps
Summaries, classification, extraction and drafts use ClickRuntime's built-in AI, with no extra key.
On a schedule or on each event
Runs as often as every 5 minutes, or the moment an app sends an event, and keeps track of what it already handled.
Changes you can ask for
- Act only on the items that match your own rules, and skip the rest
- Change what the AI looks for, or how it writes the result
- Add another app, for example also send it to Slack
- Combine it with other GitHub steps into one automation
Under the hood
The code that runs this automation
from clickruntime import on_trigger, credentials, http, ai, state, report_fetched
def gh(method, path, **kw):
resp = http.request(method, f"https://api.github.com{path}", headers={
"Authorization": f"Bearer {credentials.connection('github', 'work')}",
"Accept": "application/vnd.github+json"}, **kw)
resp.raise_for_status()
return resp.json() if resp.content else None
REPO = "acme/app"
@on_trigger
def run(event):
tags = gh("GET", f"/repos/{REPO}/tags", params={"per_page": 2})
if not tags or tags[0]["name"] == state.get("last_tag"):
report_fetched(0)
return {"released": None}
report_fetched(1)
new, prev = tags[0]["name"], (tags[1]["name"] if len(tags) > 1 else None)
commits = gh("GET", f"/repos/{REPO}/compare/{prev}...{new}")["commits"] if prev else []
log = "\n".join(c["commit"]["message"].splitlines()[0] for c in commits)[:12000]
notes = ai.generate(log or "Initial release", max_output_tokens=800,
system="Write release notes in Markdown with sections Features, Fixes and Other changes. Skip empty sections.").text
gh("POST", f"/repos/{REPO}/releases", json={"tag_name": new, "name": new, "body": notes})
state.set("last_tag", new)
return {"released": new, "commits": len(commits)}FAQ
Common questions
How does it know a new tag was created?
Does it need a GitHub Release to exist first?
Which token permissions does it need?
What permissions does it need?
Does it need AI?
How many runs does it use?
Can I change how it works?
Related
You might also like
Get an AI review on every new pull request
Each new pull request gets a review comment within minutes, checked against your own guidelines.
See how it worksLabel new issues and flag duplicates
New issues are labelled as a bug, feature or question, and likely duplicates get a comment pointing to the original.
See how it worksAssign new issues automatically
New issues get an owner based on their label, and anyone can take an issue by commenting /assign.
See how it worksKeep exploring
Set up “Write GitHub release notes from commits” from your assistant
Copy the prompt above, or connect your assistant first. Free plan, no credit card.