惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
D
DataBreaches.Net
博客园 - 三生石上(FineUI控件)
博客园_首页
T
Tailwind CSS Blog
美团技术团队
Hugging Face - Blog
Hugging Face - Blog
博客园 - 叶小钗
大猫的无限游戏
大猫的无限游戏
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
云风的 BLOG
云风的 BLOG
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 聂微东
S
SegmentFault 最新的问题
小众软件
小众软件
酷 壳 – CoolShell
酷 壳 – CoolShell
N
Netflix TechBlog - Medium
Jina AI
Jina AI
WordPress大学
WordPress大学
U
Unit 42
J
Java Code Geeks
Blog — PlanetScale
Blog — PlanetScale
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
The Cloudflare Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
I installed 116 Claude Code skills. After 30 days I'd use...
Sergei Frang · 2026-05-18 · via DEV Community

Sergei Frangulov

I kept installing Claude Code skills because it's one command and it's free. Every time I saw a skill that looked useful, I added it. No cost, no friction, so why not. After 30 days I parsed my own session logs, just out of curiosity. I had 116 skills installed. I had actually used 35. I never noticed the other 81.

The problem

Skill marketplaces grow fast and installing is easy. One command, no review, nothing to pay. So people keep installing and nobody checks later which skills they actually use. Nothing forces you to check.

This is not free. Every installed skill loads its metadata into the prompt at the start of every session. So dead skills cost tokens for nothing, every session. With a normal dependency you eventually hit a version conflict or a security warning and you have to look at it. An installed skill never makes you look. It just sits in the prompt until you go and count.

How I measured it

I parsed my local ~/.claude session logs. No network, just the JSONL files the client already writes. I put every skill into one of four buckets:

  • active — installed and used
  • dead — installed, used zero times in the window
  • missing — used, but no SKILL.md found for it
  • hallucinated — used, but the runtime errored, because Claude confused a tool or command name with a skill name

The tool that does the parsing is skill-graveyard (github.com/sfrangulov/skill-graveyard). Here is the summary it printed for my 30-day window:

────────────────────────────────────────────────────────────
 skill-graveyard — 30d audit
 116 installed   35 active · 81 dead · 9 missing
              ██████████                        30% used
 274 sessions, 847 calls, 499 errored
 +65 hallucinated names (telemetry)
────────────────────────────────────────────────────────────

Enter fullscreen mode Exit fullscreen mode

116 installed, 35 active. That is 30% used. 81 dead, 9 missing. Across 274 sessions there were 847 skill calls and 499 of them errored. That error rate is high, so I looked closer.

The unexpected part

The most interesting bucket was not the dead one. It was the hallucinated one. Claude tried to call 65 names that are not skills at all: bash, read, agent, and 62 more. That is 493 failed calls, because the model used a tool or command name as if it were a skill name.

Here is the thing. bash, read, agent are real. They are real things the Claude Code runtime can do. But they are not skills. The runtime runs them through a different path: built-in tools and slash-style commands, not the skill loader. So the model wants a real capability, but it asks for it the wrong way. The skill loader fails, because that name is not a skill, even though bash works fine somewhere else.

So this bucket is not just junk. It is a signal. It shows how often the model mixes up the runtime's different paths. Dead skills tell you what to uninstall. This tells you where the model's idea of its own tools is wrong. I expected a cleanup report and instead found a debugging lead.

Try it on your own logs

If you use Claude Code, you can get the same four-bucket breakdown for your own setup. Run npx skill-graveyard. It runs locally, makes no network calls, and only reads your ~/.claude logs.

Run it and reply with your installed→active ratio. I want to know if 30% is normal or if I just install too much.

I did not decide to use only 35 of 116. It happened one easy install at a time, and I only saw it because I read the logs.

(The same four-bucket idea also exists for MCP servers via npx mcp-graveyard and project memory via npx memory-graveyard.)