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 changes

Steps

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

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

1.6. Reconcile the proposal queue (once, fleet-wide)

/release step 1.6 runs /stale-proposals per plugin, but the proposal queue is monorepo-wide shared state, not per-plugin: a proposal's shipped-evidence is scanned from all plugins' CHANGELOGs and recent PRs regardless of which single plugin /release targets. Running it once per plugin in a fleet re-scans the same evidence and finds nothing new on every pass after the first.

Skip this step entirely if .claude/skills/stale-proposals/ doesn't exist. Otherwise run it exactly once here, before the per-plugin loop, the same way /release step 1.6 does: dispatch a general-purpose subagent at model: "sonnet" to run stale-proposals/SKILL.md's Steps 1–2b, then apply SHIPPED-STRONG verdicts per that skill's Step 3. SHIPPED-WEAK and AGED verdicts go through AskUserQuestion exactly as stale-proposals/SKILL.md Step 4 describes.

When invoking each plugin's /release in steps 5 and 7 below, skip its step 1.6 — it already ran here.

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:

1. Files under plugins/<slug>/ changed on this branch vs base: git diff <base>..HEAD --name-only -- plugins/<slug>/ is non-empty
2. plugin.json version is ahead of the last <slug>--v* tag — same "already-bumped" detection as /release step 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:

1. hermitd goes first if present
2. 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 /release step 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, skipping its step 1.6 (already run once in step 1.6 above), then:

git push origin main

Then 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.json

These 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, skipping its step 1.6 (already run once in step 1.6 above), then:

git push origin main

Then 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)