agentleFS
Sign inStart free
adamlinscottadamlinscott/claude-skills/skills/check-skill-updates/SKILL.md

check-skill-updates

Skill3 starsChanged 14 days agoMITView on GitHub

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

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When the user invoked this skill directly, report every verdict plainly — being asked a question is licence to answer it.

    line 38
  2. Distinctive:

    Never mention an update next to a failure.

    line 56

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

VerdictWhat you say
freshNothing. Silence is the correct output.
too-soonNothing. Already checked within the day.
offlineNothing. A failed fetch is not the user's problem to hear about.
not-installedNothing, unless the user asked directly — then say the clone could not be found.
unsafeNothing, 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.
behindOne line. See below.
updatedOne 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free