# Release and Change Summary

## Purpose

Explain shipped or proposed changes clearly for developers, operators, collaborators, or end users, with emphasis on what changed, why it matters, and what action is required.

## When to use

- Writing release notes or changelog entries
- Summarizing completed engineering work
- Explaining migration or rollout impact
- Turning technical changes into clear stakeholder communication

## Inputs to gather

- The actual code or product changes
- Intended audience and their level of technical depth
- Any rollout, migration, compatibility, or operational considerations
- Linked docs, issues, or feature context that explains why the change exists

## How to work

- Lead with the user-meaningful change, not internal implementation trivia.
- Group related changes into a few clear themes rather than a raw diff dump.
- Call out required actions, migrations, or risks explicitly.
- Tailor the level of detail to the audience.
- Keep the summary accurate to the implementation that actually landed.

## Output expectations

- Clear release notes, summary, or change communication draft
- Audience-appropriate explanation of impact and required action
- Explicit mention of follow-up items only when relevant

## Quality checklist

- The summary matches the real change, not the original intent alone.
- Important caveats, migrations, and compatibility notes are visible.
- Wording is concise and easy to scan.
- Audience knowledge level is respected.

## Handoff notes

- Say who the summary is for and what medium it targets if that is not obvious.
- Pair with technical docs or marketing skills when the output needs deeper explanation or stronger positioning.