The Purge

Last month I mass-deleted 165 Claude Code skills. My productivity went up.

I’d accumulated 30 plugins, ~245 registered skills, and Claude was drowning in them. Responses were sluggish. Instructions contradicted each other. Three different systems told it to “always run tests” — each with subtly different wording. The model didn’t know which one was authoritative, so it tried to satisfy all of them and satisfied none.

The fix wasn’t adding better skills. It was removing most of them. I cut 67% of my skills, dropped from 27 active plugins to 13, and watched everything get faster and sharper overnight.

Why did this work? Because skills aren’t features you bolt on. They’re identity. And identity works best when it’s coherent.

The Dotfiles Parallel

Rob Pike documented in 2012 that dotfiles were an accident. Ken Thompson’s ls implementation in Unix v2 had a too-short check — it hid all files starting with . instead of just . and ... Nobody planned this. The single most enduring convention in Unix configuration was a bug.

Zach Holman wrote “Dotfiles Are Meant to Be Forked” in 2010, and that essay kicked off an entire culture. Developers started sharing their configurations on GitHub. mathiasbynens/dotfiles has 31.1K stars. There are entire communities built around the idea that your config files say something about you as a developer.

The progression matters here: .bashrc defines your shell. .vimrc defines your editor. .gitconfig defines your workflow. Each layer moved closer to encoding not just preferences, but values — how you think software should be built.

SKILL.md is the next step in that progression. It doesn’t configure an environment. It defines an epistemology. Your dotfiles tell a machine how to behave. Your skills tell an AI how to reason.

That’s the leap. From environment variables to epistemology.

What Skills Actually Are

I covered the basics in my earlier post on Claude Code skills. What I didn’t understand then is that skills are less like plugins and more like a personal engineering manifesto.

The architecture is what makes them interesting. Skills use a meta-tool design — the Skill tool is a dispatcher, not an executor. When Claude encounters a task, it reads the description fields of all loaded skills and decides which ones are relevant. There’s no regex matching, no intent classification. Discovery runs on pure LLM reasoning.

Each skill is a SKILL.md file with YAML frontmatter: name, description, trigger patterns. That description field is the routing logic. Claude reads it and makes a judgment call. This means a well-written description is the difference between a skill that fires at the right moment and one that either never triggers or triggers constantly.

Since v2.1.0 (January 2026), skills hot-reload. You edit the markdown, Claude picks up the changes immediately. No restart, no rebuild. You iterate on skills like code, not like config files that need a process restart.

Skills live in .claude/skills/ or come bundled with plugins. They’re loaded into the tools array, not the system prompt. This distinction matters — they don’t eat your context window passively. They only cost tokens when Claude decides to invoke them.

My Stack: Before and After

This is the real story. Numbers first, narrative second.

Before the purge:

  • 30 plugins installed, 27 active
  • ~245 registered skills
  • ~91,500 infrastructure tokens per session
  • Hook latency: 1-5 seconds per tool call (npx checking the npm registry on every invocation)
  • CLAUDE.md: ~1,800 tokens
  • Two copies of Superpowers installed — the official v5.0.6 AND the marketplace v5.0.1
  • The “Everything Claude Code” plugin alone contributed 48 skills
  • Duplicated rules across CLAUDE.md, CARL domains, and Hookify configs all saying the same things in slightly different words

Claude was spending 73% of its context window on infrastructure before I typed a single word. That’s not a tool. That’s bureaucracy.

The duplicate Superpowers installation was the most absurd find. Two versions of the same plugin, both active, both injecting their own copies of TDD, Verification, and Brainstorming skills. Claude would sometimes invoke one version’s TDD skill and sometimes the other, producing inconsistent behavior that took me weeks to notice.

After the purge:

  • 13 plugins active (-55%)
  • ~80 skills (-67%)
  • ~25,000 tokens per session (-73%)
  • Hook latency: ~50ms (-95%) — replaced all npx calls with local scripts
  • CLAUDE.md: ~650 tokens (-64%)

Here’s the truncated before/after of my settings.json plugins:

// Before: 27 active plugins
{
  "plugins": {
    "superpowers": true,
    "superpowers-marketplace": true,  // duplicate!
    "everything-claude-code": true,   // 48 skills alone
    "voltagent-biz": true,
    "voltagent-core-dev": true,
    "voltagent-qa-sec": true,
    "voltagent-research": true,
    "hookify": true,
    // ... 19 more
  }
}

// After: 13 active plugins
{
  "plugins": {
    "superpowers": true,
    "vercel": true,
    "figma": true,
    "obsidian": true,
    "episodic-memory": true,
    "frontend-design": true,
    "supabase": true,
    "claude-md-management": true,
    "skill-creator": true,
    "playwright": true,
    "claude-hud": true,
    "codex": true
  }
}

Each surviving plugin earned its place. Superpowers stays because TDD, Verification, and Brainstorming encode workflow discipline I actually use. Vercel stays because I deploy there. Figma stays because I design there. Everything else either duplicated functionality, added skills I never triggered, or consumed tokens for capabilities I didn’t need.

Every dotfiles veteran learns this lesson the same way: the best .vimrc is the one where every line exists for a reason, not the one with the most plugins. The same rule applies to skills. Superpowers does not make Claude smarter; it makes Claude systematic. The TDD skill forces red-green-refactor. The verification skill forces evidence before success claims. The brainstorming skill prevents jumping straight to code. The value is discipline encoded at the configuration layer, not additional features bolted on top.

The Identity Layer

When you add export EDITOR=vim to your .bashrc, you’re saying something about yourself. It’s a small statement, but it’s real. You chose vim. That choice reflects your values — minimalism, keyboard-driven workflows, maybe a tolerance for steep learning curves.

enforce: always write tests first says more. It’s not a tool preference. It’s an engineering conviction, encoded in a format that an AI can execute. Your skill set is a manifest of what you believe good software looks like.

The Superpowers skills I kept — TDD, Verification, Brainstorming — define an engineering style, not Claude’s capabilities. Claude can write tests without a TDD skill. But without it, Claude writes the implementation first and the tests second. The skill doesn’t add a capability. It enforces a value.

That’s what makes this an identity layer. Not “what can my AI do?” but “what does my AI refuse to skip?”

SKILL.md is becoming a cross-agent standard, too. Cursor reads skills. Codex CLI supports them. Gemini CLI has adopted similar patterns. Your skill set is becoming portable across AI tools — the same way your .bashrc works in any terminal emulator. The specific AI doesn’t matter. Your engineering identity carries over.

The community reflects this. awesome-claude-skills has grown past 10k stars. obra/superpowers (14 skills in the current 5.0.x release) is in the official Anthropic marketplace, and specialized skills like frontend-design have six-figure install counts. Developers aren’t sharing utility functions. They’re sharing how they think about engineering. When you fork someone’s skill set, you’re copying a philosophy more than a config.

How to Build Your Own

Don’t start by browsing the marketplace. Start by paying attention to what you correct.

Every time you tell Claude “no, run the tests first” or “don’t mock the database, use a test container” or “ask me clarifying questions before you start a large refactor” — that’s a skill waiting to be written. The pattern is simple: if you’ve corrected Claude three times about the same thing, it’s a skill.

Here’s what a good one looks like:

---
name: my-review-checklist
description: Use when completing a feature — runs through security, testing, and documentation checks before marking work as done
---

Before claiming any feature is complete:
1. Run the test suite. Show the output.
2. Check for hardcoded secrets or credentials.
3. Verify error handling covers the unhappy path.
4. Confirm the change works in both light and dark mode.

Two things matter here. The body is straightforward — it’s just instructions, written the same way you’d explain your process to a colleague. The description field is the part that requires thought. It’s how Claude decides whether to activate the skill. Too broad (“use for any task”) and it fires on every message, burning tokens and annoying you with checklists when you asked a simple question. Too narrow (“use only for Python FastAPI endpoints with SQLAlchemy models”) and it never fires when you need it.

The sweet spot is a description that matches the moment you’d naturally invoke the behavior. “Use when completing a feature” is good — it triggers at the right phase of work, not too early and not too late.

Anti-patterns from my 245-skill era: skills that duplicate other skills with slightly different wording. Skills with overlapping triggers fighting for priority — two different “run tests before completing” skills firing on the same message. Skills that restate what CLAUDE.md already says, so the same instruction appears three times in context with three different phrasings. Claude doesn’t get more obedient when you repeat yourself. It gets confused.

The consolidation rule: if you’ve written the same instruction in CLAUDE.md, a CARL domain, AND a hook — you have three copies of one rule. Pick the right mechanism for it (skill for workflow guidance, hook for automated enforcement, CLAUDE.md for project-wide context) and delete the other two. I wrote about hooks in my post on Claude Code hooks — the key insight is that hooks and skills solve different problems. Hooks automate. Skills guide. Don’t use one where you need the other.

Curate Like You Mean It

Fork my skills, not my code. Though honestly, the code is the less interesting part of any project these days.

The best AI workflow configuration says more about the developer than the language they write in. Your SKILL.md files are a mirror — they show what you believe good engineering looks like, encoded in a format that machines can follow. They’re your dotfiles for the AI age, carrying the same accidental-turned-essential quality that Rob Pike’s bug gave us fifty years ago.

Skills are the new dotfiles. Once your count crosses fifty, budget an hour a month on deletion — mine hit 245 because I never did.