Files
dotfiles/modules/claude-code/skills/update-skills/SKILL.md
alexion 7809e079e3 docs(claude-code): teach the skill-management skills the Nix layout
~/.claude/skills is generated by home-manager: the directories are real
but every leaf file is a read-only symlink into the store. The skills
that author and install skills assumed it was an ordinary writable tree.

- craft-skill: personal skills are authored in modules/claude-code/skills
  and applied by a rebuild, never edited under ~/.claude/skills; writing
  there succeeds silently and strands the skill outside the repo.
- setup-skills, update-skills: copy out of the library with cp -rL and
  chmod -R u+w. A plain cp -r copies the symlinks, committing store paths
  into the project, and dereferenced files keep the store's read-only mode.
- craft-skill also staged through `dot add`, a fish function this repo no
  longer carries; plain git add replaces it.
2026-07-19 08:34:22 -04:00

2.6 KiB

name, description, disable-model-invocation
name description disable-model-invocation
update-skills Check the current project's installed library skills for upstream changes and apply the safe ones. true

Compares every skill listed in the current project's .claude/skills-lock.yaml (see LOCKFILE.md for its schema) against both the project's own copy and the current library source, and decides what to do about each one. Never installs a skill that isn't already there — that's setup-skills's job.

Steps

  1. Read .claude/skills-lock.yaml. If it doesn't exist or is empty, tell the user there's nothing to check and stop.

  2. For each {name, hash} entry, compute:

    • project_hash: ~/.claude/skills/setup-skills/hash-dir.sh .claude/skills/<name>
    • library_hash: ~/.claude/skills/setup-skills/hash-dir.sh ~/.claude/skills/library/<name>

    If either path is missing entirely, report that anomaly for this skill (don't try to classify it) and move on to the next entry.

  3. Classify each entry against the table in LOCKFILE.md, using project_hash in place of "project copy" and library_hash in place of "library source". The two outcomes that need action below are safe update (stored matches project, differs from library) and conflict (stored differs from both). "Locally customized" needs no message beyond the summary.

  4. If there are any safe updates, list them by name and ask for one confirmation to apply all of them — unless the user's invocation already included an explicit go-ahead argument (e.g. -y, yes), in which case apply them without asking. Applying means: delete .claude/skills/<name>/ entirely and copy ~/.claude/skills/library/<name>/ in its place with cp -rL followed by chmod -R u+w (the library is read-only symlinks into the Nix store; a plain cp -r would put store paths into the project), so no file the project copy had but the library no longer has can survive — then recompute its hash and overwrite that entry's hash in .claude/skills-lock.yaml in place.

  5. For every conflict, report it and show a recursive diff between the project's copy and the library's current version (diff -ru .claude/skills/<name> ~/.claude/skills/library/<name>). Do not modify the project's copy or the lockfile entry for a conflicted skill under any circumstances — surfacing it is the whole job here.

  6. Finish with a summary: updated, left alone (customized), conflicted, already current, and any anomalies from step 2.