/fleet-release

name: fleet-release
description: 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.

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