A skill is a short text file that tells an AI assistant how your company does a piece of work: how you write a proposal, how you triage an upset client, how you run a weekly sync. Anthropic solved how to hand those files to everyone in a company. Connect a GitHub repository to your Claude organization, mark the plugins as installed by default, and every employee has them. Push a change to the repo and Claude picks it up within about thirty minutes. That part works, and we use it every day.
It stops there. The skills live in a Git repository, and Anthropic's own help text tells employees what to do if they want to change one: "You can't edit organization-managed plugins. Ask the person who built it, or build your own version." The other labs are landing on the same shape. Distribution is solved. Management is left as an exercise for the customer.
The repo is the new bottleneck.
Think about who should be writing these files. The sales lead who knows what a good discovery call sounds like. The HR partner who knows the onboarding steps. The finance manager who knows which numbers matter in the monthly close. None of them have a GitHub account, and none of them should need one. Yet the only way to change the skill they own is a commit to a repository.
That leaves a company with two options, and both are bad.
The first is to give a lot more people GitHub accounts, teach them a command line, and train them on commits, branches, and pull requests. This is a technology built by and for software engineers. Asking a sales team to learn it so they can fix a paragraph in a text file is a training program nobody asked for, and the first mistake in the shared repo will make IT take the access back.
The second is to route every change through IT or engineering as a ticket. Those teams were overwhelmed before AI arrived. Right now they are fielding requests for agents, connectors, security reviews, and vendor evaluations on top of everything they already ran. A ticket to change one sentence in a skill lands at the bottom of that queue, and the person who needed it stops asking. The skill goes stale, and stale skills are worse than none, because people trust them.
Either way, the people with the knowledge are cut off from the place the knowledge lives.
We built the layer in between.
We hit this wall ourselves. Gadoci Consulting runs on Claude skills across sales, brand, security, and general operations, and the only person who could change any of them was the one who set up the repo. So we built the missing layer and called it Skillhouse. It has been running our own skills for a week, and we plan to offer it to clients soon.
Skillhouse sits between the people and the repository. It knows your departments, who belongs to them, and who is allowed to approve changes for each one. It connects to your GitHub repo through a GitHub App, so nobody needs a GitHub account and the app only ever has the access you grant it. And it shows up inside Claude as a connector, so the whole workflow happens where people already are.
Here is what it looks like for an employee. They ask Claude about a skill, and Claude fetches the current version through Skillhouse. They work on the change together in plain conversation. Before anything is submitted, Skillhouse checks the draft the way a reviewer would: it validates the file format and runs an AI review that summarizes the change and flags anything risky, like a skill that would send client data to an outside system. The employee sees that feedback first and can fix it. Then Claude submits the proposal. The approvers for that department get notified, see the summary, the flags, and a side-by-side diff, and decide. Approve, request changes, or reject, with a note back to the requester.
What happens on approval is a setting. For a small firm like ours, approval commits straight to the repo. For a company whose IT team wants a gate in GitHub, Skillhouse opens a pull request instead, with the requester, the approver, and the reason in the description, and IT merges it on their terms. Either way, every change is a signed commit, every version is kept, any skill can be rolled back, and there is an audit log of who proposed, reviewed, and published what. About thirty minutes after the merge, everyone's Claude has the new version.
The result is that the sales lead fixes the sales skill, an approver in sales signs off, and IT sees a clean pull request or nothing at all, depending on how they want it. Nobody learned Git.
Where it is, honestly.
This is version one. It is deployed, it has passed its first real test with our own team proposing and publishing changes from inside Claude, and it has already caught a bug in one of our own skills that the repo had been quietly carrying for weeks. It has also had its first round of feedback from people who are not the person who built it, which is the only kind that counts.
It does not yet run inside a customer's own network, though it is built so that it can. It manages skills and the plugins that carry them, not every kind of file a repo might hold. And it is a Gadoci tool first, which means it reflects how we think a company should govern this: knowledge owned by the people who have it, reviewed by the people accountable for it, and published without a detour through a ticketing system.
The labs will keep improving distribution. The gap they leave is the same one every company eventually finds with shared documents, policies, and templates: who gets to change the thing everyone relies on, and how. Skills are about to become the most important documents a company writes, because they are the ones the AI reads. They deserve a review process built for the people who write them. That is what we're building.
If you're a Gadoci client and want to be an early user, ask us.
Sources
- Organization-managed plugins are distributed from a connected GitHub repository and sync on merged changes within about 30 minutes: Anthropic help center, Manage plugins for your organization
- "You can't edit organization-managed plugins. Ask the person who built it, or build your own version.": Anthropic help center, Use plugins in Claude
- Anthropic's guidance to keep skills in Git as the source of truth and separate authors from reviewers: Claude Developer Platform, Skills documentation