Prepare Release
Use this skill when the user wants to turn pending changesets into a release.
First Checks
- Read repo instructions such as
AGENTS.md, CLAUDE.md, and release docs.
- Confirm the repo already has a changeset workflow and release command.
- Confirm pending
.changeset/*.md files exist.
- Inspect the current version, changelog, branch, working tree, tags, CI expectations, and deployment model.
If the workflow is missing, stop and say the repo does not have changeset release tooling installed. Do not scaffold it from this skill.
If there are no pending changesets, stop and report that there is nothing to release.
Release Workflow
- Run the repo's dry-run or status command first.
- Summarize the pending changesets, next version, and generated changelog preview.
- Run required validation, usually tests, lint, build, and relevant browser checks.
- Run the mutating version/changelog/archive command only when the user has asked to proceed.
- Review generated files, especially
CHANGELOG.md.
- Prepare the release commit, tag, and GitHub Release notes.
Boundaries
- Do not create missing changeset tooling.
- Do not invent release notes without pending changesets.
- Do not delete consumed changesets; they should move to
.changeset/released/<version>/.
- Do not create, move, or push tags without explicit approval.
- Do not publish a GitHub Release without explicit approval.
- Treat published tags as immutable. Ship a follow-up patch rather than rewriting a release tag.
References
- For the command sequence and file behavior, read
references/release-workflow.md.
- For GitHub Release expectations, read
references/github-releases.md.
- For prompt and response examples, read
references/examples.md.
1---2name: prepare-release3description: Prepare a release from pending changesets by previewing the next version, generating the changelog, archiving consumed notes, and preparing tag or GitHub Release steps. Use when the user asks to prepare, cut, publish, or generate a release from pending changesets.4license: MIT5---67# Prepare Release89Use this skill when the user wants to turn pending changesets into a release.1011## First Checks12131. Read repo instructions such as `AGENTS.md`, `CLAUDE.md`, and release docs.142. Confirm the repo already has a changeset workflow and release command.153. Confirm pending `.changeset/*.md` files exist.164. Inspect the current version, changelog, branch, working tree, tags, CI expectations, and deployment model.1718If the workflow is missing, stop and say the repo does not have changeset release tooling installed. Do not scaffold it from this skill.1920If there are no pending changesets, stop and report that there is nothing to release.2122## Release Workflow23241. Run the repo's dry-run or status command first.252. Summarize the pending changesets, next version, and generated changelog preview.263. Run required validation, usually tests, lint, build, and relevant browser checks.274. Run the mutating version/changelog/archive command only when the user has asked to proceed.285. Review generated files, especially `CHANGELOG.md`.296. Prepare the release commit, tag, and GitHub Release notes.3031## Boundaries3233- Do not create missing changeset tooling.34- Do not invent release notes without pending changesets.35- Do not delete consumed changesets; they should move to `.changeset/released/<version>/`.36- Do not create, move, or push tags without explicit approval.37- Do not publish a GitHub Release without explicit approval.38- Treat published tags as immutable. Ship a follow-up patch rather than rewriting a release tag.3940## References4142- For the command sequence and file behavior, read `references/release-workflow.md`.43- For GitHub Release expectations, read `references/github-releases.md`.44- For prompt and response examples, read `references/examples.md`.
brandtam