agent-skills: a curated skill registry for AI coding agents, and what its lockfile model implies

The problem is prompt content with no provenance, not missing agent features

AI coding agents accept instruction files from anywhere. A developer copies a SKILL.md or a rules directory out of a blog post, drops it into the project, and the agent now follows text that nobody reviewed. The README cites a Snyk report claiming that over 13% of marketplace skills contain critical vulnerabilities, and repeats the figure as 13.4% in the security section. Treat that number as the project's own framing rather than an independently verified statistic, but the underlying concern is real: an instruction file is executable influence over an agent that can read your source tree and run commands.

agent-skills positions itself against that. The pitch is a managed library rather than an open marketplace: human-curated prompts, no binaries, static analysis in CI, and Snyk Agent Scan (formerly mcp-scan) run before publishing. The audience is a team already standardising on one or more agents and wanting the extension layer to be reviewable. It is not aimed at someone who wants to write their own skills; the catalog is the product, and the CLI is the delivery mechanism.

Skills are directories of Markdown, and the catalog is the unit of distribution

The README gives the layout directly. Under packages/skills-catalog/skills/ there is a category-name directory, then a skill directory containing SKILL.md as the main instruction file, a templates/ directory for file templates, and a references/ directory for on-demand documentation. The split between SKILL.md and references/ matters: the main file is what the agent loads by default, and the reference material is pulled in only when needed. That keeps the always-resident context small, which is the same constraint every agent vendor is working against.

The repository is TypeScript throughout, built on Nx, and releases are cut with semantic-release. Version tags follow a skills-catalog-v prefix (skills-catalog-v0.17.8 is the most recent listed), which tells you the catalog and the CLI are versioned together rather than independently. The package is published to npm as @tech-leads-club/agent-skills, and the README badges reference Node >=22. The README also mentions an MCP server section, so there is a second access path beyond the CLI, though the truncated README does not show its configuration.

The security story rests on hashing and an atomic lockfile

This is the part worth reading closely. The README claims four things about the CLI: sanitization, path isolation, symlink guards, and an atomic lockfile, plus an audit trail. It also claims immutable integrity through lockfiles and content hashing. What the README does not do is show the hash algorithm, the lockfile name, or the lockfile schema. So the mechanism is asserted, not documented in the material available.

That gap is the honest limitation. A lockfile only provides integrity if you commit it and if the tool refuses to install on a hash mismatch. Neither behaviour is stated. Path isolation and symlink guards are described as defense-in-depth measures, which suggests the CLI writes into agent configuration directories that may sit outside the project, and that the authors anticipated path traversal in skill metadata. The right move before trusting any of this is to read SECURITY.md, which the README links as the place where the full threat model and vulnerability reporting process live.

One claim is verifiable from the repository structure alone: 100% open source with no binaries. Since the catalog is Markdown and the tooling is TypeScript, you can read every instruction the agent will receive. That is a genuine advantage over a marketplace that ships opaque bundles, and it does not depend on trusting the maintainers.

Getting it running: what the README shows and what it does not

The README does not include a Quick Start command block in the material provided. It has a Quick Start section heading in the table of contents, and the npm package name is @tech-leads-club/agent-skills, so the entry point is an npm invocation against that package, but the exact subcommand and flags are not visible here. Anyone evaluating this should run the package's help output before anything else and read it against the supported-agents table.

What you can plan around is the shape of the workflow. The tool installs skills into a chosen agent, and the supported list is split into three tiers: Tier 1 covers Claude Code, Cline, Cursor, GitHub Copilot and Windsurf; Tier 2 covers Aider, Antigravity, Gemini CLI, Kilo Code, Kiro, OpenAI Codex, Roo Code and TRAE; Tier 3 covers Amazon Q, Augment, Droid, OpenCode, Sourcegraph Cody and Tabnine. Each of those agents stores its instruction files in a different location and format, so the CLI is doing per-agent translation. That translation layer is where most of the maintenance burden will land, because agent vendors move their config paths without warning.

The README invites issues for missing agents, which confirms the list is maintained by hand rather than discovered. If your agent is not in the table, you are waiting on a pull request.

Where this is the wrong tool

If your team writes its own instructions, this adds a dependency without adding content. The catalog is curated, and curation means someone else decides which workflows are worth packaging. A team with strong internal conventions will find the registry's value is mostly in the lockfile and audit trail, not the skills.

The second failure mode is version coupling. Releases are tagged skills-catalog-v0.17.x and the cadence in the supplied data is fast: three releases across two days in September 2026. If the catalog and the CLI share a version line, a skill update can pull a CLI update, and a CLI update can change install paths across sixteen agents. Pin the version in your package manifest rather than tracking latest, and treat catalog bumps as something to review rather than absorb. The README does not describe a compatibility matrix between CLI versions and agent versions, so that review is manual.

The third case is licensing. The repository metadata reports NOASSERTION, meaning GitHub could not map the licence file to a known identifier, and the README's licence section is titled License and Attribution without showing terms in the material provided. Until you read the actual file, you cannot assume permissive terms. For internal use that may be tolerable; for redistribution or for embedding in a product, it is a blocker.

How it differs from writing your own agent rules directory

The obvious alternative is the one most teams already use: a checked-in rules directory, hand-written, one per agent, maintained in the repository. That approach has no dependency, no version skew, and no third-party content. It also has no scanning, no hashing, and no way to tell whether the rules file a contractor added last month was modified after review.

The difference in approach is that agent-skills treats skill content as a supply-chain artifact rather than as source code. Content hashing plus a lockfile is the same pattern package managers use, applied to Markdown. A hand-maintained rules directory has no equivalent, because git history is the only integrity record and it does not detect a skill that was edited in place outside the repository.

If you want a middle path, keep your own rules for project-specific conventions and use the registry only for generic workflows. The two are not mutually exclusive, and the per-agent translation layer is the piece that is genuinely tedious to write yourself across sixteen targets.

Maintenance cost and the licence question

Running costs are mostly upgrade review. The catalog moves quickly, the CLI is Nx-built with semantic-release, and each release can touch install paths for agents you may not use. Budget for reading changelogs before bumping the pinned version.

The heavier cost is upstream: every agent vendor that changes its config directory forces a change in this repository. That is a maintenance treadmill the maintainers have taken on, and it is the reason the supported-agents list is tiered rather than flat. Tier 3 agents are likely to lag.

On licensing, the honest statement is that this review cannot tell you the terms. The metadata says NOASSERTION and the README points to a License and Attribution section without stating terms in the material available. Read the licence file and the attribution section before you depend on it, and if your organisation has a policy against unclassified licences, treat that as an open item rather than a formality. Nothing here is legal advice; it is a flag that the information is missing.

Editorial conclusion

Adopt this if you already run Claude Code, Cursor or Copilot on a shared team codebase and you need an auditable record of which third-party prompt content entered the repository. Do not adopt it if you need a permissive, clearly stated licence before shipping, or if you expect a documented CLI reference: the README shows the directory layout but not the install flags. Verify three things first: the actual licence text in the repository, the CLI's --help output, and whether the lockfile lands in version control or in a local cache.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tech-leads-club/agent-skills on GitHub