n-skills syncs third-party code daily, and four of its seven categories are empty

Four of the seven categories have nothing in them

The marketplace defines seven categories in a table: workflow, tools, development, productivity, automation, data and documentation. Each has a one-line description of what belongs in it.

The catalogue above it holds five skills, and the two routes into them are both three commands long. With the plugin route, you add the marketplace:

/plugin marketplace add numman-ali/n-skills

and then install a skill by name with the marketplace suffix. With the universal route, you install the command line tool, install from the repository, and sync:

npm i -g openskills
openskills install numman-ali/n-skills
openskills sync

Back to the categories. Two of the five skills are workflow, two are tools, and one is automation.

So four of the seven defined categories are empty, and three of the five populated ones have exactly one entry each. The taxonomy was written ahead of the collection, which is normal for a new marketplace and worth noting because the category names are what a curator would file future submissions against.

The five skills themselves are worth reading closely, because the descriptions are unusually blunt about what each one is. One is a multi-agent orchestrator using a task mirroring tool and a todo writer. One is described as end to end maintenance for an open-source repository. One is browser automation with persistent page state, and it is the only skill sourced from outside this project. One is another multi-agent orchestrator, annotated as best with a specific assistant and a specific model. And one exposes another company's vision, search, reader and repository exploration tools through the protocol for tool access.

Two multi-agent orchestrators out of five is a marketplace that has clustered on one theme rather than on one need.

A daily job copies external skills in without a review

The auto-sync section describes a mechanism that is the most consequential thing in the readme, and it is easy to skim past.

A skill author keeps their skill in their own repository. They add an entry to a source manifest in this repository by pull request. After that, a scheduled job runs daily and copies the author's folder into the marketplace, preserving attribution in a metadata file. The stated division of labour is that the author maintains ownership and the marketplace curates the collection.

Read as a supply chain, this is a standing agreement to take code from someone else's default branch on a timer. Once listed, the author's next commit lands in the marketplace without anyone reviewing it, and anyone who installs the skill gets whatever is at the head of that branch at that moment. The one native installer command that takes a repository address points at a branch rather than a tag for the same reason.

The attribution file is the mitigation, and it is a good one: it records where the code came from, so an analyst can tell synced code from curated code by looking. What it does not do is pin anything.

The alternative the project considered and rejected is worth reading too. Submodules are named as the thing being avoided, with the blunt reason that submodule hell is real, and the stated benefit of the chosen approach is that it works with the native installers of every agent without special handling.

A sync pipeline built for one external skill

The repository layout explains how much machinery stands behind the sync, and comparing it with the catalogue size is instructive.

At the root there is a marketplace manifest for the plugin system, a scheduled workflow file for the daily sync, two scripts, one for the sync engine and one that regenerates the registry from what the sync produced, and a source manifest listing external skills. Those five files are the whole pipeline.

Now look at what it currently serves. Of the five skills in the catalogue, four are marked native, meaning they live in this repository. Exactly one is external, with an attribution link to another author's project.

So a daily scheduled job, a source manifest, an attribution convention, two scripts and a registry generator exist to keep one folder current.

That is not an argument against building it early. A marketplace that intends to hold external skills has to have the mechanism before it has the tenth contributor, and writing the sync first means the first external author does not wait on anyone. It is an argument for reading the catalogue as smaller than the infrastructure implies.

The package scripts reflect the same shape: a sync command, a registry command, and one that runs the first then the second in sequence.

The manifest says 1.3.6 and the newest tag is 1.3.2

The release list stops in January. Three tags are visible, two of them published on the same day in early January 2026: an orchestration feature release, then a namespace fix with compliance documentation hours later. The third came about a week later and covers the official plugin structure and an open-source maintainer skill.

The package manifest, meanwhile, says a different number. It is three patch versions ahead of the newest tag, and the last push to the repository came in September 2026, roughly eight months after that tag.

None of that is visible to a user, and that is the point worth making. The package is marked private, so there is no registry entry and no version anyone installs. Installation goes through a plugin command or through a separate command line installer, neither of which resolves a semantic version from here.

So the version number is internal bookkeeping, and it has drifted from the tags that are the only other record. For a marketplace whose value depends on knowing what you are installing, the practical answer is that you cannot tell from this repository which state of the collection you have. The skills are directories, not versions.

Universal means one author's installer writes another agent's file

The compatibility table lists nine agents and sorts them into two groups, and the distinction matters more than it first appears.

Five are native. One has a plugin system the marketplace registers with directly. Two read the shared discovery file directly. One has its own installer command. One has native skill support of its own.

Four are marked universal instead, and all four reach the same destination: the openskills command line tool is installed, the marketplace is added through it, and it writes the shared discovery file where that agent expects to find it.

So the universal path is not a standard. It is a third-party installer, and it is published by the same person who curates the marketplace. That is not a problem in itself, and it is the only thing making four agents work at all, since none of them reads the marketplace format natively.

The shared discovery file is the load-bearing idea underneath all of it. The readme cites an industry article for the claim that it is adopted by a large number of repositories and natively supported by several of the agents in that first group, and the claim is the reason a marketplace can exist at all: without one file every agent reads, there is no marketplace, only nine plugin systems.

The curation bar and the existing catalogue do not fully agree

The submission section is specific about what gets turned down, and the specificity is a sign the curator has seen the failure modes.

Wanted: skills that solve real problems, clean well-documented code, genuine utility for developers, active maintenance. Not wanted: wrapper skills with no real value, abandoned or unmaintained projects, and low-effort submissions. The process is an issue first, then a pull request against the contribution guide, and the curator also accepts direct messages.

Now apply that bar to the five skills on show.

One of them is explicitly a wrapper: it exposes another company's vision, search, reader and code-hosting tools through the protocol for tool access. Two are multi-agent orchestrators, and one of those carries a note that it is best with a particular assistant and a particular model, which is a vendor preference written into a marketplace entry. The browser automation skill is the only one whose description names a capability that is hard to get elsewhere, namely persistent page state.

None of this makes the catalogue bad. It makes the stated bar aspirational rather than applied, which is normal for a small curated collection and worth knowing before you submit something thin and expect a fast answer.

Two scripts, one development dependency, no lockfile and no tests

The automation surface is small enough to read in full. The manifest has three scripts: run the sync, regenerate the registry, and a third that runs the first and then the second in sequence.

There is one development dependency, a YAML parser. That is the correct dependency for reading the source manifest and nothing else is needed.

What is missing is more interesting. There is no test script and no lint script. There is no lockfile in the repository, despite the one development dependency, so two clones can resolve different patch versions of that parser. There is no build step, which is correct for a repository whose artefacts are markdown files and a JSON manifest.

The absence of tests is defensible for a two-script sync tool, and it becomes less defensible as the collection grows, because the sync script is the component that writes into other people's installations. A test that asserts the sync copies a folder and writes an attribution record would be cheap.

The tree also commits both discovery conventions at the root, which means the repository uses the two files it spends most of its documentation explaining.

The structure listing stops halfway through the skills tree

The repository structure block shows the same five files the pipeline needs, then starts into the skills directory and ends mid-path, at the automation folder with one child name cut off.

That is a formatting truncation rather than a structural problem, and it is worth naming only because the block is the reader's map of where a skill lives: the marketplace manifest at the root for the plugin system, the workflow file for the daily sync, the two scripts, the source manifest, the discovery file, and then the skills themselves grouped by category.

What the tree adds beyond the block is the rest of the root: a second discovery file for the Claude convention, the contribution guide, a licence, an assets directory, a documentation directory, and a gitignore. There is no separate tests directory and no example, which is consistent with a repository whose deliverable is a directory of instruction files.

One naming detail is worth carrying into use: skills are filed under a category and then a name, which is the path shape the sync copies into and the shape one of the native installer commands points at when installing a single skill.

Editorial conclusion

The portability idea here is sound and it is the reason the project exists: one skill file and one discovery file, so the same skill works whether your agent reads a plugin manifest or a plain instruction file. That makes it a reasonable place to browse for skills before you commit to any of them. Two things to weigh. A daily sync copies external skills from their authors' default branches into the collection, so a listing can change without a review after the initial pull request, and one of the install commands points at a branch rather than a tag. And the catalogue is small: five skills across three of the seven categories it defines, with a curation policy that turns down wrapper skills, next to a listing that wraps a vendor tool. Read the skill file before installing it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. numman-ali/n-skills on GitHub
4. README
5. Releases