fleet-release
Skill84 starsChanged 5 days agoMITView on GitHub
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 like "release both plugins", "ship them together", "release all changed plugins", "fleet release", "multi-plugin release", "release in order", or "release everything on this branch". Handles dependency ordering (core first), automatic required_core_version sync, and tags each plugin immediately on main.
- Commits and pushes
2 other projects use a version of this.
Adopted by
Most recently taken up by
- gtapps/hermitdword for word, first seen Nov 7, 2026
- pdw96/fleettheir own version, first seen Sep 9, 2026
Other versions2 projects use a version of this.
Word for word · 1
- gtapps/hermitd★ 84100% same
Edited · 0
None found.
Wrote their own version · 1
- pdw96/fleet★ 2same name
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
- bump-core-reqSkill
- claude-harness-canarySkill
- commitSkill
- docs-driftSkill
- downstream-impactSkill
- 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
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 24
Run git branch --show-current.
- Very specific: line 46
If condition 1 holds but condition 2 does not (branch changes but version not bumped yet): include the plugin and note it will need a full …
- Distinctive: line 57
If version is already ahead of last tag: mark as "already prepped at vX.Y.Z" — no bump step needed for it
- Distinctive: line 73
Wait for confirmation. If the user adjusts, accept corrections before continuing.
≈ “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
Fleet Release
Orchestrate a multi-plugin release: determines order, runs each plugin's /release prep sequentially, injects cross-plugin hermit-meta.json sync between core and domain plugins, tags each plugin on main.
Runs on main. Each plugin is committed, tagged, and pushed in order. No PR needed.
Usage
/fleet-release [slug1 slug2 ...] explicit list
/fleet-release auto-detect from current branch
/fleet-release --dry-run show plan, no file changesSteps
1. Validate branch
Run git branch --show-current. If not on main or the repo's default branch: stop and tell the user to switch to main before running a fleet release.
1.5. Refresh the knowledge graph (fleet-wide)
/release only refreshes the root graph plus its own target plugin's graph (single-plugin scope). A fleet release touches multiple plugins at once, so refresh everything in one shot before the per-plugin /release runs:
bash scripts/graphify-refresh.shAST-only, no API cost. Skips silently if graphify isn't installed or the session is in a worktree; a single plugin's update failure warns and continues rather than aborting — a stale graph must never block a release.
2. Determine target plugins
Explicit slugs: validate each exists at plugins/<slug>/.claude-plugin/plugin.json. For any unknown slug, abort and list available slugs.
Auto-detect (no args): discover all slugs from ls plugins/ (never hardcode or rely on session context), then collect plugins where both:
- Files under
plugins/<slug>/changed on this branch vs base:git diff <base>..HEAD --name-only -- plugins/<slug>/is non-empty plugin.jsonversion is ahead of the last<slug>--v*tag — same "already-bumped" detection as/releasestep 2
Skip plugins with no plugin.json version or no tags (unstructured). Note skipped plugins in output.
If condition 1 holds but condition 2 does not (branch changes but version not bumped yet): include the plugin and note it will need a full /release prep run.
3. Determine release order
Rule — not a graph:
hermitdgoes first if present- Remaining plugins in the order the operator specified, or alphabetical for auto-detect
4. Determine version bumps and confirm upfront
For each plugin in order:
- If version is already ahead of last tag: mark as "already prepped at vX.Y.Z" — no bump step needed for it
- Otherwise: inspect
git log <last-tag>..HEAD -- plugins/<slug>/to suggest patch/minor bump (same heuristics as/releasestep 2)
Present the full plan at once before touching any file:
Release plan:
hermitd 1.0.22 → 1.0.23 (patch)
hermitd-dev already prepped at 0.2.2
Dep sync after core prep:
hermitd-dev required_core_version: >=1.0.22 → >=1.0.23
Confirm? [Yes / Adjust versions]Wait for confirmation. If the user adjusts, accept corrections before continuing.
With --dry-run: stop here. Print the plan and exit without touching anything.
5. Run /release for core (if in fleet)
Invoke the full /release hermitd skill logic through the commit step, then:
git push origin mainThen run tag and push (claude plugin tag --push) and gh release create. The branch push must happen before tagging so the release commit is on the remote before the tag points to it.
6. Inject cross-plugin dep sync
Immediately after core's release commit and tag, before any domain plugin runs:
NEW_CORE=$(jq -r .version plugins/hermitd/.claude-plugin/plugin.json)For each domain plugin in the fleet that has plugins/<slug>/.claude-plugin/hermit-meta.json:
jq --arg v ">=$NEW_CORE" '
.required_core_version = $v |
.requires["hermitd"] = $v
' plugins/<slug>/.claude-plugin/hermit-meta.json > tmp && mv tmp plugins/<slug>/.claude-plugin/hermit-meta.jsonThese changes will be staged and committed as part of each domain plugin's /release run in step 7 — no separate commit needed.
Only update plugins in this fleet. Plugins not being released are not touched.
7. Run /release for each domain plugin
For each domain plugin in order, invoke the full /release <slug> skill logic through the commit step, then:
git push origin mainThen tag and push (claude plugin tag --push) and gh release create. Always push the branch before tagging — same rule as step 5. The updated hermit-meta.json from step 6 will be included in the files that release commit touches.
8. Report
Fleet release complete:
hermitd v1.0.23 (commit abc1234, tag hermitd--v1.0.23)
hermitd-dev v0.2.3 (commit def5678, tag hermitd-dev--v0.2.3)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.

