The build is green, the binary is uploaded, and yet you find yourself staring at the empty "What's New in this Version" field on App Store Connect. If you ship apps as a one-person operation, you know that exact moment. For years I would burn at least half an hour on every release writing those notes, and the English version was usually whatever Google Translate handed back.
Once Antigravity became part of my routine, that final stretch shrank dramatically. Hand it the commit history, name the audience, set the character limits, and bilingual release notes come out in one pass. This article walks through the workflow I actually use, with the prompts and the small refinements that make the output worth shipping rather than another generic AI paragraph.
Make your commits worth feeding to Antigravity
Antigravity is only as good as the material you give it, and most release-note generation problems start in the commit log. If you tighten three things first, every later step gets easier.
- Use Conventional Commits so the AI can tell features from fixes (
feat:,fix:,perf:,refactor:). - Reserve
feat:andfix:for user-visible changes; everything internal goes underrefactor:orchore:. - Tag every release in Git so you can extract just the commits between the previous version and now.
With tags in place, the diff is trivial to pull:
# Grab every commit message between the last release tag and HEAD
git log v1.4.0..HEAD --pretty=format:"- %s%n%b" --no-merges > /tmp/release-commits.txt
# Sample output:
# - feat: add a recently-opened wallpapers row to the home screen
# - fix: correct toolbar position on iPad Pro
# - perf: speed up image prefetching by 30%
# - refactor: clean up the settings screen data layerOnce that file exists, the rest of the workflow is about asking Antigravity to keep only what users will notice—and to phrase it the way users actually talk.
Generate Japanese and English in a single prompt
Here is the template I paste into Antigravity for almost every release. I prefer pulling the commits with @file instead of pasting them inline, because the file stays editable and you can rerun without re-pasting.
@/tmp/release-commits.txt
This app is "Wallpaper Notes," a simple memo app for iPhone and Android that lets people
keep little notes inspired by photos. The audience is not technical—mostly users who
care about photography and art.
Using the commit history above, please draft release notes for the App Store and
Google Play, with these constraints:
1. Japanese version (max 200 characters, complete sentences ending in periods)
2. English version (under 500 characters, friendly tone)
3. Drop internal refactors—they are invisible to users
4. Avoid technical terms (API, repository, etc.); describe what the user can do
5. Three to four flowing sentences, not a bullet list
6. Include one sentence that explains how this changes the user's day
Format:
【JA】
(text)
【EN】
(text)The leverage in this prompt is the explicit list of constraints. Generative AI loves to produce balanced, neutral copy; the more specific the rules, the more personality survives. Asking for a length cap, banning jargon, and steering the closing line toward the user's experience together do more for tone than any "be friendly" instruction ever does.
I include the English length cap up front rather than tacking it on later because English release notes tend to balloon to 1.5–2x the Japanese length. Without that cap you will routinely overrun Google Play's 500-character ceiling and have to truncate by hand.
Trim to the limits each store actually rewards
The first draft will usually be too long. The practical limits in each surface are not what the documentation says—they are what the UI actually shows.
- App Store "What's New": technically up to 4,000 characters, but the truth is that the first ~100 characters carry the message because of the collapsed display.
- Google Play "What's new": 500 characters, hard limit.
- In-app What's New dialog: realistically three lines plus one button.
This is where a second pass with Antigravity earns its keep:
Please rewrite the Japanese version so the first 80 characters land the headline.
The opening sentence alone should tell the user what is exciting about this update.
Anything cut from the first part can become a short follow-up.
Do the same for the English version, with the headline landing in the first 100 characters.The "front-load the headline" rule extends well beyond release notes. It is the same principle that drives effective in-app announcements, press releases, and blog intros. Once you find yourself typing this prompt for the third release in a row, it is time to save it as a Custom Command.
Spin off the SNS posts and in-app banner from the same draft
The real time savings come from generating every adjacent piece of copy in the same Antigravity session, while the context is still fresh.
From the Japanese and English release notes you just produced, please derive:
1. An X (formerly Twitter) post in Japanese (max 140 characters, max 1 emoji, 2 hashtags)
2. An X post in English (under 280 characters, max 1 emoji, 2 hashtags)
3. In-app banner copy: a 20-character title and 60-character body, in both languages
For the X posts, pick exactly one feature to highlight—the one most likely to make someone
want to open the app. Do not try to mention everything.I run all three prompts—generate, trim, derive—in one Antigravity conversation so the context carries through. There is no need to re-explain the app each time, and the tone stays consistent across the surfaces.
The instruction to pick exactly one feature for social posts is deliberate. Left to its own devices, AI tends to give every change equal billing, and the post loses its hook. The single-feature rule is well-known in App Store Optimization (ASO) circles, and from my own experience it is the difference between an X post that converts and one that scrolls past.
Save the whole thing as a Custom Command so you stop retyping it
By the third release you will be tired of pasting the same prompt three times. Antigravity's Custom Commands let you bundle the whole workflow into a single slash command.
Drop a file at .antigravity/commands/release-notes.md in your project, with the three prompts written in order:
# /release-notes
Convert the changes since the last release tag into bilingual release notes
plus the matching social posts.
## Step 1: Gather material
```bash
git log $(git describe --tags --abbrev=0)..HEAD --pretty=format:"- %s%n%b" --no-mergesStep 2: Generate release notes
(the same prompt from "Generate Japanese and English in a single prompt")
Step 3: Trim to store limits
(the prompt from "Trim to the limits each store actually rewards")
Step 4: Derive SNS and in-app copy
(the prompt from "Spin off the SNS posts and in-app banner")
If you have not built a Custom Command before, the Antigravity Custom Commands master guide walks through the file format and how Antigravity discovers them.
## Try the smallest version on your next release
You do not have to commit to the entire workflow on day one. For your next release, the single highest-leverage change is just running that first prompt—handing your `git log` output to Antigravity and asking for both languages with explicit constraints.
The practical advice I would offer: do not ship the AI's output verbatim. Rewrite one or two phrases in your own voice. AI-generated copy reads like AI-generated copy unless a human leaves a fingerprint somewhere, and on a release note that single line of "your voice" is what makes users feel like a real person is shipping the app.
The more time you save on writing release notes, the more time you can put into the work that actually moves the product forward—deciding what to build next, reading user feedback carefully, and noticing the small UI details that compound across releases. For a solo developer, the bottleneck is rarely typing speed. It is thinking time.