~/.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.
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
-
Read
.claude/skills-lock.yaml. If it doesn't exist or is empty, tell the user there's nothing to check and stop. -
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.
-
Classify each entry against the table in LOCKFILE.md, using
project_hashin place of "project copy" andlibrary_hashin 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. -
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 withcp -rLfollowed bychmod -R u+w(the library is read-only symlinks into the Nix store; a plaincp -rwould 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'shashin.claude/skills-lock.yamlin place. -
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. -
Finish with a summary: updated, left alone (customized), conflicted, already current, and any anomalies from step 2.