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