The @skills Proposal: Stop Paying Prompt Space for Every Agent Skill (2026)

Your agent can have thousands of useful procedures and still behave as if it has none. The failure may happen before the model reasons: the product has no reliable way to decide which procedure deserves attention.

Quick take

Trend: agent skills are moving from an install-and-forget convention toward a delivery system that separates content, persistence, and automatic triggering.
Fresh signal: the Aug. 12, 2026 paper "@skills: Attention Is All You Have" reports a July crawl of 56,804 public skills across 1,133 GitHub repositories and argues that install-only delivery makes them compete for fewer than 100 reliable auto-trigger slots per agent.
Product implication: the deployment unit is not just model + tools. It is model + tools + the policy that decides which procedural knowledge is resident, discoverable, and loaded at the point of use.
Action window: audit one agent workflow now. Keep only rules that must fire without user intent in the always-on prompt; move the rest into explicit, searchable, versioned skills.
Evidence boundary: @skills is a proposed open protocol grounded in ecosystem measurement and attention literature. The paper has not run a controlled experiment measuring trigger reliability as installed-skill count rises.

What changed

An agent skill is procedural knowledge packaged as a folder: a SKILL.md file can point to instructions, scripts, templates, and other resources. Anthropic introduced the pattern as a way to turn a general-purpose agent into a specialist without building a separate agent for every job. Its design uses progressive disclosure: the agent keeps a short name and description available, reads the full SKILL.md only when the skill seems relevant, and opens deeper reference files only when needed. The engineering explanation from Anthropic uses a PDF skill for document editing as the concrete example.

That solved one problem—how to package expertise—but created a second one: how to distribute a large and growing library of expertise without filling the agent's context with descriptions that may never be used.

The new paper's diagnosis is architectural. In the dominant install-only workflow, three separate decisions are bundled together:

Content: what the skill says and which scripts it contains.
Persistence: whether a team wants to keep and version its own copy.
Auto-triggering: whether the model should decide silently, on every task, whether the skill applies.

Only the third decision needs prompt residency. The proposal's answer is an open @skills protocol that makes the other two cheaper:

Delivery mode	What happens	Good fit
Reference	Load a skill by path at the moment of use; nothing is installed or left resident.	One-off work, exploration, long-tail skills
Saved	Keep a team-owned copy in the project tree, review it in Git, but do not put it in every prompt.	Runbooks, checklists, recurring workflows
Installed	Add a small auto-trigger entry for skills that must fire without the user remembering them.	Security guardrails, formatting rules, API checks

The proposed implementation uses a project directory such as .atskills/ for saved skills and a small .autotrigger file for the resident set. That is a product idea, not a benchmark result: the point is to make the lifecycle visible and controllable rather than to claim that a new file convention automatically improves agent quality. See the paper's full HTML specification for the exact resolution and save behavior.

Why PMs should care

1. Activation is becoming a product surface

Most skill roadmaps ask, "How do we help developers author and install more skills?" The more important question may be, "How does a user reach the right skill without paying for every other skill on every turn?"

The paper's fewer-than-100 figure is deliberately conservative and not a measured constant. Its stronger claim is about the mismatch in scale: tens of thousands of published skills are being routed through a tiny, probabilistic, always-on channel. The paper also reports that the median fetched skill body is 921 words, with a 90th percentile of 2,207 words—large enough to be wasteful when permanently resident, but small enough to fetch when needed. Those measurements come from one crawl and one working setup, so use them as architecture signals rather than operating limits.

This changes the product metrics. An install count tells you that someone paid the permanent context cost once. It does not tell you whether the skill was invoked, whether it helped, or whether it displaced a more useful instruction. A better dashboard would include:

explicit references and successful loads per skill;
auto-trigger precision and miss rate;
task success with and without the skill;
added context tokens, latency, and tool calls;
stale-copy, permission, and rollback events.

The paper calls this the difference between album sales and plays. For a skills marketplace or internal registry, usage should be measurable at the moment a skill is actually loaded.

2. Cross-agent portability is not just a file-format problem

Anthropic's open-standard announcement says Agent Skills are supported across Claude.ai, Claude Code, the Claude Agent SDK, and the Claude Developer Platform. In the ecosystem measured by the paper, however, the same SKILL.md format is spread across 54 project-level directories used by 75 coding agents, plus 58 user-level locations. The file can be portable while its installation path is not.

That is a familiar PM trap: a common artifact does not create a common distribution layer. If a team supports multiple coding agents, its real maintenance unit becomes "one skill multiplied by every agent's storage convention." A neutral path, explicit invocation, and project-owned copy can remove that tax even if vendors keep their existing directories for compatibility.

A social signal points in the same direction. On Aug. 13, Resend described Agent Plugins as an open standard that bundles an MCP server for tools with agent skills for instructions. That post is an ecosystem packaging signal, not proof of adoption. But it shows the market converging on a bundle whose value is the delivery of a capability—not merely the existence of a model or an API.

3. The trust model should rise with persistence

A skill is not harmless documentation if it contains executable code or instructions that an agent will follow. The paper explicitly notes that a referenced skill is remote behavior and can carry indirect prompt-injection risk. Anthropic likewise recommends auditing skills from less-trusted sources, including their dependencies and network instructions.

The three delivery modes create a useful trust ladder:

Reference: try an unfamiliar skill in a sandbox or restricted-permission session.
Saved: copy it into a reviewed project tree with an owner, revision, and change history.
Installed: allow only a small set of reviewed skills to influence automatic triggering.

This is a better governance primitive than one global "install" button. It lets a PM make the permission and review burden proportional to how much future behavior the skill can influence.

How to implement now

Do not begin by building a universal skill marketplace. Start with one repeated workflow where the team can observe both the benefit and the cost of procedural context.

Step 1: Map the current delivery tax

Export the skills your agent sees at startup. For each one, record its owner, description length, last use, trigger behavior, tools or scripts, permissions, and whether a user could name it explicitly. Sample representative tasks and measure when the skill fired, when it should have fired but did not, and when it fired unnecessarily.

The goal is not to hit an arbitrary skill count. It is to find which instructions are paying a permanent token and attention tax without delivering recurring value.

Step 2: Classify by activation need

Put every skill in one of three buckets:

Point-of-use: load explicitly when a task calls for it. This is the default for rare or exploratory procedures.
Team working set: keep a local, versioned copy that is easy to search and invoke. This is the right home for runbooks and checklists that must be available but not always active.
Implicit essentials: keep resident only when a miss is costly and the user should not have to remember the rule. Set a hard review threshold for this bucket; the paper recommends fewer than ten essentials as a design heuristic, not a validated production number.

Step 3: Add a safe activation interface

Whether you adopt @skills or build an internal equivalent, give users one obvious path: a command palette, @ reference, or search result that shows the skill's owner, source revision, required tools, permissions, and a short preview before loading it. Make the loaded skill visible in the transcript or run trace.

This solves the long-tail discovery problem without silently turning every catalog entry into system-prompt content.

Step 4: Promote with a holdout, not enthusiasm

Run the new delivery policy against a fixed development set and a separate holdout. Compare task quality, successful completion, p95 latency, context cost, unnecessary trigger rate, and security incidents against the current install-only baseline. Keep a rollback path for both the skill content and the trigger policy.

A skill that improves one benchmark while increasing silent activations or permission scope is not a product win. Promotion should require evidence that the procedure is easier to reach, cheaper to carry, and safer to maintain.

Limits: what not to overclaim

The paper is a timely design proposal, not an independent demonstration that @skills improves production reliability. Its central trigger-slot estimate is inferred from related attention and instruction-following literature; the authors explicitly call for future experiments that vary installed-skill count and measure trigger reliability directly. The ecosystem counts come from one July 2026 crawl, and the paper discloses that one author founded SylphAI, which develops the AdaL implementation and operates the related catalog and hub.

The YouTube signal is useful for accessibility, not validation: IBM Technology's 13-minute explainer, published Aug. 10, had about 33,000 views when checked and covers triggering, context usage, deterministic scripts, and security vetting. Its reach says the concept is becoming explainable to practitioners; it does not establish that the protocol works.

The near-term PM conclusion is narrower and more useful: skills are no longer only an authoring format. They are a distribution and governance layer. Treat resident context as a scarce budget, make the long tail explicit and searchable, version what the team owns, and reserve automatic triggering for the few behaviors that truly must happen without asking.