We Deleted 52 Skills and Commands 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.

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. (If you want the mechanics of skills and commands themselves, the guide covers them. This post is about running a pile of them for a business.)

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.

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, 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.

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 run about 330 lines today, and they get used because they were written against a real close.

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 enforced it at three levels. A hook runs before every file write and blocks writes to paths the schema doesn’t recognize. 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 first janitor run found 218 issues and moved zero files. It flagged 24 for a human. That ratio was the point. 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. Today there are 157: 67 commands, 72 skills and 18 agents. The root CLAUDE.md went from 32 lines in early March to 223 lines now, 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.

What I’d tell anyone running AI tooling for a team: treat every command as a procedure you’re promising to keep true. Delete freely, because rebuilding is cheap. Attach tools to rhythms. Keep one source of truth for anything the AI might look up. And put enforcement in hooks and nightly jobs, because a rule in a README only works if the AI happens to read it.

If you want this kind of brain for your team, with the pruning habits built in from the start, I set them up in 14 days.