I built 140 tools for work that never was

I built a skill that suggests new skills/hooks/scripts, ran it after sessions, and accepted the good ideas. Most sounded useful, because each was proposed right after the moment it would have helped.

Six months later there are 140 across 12 repositories, and I was not sure which were helpful rather than noise.

TL;DR:

Six months of accepting AI-suggested tooling produced 140 custom skills.
I never built the metric that would say for certain. My best estimate is that 103 have never run.
Usage is heavily concentrated in just a hendful of tools
The mistake underneath it - I built tools for work I was imagining, not work I was doing.

What accepting every good idea looks like

The largest untouched cluster is 40 files in one repository: 9 for sales, 8 wrapping calendar and mail, 7 for content.

The wrappers were a mistake outright, because a general tool already did that job. The sales and content ones are subtler: they are pre-built for work I have not started, betting the agent reaches for them when I do.

I had built tools for work I was imagining.

Measuring

I could not correctly, because a skill can be invoked 3 ways and my scan saw only the first:

✅ the agent calls it
❌ I type its name myself
❌ a cron runs it with nobody watching

So my numbers are not exact, but they are still scary.

Six months building tools to work faster, and nothing to tell me whether it worked.

Three bars: 140 skills sitting in repos, 37 with an invocation I could observe, 20 used repeatedly, with a note that those 20 carry 74% of observed use

Use is extremely concentrated. Of what I could observe, 20 tools carry 74% of invocations. The Pareto principle is usually advice to find your best fifth; the warning is the other four fifths, which are inventory, and inventory costs.

Cadence decides survival. Everything that fired is on a schedule or part of a weekly habit: the retrospective, the branch sync, the merge, the status check. The untouched ones are annual jobs, and I have forgotten the tool by then.

Cheap to make is not cheap to keep

Building a tool used to cost an afternoon, so you thought hard first. Now it costs four minutes. Keeping it did not get cheaper: it must still be findable, trusted and true in three months.

The real skill now is not writing the tool. It is deleting it without ceremony.

The takeaway

Dead code and unread dashboards are the same disease. Only the speed changed. On Monday:

Ask yourself before you build, “Do I really need it?” Weekly or more, build the tool. Once a year, do not: you will have forgotten it. Put the knowledge where it finds you, or put the tool on a cron.
Ship the metric with the tool, not after 140 of them. Mine took twenty minutes and immediately proved me wrong, which is the point.
Run a monthly cleanup against that metric. Not when the mess irritates you, because by then it has been costing you for months. Delete what has not fired; git holds it.

A note on precision, and what would change my mind

The 140 is a directory count and is solid. The usage numbers come from a scan of 355 session transcripts and 236,313 events, 2026-04-03 to 2026-08-04, and they are a lower bound rather than a reading: that scan could only see the first of the three paths above, so a tool I run by hand or on a cron looks identical to one nobody touches. Two days of logging all three paths was already enough to prove several supposedly-dead tools alive. I measured whether tools ran, never whether they are any good. Thirty days of the complete log settles the cadence claim: if tools whose job recurs weekly do not clearly out-run the rare-job ones, cadence is the wrong explanation and I will publish that instead.

The tool built to catch exactly this is /skill-usage, whose only job is listing tools that never get called. Until I ran it for this post, it never had been.