For agent builders
Integration is one file.
@skills is a delivery layer, not a fork of the format — the unit of content is the unmodified SKILL.md directory, and the protocol adds zero fields to it. A resolved skill is just files on disk, so agents that load skills their own way keep working untouched.
Two ways in. Pick the one that fits your architecture.
One file, or one CLI
The protocol asks nothing of you or your vendor — no SDK, no registry client, no plugin. Drop SKILLS.md into any repository and an agent that can read files, run shell commands, and fetch URLs is already a full client.
- States the resolution rule, cache discipline, and .autotrigger semantics
- Covers the save procedure and the safety rules — in about a page
- Prefer to shell out? The reference CLI gives the same behaviour
Native @ integration
Reuse the @ context system you already ship. The client computes the resident prompt block; your serving layer receives it as one string and splices it into the system prompt verbatim.
- The host needs no protocol logic at all
- One codebase per client owns parsing, resolution, cache, and saves
- What the user sees resolved can never disagree with what the model gets
The whole protocol is a filesystem.
No manifest, no lockfile, no database, and no state that isn't visible in an editor and reviewable in a pull request. That is the entire surface you would be implementing:
@skills:<path>a reference command — reading it is using it.atskills/the project's own folder, git-tracked.autotriggerone .gitignore-style line per resident skill.sourcetwo lines of provenance on a saved copy/skillsthe management surface every client should shipOr shell out to the CLI.
Four verbs, and your agent inherits resolution, the validating cache, saves, and trigger semantics without implementing any of it.
Everything ships as one installable package holding the normative specification, a TypeScript core, the reference CLI, the agent instruction file, and a runnable demo.
Your serving layer never learns the protocol.
In AdaL's implementation the frontend client owns everything — parsing .autotrigger, resolution, the validating cache, saves, and construction of the resident prompt block — and the model-serving backend receives that block as one string it splices in verbatim. So the implementation lives in exactly one codebase per client, and any agent architecture with a prompt-assembly step can adopt it this way, whatever language its serving layer is written in.