📢 Release Notes from Merged PRs
Auto-generate release notes from merged PRs, grouped by type (features/fixes/internal), ready to paste into your changelog or email to customers.
The problem
Release notes are either written at the last minute (incomplete), delegated to a junior who doesn't know what shipped (inaccurate), or skipped entirely (invisible work). Customers don't know what changed; support doesn't know what to say; marketing has nothing to post.
The outcome
When you tag a release, the agent reads every PR since the last tag, groups them into Features / Fixes / Internal (hidden from customer notes), and writes customer-facing copy. You review, tweak, ship. 3 hours of toil → 15 minutes of review.
Why OpenClaw
Release notes are batch work triggered by a git tag. OpenClaw can be started by an inbound webhook (see its automation docs), so a CI step on tag push can kick it off. Self-hosted, so a release with 50+ PRs costs model usage, not a per-seat fee.
Alternatives worth considering
- Claude Cowork — For teams doing infrequent releases, paste the PR list into a Project and iterate manually
Setup steps
-
Step 1: Define release-note labels
Add PR labels: feature, fix, internal, breaking, security. Train the team (or auto-label from PR title patterns). The agent uses labels to group.
-
Step 2: Trigger on tag
When a release tag is pushed, have CI call OpenClaw's inbound webhook. It fetches all PRs since the last tag with gh, filters by label, and writes customer-facing copy for feature, fix, breaking and security only. 'Internal' is excluded.
-
Step 3: Write for two audiences
Customer release notes (benefit-focused, plain language) and internal changelog (complete list including 'internal' PRs). The agent produces both from the same data.
-
Step 4: Add the email draft
Optional: the agent also drafts a customer email announcement highlighting the 2–3 biggest features. You send it manually.
Example prompt
Given these merged PRs since the last release tag, write customer-facing release notes. Group by: New, Improved, Fixed. Translate engineering language to user benefit. Skip anything labeled 'internal'. Flag any PR whose label seems wrong.Pitfalls to avoid
- Exposing internal work in customer notes. Label discipline matters. If an 'internal' PR gets mislabeled as 'feature', customers see work they shouldn't. Have the agent flag low-confidence classifications for human review.
- Writing in engineer voice. 'Refactored the user service for performance' means nothing to customers. The prompt must translate: 'Pages load 40% faster.'
Cost breakdown (monthly)
| Item | Cost |
|---|---|
| Model API (per-PR summaries and customer copy) | See the model pricing table |
Cost: Model usage only. Model rates change often; check the model pricing table or the cost calculator for current figures.
Related guides
← Back to all use cases · Compare platforms at the decision guide.