Package the repo as an Agent Plugin

[decebals]

Agent Plugins 1.0, published in August 2026, packages Agent Skills and MCP servers into one folder that Cursor, GitHub Copilot, VS Code, Codex and others install directly. For this repo it would mean people stop copying skill folders by hand.

The obstacle looked bigger than it is. The standard puts plugin.json at the root and skills under skills/, while ours live in .claude/skills/. Moving them would break every symlink, every copy people have already made, and every path in our own documentation.

We do not have to move them. Git stores symlinks natively, as mode 120000 with the target as the blob content, so a committed skills -> .claude/skills at the root survives a clone and satisfies discovery. I tried it here: a client looking in skills/ sees all 18, and both validators pass when run through the link. Nothing moves, link-skills.sh is untouched, and the Claude Code path is unchanged.

The direction of the link matters. Git on Windows without developer mode writes symlinks out as plain text files, which docs/SCRIPTS.md already warns about. With skills -> .claude/skills, a Windows user without symlink support loses plugin consumption and keeps a working .claude/skills. Pointing it the other way would have cost them the primary path instead.

What needs deciding

plugin.json requires a name, and that name is what a client shows in its plugin list. claude-code-java reads oddly for a plugin that no longer claims to be Claude-specific, so this brings the repository naming question back from a different angle.

There may be a way out that the rename discussion did not have: the plugin name and the repository name do not have to match. A plugin named java-agent-skills inside a repository still called claude-code-java costs nothing and keeps the discovery value the current repo name is doing.

Scope, if we go ahead

• skills -> .claude/skills symlink at the root
• plugin.json with $schema, name, version, description, license, repository, homepage, keywords
• validate-skills.sh gains a check that the symlink resolves, so a bad checkout fails the build instead of silently shipping a plugin with no skills in it
• the README claims installability only after someone has actually installed it somewhere and confirmed it works

Out of scope

mcp.json. There are MCP templates here, but they are per-project configuration rather than servers this repo provides.

Related: #6, which decides where the version lives. If we adopt plugin.json, its version field becomes the natural anchor and CHANGELOG.md stays the record for humans.