A BETTER WAY TO SHARE THE WORK
Write release notes that tell people what changes for them
A list of merged changes is useful to the team. Your users need to know whether anything changes for them.
New to creating with an agent? The request will guide it through the task. Bring your notes; you don’t need to write HTML.
How can my agent turn a change log into useful release notes?
Supply the verified release scope, availability, compatibility notes, and approved instructions. Ask your agent to group changes by their effect on the reader: what is new, what changes, and what action is required. Keep planned work and unverified fixes out of the release claims, then review the static page before sharing.
01 / SEE THE DIFFERENCE
A small export change with a specific reader action
A fictional reporting tool releases version 2.4. The example is not a real product migration instruction.
Version 2.4 is available September 7 to hosted-workspace users. New CSV downloads use customer_id instead of account_id as the first header. Existing downloaded files are unchanged. The importer still requires explicit mapping; it does not rename fields automatically. Integration owners should review their mapping before adopting new exports. On-premise availability is not confirmed. No migration deadline or performance improvement was supplied.
- Available to
- Version 2.4 is available September 7 to hosted-workspace users.
- What changes
- New CSV downloads use customer_id instead of account_id as the first header.
- What stays
- Existing downloaded files are unchanged.
- Your action
- Integration owners should review their mapping before adopting new exports; the importer does not rename fields automatically.
- Not established
- On-premise availability, a migration deadline, and a performance improvement are not confirmed.
Open a complete fictional HTML example, with its source notes →
Create my release notes02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
Verify what is actually available
A merged change may not be deployed, enabled, or available to every user. State the exact version and audience. Keep previews, staged rollouts, and future work visibly separate from generally available functionality.
Translate changes into reader impact
Ask who notices each change and what becomes different in their existing workflow. Group related implementation details under that effect. Preserve limitations even when they complicate the headline; avoid claiming a fix resolves every similar symptom.
Put required action before celebration
If a format or behavior changes, say which users need to act, under what condition, and where the approved instructions live. Do not invent migration commands, automatic upgrades, compatibility guarantees, or deadlines. An absent instruction is a question to resolve before release communication.
Check the page against the shipped scope
Review each claim with the release owner. Remove private issue discussions and unsuitable internal links. Share a dated HTML reading page only after approval, while keeping the authoritative release history and technical documentation in their established locations.
03 / TRY THIS PROMPT
Copy this into your agent. Add your source material.
Use the conversation where you already did the work, or start one with your notes. Replace the placeholders and supply any missing context; only attach information you are allowed to share with your agent.
Get the ready-to-copy creation request for guided questions, this task, and a draft review before anything is published.
Using only authorized release notes, verified shipped scope, and approved instructions, draft release notes for [version] and [audience]. Ask for missing version, date, rollout scope, compatibility details, and required actions. Separate shipped changes from merged or planned work. Lead with reader impact and required action, then improvements and known limitations. Preserve exact field names and affected environments. Do not invent fixes, performance gains, migration commands, deadlines, automatic upgrades, or compatibility guarantees. Leave missing availability explicitly unconfirmed. Link only to supplied audience-safe documentation; exclude private issue notes. Create static HTML with no scripts, forms, or live-data claims. Apply my saved artifact style if available. Return a draft and verification questions. Do not publish or change access without separate explicit approval; publishing these notes must not trigger a release or deployment.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- Does every availability claim match the released version and rollout scope?
- Can an affected reader find the required action before the feature list?
- Are technical names, compatibility conditions, and known limitations exact?
- Are planned work and missing instructions kept out of confirmed release claims?
- Are linked sources safe for this audience?
When HTML fits
A reader-facing announcement or release companion that explains verified technical changes without requiring everyone to read a pull-request list.
When another format fits better
Keep version history, package downloads, support procedures, and migration execution in their existing systems. If the native release page already serves users well, improve it instead of creating another copy. This page does not ship software or make changes to a reader's system.
FROM DRAFT TO A LINK
Make it clear. Make it yours. Then share it.
Keep creating and revising in the agent you already use. With a compatible connection, share/artifacts publishes the reviewed HTML so you do not have to rebuild it in another editor. Ask your agent to use your saved artifact style for headings, color, and tone; review the result before sending it.
Choose who should be able to open the page and verify the returned link. For corrections to the same deliverable, update the existing artifact without changing its link. Publish a separate artifact when the old edition needs to remain available.
These are static pages, not live apps: no scripts, forms, or automatic data refresh. Source collection and scheduling depend on your agent and its available tools, not on share/artifacts.
Make this with my agentQuestions before you start
Can my agent start with generated GitHub release notes?
Yes, if you authorize access. Generated notes can supply a change inventory, but the release owner still needs to verify availability, user impact, and compatibility. A merged pull request alone does not establish those facts.
Should every bug fix appear?
Include fixes that matter to the audience and summarize the verified effect. Keep a full changelog link when supplied. Do not hide a material limitation merely to make the list shorter.
Can the page perform the migration?
No. It is a static explanation. Use approved documentation and the established update workflow for any actual changes; the agent must not infer deployment permission from permission to draft release notes.