releaselisted

# Release Turn what has landed since the last release into a released version: work out what is shipping, recommend a semver bump, draft notes a *user* of the project can read, and publish along the path the repo's own release model prescribes. This is the step after `/anchor:merge`. It is **always invoked explicitly** — `merge` names it as the next step but never runs it, because publishing is a deliberate act and batching several merges into one release is the normal shape. So this skill assumes nothing about a preceding merge in the same session: it reads the release state from the repo, and runs the same way whether one CR just landed or five did last week. **Release model** = who owns the version bump: the CI workflow, a commit in this repo, or nobody. It is the first thing to establish and the one thing worth being certain about — hand-editing a manifest whose workflow also bumps it lands two commits that fight, and it surfaces only after the release is public. **Don't narrate your work.** Every step below is an operating instruction, not a script to read aloud — follow the execute-quietly discipline: `${CLAUDE_PLUGIN_ROOT}/guides/execute-quietly.md`. For this skill, the only things worth surfacing are the resolved repo and model in one line, any fork that needs the author, the version recommendation, and the one-line result. ```mermaid %%{ init: { 'look': 'handDrawn' } }%% flowchart TD Start(["/release"]) --> Recon["Resolve repo + run release-recon.sh"] s