release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release", "cut a release", "ship a new version", or "bump and publish" brooks-lint. Do NOT trigger for: propagating an already-decided version without releasing (use `npm run bump` directly), CHANGELOG edits alone, or questions about the release process that don't ask to perform it.
npx skills add hyhmrright/brooks-lint --skill release --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# brooks-lint — Release Target version comes from `$ARGUMENTS` (e.g. `1.4.0`). If empty, ask the maintainer for the semver bump before doing anything. 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 manifests + badge. 1. **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). 2. **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 plus the JSON-LD `softwareVersion` on the docs landing page). Do not maintain a list here — the script's is authoritative. 3. **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 (`git log <
What does the release skill do?
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release", "cut a release", "ship a new version", or "bump and publish" brooks-lint. Do NOT trigger for: propagating an already-decided version without releasing (use `npm run bump` directly), CHANGELOG edits alone, or questions about the release process that don't ask to perform it.
How do I install it?
Run `npx skills add hyhmrright/brooks-lint --skill release --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From hyhmrright/brooks-lint, a repository with 1,284 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.