Why another agent package manager? Starting with Skills and npx

At WarsawJS Meetup #142, I was introduced to Agent Package Manager (APM). The talk gave me a broad overview, but one question stayed with me: why introduce another tool when Skills already exists?

I wanted to understand what would justify adding another piece to a development setup. Could the tools we already have cover the same needs? Was I overlooking a problem that APM was designed to solve?

I promised to explore this after the meetup. My investigation started with Skills - and took a detour into what happens when we type npx.

That detour helped me make the comparison more precise. Before asking which tool I would choose, I needed to separate the instructions I wanted to share from the software used to install them.

Start with what we want to share

Imagine writing down a process for reviewing code for an AI coding agent. You might explain which problems to look for, which project conventions matter, and how to report findings. Once those instructions are useful, you may want to reuse them in another project or share them with a teammate.

A skill gives those instructions a home. In the format used by Skills CLI, it is a directory containing a SKILL.md file with a name, a description, and instructions. Supporting files can accompany it. Skills CLI provides a way to discover and install skills for supported agents. Skills documentation

For this example, the review process is hypothetical. It helped me frame the question: how would those files get from their author's repository into someone else's agent setup?

That is where this command enters the story:

npx skills add owner/repo

Here, owner/repo stands for the GitHub repository containing the skills you want to install. The command is short enough to make the whole operation look like one thing. I found it useful to read it in two stages.

What npx actually does

npx runs a command provided by an npm package. It can use a package available locally; when the requested package is missing from the project's dependencies, it can fetch it into the npm cache before running it.

In this example, npx launches the Skills CLI and passes add owner/repo to it. Skills CLI then handles the skill installation. The instructions come from the specified repository.

You can think of npx as an executor for npm packages. Its job here is to get the installer running. The meaning of add, the source formats, and the options for selecting skills belong to that installer. npm documentation

For example, Skills documents this way to list the skills available in a repository before installing them:

npx skills add owner/repo --list

The --list option is handled by Skills CLI. Skills installation options

This also means you can distribute your own skills through a Git repository without publishing them as a separate npm package. npm delivers the CLI; the repository supplies the skill files.

The next question: which version?

Once I separated those pieces, “does it support versioning?” became a more specific set of questions.

There is a version of the installer, and there is a revision of the instructions it installs. Choosing one does not, by itself, tell me which other files will end up in my project.

For a comparison, I wanted to know: can I choose a particular revision of a skill? What gets recorded after installation? If a teammate installs it later, will they receive the same content? And what changes when I ask for an update?

Those questions became the next stage of my investigation. A convenient installation command was only the starting point; I also cared about maintaining the resulting setup over time.

I began with “why do we need APM?” This first step gave me a clearer basis for answering it: the skill, its source, and its installer each have a separate role.

In the second part, I’ll look at how APM approaches that setup and where its responsibilities differ from Skills CLI. That is where I can return to the original question with a useful comparison.