免费在 GitHub 公开

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.

中文简介正在准备中。当前显示原文说明。

hyhmrright/brooks-lint

集成工具GitHub

查看安装方法

包含的文件（1）

SKILL.md4.6 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

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.

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 plus the JSON-LD softwareVersion on the docs landing page). 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 chart's own two files) and prints the rest as a checklist. Walk it: each line gets an entry you just wrote, or a reason it needs none. Nothing else is exempt — internal hardening with no user-visible change earns an entry, and so does an outside contributor's maintainer-facing fix, which also earns an @handle credit. A Changelog: trailer on a commit is surfaced as a flag; that commit's entry is the one you are writing now.

The script exits non-zero on the gap it can prove — a pull request in the range whose #N the section never cites. That same check runs inside npm run validate while a release is in progress, so it cannot be skipped, and validate prints one line whenever it stands down. The rest of the checklist is judgment and is not enforced. A green audit is not proof of a complete changelog: a bare #N anywhere in the section clears the gate, a rebase-merged PR leaves nothing to match, and anything staged into the release bump itself is never audited. See CLAUDE.md's Release Process.
Validate. npm run validate — fails if any manifest, any version-bearing text file, or the CHANGELOG entry is out of sync. Fix and re-run until clean. Then npm test.
Commit & push. Stage everything npm run bump rewrote plus CHANGELOG.md — read git status rather than naming files, because the version-bearing set is discovered from disk and is more than one README; commit with a conventional message (chore(release): bump version to <version>); push to main (direct-to-main repo — no PR).
Tag & publish. Create the GitHub release: gh release create v<version> --title "v<version>" --notes "<changelog section>".

Report the released version and the GitHub release URL when done.

评价

还没有评价。欢迎分享你的使用感受。

无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

同一仓库的技能

brooks-audit

免费

Architecture audit that maps module dependencies, checks layering integrity, and flags structural decay across a codebase, drawing on twelve classic engineering books. Triggers when: user asks to audit architecture, review folder/module structure, check for circular imports, understand how the codebase is organized, or asks "does this follow clean architecture?" or "why does everything depend on everything?". Also triggers for onboarding requests: "explain this codebase to a new developer" or "give me a codebase tour" (use onboarding mode). Do NOT trigger for: PR-level code review (use brooks-review) or line-level refactoring questions — this skill analyzes structural/module-level concerns, not individual functions.

中文简介正在准备中。当前显示原文说明。