bump-core-req
Skill84 starsChanged 5 days agoMITView on GitHub
Updates the minimum core version requirement for a fleet plugin in all three canonical places: `required_core_version` and `requires["hermitd"]` 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.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- gtapps/hermitdword for word, first seen Nov 7, 2026
Other versions1 project uses a version of this.
Word for word · 1
- gtapps/hermitd★ 84100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- claude-harness-canarySkill
- commitSkill
- docs-driftSkill
- downstream-impactSkill
- fleet-releaseSkill
- pipeline-digestSkill
- pre-release-reviewSkill
- pricing-refreshSkill
- releaseSkill
- release-statusSkill
- routine-test-pingSkill
- stale-proposalsSkill
- tackle-issueSkill
- test-runSkill
- bump-core-reqSkill
- commitSkill
- docs-driftSkill
- downstream-impactSkill
- fleet-releaseSkill
- pipeline-digestSkill
- pre-release-reviewSkill
- pricing-refreshSkill
- releaseSkill
- release-statusSkill
- routine-test-pingSkill
- stale-proposalsSkill
- test-runSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 2 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Update a fleet plugin's minimum core version in all three canonical locations.
- Very specific: line 24
All three must stay in sync.
- Distinctive: line 39
If no slug was passed, or it's invalid:
- Very specific: line 42
Remove hermitd from the list — that's core, not a fleet plugin.
- Very specific: line 43
Ask via AskUserQuestion: "Which fleet plugin to update?" with one option per slug.
- Very specific: line 45
If hermitd was explicitly passed as slug, abort: "Core doesn't depend on itself — pass a fleet plugin slug."
- Very specific: line 52
If version was passed as an argument, strip a leading v if present.
- Very specific: line 54
If no version arg, read plugins/hermitd/.claude-plugin/plugin.json → .version.
- Very specific: line 71
If all three fields already encode the target version (old_range == ">=X.Y.Z" and old_dep_ver == "<prefix>X.Y.Z"), print:
- Very specific: line 79
Do surgical string replacements — do not rewrite whole files.
- Very specific: line 117
No version bump, no CHANGELOG entry — those are for /release when the operator decides to ship.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
bump-core-req
Update a fleet plugin's minimum core version in all three canonical locations.
Background: why three places?
Per this monorepo's conventions (AGENTS.md → Repository and architecture), the core version requirement lives in:
plugins/<slug>/.claude-plugin/hermit-meta.json→required_core_version— authoritative, read bydoctor-check.tsat runtime to detect incompatible siblingsplugins/<slug>/.claude-plugin/hermit-meta.json→requires["hermitd"]— documentation mirrorplugins/<slug>/.claude-plugin/plugin.json→dependencies[name=hermitd].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.
Usage
/bump-core-req <fleet-slug> [version]<fleet-slug>— directory name of the fleet plugin underplugins/(e.g.hermitd-fitness)[version]— optional target version like1.0.26. If omitted, readplugins/hermitd/.claude-plugin/plugin.json→.versionand use that.
Steps
Step 0: Resolve slug
If no slug was passed, or it's invalid:
- Glob
plugins/*/.claude-plugin/plugin.json. Collect directory names. - Remove
hermitdfrom the list — that's core, not a fleet plugin. - Ask via
AskUserQuestion: "Which fleet plugin to update?" with one option per slug.
If hermitd 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 nohermit-meta.json— not a fleet plugin or migration is incomplete."
Step 1: Resolve target version
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/hermitd/.claude-plugin/plugin.json → .version. This is the current shipped core version. Report it to the operator: "Autodetected core version: X.Y.Z".
Step 2: Read current state
Read both files:
plugins/<slug>/.claude-plugin/hermit-meta.jsonplugins/<slug>/.claude-plugin/plugin.json
Extract the current values of:
required_core_version(from hermit-meta.json) → call thisold_range(e.g.>=1.0.22)requires["hermitd"](from hermit-meta.json) → same value, confirm they matchdependencies[name=hermitd].version(from plugin.json) → call thisold_dep_ver(e.g.^1.0.22)
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.
Step 3: No-op short-circuit
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.
Step 4: Edit the three fields
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):
- Replace
"required_core_version": "<old_range>"→"required_core_version": ">=X.Y.Z" - Replace
"hermitd": "<old_range>"→"hermitd": ">=X.Y.Z"
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):
- Locate the exact string
"<old_dep_ver>"that appears as the version value inside thehermitddependency entry. Because there is exactly onehermitddependency, replace the precise version string in context. Use enough surrounding text (the"name": "hermitd"line or inline prefix) to make the replacement unambiguous if the version string is short.
New value: "<prefix>X.Y.Z" — same prefix, new version.
Step 5: Verify
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>&1Abort on any error.
Step 6: Report
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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

