Package the repo as an Agent Plugin - #9
Merged
Merged
Conversation
The Agent Plugins standard expects skills under skills/ at the repository root. Ours were under .claude/skills/, a path named after one client, which sits badly with a project that describes itself by the open format it follows. .claude/skills stays as a symlink, so links people already made keep resolving. Git records the move as a rename, so history survives, and a symlink to a symlink resolves, so anyone who ran link-skills.sh notices nothing. This commit only moves files. Nothing inside them changes, which is the easiest kind of change for a fork to merge.
link-skills.sh now links skills/ into a project, still as .claude/skills on the receiving side, which is where a client looks. The workflow path filters, the documentation and the README tables follow the new location. Paths that describe a consumer's project rather than this repository are left alone. In a project set up by link-skills.sh the skills are still at .claude/skills, so the templates and the per-skill READMEs are already correct.
plugin.json validates against the 1.0.0 schema. With skills/ in place, a client that reads the manifest finds them where the standard says they are. The manifest is named java-agent-skills rather than after the repository. What a client shows in its plugin list should say what the thing is, and the repository keeps the name people search for. The version now lives in plugin.json, since clients read it from there. The changelog carries the same number, and validate-skills.sh fails when the two disagree, so one cannot be bumped without the other. It also checks that the .claude/skills compatibility path still resolves, which a checkout without symlink support breaks silently.
|
Verdict: APPROVE Files reviewed: No skill content changes detected. Findings:
Action required: None - ready to merge. This PR reorganizes the directory layout from |
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 #8.
Skills now live in
skills/, where the Agent Plugins standard expects them, and.claude/skillsstays as a symlink so nothing anyone already linked or copied stops working.The move is its own commit with no content changes in it, which is the easiest kind of change for a fork to merge. Git records it as a rename, so
git log --followstill walks through the history of every skill.The direction was picked for what breaks where symlinks are not supported, Windows without developer mode being the usual case. Whoever uses
.claude/skillsgets there throughlink-skills.sh, which is bash, anddocs/SCRIPTS.mdhas been telling them to use WSL or copy for months. Whoever installs this as a plugin looks inskills/and is much more likely to be on Windows. The real directory belongs where that audience is looking, and the symlink can be the part that degrades.plugin.jsonvalidates against the 1.0.0 schema with no missing required fields and no unknown ones. It is namedjava-agent-skillsrather than after the repository: a plugin list should say what the thing is, and the repo keeps the name people search for.The version anchor moves to
plugin.json, because that is where a client reads it.CHANGELOG.mdcarries the same number andvalidate-skills.shfails when the two disagree, so a release cannot half-happen. The validator also checks that.claude/skillsstill resolves toskills/, which is not paranoia: a contributor on Windows gets the symlink as a text file and committing that back would break it for everyone, silently.The README does not claim this installs anywhere. Nobody has tried it in a client yet. That line goes in once someone has.
Verified locally: the suite passes, both validators pass through either path, the compatibility check catches a
.claude/skillsmaterialised as a text file, and the version check catches a mismatch. What this PR cannot verify on its own is that thepathsfilter on the skill review workflow still fires now that it points atskills/**, which is part of why it is a pull request.