Agent Skills Registry: How Tech Leads Club Built a Validated Skill Marketplace to Solve the 13% Vulnerability Problem

Snyk’s recent scan found that 13% of agent marketplace skills contain critical vulnerabilities. Tech Leads Club’s Agent Skills registry responds with a curated, validated distribution layer that treats skill installation as a supply-chain security problem. The project (6,262 stars, trending #7 in TypeScript) positions itself as hardened infrastructure for Antigravity, Claude Code, Cursor, and Copilot integrations via the Model Context Protocol.

This is not a marketplace. It is a gatekeeper that enforces validation before skills reach production environments.

The Supply-Chain Problem

Agent skills are executable code that runs in your development environment with access to filesystems, network calls, and secrets. Marketplace models optimize for discovery and volume. Agent Skills optimizes for trust boundaries.

The registry enforces:

• Immutable plugin names: Once published, a skill name cannot be reused. Renames require a migration map that explicitly tracks the lineage.
• Semantic versioning: Breaking changes must increment the major version. Agents can pin to specific ranges.
• Pre-deployment validation: Skills pass linting, type checks, and security scans before they enter the registry.
• MCP integration: Skills expose capabilities through the Model Context Protocol, which standardizes tool discovery and invocation across agent platforms.

The architecture assumes that skill authors are not always security-conscious and that agents will auto-update dependencies without human review.

Validation Pipeline Architecture

The registry uses a multi-stage validation flow:

1. Submission: Author pushes skill to a staging branch.
2. Automated checks: GitHub Actions run ESLint, TypeScript strict mode, and dependency audits.
3. Manual review: Maintainers inspect the skill for privilege escalation patterns, hardcoded secrets, or unsafe file operations.
4. Publication: Approved skills merge to main and publish to npm under the @tech-leads-club/agent-skills scope.
5. Immutable record: The skill name and version become permanent. Updates require new versions.

The pipeline rejects skills that:

• Access environment variables without explicit user consent prompts
• Execute shell commands with unsanitized input
• Make network requests to non-allowlisted domains
• Read or write files outside declared working directories

The Strict Mode Trade-Off

The registry supports two integration modes:

Mode	TypeScript Strict	Validation Depth	Use Case
Registry	strict: true	Full pre-deployment checks	Production agents, enterprise environments
Skill Bundle	strict: false	Runtime-only checks	Rapid prototyping, internal tools

The skill-bundle plugin pattern allows teams to bypass the registry for internal skills. This mode disables immutable naming and semantic versioning but maintains runtime sandboxing. It is a deliberate escape hatch for organizations that want to manage their own validation.

The trade-off: speed vs. auditability. Skill bundles let you ship faster but lose the cryptographic proof that a skill passed central validation.

MCP Integration Layer

Agent Skills exposes capabilities through MCP servers. Each skill declares:

• Tools: Functions the agent can invoke (e.g., git_commit, run_tests)
• Resources: Data the agent can read (e.g., file://project/README.md)
• Prompts: Pre-built instruction templates (e.g., “refactor this function for readability”)

The MCP server handles:

• Discovery: Agents query available tools at runtime.
• Invocation: Agents call tools with typed parameters.
• Streaming: Long-running operations (e.g., test suites) stream progress updates.
• Error boundaries: Tool failures return structured errors instead of crashing the agent.

Here is a minimal skill definition:

import { Skill, Tool } from '@tech-leads-club/agent-skills';

export const gitCommitSkill: Skill = {
  name: 'git-commit',
  version: '1.0.0',
  tools: [
    {
      name: 'commit',
      description: 'Stage and commit changes with a message',
      parameters: {
        type: 'object',
        properties: {
          message: { type: 'string' },
          files: { type: 'array', items: { type: 'string' } }
        },
        required: ['message']
      },
      handler: async ({ message, files = ['.'] }) => {
        // Validation: prevent command injection
        if (!/^[a-zA-Z0-9\s\-_.,!?]+$/.test(message)) {
          throw new Error('Invalid commit message format');
        }
        
        // Execute with sanitized input
        await exec(`git add ${files.join(' ')}`);
        await exec(`git commit -m "${message}"`);
        
        return { success: true, sha: await getHeadSha() };
      }
    }
  ]
};

The registry rejects this skill if exec is not a sandboxed wrapper or if files can escape the working directory.

Semantic Versioning as a Security Control

The registry enforces semver to prevent silent breaking changes. Agents declare version ranges in their configuration:

{
  "skills": {
    "git-commit": "^1.0.0",
    "run-tests": "~2.3.0"
  }
}

When a skill author changes the tool signature (e.g., adds a required parameter), the registry forces a major version bump. Agents that pinned to ^1.0.0 will not auto-update to 2.0.0 without explicit configuration changes.

This prevents the scenario where an agent silently adopts a skill update that breaks its orchestration flow or introduces new privilege requirements.

Immutable Naming and Migration Maps

Once a skill name is published, it cannot be reused. If an author wants to rename git-commit to git-operations, they must:

1. Publish git-operations as a new skill.
2. Submit a migration map to the registry:

{
  "migrations": {
    "git-commit": {
      "deprecated": true,
      "replacement": "git-operations",
      "reason": "Expanded scope to include rebase and cherry-pick"
    }
  }
}

Agents that reference git-commit receive a deprecation warning with the replacement path. The old skill remains available but stops receiving updates.

This prevents supply-chain attacks where an attacker registers a popular skill name after the original author abandons it.

Observability and Failure Modes

The registry does not provide runtime telemetry. Observability is the agent’s responsibility. Skills should:

• Return structured errors with error codes.
• Log to stdout/stderr in a parseable format (e.g., JSON lines).
• Expose health checks for long-running operations.

Common failure modes:

• Version mismatch: Agent expects a tool that was removed in a major version bump. The MCP server returns a ToolNotFound error.
• Permission denied: Skill tries to access a file outside its declared working directory. The sandbox kills the process.
• Network timeout: Skill makes an external API call that hangs. The agent’s timeout wrapper cancels the operation.
• Malicious update: An attacker compromises a skill author’s npm account and publishes a backdoored version. The immutable name constraint and semver pinning limit blast radius to agents that explicitly upgrade.

Deployment Shape

The registry is a monorepo managed with Nx. Each skill is a separate package under packages/skills/. The build pipeline:

1. Runs type checks and linters in parallel using Nx’s task graph.
2. Publishes each skill as an independent npm package.
3. Updates the central registry manifest (a JSON file listing all skills, versions, and metadata).
4. Deploys the MCP server as a Docker container or serverless function.

Agents install skills via npm:

npm install @tech-leads-club/agent-skills

Or reference them in an MCP configuration file:

{
  "mcpServers": {
    "agent-skills": {
      "command": "npx",
      "args": ["@tech-leads-club/agent-skills", "serve"],
      "env": {
        "SKILLS": "git-commit,run-tests"
      }
    }
  }
}

The MCP server loads only the requested skills, reducing attack surface.

When Validation Becomes a Bottleneck

The manual review step introduces latency. Skills can wait days for approval. This works for a curated registry but breaks down at scale. The project acknowledges this with the skill-bundle escape hatch.

Organizations with high skill velocity should:

• Run their own registry fork with automated-only validation.
• Use skill bundles for internal tools.
• Contribute back to the public registry only for widely reusable skills.

The registry is not designed for rapid iteration. It is designed for trust.

Technical Verdict

Use Agent Skills when:

• You need provably safe skills for production agents.
• You want to avoid the 13% vulnerability rate of open marketplaces.
• You can tolerate the approval latency for new skills.
• You need MCP integration with Antigravity, Claude Code, Cursor, or Copilot.

Avoid it when:

• You need to ship custom skills daily.
• You have internal validation infrastructure that exceeds the registry’s checks.
• You need skills that the registry’s security model prohibits (e.g., unrestricted shell access).
• You want a marketplace with thousands of skills instead of a curated set.

The registry solves the supply-chain problem by accepting lower skill volume in exchange for higher trust. It is infrastructure for teams that treat agent capabilities as privileged code, not plugins.

Source Links

• Agent Skills Registry
• Snyk Agent Skills Vulnerability Report