How to share and manage Claude skills for your team with GitHub

Google ships more than 170 agent skills from one GitHub repo. No change merges without a version bump, a fresh eval report, and sign-off from the skill's owner.

That level of process exists because shared skills drift. Getting a skill onto someone else's machine takes a few clicks. Six months later, five people are maintaining five slightly different versions of the same workflow, nobody knows which one is current, and the person who wrote the original moved teams.

Org-wide skill deployment in Claude shipped in December 2025, and most teams have been building skills for longer than they've had a way to govern them. You might be fine using Claude’s skill sharing and plugin features, or it might be time to move your company skills to GitHub.

When to share Claude skills directly instead of through GitHub 

For one recurring workflow and one team, a repo is more process than the problem needs. Claude has two lighter options.

• Share with colleagues. On Team and Enterprise plans you can share a skill with colleagues or groups. Recipients get it view-only and turned off until they enable it. When you update the skill, they get the new version at next use, and access is removed automatically when someone leaves the organization.

• Publish to the organization library. Anyone can submit a skill to the org library when the publishing policy allows it. Owners set that policy to Requires review, Open, or Off. With review on, every later version goes through the same review, and you can't approve your own submission. The Inventory tab keeps version history.

Two limits push teams toward GitHub eventually. Only owners can add or remove organization-wide skills, which turns one person into the bottleneck for every change. And there's no version pinning – once a new version is approved, everyone gets it automatically. A synced plugin updates everyone on merge too, but a repo adds pull request review by the people who know the skill, a way to revert a bad release, and release channels for staged rollout.

How GitHub sync for Claude plugins works

Skills travel through GitHub inside plugins. A plugin bundles one or more skills (plus optional connectors and commands), and a marketplace is a repo with a marketplace.json that lists them. Since September 2026, Claude Code also pulls skills and plugins from claude.ai into terminal sessions, so one synced repo reaches chat, Cowork, and the CLI.

• Connect the repo. An owner goes to Organization settings > Plugins & skills > Marketplaces, selects Add, then Sync from GitHub, and enters the repo as owner/repo. The repo must be private or internal – public repos aren't allowed for organization marketplaces. GitHub Enterprise servers work too.

• Turn on automatic sync. This creates a webhook on the repo, so whoever flips the toggle needs admin access on GitHub. A sync only fires when a pull request with a plugin version bump merges to the default branch. Direct pushes don't trigger it. That rule enforces the workflow you want: no review, no release.

• Bump the version every time. Claude Code resolves a plugin's version from plugin.json first. If you set "version": "1.0.0" and push new commits without changing it, users keep the cached copy and never see the update.

• Pick a distribution setting per plugin. Required (pre-installed, can't be turned off), Installed by default, Available to install, or Not available. On Enterprise, admins can override these per group.

• Add release channels if you need staged rollout. Organization settings have no canary group or percentage rollout, so the workaround lives in Claude Code: point two marketplaces at different branches, stable and latest, and assign them to different groups through managed settings. Each channel has to resolve to a different version, or both groups get the same thing.

Review shared skills the way you review code

A skill carries instructions and often executable code, and it runs with the permissions of whoever invokes it. Anthropic's engineering team names the risk: "malicious skills may introduce vulnerabilities in the environment where they're used or direct Claude to exfiltrate data and take unintended actions."

How Google ships 170+ agent skills through GitHub

In a post on how the team runs the repo, Lead Developer Relations Engineer Remigiusz Samborski treats every skill as a product, because a skill "steers an AI agent's reasoning loop, tool selection, and execution path." The repo has passed 21,000 GitHub stars and installs into Claude Code as a plugin marketplace with claude plugin marketplace add google/skills.

Before a change reaches the public repo, it has to pass six automated gates and a human reviewer:

1. Structural conformance – directory layout, allowed files, and taxonomy
2. Linters – frontmatter, folder naming, and Markdown rules
3. Semantic versioning – every behavioral change needs a version bump, or the pull request is blocked
4. Evaluation suite – a valid eval suite and a fresh report run against the latest commit
5. Link validation – relative links on every PR, plus a weekly scan of external links
6. AI review agent – a skill that checks quality and design standards
7. Human approval – the skill's subject matter expert, plus a member of the Central Skills team for new skills

The first three checks are fast and deterministic, and they stop the pipeline before the slower LLM-based checks run. Google suggests gating the expensive checks further for teams with frequent small commits, for example behind a /run-evals PR comment.

Google's AI reviewer also enforces a few design rules worth copying as-is:

• Scripts for deterministic steps – rigid CLI sequences, parsers, and deployment steps go in scripts/; Markdown is for judgment
• A compact SKILL.md – the body stays under 500 lines
• One level of references – agents often stop before following a second chained reference

What human reviewers check at Anthropic

Anthropic's enterprise review checklist is eight steps, and it works as a pull request template. The first few: read everything in the skill directory, verify each script does what it claims, and check for adversarial instructions, external network calls, and hardcoded credentials. 

Claude Code gives you enforcement to go with it. You can allow or deny individual skills with Skill(name) permission rules and set disableSkillShellExecution to stop skills from running shell commands. For marketplaces, strictKnownMarketplaces is a hard allowlist, and setting it to an empty list blocks all of them.

How non-engineers contribute to a GitHub skills repo

Everything above assumes the people writing skills are comfortable opening a pull request. Many of the best skills come from marketing, sales ops, finance, and support – people who build and refine them in claude.ai.

Those edits don't flow back to the repo. Someone improves a skill in the chat UI, their copy drifts from the synced plugin, and you're back to five versions. Anthropic's guidance for multi-surface deployments is to "implement your own synchronization process to keep them consistent." No built-in sync exists yet.

Google routes outside input through GitHub issues: anyone can report a bug in a skill or request a new one, and the skill's owners make the change.

The same setup works inside a company. Name a skill owner who can use Git, give non-engineers a simple path to submit changes (a form, a Slack channel, or the org library with review on), and treat the repo as the only place a release comes from.

Claude Team vs Enterprise for skills management

Both plans get sharing, the org library, and GitHub sync. The differences show up once you need control over who gets what.

• Group targeting – Enterprise only. Bundle skills into a plugin and assign it to a group; when someone belongs to several groups, the most permissive setting wins
• Skill scanning – Enterprise only. Claude checks each third-party skill and plugin users upload or edit for malicious content before it can run
• Publishing defaults – Team plans default to Open. Enterprise starts with publishing off, and Requires review has been the default since October 2, 2026 

If you're rolling skills out to a few dozen people who mostly want the same things, Team covers it. Once different departments need different skills, or security wants scanning in place before anyone uploads a third-party skill, Enterprise is worth it. For pricing and the rest of the differences, see how to choose Claude Team vs Claude Enterprise.

Where to start

For one workflow and one team, share the skill and name an owner. That's enough.

Once several teams depend on a handful of skills, move them into a plugin backed by a private GitHub repo, connect it with GitHub sync, and review changes through pull requests.

Borrow the cheap parts of Google's pipeline first: a CI check that blocks a missing version bump, a linter for structure, and an eval report on every PR. Retire the personal copies as you go, and route improvements back to the shared version instead of letting people fork it.

The usual failure is five versions that all sort of work, and no one who can tell you which is right.