clean up retired skills on the claude target - #15
Merged
Conversation
|
| Filename | Overview |
|---|---|
| setup | Adds Claude-specific managed-skill cleanup and fully addresses the previously reported nested-path symlink bypass. |
| .github/workflows/setup.yml | Adds focused lifecycle and deletion-boundary tests, including a regression test for the previously reported nested symlink escape. |
Reviews (2): Last reviewed commit: "reject nested manifest paths" | Re-trigger Greptile
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #14
The
claudetarget installsoss-<skill>/SKILL.md, one level deeper thanreset_managedhandles, so it recorded nothing and cleaned up nothing. A skill retired or renamed upstream stayed in~/.claude/skillsand kept being offered. The other eight targets already do this correctly.Adds
reset_managed_skillsandrecord_managed_skill, which apply the same two proofs one directory deeper: the name has to be in theoss-<skill>/SKILL.mdnamespace setup owns, and the file has to still be byte for byte what setup wrote. A third check rejects a symlinkedoss-<skill>/, which would otherwise put the delete outside the skills directory. The existing functions are untouched, so the eight working targets are not in the blast radius.An install made before this change carries no manifest. The first run after upgrading adopts it and deletes nothing, so a skill retired before the upgrade stays until you remove it by hand.
The new CI step covers each guard with a case that fails when the guard is removed:
Verified by mutating
setupfour ways, one per guard, each failing with its own message, and the clean tree passing. Also checked that your own skills, your ownoss-named directories, and your files inside a managed skill directory all survive. All 24 steps of the install job pass locally.