@skills: using agent skills without clogging the system prompt
Sh0ny
15 августа 20262 min read
In short
Installing every skill turns its description into a permanent competitor for space in the agent's context. @skills proposes separating storage, content and automatic invocation — and attaching a skill only at the moment it is read.
Agent skills face an unexpected shortage: not of instructions themselves, but of room for them to sit permanently in the system prompt. @skills proposes not installing skills at all — the agent addresses the path it needs, reads the file and gains the ability to use it.
According to the protocol's authors there are already 56,804 public agent skills, and teams hold many more private instructions besides. Under the usual installation, each skill's description stays in the system prompt and competes for fewer than 100 reliable invocation slots. As a result the long tail of skills goes almost unused, and a team's internal playbooks fight for the same limited space.
What matters here is not the magic of a new format but the separation of three different jobs: storing content, keeping it in the project, and deciding automatically when to invoke it. Only the automatic trigger mechanism should stay in the prompt. The skill itself can be addressed by path, read, and if needed copied into the project's Git-tracked tree for adaptation and ownership.
This also changes the model for bundles. A catalogue becomes a menu: you can address a single skill, a subdirectory or a collection without installing everything wholesale. The protocol needs no manifest, lockfile or registration, and SKILL.md stays unchanged. Any agent that can read files and run commands can become a client through a single instruction file. The specification is published on GitHub, and there is an implementation in the AdaL CLI.
But the problem does not disappear entirely — it moves. Paths address skills you have already found well enough, yet on their own they do not help you find them. For that the authors offer an optional free hub, atskills.one, with search and ranking, repository-free hosting, private and team collections, and skill creation in a single screen. Local paths and gh: work without the hub, and indexed GitHub skills keep their gh: identifiers. That said, what we have so far is a protocol and its implementation, not proof that agents will actually become noticeably more useful on real projects.
If your skills already live in the project, what gets in the way more right now: the lack of room in the prompt, or being unable to find the instruction you need quickly? Source: cs.AI updates on arXiv.org