agentsclimarketplace

Release

Skill IcodeNet/agent-skills/skills/release

40 portable full-SDLC agent skills for Claude Code, Cursor, Codex, and GitHub Copilot — deep-work autonomy, contract-guard for external interfaces, TDD, code review, PR babysitting. Install: npx github:IcodeNet/agent-skills

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.

2 things to look at

  • 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 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.

What its author says it does

Copied from the file, not written here

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).

SKILL.md

2.7 KB, 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

Gives 0 of the 12 instructions most ship operate skills give

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-06

  • document a rollback plan before deploymentin 40 of 779, across 21 files
  • create an annotated git tagin 21 of 779, across 20 files
  • Run the test suitein 20 of 779
  • update the changelogin 20 of 779, across 18 files
  • verify deployment health after launchin 19 of 779, across 10 files
  • clean up feature flags after full rolloutin 18 of 779, across 10 files
  • verify the working tree is cleanin 18 of 779
  • test both feature flag statesin 17 of 779, across 9 files
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • set up error monitoring before launchin 15 of 779, across 7 files
  • monitor metrics at each rollout stagein 14 of 779, across 5 files
  • create a github releasein 14 of 779

Said here and by no other author read

  • derive the change list from git history
  • classify the version bump using the breaking-change taxonomy
  • phrase release entries as consumer outcomes
  • append to the changelog file
  • stop if a breaking change lacks a migration path
  • follow project release tool conventions

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. 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.