Job release-notes-drafted-from-merged-pull-requests · revised 12 October 2026
Release notes your customers can read, drafted from what you merged
For each release you get a developer changelog and a customer-facing draft where every line links to a merged pull request. You edit and publish. Tested on your last three releases.
You might be seeing
- Customers get a list of commit messages they cannot read
- Nobody has time to write notes for each release, so they stop
No passwords, keys, card details or admin invites needed to start.
What usually happened
A raw changelog lists what developers did, not what customers can now do. Writing customer notes by hand costs time every release. A tool that drafts them can state behaviour that is not in the change, or reveal a security fix before you want to say so.
Who it’s for: A small product team that ships often and whose customers ask what changed.
Usually starts when: Release notes are skipped, pasted raw from commit logs, or rewritten by hand by whoever has time.
The result: For each release you receive a developer changelog and a customer-facing draft in which every line links to a merged pull request or issue. A coverage table shows every merged pull request used or excluded with a reason, and a list flags possible breaking changes. You edit and publish; we publish nothing.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- The two drafts for the upcoming release
- The replay of three past releases with ratings
- The coverage table
- The flagged list
Included
- One repository and the merged pull requests in each release range
- Two drafts per release: a developer changelog and a customer-facing note
- A coverage table, with each merged pull request used once or excluded with a reason
- A flagged list of possible breaking changes and of pull requests labelled as security, left out of customer text for your decision
- A replay on your last three releases and one upcoming release
Not included
- Publishing or sending notes to anyone
- Deciding what to disclose, including any security fix
- Claims about behaviour that the change does not show
- Pull requests with empty bodies, which need the hygiene job first
- Marketing copy or translations
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every merged pull request in each release range appears once in the coverage table or is excluded with a reason, checked by script against the export.
Evidence: The script count and the coverage table.
Every customer-facing line cites a merged pull request or issue link.
Evidence: A script check for lines without a link.
Your person checks 10 sampled customer lines against their diffs and finds no behaviour absent from the diff. Ten lines is a tripwire and shows no rate.
Evidence: The 10 lines, their diffs and your person's verdicts.
On your last three releases, your person rates the customer draft publishable with minor edits for at least 2 of the 3; with three releases this is a small sample, it shows no rate, and the report says so.
Evidence: The three ratings.
Sign-off. Your person reads the drafts and the ratings and signs off in writing. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- Merged pull requests with usable titles and bodies for the last three releases
- A person on your side who edits and publishes
- Either an export of the pull requests or a Read-only bot account
We stop and tell you if
- Most pull request bodies are empty, so the notes would rest on titles only
- Releases are not tagged or dated, so the range is unclear
- The pull requests hold confidential customer names
What could go wrong
The job writes documents; nothing is published or changed in your repository. Our copies of your pull requests are deleted when the job ends.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A customer line states behaviour that the change does not show. | Every customer line links to a pull request, and you check 10 sampled lines against the diff; zero invented behaviour is required in the sample. |
| A security fix is described before you want to disclose it. | Pull requests labelled security are left out of customer text and flagged for your decision. |
| Pull request text carries instructions meant for the model. | Pull request titles and bodies are treated as data: the model gets the text and returns drafts a script checks, with no tools, no network and no secrets. |
A separate automated reviewer checks the work before hand-over. A named person on your side checks 10 sampled lines against the diffs, edits and publishes. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the release ranges, the tone and what is never disclosed
- Receive the pull request export for three past releases and the upcoming range
- Draft both notes with every line linked to a pull request
- Run the coverage script; flag possible breaking changes and security pull requests
- Separate automated reviewer checks lines against diffs; you rate the replay
- Hand over the drafts, coverage table and flagged list
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
To have notes drafted for every release, a monthly service is offered separately.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing managed lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Use GitHub's generated release notes and add a one-line customer summary by hand.
- Ask the developer who merged each change to write one customer sentence in the pull request template.
Questions
Do you publish the notes?
No. You edit and publish. We never send anything to your customers.
What about security fixes?
They are left out of customer text and flagged. You decide how and when to say anything.
What if our pull request bodies are empty?
Then we stop and say so. The hygiene job fixes descriptions first, then we start.
Send an enquiry
Send us
- How often you release and where notes go today
- Whether pull request bodies describe the change
- No pull request text or logins in the first enquiry
Later, once you agree
- An export of the pull requests for three past releases and the upcoming range, or a Read-only bot account
- Your preferred tone and any words to avoid
- The name of the person who edits and publishes
You keep the repository and publish the notes; we use a dedicated bot account with the least access that works (read-only first), work on a fork or branch, and you merge, read-only. Pull request titles and bodies are treated as data: the model gets the text and returns drafts a script checks, with no tools, no network and no secrets. Our automated agents read the files you send in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “release-notes-drafted-from-merged-pull-requests” as the subject.