Release Notes for Humans

Good release notes respect both sides of the work.

This skill keeps the evidence maintainers need separate from the notes readers see, producing accurate, concise release notes that help people decide whether and how to update.

Workflow

Choose the route that matches the requested result. An explicit change takes precedence when the request also uses review language.

• Existing draft: Treat supplied text or a supplied file as the working draft. Apply the approval gates to a user-supplied or previously approved draft.
• Inferred draft: Honor the user’s explicit evidence scope, then edit the supplied note target or return a new draft after completing the shared scope and evidence workflow below.
• Review: Keep the task read-only. Report evidence-backed omissions and concrete consistency problems without rewriting the notes, and distinguish defects from intentional or harmless variations.

Earlier notes may be the requested draft or comparison material. Otherwise, consult them only to resolve a concrete format or voice question. Limit this optional inspection to relevant examples. Prior notes don’t establish current behavior or override current rules or supplied or approved choices.

Whenever a route uses repository evidence or supplied change evidence, resolve the release scope first. Load only its applicable references, then build the evidence inventory for every resolved non-initial scope and continue through final review and delivery.

Drafting, editing, or reviewing release prose doesn’t authorize publishing a release, creating a tag, bumping a version, committing, pushing, or making any other release mutation. Leave a separately requested operation to the workflow that owns it.