release-noteslisted

# Release notes Release notes tell the user what changed since the last version. Keep them short. Keep them true. Read the commits and the pull requests, then write what changed. ## 1. Find the release range Do not guess. Work out the exact range of commits that will ship. 1. Find the repository owner and name from the remote: ```sh git --no-pager remote get-url origin ``` Parse the `owner/repo` from it. 2. Find the last published release and its tag with the GitHub tools. Use `get_latest_release` (or `list_releases` and take the first entry). 3. Resolve that tag to a commit so you know exactly where the last release ends: ```sh git --no-pager rev-parse <last-tag> git --no-pager log -1 <last-tag> ``` 4. List the commits on `main` (and `main` only) that will ship in this release. Use the `main` branch, not the current working branch: ```sh git --no-pager log <last-tag>..main --oneline ``` The agent tools work too: `list_commits` with `sha: main` gives the history. Count the commits. This is the set of changes to write about. If there are no commits since the last tag, stop and tell the user there is nothing to release. ## 2. Read what changed For each commit in the range, understand what it did. Do not stop at the commit subject. 1. Find the merged pull requests in the range. Commit subjects often carry the PR number, e.g. `feat: add tags view (#94)`. Collect those numbers. 2. For each PR, read its descript