Distributing Agent Skills: One Standard, Many Delivery Layers¶
For / Key Points
For: Engineers and IT teams that want to distribute internal knowledge and operating procedures as Skills across multiple AI agents.
Key Points:
- The Skill format is converging, but the delivery layer is not yet standardized
- The lowest-lock-in foundation is still Git plus a shared
.agents/skills/directory - Enterprises should separate "single-AI central control" from "cross-AI reuse"
Creating an internal Agent Skill is the easy part. The harder question is how to distribute it, update it, audit it, and disable it across a real organization.
This article answers one question: which delivery path should an organization standardize on for Agent Skills?
The Format Is Standardizing; Delivery Is Not¶
The first fact to get right is simple. The contents of a Skill are becoming standardized, but the path used to distribute that Skill is not.
A Skill is, at minimum, a directory that contains SKILL.md1. The format was developed by Anthropic and released as an open standard2. Vercel Labs' skills CLI lists support for OpenCode, Claude Code, Codex, Cursor, and many more agents3. In practical terms, the same folder can now be read by multiple AI tools.
The unresolved part is delivery. There is no single equivalent of pip install or apt install for all Agent Skills. That is different from MCP, which Anthropic donated to the Agentic AI Foundation under the Linux Foundation for neutral governance4.
The fragmentation becomes manageable if you sort it by vendor dependency. From lowest to highest dependency, the layers are Git, cross-platform CLIs, and AI-specific distribution systems.
Layer 1: Distribute With Git¶
The most robust approach is to keep Skill folders in a Git repository and have users or endpoint-management tooling clone them. No new registry or SaaS dependency is required.
The important detail is the shared location. Atlassian's TWG CLI documentation says it writes the canonical Skill bundle to ~/.agents/skills, a location used by Codex, Cursor, Gemini CLI, GitHub Copilot, and other agents5. This is similar to putting binaries in /usr/bin so multiple shells can execute them.
git clone git@gitlab.example.com:platform/agent-skills.git ~/.agents/skills/company-skills
The workflow is direct. Write the Skill. Put it in Git. Clone it onto the user's machine. The agent reads name and description at startup, then loads SKILL.md and related files only when the task matches. The Agent Skills spec describes this staged loading model as progressive disclosure1.
The strength of this layer is reuse of existing controls. GitHub, GitLab, and self-hosted Git can all provide authentication, permissions, reviews, and CI. This makes the model suitable for air-gapped environments or organizations with strict procurement constraints.
Layer 2: Add a Cross-Platform CLI¶
The second layer keeps Git as the source, then adds a one-command installer on top. The common example is Vercel Labs' skills CLI, which can install Skills through npx skills add6.
Its source formats are broad: GitHub shorthand, full URLs, GitLab URLs, arbitrary git URLs, and local paths6. Installing one Skill globally can look like this:
npx skills add https://gitlab.example.com/platform/agent-skills --skill approval-workflow -g
For enterprises, the main benefit is that the CLI absorbs cross-agent placement details. It supports agent targeting such as --agent claude-code or --agent codex, and -y for non-interactive CI-friendly installs6. It turns manual clone, copy, and symlink steps into a repeatable command.
The lock-file story should be treated carefully. The current implementation uses a global .skill-lock.json to track installed Skills, while restoring from project skills-lock.json is exposed through experimental_install7. That makes it useful for inventory and update tracking, but it should not be treated as mature as npm's package-lock.json.
There are three adoption caveats. First, npx pulls the CLI from the npm registry, so enterprise proxies and allowlists may apply. Second, --skill needs to match the Skill name. Third, this is an OSS project from Vercel Labs, so it deserves the same review process as any other enterprise dependency.
Layer 3: Use AI-Specific Delivery¶
If the company has standardized on one AI product, that product's native management layer is often the easiest path. The trade-off is that it stays inside that product.
Claude Code can package Skills inside plugins by adding a skills/ directory to the plugin root8. Users can add marketplaces and install plugins with /plugin install plugin-name@marketplace-name9. Claude Code also supports user, project, and local plugin scopes, which makes single-product distribution operationally convenient.
Claude Team and Enterprise add a stronger control plane: admins can provision Skills centrally across the organization10. That is useful when approved workflows need to be enabled by default for all users.
The cost is portability. /plugin commands and managed settings do not transfer directly to other AI agents. If future migration or multi-agent use matters, keep the authoritative Skill source in Git even when a product-specific layer handles delivery.
Summary: Separate Source of Truth From Delivery¶
These three layers are not a quality ranking. They place dependency in different parts of the system. Separate the source of truth from the delivery mechanism.
| Layer | Dependency | Best Fit | Main Caution |
|---|---|---|---|
| Git clone | Low | Company-owned source of truth, audit, air-gapped environments | Requires separate placement and update procedures |
npx skills | Medium | Multi-agent install automation and team-level standardization | Adds npm and CLI dependency review |
| AI-specific | High | Central management inside one AI product | Locked to that product's commands and admin model |
The security principle is the same across all layers. Skills can cause tools or code to run in the agent's environment, so they should come only from trusted sources11. For internal distribution, a practical default is to keep the source of truth in a company Git repository and use CLI or AI-specific delivery only as downstream packaging.
The pragmatic pattern is clear. Keep Layer 1 as the authoritative source. Add Layer 2 where teams need install convenience. Use Layer 3 only where a department needs strong central control over one AI product. Once the artifact is standardized, delivery becomes a conscious dependency decision.