The honest answer is: more portable than product-specific prompt settings, less portable than a plain Markdown file. Skills travel well when they stay close to the open directory format and avoid assumptions about one host. They travel poorly when they rely on a client-only invocation syntax, a hidden filesystem path, a proprietary plugin manifest, local binaries, or implicit permissions.
"instructions, resources, and optional scripts" OpenAI Codex skills documentation
What travels well
The most portable part of a skill is its human-readable procedure. A clear SKILL.md
with required frontmatter, concise instructions, and relative links to supporting files can be
understood by multiple agents and by humans reviewing the artifact. If scripts are self-contained
and references are ordinary files, the skill can often move with little change.
Skills also travel well when they are explicit about dependencies. "Run this Python script with Python 3.12 and no network access" is portable. "Use the internal deploy tool" is portable only inside environments that have that tool.
Where the ecosystem is now
| Client or ecosystem | Documented support | Portability note |
|---|---|---|
| Claude | Anthropic documents pre-built and custom Agent Skills across Claude products, with Claude Code using filesystem-based custom skills. | Custom skill handling differs by product: Claude Code directories, API upload paths, and claude.ai zip upload are not the same operational flow. |
| Codex | OpenAI documents skills for Codex CLI, IDE extension, and Codex app, with plugins as an installable distribution unit. | The skill format can be open, while packaging and dependency behavior may be Codex-specific. |
| VS Code / GitHub Copilot | VS Code documents Agent Skills as an open standard used by Copilot in VS Code, Copilot CLI, and Copilot cloud agent. | Project and personal locations are documented, but product settings still control discovery. |
| MCP development | MCP docs describe Agent Skills as portable instruction sets for guiding AI coding assistants through MCP server design and implementation. | Skills can guide MCP work; MCP itself remains a separate protocol for external capabilities. |
What does not travel cleanly
Portability breaks at runtime edges. A skill can include a script, but another client might not allow script execution, might run in a sandbox without the right interpreter, or might require user approval for every command. A skill can mention a tool, but another agent might call that tool by a different name or not have it installed at all. A skill can depend on an MCP server, but the host still has to configure and authorize that server.
Packaging also matters. A raw skill directory is easy to inspect. A plugin, extension, or managed upload can be easier to install, but it adds product-specific metadata and lifecycle decisions. That does not make it bad; it just means the distribution unit and the authoring format are not identical.
Security and permissions are part of portability
A portable skill should not assume unlimited execution. MCP's current specification emphasizes explicit consent, data privacy, tool safety, and user control for operations. Skill authors should carry the same mindset: avoid secrets in skills, document what scripts do, state whether network access is required, and make destructive actions opt-in.
A skill that can only work by silently reading private data or invoking hidden tools is not practically portable. It is an environment-specific automation wrapped in a Markdown file.
A convergence point: progressive discovery
Progressive disclosure in skills and progressive tool discovery in MCP hosts are cousins. Both respond to the same pressure: large agents cannot dump every procedure, reference, and tool schema into context up front. They need a catalog, a way to inspect details, and a way to execute only what the task requires.
Portability checklist
- Use the open directory shape:
SKILL.md, optionalscripts/,references/, andassets/. - Keep frontmatter valid and descriptions specific.
- Use relative paths from the skill root.
- Document runtime dependencies and network needs.
- Avoid product-only commands in the core workflow unless the skill is explicitly product-specific.
- Keep scripts non-interactive and safe to inspect.
- Separate authoring format from installation packaging.
- Test in each target client instead of assuming support.
The right claim is not "skills work everywhere." The right claim is that skills give agent ecosystems a shared, inspectable shape for reusable capability. That is already useful, and it is the basis for convergence.