agentsclimarketplace
Sign in

Release

Skill IcodeNet/agent-skills/skills/release

Prepare a release: decide the semantic version bump, write the changelog / release notes from actual changes, and tag. Use when releasing or publishing a package or service version, cutting a release branch, or when asked "what version should this be" or to write release notes. Do not use for the deploy execution itself (use deploy-checklist).From its SKILL.md

Install
npx -y skills add IcodeNet/agent-skills --skill release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.7 KB, 509 tokens by cl100k_base, as published. Nobody here has run it

Release

A release is a statement to consumers: what changed, whether it's safe to upgrade, and what they must do if not.

Workflow

1. Collect the actual changes

Work from evidence, not memory: git log <last-release-tag>..HEAD plus the diff. Group commits into user-facing changes; ignore internal noise (CI tweaks, formatting) unless it affects consumers.

2. Decide the version bump

Apply the contract-guard classification (see the contract-guard skill and its breaking-change taxonomy) to everything in the release:

  • Any breaking change to a public surface → major
  • Compatible new capability → minor
  • Behavior-preserving fixes only → patch

If a breaking change is present without a migration path documented, stop — that's a contract-guard failure to resolve before releasing, not a notes problem.

3. Write the notes

Structure, plain language, consumer perspective:

## <version> — <date>

### Breaking changes        <!-- omit section if none -->
- <what broke> — **Migration:** <exact steps for the consumer>

### Added
- <new capability, phrased as what the user can now do>

### Fixed
- <symptom that no longer occurs>

### Changed / Deprecated    <!-- include deprecation timelines -->

Rules: every breaking entry has a migration step; entries describe outcomes, not commit titles; link issues/PRs where they exist.

4. Tag and record

  • Update the changelog file if the repo keeps one (CHANGELOG.md) — append, never rewrite history of prior releases.
  • Bump the version where the project declares it (package manifest, plugin manifest, etc.).
  • git tag v<version> after the release commit; push tags.

Constraints

  • Never publish a major bump silently as minor "to avoid alarm" — mislabeled breaking changes are the worst outcome for consumers.
  • Notes are for consumers, not contributors: no internal refactor bragging unless it changes observable behavior or performance.
  • If the project uses conventional commits or a release tool (changesets, semantic-release), follow that convention instead of hand-rolling.

Verification

  • Change list derived from git history since last tag
  • Bump justified against the breaking-change taxonomy
  • Every breaking change has a migration step
  • Version bumped in the manifest + changelog updated + tag created

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most ship operate skills give in 509 tokens

Counted across 1,077 of the 1,713 authors here whose files we hold, read 2026-09-06

  • Create GitHub releasein 44 of 1077, across 43 files
  • Run the test suitein 30 of 1077, across 25 files
  • Create and push git tagin 27 of 1077, across 26 files
  • Push commits and tagsin 27 of 1077
  • Create annotated tagin 25 of 1077, across 22 files
  • Ensure working tree is cleanin 24 of 1077
  • Check for product marketing context firstin 23 of 1077, across 6 files
  • Commit version bump changesin 22 of 1077, across 21 files
  • Update CHANGELOG.mdin 21 of 1077, across 20 files
  • Structure launch marketing across three channel typesin 20 of 1077, across 5 files
  • Commit and tag the releasein 20 of 1077, across 18 files
  • Update the CHANGELOG for new releasesin 19 of 1077

Said here and by no other author read

  • Collect actual changes from git log and diff
  • Decide version bump using contract guard classification
  • Stop if a breaking change lacks a migration path
  • Write release notes from a consumer perspective

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.