Before
Read every PR manually, rewrite notes by hand, and patch missing QA/support context before release.
RT
Release Trace
BETAReviewable release notes from GitHub diffs
Release Trace / strict release review
Release notes you can trace back to source
Release notes that survive review.
Turn a GitHub release range into public notes, QA summary, and support brief with source-linked bullets. Current beta scope is GitHub-only.
With Release Trace
Pick from..to, review generated public/QA/support summaries, then copy final text with confidence.
Example output (public notes)
Improved onboarding clarity and fixed purchase restore retry handling for users on v2.13.0.
GitHub diff in, copy-ready text out.
One release range gives public, QA, and support channels.
Every generated point stays reviewable with source traceability.
Release package
v2.12.0 → v2.13.0
GitHub diff
Source range
PR #412 Improve onboarding copy and activation states
PR #417 Fix failed retry handling for payment restore
commit 8fa12e4 Reduce startup work on cached sessions
PR #423 Refactor analytics event mapper
Public notes
Improved onboarding clarity for first-run users.
source refPR / commit linked
Fixed restore flow retry handling for failed purchases.
source refPR / commit linked
QA summary
Regression-check restore after network interruption.
source refPR / commit linked
Verify startup on cached sessions and warm launches.
source refPR / commit linked
Support brief
Restore issues should no longer block paid users.
source refPR / commit linked
Onboarding wording changed on first-run screens.
source refPR / commit linked
Traceability
Every bullet keeps a source reference.
Review the output against the PR or commit it came from.
Release package
One diff becomes three outputs.
Public notes, QA summary, and support brief from the same range.
Method
Facts first. Model second.
The model rewrites the release. It does not invent it.
Why Release Trace wins
Better when the hard part is proving what shipped.
Built for release review, not just for writing a paragraph.
Release Trace edge
Every bullet can be inspected back to a PR or commit.
Release Trace edge
The same release range becomes public, QA, and support outputs.
Release Trace edge
Noise filtering happens before text generation.
Release Trace edge
The product is optimized for review, not only for publishing.
AI + Security
Explicit about what the model does and what it does not do.
Short version of how the product works today.
AI
The model rewrites the release.
- Structured PR and commit inputs go into the model.
- Source refs stay attached to every bullet.
- The model does not invent source links.
Security
GitHub access goes through a GitHub App.
- No personal access token in the workflow.
- The current implementation sends normalized PR and commit text, not raw patch diffs.
- Review happens before anything is published.
Competitive framing
Not better at everything. Better at one job.
Based on public positioning from official product sites.
If your job to be done is...
Best fit
Why
Fast default notes inside GitHub
GitHub auto-generated release notes
Best when a PR list is enough.
Changelog pages and release distribution
ReleasePad or ReleaseNotes.io
They optimize for publishing and delivery.
Quick AI draft from a git diff
Release The Notes!
It optimizes for fast draft generation.
Reviewable release package for the team
Release Trace
Source-backed notes for public, QA, and support.
Release Trace in one line
Better when the team needs notes it can review, question, and verify.
Workflow
Narrow enough to stay sharp.
Three steps. One release package.
01
Choose two tags
Build the release range from real PRs and commits.
02
Filter the noise
Keep user-facing work and drop internal clutter.
03
Review and ship
Edit bullets with source refs still visible.
Waitlist
Get early access.
Best fit for teams that still write release notes by hand.
GitHub-native
Review before publish
Public, QA, support