Agent Skills Share a Format but Not a Distribution Model

Major AI coding tools now support a shared format for reusable instructions, scripts, and reference material, but they still use different systems for locating and distributing those skills. The Agent Skills specification defines a directory built around SKILL.md and optional supporting files. Codex, Claude Code, GitHub Copilot, and Gemini CLI then apply their own discovery locations, installation methods, and precedence rules.

The distinction matters because a portable file format does not determine where a software package keeps its authoritative copy or how installed projects receive updates. The specification does not mandate where skill directories must live, while its client implementation guide recommends that clients consider both a native location and .agents/skills for cross-client interoperability. Distribution tooling must therefore deal separately with installation, synchronisation, precedence, duplicate names, and trust.

OpenAI's Codex documentation says Codex scans .agents/skills from the current working directory towards the repository root, as well as user, administrator, and system locations. Same-name skills are not merged and can both appear in selectors. OpenAI recommends plugins when authors want to distribute reusable skills beyond repository-scoped or local use.

Claude Code uses .claude/skills for project and personal skills and can distribute additional capabilities through plugins. Project skills are discovered from the starting directory towards the repository root, while plugin skills form another distribution channel. Both Codex and Claude Code follow the Agent Skills format, but their native repository locations and sharing mechanisms remain different.

GitHub Copilot accepts repository skills from .github/skills, .claude/skills, or .agents/skills, according to its Agent Skills documentation. GitHub also provides gh skill for discovering and installing skills from repositories. Google's Gemini CLI recognises .gemini/skills and .agents/skills at user and workspace levels, with workspace skills taking precedence over user, extension, and built-in sources.

Framework ecosystems add another layer between package-owned sources and the locations coding agents scan. Laravel Boost stores application-owned skills under .ai/skills, while third-party packages can supply them through resources/boost/skills. Its installation process selects skills according to detected Composer packages, and an application-owned skill with the same name can override a Boost-provided skill.

The Drupal AI Best Practices proposal separates the same concerns for Drupal modules, themes, projects, and Composer packages. It proposes .ai/skills for skills owned by ordinary Drupal packages, retains skills for repositories that primarily act as generic skill libraries, and proposes configurable .agents/skills output for consuming projects. The issue remains unresolved on the recommended package source directory: Angie Byron questioned whether skills should be used consistently instead, while Ronald te Brake said he saw value in that simpler convention.

Implementation work has progressed independently of that naming decision. The AI Best Practices project currently keeps its own Agent Skills in a top-level skills directory and provides composer drupal-ai skills-sync to synchronise discovered skills into a configured output directory. The current resolver is Drupal- and Composer-aware, with project structure, installed packages, filtering, precedence, and aggregation handled before the resulting skills are written to the agent-facing directory.

That implementation has produced a second architectural question. A newer AI Best Practices discussion asks whether Drupal should continue maintaining its own resolver and synchroniser or rely more heavily on skills.sh, a broader installation and distribution tool. The discussion distinguishes the current Drupal tooling, which derives skills from a project's Composer dependencies and Drupal structure, from a general-purpose installer that obtains skills from external repositories and distributes them to supported agents.

Collision policies also remain client-specific. Codex can expose multiple skills with the same name, Gemini CLI selects the copy from the higher-precedence source, and Laravel Boost allows an application-owned skill to replace a built-in one. The Drupal proposal calls for predictable handling and warnings rather than silent overwrites. The Agent Skills specification requires a skill's declared name to match its parent directory, but it does not provide a global package namespace that resolves identical names from unrelated sources.

Distribution also changes the trust boundary because Agent Skills can contain executable scripts and instructions that access local resources. The Agent Skills implementation guide recommends considering trust checks before loading project-level skills from untrusted repositories. Gemini CLI separately requires confirmation when installing from a remote source and asks for permission when a skill is activated and gains access to its resources.

The emerging model is therefore a common content format surrounded by several distribution systems. The shared SKILL.md structure makes skills portable at the file level, while clients and frameworks still decide how those files are discovered, installed, updated, prioritised, and trusted. Drupal already has a Composer-aware implementation for that distribution layer, but its maintainers are still deciding whether Drupal-specific orchestration should remain part of the project or rely more heavily on tooling from the wider Agent Skills ecosystem.