release

Release New Version

Model tier: sonnet — Sonnet 5 (1M context) session.

Prepare and publish a new version release, adapted to the project type.

Step 1: Orientation

Gather release context before making any changes.

1. Detect project type from manifest files:

   Check	Type	Version source	Publish action
   package.json exists	Node/npm	version field in package.json	Advisory: "Ready for npm publish"
   Cargo.toml exists	Rust	version field in Cargo.toml	Advisory: "Ready for cargo publish"
   pyproject.toml exists	Python	version field in pyproject.toml	Advisory: "Ready for twine upload"
   go.mod exists	Go	Git tags only	Advisory: "Tag pushed, consumers can go get"
   None of above	Docs/generic	CHANGELOG.md or git tags	No publish step

2. Find current version from the manifest file or latest git tag (git tag --sort=-v:refname | head -1).

3. Find last release tag and compute changes since then:

   git log <last-tag>..HEAD --oneline
   

4. Identify all version-bearing files -- do NOT rely on memory or a static list. Grep the CURRENT version string across the whole repo so nothing is missed:

   git grep -n -F "1.2.3"; git grep -n -F "v1.2.3"   # both bare and v-prefixed
   

   Hand-maintained version strings drift silently when there is no canonical manifest. Explicitly confirm these commonly-missed locations, even if a scoped scan would skip them:

   • README/docs shield.io badges -- the version can appear 3x on ONE line (badge label text, the img.shields.io URL, and the releases/tag/ link href).
   • Plugin/marketplace manifests (.claude-plugin/plugin.json, .claude-plugin/marketplace.json) -- each carries its own "version".
   • manifests, install instructions, constants files, docker tags, CI configs, documentation site configs, compatibility tables.