dotfiles/modules/claude-code/skills/setup-skills/SKILL.md at 4c0d36324c33c28da7e75202fad46ea8ebff78b6

Files

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.4 KiB

Raw Blame History

name, description, disable-model-invocation

name	description	disable-model-invocation
setup-skills	Add relevant skills from the shared skills library to the current project.	true

Adds opt-in, project-specific skills from ~/.claude/skills/library/ into the current project's .claude/skills/, tracked in .claude/skills-lock.yaml (see LOCKFILE.md for its schema). Only ever adds — checking already-installed skills for updates is update-skills's job, not this one's.

The library is a tree of read-only symlinks into the Nix store, so every copy out of it must dereference (cp -rL) and then restore write permission (chmod -R u+w). A plain cp -r copies the symlinks themselves, putting store paths into the project that break on any other machine.

Steps

Read .claude/skills-lock.yaml in the current project, if it exists. Note every skill name already listed — these are already installed and must not be re-proposed.
List every skill under ~/.claude/skills/library/*/SKILL.md and read each one's name and description.
Inspect the current project (file tree, manifests like pyproject.toml/package.json, file extensions present, etc.) and judge which library skills — excluding ones already installed — seem relevant, the same way you'd reason about any unfamiliar codebase. Propose that shortlist to the user with your reasoning, one line per skill. If the user asks to see the full catalog instead, list every library skill (minus already-installed ones) with its description.
Let the user confirm, adjust, or pick freely from the full list.
For each confirmed skill:
- If .claude/skills/<name>/ already exists in the project and is not in the lockfile, skip it and tell the user why (a same-named skill already lives there and isn't tracked — remove or rename it first if they want the library version).
- Otherwise, copy ~/.claude/skills/library/<name>/ to .claude/skills/<name>/ in the project with cp -rL followed by chmod -R u+w, run ~/.claude/skills/setup-skills/hash-dir.sh .claude/skills/<name>, and append {name, hash: <output>} to .claude/skills-lock.yaml (create the file, an empty YAML list, if it doesn't exist yet).
Report what was added and what was skipped, and why.

Done when every confirmed skill is either copied and recorded in the lockfile, or explicitly skipped with a stated reason.

2.4 KiB Raw Blame History

Steps

2.4 KiB

Raw Blame History