We Deleted 52 Claude Code Skills in Three Months
AI made it nearly free to add tooling to our company brain, so in March 2026 we added it fast. Between March and May we deleted 52 commands, skills and agents. The one we actually missed came back in June, rewritten for a real project instead of an imagined one, and it’s better for having been deleted. If your own .claude/ folder is crowded, the rules we use now are under how we decide what to delete.
Some background on what “tooling” means here. Our company runs out of one git repo. Inside it, a folder of Claude Code commands, skills and agents does the repeatable work: turning call notes into proposals, writing weekly client updates, processing each founder’s email and meetings every evening. Think of them as the company’s standard operating procedures, except they execute. (Claude Code has merged custom commands into skills, so a file in either folder gives you the same /command. We still keep both folders, and the counts below include both, plus agents. The cheat sheet covers the mechanics of writing them.)
How the pile grew
On March 1 the repo had 41 commands, skills and agents. By April 1 it had 103.
Some of that was consolidation. We had separate tooling folders per department, and on March 6 we merged them into one root folder. But a lot of it was enthusiasm. Every time someone did a task twice, it became a command. Every time a command needed background knowledge, that became a skill. Claude drafts a new one in minutes, and that speed is exactly the problem. Nobody stops to ask whether a thing that cheap should exist at all.
The cost shows up later. Each command is a promise that the procedure still matches how the company works. When the company changes and the command doesn’t, it keeps confidently running last quarter’s process.
The first cuts were duplicates
The week we consolidated, we found two sales agents that checked documents for consistency in slightly different ways, plus three skills whose rules overlapped with our main estimation skill. One of those existed only to stop the AI from estimating too early. All five got folded into the tools that actually ran. We also deleted vendored copies of document-format skills that had been pasted into one department’s folder.
Duplicates are the easy deletions. Two tools that do almost the same thing guarantee that someone uses the wrong one, and the AI picks between them by description (Anthropic’s docs say the description field is what helps Claude decide when to load a skill), which is not a great way to choose a sales process.
One-off tasks lost to rhythms
On April 2 we deleted 12 marketing commands: ad research, scraping, batch content creation, a handful of research checks. Each had been written for a task someone expected to repeat. By the time we deleted them, most were dead weight.
They were replaced by four commands built around a weekly cadence (analyze, plan, create, review) plus one monthly intelligence pass. Same underlying work, organized around when it happens instead of what it is.
This pattern repeated across the company. Tooling attached to a rhythm gets used, because the rhythm brings people back to it every week. Tooling attached to a task waits for someone to remember it exists, and nobody does.
The PM purge
The biggest single cut came on May 1. We deleted 12 project management commands at once: kickoff prep, definition of done, scope changes, midpoint review, close project, retrospective, offboarding, upsell proposals and a few more. We also deleted a milestone email skill with 23 templates and 13 reusable blocks.
Only the weekly client update survived (how it works now).
Deleting them stung a little. But they described a project management process we had designed and then mostly didn’t follow. Kickoffs happened in a call, scope changes happened in an email thread, and none of it routed through the commands. Keeping them meant keeping a fictional process on record, and the AI would read it as instructions.
Two weeks later we retired a hand-curated list of active projects and the 673-line script that audited it, because Notion had become the real source of truth. Two lists of active projects means two answers to “what are we working on,” and the AI will cheerfully use whichever one it finds first.
What came back
The retrospective came back in June.
The old version was 48 lines. It read the project docs, asked a founder for actual hours, and filled in a template. It was written before we had closed many projects through the new system.
On June 6, the same day we archived a closed engagement, we rebuilt project close as two separate commands. One is an internal retrospective: what we learned, which features are reusable, what to flag after close, how to offboard access. The other is a client-facing engagement review with a PDF, a pre-read email, a feedback survey and a follow-up schedule out to 90 days. Together they ran about 330 lines on October 8, and they get used because they were written against a real close. Both are part of the project management kit we run today.
That’s the main reason I don’t regret any of the deletions. A deleted command costs almost nothing to rebuild, and the rebuild starts from an actual event instead of a guess about one.
Making the deletions stick
Deleting files is easy. Keeping the repo from silting back up takes enforcement, because the AI will happily create a new file anywhere that seems reasonable to it.
In June we wrote the repo’s structure down as a schema and backed it with three layers. A PreToolUse hook runs before every file write and flags paths the schema doesn’t recognize. Claude Code lets a hook like that block the write outright, and ours was supposed to start blocking after a two-week trial. It still only warns, as of late October. A nightly janitor scans everything, regenerates the folder indexes, and auto-moves a misplaced file only when the move is zero-risk: one unambiguous destination, committed, untouched for 48 hours, and nothing else linking to it. Anything riskier goes to a maintenance command where a human approves it.
The janitor’s July 8 run found 218 issues and moved zero files. It flagged 24 for a human. We wanted that ratio. A janitor that moves things aggressively would break links faster than it fixes clutter.
Exceptions exist, and they expire. Each one lives in an overrides file with a reason, a date added, and an expiry roughly two weeks out. When it expires, the janitor flags it so someone either makes it permanent or deletes it.
We also added a check to the maintenance command that every command mentioned in any CLAUDE.md or README maps to a real file, and the reverse. It caught phantom commands that docs still referenced after deletion, and commands that existed with no documentation at all.
It grew back anyway
I’d like to say the pruning kept things small. It didn’t. By June 1 we were down to 96 tools even after adding new ones. On October 8 there were 155: 67 commands, 70 skills and 18 agents (what the commands do, by department).
Show the data
| Date | Total | Breakdown |
|---|---|---|
| March 1 | 41 | 16 commands, 22 skills, 3 agents |
| April 1 | 103 | 59 commands, 38 skills, 6 agents |
| June 1 | 96 | 46 commands, 42 skills, 8 agents |
| October 8 | 155 | 67 commands, 70 skills, 18 agents |
The growth since June is almost all new tools, not churn. Of the 96 on June 1, 92 were still in the same place on October 8. The root CLAUDE.md went from 32 lines in early March to 223 lines by then (what that file taught us), mostly rulings and guardrails added after something went wrong.
A company that does more work needs more procedures, so I don’t mind the count going up. What worries me is tooling nobody runs, and we still can’t measure that well. We built a hook to log which skills get used, and it has logged nothing (that story is in We Built Three Feedback Loops. None Collected Anything.). Right now the signal is a person noticing a command hasn’t come up in a month.
The janitor’s numbers since that first run, and what it still can’t clear, are in the company brain setup post.
How we decide what to delete
If you have too many skills and commands in Claude Code, these are the rules we use now:
- Every command is a promise. Keep it only if you’ll keep the procedure true when the company changes.
- Delete freely. Rebuilding is cheap, and the rebuild starts from a real event.
- Attach tools to rhythms. A weekly or monthly cadence brings people back. A one-off task waits for someone to remember it.
- Keep one source of truth for anything the AI might look up, or it will use whichever copy it finds first.
- Put enforcement in hooks and nightly jobs. A rule in a README only works if the AI happens to read it.
If you’re building your own and your .claude/ folder is getting crowded, I coach people through this on their own repo. Build It Yourself coaching is four 90-minute sessions for $1,997, you do the typing, and we decide together what to delete.
