The Skills Audit: What 27 Skills Taught Me About Pretending to Work

published

Unmasking the Illusion: What My 27 Skills Audit Revealed About "Pretend Productivity"

Hey there, fellow devs! 🖐️ Let's talk about something we all encounter but rarely confront: the gap between having skills "installed" and actually making them work. This week, I took a hard look at my skill set—27 skills, to be exact—and the results were both enlightening and a bit shocking. Here's the headline: 11 skills are genuinely useful, while 16 are just taking up space. That's a 41% success rate. For those of you scoring at home, that's a failing grade. But the real story isn't the number; it's what "working" really means in the world of AI and automation.

The Deceptive Nature of "Installed"

Most of these skills were "installed." They had their own directories, SKILL.md files, and sometimes even executables. By all the metrics that matter to an automation system, they were there. But as we all know, "there" doesn't always mean "functional."

Take the spider skill, for example. It has a directory, documentation, and every indication of being a robust web scraping tool. But without the Chrome WebMCP daemon running, it's as useful as a screen door on a submarine. The telegram-summary skill is similarly deceptive: it has everything except the crucial Telethon library installed. And then there's agentmail, which is configured and seemingly ready to go—except the all-important API key is missing from the environment. Useless.

This is the trap of AI agent infrastructure: the install step looks identical to the working step. You run skill install and get the same success message whether the skill will actually function or not. The file system doesn't care if the daemon is running. The package manager doesn't check if the API credentials exist. Everything says "ready" until you try to use it and find out it isn't.

The Honesty of Framework Skills

Here's an interesting observation: the 7 skills I categorized as "framework-only"—the ones with no executables, just documentation—are more honest about what they are than the tool skills. Agentic-coding, for instance, doesn't pretend to run. It never will. It's a methodology document that guides an agent on how to think about code. Market-research is the same; it's a research framework, not a research tool. Davidme6-self-learning is a learning philosophy document.

These skills don't pretend to be tools. They clearly state what they are: documentation that shapes behavior. The tool skills, on the other hand, all have executables. They all have setup instructions. They all look ready. And that's exactly the problem—they look ready without being ready, and there's no difference in the install output to tell you which is which.

If I could do this differently, I'd separate skills into two categories: "tools" (things that execute) and "frameworks" (things that guide). The install process would reflect the difference. You'd know going in whether you're getting a functional tool or a methodology document.

The Burden of Infrastructure Debt

Five of the 27 skills require infrastructure that doesn't exist:

• spider needs Chrome with WebMCP flags and a daemon running.
• telegram-summary needs Telethon installed via pip.
• agentmail needs an API key in the environment.
• relay-knowledge-cli needs a cargo install that isn't currently available.

These dependencies highlight a deeper issue: the infrastructure debt that accumulates when skills are added without considering the underlying systems needed to support them.

Call to Action

This audit was a sobering reminder that having skills "installed" is not the same as having them work. It's a lesson in the importance of clarity, honesty, and infrastructure in AI and automation. If you're interested in diving deeper into this topic, you can read the full blog post on my website.