Product

Your team’s skills, treated like real packages

The prompts, checklists, and workflows your team writes for its agents are production dependencies — they decide what your agents do to your codebase. MasterSkills gives each one what a dependency deserves: a name, a version, an owner, an access policy, and one reliable way to install it.

Works with 70+ coding agents — Claude Code, Codex, Cursor, Gemini CLI, Copilot, Windsurf, and the rest

What a skill becomes here

@acme-corp/secure-code-review

Reviews diffs against the internal security checklist before review is requested.

Version
v2.4.1
Maintainer
Dilara K.
Access
SecurityPlatform
Contents
3 files · 34 KB
Content hash
sha256 · 9f2c81…
Published
2 days ago

Secret scan clean · approved by a human before publish

The problem, lived

You have watched this happen

A good skill never dies loudly. It decays — in about six weeks, in roughly this order.

  1. Day 1

    The skill is born

    Someone writes secure-code-review and it actually catches things. It gets zipped and dropped into a Slack thread. Everyone downloads it. This is the best day of its life.

  2. Day 9

    The fork

    A teammate improves the checklist — locally. Now two versions exist and both are called “the review skill”. Neither knows about the other.

  3. Day 23

    The new hire

    “Where do I get the review skill?” The honest answer is a pinned message, a gist, and someone’s ~/.claude/skills folder. The new hire gets the Day-1 version.

  4. Day 40

    The question nobody can answer

    The agent waves through a pull request it should have flagged. Which version of the skill ran on that laptop? Nobody can say — and that is the moment it stops being a tooling problem and becomes an engineering-quality problem.

Nobody did anything wrong. There was just no registry.

We built MasterSkills after living this week ourselves — our own skills were zip files in Slack threads, and the developers without repo access could not share theirs at all.

What the registry does

Five jobs, done properly

Nothing here is novel — it is what npm, crates, and your artifact registry already do for code. MasterSkills applies the same discipline to the skills your agents run on.

01 · Publish

Approval-gated publishing, with a secret scan you can see

Your agent packages the skill and prepares a release — but it never uploads on its own. You see the full manifest first: every file, the size, the version bump, and anything that was excluded. Approval is yours; then the server scans the package again and rejects anything with findings.

The server never auto-publishes. Suspicious files are not silently dropped — they are excluded and reported to you. Both rules have no exceptions.

02 · Version

“Which version ran?” always has an answer

Every release is retained and content-hashed. Teams pin an exact version, follow the latest, or roll back with one command — and when an agent misbehaves, the question that used to end in a shrug ends in a version number and a timestamp.

$ masterskills add@acme-corp/[email protected]

03 · Access

Scoped like your private packages

Everything lives inside your organisation boundary. Three roles — owner, admin, member — and kits to organise skills into installable bundles. One deliberate choice worth noting: members publish. The people writing skills are the people shipping them; publishing is not an admin privilege.

Can they…MemberAdminOwner
Install & publish skills
Create & curate kits
Manage members, invites, billing—
Transfer or delete the organisation——

Kits organise — they never widen access. A private skill stays private no matter which kit it is filed in.

04 · Install

One login per machine, then one command

Each machine logs in once through the browser and gets its own device token — SSH-key logic, one credential per laptop. After that, installing a skill is a single command and it lands configured in every detected agent.

When someone leaves, you revoke their devices from the panel and their access dies with them. No credential rotation, nothing to chase.

05 · Audit

Answers, not shrugs

Every publish, install, access change, and revoke is recorded — who, what, which version, when. When compliance asks “who can change what your agents do?”, the audit log is the answer, not a meeting.

The interface

Nobody on your team learns any of this — the agent does

MasterSkills ships as a skill your agent reads once. From then on you speak plain language — “publish the skills we just wrote”, “is anything outdated?” — and the agent drives the CLI under your approval. The contract it works against is small enough to read in full:

Read https://masterskills.dev/masterskills/docs/skill.md and follow the instructions to use MasterSkills

Two invariants hold everywhere: the agent never writes to disk without approval, and never publishes without approval.

$ masterskills search review
→ catalogue + local state, as JSON

$ masterskills add @acme-corp/…
→ installs after your approval

$ masterskills update --check
→ new versions · org-required · removals

$ masterskills prepare ./skill
→ manifest + draft — uploads nothing

$ masterskills publish-draft
→ publishes the draft you approved

Boundaries

What MasterSkills is not

A tool you can trust states its edges. These are ours.

Not another assistant

It does not generate, review, or chat. It stores, versions, and distributes the things your agents run — infrastructure, not intelligence. Your agents stay yours.

Not a Git replacement

Repos remain the source of truth for code, and skills that belong to one repo should stay in it. The registry is for skills that must cross repo and machine boundaries.

Not a marketplace

Private by default, no public listing, no stars, no trending page. Your internal conventions are not content — they are operational knowledge with an access policy.

Give your skills the registry your packages already have

Publish one real skill, watch it land on a second machine in one command, and decide from there.

Start for freeSee pricing

No credit card required · Free for up to 3 people, forever