commit
Changelog and commit — lightweight motion for day-to-day plugin dev work in the monorepo. One commit per plugin scope; CHANGELOG and staging routed by detected…
Updates the minimum core version requirement for a fleet plugin in all three canonical places: `required_core_version` and `requires["claude-code-hermit"]` in `hermit-meta.json`, and the `dependencies` entry in `plugin.json`. Use this skill whenever the user says "bump core
$ npx -y skills add gtapps/claude-code-hermit --skill bump-core-req --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/bump-core-reqContext preview
The summary Claude sees to decide when to auto-load this skill.
Updates the minimum core version requirement for a fleet plugin in all three canonical places: `required_core_version` and `requires["claude-code-hermit"]` in `hermit-meta.json`, and the `dependencies` entry in `plugin.json`. Use this skill whenever the user says "bump core
name: bump-core-req description: > Updates the minimum core version requirement for a fleet plugin in all three canonical places: `required_core_version` and `requires["claude-code-hermit"]` in `hermit-meta.json`, and the `dependencies` entry in `plugin.json`. Use this skill whenever the user says "bump core requirement", "raise required_core_version", "make <fleet> require core X.Y.Z", "update min core for <fleet> plugin", or finishes shipping a core feature that fleet plugins need to declare they depend on. Also trigger when the user says "align fleet deps" or asks which version the fleet plugins are pinned to and wants to update them.
Update a fleet plugin's minimum core version in all three canonical locations.
Per this monorepo's conventions (`CLAUDE.md` → Conventions), the core version requirement lives in: 1. `plugins/<slug>/.claude-plugin/hermit-meta.json` → `required_core_version` — **authoritative**, read by `doctor-check.ts` at runtime to detect incompatible siblings 2. `plugins/<slug>/.claude-plugin/hermit-meta.json` → `requires["claude-code-hermit"]` — documentation mirror 3. `plugins/<slug>/.claude-plugin/plugin.json` → `dependencies[name=claude-code-hermit].version` — native Claude Code resolver field
All three must stay in sync. This skill is the single operation that touches all of them atomically. It leaves committing to the operator via `/commit`.
/bump-core-req <fleet-slug> [version]
If no slug was passed, or it's invalid:
1. Glob `plugins/*/.claude-plugin/plugin.json`. Collect directory names. 2. Remove `claude-code-hermit` from the list — that's core, not a fleet plugin. 3. Ask via `AskUserQuestion`: "Which fleet plugin to update?" with one option per slug.
If `claude-code-hermit` was explicitly passed as slug, abort: "Core doesn't depend on itself — pass a fleet plugin slug."
Validate `plugins/<slug>/.claude-plugin/hermit-meta.json` exists. If not: > Abort: "`<slug>` has no `hermit-meta.json` — not a fleet plugin or migration is incomplete."
If version was passed as an argument, strip a leading `v` if present. Validate the result matches `X.Y.Z` (digits only, two dots). If it doesn't match, abort with a clear message.
If no version arg, read `plugins/claude-code-hermit/.claude-plugin/plugin.json` → `.version`. This is the current shipped core version. Report it to the operator: "Autodetected core version: X.Y.Z".
Read both files:
Extract the **current** values of:
Identify the **prefix** on `old_dep_ver`: it's always one of `^`, `~`, `>=`, or exact (no prefix). Preserve it exactly when constructing the new value. The new dep version will be `<prefix>X.Y.Z`.
If all three fields already encode the target version (`old_range == ">=X.Y.Z"` and `old_dep_ver == "<prefix>X.Y.Z"`), print:
> `<slug> already requires core >=X.Y.Z — nothing to do.`
Exit cleanly. No edits made.
Do **surgical string replacements** — do not rewrite whole files. Use the `Edit` tool, targeting the exact text you read in Step 2.
**hermit-meta.json** (two replacements):
Both old values will be identical (e.g. `>=1.0.22`), but they appear in different key positions, so the surrounding context makes each Edit unambiguous.
**plugin.json** (one replacement):
New value: `"<prefix>X.Y.Z"` — same prefix, new version.
Re-read both files and confirm each of the three fields now contains the target version. If any field doesn't match, abort loudly with the field name and what was found vs expected.
Then run plugin validation:
claude plugin validate plugins/<slug> 2>&1
Abort on any error.
Print a concise summary block:
Bumped core requirement for <slug>: hermit-meta.json required_core_version : <old_range> → >=X.Y.Z hermit-meta.json requires : <old_range> → >=X.Y.Z plugin.json dependencies : <old_dep_ver> → <prefix>X.Y.Z Next steps: Run /commit to stage and commit this change. When ready to ship to operators: /release <slug>
No version bump, no CHANGELOG entry — those are for `/release` when the operator decides to ship.
If you know Claude Tag, the idea will feel familiar: hand Claude work through a channel, such as Discord, Telegram, or your custom integration, and get results back there.
Repo: gtapps/claude-code-hermit
Changelog and commit — lightweight motion for day-to-day plugin dev work in the monorepo. One commit per plugin scope; CHANGELOG and staging routed by detected…
Documentation-drift audit for the plugin monorepo. Audits either each scoped plugin's unreleased changelog claims or its latest shipped release from the…
Explain in plain language what a fix, feature, PR, or plan will actually change for downstream hermits and the operators chatting with them — a before/after…
Use this skill whenever the user wants to release, ship, prep, or cut versions for two or more plugins together on the current branch. Trigger on phrasings…
Daily release-pipeline digest with a change gate — reports which plugins are pending release, whether main's CI is green, which branches went stale, and GitHub…
Pre-release gate for the monorepo — establishes per-plugin release boundaries (each plugin's last tag → HEAD), audits every changed plugin's CHANGELOG against…