Agent Plugins 1.0: Package Agent Skills Once for AI Tools

The Strategic Case for AI Vendor Independence

As enterprises integrate AI into software engineering workflows, engineering teams are evaluating multiple AI coding assistants, including Claude Code, GitHub Copilot, Cursor, and self-hosted alternatives based on open-weight models such as Devstral and Qwen3-Coder. This multi-vendor strategy reflects factors such as cost optimization, regulatory requirements, data sovereignty, and access to rapidly evolving model capabilities. Model capability leadership is particularly unstable — a model that is state of the art when a tooling decision is made may not be twelve months later.

The economics of AI tooling are also important at enterprise scale. For example, public reporting(opens in a new tab) indicates that Microsoft wound down most of its Claude Code licenses and transitioned developers toward GitHub Copilot CLI. The Microsoft case should be interpreted with some care, since Microsoft owns the replacement platform. It nonetheless illustrates the broader point: AI coding tool selection is rarely permanent.

Consequently, organizations have a strategic interest in treating AI tooling as a replaceable component of their engineering stack rather than a long-term dependency. From an enterprise architecture perspective, the ability to migrate workflows, knowledge assets, and automation capabilities across AI systems has become an important requirement. Portability is an architectural property, not an accidental benefit.

Agent Skills as Portable Enterprise Knowledge Assets

To make AI agents useful within the enterprise, engineering teams increasingly equip them with organization-specific capabilities. These capabilities can provide access to internal systems and data, encode domain-specific knowledge, and guide agents through established business processes.

Two complementary mechanisms have emerged as important building blocks for this purpose:

Model Context Protocol (MCP)(opens in a new tab) servers, which provide a standardized interface through which AI applications can access external tools, resources, and prompts.
Agent Skills(opens in a new tab), which package domain knowledge, procedural instructions, and supporting resources into reusable, filesystem-based modules that an AI agent can discover and load when required.

Both mechanisms are relevant to enterprise AI extensibility; however, for simplicity, this article uses Agent Skills as the primary case throughout the remainder of the article.

The Agent Skill Format

Agent Skills are designed around a portable, lightweight artifact format:

<skill-name>/
- SKILL.mdRequired: metadata and instructions
- …

The SKILL.md file is the only required component of an Agent Skill. It contains the skill’s metadata and instructions, while additional files and directories can be included when needed.

This Markdown-based format makes Agent Skills straightforward to version control and provides a lightweight representation that can be readily processed by LLMs. The format has gained adoption across major AI coding tools, including Claude Code, OpenAI Codex, GitHub Copilot, Cursor, and OpenCode.

However, portability at the artifact level does not automatically eliminate platform dependencies. Individual agent implementations may support different optional frontmatter fields, directory structures, or mechanisms for locating and loading skills. The Agent Skills specification provides a common foundation, but enterprise-grade portability still requires organizations to account for implementation-specific differences.

The Operational Challenge of Skill Distribution at Scale

Within an organization, Agent Skills evolve continuously. New capabilities are introduced, existing implementations are refined, and obsolete skills are replaced. Their lifecycle therefore resembles that of conventional software artifacts:

A developer creates or updates an Agent Skill.
The skill is committed to a version-controlled repository.
Developers who require the capability must obtain the appropriate version.
The artifact must be installed or made available through a location and discovery mechanism supported by the target AI tooling.

When skills are distributed through Git repositories without dedicated distribution tooling, their distribution and lifecycle management remain largely manual. Developers must discover available skills, identify new or updated versions, retrieve them from their repositories, and install them according to the requirements of their AI tooling.

For example, Claude Code supports user-level and project-level skill discovery, including locations such as ~/.claude/skills and .claude/skills within a project. Other AI coding tools may use different locations or discovery mechanisms. As the number of skills and supported AI tools increases, manual distribution can create significant operational overhead and result in stale, inconsistent, or incorrectly configured local skill versions. Without centralized distribution and governance mechanisms, the operational effort required to manage agent capabilities can grow faster than organizational AI adoption.

The Claude Plugin Ecosystem

To address the distribution and lifecycle-management challenges of Agent Skills, Anthropic introduced a plugin system(opens in a new tab) for Claude Code. A plugin provides a packaging and distribution mechanism that can bundle Agent Skills with other agent capabilities, including MCP server definitions, hooks, and custom agents.

A typical Claude plugin can be structured as follows:

<plugin-name>/
- .claude-plugin/
  - plugin.jsonPlugin manifest
- skills/
  - <skill-name>/
    - SKILL.mdEmbedded skill definition

The plugin.json manifest identifies the plugin and provides metadata used by the plugin-management system. Plugins can be distributed through Git-based marketplaces and installed through the corresponding mechanisms, providing capabilities for discovery, installation, and updates.

From a DevOps perspective, this introduces a scalable package-management model in which Agent Skills become versioned, distributable components with an associated lifecycle rather than isolated artifacts that developers must manually synchronize.

The Packaging–Portability Trade-off

However, plugin packaging introduces a structural distinction from the underlying Agent Skills format.

A standalone skill has a simple structure in which the skill directory itself contains the mandatory SKILL.md:

<skill-name>/
- SKILL.md

A Claude Code plugin, by contrast, introduces a vendor-specific packaging layer:

<plugin-name>/
- .claude-plugin/
  - plugin.json
- skills/
  - <skill-name>/
    - SKILL.md

The skill itself remains a portable artifact, but the surrounding package structure introduces platform-specific metadata and conventions. Consequently, a plugin repository cannot necessarily be treated as a standalone skill repository by an AI coding tool that expects to discover skills directly from a conventional skill directory.

Claude-format plugins have nevertheless been adopted by other AI development environments. For example, current versions of Visual Studio Code support Claude-format plugins(opens in a new tab) and can recognize .claude-plugin/plugin.json, allowing Claude-format plugin repositories to be used alongside VS Code’s own agent tooling.

Nevertheless, AI coding environments that do not recognize the Claude plugin format may require the underlying skills to be extracted or exposed through their own supported discovery mechanisms.

This raises a broader architectural question: how can organizations preserve Agent Skill portability across heterogeneous AI coding tools?

Approaches to Solving the Packaging–Portability Trade-off

When engineering teams seek to combine the managed distribution and lifecycle-management capabilities of the Claude Plugin ecosystem with the portability requirements of heterogeneous AI tooling, several approaches can be considered.

Dual Repositories

One conceptually simple approach is to maintain two repositories: one containing the plugin-packaged version of a capability and another containing the underlying, tool-agnostic Agent Skill.

This allows each repository to follow the conventions of its target ecosystem. However, it introduces two sources of truth. Changes to the underlying skill must be propagated across repositories, creating additional maintenance effort and increasing the risk of version drift or inconsistent releases.

It also introduces a discoverability and governance problem for developers. When multiple repositories contain related or apparently identical skills, developers may be uncertain about where to search for an existing skill, which repository represents the canonical source, and where a newly developed skill should be published. Over time, this ambiguity can lead to skills being created in the wrong repository or maintained inconsistently.

Symbolic Linking

A second approach is to maintain a single canonical skill and use symbolic links to expose it through the directory structure expected by a plugin or another AI tooling environment.

This avoids duplicating the actual skill content and can therefore provide a single source of truth. However, symbolic links introduce an additional dependency on the underlying filesystem. Their creation, permissions, resolution, and handling by version-control and development tools can vary across operating systems and environments.

Consequently, while symbolic linking can be an effective local development technique, it is generally a less attractive foundation for a cross-platform enterprise distribution strategy.

The Co-Location Pattern

A third approach is the Co-Location Pattern, which avoids maintaining separate repositories or filesystem links.

A single-skill package can be structured as follows:

<skill-name>/Canonical skill root
- SKILL.mdThe canonical Agent Skill
- .claude-plugin/
  - plugin.jsonClaude-specific identity and version metadata

This structure preserves the canonical Agent Skill at the root of the directory while adding the Claude-specific .claude-plugin/plugin.json manifest as an additional layer.

Claude Code supports this layout explicitly. Its plugin reference(opens in a new tab) states that “[a] plugin that has a SKILL.md at its root, no skills/ subdirectory, and no skills manifest field is automatically loaded as a single-skill plugin.” No configuration is required to opt in; the manifest does not need to declare "skills": ["./"].

The manifest is optional for loading: without one, Claude Code auto-discovers components in their default locations and derives the plugin name from the directory name. Its metadata becomes important for distribution and lifecycle management, particularly version information used for update detection. The Co-Location Pattern consequently allows organizations to preserve the Agent Skill as the canonical, portable artifact while adding Claude-specific packaging metadata only where lifecycle management requires it.

The pattern is not a universal replacement for Claude’s standard plugin structure. It suits single-skill packages specifically; teams who want to bundle several logically related skills into one plugin will still prefer the conventional skills/ layout.

Agent Plugins 1.0: A Vendor-Neutral Packaging Standard

Agent Plugins 1.0(opens in a new tab) is an open standard for packaging reusable agent capabilities, including Agent Skills and MCP servers, into a common plugin format. It was introduced by Amazon, Microsoft, OpenAI, and Vercel as a vendor-neutral specification and is designed to allow compatible AI agent clients to load the same plugin without requiring vendor-specific packaging.

An Agent Plugin is a self-contained directory with a root plugin.json manifest and standardized locations for its components. Skills and MCP configuration are optional, allowing the same package format to accommodate different combinations of agent capabilities.

A simplified structure is:

<plugin-name>/
- plugin.jsonPortable manifest, at the package root
- skills/
  - <skill-name>/
    - SKILL.md
- mcp.jsonMCP server configuration

The manifest defines a closed set of top-level fields — $schema, name, version, description, author, homepage, repository, license, keywords, and extensions. No others are permitted. This is what prevents the format from accreting vendor-specific metadata over successive releases.

This addresses an important limitation identified earlier in this article. Instead of maintaining a vendor-specific plugin representation alongside a portable Agent Skill, organizations can package the capability using a common, vendor-neutral format. The package itself becomes the portable distribution unit.

The commercial significance is more instructive than the format itself. Major vendors and AI development platforms chose to collaborate on a common package format(opens in a new tab) rather than maintain entirely separate formats. Agent Plugins 1.0 is already supported across multiple major AI development environments, including VS Code, GitHub Copilot, Cursor, ChatGPT, and Kiro. AWS, a founding member of the Technical Steering Committee, has made its Agent Toolkit compatible with the specification, with Kiro support rolling out. Google has also adopted the standard in its Data Agent Kit and announced support through its Agents CLI.

Agent Plugins 1.0 therefore represents an important evolution of the Agent Skills ecosystem: Agent Skills provide the capability format; Agent Plugins provide a standardized packaging boundary for distributing those capabilities across compatible AI agents. Rather than creating another abstraction layer, enterprises can build their internal distribution and governance processes on top of an emerging industry standard.

The standard is still new, and support will continue to evolve across AI coding environments. However, its emergence significantly reduces the architectural justification for maintaining vendor-specific packaging strategies and provides a common foundation for portable agent capabilities.

Conclusion – Keeping Enterprise Knowledge Portable

Enterprises need the ability to adopt new models and tools without repeatedly rebuilding the knowledge, processes, and automation capabilities accumulated around their AI engineering workflows.

Agent Skills provide a proven foundation for this portability because they encapsulate reusable organizational knowledge in a lightweight, filesystem-based format. However, artifact portability alone does not solve the operational problem. Skills still need to be discovered, versioned, distributed, installed, and maintained across heterogeneous AI coding environments.

Agent Plugins 1.0 changes this materially. The packaging–portability trade-off examined in this article is largely resolved: organizations can rely on a common, vendor-neutral packaging boundary instead of maintaining a tool-specific packaging strategy for each environment they support. A capability is authored once and consumed across compatible AI coding tools without transformation.

The standard’s boundaries matter as much as its contents. Agent Plugins 1.0 standardizes packaging; it does not standardize distribution, installation, marketplaces, registries, or lifecycle management, and its first version focuses on Agent Skills and MCP servers. Those concerns remain with the client implementations and with the organizations adopting it.

The practical consequence is a change of scope rather than an elimination of work. Enterprises can now align on one packaging standard and direct their remaining effort at catalog management, governance, version currency, and controlled distribution — a single organizational problem in place of one packaging problem per supported tool. That is the separation worth defending: the tool through which knowledge is consumed remains replaceable, while the knowledge itself stays an organizational asset.