Skill Gateway Comparison with tech-leads-club/agent-skills

6 min read

What tech-leads-club/agent-skills Is

tech-leads-club/agent-skills (TLC) is an open-source skill registry for AI coding agents. It has approximately 4,500 stars, 57 releases, and a structured catalog of skills across 15 categories. It is a serious, well-engineered system and the closest public prior art to what the Skill Gateway is building.

Key properties:

Skills are SKILL.md files with supporting references and templates the same base format used here
A single skills-registry.json manifest (~45KB) is the central index, distributed via npm CDN
Installation is handled by a CLI (npx @tech-leads-club/agent-skills) that copies skill files into agent-specific config directories (.cursor/rules/, .claude/, etc.)
A .skill-lock.json tracks installed skills with content hashes and timestamps
An MCP server (@tech-leads-club/agent-skills-mcp) exposes the catalog to agents for search and retrieval
Security scanning (Snyk Agent Scan) is run against every skill before publish
The entire codebase is TypeScript, built on an Nx monorepo, with semantic-release for automated versioning

Where the Proposed System Differs

The TLC system combines discovery and installation for a shared public catalog. The comparison below evaluates the proposed system as a whole: the deployed Skill Gateway plus a separate local installation client. The differences reflect the requirements of a private, enterprise, multi-backing-system platform rather than criticisms of TLC’s design for its intended use case.

1. Distribution backing

TLC distributes skills exclusively as npm packages via CDN. The registry index and all skill files are fetched over HTTP from jsDelivr or unpkg. This works for public, npm-hosted skills. It does not support:

Private registries with access control
OCI-native distribution (signed artifacts, content-addressed immutable references, multi-arch layers)
Skills backed by pip, Nix, or WASM
Air-gapped or internally-mirrored environments

The proposed system uses OCI as the primary artifact format, with npm and pip treated as secondary sources. The Skill Gateway indexes those sources and resolves skills to immutable references. A separate installation client fetches from the selected backing system. Any OCI-compatible registry (Harbor, Zot, GHCR, ECR) can store the artifacts, while the Gateway remains the searchable catalog and policy boundary.

2. What `skill.yaml` adds vs TLC’s `skills-registry.json`

TLC’s skills-registry.json is a single flat manifest at the catalog level it lists all skills with their version, content hash, category, and file list. There is no per-skill provenance record written at install time.

The local installation client writes a skill.yaml into each installed skill directory. It combines the Gateway’s resolution and provenance metadata with facts only the client can observe, such as the installation time and runtime version used. This record answers “exactly what was installed, from where, and when” at the per-skill level rather than only at the lock-file level.

The root skill.yaml is also the workspace dependency manifest (analogous to package.json), not just a generated lock file. Teams declare their skill requirements here and commit it to VCS.

3. Separation of agent interface from system metadata

TLC’s SKILL.md contains only agent-facing content instructions, triggers, references. System metadata (version, hash, category, author) lives in the external skills-registry.json.

The proposed skill format formalises this separation with a strict rule: skill.yaml is the place for local installation metadata. SKILL.md is kept clean of anything that is not directly useful to the agent reading it. Capability, backing, and publication metadata live in the Gateway catalog and can be copied into the local record by the installer. This keeps the agent interface stable while system metadata evolves independently.

4. Installation clients and backing adapters

TLC installs skills by copying SKILL.md and supporting files into agent config directories. Skills are all “native” markdown and scripts that the agent reads directly. There is no mechanism for a skill to declare a runtime dependency (e.g. Node, Python) or for the installer to provision it.

The Gateway records where each skill artifact is hosted and which platform variants exist. The local installation client introduces the backing adapters. For example, an npm adapter may run npm install and generate a local wrapper, while a pip adapter may create a virtual environment. The client, not the deployed Gateway, performs host pre-flight checks and any optional Nix wrapping.

5. Bundling

TLC has no bundle concept. Skills are installed individually.

The Skill Gateway catalogs bundles as named, versioned collections of skills. Platform teams publish bundles and product teams pin a bundle version in their root skill.yaml. The installation client resolves and installs the members as a unit, while commands such as skill bundle diff v1 v2 compare the catalog records before an upgrade.

6. Dynamic injection

TLC’s MCP server supports skill search and retrieval for agents that want to read skill content. It does not support runtime installation the agent can read a skill, but installing it into the agent’s active session is a separate manual step.

The Skill Gateway supports dynamic search, description, and resolution through tool calls. Installing and activating the selected skill is a separate operation performed by a local tool or harness integration. Keeping the calls separate makes it clear when an agent moves from read-only discovery to a state-changing local install.

7. Governance layer

TLC’s governance is at the catalog level: Snyk scanning before publish, content hashing for integrity. There is no per-installation policy enforcement, no signing requirement, and no per-agent-identity access control.

The proposed system splits governance across the two boundaries:

the Gateway applies publication, visibility, and per-caller access policy to catalog records
the Gateway returns artifact digests, signature references, and provenance metadata
the installation client verifies signatures and compatibility before install
the local tool or harness records installation and activation events that the remote registry cannot observe by itself

What We Borrow from TLC

The proposed Gateway and installation client adopt the following from TLC’s design:

The SKILL.md format as the agent interface
The skills-registry.json pattern (adapted as the OCI manifest annotations and a gateway-side search index)
The content hash per skill for integrity validation
Per-agent adapter pattern (TLC has adapters for Cursor, Claude Code, Windsurf, etc.) the installation client should similarly generate agent-specific install targets
The MCP server gateway concept for dynamic skill exposure to agents
Skill deprecation tracking (TLC’s deprecated.yaml should have an equivalent in the gateway’s registry metadata)

Summary

Concern	TLC agent-skills	Gateway plus installation client
Distribution backing	npm CDN only	OCI primary, npm/pip/nix/wasm proxy
Registry type	Public, single catalog	Private-first, multi-registry
Per-install provenance	Lock file only	Per-skill `skill.yaml` written by the local client
SKILL.md purity	Clean (no system metadata)	Clean (same rule, enforced)
Runtime dependency handling	None	Pre-flight checks + adapter wrapping
Bundling	No	Yes, OCI-backed versioned bundles
Dynamic use	Read-only via MCP	Gateway discovery followed by a separate local install call
Signing / verification	None	Gateway supplies provenance; client verifies artifacts
Access control	None	Gateway policy for catalog access; host policy for installation