Ops Update

OPS ► UPDATE — one-command local plugin upgrade

Load ops-rules before acting. Public repo (no personal data). Outbound: one draft → one approval → one send. If AskUserQuestion / Workflow are missing, follow Rule 10 in ops-rules (Hermes: numbered options / two-turn Telegram card; delegate_task).

Upgrades the local claude-ops plugin to the newest version published in the ops-marketplace catalogue, then leaves the box clean: no stale cache dirs, no dangling version-pinned paths.

Automatic daily check (detect only, never auto-installs)

bin/ops-update-check runs daily from the ops daemon (update-check service) and answers one question: is a newer version published? It writes the verdict to ~/.claude/state/ops-update/update-available.json and exits 3 when an update exists, 0 when current.

It never installs anything. Detection and application are deliberately split: a background job that swapped the plugin out mid-session would break a working install at the worst possible moment. Applying is always ops-update, run on the user's word.

When you see that an update is available — because the state file says so, or because the user asks — surface it once and offer to apply it:

"${CLAUDE_PLUGIN_ROOT}/bin/ops-update-check" --json    # current verdict, throttled to daily
"${CLAUDE_PLUGIN_ROOT}/bin/ops-update-check" --force   # recheck now, ignoring the throttle

Then a single AskUserQuestion: [Update now] [Show what changed] [Not now]. Only on Update now do you run bin/ops-update. Never chain the two, and never apply an update the user has not just agreed to in that exchange.

Checking on every skill call

The daily cron is the only thing that ever ran the check, so a box without the daemon (Linux, or launchd never set up) heard about a new version exactly never. bin/ops-pretool-skill-update closes that: a PreToolUse hook on ^Skill$ re-uses the same throttled check whenever an ops skill is invoked, so the first skill call of the day says what the daily cron would have said.

Behaviour is set by auto_update in preferences.json (or $OPS_AUTO_UPDATE):

auto is the one exception to the split above, and it stays opt-in for the reason stated there: the running session keeps the old version until it reloads, so the upgrade lands detached, behind a lock, and never prunes the tree the session is rooted in. Turning it on is the user's decision, not yours — never switch a box to auto on your own initiative.

Flags: --json (verdict on stdout), --no-fetch (compare against the catalogue already on disk, no network), --force (ignore the once-a-day throttle), --quiet (write state, print nothing — how the daemon runs it). Override the cadence with $OPS_UPDATE_CHECK_INTERVAL in seconds.

The workhorse is ${CLAUDE_PLUGIN_ROOT}/bin/ops-update. It runs a 9-step loop:

1. Refresh catalogue — claude plugin marketplace update ops-marketplace (git-pulls the clone).
2. Resolve target — newest version from the refreshed marketplace.json (or --to X.Y.Z).
3. Update plugin — claude plugin update ops@ops-marketplace, with a force-reinstall fallback (rm cache + claude plugin install) for the Claude Code bug where update reports "already latest" while the cache stays stale (anthropics/claude-code#61954).
4. Reapply patches — runs idempotent scripts in scripts/cache-patches/ against the new cache (empty when all fixes are upstream — the desired state).
5. Prune — deletes every old cache/ops-marketplace/ops/<ver>/ except the new one.
6. Rewrite — fixes stale cache/.../ops/<oldver>/ paths in live configs/scripts/systemd units only (never logs, memory, or transcripts — those use ${CLAUDE_PLUGIN_ROOT} at runtime so they self-resolve).
7. Migrate — runs ops-post-update-migrate (idempotent, per-version). It also maintains a stable cache/.../ops/current/ directory (rsynced from the new version and repointed in installed_plugins.json) so Claude Code GC'ing the old versioned dir mid-session never causes "Plugin directory does not exist" hook errors.
8. Local sync — if a linked local source checkout of this repo is present under ~/Projects, fast-forwards its main to origin/main so a dev clone never silently drifts behind the published release. Acts only on a clean main (never clobbers uncommitted WIP, a feature branch, or unpushed commits); a no-op when no checkout exists. Skip with --no-localsync.
9. Report — old→new, what changed, and that a restart / /reload-plugins is needed to load it.
10. Companions — bin/ops-update step 9 runs scripts/install-companions.sh against plugin-dependencies.json. Every companion with required: true is co-installed when missing and updated on every ops-update:
    • desktop-act — /ops:desktop + captcha cascade
    • gsd — /ops:flow project mode, /ops:projects, /ops:go
    • gstack — skills clone for /ops:flow ad-hoc (/spec /review /qa /ship)
    • superpowers — merge / orchestrate / triage checkpoints
    • feature-dev — /ops:ops-feature-dev Skip only with --no-companions or OPS_SKIP_COMPANIONS=1.

# manual companion pass
bash "${CLAUDE_PLUGIN_ROOT}/scripts/install-companions.sh"
bash "${CLAUDE_PLUGIN_ROOT}/scripts/install-companions.sh --status"
# skip from ops-update:
${CLAUDE_PLUGIN_ROOT}/bin/ops-update --no-companions