agentsclimarketplace
Sign in

Release

Skill skrrt-sh/skills/skills/ship/release

Draft, prepare, or publish a GitHub or GitLab release. Use when the user asks for release notes, wants to publish a release, or asks what changed since the last tag.From its SKILL.md

Install
npx -y skills add skrrt-sh/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

  • 2 stars2 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

3.1 KB, as published. Nobody here has run it

Prepare a Release

Derive release facts from tags, commits, diffs, and repository configuration.

Process

  1. Classify the request before mutating anything:
    • Notes only: produce release text; do not edit files, tag, push, or publish.
    • Prepare: update requested local release files; do not tag, push, or publish.
    • Publish: perform the verified publication flow below.
  2. Read .agents/ship.md at the repository root. If missing, stop and ask the user to run /setup. Validate the release branch and tag rules it defines.
  3. For Claude Code plugin repositories, read references/claude-plugin-releases.md.
  4. Run git fetch origin --tags so local tag data is current, then validate the requested tag format and confirm it does not exist locally or on the remote.
  5. Find the previous release tag in the same namespace. Use <previous>..HEAD for an existing series. For an initial release, inspect the full history with git log --reverse HEAD; include the root commit and omit the compare link.
  6. Draft reader-focused notes from commits and diffs. Update an existing CHANGELOG.md only for a prepare or publish request, preserving its style. Never create one unless asked.
  7. For publication, stop if release preparation changed tracked files; those changes must reach the release branch through the configured commit and PR workflow first.
  8. From the target repository, run ${CLAUDE_SKILL_DIR}/scripts/detect-forge-cli.sh. Continue only on STATUS=ok.
  9. Verify a clean worktree, HEAD at the required remote release commit, a non-empty release range, and the tag still absent remotely. Show the tag, commit, previous tag, and notes file, then publish only because the user requested publication.
  10. Create and push an annotated tag. Create the release with that verified remote tag and the notes file (gh release create --verify-tag or glab release create --no-update). Read the release back, remove temporary files, and report its URL and tag.

Release text

## What's Changed

### ✨ Features
- ...

### 🐛 Fixes
- ...

### ⚠️ Breaking Changes
- ...

### 🧰 Internal
- ...

**Full Changelog**: <compare link>

Omit empty sections. Keep internal changes only when they matter to users or operators. Never copy a raw commit log or invent tests, changes, contributors, or links.

Guardrails

  • Publish only on an explicit publication request; loading this skill is not that request.
  • Treat tags as immutable; fix a bad release with a new version.
  • Never rebuild an artifact for promotion or move an existing tag.
  • Never publish from uncommitted preparation changes or an unverified commit.
  • Never force-push or delete a tag as part of this workflow.
  • If forge publication fails after the tag is pushed, keep the tag and report a safe retry; do not retag another commit.

What ships with it: 3 files

3.5 KB alongside SKILL.md, 1 of them executable

evals/

scripts/

Gives 1 of the 12 instructions most ship operate skills give

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 taghere, and in 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

  • Classify the request before mutating anything
  • Read the ship configuration file
  • Fetch tags to update local tag data
  • Draft reader-focused notes from commits

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 626,194. 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.