← ClaudeAtlas

skills-resynclisted

Re-sync the vendored user skills in ~/.claude/skills against their upstream plugin copies, and re-vendor the ones that moved after one confirmation. Manual maintenance task.
StefanoZaghi1987/ClaudeHarness · ★ 0 · AI & Automation · score 75
Install: claude install-skill StefanoZaghi1987/ClaudeHarness
These skills were copied out of their plugins so they survive the plugin being disabled, updated or swept. They receive no marketplace updates. `scripts/resync.sh` owns every mechanical step — refreshing upstream, resolving it, classifying drift, swapping the directory, replaying the protected local edits, restoring the invocation regime, verifying the result, rebasing the baseline, deleting its own leftovers. This document owns the judgement, and there is now exactly one occasion for it: **a patch that rejects**, meaning upstream rewrote a line a local edit owns. Everything else is decided by the script. Never write before the user confirms. ## Three sources of truth `scripts/inventory.tsv` — which plugin each skill came from, its subpath, and the upstream **tree hash** it was vendored at (a per-skill hash of the upstream skill directory, not a plugin commit sha — see *Upstream resolution*). The script resolves the upstream from the marketplace clone, so no version directory is recorded anywhere. The baseline column is rewritten by `--apply`; hand-editing it makes `--check` lie in both directions. `scripts/patches/<skill>.patch` — the protected local edits themselves, as a patch `--apply` replays onto each fresh vendor. Generated only by `--snapshot`, never by hand. This is what makes a re-vendor of an edited skill mechanical instead of a hand step nothing could confirm had happened. This document — *why* each protected edit exists, and why a skill is or is not in the