Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

$pwd:

release

Name: Release
Author: hyhmrright

// 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. 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.

Exécuter dans Manus

$ git log --oneline --stat

stars:186

forks:12

updated:28 mai 2026 à 14:55

SKILL.md

readonly

name	release
description	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. 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.
disable-model-invocation	true

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.

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 the README badge.
Write the changelog. Add a new ## <version> section at the top of CHANGELOG.md with categorized notes (Added / Fixed / Changed) summarizing the commits since the last release tag (git log <last-tag>..HEAD --oneline).
Validate. npm run validate — fails if any manifest, the README badge, or the CHANGELOG entry is out of sync. Fix and re-run until clean. Then npm test.
Commit & push. Stage the changed manifests, README, and CHANGELOG; 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.

related-skills.json

même dépôt

new-skill.md

from "hyhmrright/brooks-lint"

Scaffold a new brooks-lint analysis skill so it passes `npm run validate` and `npm run evals` on the first try — generates skills/{name}/SKILL.md (with the mandatory "Do NOT trigger for:" clause and a Process section citing guide step ranges) plus skills/{name}/{name}-guide.md (sequentially numbered steps), then appends paired eval scenarios. Triggers when the maintainer asks to "add a new skill", "scaffold a skill", or "create a brooks-lint mode". Do NOT trigger for: editing an existing skill's content, adding a single eval to an existing skill, or authoring skills for some other plugin.

2026-05-28186

brooks-sweep.md

from "hyhmrright/brooks-lint"

Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user wants to "fix everything", "sweep the codebase", "auto-fix all issues", "run all checks and fix them", "clean up the whole project", or asks for a single command that both diagnoses and remediates quality problems. Do NOT trigger for: read-only audits or health reports where the user only wants findings without code changes; single-dimension reviews (use the focused skill instead: brooks-review / brooks-audit / brooks-debt / brooks-test); server health checks, HTTP /health endpoints, Kubernetes probes, or application uptime.

2026-05-24186

brooks-health.md

from "hyhmrright/brooks-lint"

Combined codebase health dashboard that scores a project across all four quality dimensions — PR quality, architecture, tech debt, and test quality — in a single pass, drawing on twelve classic engineering books. Triggers when: user wants an overall quality assessment, asks "how healthy is this codebase?", "run all the checks", "give me a big-picture quality report", "I need a health score before the release", "what's the overall state of our code?", or wants to onboard a new team with a quality overview. Do NOT trigger for: server health checks, HTTP health endpoints, Kubernetes liveness/readiness probes, database health, or application uptime. Also do not trigger when the user specifically requests only one dimension — use the corresponding focused skill instead (brooks-review / brooks-audit / brooks-debt / brooks-test).

2026-04-29186

brooks-audit.md

from "hyhmrright/brooks-lint"

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?", "why does everything depend on everything?", "are our layers correct?", "where should this code live?". 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.

2026-04-29186

brooks-debt.md

from "hyhmrright/brooks-lint"

Tech debt assessment that identifies, classifies, and prioritizes maintainability problems — helping teams build a refactoring roadmap — drawing on twelve classic engineering books. Triggers when: user asks about tech debt, refactoring priorities, what to clean up first, or asks "why is this so hard to change?", "where's the most painful part?", "what should we fix first?", "how do I justify refactoring to management?", "why is our velocity dropping?". Do NOT trigger for: server health checks, HTTP /health endpoints, Kubernetes probes, database health, or application uptime — "health" in those contexts is infrastructure, not code quality. Also not for single-function refactoring questions.

2026-04-29186

brooks-review.md

from "hyhmrright/brooks-lint"

PR code review that surfaces decay risks, design smells, and maintainability issues with concrete Symptom → Source → Consequence → Remedy findings, drawing on twelve classic engineering books. Triggers when: user asks to review code, check a PR, shares a diff or pastes code asking "does this look right?" / "any issues here?" / "ready to merge?", or asks for feedback on a function, class, or file. Also triggers when user mentions: code smells / refactoring / clean architecture / DDD / domain-driven design / SOLID principles / Hyrum's Law / deep modules / tactical programming / conceptual integrity / Brooks's Law / Mythical Man-Month / second system effect. Do NOT trigger for: questions about how to write code from scratch, language syntax questions, or framework/tool questions where no existing code is shared.

2026-04-29186

package.json

"author": "hyhmrright"

"repository": "hyhmrright/brooks-lint"

Ouvrir le dépôt GitHub Voir les dépôts du créateur

$ install --global

$ download --local

Exécuter dans Manus

$ useful --forSOC

Développeurs de logicielsProfessions informatiques et mathématiques15-1252L4

name	release
description	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. 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.
disable-model-invocation	true

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.

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 the README badge.
Write the changelog. Add a new ## <version> section at the top of CHANGELOG.md with categorized notes (Added / Fixed / Changed) summarizing the commits since the last release tag (git log <last-tag>..HEAD --oneline).
Validate. npm run validate — fails if any manifest, the README badge, or the CHANGELOG entry is out of sync. Fix and re-run until clean. Then npm test.
Commit & push. Stage the changed manifests, README, and CHANGELOG; 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.

release

brooks-lint — Release

Plus depuis ce dépôt

brooks-lint — Release

Plus depuis ce dépôt