# Pin a short skill allowlist instead of shopping the registry

> Nearly half of public skills were installed once. Pin a short allowlist in the repo and write the private rule only your team knows.
> By Dave · 2026-09-27
> Source: https://otf-kit.dev/blog/pin-agent-skills-allowlist

A SaaS team should pin a short agent-skills allowlist in the repo instead of shopping the public registry every sprint. Amelia Charles, Andrew Qu, and Jonathan Hefner published the report behind that decision on the Vercel blog on 25 September 2026. The useful finding is concentration. Nearly half of all skills on the skills.sh registry were installed exactly once. 375 skills, 0.04% of the registry, account for 62% of installs. The most-installed skill is still under 1% of installs. There is no default skill to buy.

Install figures in that report are aggregate registry counters. They do not represent unique people, and they do not necessarily represent independent choices. A high count can be one script repeating an install. A count of one can be a skill that fit a single setup. Neither count shows that an agent does the job better with the skill than without it. Pin the public skills that match jobs this repo already runs, and write the private rule only your company knows. The report names the shape of that rule: when a customer gets a refund, or what can ship without another review. Those are files you maintain, not rows in the registry.

## What the install curve actually says

The top 1.2% of skills account for 94% of installs. Skills installed exactly once sit in what remains.

That concentration is not one winner. Skills compete inside a job and stack across jobs. Once a team has an expense-report skill, it has little reason to install a second one for the same job. It can still add a different skill for spreadsheets, research, or a presentation. Each job has a small winner, and those winners together carry most installs. The allowlist is that set of jobs, written in the repo.

A leaderboard is a poor source for the file. First place can be a job you do not run, and even that skill is under 1% of installs. Catalog totals count unique listings, and the report notes that figures may be revised as the data and the method improve. Treat the percentages as the shape on 25 September 2026. Treat the file as the decision that survives a revision.

## Why an install count is a weak buy signal

The report says the best public signal of quality today is install count. It is still a counter, not a test that the job got better. A skill justifies itself only when the agent does the job better with the skill than without it, and the report expects skills to gain tests for that. Until a test exists for the listing you want to add, the count cannot close the review.

Category shares describe a classified sample, not every listing. No category draws more than a fifth of installs. Software engineering is the largest share at 18%, agent workflows follow at 15%, and business operations and writing sit near 11% each. None of those shares names a package.

In that same sample, skills for work shared across industries are 66% of classified skills and 87.5% of installs. They draw 3.6 times as many installs per listing as industry-specific skills. That supports a short list of shared jobs. It does not let a public listing stand in for your refund rule.

## Pin the allowlist in the repo

The pin is a file you review. The report does not define a command, an endpoint, or a schema for an allowlist, so this draft does not invent one. One job per block. The registry id stays blank until a reviewer has opened that listing. The date is the merge date. A second block for the same job needs a reason the first skill cannot do the work.

```text
# agent/skills-allowlist.txt
# One public skill per job. Add a block only in a reviewed change.
# Install counts are aggregate counters, not unique people.

job: expense-report
registry-id:
pinned: 2026-09-27
note: one skill for this job

job: spreadsheet-cleanup
registry-id:
pinned: 2026-09-27
note: tidy an export before a person reads it
```

Those job names follow the report's examples. They are not packages it ranked. A blank `registry-id` is not approved for install. Fill it in the same change that reviewed the listing. Do not paste an id from a leaderboard nobody opened.

![Byte edits the allowlist file while Luna points at two job blocks and Dex holds one approved card](https://cdn.otf-kit.dev/blog/pin-agent-skills-allowlist/inbody1-20260927a.png)

The pull request should name the weekly job, say why the current block is not enough if one exists, and say what a later review will re-check. If it cannot name a job in this repo, it does not merge. The next sprint reads the file. It does not browse the registry.

Delete a block unused for a month. On sprint day, a filled id does not get a replacement search. A blank id gets one reviewed listing, or the job is marked private. A new job starts as a blank block. The install happens after the merge.

## Write the private rule next to the list

The report says public skills will turn general know-how into the baseline. More of what sets a company apart will then sit in judgment only that company has. The examples it names are when a customer gets a refund, and what can ship without another review. Write them in ordinary language: the steps, what good looks like, and when to stop. The report describes a skill as a file of that kind. The registry cannot rank yours, because it does not know your window or which paths touch billing.

The numbers below are a shape, not thresholds from the report, and not a default for every team. Replace each one with the rule a person on your team already follows.

```text
# agent/skills/company-rules.md

When a refund is allowed

Read the charge on the current workspace only.
Allow the refund only when every line is true:
- The charge posted within 14 days.
- This workspace has no refund recorded in the current quarter.
- The caller is an owner of this workspace.
If any line is false, stop. Write the failed line on the ticket and leave the charge.

What can ship without another review

A change may ship with no extra reviewer only when every line is true:
- It does not change a price, a limit, or who can sign in.
- It touches no migration and no billing file.
- The diff is at most 40 lines.
If any line is false, open a review and stop. Do not merge.
```

![Dex and Luna review a private refund and ship-gate rule folder while Byte files it in the repo](https://cdn.otf-kit.dev/blog/pin-agent-skills-allowlist/inbody2-20260927a.png)

Change the rule by editing the file. A window that moves from 14 days to 7 days is a diff, and the agent sees it the next time it reads the path. Point the agent at that file the same way you point it at any other instruction file in the repo. There is no extra service to call.

Keep three cases beside the file: a refund that meets every line, a refund that fails one line, and a diff that must wait. Re-run them when the file changes. That check stays private. It is not a registry count. Once a public skill is on the allowlist, [measure whether that skill does the job](https://otf-kit.dev/blog/claude-code-plugin-eval-ci) before you add another beside it.

## When the catalog is already finite

Some tools ship a small catalog for their own surface. Installing it once is a closed list. [Install that catalog](https://otf-kit.dev/blog/expo-skills-for-ai-agents) and record those jobs as blocks whose note names the vendor catalog as the source, so the next sprint does not add a second public skill for a covered job.

Do not paste that catalog into the private rule. It knows the tool. It does not know when your company refunds a charge. If a job still has a blank registry id, review one listing or keep the job private.

## When you don't need this

Skip the allowlist when no agent runs against this repo. The concentration in the report matters when someone is about to install a skill.

Skip it when one person installs skills and already keeps that list in a note they open. The pin matters when the next person, or the next sprint, would shop again and treat a fresh count as a reason to switch.

Skip the refund lines and the ship lines when a person still makes every call and the agent is not allowed to take them. Write the file when the agent is about to act.

Skip a second public skill for a job that already has a block. Add a block for a new job instead. You also do not need the file merely to read the report.

Put both files in one reviewed change. The list records which public skills are allowed. The rule records what only your company knows. Commit them in the SaaS repo you already ship. The SaaS dashboard template is here: https://otf-kit.dev/templates/saas-dashboard

## Sources

- https://vercel.com/blog/state-of-agent-skills
- https://www.skills.sh/