The Claude Code "Skill Rot" Problem Nobody Talks About

You wrote a /test slash command three months ago. It was perfect. It ran your project's weird test setup, parsed the output, surfaced only the failing assertions, and re-ran flaky tests twice before reporting failure.

Then you started a new project. You copied the /test command over. It mostly worked, so you tweaked it a bit for the new repo. Then your testing framework changed. Then a colleague tweaked it again without telling you. Six months later you're looking at four slightly different versions of "the same" /test command across four repos and none of them are as good as the one you originally wrote.

This is skill rot, and it is the single most under-discussed problem in Claude Code workflows.

Why your skills rot

The default way most of us store Claude Code skills is as loose files in .claude/skills/ inside each project repo. This has four failure modes:

1. Copy divergence. The moment you copy a skill to a new project, the two versions start diverging. A year later you have no idea which one is "canonical."

2. 2. No versioning. When you improve /test in project A, project B doesn't automatically benefit. And when project A's copy regresses, you have no way to roll back to the last known-good version.

3. 3. No discovery. Your teammate wrote a brilliant /review skill last week. You have no idea it exists unless you happen to be staring at her repo at the right moment.

4. 4. No trust signal. Random skill dump on someone's GitHub? Great, but does it actually work? Has it been tested against real Claude Code versions? You're flying blind.

Every engineering team I've talked to has independently reinvented the same /test, /commit, /review, /refactor skills. It's a massive coordination failure.

The npm analogy (again, sorry)

npm solved this for JavaScript. You don't copy lodash into your repo; you install it. You don't re-implement a date picker; you npm install one. Package registries give you:

• A canonical version of each package

• - Versioning and changelogs

• - Discovery npm search)

• - Trust signals (download counts, stars, audits)

• - Dependency resolution

Claude Code skills should have the same shape. A skill is just code + conventions, exactly like a package. It should be installable, versioned, discoverable, and auditable.

This is why I'm building tokrepo.com — an open-source registry for Claude Code skills, slash commands, and MCP configs. You publish a skill once. Anyone can install it into their project with a single command. Versions are pinned. Updates are opt-in. Trust signals are built in (stars, install counts, maintainer verification).

What "good" looks like

Here's the workflow I'm pushing for:

# Browse the registry
tokrepo search test

# Install a skill
tokrepo install @ethanfrost/test-runner

# Skill lands in .claude/skills/ automatically
# Upgrades are explicit:
tokrepo upgrade @ethanfrost/test-runner
```

Three properties this gives you:

- **Project-portable.** Moving to a new repo? `tokrepo install` your stack in 30 seconds.
- **Team-shareable.** Your teammate built something great? It's one command away.
- **Version-pinned.** Know exactly which version of `/review` is running in CI.

## What this isn't

It isn't a replacement for persistent memory tools like RecallNest or session-roam. Those solve "resume this exact investigation across machines." A registry solves "onboard a fresh session to my conventions without re-prompting them." Both layers are useful, and they compose well: use memory for facts, use the registry for skills.

It also isn't a gist dump. A gist dump is "here are my files, copy them." A registry is "here is a canonical, versioned, installable artifact with trust signals attached." The difference matters once you try to scale past one developer.

## The meta point

A lot of Claude Code productivity discussions focus on the model itself — context window size, planning quality, harness design. But the compounding wins come from the layer above the model: the skills, the conventions, the shared institutional knowledge. That's the layer that doesn't magically get better when Anthropic ships a new version.

Stop rebuilding from scratch. Start treating your Claude Code workflow like a package ecosystem, because that's what it already wants to be.

---

If you have a skill you think other people would use, I'd love to see it on tokrepo.com. And if you've hit skill rot in your own workflow, I'd love to hear how you've been hacking around it — reply or DM and let me know.