The Agent Skill

The repository doubles as a plugin marketplace, so installation is two commands inside Claude Code:

The skill then loads on demand in every project, and /plugin is also where updating and removing it live.

Copy the skill directory into the project’s .claude/skills/ for a single project instead, so that collaborators get the skill by cloning and install nothing of their own:

A project-level copy is also what Cursor and GitHub Copilot read, as their sections below say, so one directory can serve three tools.

Codex reads skills from ~/.codex/skills for every project, and from a project’s own .codex/skills. Copy skills/spider-silk into either one.

Cursor reads a project’s .cursor/skills/ and the user-level ~/.cursor/skills/. It also reads the project’s .claude/skills/, so a project already set up for Claude Code needs nothing more.

Copilot reads a project’s .github/skills/, and ~/.copilot/skills/ for the coding agent and the CLI. It too reads the project’s .claude/skills/.

The format is an open standard, and this skill uses nothing tool-specific: YAML frontmatter with a name and a description, a Markdown body, and relative links to the reference files beside it. Any tool that discovers SKILL.md files takes the same directory unchanged. https://agentskills.io keeps the list of them.

SKILL.md carries what every task needs: the framework’s principles stated as rules an agent must not code against, the dependency and plugin repositories a first build needs, and the core API at a glance. Five reference files carry the rest, one per territory: setup, the web API, content, servers and deployment, and testing. An agent then reads only the territory its task touches. Nothing in the skill is new information: every statement is this manual, compressed for an agent’s context window instead of a reader’s screen.

The skill was benchmarked in 2026-08 by running the same three tasks twice, once with the skill installed and once without, on three Claude models: Fable 5, Opus 5, and Sonnet 5. Every result was graded against eighteen behavioural assertions per arm. The tasks were a notes API built from an empty directory, a content-negotiation-plus-API-key change to a working app, and an SSE endpoint whose literal path had to be registered ahead of an existing {id} route.

Every assertion passed in every run, with the skill and without, on all three models. An agent without the skill is not helpless: given the published jars, every model reconstructed the API by unpacking the sources jar or running javap over ~/.m2, and found its way to accepts, the before-filter’s null contract, and WebResponse.sse on its own.

What the skill changes is what that reconstruction costs. With the skill the same tasks completed with 12% fewer tokens on Fable 5, 16% fewer on Opus 5, and 22% fewer on Sonnet 5. The saving grows as the model tier goes down, because the reconstruction is what gets more expensive: the skill-less baseline cost 80k tokens per task on Fable, 100k on Opus, and 130k on Sonnet. Wall-clock time moved only three to six percent, because Gradle dominates it. Even on the top model tier, where correctness converges, the skill’s advantage is token savings: the excavation an agent would otherwise repeat in every project is done once, in the skill.

Two effects never reached the pass rate but are worth recording. The skill-less agents, told the benchmark machine held the artifacts in mavenLocal, shipped builds that resolve nowhere else, where the skill’s agents declared the GitHub Packages repository and its credential pattern alongside. The one run that stumbled into the registration-order trap fixed it by matching the failure to the skill’s own warning, where the skill-less runs had to derive the rule from scratch before writing code.

The numbers are single runs of each task on one machine, so read them as a shape, not a measurement.