Your support team wrote a great “triage a ticket” skill for Claude Code. It encodes everything they’ve learned: how to classify severity, which runbooks to pull, when to escalate. Last month, your sales engineers — working in Cursor — wrote the same skill from scratch. Theirs is worse, and neither team knows the other’s exists.
This is where enterprise AI adoption has landed. Whether organizations got here through cautious pilots or rapid experimentation, the result is the same — multiple AI clients, duplicated workflows, and little to no oversight or governance.
Now that the AI ecosystem has started to mature, teams are using Cursor, VS Code, Claude Code, Codex, ChatGPT, and Claude across the organization. The problem is not that there are multiple tools. The problem is that reusable enterprise knowledge gets trapped.
As components like skills, MCP servers, plugins, and agents have emerged in similar but slightly different forms across clients, the challenge of normalizing, distributing, and governing them has grown harder. In this post we’ll talk about how to curate the client zoo — and why, much like RPM, DEB, PyPI, and npm needed package managers, centralized skill management is an important part of the solution.
What Are Skills?
Skills are reusable prompts, scripts, and assets that can be shared across an organization. They were originally defined by Anthropic as a way to package and share reusable bits of context among users. The specification has since been adopted by other clients and is becoming a standard in the industry.
The key property is progressive disclosure. Context is only loaded when a user needs it. The model is fed metadata from the SKILL.md frontmatter — just enough information to determine when and how to use the skill. All of these components can be packaged and shared across clients and teams.
Why Skills Are Not Enough
Skills are a great way to package reusable workflows, but they are not a complete solution to the client zoo problem. They do not address centralized discovery, distribution, or governance.
Today most teams use skills within small silos. There is no central repository or management system. Each team creates its own skills and encapsulates its own knowledge, so the rest of the organization never benefits from that work — or improves on it.
Duplicated effort is only part of the cost. Skills get manually copied between machines and teams, which creates version drift. Consider a “generate a customer contract” skill that legal updated three weeks ago to reflect new data-handling terms. Half the company is still running the old copy, and nobody can tell you which half. When skills carry compliance and policy logic, stale versions become a real liability.
This is the same problem code packages had before npm and apt. The packages existed, but without a registry and package manager, distribution was manual and inconsistent. Skills are in the same place today.
Skills need a way to be centrally managed, curated, and distributed across the organization.
Ready to manage AI skills across your organization? Start a free Obot trial and see centralized skill management in action.
What Centralized Skill Management Requires
Teams are already familiar with Git-based workflows. Centralizing skills into a Git repository gives you version control, pull request collaboration, and a single source of truth for the organization. CI workflows can validate changes, enforce policy, and run security checks before anything ships.
But a Git repo alone is a registry without a package manager. npm isn’t just a pile of tarballs on a server — it’s discovery, installation, versioning, and updates. A complete skill management system needs the same pieces:
Distribution across clients. Each AI client handles skills slightly differently — some use ~/.agents/skills, others use ~/.claude/skills. The distribution layer needs to install skills to the right location for each client, so every user has access to the same set of skills regardless of which tool they use.
Access policies. Not every skill should be visible to everyone. Your finance team’s “close the quarter” skills may need to stay private while your support team’s “handle a support ticket” skills are shared across the organization. Git permissions alone are too coarse for this.
Discovery. A skill nobody can find is a skill that gets rewritten. Users need to be able to search for skills from inside their agent of choice, not browse a repo and hope.
A feedback loop. Skills should update automatically when new versions ship upstream, and usage and feedback should flow back to authors so skills improve based on real-world use.
Git provides the foundation. The rest is what turns a repository into a package manager.
How Obot Can Help
Obot is an AI platform that provides exactly this layer. It aggregates skills from multiple Git repositories into a single registry, adds access policies on top, and handles distribution and updates across clients.
Discovery happens where users already work. Using the Obot CLI, users can find skills with natural language in their agent of choice:
text
> How do I handle a support ticket?
Found skill: support-ticket-triage (v2.3.1)
Installed to ~/.claude/skills/support-ticket-triage
There’s no need to browse a repo, ask around in Slack, or rewrite a skill that already exists on another team.
For admins, Obot provides visibility into which skills are installed and in use across the organization — enabling better planning and governance of the skill layer as AI adoption scales.
Curating the Zoo
The client zoo isn’t going away — and it shouldn’t. Different teams genuinely need different tools. What needs to change is the layer underneath: the knowledge your organization encodes in skills should be written once, governed centrally, and available everywhere.
That’s what Obot does. If your teams are already building skills in silos, try Obot and turn them into shared infrastructure.
