Standing service release-notes-drafted-for-every-release-each-month · revised 12 October 2026
Standing service
Have customer release notes drafted for every release, each month
Each release in the month gets a developer changelog and a customer-facing draft with every line linked to a merged pull request. You edit and publish; security fixes are flagged, not written up.
This starts a conversation by email. Nothing is charged, and nothing is read or run, until we have agreed scope, access and terms with you in writing.
The responsibility you hand over
Each release needs a note that customers can read. Teams under pressure skip it or paste raw logs, and customers stop trusting that releases tell them anything.
Who it’s for: A product team that ships several releases a month and wants notes ready for each.
Usually starts when: Notes are late or skipped when the team is busy shipping.
The result: For each release in the month, up to 6 a month, you receive a developer changelog and a customer-facing draft with every line linked to a merged pull request, a coverage table and a flagged list. A monthly summary shows what was drafted.
What stays true, and what we do about it
No response-time guarantee beyond the written turnaround is published for this new service.
Drafts are written in working hours, within a turnaround agreed in writing. There is no round-the-clock cover.
What must remain true
- Every merged pull request in each release range is used once or excluded with a reason
- Every customer line links to a pull request, and no security pull request is written into customer text
What we watch
- Merged pull requests in each release range, read-only
- Your tone guide
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A release is tagged or dated. | We draft both notes within the agreed working hours. Linked job: Customer release notes from merged PRs |
| A pull request is labelled security or looks like a breaking change. | We list it first in the flagged list and leave it out of customer text. |
| A month closes. | We send a summary of releases drafted and what was flagged. |
We do on our own
- Read merged pull requests
- Draft the notes and flag items
We ask you first
- Publishing anything
- Wider access
- Any change to what is flagged
We escalate to you when
- Pull request bodies become empty
- A line cannot be linked to a change
- A release range is unclear
How you know it held. Each quarter you check three published notes against their diffs and the summary shows any line with no matching change.
How we keep it true
This service is never finished. Each month's summary shows whether what it watches stayed true, and it continues until you end it.
Release notes your customers can read, drafted from what you merged Job Optional
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.
Bought separately, once
The one-off job that tests the drafts on your last three releases.
What is included, and what is not
- Two drafts per release
- The coverage table and flagged list
- A monthly summary
Included
- One repository and up to 6 releases a month
- Two drafts per release with a coverage table and a flagged list
- A monthly summary, and a quarterly check of three published notes against their diffs
Not included
- Publishing or sending notes
- Deciding what to disclose, including security fixes
- Translations or marketing copy
- Releases without usable pull request descriptions
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each release has both drafts, and every merged pull request in the range is used once or excluded with a reason.
Evidence: The drafts and the script coverage count.
Every customer line has a pull request link, and no pull request labelled security appears in customer text.
Evidence: A script check of links and labels.
Each quarter you check three published notes against their diffs and find no behaviour absent from the diff. This describes those three notes, not a rate.
Evidence: The three notes with diffs and your verdicts.
Sign-off. You read each summary and tell us whether the tone and cap suit you. A month counts as delivered when you have received the drafts and the summary.
If it fails. If we cannot read the pull requests we say so and do not guess. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- Usable pull request titles and bodies
- Tagged or dated releases
- A Read-only account or an export
- A person who edits and publishes
We stop and tell you if
- Pull request bodies become empty
- More than 6 releases a month for three months
- Notes are published without anyone editing them
What could go wrong
The service writes documents. Nothing is published or changed in your repository. Ending the service changes nothing.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A line states behaviour that the change does not show. | Every line is linked, a script checks links, and a quarterly check compares published lines with diffs. |
| A security fix is disclosed too early. | Security pull requests stay out of customer text and are 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 edits and publishes every note. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
Questions
Do you publish the notes?
No. You edit and publish.
What if a release has no good descriptions?
We stop and say so. The hygiene job fixes descriptions first, then we start.
Do you tell customers about security fixes?
No. We flag them for your decision and keep them out of the draft.
Is there a test run before it starts?
No. The one-off job replays three past releases. This monthly service has no replay, only a quarterly check of three published notes.
Also part of
Send an enquiry
Send us
- How many releases a month and where notes go
- Your tone and words to avoid
- No pull request text or logins in the first enquiry
Later, once you agree
- A Read-only account or an export per release
- The tone guide
- 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-for-every-release-each-month” as the subject.