Version control
Git's guarantees. A document editor's interface.
GitHub gives you real version control at a barrier most teams will not clear. A shared drive gives you an editor anyone can use and no idea who changed what. Neither one fits the people who need to publish here.
The rules
Eight decisions, and the gap between them is the product.
- 01
Editing happens in the browser
No git, no branches, no merge conflicts, no local checkout. If someone can edit a shared doc, they can edit a skill.
- 02
Version numbers are picked, never typed
Publishing offers three buttons — patch, minor, major — each showing the exact next number. The version in the admin console is the same one your agent installs, and a number is never reused.
- 03
Saving and publishing are different buttons
A draft is invisible to everyone else until you say so. Nothing you are still thinking about reaches anyone's agent.
- 04
Nobody edits a published skill in place
Anyone who is not an owner suggests a change, and an owner accepts or rejects it. There is no path where your skill quietly becomes someone else's — not even for a workspace admin.
- 05
Every skill has owners, and only they publish
Owners publish their own edits directly, or open a change request when they want a second pair of eyes. Everyone else's changes wait for an owner. The log records which path each version took.
- 06
Rollback is picking an old version from a list
One click. The next fetch serves it. No revert commit, no incident channel.
- 07
Diffs read as prose
Side by side, in sentences, without a single + or - character. An owner who has never used git can tell what changed.
- 08
New skills start private
A new skill is visible only to its owners until someone shares it. Run it in your own agent for a day, then point it at a group.
Entitlement
Groups, not people.
Every skill and every server is entitled to a group, and people belong to groups. Nobody maintains a per-person list, because per-person lists are how a contractor keeps production access for eight months after the contract ends.
Groups are managed by hand today. On Enterprise they sync from Okta or Keycloak over SCIM, so the offboarding you already do in your identity provider is the offboarding that happens here.
The audit log
It is not a feature we added. It is what the requests already are.
Every catalog fetch and every archive download arrives carrying an identity, because it has to — that is how entitlement filtering works at all. Writing those down is the log.
There is a second reason it has to live on our side: Claude Code keeps no per-user marketplace state. If you want to answer "who has version 4 of this skill right now", the server is the only place that knows.
Each entry records the identity, the client, the object, the version served and the time.
FAQ
Fair challenges.
Why not just use a git repository?
For engineers, git is better and free. It stops working the moment the person who owns the knowledge is in support, finance or legal — and those are the people whose skills are hardest to write and most valuable to govern.
Why not a shared document?
Because anyone can silently change your skill and there is no record. That is exactly the failure the audit log exists to prevent.
Who can see the audit log?
Any admin on your account. It records every catalog fetch and every archive download, with the identity that made it and the version that was served.
Can we export everything?
Yes, at any time, as plain SKILL.md files and JSON config. Portability is the argument we are making to you, so making it hard to leave would be self-defeating.
The price is on the page. That is the whole idea.
$99 a month for up to 50 people, cancelled from the billing page. If you've got a question first, ask it — a person answers.