# AI Agent Skills states the size of its own library twice and the two numbers differ > An npm package that both ships a curated shelf-based library of agent skills and provides the tool to build your own. An auto-generated stats block says 18 house copies and 123 cataloged entries; the release note three paragraphs below says 17 and 115. The global default install target is a Claude directory, most catalog entries fetch a third-party repository at install time, and the engine floor is Node 14 under four modern UI libraries. **MoizIbnYousaf/ai-agent-skills** — Universal skill installer and package manager for AI coding agents. One command, 12+ runtimes. npx ai-agent-skills - Repository: https://github.com/MoizIbnYousaf/ai-agent-skills - Website: https://www.npmjs.com/package/ai-agent-skills - Stars: 1,146 · Forks: 134 - Language: JavaScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/moizibnyousaf-ai-agent-skills ## The library size is stated twice and the two figures disagree Near the top of the readme there is a block delimited by comments marking it as generated, and inside it a line of statistics. That line reads 18 house copies and 123 cataloged upstream. Three paragraphs lower, in the section announcing what shipped in version 4.3.1, a bullet says the bundled library now ships 115 cataloged skills, made up of 17 house copies and 98 cataloged upstream. Every number differs. House copies are 18 in one place and 17 in the other. Cataloged entries are 123 against 98. The total implied by the generated block is 141 against a stated 115. The generated block is the one to believe about the current state, and the explanation is structural rather than accidental. The block sits between markers saying it is generated, and the section above it instructs agents not to hand-edit three specific files when a command already exists. So the statistics line is produced by a script and the release note is prose written by a person. What makes this more than a stale blog post is that the release note is the newest section in the file and describes version 4.3.1, while the manifest carries 4.3.2. So the hand-written part is one patch release behind, and its numbers are pinned to the moment it was written. ## The universal installer's default global target is a Claude directory The description calls this a universal skill installer and package manager for AI coding agents, one command across more than a dozen runtimes. The install targets section is where that claim meets the filesystem. Two defaults are given. The global target is a skills directory under the home directory, named for Claude. The project target is `.agents/skills/`, which is agent-neutral. So the two defaults are not symmetrical. On a per-project basis the tool is genuinely universal, because the directory name does not name a vendor. At the user level, the default is one specific agent's directory, and a machine running three different agents has all three sets of skills installed into whichever of them reads that path. The older layout is still reachable, through an explicit agent flag. So the migration is: agent-specific directories were the original scheme, an agent-neutral project directory replaced them for projects, and the user-level path still points at the old vendor's directory. The bundled library is reached through commands that never name a target, because the target is a default. ```bash # Open the terminal browser npx ai-agent-skills # List the shelves npx ai-agent-skills list # Install a skill from the library npx ai-agent-skills install frontend-design # Install the Swift hub to the default global targets npx ai-agent-skills swift # Install an entire curated pack npx ai-agent-skills install --collection swift-agent-skills -p # Install the mktg marketing pack npx ai-agent-skills mktg npx ai-agent-skills marketing-cli # Install to the project shelf npx ai-agent-skills install pdf -p ``` That block shows a second wrinkle in the command grammar. A single skill name goes through the install verb, but a named pack is a bare verb of its own with no argument at all. So whether a name is a skill or a pack decides whether it needs a subcommand, and nothing in the file explains how the tool tells them apart. The project flag is also a bare letter, explained by one comment and nowhere else. The twelve-plus runtimes claim is not enumerated anywhere in the visible file. Two paths are named, plus whatever the agent flag reaches. The keyword list in the manifest names one vendor alongside the generic terms, which is consistent with the default path rather than with the description. ## Most of the catalog fetches a third-party repository when you install The architecture section is four paragraphs long and it is the most important part of the file. Every skill is one of two kinds. A house copy is a local folder under a skills directory, and the file says those install fast, work offline, and ship with the npm package. A cataloged upstream pick is metadata in a JSON file with no local folder, and those stay upstream and install from the source repository when you ask for them. The stated principle is that upstream work stays upstream, and the stated reason is that it keeps the library lean. That is a real trade and the file makes it explicitly. The consequence is arithmetic. Of the entries described, the large majority are catalog records rather than folders. Installing one of those is a network fetch of somebody else's repository content at the moment you run the install command, and nothing in the published package contains it. So the offline property is a property of one of the two kinds, not of the library. The package itself contains the catalog metadata and the local folders; the catalog is an index of things to go and get. The file is honest about this, which is the right way to present it, and a reader who takes the word universal as also meaning self-contained would be reading more into it than is there. ## The onboarding path is to tell an agent to fetch a document There is a section headed for your agent, and it is the primary onboarding route. The instruction is to paste a block into your agent. The block asks the agent to set up a managed team skills library, and then instructs it to fetch and read a protocol document from a raw content URL on the same repository before starting anything. It also tells the agent not to hand-edit three files when a command already exists, and lays out numbered steps beginning with fetching that document and creating a workspace. So the flow is: the user pastes text into an agent, the agent retrieves a document over the network, and the agent then runs a series of commands. The document is described elsewhere as the full curator decision protocol, and a separate link offers the long version with a decision framework. That design has a clear rationale. The tool's hardest verb is a judgement call about what belongs on a shelf, and a model can make that call with the library in front of it. It also means the entire onboarding depends on two things the user did not write: the pasted block, and whatever is at that raw URL when the agent fetches it. The companion workflow skills reinforce the pattern. Nine of them are named, covering installing from a remote library, curating a team library, sharing a library, browsing and evaluating, updating installed skills, building workspace documentation, reviewing a skill, auditing library health, and migrating skills between libraries. The library ships skills about managing skills. ## Node 14 as the floor under React 18 and a terminal UI framework The manifest declares an engine floor of version 14.16.0 and depends on five packages. Four of those five are a terminal user interface stack: a terminal renderer, a terminal text input component, React itself, and a small hyperscript-style tag helper. The fifth is a YAML parser. So the declared floor is a Node release from 2019, sitting under four modern major versions of rendering libraries plus a text-input widget that has to read from a terminal. The floor is what the package asks a resolver to enforce, and a Node 14 machine that satisfies it will still have to run all of that. There is a second thing the dependency list does not contain, and it is more interesting than the first. Cataloged upstream entries install from a source repository. Fetching a repository needs a network client, and there is no HTTP client in the dependency list. So that fetch goes through whatever Node provides out of the box, or through a version control subprocess, and the file does not say which. The manifest also carries two different descriptions of the project. The repository description calls it a universal installer and package manager. The package description calls it a curated library and a library manager for building your own. And the homepage field points at the readme anchor rather than at the package page or the documentation site. ## Adding a skill requires an area, a branch and a sentence saying why The workspace commands are where the curation idea becomes concrete, and they are the part of the file most worth reading. Creating a workspace is one command and a directory change. Adding a bundled pick takes the skill name, an area, a branch, and a why flag whose value is a sentence about wanting the skill on the shelf. Adding an upstream skill takes a repository reference in the form of an owner and a repository, a separate flag for the skill inside that repository, and the same three metadata flags. So the core verb of the tool is add, and add refuses to be called without a written justification. That is the mechanism behind the file's claim that it keeps provenance visible and keeps notes explaining why a skill is there. Every shelf entry carries a classification and a reason, which means the shelf is a curated argument rather than a list. The word branch is worth flagging, because in the examples it takes values like implementation and testing. It means the kind of work, not a version control branch. A reader who assumes otherwise will structure their shelves wrongly. The other verbs form a small maintenance cycle: install to place a skill, sync to refresh it, and build-docs to regenerate the generated files. A separate vendor script in the manifest, and a workflow guide on making a house copy, describe the one-way promotion from a catalog entry to a local folder. ## Bulk import fills a fallback bucket that a human has to finish The workspace section covers importing an existing library in bulk, and the command carries a flag that promises more automation than it delivers. The flag is called auto-classify. The comment above it says to bulk import an existing library after bootstrap. And the next comment, which is the one that matters, says to review the fallback bucket and finish it. So the automatic classification does not classify everything. Whatever the classifier cannot place goes into a bucket, and a person has to look at that bucket and complete the job. Given that every other add in this tool demands an area, a branch and a reason, that is coherent: the classifier can propose a shelf, and the human still has to justify it. It is worth knowing because the flag name is the sort of thing a reader skims. Auto-classify sounds like the migration is finished when it runs, and the file's own next comment says otherwise. The surrounding flow repeats the earlier cycle with one addition, which is that the section is framed as workspace mode now being part of the normal flow rather than a separate mode. So the tool converged on a single path: create a workspace, add things, install, sync, generate docs, and periodically audit. ## Two root HTML files and a one-file test suite, none of it published The repository listing and the published file list do not overlap in an interesting way. At the root there are two standalone HTML pages, one named for an atlas and one for the curator view. Neither appears in the file list in the manifest, so neither is in the npm tarball. Both exist only on the repository host, which is where the library statistics block and any curator interface are actually rendered. The tests are a single file at the root, and the test script is a single command running that file with node. There is no test directory and no test framework in the dependency list. The live test scripts are two more commands against a script in the scripts directory, one of which takes a quick flag. The entry point is also one file: the same root file is both the package main and the binary the CLI is invoked through. Implementation lives in two directories, a library directory and a terminal interface directory, and both are published along with the skills folders, the catalog file and one of the three root markdown documents. That last detail is the one to notice. Of the three root documents, the one meant for an agent to read is published, and the two meant for a human curator, the curation guide and the work areas file, are not. Both are still in the repository, and both are referenced by content the readme generates. ## Conclusion Take it if you want a small curated shelf rather than the whole ecosystem, because that is exactly the position the file takes against a larger alternative it names. The design choice that matters is the split between a local folder that ships with the package and a catalog entry that fetches someone else's repository when you install it, and you should know which of the two you are getting for any given skill. Three things to check. The global install target is one vendor's directory by default, so anything genuinely cross-agent needs the project target or an explicit agent flag. Most of the catalog is not vendored, which means an install can pull third-party content you have not read. And the library's own counts are stated twice in the readme with different figures, one of them generated and one hand-written, so trust neither as a live number without running the command. The newest release tag is v4.3.1 while the manifest is at 4.3.2. ## FAQ ### What does ai-agent-skills do? Two things. It ships a curated library of agent skills organised onto shelves, and it provides a command-line tool and a terminal browser for building and managing your own library. A skill is either a local folder that ships with the package and installs offline, or a catalog entry that installs from the upstream repository when you ask for it. ### Where does ai-agent-skills install skills? Two default targets. Globally it installs into a Claude skills directory under your home directory, and per project it installs into an agent-neutral .agents/skills directory. Older agent-specific directories are still reachable through an explicit agent flag, so the per-project default is the universal one and the global default is vendor-specific. ### How do I add a skill to my own library? With the add command, which takes either a bundled pick by name or an upstream reference given as an owner and repository plus a separate skill name. Both forms also take an area, a branch and a why flag holding a sentence explaining why the skill belongs on the shelf, which is how the tool records provenance. ### Do I need to install anything to use ai-agent-skills? No. Every quick start command runs through npx, and the curated library ships inside the package. The manifest declares a Node engine floor of 14.16.0 while its dependencies are React 18, a terminal renderer, a terminal text input component and a YAML parser, so the declared floor sits well below what that stack expects. ## Sources - [License: MIT](https://github.com/MoizIbnYousaf/ai-agent-skills/blob/main/LICENSE) - [MoizIbnYousaf/ai-agent-skills on GitHub](https://github.com/MoizIbnYousaf/ai-agent-skills) - [Project website](https://www.npmjs.com/package/ai-agent-skills) - [README](https://github.com/MoizIbnYousaf/ai-agent-skills/blob/main/README.md) - [Releases](https://github.com/MoizIbnYousaf/ai-agent-skills/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/moizibnyousaf-ai-agent-skills