Li Yin, Zhi Li, Zhan Shi, Haoran Zhang, Haebin Seong, Zhangyang (Atlas) Wang
5 min
Coding agents currently deliver procedural knowledge—skills—by installing them into a system directory. Once installed, a skill's description is permanently injected into the agent's system prompt. This creates a significant problem: the agent's attention budget is strictly limited, and the 56,804 publicly available skills are forced to compete for fewer than 100 reliable trigger slots. This leads to "trigger-engineering," where authors pad descriptions with complex instructions to ensure their skill fires, which in turn increases prompt bloat and degrades overall model reasoning performance.
@skills proposes an open protocol that decouples the three functions bundled into current installations: content, persistence, and auto-triggering. By separating these, the protocol introduces three distinct tiers of delivery:
This protocol transforms skills from a commitment into a decision. Because referencing a skill costs nothing that persists, users can try new capabilities without the overhead of managing installations across multiple agents or machines. For teams, it provides a unified way to share private workflows that are version-controlled and reviewed like code. By moving away from an install-only lifecycle, the ecosystem can scale to support tens of thousands of skills without hitting the hard limits of the model's attention budget.
There are 56,804 public agent skills today, and teams write many more privately. The dominant delivery model is installation: once installed, a skill's description remains in the system prompt, competing for fewer than 100 reliable trigger slots. This leaves the long tail with no practical path to use and forces teams' own playbooks to compete for the same scarce space. We observe that installation bundles three separable functions: content, persistence, and automatic triggering. Only the last requires prompt residency. We therefore propose @skills, an open protocol that separates them. A path addresses any skill, subtree, or collection, and reading a skill is sufficient to use it, so nothing is installed or made resident. The operation vendors a copy at the same path into a project's Git-tracked tree for adaptation and ownership. The operation adds one .gitignore-style line, the only element that costs prompt residency. A directory is a menu, making bundles ordinary directories rather than all-or-nothing units. The protocol requires no manifest, lockfile, or registration, and SKILL.md remains unchanged. @skills is additive, ships as an installable package, and turns any agent that can read files and run commands into a client through a single instruction file. Its open specification is at https://github.com/SylphAI-Inc/atskills and it is implemented in the AdaL CLI at https://adalagent.ai . Because paths address skills well but cannot find them, the protocol is paired with a free hub at https://atskills.one for corpus-wide search and ranking, repository-free hosting, private and team collections, and one-screen authoring. The hub is optional: gh: and local paths resolve without it, and indexed GitHub skills retain their gh: identities. Install less, use more.
Sam: But that raises a real question about reliability. If skills aren't resident, the agent has to know to look for them. Doesn't that just shift the failure mode from prompt saturation to retrieval miss?
Alex: The paper addresses this directly, and it's worth being precise about the claim. The authors aren't arguing that on-demand retrieval is perfect — they're arguing that the current auto-triggering mechanism is already unreliable, and that explicit, deterministic references give you more control than the probabilistic lottery of hoping the right skill fires from a crowded resident prompt. The trade-off is: you lose the "set-and-forget" convenience of installation, but you gain predictability in when and how skills are invoked.
Sam: That's a meaningful distinction. Unreliable-but-automatic versus reliable-but-explicit. For a researcher thinking about agent system design, that's actually a cleaner failure mode to reason about.
Alex: And that's probably the paper's strongest contribution as a position piece — not a new algorithm, but a cleaner conceptual vocabulary for a problem that's been treated as an engineering nuisance rather than an architectural constraint. Treating attention as a genuinely scarce budget, and designing the skill delivery system around that scarcity, changes how you think about scaling agent capability.
Sam: Though I'd want to see empirical work on where the crossover point is — at what skill-set size does the tiered model actually outperform naive installation, and how sensitive is that to the underlying model's context length?
Alex: That's the open question the paper leaves on the table. As a position paper, it's making the structural argument and proposing the framework. The ablations that would tell you how much reasoning degradation you actually recover, and under what conditions, aren't here yet. That's the work this paper is trying to motivate.
Sam: Fair enough. It's a well-posed problem statement, and the tiered model is a concrete enough proposal that it's testable. Worth watching for the follow-up empirical work.
Alex: Agreed. If you're building or evaluating agent systems that rely on large skill libraries, the core intuition here — that attention is a budget and your delivery mechanism should respect that — is worth taking seriously regardless of how the specific implementation details shake out. Thanks for listening to ResearchPod.