One Agent Skill, Three Registries: PyPI, Claude, and skills.sh

Agent skills are turning into a distribution layer for developer tools.

That sounds abstract until you build one.

A year ago, the normal path for an AI developer tool was simple: ship a package, write docs, hope people paste the right snippet into their agent. Now there is a second surface. The agent itself can install instructions, scripts, examples, and operating rules.

That changes how small tools should be packaged.

The best shape is not three separate products. It is one source with three doors:

1. PyPI for Python users.
2. A Claude-style SKILL.md for agent users.
3. skills.sh for discovery and install stats.

AgentGuard is the worked example I care about. It is a Python package first. The job is runtime cost control: budget caps, rate limits, and kill switches for AI agents. The natural install path is still pip install agentguard47.

But a lot of the value is procedural. When should an agent add a budget cap? What counts as a dangerous retry loop? How should a coding agent test that the guard actually fired? That knowledge belongs in a skill.

PyPI is the runtime door

PyPI is where the code lives.

If your tool has a real library, CLI, or runtime dependency, publish it there first. That gives builders a normal install path, normal versioning, and normal CI behavior.

For AgentGuard, PyPI is the source of truth because the useful part runs inside code. The agent cannot merely read a warning about budget caps. It needs a package that can enforce them.

This matters for cost-control tools in particular. A blog post about cost is not a guardrail. A README is not a kill switch. A package in the runtime path can actually stop work.

I wrote more about that in AI agent cost control with AgentGuard and what AI agents cost in production.

SKILL.md is the agent door

A skill is where the operating procedure lives.

The file should tell an agent when to use the tool, how to install it, how to verify it, and what failure looks like. Keep it concrete. Agents do better with commands and checks than with vibes.

For AgentGuard, that means a skill should answer questions like:

• Before adding an LLM loop, decide the max spend per run.
• Wrap model calls with a budget cap.
• Add a test that proves the cap stops the run.
• Treat a passing command as weak evidence unless the trace shows enforcement.

That last line matters. A lot of AI safety tooling looks fine in a demo and does nothing in the real path. The skill should force proof.

This is the same reason MCP needs boring operational checks. Agent integrations are easy to announce and easy to fake. The only proof is behavior.

skills.sh is the discovery door

Vercel's skills.sh made the directory piece visible.

The important part is not the leaderboard. The important part is that skills can now be found, installed, and compared through a shared directory. Vercel's docs show npx skills add <owner/repo> as the install path and describe support across many agent tools.

That means a small open-source tool can show up where agents are looking, not just where humans search.

For a tool like AgentGuard, that is the right kind of distribution. A developer may not search for "AI agent budget limiter" until after the bill hurts. An agent working on a risky loop can be instructed to look for a budget-control skill before it ships the loop.

That is a better moment.

The packaging rule

Do not maintain three stories.

Keep one source. The package docs, SKILL.md, examples, and site copy should all say the same thing in different levels of detail.

The Python README explains the API. The skill explains agent behavior. The blog explains why the behavior matters. The product page gives the next step.

That is enough.

For AgentGuard, the next step is still simple: install it, wrap the dangerous path, and prove the cap trips before production does.

Build it safely with AgentGuard: https://bmdpat.com/tools/agentguard