Turn Selected Code Changes into Evidence-Linked Release Notes

Write statements you can defend, not a summary of commit messages

To turn selected code changes into release notes you can defend: read the diff yourself, group the changes by who is affected, write one plain statement per change with its source reference, attach the record of what was actually checked, and delete every sentence the evidence does not support. You can use Cue to dictate the explanation while the diff is in view, then request a draft from the reviewed text. This text-only exercise does not authorize repository access, tests, tagging or publication. That is a task boundary, not a statement that Cue or a connected Agent lacks those capabilities.

Commit messages summarize an author's intent; they may be incomplete or stale after review. A release note turns those claims into expectations for people who cannot see the code. Check subjects against the diff, tests and deployment record rather than treating any one source as proof of the entire user outcome.

Three routes are available, and they are alternatives rather than steps:

1. Dictate into the tool you already use. Focus the editable field where the notes are being written, a scratch note or a draft file, and speak the explanation with Cue Dictation. Check the inserted text and submit it yourself. Cue is entering text; the receiving app owns the document.
2. Select an external Agent inside Cue. In Cue versions with the Agent selector, Claude and Codex appear as local Agent choices. Seeing an entry listed — Claude, Codex or Gemini — is not proof of a working connection, a sign-in, an available model or repository access. Confirm what that Agent can reach before handing it anything.
3. Use Cue Agent with a supported model. Choose Cue in the Agent column, then an available model. That changes which model drafts the text. It does not grant a terminal, a checkout of your repository or permission to publish.

For a longer change set, Cue's recording and transcription controls can hold a spoken walkthrough taken while the diff is open. Treat that transcript as raw material, not a verified record. The recording-to-context workflow covers the checking step.

Prepare the change set, the checked record and the destination

This workflow assumes a person is responsible for the release text. Before starting, assemble four things. The practice exercise below supplies all four so you can follow along without a repository.

• The exact change set. The commit range, tag or pull request you intend to describe, with the commit identifiers. "The work from last week" is not a change set. If you cannot name the boundary, you cannot tell which changes belong in the notes.
• The diff itself. The changed lines, with enough surrounding code to interpret them. A commit subject line alone is not evidence of what the code does.
• A record of what was checked. Which tests exist and passed, which platforms were exercised, what was not covered, and any measurement that was actually taken. If nothing was measured, that is the record, and it belongs in the notes as a silence rather than an estimate.
• The destination and its rules. Where the notes will go, who approves them, and whether your team has an embargo or security-disclosure process. Some fixes must not be described in detail before a patch reaches users.

For Cue, use the controls in your installed version, confirm microphone and input permissions for Dictation, and start in a scratch note so an unfinished sentence cannot become a published release note. Default shortcuts differ by platform and can be changed; the setting in your copy takes precedence over any key named in a guide. The Dictation tutorial covers setup and insertion checks.

Authorization matters more here than in most writing tasks. A private diff may not be shareable with an external Agent, and a release note can commit your organization to a behavior. Share the minimum excerpt, follow your organization's data-handling rules and review Cue's privacy policy before supplying anything confidential.

Practice: release 1.4.0 of a fictional notes app

Everything below is fictional practice material for an app called Example Notes. The commits and test record are invented for the exercise, and the code is an incomplete excerpt. Nothing here is a Cue product behavior, a recorded Cue run or a measured result. You can work through the sources manually without a repository or an Agent account. Copy the four sources into a blank note. For this exercise, assume consumers import the functions re-exported by src/index.mjs; no other compatibility export is supplied.

The four source blocks stay in English in every language edition so code, identifiers and the statements being checked remain identical. The explanation and worked answer are translated separately. Do not run this incomplete diff as a program.

C-01 — the selected change set (five commits, fictional):

a1b2c3d  feat(export): include the note title in the exported file name
e4f5a6b  refactor(export): extract buildExportName from the export handler
9c0d1e2  fix(export): stop trimming the final page when a note ends with an empty block
7f8a9b0  chore(deps): update markdown-render 2.3.1 -> 2.4.0
3d4e5f6  feat(sync): add background sync retry behind the disabled syncRetry flag

C-02 — the diff for those commits, shown combined:

--- a/src/export-name.mjs
+++ b/src/export-name.mjs
@@
-export function exportName(note) {
-  return `note-${note.id}.pdf`;
-}
+const MAX_TITLE = 40;
+
+export function buildExportName(note) {
+  const title = (note.title || '').trim().slice(0, MAX_TITLE);
+  const safe = title.replace(/[^\p{L}\p{N} _-]/gu, '').trim();
+  return safe ? `${safe}.pdf` : `note-${note.id}.pdf`;
+}

--- a/src/index.mjs
+++ b/src/index.mjs
@@
-export { exportName } from './export-name.mjs';
+export { buildExportName } from './export-name.mjs';

--- a/src/export-pages.mjs
+++ b/src/export-pages.mjs
@@
 export function exportPages(blocks) {
-  return paginate(blocks.filter(block => block.text.length > 0));
+  return paginate(blocks);
 }

--- a/package.json
+++ b/package.json
@@
-    "markdown-render": "2.3.1"
+    "markdown-render": "2.4.0"

--- a/src/sync.mjs
+++ b/src/sync.mjs
@@
 export function scheduleSync(config, queue) {
+  if (config.syncRetry) return scheduleWithRetry(queue, { attempts: 3 });
   return scheduleOnce(queue);
 }

C-03 — the record of what was actually checked for this release:

Unit tests for export-name.mjs: 6 cases pass. Covered: usable title, empty title,
title of only punctuation, title over 40 characters, missing title property,
non-Latin title.
export-pages.mjs: no test covers this file, before or after the change.
Manual export: run on macOS only. Not run on Windows.
markdown-render 2.4.0: upstream release notes were not read. Reason for the bump
is recorded only as "routine update".
config/defaults.json: syncRetry is false. Not changed in this release.
Performance: no measurement was taken before or after these changes.
Crash reports: none were linked to any commit in this change set.

C-04 — draft release statements from a teammate, to be validated:

1. Exports are now named after your note.
2. Fixed a crash that caused the last page to disappear.
3. Export is about twice as fast.
4. Background sync retry is now available.
5. Internal refactor only, no API changes.
6. Updated markdown-render for security.

The diff above is shown as one block for readability. It does not establish which commit introduced each line. Cite C-02 plus the file path for the worked answer; use C-01 subjects only as claims to check. In a real task, read each commit's own diff before attaching its identifier to a statement.

Read C-02 before C-04. The statements need different corrections: source behavior, test coverage and availability are separate questions. The renamed function is re-exported from the fixture's public entry point. Removing the filter call passes every block to paginate, but its implementation is absent: neither the final PDF layout nor a crash fix is established. A default-off flag does not tell you whether someone can enable it elsewhere. Also, JavaScript's slice(0, 40) counts UTF-16 code units, not necessarily 40 visible characters.

Capture the walkthrough and request a bounded draft

1. Open the diff and a blank scratch note side by side. Do not start in the release description field of a publishing tool.
2. Focus the note's text field, start Dictation with the shortcut shown in Cue Settings, and confirm the recording state before speaking. If capture is unavailable, type the walkthrough instead; the exercise does not depend on audio. For longer recordings, first follow the setup and review checks in the linked recording-to-context guide.
3. Walk through the changes out loud, one at a time. For each one say what the code now does, who notices, and what you personally checked. Say "not checked" when nothing was checked; that phrase is easier to keep than to reconstruct later.
4. Stop dictation, wait for processing, and read the inserted text. Paste commit identifiers, file paths, version numbers and flag names from their source rather than dictating them. Speech is good for the explanation and unreliable for 9c0d1e2.
5. Assemble the sources beside your notes. If your corrected text is already clear, skip the Agent and edit it yourself. For help with structure and wording, open Cue Agent or a connected external Agent and paste C-01 through C-04 explicitly. An open repository window is not context an Agent received.
6. Send the drafting request. Ask for the notes, the evidence table and the claim validation as three separate blocks, so an unsupported sentence cannot be quietly folded into a polished paragraph.
7. Check the draft against C-02 and C-03 yourself using the verification pass. Then copy the approved text into your release tool, confirm the version and target you are editing, and publish it yourself. Do not ask any Agent to tag, push, deploy or post the notes.

Copy a release-notes request

Replace the bracketed fields with your own reviewed sources, or paste C-01 through C-04 to practice. Leave no placeholders in a real task.

Task: Draft release notes from the supplied sources only. Do not publish anything.
Release: [version and platform]
Sources:
C-01 commit list, C-02 diff, C-03 record of what was checked,
C-04 draft statements written by someone else.

Produce three separate blocks.

Block A. Release notes, grouped as:
- What changed for you
- For anyone importing this package (only if a public interface changed)
- Internal and dependency changes
- Not enabled by default or not yet verified as available
- Not measured
Write one statement per change in plain language. Code and interface statements
cite C-02 and its file path; checks, measurements and default configuration cite
C-03. The combined diff does not map individual lines to commits;
do not infer that mapping from C-01 subjects. State conditions and limits where
the sources show them, including fallbacks, truncation, defaults and untested files.

Block B. Evidence table: statement, the applicable code lines or C-03 entry,
and what remains unverified. Distinguish source-supported behavior
from tested behavior. A missing test means untested, not automatically false;
an outcome not established by the excerpt must remain unverified.

Block C. Validation of each C-04 statement: supported, incomplete, unsupported or
contradicted, with the reason, and where possible a wording the evidence allows.
List separately every statement that must be removed outright.

Rules:
Use only the supplied sources. Do not infer a cause, a crash, a user count,
a speed change, a security impact or a customer complaint.
A commit message is a claim, not evidence. If it conflicts with the diff, follow
the diff and flag the conflict.
Default-off is not proof of total unavailability. Report the documented default;
do not infer an opt-in path, rollout state or universal user availability.
Do not describe tests that C-03 does not record.
Draft only. Do not tag, release, publish, push, deploy or edit files.

Illustrative output

The three blocks below are illustrative examples written for this exercise. They are not a recorded Cue run, not a product output sample and not a guarantee of what any Agent will return. Compare your own result against them.

Illustrative release notes:

Example Notes 1.4.0 (fictional exercise release)

What changed for you
- Export names use the trimmed title's first 40 UTF-16 code units, then remove
  unsupported characters. If nothing remains, the name is note-{id}.pdf.
  The supplied test record lists six passing cases; it does not supply the tests.
  (C-02: src/export-name.mjs; C-03)
- All blocks now pass to paginate without filtering out empty-text blocks.
  The final PDF layout and any crash fix remain unverified: paginate is not
  supplied and C-03 records no tests for this file.
  (C-02: src/export-pages.mjs; C-03)

For anyone importing this package
- The exported function exportName is now buildExportName in the package index.
  With the public-entry-point assumption in this exercise, imports of exportName
  need updating. (C-02: src/index.mjs)

Internal and dependency changes
- markdown-render updated from 2.3.1 to 2.4.0. The upstream release notes were
  not reviewed, so its effects and security significance are not established.
  (C-02: package.json; C-03)

Not enabled by default
- A retry branch exists but syncRetry remains false in the supplied defaults.
  Opt-in availability and deployment state are not provided.
  (C-02: src/sync.mjs; C-03)

Not measured
- No performance measurement was taken for this release. (C-03)
- No crash report was linked to any commit in this change set. (C-03)
- Export was exercised manually on macOS only. (C-03)

Illustrative evidence table (Block B):

Illustrative claim validation, the checklist for C-04:

Statement 5 is the one worth slowing down for. "Internal" is a claim about an audience, not about a file. A rename inside one module is internal; the same rename in the package index is a breaking change for everyone who imports it.

Verify every statement against the diff

Do this pass yourself, with the draft on one side and C-02 and C-03 on the other. Do not ask the same Agent that wrote the notes to confirm the notes are accurate.

Finish with a reverse read. Cover C-01 and C-04, read the diff and C-03, and ask what you would write from scratch. Any remaining claim needs a source; do not infer where an unsupported statement came from. If the record later changes, for example someone adds a test for export-pages.mjs, update the statement and its evidence together.

Where this method does not work

• This exercise is text-only and draft-only. Supply the reviewed sources explicitly. Do not authorize file changes, tests, network requests, tagging or publication for this exercise. Actual tool availability depends on the installed version, selected Agent, connection and permissions; it is not established by this article.
• Large or squashed releases outgrow a single pass. This method suits a change set you can read end to end. Hundreds of commits need triage first, and a squashed commit that bundles unrelated changes is a weak reference; point to files or ranges instead, and say so.
• Private code may not leave your environment. Do not paste an employer's or client's diff into any Agent without authorization. If in doubt, draft from the scratch note and skip the Agent step.
• Security fixes have their own process. Describing a vulnerability before a patch reaches users can create risk. Your organization's disclosure rules outrank any wording suggestion here.
• Shipped is not the same as available. Flags, staged rollouts, server-side gates and store review all sit between a merged commit and a user. The diff cannot tell you which applies.
• Release notes do not certify quality. They describe changes. They are not evidence that a release is correct, secure or complete.
• Another language is another review. A translated release note is a new set of statements. Checking the English version does not check the translation.

Recover when the draft or the record is wrong

For a Cue capture or insertion problem, use Contact Cue support with your platform, Cue version, mode and a redacted example. Do not send private repositories, credentials or unreleased security details.

Questions this exercise raises

Do I need a repository to practice this? No. C-01 through C-04 are complete. The exercise is text-only and safe to paste into any Agent, because none of it is real code from a real product.

Can Cue pull the diff for me? Do not assume so. Check what your installed version and the selected Agent can actually access, and confirm it before relying on it. In this workflow you supply the diff as text, which also keeps you reading it.

Should internal refactors appear in release notes at all? Usually in a separate section or not at all. The test is not whether the change is small but whether anyone outside the team can observe it, including people who import your package.

Is "no user-visible changes" a safe thing to write? Only after checking the public surface, output formats, error messages, defaults and dependencies. Statement 5 in the exercise fails exactly this test.

Sources and related workflows

This tutorial describes Cue's Dictation and Agent boundaries as documented for these guides. It does not claim a Git, CI, package-registry or release-tool integration. Your installed controls and your organization's release process take precedence over the fictional exercise.

• Cue Dictation tutorial: focused field, recording state and insertion recovery.
• Cue Voice Agent tutorial: explicit context and bounded requests.
• Cue with coding Agents: the difference between dictating into a tool, selecting an external Agent and using Cue Agent with a model.
• Review a code change with Codex: that workflow decides whether a change is correct; this one describes a change that has already been accepted.
• Fix a small bug with Claude Code: implement and test a bounded change before it becomes a release line.
• Write a weekly status update by voice: a progress report for colleagues, with a different audience and no requirement to trace each line to a commit.
• Dictate exact technical terms: preserve identifiers, versions and error strings.
• Cue privacy policy: review before supplying any non-public code or record.