Team and Enterprise Distribution

Three Paths to Team Distribution

Getting a skill from your machine to your team's workflow happens through three mechanisms in Claude Code and one additional pattern in Hermes. The right choice depends on whether skills should be organization-wide, project-scoped, or user-optional — and whether your team uses Claude Code, Hermes, or both.

Claude Code: Managed Settings for Enterprise Deployment

Enterprise deployments configure a managed settings directory that applies to every Claude Code installation in the organization. Skills placed in this directory's .claude/skills/ subfolder load for all users automatically, at the highest priority in the resolution order — enterprise settings override personal and project settings when names conflict.

The full resolution priority: Enterprise (managed settings) > Personal (~/.claude/skills/) > Project (.claude/skills/) > Bundled. Enterprise skills are the right path for organization-wide standards: a coding conventions skill, a deployment checklist, or a security review procedure every developer should run.

Claude Code: Project Skills for Team Sharing

The simplest team distribution path is committing skills to the repository. Any skill placed in .claude/skills/ at the project root is available to every developer who clones the repo — no installation step, no managed settings, no environment variables required.

Project skills version-control alongside the code they document. When the deployment procedure changes, the deploy skill changes in the same commit. When a new developer joins and clones, they get current skills immediately. This alignment prevents the drift that makes personal skills go stale: the skill and the thing it describes evolve together under the same review process.

For most teams, project skills are the recommended first choice. They require no enterprise IT setup, work with any Claude Code version, and git history on the .claude/skills/ directory is a free audit trail of every skill change.

Claude Code: skillOverrides for Visibility Control

The skillOverrides setting controls skill visibility without touching SKILL.md files. Use it to roll out a new skill gradually, retire a legacy one, or prevent Claude from auto-invoking a skill while keeping it user-accessible.

{
  "skillOverrides": {
    "legacy-deploy": "off",
    "new-deploy": "on",
    "internal-docs": "user-invocable-only"
  }
}

Place skillOverrides in settings.json (committed to the repo) for team-wide effect, or in settings.local.json (gitignored) for personal overrides that don't affect teammates.

The Cloud Sync Gotcha

Personal skills in ~/.claude/skills/ silently do not load in Cowork sessions or Claude Code cloud sessions. A developer who built a personal skill library will find it absent the moment they open a Cowork tab or run a scheduled routine. Three options address this:

1. Enable sync with the environment flag. Set CLAUDE_CODE_SYNC_SKILLS=1 before starting a terminal session (requires Claude Code v2.1.273+ and a /login session, not API key). This downloads account-enabled skills into ~/.claude/skills/synced/ before the first prompt. Never name a skills directory synced — that name is reserved for this mechanism.
2. Commit to .claude/skills/. Project skills load in all session types including cloud and Cowork. This is the natural home for any skill the team shares.
3. Ship in a plugin. Plugins declared in .claude/settings.json install their bundled skills across all session types.

Synced skills carry one important limitation — several dynamic features are disabled in cloud and Cowork contexts:

Design any skill intended for cloud sessions to degrade gracefully when these features are unavailable — or route it through project skills instead.

Hermes: external_dirs and Profiles

Hermes provides direct team sharing through external_dirs in config.yaml. Point Hermes at any directory and its skills become available without copying files into the primary ~/.hermes/skills/ tree:

# config.yaml
skills:
  external_dirs:
    - /mnt/team-skills
    - /opt/org-skills

Team members mount the shared directory (via network share, NFS, or a symlink to a locally cloned repo). Updates pulled to the shared directory are visible on the next session — no re-install needed.

One precedence rule to know: local skills shadow external ones by name. If a developer places their own version of a skill in ~/.hermes/skills/, it takes priority over the identically named skill in external_dirs. This prevents accidental overwrites but can create "works on my machine" discrepancies. Team naming conventions prevent most collisions.

Hermes profiles allow different skill subsets per context. A backend profile exposes backend-specific team skills; a frontend profile exposes frontend skills. Profiles prevent list pollution — developers see only the skills relevant to their current context rather than the entire team library.

Naming Governance

Establish naming conventions before distributing skills. The team- prefix keeps team-distributed skills visually distinct from personal and community skills in any listing:

• team-deploy-prod — not deploy, which collides with personal or community skills
• team-review-pr — not review-pr, which may already exist in community registries
• team-setup-env — not setup, which is too generic to distinguish

Document conventions in the team skills README before the first skill ships. Governance before distribution is easier than renaming after — rename collisions in skillOverrides can mask bugs for weeks if the wrong skill silently runs in place of the intended one.