The procedure
The markdown body is the skill: the steps, the checks, the shape of the output, the things not to do. None of it references the host, and it is the part you would least want to write twice.
Explainer
The short answer is partly, and the part that travels is the part that took longest to write. A skill that is a folder - a SKILL.md holding a name, a description and the procedure, plus whatever scripts and templates it needs - can be copied to any agent that reads that shape. What stays behind is everything the procedure assumes about its host: the names of the tools it calls, the credentials behind those tools, and the helpers only one platform provides. This page says where that line falls, what a move costs, and why we chose folders over a builder - a bet we made, not a standard we are announcing.
A skill is the most expensive thing you write for an agent. Not because the words are hard, but because the words are the residue of a procedure you ran badly several times before you ran it well. When that knowledge sits inside a vendor's builder as a graph of nodes, it is worth exactly as much as your contract. When it sits in a folder you can open, it is worth what it says. But portability is a line through the middle of a skill, not a property it has or lacks, and where the line falls is fixed by what the procedure assumes about the machine that runs it.
The shape is a folder named after the skill with a SKILL.md inside it: a short YAML header carrying at least a name and a description, then the instructions in plain markdown, with optional scripts/, references/ and assets/ directories alongside. That is the Agent Skills format, which its public repository describes as originally developed by Anthropic, released as an open standard and adopted by a growing number of agent products. Olano's skills are that shape, scripts and assets included.
One rule matters more than the label: the name matches the folder, which is what makes a copied folder addressable by name on arrival. Olano checks it on every start and tells you which folders disagree. A skill that breaks the rule still loads, because losing a working procedure over a naming rule would be the wrong trade; the fix is to rename the folder to the name, since the name is what the agent refers to.
The parts of a skill that mean the same thing on any host that reads the folder.
The markdown body is the skill: the steps, the checks, the shape of the output, the things not to do. None of it references the host, and it is the part you would least want to write twice.
The header is what an agent reads to decide whether the skill applies, and it travels as written - a reason to describe situations rather than summarise the file.
A script that needs only the interpreter runs wherever the interpreter is. Olano's own chart skill is built that way - a dependency-free script and a vendored charting library - so forking the folder changes every chart the agents make.
Themes, recipes, reference documents, example files. They are read by the procedure, not by the platform, so they arrive intact and mean what they meant.
Everything the procedure assumes about the machine underneath it.
A step that says "render this with the built-in browser" names a tool that exists on one host under one name. Olano's chart skill declares that dependency in its header. On arrival somewhere else, the sentence is still there and the tool is not.
A skill that calls a CRM never carries the key to it, and should not - a folder with a secret in it leaks the moment it is copied. In Olano, credentials live in an encrypted vault, resolved per agent, so a moved skill arrives needing the same grants made again.
Anything the procedure leans on that the platform provides: a rendering engine, a sandbox with LibreOffice and OCR in it, workspace files such as MEMORY.md, a scheduler reading HEARTBEAT.md. The skill can name them; it cannot bring them.
Olano hides a skill from any agent that lacks the tools it declares, so agents are never shown procedures they cannot run. That behaviour belongs to the host, not the folder; a host that does not read the declaration ignores it.
The cost of a move is proportional to the number of tool calls in the procedure, not to its length. A twenty-step skill that only reads and writes files moves in the time it takes to copy a folder. A five-step skill that calls a calendar, a CRM and a renderer needs three matches found and three grants made, and one of the three may have no equivalent.
The matching means reading every sentence in SKILL.md that names an action rather than describes one. Where the new host has an equivalent tool, change the name; where it does not, the step is dropped or a tool has to be added. Tools reached over MCP are the easier case, provided the new host connects to MCP servers too: the server is an external service that publishes tools, not part of either platform, so it can be connected again on arrival. Olano connects to any MCP server over stdio or HTTP, with sign-in tokens stored and renewed, and can expose an agent as one in turn.
Then run it once and watch. A skill that names a tool the agent does not have fails at that step, mid-task, in front of whoever asked. Olano's answer is the gate above. A skill that arrives without a declaration gets no protection anywhere, which is a good argument for writing one before you move.
Every skill an Olano agent has is a folder you can read: the Skills tab renders the SKILL.md the agent actually follows and lists everything bundled beside it, and the Files tab is where it is edited and downloaded. Skills reach an agent three ways - bundled with the platform, synced from the Olano skills catalog, or authored in the agent's own workspace - and all three land as the same shape. Any agent can write one; Cortex's Learned Skills phase drafts them from repeated work on its own, and a person can ask an agent in chat to turn a procedure into one. Every change Cortex makes is logged, and its tidy-ups of the skill library are snapshotted with one-click undo.
None of that makes the format settled, and we are not going to call it a standard. It is the shape we chose because it is the one where the expensive part - the procedure - is a text file, and a text file is the only kind of skill you can take with you when you leave. If a better shape wins, a folder of markdown is also the easiest thing to convert.
Partly, and the split is predictable. The written procedure, its name and description, its scripts and its templates travel as a folder. The names of the tools it calls, the credentials behind them and any helper the old platform provided do not, and each of those has to be matched or granted again on the new host. The effort scales with the number of tool calls, not the length of the skill.
There is a published shape: a folder named after the skill, containing a SKILL.md with a YAML header of at least a name and a description followed by markdown instructions, with optional scripts, references and assets directories. The Agent Skills repository describes it as an open standard originally developed by Anthropic and adopted by a growing number of agent products. Olano uses that shape, but adoption is still moving and nobody should call the question settled.
The first tool call. A step that names a tool the new host does not have fails at that step, mid-task. Olano avoids the failure by hiding any skill that declares tools the agent lacks, so the agent is never shown a procedure it cannot run. A skill that arrives with no such declaration gets no protection anywhere, so write one before you move.
No, and they should not: a folder with a secret in it leaks the moment it is copied. In Olano, credentials live in an encrypted vault and are resolved per agent, so a moved skill lands needing the same authorisations made again on the new deployment. Treat re-granting as part of the move rather than a surprise after it.
Yes. Every skill is a plain folder inside your own deployment. The Skills tab renders the SKILL.md the agent actually follows and lists the files bundled with it, and the Files tab lets you read and download them. There is no export format, because there is no proprietary format to export from.
A skill the agent wrote for itself is a folder in the same shape, in the agent's own workspace, and it moves the same way. What does not move with it is the context it was written from - the agent's memory and the conversations that produced it - which is a separate set of files with its own answer.
Where to go next.
The authoring side: what goes in the folder, and how to fork the bundled chart skill.
The wider exit question - what you would actually rebuild if a vendor disappeared.
The tool half of portability, and what a platform should do to keep those connections alive.
Where a learned skill comes from, and how the library is kept from degrading.
Checked 14 September 2026. The description of the Agent Skills format is taken from its public repository on that date; which products read the format is changing quickly, and we have not tested any of them. If we have described something wrongly, write to support@olano.ai and we will correct this page.
Send us one SKILL.md you built somewhere else. We will read it and say which lines move as they are, which tool names need a match here, and whether the honest answer is a copy or a rewrite.