A skill is a folder with one required file in it. That is the whole Agent Skills standard, stripped to the studs. The folder holds a SKILL.md, which carries a little YAML at the top with a name and a description, and below that you write plain Markdown telling an agent how to do a thing. Everything else (scripts, reference docs, templates) is optional.
The reason that matters in June 2026 is that the same folder now runs in more than one vendor's agent. The Agent Skills standard is an open format, originally built at Anthropic and released publicly, and a folder you author once can be picked up by any agent that implements the spec, with no rewrite and no per-tool config dialect to maintain. Portability is the whole reason it exists.
What the agent skills standard defines
The canonical spec lives at agentskills.io/specification. Read it directly; it is short, which is a good sign for a standard. It defines three things: a directory layout, a file format, and a loading model.
The directory layout is loose on purpose. A skill is any directory containing a SKILL.md. Alongside it you can drop a scripts/ folder for executable code, a references/ folder for docs the agent reads on demand, and an assets/ folder for templates and data. None of those are required.
The file format is where the rules tighten. SKILL.md must open with YAML frontmatter, and that frontmatter must carry two fields:
name: 1 to 64 characters, lowercase letters, numbers, and hyphens only, no leading or trailing hyphen, no consecutive hyphens, and it has to match the parent directory name.description: 1 to 1024 characters, non-empty, describing both what the skill does and when an agent should reach for it.
Those two are the hard contract. Everything else in the frontmatter is optional: license, a compatibility string for environment hints, a free-form metadata map, and an experimental allowed-tools field that pre-approves specific tool calls. The body below is unrestricted Markdown, recommended under 500 lines with the long tail in references/. If you have ever fought a plugin manifest with forty required keys, the restraint reads as deliberate.
Progressive disclosure is the load-bearing idea
The third thing the standard defines is how an agent reads a skill, and most write-ups skip it.
Agents do not load every skill in full at startup. They load skills in three stages. At startup the agent reads only the name and description of each skill, roughly a hundred tokens apiece, which is enough to know the skill exists and when it might be relevant. When a task matches a description, the agent pulls the full SKILL.md body into context. Only then, if the instructions call for it, does the agent load a referenced file or run a bundled script.
That staging is why an agent can carry fifty skills without drowning in context, because a skill sitting idle costs you a sentence and not a chapter. The spec even suggests a budget: keep the body under 5000 tokens, and push anything heavier into files loaded only when needed.
This is also why the description field is the most important line you will write. It is what the agent reads to decide whether to wake the skill up at all. A vague one ("helps with PDFs") gets ignored; one that names the trigger conditions gets matched.
Open, and honestly multi-vendor
The Agent Skills format did not emerge from a neutral committee. Anthropic built it, shipped it inside Claude first, and then published it as an open standard for cross-platform portability. So calling it "open" is accurate even though the origin is plainly Anthropic. Both of those things hold at the same time, and the format is more interesting for it.
What makes it a standard rather than a product feature is the second half: other agent products implement it. Anthropic's own surfaces (the Claude apps, Claude Code, and the API) use the identical format, so a skill built once works across all three. Beyond Anthropic, community catalogs and several agent vendors report SKILL.md support landing in tools like OpenAI's Codex, Cursor, Gemini CLI, and GitHub Copilot. The exact roster shifts month to month, and the spec site points you at a live client list rather than freezing one. Check that page or the agent's own docs before you assume support.
The governance sits in the open. The spec and its reference tooling are maintained on GitHub at github.com/agentskills/agentskills, the code under Apache 2.0 and the docs under CC-BY-4.0, with contributions open to the wider community. That repo ships a skills-ref validate command for checking your frontmatter before you publish.
Why an open format is worth caring about
Lock-in usually shows up at the integration layer, and skills are an integration layer. If every agent invented its own folder shape and its own metadata keys, you would maintain four versions of the same playbook and rewrite all four every time you switched tools. An open SKILL.md format kills that tax, because you author the procedure once and it travels with you.
There is a second payoff: a skill is auditable in a way a black-box plugin is not. The whole thing is text in a version-controlled folder. You can diff it, review it in a pull request, and read exactly what the agent will be told to do. For a team deciding whether to trust a skill, reading it beats hoping.
Where Knack fits
Authoring a correct SKILL.md by hand is not hard, but it is fiddly. The name rules, the description that has to actually trigger matching, the call about body versus reference file. Knack runs a short interview and outputs a skill in this exact open standard.
The result is a plain Agent Skill that runs in any compatible agent, with no proprietary wrapper.
For the grounding first, start with what a Claude skill is. To see which agents read your file, the SKILL.md compatibility matrix tracks support tool by tool.
Then go read the spec. Ten minutes, and you will know the format better than most people shipping skills.