Release Notes Pipeline

Goal

Turn a merged set of user-facing changes into three consistent artifacts: a changelog entry, a short in-app note, and a sales bullet. Each one may say only what the change list says.

Tools required

Direct is the vendor's public site. Affiliate appears only when ShipPlays is enrolled in that program.

• GitHub

  Direct

  The merged pull requests, filtered by a label you actually enforce.

• Linear

  Direct

  Optional, if that is where the human title of the work already lives. Jira works the same way.

• The changelog you already have

  Direct

  Docs, a CHANGELOG file, or a blog. The pipeline does not invent a new home.

Step-by-step setup

1. Make user-facing a real label

   If a change can ship without a label, the pipeline will guess, and guesses put refactors in the changelog as features. Require a label on the release branch, or accept that you will hand-pick the list. Also keep a ten-noun glossary: the words the product uses, such as Projects, not the synonym someone prefers in a blog post.

2. Paste only the user-facing items

   At release time, paste title, the human explanation if you wrote one, and the issue link. Leave internal work out of the paste. The model cannot leak what it never saw. Do not paste the raw git log. Commit messages are for the team.

3. Generate the three artifacts together

   Changelog (one short paragraph plus bullets), in-app note (two sentences, present tense), and one sales bullet a seller can say without lying. They must share the same facts. If an item has no user effect, it does not appear, even if the work was hard.

4. Run the glossary pass and delete hype

   Button names match the product. If the interface says Projects, the note does not say workspaces. Blazingly fast dies unless you pasted a measurement. You are the editor. One person edits all three so they cannot drift.

5. Publish together

   Changelog and in-app note go out together. The sales bullet goes to the channel sellers already read. The agent does not tag the release or deploy.

6. Fix the source, not the prompt, when support is surprised

   When someone asks what changed and the answer is not in the note, add the missing fact to the pull request template. A longer prompt will not remember a button you forgot to mention.

Exact prompts

Write three artifacts from this list. They must not disagree. Do not add a change that is not in the list. Do not describe internal refactors. Do not include exploit detail. "Fixed an access check" is enough if that is all the list says.

Glossary (use these nouns; do not invent synonyms):
{GLOSSARY}

User-facing changes:
{LIST}

Return:
1. Changelog: one paragraph of at most four sentences, then bullets. Past tense for fixes, present tense for what the user can do now. No adjectives you cannot point to in the list.
2. In-app note: two sentences, present tense, under 50 words.
3. Sales bullet: one sentence a seller can say. If the list is only fixes, the bullet says what is more reliable, not that there is a new product.
4. Left out: items that had no user effect, and why.

If the list is empty, say there is nothing to announce. Do not write a release anyway.

Check three release artifacts against the glossary and the source list. Do not rewrite for style. Do not add a feature to make the note sound finished.

Glossary (the only nouns allowed for product objects):
{GLOSSARY}

Source list (the only facts allowed):
{LIST}

Artifacts:
{ARTIFACTS}

Return these sections, in this order:
- Noun conflicts: quote the artifact phrase and the glossary noun it should have used. If none, write none.
- Measurements: quote any number, duration, or percentage that is not in the source list. If none, write none.
- Extra features: quote any sentence that implies a capability the source list does not contain. If none, write none.
- Disagreement: quote any fact that one artifact states and another contradicts or quietly drops in a way a customer or a seller would notice. If the three agree, write they agree.
- Publish: yes or no. No if any section above found a problem.

A clean pass still names what you compared: nouns, measurements, features, and agreement across the changelog, the in-app note, and the sales bullet.

Expected results

• One changelog entry, one in-app note, and one sales bullet written from the same labeled list.
• The same facts in all three. A fix stays a fix. A new action stays a new action.
• Button and object names that match the glossary, so the note says Projects when the product says Projects.
• A publish decision from the glossary pass: yes, or a quoted line to cut before anyone ships it.

Guardrails

• No security-fix details that would help someone abuse the bug. Say that you fixed a check, unless your disclosure policy says more.
• No customer names unless that customer agreed to be a reference.
• Measurements only if they are in the paste.
• The agent does not tag, merge, or deploy.
• Internal work stays out of customer copy even when it was difficult.

Common mistakes

Related

• Incident Update Agent
• Outbound Account Research Sprint