/check-skill-updates

name: check-skill-updates
description: '[Adam''s Skills] Check whether the installed copy of this skills collection is behind its remote, and offer to update it. Runs a script that resolves the clone the skills are linked from, respects a once-a-day rate limit and a remembered refusal, and reports one of: up to date, N commits behind, unsafe to touch, or offline. Only "behind" is ever mentioned to the user; everything else is silent. On a yes it pulls and re-links, changing nothing about which skills are installed. Use when the user asks whether their skills are up to date, or when another skill reaches a natural close and wants to mention a waiting update.'
allowed-tools: Bash, Read

check-skill-updates

Say nothing unless there is something to say. This skill exists to mention a waiting update **once**, at a moment when the user is not busy — and to be invisible the rest of the time.

Run it

node <repo>/tools/freshness/check.mjs

`<repo>` is the clone the skills are linked from. Resolve it from **this file's real path**, not from the working directory: `~/.claude/skills/check-skill-updates` is a link, so its target's `../../tools/freshness/check.mjs` is the script. The working directory is whatever the user happens to be editing, which is usually a different repo entirely.

The script prints one line of JSON and nothing else. Flags: `--force` (the user asked directly, ignore the rate limit), `--update` (pull and re-link), `--decline` (remember this was turned down).

What each verdict means

| Verdict | What you say | |---|---| | `fresh` | Nothing. Silence is the correct output. | | `too-soon` | Nothing. Already checked within the day. | | `offline` | Nothing. A failed fetch is not the user's problem to hear about. | | `not-installed` | Nothing, unless the user asked directly — then say the clone could not be found. | | `unsafe` | Nothing, unless the user asked directly — then say the clone is on `<branch>` or has uncommitted changes, so it is not safe to pull for them. | | `behind` | **One line.** See below. | | `updated` | One line: what was applied. If `refreshed` is false, say the pull worked but the re-link did not, and name `node <repo>/install.mjs --refresh`. |

When the user invoked this skill directly, report every verdict plainly — being asked a question is licence to answer it. When another skill called you, only `behind` earns any words at all.

Mentioning an update

One line, at the very end of whatever the calling skill was already saying, never in the middle:

> Skills update available — 3 commits behind (`feat(are-we-done): add close-out gate`). Update now?

Then honour the answer:

• **Yes** → run with `--update`, then say in one line what was applied. The pull is safe mid-session:

it changes the text of skills you already have, adds and removes nothing, and anything already running finishes on the version it started with.

• **No** → run with `--decline` and drop it. That version is never raised again, however long it

sits there. Do not re-ask tomorrow; the answer has not expired.

• **No answer** → drop it. An ignored offer is a no.

Never mention an update next to a failure. If the calling skill is reporting blockers, a broken build, or anything the user has to act on, stay silent — an update offer stapled to bad news dilutes both, and this is the one thing here that can always wait.

Who calls this

`/are-we-done` on a clean close, `/ship-it` once the release is out and verified, `/where-are-we` when the user has been away. All of them skip this silently if it is not installed; none of them treat it as a prerequisite. The rule they share is that the work has to be finished first — this is a footnote to a natural close, never an interruption of one.