release
installsforks
How to install release?
hyhmrright/brooks-lint/release
$npx -y skills add hyhmrright/brooks-lint --skill releaseCut 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. Triggers when the maintainer asks to "release", "cut a release",
SKILL.md
| 1 | # brooks-lint — Release |
| 2 | |
| 3 | Target version comes from `$ARGUMENTS` (e.g. `1.4.0`). If empty, ask the maintainer |
| 4 | for the semver bump before doing anything. |
| 5 | |
| 6 | Execute these steps in order. `bump-version.mjs` reads the version FROM |
| 7 | `package.json` and does NOT touch the changelog — so the version edit and the |
| 8 | CHANGELOG entry are manual; the script only fans the version out to manifests + badge. |
| 9 | |
| 10 | 1. **Set the source of truth.** `npm version <version> --no-git-tag-version` |
| 11 | (the `--no-git-tag-version` flag is required — plain `npm version` would create |
| 12 | its own commit + tag and collide with the manual commit in step 5). |
| 13 | 2. **Propagate.** `npm run bump` — writes the version into |
| 14 | `.claude-plugin/plugin.json`, `.claude-plugin/marketplace.json`, |
| 15 | `.codex-plugin/plugin.json`, `gemini-extension.json`, and the README badge. |
| 16 | 3. **Write the changelog.** Add a new `## <version>` section at the top of |
| 17 | `CHANGELOG.md` with categorized notes (Added / Fixed / Changed) summarizing the |
| 18 | commits since the last release tag (`git log <last-tag>..HEAD --oneline`). |
| 19 | 4. **Validate.** `npm run validate` — fails if any manifest, the README badge, or |
| 20 | the CHANGELOG entry is out of sync. Fix and re-run until clean. Then `npm test`. |
| 21 | 5. **Commit & push.** Stage the changed manifests, README, and CHANGELOG; commit |
| 22 | with a conventional message (`chore(release): bump version to <version>`); push |
| 23 | to `main` (direct-to-main repo — no PR). |
| 24 | 6. **Tag & publish.** Create the GitHub release: |
| 25 | `gh release create v<version> --title "v<version>" --notes "<changelog section>"`. |
| 26 | |
| 27 | Report the released version and the GitHub release URL when done. |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
