Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →hyhmrright/release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests + README badge, write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release.
Passed 19 of 22 test cases with the skill, and 10 of 22 without it.
and 11 more in the full report
11 fixed11 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.8-flash on 10/19/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
A commit in the brooks-lint release range contains a 'Changelog:' trailer in its commit body. What does npm run changelog:audit do with this trailer?
| Checked | Without skill | With skill |
|---|---|---|
| Surfaces the Changelog: trailer as a flag indicating that commit requires a changelog entry | Missed | Passed |
The instructions your model reads when the skill loads.
Target version comes from the user request (e.g. 1.4.0). If empty, ask the maintainer
for the semver bump before doing anything.
Before accepting that version, read the backlog. Run
npm run changelog:audit and look at what is actually unreleased — the bump is decided by the whole range, not by the change
that prompted the release. If the range contains a feature or a new platform and
the maintainer asked for a patch, stop and say so: v1.5.1 was published, then
deleted and re-cut as v1.6.0 because twenty unreleased commits (including a new
platform) had been swept into a patch.
Execute these steps in order. bump-version.mjs reads the version FROM
package.json and does NOT touch the changelog — so the version edit and the
CHANGELOG entry are manual; the script only fans the version out to the manifests
and every version-bearing text file.
Set the source of truth. npm version <version> --no-git-tag-version
(the --no-git-tag-version flag is required — plain npm version would create
its own commit + tag and collide with the manual commit in step 5).
Propagate. npm run bump — writes the version into
.claude-plugin/plugin.json, .claude-plugin/marketplace.json,
.codex-plugin/plugin.json, gemini-extension.json, and every version-bearing
text file discovered by scripts/version-refs.mjs (all six README badges and action uses: pins,
the JSON-LD softwareVersion on the docs landing page, and
docs/github-action-example.yml). Do not maintain a list
here — the script's is authoritative.
Write the changelog. Add a new section at the top of CHANGELOG.md with
categorized notes (Added / Fixed / Changed) summarizing the commits since the
last release tag. The heading MUST be ## [<version>] - YYYY-MM-DD —
npm run validate parses that exact shape and fails on a bare ## <version>.
3a. Audit the range — every commit, no sampling. Run:
npm run changelog:audit
It derives the range from the last release tag, applies the only three exemptions (the release bump, a merge commit whose branch commits are listed separately, and the star-history refresh — a bot commit touching only the
test cases passed, vs 10 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.