Agent Skills Can Travel Between Tools. Your Permissions Still Cannot

A team has finally written down the deployment checklist that its most experienced engineer keeps in their head. Now it wants the same procedure available to an assistant in the terminal, a code editor and a hosted agent. The promise of a portable “skill” is that the procedure can travel. The operational question is what must stay behind.

GitHub’s November 12 guide to agent skills makes a practical distinction: a skill can capture reusable knowledge in reviewable files, while tools, project context and permissions belong to the host that loads it. That is the useful boundary. Portability can reduce repeated instruction writing, but it does not make two agents equivalent or transfer authority from one environment to another. [^[1] ]

A folder is a better handoff than a magic prompt

The open Agent Skills format packages a skill as a directory centered on SKILL.md, with frontmatter such as a name and description and instructions in Markdown. A package can also include references, scripts and other assets. An agent can use the description to decide when the procedure is relevant, then load the instructions and supporting files as needed. [^[2] ]

That structure changes the maintenance problem. Instead of pasting a long prompt into every tool, a team can review the procedure as source: who it is for, what it assumes, which steps are mandatory, and where the supporting material lives. A documented skill can be versioned, reviewed and tested like other operational code. It can also be wrong, stale or too broad. A portable mistake is still a mistake, only easier to distribute.

The format’s public stewardship is also evolving. The Linux Foundation’s Agentic AI Foundation announced Agent Skills among projects contributed to the foundation, alongside Open Responses, OpenEnv and OpenSandbox. That signals an effort to create shared infrastructure around agent systems; it does not guarantee that every host supports every feature or interprets every instruction identically. [^[3] ]

Separate the procedure from the authority

A skill may say, “inspect the deployment diff, run the checks, then publish.” The host determines whether the agent can read the repository, invoke the shell, access network services or trigger a release. Those permissions are not magically embedded in the text file. Nor does the skill bring a user’s private project context along to another system.

This separation is a safety feature if teams preserve it. Put stable procedural knowledge in the skill. Keep credentials, account-specific settings and authorization decisions in the host’s normal controls. Make the skill state its prerequisites and stop conditions. If an action can affect production, money or user data, the skill should explain what evidence is required and when a human must approve the action; the host should enforce the relevant permission boundary.

The same discipline applies to scripts. A script bundled with a skill may be more reliable than asking a model to reconstruct a routine operation, but it is executable software. Review its inputs and side effects, pin or verify dependencies, and test it in a limited environment. Do not grant a skill network or filesystem access simply because its README says it needs them.

Portability is not compatibility

A shared instruction set can encounter different tool names, APIs, file layouts and model behavior. One host may provide a read-only browser, another a shell with write access, and a third may not support a referenced feature. The skill should describe capabilities rather than assume a particular product interface wherever possible, and it should identify optional host-specific adapters clearly.

For each supported host, test the same small set of representative tasks: a successful path, a missing prerequisite, a malformed input and an action that should be refused. Compare whether the agent reaches the same intended result and respects the same safety boundaries. A passing result on one assistant is not evidence for another.

A recent study of 138,133 public SKILL.md files across 20,556 repositories examines how real-world skills conform to the specification and common quality practices. The scale itself is a reminder that an open file format does not automatically produce reusable, well-maintained content. The study is a research snapshot, not a live census of all skills or proof that every listed issue affects a given package. [^[4] ]

A review checklist for teams

Before sharing a skill, give it one narrow job and a name that says what it does. Explain the expected inputs, outputs and prerequisites in its description. Keep the core instructions short enough to follow, link supporting references from the skill folder, and state which steps are examples versus requirements. Put a maintainer and review date on the package so owners can retire stale guidance.

Then test it in a clean repository or disposable project. Check that it fails safely when a referenced tool, file or permission is absent. Inspect scripts and dependencies. Confirm that it does not rely on hidden memory, undocumented environment variables or a particular user’s account. Finally, test it under each agent host you intend to support and document the versions you checked.

The best outcome is not one universal agent that behaves identically everywhere. It is a procedure that humans can inspect, hosts can adapt and teams can validate against their own permissions. Skills can make operational knowledge easier to share; keeping authority local is what makes that sharing manageable. For a related look at controlling computer-use permissions, see our guide to sandboxing GUI agents and operating always-on agents.