asm (agent-skill-manager): a CLI for skills across 21 AI coding agents

The problem asm solves: skill directories that multiply per agent

Every AI coding agent keeps its own skill folder. The README names three of them explicitly: ~/.claude/skills/, ~/.codex/skills/ and ~/.cursor/rules/. The same skill ends up copied into each, at different versions, with no single command that shows what exists where. The README's comparison table frames this as scattered installs plus no inventory, and that is the honest framing: asm is not a skill marketplace first, it is an inventory and install layer that happens to ship a catalog.

The secondary problem is less obvious and more interesting. The README states that every installed skill's description is resident in the agent's prompt on every message, whether or not the skill ever fires. That is a context tax paid continuously for capabilities used occasionally. asm addresses it with two commands, asm stats --tokens and asm audit residency, which rank skills by what they cost while resident. Whether the token accounting matches your provider's real prompt construction is something the README does not claim; treat the numbers as asm's own model, not your agent's billing.

The audience is narrow and clear: people running multiple agents, or agents driven from scripts and CI. Single-agent users with three skills will find the TUI pleasant and the audit commands unnecessary.

How asm discovers providers, installs skills and scans them

The README's architecture diagram is short. An agent or script calls asm with --json. asm discovers skill directories, then routes to install, audit or search. Installs pass through a security scan, then SKILL.md frontmatter validation, then get written to agent provider paths. Sources come from GitHub or a registry, and the README says installs pin registry commits.

That ordering matters. Validation and scanning happen before files land in a provider directory, so a malformed SKILL.md fails at the boundary rather than silently sitting in ~/.claude/skills/. The scan looks for shell exec, network access and credential exposure according to the feature table. Three categories is a shallow scan compared with a general-purpose static analyzer, and the README does not describe what happens on a finding beyond the scan existing. Assume it reports; verify whether it blocks before you rely on it in CI.

State lives in the filesystem, not a database. asm list reads across all 21 providers and scopes, which means the answer is only as good as the provider paths asm knows about. A tool released after your asm version will not appear until asm ships a mapping for it. The optional TUI (running asm with no arguments) is a view over the same data, not a separate store.

The authoring side is a pipeline rather than a single command: asm init, asm link, asm eval and asm publish. eval implies some scoring of a skill's behaviour, but the README does not document the evaluation criteria, so do not treat an eval result as a quality signal until you read the docs directory.

Installing asm and running a first audit

The README gives npm as the primary install path. Node.js 22 or newer is required, per the badge at the top of the README. The install is global because the binary needs to be on your PATH for agents to call it.

npm install -g agent-skill-manager

There is also an install.sh at the repository root for a curl-based install, which the README mentions as an alternative. After installing, the first useful command is a JSON listing, because it tells you immediately whether asm sees your agent directories.

asm list --json

You should get one response containing every skill across every provider asm recognizes. If your agent's directory is missing from the output, asm does not have a mapping for it and the rest of the tool will not help you.

Before installing anything new, the README's own workflow puts the security scan first. Run it against a skill you already have so you can compare a known-good result with an unknown one.

asm audit security

For one-off reading without installation, asm get prints a skill body and installs nothing. The README calls this the reference tier: the body is delivered once, at zero residency. That is the command to reach for when you want to check whether a skill is worth its context cost.

asm get <skill>

For scripted installs, every command supports --json and --yes. The README shows the GitHub form directly.

asm install github:user/repo --yes

Where asm gets in your way

The catalog is 6,082 skills from 77 repos. That is the headline number and also the problem: search quality determines whether the catalog is useful or a wall. The README lists asm search and asm inspect as the discovery commands and local tags (asm tag add, asm list --tag, asm search --tag) as a filter, with tag matching using AND. Nothing in the README describes ranking, curation or moderation of the 77 repos. A registry that grows by accepting repositories will accumulate abandoned skills, and there is no documented signal for staleness at the skill level.

The audit commands that delete things deserve caution. asm audit --yes removes redundant skills non-interactively, and asm audit overlap finds differently-named skills doing the same job. Overlap detection on natural-language descriptions is inherently fuzzy. The README does not document a rollback, and it does not document a dry-run flag for the audit commands. If you run asm audit --yes in a script before reviewing the JSON, you have handed deletion authority to a heuristic. Run the audit, read the output, then decide.

Residency accounting is asm's own model. The README says asm stats --tokens shows resident versus body token cost per tool. It does not say the numbers are validated against any provider's tokenizer. Use them for ranking skills against each other, which is what asm audit residency does, rather than as an absolute budget.

Finally, the install is global and the tool writes into provider directories. That is the point, but it means asm is not sandboxed from your agent configuration. Version pinning on registry commits helps with supply chain, not with a bad skill that passes the three-category scan.

asm versus a plain sync script or a dotfiles manager

The obvious alternative is a shell script or a dotfiles manager that symlinks one skills directory into each agent's path. That approach is simpler, has no dependency on Node 22, and does exactly one thing predictably. Its difference in approach is that it has no concept of a skill as a unit: no frontmatter validation, no security scan, no token accounting, no notion of residency versus reference. If you keep one canonical skills folder and symlink it, you already have the scattered-installs fix without the catalog.

What asm adds on top of symlinking is the audit layer. asm audit residency ranks skills to demote out of resident context, and asm get delivers a body once without installing. A symlink farm cannot tell you which of your skills is costing prompt space on every message. That is the specific capability worth the dependency.

Bundles and the local library are the other differentiator. asm bundle install takes curated sets in one pass, and asm install --library installs once with asm activate per provider. The library model is the more interesting one because it separates installation from activation, which is closer to how you would want multi-agent setups to work. The README does not describe how activation interacts with the residency accounting, so that combination is worth checking in the docs before you build a workflow on it.

Maintenance, licence and what upgrades cost you

The repository is not archived. The last push was on 2026-09-13, and v2.20.1 was released the same day, with v2.20.0 the day before and v2.19.0 on 2026-09-09. Three releases in five days is a fast cadence, and it is the kind of cadence that also means breaking changes can arrive quickly. The CHANGELOG.md at the repository root is where to check before upgrading, not the README.

The licence is MIT, stated in both the README badge and the LICENSE file. MIT permits commercial use and modification, and it comes with no warranty. The README also states there are no accounts and no telemetry, which removes a data-processing question that hosted skill managers raise. That is a factual property of the tool, not legal advice; if your organisation has rules about installing global npm packages that write into agent config directories, those rules apply regardless of the licence.

Upgrade cost is mostly the provider mapping surface. Each of the 21 providers is a path convention asm has to know. When a provider changes where it stores skills, asm needs a release. Pinning a version in CI and reading the changelog before bumping is the cheap path. The postinstall script (scripts/postinstall.cjs) runs on install, so a fully offline or script-restricted environment needs to account for that step.

Editorial conclusion

Adopt asm if you run more than one AI coding agent and want one inventory plus a token-residency number you can act on; the catalog is large enough that manual directory archaeology stops scaling immediately. Skip it if you use a single agent with a handful of skills, or if you need a hosted dashboard with team roles, since asm is a local CLI with no accounts and no telemetry. Before trusting it, confirm the version you install from npm is 2.20.1 or later, run asm audit security against one skill you already use, and check that your agent's skill directory appears in asm list output.

Frequently asked questions

Official sources

1. License: MIT
2. luongnv89/asm on GitHub
3. Project website
4. README
5. Releases