@SKILLS: The Missing Infrastructure for the Next 10x in Agent Automation

We build agents and shipped skill support, but we could not make skills stick inside our own team. This is why, and what we built instead to unlock the next 10x in productivity.

Our AGENTS.md is 1,109 lines and about 27,000 tokens. It contains 46 separate procedures, and every request starts with all of them in the agent's context.

Anthropic's own documentation tells you not to do this:

"CLAUDE.md is loaded every session, so only include things that apply broadly. For domain knowledge or workflows that are only relevant sometimes, use skills instead. Claude loads them on demand without bloating every conversation."

We read that. We did the opposite. So does nearly everyone I ask.

When a documented, widely known practice is almost universally ignored, the reason is rarely discipline. The recommended path costs more than the bad one.

In a LinkedIn poll I ran, 68% of technical respondents said they already use skills. But much of that use has collapsed into workarounds.

For external knowledge, people often pass the agent a link to a GitHub-hosted SKILL.md. For internal knowledge, teams put their procedures into one large AGENTS.md or CLAUDE.md. Both workarounds avoid the installed-skill lifecycle because creating, inspecting and managing installed skills remains opaque.

The move from MCP servers to skills radically simplified the artifact. Complex server infrastructure became readable instructions and supporting files. But delivery still has a missing last mile: how a skill reaches an agent, whether it stays, when it triggers and how a team manages it. That gap is now the bottleneck.

Skills are infrastructure for the next 10x

The next 10x in team productivity will come from agents that no longer need a person to prompt every step. Skills are the infrastructure that makes that possible.

A skill is procedural knowledge an agent can read: domain expertise, how to operate a provider's service, or how your team does a thing. It is the difference between an agent that finishes the job and one that stops to ask you.

The first time an agent does something new, it has to explore. Ask it to order the team lunch and it must learn the preferences, the usual order and the checkout flow. The same discovery happens when it learns how your team runs a migration, reviews a change or ships a release. That first run should be expensive. The second should not be. In our experience, writing down what the first run learned can make the next one cost close to a tenth as much.

Skills also let you borrow discoveries made by other people. I began this article from a blank file even though someone had already documented a strong method for structuring it. The knowledge existed, but my agent could not reach it.

A team's skills should become the accumulated record of every expensive first pass, whether the discovery came from your team or someone else. That is how automation compounds. As Addy Osmani puts it, "Without skills the loop re-derives your whole project from zero every cycle, with skills it kind of compounds."

Once we saw that, skill delivery became the biggest blocker to our team's next 10x.

Skills are files, but we manage them like software

The SKILL.md format is simple. Its delivery is not. To try a skill, users are expected to install it into an agent-specific directory, carry its description in the system prompt, remember where it came from and later remove it from every agent and machine.

So users route around installation. For external knowledge, they paste a file or GitHub link into the query. For internal knowledge, they put every procedure into one large AGENTS.md or CLAUDE.md. Both workarounds treat a skill as the file it already is. They are simpler because they avoid the installed-skill lifecycle.

Installation is the root problem because it bundles three different decisions: using a skill for this task, saving it for later and loading its index into the system prompt so it can trigger automatically. Most skills need only one or two of those things, but installation charges them for all three.

The result is an opaque pile and a hard attention ceiling. Claude Code limits its skill listing to 1% of the context window. When it overflows, it drops the least-used descriptions first, including skills the agent has not yet had a chance to discover.

Introducing @ skills:, a filesystem protocol with three tiers

We built the open @skills: protocol and atskills.one around the behavior users had already chosen: treat skills as files.

Reference. Use the existing @ convention to load a local or remote skill for one task. Nothing is saved and nothing becomes resident.

Saved. Save the skill into .atskills/, then mention its path with @ whenever a user or agent needs it. The team can inspect, adapt and version the file without making the agent remember it on every request.

Auto-triggered. Add a line to .autotrigger, using .gitignore-style configuration, only when the agent should load the skill index into its system prompt at session start.

@skills:gh:SylphAI-Inc/glowmotion          use.     read it now, keep nothing
@skills:gh:SylphAI-Inc/glowmotion:save     save.    adopt it into your repo
@skills:gh:SylphAI-Inc/glowmotion:install  trigger. add one configuration line

The three tiers formalize what users already do. A remote file link becomes a reference with no permanent footprint. A team workflow can live in the project and load only when someone mentions it. Only the few skills that must fire on their own become resident. Using does not imply saving, and saving does not imply auto-triggering.

The filesystem makes that separation visible. A path identifies one skill. A directory path returns an index of the skills beneath it, with each description and path available for the agent to open next. /skills shows the resident set, its sources and its token cost, so teams can finally see and manage what the agent remembers.

The same paths support reference, save and auto-trigger. The filesystem shows what the project owns, /skills manages residency, and the prompt view shows exactly what the model receives.

The protocol needs no manifest, marketplace.json. Publish a skill by pushing its folder to a repository.

Remote skills are still untrusted instructions, and they may include scripts. The protocol has no signatures or immutable pins today. Review consequential skills and save them into your own git history before relying on them.

Skills are already a service-integration channel. Among 54,929 analysed public skills, 15,542 connect to accounts across 1,774 external services. On-demand references keep those integrations available without forcing every provider a user has tried into every prompt.

First-class support for agents, one home for users

We want @ skills: to work across the agent ecosystem, so we released the protocol, code and atskills package at github.com/SylphAI-Inc/atskills.

For agent builders, the TypeScript atskills package implements the protocol directly. Wire it into your agent to add full first-class support for references, saved skills, auto-triggering and management

For users and teams, atskills.one is the shared management surface. You can find skills, submit your own, and curate a collection of trusted knowledge that remains available across projects and agents.

A paper on the protocol, joint work between AdaL and UT Austin, is coming soon.