The protocol
@skills: the missing infrastructure for agent automation
An open and simple agent skills protocol, built for the future of knowledge sharing.
By Li Yin, Cofounder and CEO, AdaL · @panda_liyin
@skills in 45 seconds
Our own AGENTS.md was 1,109 lines and about 27,000 tokens when we wrote this. It held 46 separate procedures, and every request started with all of them in the agent's context. It has passed 1,175 lines since, which is the point. Anthropic's documentation tells you not to do this. We read that, and we did the opposite. So does nearly everyone we 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.
The move from MCP servers to skills simplified the artifact: server infrastructure became readable instructions and supporting files. Delivery did not follow. How a skill reaches an agent, whether it stays, when it triggers, and how a team manages it is still the missing last mile.
Installation bundles three decisions
To try a skill, you 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.
That single act decides three separate things: use this skill for this task, keep it, and load its index into the system prompt so it fires on its own. Most skills need one of the three. Installation charges them for all three.
So people route around it. For external knowledge they paste a GitHub link into the query. For internal knowledge they put every procedure into one large AGENTS.md. Both workarounds treat a skill as the file it already is.
Installation bundles use, ownership, and triggering. Each skill should pay only for the lifecycle it needs.
Three tiers, one filesystem
Using a skill does not imply saving it. Saving does not imply auto-triggering.
@skills:gh:SylphAI-Inc/skills/skills/glowmotion
Load a local or remote skill for one task, using the @ convention the agent already has. It leaves no permanent footprint.
@skills:gh:SylphAI-Inc/skills/skills/glowmotion:save
Copy the skill into .atskills/ and mention its path when someone needs it. The team can read, adapt, and version the file without the agent carrying it in every prompt.
@skills:gh:SylphAI-Inc/skills/skills/glowmotion:install
Add a .gitignore-style line to .autotrigger. Only now does the skill index enter the system prompt at session start.
Reference and saved skills load only when named. Auto-triggered skills alone occupy the prompt before a task begins.
Why the filesystem
A path identifies one skill. A directory path returns an index of the skills beneath it, each with its description and path, so the agent can open the right one next. /skills shows the resident set, its sources, and its token cost. Teams can finally see what the agent remembers.
The protocol needs no manifest, no lockfile, and no registry. Publish a skill by pushing its folder to a repository.
Remote skills are untrusted instructions and may include scripts. The protocol has no signatures or immutable pins today. Read consequential skills, and save them into your own git history before you rely on them.
The same paths support reference, save, and auto-trigger. The filesystem shows what the project owns, and the prompt view shows exactly what the model receives.
The numbers behind this
- 1,109 lines
- our own AGENTS.md when this was written — about 27,000 tokens across 46 procedures, and still growing
- 68%
- of technical respondents in a LinkedIn poll said they already use skills
- 1%
- of the context window is Claude Code's budget for listing skills
- 15,542
- public skills connect to accounts across 1,774 external services
Install less, use more
The protocol, the code, and the atskills package are MIT licensed. The hub is optional: local and gh: paths resolve directly, so nothing here depends on our service.