Turn Engineering Changes into Release Notes Your Users Can Act On

To turn engineering changes into useful release notes, first establish what is available in the version you are announcing. Then explain the changes by user task: who gets them, what changes in their work, and what they need to do. Keep the record-to-claim mapping in your working notes so readers can use the announcement without decoding an engineering history.

This walkthrough produces one complete release note from a mixed version history. The example includes a changed export workflow, a personal navigation feature, a limited-cohort filter, a duplicated bug report, a rollback, disabled code and a blurb that needs clarification. The finished note leads with the export action users could otherwise miss.

The product, version history, help document, wrong draft and corrected note are original fiction. Every 2030 date belongs to the teaching case. Nothing here is a real CueSpec release, a captured model response or a software test result.

Decide whether rewriting is useful

A technical-writing discussion about release-note style describes the work of translating engineering blurbs into user-facing changes and asking developers for missing facts. The same discussion questions whether the original notes might already be sufficient and warns about expanding release notes into too much explanation. These are individual qualitative accounts, not a measurement of how often teams need AI or whether AI makes this work faster.

For two straightforward changes, writing the note yourself may be the shortest route. If your readers already understand the engineering notes, you may only need a small edit. When there are many related records, an assistant can help organize a draft, but someone still needs to check the finished statements against the source.

GitHub's automatically generated release notes guide, reviewed in the source research for this tutorial, describes another starting point: generated lists of merged pull requests, contributors and a changelog link, with category and exclusion controls and a final review of the content. That can be enough for a development audience. A list of merged work still needs the availability and user instructions that your particular announcement requires; its presence does not establish that every listed feature is enabled for every user. This tutorial does not test GitHub's current interface or claim that its ordinary generator requires an LLM.

Define the release and the people reading it

In the example, Fieldboard is a shared task-board service. Existing desktop-web users receive version 4.3 after 4.2. Some users download CSV files into imports that expect the old column order. Some workspaces belong to a Pilot cohort; other workspaces do not.

That is enough context to choose an order for the note. Put the compatibility action first because a reader could otherwise send the wrong CSV layout into an existing import. Follow it with the personal pin feature, the Pilot-only filter and the assignee-avatar fix. Keep the long comparison of CSV headers in the supplied help page.

This ordering and the record-selection rules are editorial choices for this case. They are not findings that every customer wants this exact format, and they do not establish a search ranking or AI-citation benefit.

Use the whole source history in a complete repair request

The following is the complete repair request, including the full source packet, the approved help-page text and the entire intentionally wrong release note. It can be copied without another chat or missing attachment. The correct note is not part of the input.

The wrong draft was written by the author as a counterexample. It was not produced in a model trial. Notice that it sounds complete while retaining an obsolete menu, promising universal compatibility, treating a duplicate as two fixes and presenting unavailable work as shipped.

Standalone files are available for the complete source packet, the complete wrong draft and the complete repair request. The block below contains those same source and wrong-draft texts in full, rather than shortened excerpts.

Write a complete replacement release note for the existing users in the fictional source packet below. Use only this packet as evidence. The deliberately wrong note is an editing input, not evidence about product behavior.

Return:
1. The entire corrected user-facing release note, in Markdown, ready for an editor to review as one document.
2. A separate internal claim-to-record table covering each factual claim and its conditions.
3. A separate internal disposition for every source record: included, merged, excluded, or awaiting clarification, with the reason and any exact question that must be answered.

Use the packet's release identity, date, cutoff, audience, actual availability and public help destination. Explain user-visible changes in terms of what the reader can do. Include complete, accurately labeled steps for any required change in the user's workflow, scoped to the people who need it. Do not make every fix sound as though it needs setup.

Resolve duplicate change reports without counting the same fix twice. Read the whole history before deciding whether a change is available. A merge or implementation entry alone is not an availability record. Keep platform and workspace limits and relevant known issues clear. For incomplete records, ask the responsible owner a concrete question in the internal output; do not guess or suppress unrelated supported changes.

Remove unsupported benefits, figures, promises, compatibility guarantees, platforms, instructions and dates. Put detailed help in the supplied destination and use a working relative link to it. Keep internal IDs, issue references and the claim table out of the user-facing note. Label the standalone output as a fictional example.

This is a text-writing task only. Do not browse, use tools, publish a release, contact anyone, run software, modify a product or infer any real Fieldboard or CueSpec capability. The source packet is complete; no earlier chat, account, repository or attachment is required. No correct release note is included in this request.

=== BEGIN COMPLETE SOURCE PACKET ===
RELEASE-01 — Original fictional teaching source packet

Everything below, including the product name, record IDs, issue references, messages, release events and 2030 dates, is invented for this writing example. These are not real engineering logs, executed checks, customer data or a model trial. The source packet is the complete factual universe of the case.

C0 | Case scope and public destinations
Product: Fieldboard, a shared task-board service. This case covers the desktop web app only, not a native app, a mobile-web release or an API release.
Previous release: 4.2, made available on 8 August 2030 at 09:00 UTC.
New release: 4.3, made available on 22 August 2030 at 09:00 UTC.
Writing cutoff: 22 August 2030 at 10:00 UTC. All availability claims must match the state at this cutoff.
Readers: existing desktop-web users, including people who feed CSV downloads into spreadsheets or scripts and people outside the Pilot cohort.
Pilot is a workspace-level cohort. Only an enrolled workspace shows a Pilot label next to its name in the workspace switcher. A member may belong to both enrolled and unenrolled workspaces.
Allowed public help destination: help/export-csv.en.md. Its complete, approved text is H1 below. Use this relative destination in the sample release note; do not invent a website, support address or product download link.
This packet may be used in full as fictional tutorial material. The user-facing release note should omit internal record IDs, issue IDs, patch names and release-control details. No speed, accuracy, productivity or reliability measurements are supplied.

P0 | 8 August 2030, 09:00 UTC | 4.2 behavior snapshot
The board header's More menu contains Download CSV. Choosing it immediately downloads a UTF-8 comma-delimited file with a header row in this order: task_id,title,assignee,due_date,status. Dates are YYYY-MM-DD; an unset due date is empty. All tasks on the board are exported, including completed tasks, regardless of board filters. Existing export permissions apply.
There is no personal Pinned section or Pin board command. The More filters menu has no Has unread comments choice. After an assignee is cleared from a task, the avatar can remain visible until the board is reloaded.

R1 | 15 August 2030, 12:20 UTC | merged change description, patch export-dialog-43
Replace the immediate Download CSV action with Export… in the board-header More menu. Open an Export board dialog. Format is CSV. Add Layout choices Standard (4.3) and Legacy (4.2), plus an Export CSV button. Standard (4.3) is selected every time the dialog opens; do not persist the last layout choice.
The standard file header is task_id,title,status,assignee,due_date,priority. The legacy header is task_id,title,assignee,due_date,status and preserves the 4.2 layout. Both retain the old delimiter, encoding, date/empty-date representation and all-board-task row selection. This patch changes no export permissions and no stored tasks.
Compatibility note from the change author: a consumer that assumes the 4.2 positional order or five columns needs Legacy (4.2) for every export until that consumer is updated. Do not call the new default universally backward compatible.
Merged here does not yet mean available to users; see the later release record.

R2 | 16 August 2030, 14:10 UTC | merged change description, patch personal-pins
Add More → Pin board to each board header for desktop web users. Selecting it adds that board to the current user's new Pinned sidebar section. In that board's More menu, the action becomes Unpin board; selecting it removes the user's pin.
Pins belong to the user. Pinning a board does not pin it for teammates or change anyone's permission to open it. In 4.2, users had to navigate without a personal Pinned section. No time-saving measurement accompanied this change.

R3 | 17 August 2030, 11:00 UTC | merged change description, patch unread-comment-filter
Add More filters → Has unread comments on boards. It shows tasks with at least one comment the current viewer has not read. Reading all comments on a task removes it from this filter when the board next refreshes. Other board filters can still be combined with it.
Initial launch is limited to Pilot workspaces, identified by the Pilot label in the workspace switcher. Other workspaces retain their existing filter choices. A person enrolled through one workspace does not get this choice in their other, unenrolled workspaces. There is no committed date for wider access in this record.

R4 | 17 August 2030, 15:30 UTC | merged internal maintenance note
Move task-repository helpers into a shared module. No menu, stored data, permissions, user-visible behavior or measured performance changes are part of this refactor. Internal code organization only.

R5 | 18 August 2030, 10:40 UTC | fix record, FB-271, patch clear-avatar-on-unassign
Fix the stale assignee avatar after clearing the assignee on a board task. Previously, the assignee value was cleared but the avatar could remain until the board reloaded. Now the avatar is removed immediately after the clear succeeds. Applies to the desktop web app in all workspaces. No user setting or repair step is required. This is a fix to the display after clearing, not a change to assignment permissions or a claim that all synchronization defects are resolved.

R6 | 18 August 2030, 16:05 UTC | duplicate issue closure, FB-299
Close “avatar still there after removing owner” as a duplicate of FB-271. It uses the same clear-avatar-on-unassign patch. No second fix or additional affected behavior is described here.

R7 | 19 August 2030, 09:45 UTC | merged experiment note, patch automatic-status-order
An automatic status sort was merged and enabled in staging. It would move completed tasks below other tasks without a manual sort. This entry contains no production enablement record.

R8 | 20 August 2030, 13:15 UTC | revert record for R7
Revert automatic-status-order before the 4.3 production release. It moved tasks unexpectedly in the staging checks. The 4.3 release retains the previous manual-order behavior; the automatic status sort is not included. No release date for a replacement is agreed.

R9 | 20 August 2030, 16:25 UTC | digest implementation and launch note
A daily digest implementation was merged into the release branch. Its feature switch remains OFF for all production workspaces, including Pilot. No digest subscription control is exposed, and no automatic digest is sent in 4.3. There is no committed launch date. Do not treat code inclusion as user availability.

R10 | 21 August 2030, 10:10 UTC | incomplete change blurb
“Polish comment send retry. Better now.”
No old behavior, new behavior, affected conditions, implementation reference or enablement scope is supplied. The release owner cannot match this blurb to a shipped change by the cutoff.
Unanswered questions for the change owner: What exact failure did a user see? What happens differently now? Which platforms and workspaces are affected? Which change implements it, and is it deployed and enabled in 4.3? Are there any user actions or help instructions? No answer is present in this packet.

R11 | 21 August 2030, 15:20 UTC | known issue from the personal-pins review
The tab in which you choose Pin board updates its Pinned sidebar immediately. Another already-open tab may continue showing its previous Pinned list until it is reloaded. If a new pin is missing in that other tab, reload that tab. This known issue remains in 4.3 at the cutoff. It does not change the personal scope of pins described in R2.

H1 | 21 August 2030, 17:00 UTC | approved help content
Package path: help/export-csv.en.md
The following complete text is the approved destination content, between BEGIN HELP and END HELP. No other help content is assumed.
BEGIN HELP
# Export a board to CSV in Fieldboard 4.3

*Help for the fictional Fieldboard 4.3 teaching case.*

Use this guide if you already have permission to export a board in the desktop web app. Version 4.3 changes the export menu and introduces a new default CSV layout. Your export permission has not changed.

## Find the export command

In 4.2, the command was **More → Download CSV** in the board header. In 4.3, open the same board and choose **More → Export…**. The **Export board** dialog opens with **Format** set to **CSV**.

Both layouts export all tasks on that board, including completed tasks. Board filters do not change the exported rows. Both layouts use UTF-8, a comma delimiter, a header row and `YYYY-MM-DD` dates; an empty due date stays empty.

## Choose the layout for the file's destination

The **Layout** field defaults to **Standard (4.3)** each time you open the dialog. The last selection is not remembered.

**Standard (4.3)** has this header order:

```csv
task_id,title,status,assignee,due_date,priority
```

**Legacy (4.2)** has this header order, matching the 4.2 export:

```csv
task_id,title,assignee,due_date,status
```

If an existing spreadsheet import or script expects the 4.2 column order or its five-column layout, choose **Legacy (4.2)** for each export until you have updated that import. Do not assume that the new default matches the old file because both are CSV.

## Export for an existing 4.2 import

1. Open the board you want to export.
2. In the board header, choose **More → Export…**.
3. In **Export board**, leave **Format** set to **CSV**.
4. Set **Layout** to **Legacy (4.2)**.
5. Choose **Export CSV** to download the file.
6. Check that the header is `task_id,title,assignee,due_date,status` before passing the file to the existing import.

Repeat the layout selection next time: reopening the dialog resets it to **Standard (4.3)**. If you already downloaded the standard layout by mistake, export again with **Legacy (4.2)** before running the import. There is no retirement date for the legacy layout in this release's information.

## If you read files manually

You can keep **Standard (4.3)** if its column order suits your work and you want the priority column. You do not need to change a board's tasks to choose either layout. The layout changes the exported columns, not the board's stored tasks.
END HELP

R12 | 22 August 2030, 09:00 UTC | release owner's completed availability record
Fieldboard 4.3 is deployed and enabled in the desktop web app at 09:00 UTC on 22 August 2030, replacing 4.2 for that app. This is a completed fictional availability record, not a deployment plan or a conclusion inferred from merges.
Export dialog and both layouts (R1), personal pins (R2), and the stale-avatar fix (R5, with R6 its duplicate) are available in all production workspaces. Existing export and board-access permissions remain as documented above.
Has unread comments (R3) is enabled only in Pilot workspaces. The Pilot label in the workspace switcher is the user-visible scope indicator. Wider availability is not scheduled.
R4 has no user-visible change. R7 remains reverted by R8. The digest in R9 remains disabled everywhere. R10 is still unmatched and unconfirmed; do not list it as an available improvement or a confirmed known issue. R11 remains a known issue. H1 is the complete help destination supplied for this case.
Release owner cutoff confirmation at 10:00 UTC: no change to any of these availability statements.
=== END COMPLETE SOURCE PACKET ===

=== BEGIN COMPLETE WRONG RELEASE NOTE ===
AUTHOR-WRITTEN COUNTEREXAMPLE — Intentionally incorrect fictional release note. This is not captured model output or a real announcement.

# Fieldboard 4.3 — 22 August 2030

Fieldboard 4.3 is available now on web, mobile and desktop apps. This release makes every workspace faster and brings the same new capabilities to all teams.

## Export without changing your workflow

Choose More → Download CSV as before. Exports are twice as fast, and the new format works with every existing spreadsheet and script automatically. Your previous export preference is remembered, so you only need to choose it once. Exports now contain only the tasks visible through your board filters.

## Organize the whole team

Pin a board to give everyone on your team a shared shortcut. Use Has unread comments in any workspace to find unread discussion. Tasks now sort themselves by status, and a daily digest keeps every user up to date automatically. Nothing needs to be set up.

## Fixes and improvements

- Fixed an assignee avatar remaining after you clear the assignee.
- Fixed an owner avatar remaining after you remove the owner.
- Rebuilt the task repository to make all boards faster.
- Comment retries now work reliably in every browser, even offline.

There are no known issues and no changes you need to make. All features above are available to everyone today; the legacy CSV option will be removed next month.
=== END COMPLETE WRONG RELEASE NOTE ===

Read availability from the release record, then explain the user task

The packet deliberately supplies different kinds of records. R1–R3 describe merged changes; R12 says which changes were actually deployed and enabled at the cutoff. R7 describes an experiment that R8 later reverts. R9 describes implemented code that is still off. R10 cannot even be matched to a shipped change. Reading the whole set prevents the first merged headline from becoming the final announcement.

This does not mean every change should be called uncertain. R12 explicitly supports the export dialog, personal pins and avatar fix for all desktop-web workspaces, and the unread-comment filter for Pilot workspaces. Those can be described as available within the fictional case. Missing facts for comment retries do not erase the separate availability records.

The export section needs more than “new export experience.” P0 and R1 establish both menu paths, both layouts and a default that resets on every opening. The user who feeds a CSV into an old import needs to choose Legacy (4.2) each time. A user who reads a file manually may prefer the new standard layout. Neither reader benefits from a blanket “no action required” or “everyone must migrate” instruction.

Read the complete corrected release note

Here is the whole repaired note. It contains the actions and limits a user needs, without the internal record IDs or a report of the writing process. The standalone release note contains the same text. Its help link points to the complete supplied export guide, whose full text is also present in the source packet above.

Fictional teaching example — not a real product announcement.

# Fieldboard 4.3 — 22 August 2030

Available from 09:00 UTC in the desktop web app. This update replaces 4.2. The changes below are available in all workspaces except the unread-comment filter, which is limited to Pilot workspaces.

## Export a board: choose the layout your import expects

The board-header command has moved from More → Download CSV to More → Export…. The new Export board dialog defaults to Standard (4.3), which adds a priority column and changes the column order.

If your spreadsheet import or script expects the 4.2 column order or five-column layout, choose Legacy (4.2) for each export until you update that import:

1. Open the board and choose More → Export….
2. In Export board, leave Format set to CSV.
3. Set Layout to Legacy (4.2).
4. Choose Export CSV.
5. Before running the existing import, check that the file header is task_id,title,assignee,due_date,status.

The dialog resets to Standard (4.3) each time you open it; it does not remember your last layout choice. If you read the file manually and want the priority column, you can keep the standard layout.

Both layouts still export all tasks on the board, including completed tasks, regardless of board filters. Your export permission is unchanged. See [Export a board to CSV in Fieldboard 4.3](help/export-csv.en.md) for both header layouts and the full steps.

## Keep your own board shortcuts

Choose More → Pin board in a board header to add that board to your Pinned sidebar section. Pins are personal; they do not pin boards for teammates or change board access. To remove a pin, open that board's More menu and choose Unpin board.

Known issue: a new pin may not appear in another already-open browser tab until you reload that tab. Reload that other tab if its Pinned list is out of date.

## Find tasks with unread comments — Pilot workspaces

In a workspace marked Pilot in the workspace switcher, choose More filters → Has unread comments to show tasks with comments you have not read. This filter is not available in other workspaces, even if you belong to a Pilot workspace elsewhere. There is no announced date for wider access.

## Fixed: stale avatar after clearing an assignee

Clearing a task's assignee now removes the avatar immediately after the change succeeds. You no longer need to reload the board to clear that stale avatar. No setting change is required.

Check the important editorial choices

The note keeps one known issue because the packet describes a current, user-visible condition and a useful workaround. It does not invent a known issue out of the incomplete retry blurb, nor claim there are no issues because most entries are improvements.

The wrong draft's “twice as fast,” offline retry support, mobile/native availability and legacy-removal date have no source. They are removed. The correct note does not replace them with softer versions of the same unsupported promises. It explains the supplied behavior instead.

Keep the factual mapping beside your draft

The internal claim map connects the final note's factual statements to specific records and excerpts. It also gives every record a disposition, including the duplicate, the rollback and the open retry questions. It is an editing aid; a user does not need it to understand the release note.

For your own release, you can use a simple working table: proposed sentence, supporting record, applicable users and unresolved question. You do not need a separate application or an elaborate approval system to do this. If a change has no user-visible consequence, omit it from a user announcement unless your audience has a reason to care about it.

For this case, the questions about R10 remain with the change owner: what failure did users see; what now happens differently; which platforms and workspaces are affected; which change implements it; is it deployed and enabled; and does anyone need to change an action or read help? Until those answers arrive, publishable wording for that one item remains unavailable. The supported export, pin, filter and avatar sections can still be reviewed on their own merits.

Review the note as the person using the product

Before publishing a real note, follow its instructions against the version you are announcing. Check exact labels, defaults, scope indicators and the help destination. This tutorial supplies those facts as fiction; it has not run Fieldboard or verified any real interface.

Read the compatibility section as someone who has not seen the engineering records. Can they identify whether their import is affected, select the right layout, produce the file and find more help? Then read the filter section as someone outside the Pilot cohort. It should be clear why they might not see the control, without needing to know how a feature switch works.

Finally, compare the note with the version history one more time. Each user-visible change should appear once, within its actual available scope. Remove claims that only a merge title, a hoped-for benefit or an unresolved blurb supports. Return a complete replacement note so obsolete instructions do not survive in a paragraph that was never revised.

An assistant is optional throughout this process. The finished example demonstrates an editorial method and a usable document; it does not establish model accuracy, time savings, customer adoption or GEO results.