Why the skills you build stop getting used
In brief
Most teams build more skills than they use. The inventory grows; the invocation count per skill falls. Here's why skills die after the first week — and what to do instead.
Contents
There's a pattern in almost every Claude Cowork rollout that's been running for more than two months.
The team has a skill library. Some skills in that library are used constantly — people run them every day, they've become part of how work gets done. Most skills in that library haven't been touched in weeks. Nobody remembers they exist.
This is the skills graveyard problem. It's not a failure of ambition. It's a failure of design, discovery, and timing.
What the data shows
When you query your skill invocation logs and sort by last_used_at, you almost always see the same shape: 20% of your skills account for 80% of all invocations. The rest sit there.
Skills built but never used fall into a predictable pattern. They were created when someone had a good idea. They were announced once — usually in Slack, usually on the day they launched. They got used for the first two weeks while the idea was fresh. Then something else came up, the novelty wore off, and the skill stopped appearing in anyone's working memory.
This isn't unique to Claude skills. It happens with Notion templates, Slack workflows, Zapier automations, and every other "build it once, use it forever" tool. The difference with Claude skills is that the failure is invisible. A broken Zapier automation sends you an error. An unused skill just sits there silently, making your skill library look bigger than it is.
The three reasons skills die
1. Too narrow a use case
The skill was built for a task that comes up once a month, not once a day. When the task finally arrives, nobody remembers the skill exists. They do it manually.
Skills with daily or weekly natural recurrence survive. Skills built for monthly or quarterly tasks usually don't — not because they're bad skills, but because they're not embedded in a habit.
The fix: before building a skill, ask "how often will someone naturally reach for this?" If the honest answer is "once a month," consider whether a documented prompt template in Notion serves the same purpose with less maintenance overhead.
2. Discovery failure
The skill exists but people don't think to use it at the moment they need it. Cowork's skill surface is a slash command — you have to know the skill name to invoke it. If someone wasn't in the meeting where the skill was announced, they may not know it exists.
This is different from the skill being bad. The skill might be excellent. The problem is that people can't recall it at the moment they need it.
The fix: onboarding shouldn't list skills — it should invoke them. Instead of "here are the skills available to you," give new users a prompt: "Try typing /[skill-name] right now, with your most recent customer call in mind." The skill only exists in someone's workflow once they've run it and seen what it does.
3. The skill is too slow or too complicated
A skill that takes 45 seconds to run and produces a dense report doesn't get used, even if the output is valuable. People will reach for it when they have time. They rarely have time.
The best-used skills produce a result in under 15 seconds and surface one clear thing. The weekly briefing that gives you five bullet points beats the comprehensive analysis that gives you a 12-section report.
The audit
Run this quarterly. It takes about an hour and it's more valuable than building three new skills.
Step 1: Pull invocation data
For each skill in your library, find: total lifetime invocations, number of distinct users who've invoked it, and last invoked date.
If you don't have telemetry yet, you can do this by asking your team directly: "Which Cowork skills do you use regularly?" The ones that come up without prompting are the keepers. The ones nobody mentions need investigation.
Step 2: Classify each skill
- Active: Used by multiple people in the last 30 days. Keep as is.
- Dormant: Used occasionally but not regularly. Investigate why — is it a timing problem, a discovery problem, or is the use case genuinely infrequent?
- Dead: Not used in 60+ days. Retire it or redesign it. Don't leave it in the library.
Step 3: Retire before building
For every skill you want to add, retire one dead skill first. This keeps the library small enough to be discoverable. A skill library with 30 entries is unusable. A library with 8 entries, all actively used, is powerful.
What makes a skill stick
The skills that survive have four things in common:
1. They solve a daily problem. Not a quarterly one. The person using them knows exactly when to reach for them because they hit the trigger every day.
2. They produce something shareable. A morning briefing someone can paste into Slack. A customer summary someone can paste into a handoff note. A draft someone can send. Output that immediately goes somewhere is output people remember they got.
3. They were introduced through use, not announcement. The first time someone used the skill, another person walked them through it. Or they were onboarded to Cowork via a skill invocation, not a doc.
4. They fail fast and informatively. When a skill can't complete its task — because a connector is down, or the data isn't there — it says so clearly instead of producing a half-baked result. Skills that fail silently erode trust faster than almost anything else.
The skill you should build next
Before you add anything new to your library, answer this question: "What's the one thing my highest-usage person does manually every week that Claude could handle?"
That person has already proven the workflow is real and recurring. They've already solved the discovery problem (they'd use the skill because they do the task every week). The only design work is turning their current manual process into a skill that runs in under 15 seconds.
Start there. Then audit what you have. Then — and only then — build something new.
Try this today
Open your Cowork and run your most-used skill. If you don't know what your most-used skill is without checking, that's the answer — you have a discovery problem that training won't fix, because you manage the system and even you can't recall it.
The fix is almost never "build another skill." The fix is usually "make the existing skills harder to forget."