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

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 Skill Gateway Differs

The TLC system solves the discovery and installation problem well for a shared public catalog. The differences below 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 Skill Gateway uses OCI as the primary distribution format, with npm and pip treated as secondary backing systems that the gateway proxies. Any OCI-compatible registry (Harbor, Zot, GHCR, ECR) can serve as the backend. Private registry support is a first-class concern, not an afterthought.

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 Skill Gateway writes a skill.yaml into each installed skill directory at install time. This records the full provenance: exact source registry, immutable digest, signature reference, the specific runtime version that was used (e.g. node_version_used: "20.11.0"), and bundle membership. This is the audit record it answers “exactly what was installed, from where, and when” at the per-skill level rather than just 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 Skill Gateway formalises this separation with a strict rule: skill.yaml is the only place for system metadata. SKILL.md is kept clean of anything that is not directly useful to the agent reading it. No capability tags, no backing metadata, no install fields in SKILL.md. This means the agent interface contract is stable and the system metadata can evolve independently.

4. Multi-backing-system install and wrapping

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 Skill Gateway introduces backing adapters. An npm-backed skill is installed by running npm install into .skills/<name>/.npm/, then generating a thin wrapper in scripts/ that delegates to the installed package. The agent sees the same SKILL.md interface regardless. The gateway handles pre-flight checks (is Node installed? what version?) before attempting install, and can optionally wrap the skill in a Nix shell for hermetic reproducibility.

5. Bundling

TLC has no bundle concept. Skills are installed individually.

The Skill Gateway supports bundles: named, versioned collections of skills published as OCI artifacts and installable as a single unit. Bundles are the enterprise primitive platform teams publish bundles, product teams pin a bundle version in their root skill.yaml. Upgrading a bundle upgrades all member skills atomically. skill bundle diff v1 v2 shows exactly what changed.

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’s dynamic injection path allows a running agent to request, install, and activate a skill within the current session via MCP, without restarting. This is a requirement for open-ended orchestration where capability requirements are determined at task time rather than at startup.

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 Skill Gateway adds:

Cosign/Sigstore-based signing for OCI skills
Pre-flight verification of signatures before install
A policy engine that controls which registries and skill sources are allowed per agent identity
Audit logging of every install and activation event

What We Borrow from TLC

The Skill Gateway adopts the following directly from TLC’s design, which is well-validated at scale:

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 gateway 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	Skill Gateway
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 at install
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 runtime injection	Read-only via MCP	Full install + activate via MCP
Signing / verification	None	Cosign/Sigstore for OCI skills
Access control	None	Per-agent-identity policy engine