New laptop, new hire
One login, one command — every approved skill lands configured in their agent. The setup wiki page retires.
Solutions
Four teams, the same broken pipeline
Agent skills always start as a favour — a zip in a Slack thread, a gist, a pinned message. What breaks next depends on the team you run. Find yours.
For platform teams
Your standards only exist where they are installed
You wrote terraform-baseline so agents stop widening IAM roles. It works — on the four laptops it is installed on. The fifth belongs to the engineer who joined last week, and their agent happily writes iam:* because it has never heard of your rules.
With a registry, the baseline is an org skill. New machines get it on day one; when you cut a new version, an update check shows exactly who is behind. Skills you mark as required are surfaced on every machine that lacks them — surfaced, not force-installed: even a required skill waits for the person to approve it. Enforcement without the spyware feel.
- ↑
terraform-baseline2.1.0 → 2.2.0 - ＋
security-guidelinesv3.0.1org required - −
legacy-deployv1.2.0 — removed by org
Nothing applies until the person approves — required skills included. That rule is what keeps your rollout from feeling like surveillance.
For product engineering
Plausible PRs, wrong in six different ways
Your design system has tokens, a lint rule, and a document explaining both. Every developer’s agent holds a slightly different memory of it — so the PRs look right and drift anyway: a raw hex here, an off-scale spacing value there, a deprecated variant someone’s agent still believes in.
Publish design-system-rules once and every agent reasons from the same version. When the rules change, one release moves the whole team — and the usage view shows which laptops are still generating yesterday’s UI, so drift becomes something you can see instead of something you discover in review.
| Skill | Version spread | State |
|---|---|---|
design-system-rules | current | maintained |
company-architecture | mixed | update available |
old-component-prompts | stale | unused |
For agencies
Client A’s conventions must never touch Client B
Both clients live in the same agents on the same laptops. One wrong context load — a deploy convention, a naming scheme, a stack detail that identifies the client — and you have an awkward email to write and trust to rebuild.
Give each client its own organisation — membership is the wall. Developers staffed on both clients join both organisations and see both registries; everyone else sees neither. When the contract ends, revoke the devices — access dies at the boundary you promised the client it would.
client-a
- deploy-conventions v1.3.0
- stack-context v2.0.1
- review-checklist v1.1.0
@client-a members
client-b
- deploy-conventions v0.9.2
- brand-rules v1.5.0
- api-context v1.0.0
@client-b members
Each client is its own organisation — membership is the wall, and crossing it takes a deliberate invite.
For AI-native companies
Your skills are the process documentation now
Half your operations already run through agents — incident response, PR summaries, release notes. The skills are how the company works. Except they are unversioned, unowned, and live wherever they were last pasted.
Give each operational skill an owner, a version, and an access scope, and the pile of prompts becomes a governed capability shelf: you can see what exists, who maintains it, who can run it, and what changed since last quarter. That is the difference between “we use AI” and “AI is part of our infrastructure”.
incident-runbookSREv1.2.7pr-summaryAll engv0.4.9release-workflowPlatformv1.9.0company-architectureAll engv3.1.2
Cross-cutting
Six Mondays this fixes
Whichever team you run, these are the mornings a registry earns its keep.
“Which version ran?”
The agent did something wrong. The audit log answers with a version and a timestamp instead of a guess — so the post-mortem debugs the skill, not the mystery.
The contractor rolls off
Revoke the device from the panel; installed access dies with it. Nothing to chase, no shared secret to rotate.
The checklist changed
One publish, and every laptop pulls the same v2.2.0. The version-spread view shows who has not updated yet.
Compliance calls
“Who can change what your agents do?” Roles, access scopes, and change history sit in one place — the answer is a page, not a meeting series.
IT refreshes the laptops
Skills stop being the thing everyone forgets to restore. Log the machine in once and reinstall the lot in a minute.
Honest fit
When you do not need us
Two cases where we would rather you keep your current setup — and come back when the shape of the problem changes.
You are one person with three skills
A dotfiles repo is a fine registry for a team of one. The problems MasterSkills solves — drift, access, onboarding, audit — are team problems. Come back when the second person asks for your review skill.
Your skills belong to one repo
A skill that only makes sense inside backend/ should live in backend/ — the repo is already its distribution mechanism, and we deliberately leave repo-internal skills untouched. The registry is for skills that cross repo and machine boundaries.
Start with the team that feels this most
Publish the skill that gets asked about in Slack the most. If it stops getting asked about, you have your answer.
No credit card required · Free for up to 3 people, forever