agentleFS
Sign inStart free
stamatstamat/claude/skills/release/SKILL.md

release

Skill0 starsChanged 3 months agoMITView on GitHub

Preflight and run a release via script/publish — clean tree, tests green, changelog entry present, then hand off to the interactive script. Use when the user says "release", "publish", "cut a release", "ship it", "bump the version", or "/release".

  • Commits and pushes

196 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use create-agent-adapter, changelog-style and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MicrosoftSkill

    create-agent-adapter

    Technical guide for creating a new Paperclip agent adapter. Use when building a new adapter package, adding support for a new AI coding tool (e.g. a new CLI agent, API-based agent, or custom process), or when modifying the adapter system. Covers the required interfaces, module structure, registration points, and conventions derived from the existing claude-local and codex-local adapters.

    Also in 5 projects that use this

  • GrinvSkill

    changelog-style

    Turn a commit range into CHANGELOG.md entries following common-changelog style. Use when finishing a PR or cutting a release, to write/fix the [Unreleased] section's entries — moving [Unreleased] under a new dated version heading is a separate, automated step (see the release skill / scripts/sync-version.ts), not this skill's job.

    Also in 4 projects that use this

  • GrinvSkill

    docs-consistency-check

    Check README/manifest.json/server.json/CHANGELOG.md/AGENTS.md and docs/*.md for drift against the actual registered tools and source. Use after adding, renaming, or removing a tool, or as part of a live-audit pass.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    component-release

    Prepares a verifiable Agent Landing Zone UI release. Use for release branches, VERSION, changelog entries, tags, release notes, and compatibility evidence; never publish without explicit human approval.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    documentation-consistency

    Keeps AI Landing Zone contributor, user, and operator documentation aligned with shipped Bicep behavior. Use for parameters, defaults, outputs, topology, deployment flow, operations, or releases.

    Also in 8 projects that use this

  • rivet-devSkill

    launch-graphics

    Generate agentOS marketing/launch graphics (launch & social heroes, code-snippet cards) from the committed generators in docs-internal/graphics. Use when asked to make, update, or render an agentOS launch image, social image, "agentOS Apps" graphic, or technical code-snippet image.

    Also in 3 projects that use this

  • +3 more from Grinv

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 186 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    ## [Unreleased] has content: If CHANGELOG.md exists and that section is empty, stop: the release will ship with empty notes.

    line 20
  2. Distinctive:

    If they want it non-interactive, pass the version as the argument — that skips the version prompt, but the GitHub release prompt remains.

    line 37

“Common” is measured: kept by at least 6 in 10 of the 186 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

release

script/publish does the release. This skill runs the checks that script does not do, then hands over.

Preflight — run all of these before touching script/publish

  1. Working tree clean. git status --porcelain. The script warns and offers to continue, but a dirty tree means uncommitted work gets swept into the release commits by the git add . after the build. Stop and ask.
  2. On the default branch, and pushed up to date. git status -sb.
  3. Tests and lint green. script/test and script/lint if present, otherwise npm test. Do not skip this — script/publish tags and pushes without running either.
  4. ## [Unreleased] has content. If CHANGELOG.md exists and that section is empty, stop: the release will ship with empty notes. Offer the changelog-entry skill.
  5. The version argument makes sense. Semver, and not the version already in package.json. Breaking changes in the changelog mean a major.

Report anything that fails and stop. Do not "fix" a failing test to unblock a release.

Then hand off

script/publish <version>

It is interactive — readline prompts for the version, and for whether to create the GitHub release. Never run it in the background, never pipe it, never try to answer its prompts for the user. Tell them to run it, or run it in the foreground and let them type.

If they want it non-interactive, pass the version as the argument — that skips the version prompt, but the GitHub release prompt remains.

What it does, so you can tell them what to expect

  1. Writes the version into package.json.
  2. Runs script/changelog <version> if present — cuts ## [Unreleased] into a dated release entry, starts a fresh one, writes the changelog post, and leaves the cut entry in the temp dir as the release notes.
  3. Commits Bump version to <version>.
  4. Runs script/build if present, commits Build version <version>.
  5. Tags v<version>, pushes commits and tags.
  6. Offers to gh release create with the cut changelog entry as --notes-file.

npm publish happens in CI (publish.yml, trusted publishing) when the tag lands. It is not part of this script. If the package did not appear on npm, that is a CI problem, not a publish-script problem — check the workflow run.

Notes

  • Bump version to X and Build version X are the script's own commit messages. They are generated, and are the one place the no-prefix one-liner rule does not apply — leave them.
  • The release notes file is $TMPDIR/<repo>-release-notes-v<version>.md. A failing gh leaves it there on purpose, for a manual gh release create --notes-file retry.
  • script/changelog, script/publish and script/lint are identical across my repos — they come from stamat/template. A fix to one belongs upstream in the template, not copy-pasted around.

Boundaries

Preflight and hand-off. Does not write the changelog entry (see changelog-entry), does not decide the version number — propose one from the changelog and let the user confirm.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free